Announcement

Collapse
No announcement yet.

Intel Brings OpenGL 2.0/2.1 To Classic i915 Mesa Driver

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

  • Intel Brings OpenGL 2.0/2.1 To Classic i915 Mesa Driver

    Phoronix: Intel Brings OpenGL 2.0/2.1 To Classic i915 Mesa Driver

    While there's been talk recently of defaulting the Intel i914/i945 hardware support to using Gallium3D rather than the longstanding classic i915 Mesa DRI driver, some new features were just introduced into the i915 classic world...

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

  • #2
    Qt 5!

    Great news, that means I will be able to use Qt 5 on my dated Stylistic Tablet!

    Comment


    • #3
      Intel needs to get over its aversion to Gallium

      This is the one and only thing that bothers me about Intel's OSS strategy. The move is clearly toward Gallium.(every other manufacturer, I mean) But Intel has it's drivers stuck in the mud of "classic".

      It's one thing if they're carrying the huge brunt of the load for their own drivers, great. Then that's up to them. If you don't want to port your over to gallium, then don't. I respect that you're doing the huge work on the new drivers, and you do it as you want. But the i915 gallium driver is eclipsing the old classic driver.

      Just let it die! Put your patches in the gallium driver instead! What's wrong with that? Normally, those who want to try to get the gallium driver up and running are chasing after the classic, but in this instance, it's Intel who's re-inventing the wheel. The gallium driver already had these.

      I just don't get it. Why not say "If the gallium drivers start coming close, then let's just support that one instead. That's where the heavy lifting is taking place now. We see the shift, we understand."

      Comment


      • #4
        Originally posted by halfmanhalfamazing View Post
        I just don't get it.
        Seriously not trolling here, but I think this is the most important part of your post. Gallium isn't some silver bullet. It actually is a bad fit for i915 since Gallium doesn't have any ability to fallback to software on fragment shaders (hence the dummy fragment shaders when something bad happens). i915 has some severe fragment shader limitations (three texture indirections, very small number of instructions, etc.) so this is kind of a bad fit.

        As far as eclipsing... I don't know what you're seeing to support that. http://www.phoronix.com/scan.php?pag..._default&num=1 shows that i915g is meaningfully faster in only a single benchmark, and *much* slower in most others. Eric's piglit comparison shows that i915g is much less conformant than i915c: http://people.freedesktop.org/~anhol...g/changes.html . Extra extensions supported by i915g like ARB_draw_instanced are just because it does all its vertex shaders in software. Kind of uncompelling.

        Comment


        • #5
          Improving i915 is like improving IE6, a waste of time and a reason for someone to use dusty rusty hw.

          Comment


          • #6
            Originally posted by mark45 View Post
            Improving i915 is like improving IE6, a waste of time and a reason for someone to use dusty rusty hw.
            I love the "if I don't use it it's useless crowd". Why don't you get back to your haswell and let me be satisfied with the hardware that I have.

            Comment


            • #7
              Tried on intel gen3. Breaks Unity destkop badly.

              Tried on an eeepc with intel gen3 graphics.

              Indeed, I see the opengl 2.1 advertised as well as the shading language level 1.2.
              But the issue is that this change breaks the Unity desktop to the point of making it unusable.
              Try to log-out to realize why, or to use the "search your computer" function.

              I believe that the issue is that now unity thinks that it can rely on some hardware features, that conversely are so painfully slow that make everything hang whenever they are invoked. As a matter of fact, whenever you see unity hanging, if you give enough time to it you will see that it is actually trying to play a fading or a translucency effect.

              Any way to force the graphics driver to advertise opengl 1.4 only as it was before?

              Comment


              • #8
                Originally posted by callegar View Post
                Any way to force the graphics driver to advertise opengl 1.4 only as it was before?
                Code:
                $ glxinfo | grep OpenGL
                OpenGL vendor string: Intel Open Source Technology Center
                OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
                OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0 (git-5ba4c2e)
                OpenGL core profile shading language version string: 1.40
                OpenGL core profile context flags: (none)
                OpenGL core profile extensions:
                OpenGL version string: 3.0 Mesa 9.2.0 (git-5ba4c2e)
                OpenGL shading language version string: 1.30
                OpenGL context flags: (none)
                OpenGL extensions:
                $ MESA_GL_VERSION_OVERRIDE=1.4 glxinfo | grep OpenGL
                OpenGL vendor string: Intel Open Source Technology Center
                OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
                OpenGL core profile version string: 1.4 Mesa 9.2.0 (git-5ba4c2e)
                OpenGL core profile extensions:
                OpenGL version string: 1.4 Mesa 9.2.0 (git-5ba4c2e)
                OpenGL extensions:
                $
                http://www.mesa3d.org/envvars.html

                Comment


                • #9
                  Originally posted by callegar View Post
                  I believe that the issue is that now unity thinks that it can rely on some hardware features, that conversely are so painfully slow that make everything hang whenever they are invoked. As a matter of fact, whenever you see unity hanging, if you give enough time to it you will see that it is actually trying to play a fading or a translucency effect.
                  It could just be standard shaders. The hardware only supports very short ones, and the driver will try to fallback to software rendering if it is given one that's too long. The gallium driver will just skip over it instead.

                  Comment


                  • #10
                    Originally posted by mattst88 View Post
                    Gallium isn't some silver bullet. It actually is a bad fit for i915 since Gallium doesn't have any ability to fallback to software on fragment shaders (hence the dummy fragment shaders when something bad happens).
                    That's a good answer. In the context of i915, there's a good solid reason based on the hardware capabilities.

                    But here's what I wonder about:

                    Some day there may come a gallium driver that could very well eclipse Intel's classic offerings on something that would be a good fit for gallium. I mean truely, and in ways that would come with links to pages like the ones you presented here.

                    I have this suspicion that Intel just wouldn't allow it to become the standard. Call it a gut instinct, perhaps its wrong, but there it is.

                    Originally posted by mattst88 View Post
                    As far as eclipsing... I don't know what you're seeing to support that.
                    I was probably too overly aggressive with the use of that word. I meant it only on the surface, because the "g" driver had OGL2.1, while classic only just now gained the feature. You clearly have a greater grasp of this, I'm glad your post was the first in reply.

                    Comment

                    Working...
                    X