Announcement

Collapse
No announcement yet.

Intel's Mesa Driver Tacks On Another GL Extension For Old Hardware

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Intel's Mesa Driver Tacks On Another GL Extension For Old Hardware

    Phoronix: Intel's Mesa Driver Tacks On Another GL Extension For Old Hardware

    The OpenGL EXT_polygon_offset_clamp extension has been supported in mainline Mesa for the Intel i965 Mesa DRI driver for some time while now this extension is supported for older Intel Gen 4/5 hardware...

    http://www.phoronix.com/scan.php?pag...et-Clamp-Gen45

  • #2
    Wasn't Illia recently become a employee of Intel or am I confusing him with another nouveau developer?

    Comment


    • #3
      Originally posted by andrei_me View Post
      Wasn't Illia recently become a employee of Intel or am I confusing him with another nouveau developer?
      no, I think you're talking about Martin Peres.

      Comment


      • #4
        Originally posted by andrei_me View Post
        Wasn't Illia recently become a employee of Intel or am I confusing him with another nouveau developer?
        Can't say for sure who you're thinking of, as a number of developers associated with nouveau at one point or another work at Intel or as their contractor, but I can say with some certainty it wasn't me.

        Comment


        • #5
          Thank you. I am one of those "being stuck" with a Gen4 Intel Chip. Do you know why this has not been added by Intel?

          That document states that OpenGL 3.3 is required for GL_EXT_polygon_offset_clamp:

          https://www.opengl.org/registry/spec...fset_clamp.txt

          But Mesa on Gen4 and Gen5 graphics chips provides only OpenGL 2.1. Is that a problem?

          Comment


          • #6
            Originally posted by kmare View Post

            no, I think you're talking about Martin Peres.
            Yeah, you are rigth:

            http://www.phoronix.com/scan.php?pag...veau-Developer

            Comment


            • #7
              Intel's own old hardware support is a fucking shame. On gen 4/5 under Linux you'll get at most something like ancient OpenGL 2.1. And some of these GPUs are just 4-5 years old, dammit. I bet windows driver can do at least GL 3.3, if not something like 4.2 on these gen's. Not to mention it is costly to upgrade GPU in Intel's case (gen4/5 are usually integrated into M/B chip set). I wonder if Intel would do the same trick with more recent GPUs some couple of years later.

              Comment


              • #8
                Originally posted by SystemCrasher View Post
                Intel's own old hardware support is a fucking shame.
                They are the fastest of the three desktop GPU vendors when it comes to dropping support, that's true.

                Originally posted by SystemCrasher View Post
                On gen 4/5 under Linux you'll get at most something like ancient OpenGL 2.1. And some of these GPUs are just 4-5 years old, dammit. I bet windows driver can do at least GL 3.3, if not something like 4.2 on these gen's.
                Nope, it's 2.1 on Windows as well. But it doesn't matter much there, because there's Direct3D 10.0. The GPUs aren't capable of 3.3, I recall a comment from Chris Forbes that most of 3.2 could be done if you'd fake multisampling. The extension that should be done first is GL_ARB_uniform_buffer_object (opengl 3.1)

                But the driver's issues go beyond opengl version numbers, much more important stuff like fast color clears and HiZ are missing.

                Originally posted by SystemCrasher View Post
                I wonder if Intel would do the same trick with more recent GPUs some couple of years later.
                Of course they will, they do it all the time. Haswell is barely on their radar, Ivy Bridge is already off it.
                Last edited by Gusar; 06 October 2015, 02:45 PM.

                Comment


                • #9
                  Oh wow, what a lovely useful extension. It's a nice companion to GL_DEPTH_CLAMP_SEPARATE.

                  Comment


                  • #10
                    Originally posted by SystemCrasher View Post
                    Intel's own old hardware support is a fucking shame. On gen 4/5 under Linux you'll get at most something like ancient OpenGL 2.1. And some of these GPUs are just 4-5 years old, dammit. I bet windows driver can do at least GL 3.3, if not something like 4.2 on these gen's. Not to mention it is costly to upgrade GPU in Intel's case (gen4/5 are usually integrated into M/B chip set). I wonder if Intel would do the same trick with more recent GPUs some couple of years later.
                    What are you talking about? The *hardware* can't do multisampling which is required for 3.0. We expose the highest GL version the hardware is capable of, plus a ton of extensions (you're commenting on a thread about the addition of a new extension for those very platforms!)

                    Originally posted by Gusar View Post
                    They are the fastest of the three desktop GPU vendors when it comes to dropping support, that's true.
                    And what are you talking about? We still maintain Gen4 and Gen5. They're part of the *same* driver as Gen6-9. All the NIR work benefits them too.

                    Originally posted by Gusar View Post
                    Nope, it's 2.1 on Windows as well. But it doesn't matter much there, because there's Direct3D 10.0. The GPUs aren't capable of 3.3, I recall a comment from Chris Forbes that most of 3.2 could be done if you'd fake multisampling. The extension that should be done first is GL_ARB_uniform_buffer_object (opengl 3.1)
                    What would UBOs allow you to do with Gen4/5?

                    Originally posted by Gusar View Post
                    But the driver's issues go beyond opengl version numbers, much more important stuff like fast color clears and HiZ are missing.
                    HiZ doesn't even exist on Gen4, and it's semi-broken and isn't really worth implementing on Gen5. Fast color clears don't exist on those platforms either. There's a "replicated data" message that can be used to implement a kind of crappy fast color clear that exists on those platforms, and Ken has a branch that uses it, but couldn't measure any performance difference.

                    So again, why are you so confident about your ridiculous claims? We wrote the i965TODO page to help people find projects and get involved, not for clueless people to misinterpret and use as evidence that we're not supporting 9 year old hardware.

                    Originally posted by Gusar View Post
                    Of course they will, they do it all the time. Haswell is barely on their radar, Ivy Bridge is already off it.
                    Again, absurd.

                    Comment

                    Working...
                    X