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

Thread: OpenGL 4.3 Support Is A Ways Out In Mesa

  1. #1
    Join Date
    Jan 2007
    Posts
    13,456

    Default OpenGL 4.3 Support Is A Ways Out In Mesa

    Phoronix: OpenGL 4.3 Support Is A Ways Out In Mesa

    While the OpenGL 4.3 specification was just released (along with OpenGL ES 3.0), there's already a beta NVIDIA Linux proprietary driver supporting this latest desktop graphics API from Khronos. AMD will also soon be released a Catalyst beta with the GL 4.3 / GLSL 4.30 support. However, the open-source Mesa support will still be a ways out...

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

  2. #2
    Join Date
    Jan 2010
    Posts
    335

    Default

    It would be great to see more focus in Mesa development. Many of the features required for GL 3.2/3.3 and even some required for 4.x are already done, but support for 3.1 still isn't fully done yet! It would make more sense to focus on completing 3.1, and after that 3.2, and so on.

  3. #3
    Join Date
    Jun 2010
    Posts
    211

    Default

    With Gallium and all, shouldn't this process go faster this time around because devs can focus more on optimizations and features than simple enablement?

  4. #4
    Join Date
    Oct 2007
    Posts
    91

    Default

    Quote Originally Posted by brent View Post
    It would be great to see more focus in Mesa development. Many of the features required for GL 3.2/3.3 and even some required for 4.x are already done, but support for 3.1 still isn't fully done yet! It would make more sense to focus on completing 3.1, and after that 3.2, and so on.
    To my knowledge, the only major hurdle to getting OpenGL 3.1 support out the door is ARB_uniform_buffer_object, which although listed as 'not started' is nearing completion on Intel hardware thanks to Eric Anholt. GL 3.2 and 3.3 should also fall into place rather quickly given the fact that most of the extensions are already done.

    I would have to argue that it doesn't make much sense to focus only on the 3.1 features, then 3.2, etc. Picking the low hanging fruits and scratching itches first seems like the way to move forward most rapidly.

  5. #5
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    124

    Default

    Quote Originally Posted by phoronix
    The GL_ARB_debug_output support in Mesa originated with a request from Valve for Mesa supporting this OpenGL extension
    Actually, Mesa's support for GL_ARB_debug_output was written by Dylan Noblesmith (nobled), a community contributor, with some finishing touches from Marek. While at Valve, Eric made our driver output some performance data via ARB_debug_output, but this was really just leveraging the work nobled had done...the extension already existed.

  6. #6
    Join Date
    May 2012
    Posts
    66

    Default

    I hope this doesn't sound like a very stupid question, but what is the reason that Mesa is lagging behind in terms of OpenGL support? Is it because of a lack of developers or funding? Or lack of documentation and avaliable specifications for the things they're working with? Or is it perhaps due to patent issues?

    I was just wondering... I don't mean to imply that Mesa aren't doing a good job.. In fact, they're doing a pretty good job if you ask me

  7. #7
    Join Date
    Oct 2008
    Posts
    2,912

    Default

    Quote Originally Posted by 9a3eedi View Post
    what is the reason that Mesa is lagging behind in terms of OpenGL support? Is it because of
    a lack of developers
    Yes.

    funding?
    Yes.

    Or lack of documentation and avaliable specifications for the things they're working with?
    No.

    Or is it perhaps due to patent issues?
    No, except for floating-point textures, required for 3.0+, which are present in Mesa but not compiled by default unless you configure it to ignore those patents.

  8. #8
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    124

    Default

    Quote Originally Posted by 9a3eedi View Post
    I hope this doesn't sound like a very stupid question, but what is the reason that Mesa is lagging behind in terms of OpenGL support? Is it because of a lack of developers or funding? Or lack of documentation and avaliable specifications for the things they're working with? Or is it perhaps due to patent issues?

    I was just wondering... I don't mean to imply that Mesa aren't doing a good job.. In fact, they're doing a pretty good job if you ask me
    Thank you :) I'd say it was a lack of developers, and now it's just that we have a lot of ground to catch up.

    When I started working on Mesa two years ago, the Intel 3D "team" was basically Eric and Ian. Plus, Eric was also maintaining the kernel tree at the time, so his attention was divided. (There were a few others, but mostly those two; Kristian had also been working on GL, but was beginning to transition to Wayland as his primary focus.) When it comes down to it, there's really only so much you can do with two guys...especially when you break that down into: 1) adding support for new GL extensions and versions, 2) new hardware bring-up, 3) bug fixing, 4) performance enhancements, 5) writing a shader compiler, 6) developing an open source OpenGL conformance suite (piglit), 7) customer support and random firefighting, and more. Even with amazing developers, it's just too much.

    Fast forward to today, and things look a lot different. There are ~eight of us in Portland who meet up regularly, all working full time on OpenGL. In the extended team, there are several people dedicated to working on the kernel, one working on developer tools, a number of people working on Android and EGL related stuff, and more. With the extra help, we're finally beginning to catch up and close the gap. The pace at which things are getting done has definitely increased substantially. Plus, we still have solid help from the rest of the community. Brian remains a constant aid to us, especially as we evolve core Mesa, and we're really grateful. Jose's work on apitrace is invaluable. I could go on and on.

    Access to the GL specs is not an issue...the specs for everything we're working on are publicly available at either opengl.org or khronos.org. Ian's also fairly involved with the OpenGL ARB (architecture review board), so he stays on top of the latest specs. Hardware documentation varies. The Intel developers are in good shape there. I think things are decent for AMD hardware as well, though I'd have to defer to one of the Radeon developers. As far as I know, Nouveau continues to be completely reverse engineered, which has to be extremely hard.

  9. #9
    Join Date
    Apr 2008
    Posts
    65

    Default

    So in this "extension matrix", the extensions marked as "DONE (x,y)" are working only on X and Y? And stuff marked as "DONE" works on all platforms?
    Cheers.

  10. #10
    Join Date
    Nov 2008
    Posts
    77

    Default

    Quote Originally Posted by PeterKraus View Post
    So in this "extension matrix", the extensions marked as "DONE (x,y)" are working only on X and Y? And stuff marked as "DONE" works on all platforms?
    In theory yes, but in practice, DONE sometimes mean DONE (swrast). And DONE (x) sometimes mean "work on some hw using x" (usually a hw generation, rarely a single hw model). And it is not always kept up-to-date, so DONE(x,y) does not always preclude it from working on z too. Additionally, DONE (swrast) means it work on at least one of softpipe and llvmpipe, not always both...

Posting Permissions

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