Freedreno Gallium3D Now Handles sRGB Textures, OpenGL 2.1

[phoronix]

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...

http://www.phoronix.com/vr.php?view=MTY5MjM

[Calinou]

It's sRGB, not sRBG.

[robclark]

It's sRGB, not sRBG.

yeah, I fat-fingered it in the commit subject line (but had it right in the body) :-P

[zanny]

yeah, I fat-fingered it in the commit subject line (but had it right in the body) :-P

I wanted to let you know I'm almost exclusively buying Snapdragon based systems nowadays because of how solid freedreno is becoming. I figure if any of these devices will be usable in the future with a full open stack, it will be those, despite the hostile attitude of Qualcomm.

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.

[Ancurio]

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?

[robclark]

I wanted to let you know I'm almost exclusively buying Snapdragon based systems nowadays because of how solid freedreno is becoming. I figure if any of these devices will be usable in the future with a full open stack, it will be those, despite the hostile attitude of Qualcomm.

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.

btw, it isn't really something I've talked about publically before (mostly because it isn't to the point of anything newsworth), but I would say that qcom is definitely not hostile to freedreno.

The community board vendors are advertising freedreno support, for example:

http://inforcecomputing.com/blog/?p=140

and

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.

[robclark]

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?

tbh, I'm not really sure. I'm not a GL spec expert. I kinda approached gl drivers from the bottom up, rather than top down.. at this point most of the GL code I've written is tests to get cmdstream dumps for various features from blob driver. But if I understand glDrawElementsBaseVertex would require some hw support to add an offset to the value in the index buffer before using it to index into the vertex buffer. So probably some vendor(s) could not do that and fought against it being in the GLES3 spec.

(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..)

[zanny]

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.

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.

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.

[plonoma]

Wonderful news.

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.

[ssvb]

Please keep implementing more, OpenGL ES 3 is more important to many applications than OpenGL 3.x.

Which applications? Could you please provide a list?