Freedreno Gallium3D Is Passing 90%+ Of Piglit Tests

[robclark]

I remember robclark saying the DSP/sound driver is also closed source.

not sure about devices with onboard modem.. but ignoring modem there are firmware blobs for vidc (video encode/decode), audio, and gpu.. But we have the kernel src for everything and other than blob libGLES/libEGL, everything else has open userspace.

The bigger problem with audio is that it has a pretty massive downstream kernel driver that only a mother could love, which would need a lot of work to get it into shape where it could be merged upstream. Some of the linaro folks where doing some investigations to see if they could write a simple "bypass" audio driver for upstream which did not use the DSP and was clean enough to push upstream.

[robclark]

I wanted to buy an ifc6410 board, but even if you select the Ubuntu version with open source drivers, it requires you to sign away your soul to the worst piece of click-through license agreement I've ever read.

It limits you to non-commercial usage, bans reverse-engineering, bans teaching people with it, bans using it for any kind of radio, makes you agree to defend them in court at your cost, and says "Inforce may terminate this Agreement at any time" at which point you have to "return or destroy" (their choice) the device at your cost while you are still liable for everything else in the contract forever.

What the heck...?

yeah.. qcom has too many lawyers.. Some of those parts do make sense (ie. radio stuff is, I expect, because the device has not gone through FCC certification). I do hope they manage to come up with something more sane, but some parts I've managed to work around (for example, using instead blob drivers from my n4 for r/e work).

[liam]

not sure about devices with onboard modem.. but ignoring modem there are firmware blobs for vidc (video encode/decode), audio, and gpu.. But we have the kernel src for everything and other than blob libGLES/libEGL, everything else has open userspace.

The bigger problem with audio is that it has a pretty massive downstream kernel driver that only a mother could love, which would need a lot of work to get it into shape where it could be merged upstream. Some of the linaro folks where doing some investigations to see if they could write a simple "bypass" audio driver for upstream which did not use the DSP and was clean enough to push upstream.

Vidc is a separate component? I know there's a lot of weird decoupling in the embedded space but that doesn't make a whole lot of sense, IMHO.
Is that DSP hexagon? I know I recall them a press release awhile back that said they were opening it up to 3rd party devs, and had a number of libraries, but I don't know the terms of use.
BTW, are you familiar with the basemark benchmark? There's a test in there which submits tons of draws to measure driver overhead. For some reason adreno(and Android in general) does terribly. Is that purely driver related or is there something issue you've come across in hardware that would cause submissions to be a bottleneck? Are context clears particularly slow?

[robclark]

Vidc is a separate component? I know there's a lot of weird decoupling in the embedded space but that doesn't make a whole lot of sense, IMHO.
Is that DSP hexagon? I know I recall them a press release awhile back that said they were opening it up to 3rd party devs, and had a number of libraries, but I don't know the terms of use.

yeah, separate component (as in separate IP block, not separate chip). I don't believe it is hexagon (although maybe they use the dsp to implement part of new standards, like h265, before they have full hw support). No one really uses the dsp for viddec/videnc heavy lifting anymore, too power hungry.

BTW, are you familiar with the basemark benchmark? There's a test in there which submits tons of draws to measure driver overhead. For some reason adreno(and Android in general) does terribly. Is that purely driver related or is there something issue you've come across in hardware that would cause submissions to be a bottleneck? Are context clears particularly slow?

It's hard to say specifically.. it depends on what state changes happen in between the draws. If you toggle between two render targets on a tiler, for example, your perf will suck. If it is just a gazillion draws with no other state change, then it could just be crappy drivers. I'd hazzard a guess that only nvidia has experience optimizing per GL call overhead (from back in the gl1 days)..

afaiu android does have a EGL (and I assume GLES?) dispatch shim for some reason.. I'm sure that adds *some* overhead (but I'd hope it is just a matter of an extra fxn ptr call)

[liam]

yeah, separate component (as in separate IP block, not separate chip). I don't believe it is hexagon (although maybe they use the dsp to implement part of new standards, like h265, before they have full hw support). No one really uses the dsp for viddec/videnc heavy lifting anymore, too power hungry.

OK, I was a bit ambiguous. The "that" I was referring to when I mentioned hexagon was the audio offloading that you mentioned as relying on a lovely little, un-upstreamable driver. I was wondering if hexagon was the DSP used for audio offloading? I searched for linaro and hexagon but the most recent hit was from a meeting in 2011.

It's hard to say specifically.. it depends on what state changes happen in between the draws. If you toggle between two render targets on a tiler, for example, your perf will suck. If it is just a gazillion draws with no other state change, then it could just be crappy drivers. I'd hazzard a guess that only nvidia has experience optimizing per GL call overhead (from back in the gl1 days)..

afaiu android does have a EGL (and I assume GLES?) dispatch shim for some reason.. I'm sure that adds *some* overhead (but I'd hope it is just a matter of an extra fxn ptr call)

Sorry, that should've been gfxbench, not basemark.
I've searched a good deal and not been able to find definitive info about how they run that test.
The consensus seems to be that a bunch of (simple)objects are created and then changed (presumably naively, rather than using something like instanced rendering), so state seems to be altered. The constant seems to be that Qualcomm has pretty much the least efficient drivers around (and apple/IMG the most efficient by a mile). The shim may explain the difference between apple and android (though given the rather massive delta it seems likely to be something else) but not between adreno/Mali/Nvidia/IMG on android, I think.
BTW, I'm not sure the egl/gles shims are still used as of android 4.4 (http://www.2net.co.uk/tutorial/android-egl-cgf-is-dead), since you can now link directly to /vendor/lib/.

[robclark]

OK, I was a bit ambiguous. The "that" I was referring to when I mentioned hexagon was the audio offloading that you mentioned as relying on a lovely little, un-upstreamable driver. I was wondering if hexagon was the DSP used for audio offloading? I searched for linaro and hexagon but the most recent hit was from a meeting in 2011.

ahh.. yeah, the audio driver seems to load some dsp firmware.. I couldn't tell you exactly what all they use the DSP for, but I assume for things like echo cancellation and other sorts of stuff that you need for voice calls.

Sorry, that should've been gfxbench, not basemark.
I've searched a good deal and not been able to find definitive info about how they run that test.
The consensus seems to be that a bunch of (simple)objects are created and then changed (presumably naively, rather than using something like instanced rendering), so state seems to be altered. The constant seems to be that Qualcomm has pretty much the least efficient drivers around (and apple/IMG the most efficient by a mile). The shim may explain the difference between apple and android (though given the rather massive delta it seems likely to be something else) but not between adreno/Mali/Nvidia/IMG on android, I think.
BTW, I'm not sure the egl/gles shims are still used as of android 4.4 (http://www.2net.co.uk/tutorial/android-egl-cgf-is-dead), since you can now link directly to /vendor/lib/.

I would be interested if someone could get an apitrace of what that test does.. I'm a bit curious. I don't suppose you have handy a link to results comparing the various different android drivers and apple?

[liam]

ahh.. yeah, the audio driver seems to load some dsp firmware.. I couldn't tell you exactly what all they use the DSP for, but I assume for things like echo cancellation and other sorts of stuff that you need for voice calls.

http://releases.linaro.org/14.09/ubuntu/ifc6410

That's the most recent link I've found while searching for "linaro Qualcomm audio dsp firmware".
Do you have any links that point to the discussions about the upstreaming attempts? All I've found indicates that only blobs exist.

I would be interested if someone could get an apitrace of what that test does.. I'm a bit curious. I don't suppose you have handy a link to results comparing the various different android drivers and apple?

Most of the big review sites will have this data. This is from anandtech and represents off screen results:

http://www.anandtech.com/bench/PhoneTablet14/972