As nitin requested, add a bug to track the build warnings.

Hi Ross,
  I think we will need to bring back the 7.11.x version of mesa-dri for EMGD. I notice many changes in mesa recipe lately. Will bringing back the old mesa 7.11 recipe good enough ? or does it need further changes? If you can help me with bringing back the mesa 7.11 recipe that would be great.

Thanks,
Nitin

But crownbay uses EMGD so it doesn't need mesa-dri at all, the preferred version declaration is redundant surely.

Ross,
 The EMGD driver expects mesa as one of it's dependency. 

This is from EMGD's documentation.
MeeGo* IVI 1.2, kernel version 2.6.37, Xorg 1.9.X, Libva 1.0.12, Mesa 7.9.1

There is a problem though. Saul and I have been looking into a failure with EGL/libgl.h (or something like that) and we find that both emgd-driver-bin and mesa-dri provide that file. So installing both seems like a problem.

Darren,
  emgd always pulled the mesa-dri with it in the images. So I am surprised how I did not see that issue yet.

BTW to meet EMGD's requirements more accurately I have brought mesa-dri_7.11.2 recipe into meta-intel now. 

Nitin

Have you observed a problem with version 8? Or are you just trying to satisfy the version listed in the documentation (which may very well just be out of date) ?

Darren,
  I was doing few test to see if version 7.11.2 of mesa-dri is any better than 8.0.4. In my finding I did not find any differences for EMGD graphics. 
   My intention was to keep the EMGD dependencies exactly as mentioned in the EMGD user guide, to avoid any future unexpected usage issues that don't get covered up in our testing.
   I already have the recipe mesa-dri_7.11.2 in my local meta-intel repo. And I have tested crownbay BSP with it. So let me know if I should send a pull request for it.

Thanks,
Nitin

Ah, right, so EMGD uses Mesa for libGL, and provides it's own libGLESv1, libGLESv2 and libEGL.

Let's step through the warnings one by one, as the report was about "warnings" in general.

(In reply to comment #0)
> NOTE: preferred version 7.11 of mesa-dri not available (for item
> virtual/libgl)
> NOTE: versions of mesa-dri available: 2:8.0.4
> 2:8.0.4+git1+c1f4867c89adb1a6b19d66ec8ad146115909f0a7

If EMGD needs a specific version of mesa (which it does, at runtime), then meta-intel should provide it.

> WARNING: bzip2: No generic license file exists for: bzip2 in any provider
> WARNING: bzip2-native: No generic license file exists for: bzip2 in any
> provider

Fixed in oe-core.

> WARNING: The recipe is trying to install files into a shared area when those
> files already exist. Those files are:
>   
> /home/trz/yocto/crownbay-tracing/build/tmp/sysroots/x86_64-linux/usr/share/
> sgml/openjade-1.3.2/catalog

oe-core is whitelisting this for now.

> WARNING: emgd-driver-bin: No generic license file exists for:
> Intel-binary-only in any provider

This is a license thing that should be fixed.

> This BSP sets 2 invalid/obsolete kernel options.
> These config options are not offered anywhere within this kernel.
> The full list can be found in your kernel src dir at:
> meta/cfg/standard/crownbay/invalid.cfg
> 
> This BSP sets 13 kernel options that are possibly non-hardware related.
> The full list can be found in your kernel src dir at:
> meta/cfg/standard/crownbay/specified_non_hdw.cfg

I'll let Tom worry about these. :)

> WARNING: The recipe is trying to install files into a shared area when those
> files already exist. Those files are:
>   
> /home/trz/yocto/crownbay-tracing/build/tmp/sysroots/crownbay/usr/include/
> python2.7/pyconfig.h
> ...

Again, fixed in oe-core master.

> /home/trz/yocto/crownbay-tracing/build/tmp/sysroots/crownbay/usr/include/
> GLES2/gl2.h
> ...

This is emgd-driver-bin writing the same files as mesa-dri is writing, because they are both GLES/EGL providers.

I've spent the morning figuring out what EMGD is trying to do.  EMGD is a re-badged PVR driver from Imagination, and thus supports EGL and GLES (v1/v2).  It also has a DRI driver that gives it something approximating OpenGL support.

This DRI driver is *incredibly* dependent on the Mesa version it was compiled against, down to the configure flags used.  Has anyone tested it? (glxgears doesn't count, that can fallback to software and you'd never know)

What 3D tests/benchmarks do we have available? Do we need to get one packaged up?

We use glxgears and glxinfo.  We should have better tests, but glxinfo should at least tell you for sure whether hardware rendering is being used.

glxgears in software is often indistinguishable from hardware.  glxinfo will tell you if the stack thinks it's rendering via HW, but thanks to Imagination's "special" you'll often fall back to software anyway.

Also glxgears/glxinfo are GLX, and therefore GL, specific.  SGX hardware (thus anything EMGD, and Cedar Trail) really doesn't like GL and much prefers GLESv2 so we *really* need stuff packaged for that.

The Clutter tests are far more useful at demonstrating that hardware is working.  Annoyingly fixing our packaging was on my list but didn't happen in time.

I think when we enable h/w acceleration we do not package the s/w emulation libraries. so that should be good enough to test if h/2 acceleration is working or not. Also we watch for the CPU utilization at video playback, and it can also reliably detects if h/w acceleration is working or not. but if there are tests which will add value it is worth considering.

Of course GL acceleration is orthogonal to video acceleration.

Video is trivial to test: give it a 1080p h264 and if it plays back fine it's accelerated.  Without hw assistance 1080p on Atom runs at about 1fps!

(In reply to comment #13)
> glxgears in software is often indistinguishable from hardware.  glxinfo will
> tell you if the stack thinks it's rendering via HW, but thanks to
> Imagination's "special" you'll often fall back to software anyway.
> 

Can you explain what you mean by 'Imagination's "special"'?  Is there any easy way to detect the fallback to software, or is there any simple way to determine with certainty that hardware acceleration is being used?

Hm, that "imagination special" sentence isn't quite right - I must have lost my place when writing.

What I was basically saying is that Imagination don't terribly care about OpenGL, only GLESv2.  I've more experience with the Cedar Trail core/drivers which is a close relation but not identical to the EMGD drivers, but on that IMG refused to fix GL bugs.

You can identify when HW is really being used by running something that doesn't work in software.  The game Neverball was the standard test in MeeGo, which also doubled as a convenient "look how broken GL is" because surfaces would randomly disappear..  I'm finding out if there's a clutter test that would be quick and easy to run - there's a flowers test that animates lots of textures which should do the job.

I did run the flowers test from the clutter test suite on crownbay. And it ran without any issues.

All these warnings are fixed now.