Page 1 of 3 123 LastLast
Results 1 to 10 of 27

Thread: OpenGL 4.2 Specification Published With GLSL 4.20

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    14,773

    Default OpenGL 4.2 Specification Published With GLSL 4.20

    Phoronix: OpenGL 4.2 Specification Published With GLSL 4.20

    The good news: Khronos has published version 4.2 of the OpenGL specification in conjunction with the GL Shading Language version 4.20 specification. The bad news? The open-source Linux graphics drivers are falling hopelessly behind in keeping up-to-date with the latest upstream OpenGL releases and what is supported by the proprietary drivers and those for other operating systems...

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

  2. #2
    Join Date
    Jun 2011
    Posts
    316

    Default

    At least OpenGL is moving along now..

    For a while there, it seemed like the OpenGL spec was hopeless too far behind DirectX.. Now the OpenGL spec seems to be rocketing forward while the Open Source drivers are lagging behind, but I don't see that as a serious problem... Game developers can just use the proprietary drivers to develop their games and hopefully by the time the game is done in development and testing, the open source drivers will be available.

  3. #3
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    OMG, this doom and gloom is unbearable.

    Some of the FLOSS drivers have caught up on 10 years of backlog in less than 2 years. Just because they won't catch up next month does not mean that they are falling behind.

    We didn't even have OpenGL 2 just a few years ago.

  4. #4
    Join Date
    Oct 2009
    Location
    .ca
    Posts
    402

    Default

    Quote Originally Posted by pingufunkybeat View Post
    OMG, this doom and gloom is unbearable.
    +1

    10 char

  5. #5
    Join Date
    Oct 2008
    Posts
    3,125

    Default

    This is a weird way to phrase things, considering that the OSS drivers are actually catching up and not falling further behind.

    The open-source Linux graphics drivers are falling hopelessly behind in keeping up-to-date with the latest upstream OpenGL releases and what is supported by the proprietary drivers and those for other operating systems.
    The changes from GL 1.5 -> 3.0 are quite a bit bigger than 3.0 -> 4.2

    As far as ever updating OpenGL to a more modern API. Good luck with that. I don't think it's ever going to happen, all the important players view the backwards compatibility as the most important part of the API. Otherwise they'd just use DirectX.

    Where we might have better luck is with OpenGL ES. People actually care about that API and are using it heavily on the new "hot" market, and backwards compatibility isn't nearly as important in the phone market. Maybe we can get a GL ES 3 that changes the API into a more modern alternative, and then the desktop can follow along and start using that instead of the old GL.

  6. #6
    Join Date
    Feb 2011
    Posts
    62

    Default

    Quote Originally Posted by smitty3268 View Post
    Where we might have better luck is with OpenGL ES. People actually care about that API and are using it heavily on the new "hot" market, and backwards compatibility isn't nearly as important in the phone market. Maybe we can get a GL ES 3 that changes the API into a more modern alternative, and then the desktop can follow along and start using that instead of the old GL.
    OpenGL ES Halti?

  7. #7
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Some of the FLOSS drivers have caught up on 10 years of backlog in less than 2 years. Just because they won't catch up next month does not mean that they are falling behind.
    I have to agree. While it sucks that we still don't have OpenGL 3.2 support on the FOSS drivers, we're a heck of a lot closer to that now than we were. I don't imagine that it'll be too terribly much longer before the FOSS drivers catch up (save for the patent problems, of course), and once that happens it should be relatively easy to stay caught up.

    It'll also give us the solid base necessary to start working on alternative, superior APIs to the one designed 20 years ago for fixed-function networked rendering in the bygone days of SGI graphics mainframes.

    Quote Originally Posted by Sidicas View Post
    At least OpenGL is moving along now..

    For a while there, it seemed like the OpenGL spec was hopeless too far behind DirectX.. Now the OpenGL spec seems to be rocketing forward while the Open Source drivers are lagging behind, but I don't see that as a serious problem... Game developers can just use the proprietary drivers to develop their games and hopefully by the time the game is done in development and testing, the open source drivers will be available.
    It's not moving ahead fast enough, unfortunately. It's still lacking a few core features of D3D 11, for instance, not least of which is sensible application-side multi-threading support. It's still lacking in solid documentation in many areas, lacking in a proper test suite, lacking in an industry-standard fully complete reference software implementation, etc. All of which are thing that Khronos can fix (and in fact, have put money into achieving for OpenGL ES already, which they clearly care far more about than regular OpenGL, likely due to the mobile market not already being dominated by a superior API).

    The GL API still is a pain, too. I cannot stress enough how much bitching I hear about OpenGL from graphics devs in the games industry. It mostly revolves around the drivers still all being crap (which despite what some will say _is_ Khronos' fault, at least partially, as they have not provided anyone a test suite or reference implementation, despite being fully capable of doing so -- its member companies have a collective shitload of money to spend on such things if they actually cared at all about the quality of OpenGL), but a lot of it definitely has to do with the API making many things very, very error-prone or difficult to debug. The object names instead of distinct, opaque object pointer types causes problems. The state-machine setup is difficult to understand, difficult to debug, and doesn't support the workflow that a game (or any high-end rendering engine) really wants want of a hardware API. The errors are usually useless (GL_INVALID... thanks). And extensions are pretty much only ever used to work around OpenGL's limitations compared to Direct3D rather than being used to enable cutting-edge features that D3D lacks (you actually don't hear much complaining about D3D's lack of extensions, because nobody actually needs them to get useful stuff done with that API; mostly it's just the researchers that actually care about extensions for playing around with ideas for the next version of D3D). I really can't stress the state machine problem enough, either: it makes _everything_ more difficult and slower than it needs to be, and unless DSA becomes a core part of GL the API is going to continue to be a pain to use.

    OpenGL is doing a LOT better these days than it was, but it's still not where it could (should?) be if the parties responsible for it actually effort and care into it.

    The community really just needs a new API, backed by a non-profit rather than a corporation (or consortium of corporations). And Gallium3D lets that API come into existence and work with real hardware without needing to get the big hardware vendors on board first, which is an awesome opportunity that needs to be made use of. Soon.

  8. #8
    Join Date
    Sep 2010
    Posts
    465

    Default

    Still no Direct State Access.
    C'mon Khronos, add it!

  9. #9
    Join Date
    Jan 2009
    Posts
    1,676

    Default

    Quote Originally Posted by elanthis View Post
    The community really just needs a new API, backed by a non-profit rather than a corporation (or consortium of corporations). And Gallium3D lets that API come into existence and work with real hardware without needing to get the big hardware vendors on board first, which is an awesome opportunity that needs to be made use of. Soon.
    didn't you said in the past that you were planning, designing or thinking of creating a new API or something??

  10. #10
    Join Date
    Jun 2010
    Posts
    150

    Default

    Again, nVidia provides drivers at launch and also adds the features which are possible for older hardware, such as ARB_conservative_depth which would allow more performance optimization.

    I haven't reviewed the new specification yet. But several of the new features would allow more tweaking and performance, and compression in memory which is a limitation for graphics cards.

    It still lacks one feature I need though, an effective way to upload data and preferly geometry without traditional GL-calls. I would love if I could just exchange some of the vertex data and just use one glDraw-call to render it all, and program the pipeline fetch data itself and choose which fragments to process. It's rumored that Kepler will feature the ability to access system memory directly from the GPU, and this might be used to achieve what I want.

    And of course the open source drivers are still lagging behind, and does not yet offer support for modern OpenGL specifications. Some argue that many of the components of OpenGL 3.0 is there, but the most important one, shading, is still not complete.

    Quote Originally Posted by elanthis View Post
    It's not moving ahead fast enough, unfortunately. It's still lacking a few core features of D3D 11, for instance, not least of which is sensible application-side multi-threading support. It's still lacking in solid documentation in many areas, lacking in a proper test suite, lacking in an industry-standard fully complete reference software implementation, etc. All of which are thing that Khronos can fix (and in fact, have put money into achieving for OpenGL ES already, which they clearly care far more about than regular OpenGL, likely due to the mobile market not already being dominated by a superior API).
    What kind of multithreading do you want?
    OpenGL supports multiple rendering contexts and shared contexts, handling is up to the driver and window system. But still, as far as I can see, no one of the popular toolkits supports this, such as GLUT, SDL, glfw etc.

    But you'll have to remember that the driver will still just do one task at a time, you you'll only achieve a queue of tasks.

    Documentation is not a large issue. Samples could be much better however, almost all samples are outdated and irrelevant today. Khronos should provide samples exposing all features. I hope nVidia's new SDK will be ready soon. But still, I think the lack of a decent official OpenGL library/toolkit is a larger problem. I've had to make my own to satisfy my own needs.

    OpenGL actually has support for debugging messages.

Tags for this Thread

Posting Permissions

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