Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Freedreno Gallium3D Now Handles sRGB Textures, OpenGL 2.1

  1. #1
    Join Date
    Jan 2007
    Posts
    15,607

    Default Freedreno Gallium3D Now Handles sRGB Textures, OpenGL 2.1

    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

  2. #2
    Join Date
    Nov 2012
    Location
    France
    Posts
    624

    Default

    It's sRGB, not sRBG.

  3. #3
    Join Date
    Sep 2011
    Posts
    292

    Default

    Quote Originally Posted by Calinou View Post
    It's sRGB, not sRBG.
    yeah, I fat-fingered it in the commit subject line (but had it right in the body) :-P

  4. #4
    Join Date
    Dec 2012
    Posts
    586

    Default

    Quote Originally Posted by robclark View Post
    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.

  5. #5
    Join Date
    Aug 2011
    Posts
    569

    Default

    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?

  6. #6
    Join Date
    Sep 2011
    Posts
    292

    Default

    Quote Originally Posted by zanny View Post
    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.

  7. #7
    Join Date
    Sep 2011
    Posts
    292

    Default

    Quote Originally Posted by Ancurio View Post
    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..)

  8. #8
    Join Date
    Dec 2012
    Posts
    586

    Default

    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.

  9. #9
    Join Date
    Sep 2010
    Posts
    488

    Default

    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.

  10. #10
    Join Date
    Jan 2012
    Posts
    121

    Default

    Quote Originally Posted by plonoma View Post
    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •