It's sRGB, not sRBG.
Phoronix: Freedreno Gallium3D Now Handles sRBG Textures, OpenGL 2.1
Rob Clark's work on the Freedreno Gallium3D driver continue to prosper with hitting yet another achievement for this open-source, reverse-engineered Qualcomm Adreno graphics driver for Linux...
It's sRGB, not sRBG.
And that does make me feel bad since I'm supporting them because of work you are doing, but literally not one of the major ARM SoC producers grant me my software freedoms.
You should probably write Qualcomm and tell them you are are selling them units because of your driver. Maybe they could stop having a stick up their ass and release some programming documentation on their black boxes.
Rob, I have a question that is unrelated to this commit. I can't seem to find glDrawElementsBaseVertex in any of the GLES specifications, not even the brand new 3.1. Is this something fundamentally difficult to support on mobile chips? I recall 32bit indices only being available on GLES3 and later. Is that somehow related?
The community board vendors are advertising freedreno support, for example:
http://www.braincorporation.com/bstem-faq/ (see "Does the bstem offer 3D support?")
and I believe once the new linaro qualcomm landing team starts cranking out builds, they will be using freedreno as well.
Also, I do talk with a few of their kernel developers from time to time. They've helped me out with a few little things here and there on the kernel side. And I've given some of them some informal training about drm/kms and the linux graphics stack. So they definitely seem to want to do the right thing.
Obviously the userspace part is a bit more touchy. I'm sure there are plenty of individuals in qualcomm who would like to be able to share docs, etc. But it is not straightforward.
Because of the competive pressures (read "omg, benchmarks") on the mobile space, I'm not really sure I could expect any of the mobile vendors to just dump their closed drivers and all there secret sauce. Mesa is a very "honest" GL driver compared to all the tricks blob drivers (and I would assume that includes qcom's blob driver) play: shader replacement, app specific GL entry points, etc.
But I'm optimistic about how things are going, and I expect we should be able to get a good cooperation going at least on the kernel side. And that is at least a really good start.
(fwiw, it does appear that adreno can support this but I don't see it exposed via extension, at least not in the version of blob driver I have.. but could just mean they did not have time to implement..)
I feel better knowing they are at least better than Nvidia, but just your work should be setting off alarm bells in their heads that they are overinvesting in a pointless closed sourced blob driver when one ultra-smart and great guy can crank out something that actually works (see the Dolphin blog posts about mobile drivers) and is certainly much more maintainable, portable, etc.But I'm optimistic about how things are going, and I expect we should be able to get a good cooperation going at least on the kernel side. And that is at least a really good start.
Then again, that applies to all the proprietary drivers. And honestly AMD is the testament to that, by having two drivers - radeon is so much more stable, even if it lacks in performance due to just a lack of developer man hours, and their entire ecosystem (Gallium) is enabling all these other drivers too. Compare that to Catalyst, which rarely even works under Linux and is this massive piece of shit, that they have over a hundred developers on.
Keep fighting the good fight, and know there are users out there, and that we are advocating where we can to use the open driver stack.
Open Source drivers going towards a bright future.
Please keep implementing more, OpenGL ES 3 is more important to many applications than OpenGL 3.x.