Phoronix News Bot
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
Senior Member
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.
Senior Member
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.
Senior Member
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.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.
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.
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).Originally Posted by Sidicas
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.
Senior Member
Still no Direct State Access.
C'mon Khronos, add it!
Senior Member
didn't you said in the past that you were planning, designing or thinking of creating a new API or something??
Phoronix Member
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.
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.
Senior Member
+1
10 char
Senior Member
This is a weird way to phrase things, considering that the OSS drivers are actually catching up and not falling further behind.
The changes from GL 1.5 -> 3.0 are quite a bit bigger than 3.0 -> 4.2The 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.
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.
Senior Member
This is such a great idea. We should be able to use the low-level hardware access provided by Gallium3d to build a reference implementation of this nebulous new API as a G3D state tracker! Ideally the state tracker should be written with as little hardware-specific binding as possible, and version 1.0 should have the ability to reliably report on hardware capabilities, software emulated capabilities, and completely unsupported capabilities, with a well-defined interface that doesn't involve any guesswork or string parsing, and uses an easy-to-understand object model with predictable semantics, common computing terminology used as much as possible (avoiding graphics domain-specific technical terms unless they are completely unavoidable), and with a design goal of minimizing the amount of work that would be required of an engine author. Almost to the point that actually "writing" a 3d engine on top of this API would be a mimicry of the API itself. Basically, you'd get a low-level 3d engine as a Gallium3d state tracker, but still with enough flexibility to do crazy things like portal effects and non-3d geometries.
The gallium3d infrastructure may not be the end-all of APIs, but it is the best hardware-independent 3d graphics API we have in the free world right now. And it's only on version 0.4; I am sure it will improve. But what's the use of improving it if the end-user API on top of it is the culprit of most of the semantic mismatch you see?
Reply With Quote
