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

  • callegar
    replied
    Having a piece of hardware for which both gallium and classic drivers exist is good

    Having a piece of hardware for which both gallium and classic drivers exist is good since it makes comparisons possible.

    IMHO comparing i915/965 classic and gallium is much more interesting than comparing gallium and catalyst or noveau and nvidia blobs, since this is the only case where the two drivers under comparison are both open source and controllable.

    This can indeed reveal if there are intrinsic issues with the gallium architecture wrt speed as the Intel developers at times seem to suggest or if there are bottlenecks that can be removed.

    Leave a comment:


  • callegar
    replied
    Thanks !!!

    Originally posted by ChrisXY View Post
    Thanks, this saved the day!

    Setting MESA_GL_VERSION_OVERRIDE to 1.4 in /etc/environment has made my eeepc usable again.

    Now, I wonder... Is providing opengl 2.1 on gen3 based on CPU rendering? I guess so since CPU use is sky rocketing.
    Is it sensible to do so by default, given that gen3 hardware cannot be expected to have strong CPUs?
    How can destktop managers find out whether something that is advertised is in fact usable or just unbearably slow?

    Leave a comment:


  • Pallidus
    replied
    benchmarks have shown, time and time again, that the classic intel driver is BETTER than gallium.

    every 2d benchmark, even most 3d say the same


    why switch to something that is slower instead of asking intel to provide more support?

    Leave a comment:


  • halfmanhalfamazing
    replied
    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.

    Leave a comment:


  • smitty3268
    replied
    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.

    Leave a comment:


  • ChrisXY
    replied
    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:
    $

    Leave a comment:


  • callegar
    replied
    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?

    Leave a comment:


  • [Knuckles]
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • mattst88
    replied
    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.

    Leave a comment:

Working...
X