Another blog post from the Valve developer Rich Geldreich who works on the Vogl OpenGL debugger. This time Rich lends his experienced thoughts to the state of OpenGL in vendors drivers.
I doubt anyone will be surprised at what he has to say about the drivers. He doesn't mention them by name as to not be unfair to them, but I imagine even they know who they are it's so obvious.
A blog post like this I imagine would be pretty scary for anyone looking to get into OpenGL when it starts with things like this:
I hope the graphics card vendors are reading and taking notes, it's time for all of you to step up your OpenGL game. You all have issues and for Linux + OpenGL to be taken more seriously we need them all to get their heads together and work harder for us.
Personally I have found Nvidia's closed-source drivers to be pretty good (if you use a recent driver version), while their open-source driver not so good at much at all. I hear from a lot of you that AMD's open-source drivers are getting pretty good nowadays too, so that's good. I've never really had much of a problem with Intel's drivers luckily too.
The thing is you get some of the same issues with the vendors DirectX Windows drivers too, my partners computer for example has gone to a BSOD (blue screen of death) multiple times due to a graphics driver crash. OpenGL is not alone in hard-crashes and I do wish people wouldn't make sound like it's only OpenGL that does it.
What has your experience been?
See the full blog post here. Article taken from GamingOnLinux.com.
I doubt anyone will be surprised at what he has to say about the drivers. He doesn't mention them by name as to not be unfair to them, but I imagine even they know who they are it's so obvious.
A blog post like this I imagine would be pretty scary for anyone looking to get into OpenGL when it starts with things like this:
QuoteIf all you've ever done is use D3D then you better strap yourself in because the available GL drivers for Windows/Linux are all over the map.
I hope the graphics card vendors are reading and taking notes, it's time for all of you to step up your OpenGL game. You all have issues and for Linux + OpenGL to be taken more seriously we need them all to get their heads together and work harder for us.
Personally I have found Nvidia's closed-source drivers to be pretty good (if you use a recent driver version), while their open-source driver not so good at much at all. I hear from a lot of you that AMD's open-source drivers are getting pretty good nowadays too, so that's good. I've never really had much of a problem with Intel's drivers luckily too.
The thing is you get some of the same issues with the vendors DirectX Windows drivers too, my partners computer for example has gone to a BSOD (blue screen of death) multiple times due to a graphics driver crash. OpenGL is not alone in hard-crashes and I do wish people wouldn't make sound like it's only OpenGL that does it.
What has your experience been?
See the full blog post here. Article taken from GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
7 comments
To put it into perspective. Vendor A is nVidia, B is AMD, C is Intel with #1 being their Linux stack and #2 their windows one.
And now some truths. Excluding nVidia all the rest of the OpenGL desktop drivers out there are having questionable quality and there is a reason for that. OpenGL is huge, complex and all the extensions (start counting from 20year ago) interact in a very weird way with each other. That is a source for many bugs and redundancy.
Khronos group at some point created a cut down version of GL with core profiles. Valve, despite the love I have for them, in some presentations they recommended using compatibility profiles. That makes me angry because in a way they undermine all the effort Khronos had put into driving everyone to the core profiles.
I totally get AMD, writing OpenGL drivers with all this ***load of extensions is unimaginable tough (I know because I write OpenGL drivers myself). Trying to test all this combinations and interactions is an insanely huge vector of possibilities.
The solution IMHO? A new and slick and modern API.
And now some truths. Excluding nVidia all the rest of the OpenGL desktop drivers out there are having questionable quality and there is a reason for that. OpenGL is huge, complex and all the extensions (start counting from 20year ago) interact in a very weird way with each other. That is a source for many bugs and redundancy.
Khronos group at some point created a cut down version of GL with core profiles. Valve, despite the love I have for them, in some presentations they recommended using compatibility profiles. That makes me angry because in a way they undermine all the effort Khronos had put into driving everyone to the core profiles.
I totally get AMD, writing OpenGL drivers with all this ***load of extensions is unimaginable tough (I know because I write OpenGL drivers myself). Trying to test all this combinations and interactions is an insanely huge vector of possibilities.
The solution IMHO? A new and slick and modern API.
0 Likes
It would be really nice to get a new and slick modern API that kicks OpenGL and DX's ass, but the chances of that happening I would think are somewhere around 0%. GL and Directx have been around for what 20-ish years? and they're still broken, they're still under active development.
Making an API is clearly a huge undertaking not just anyone could jump at. Valve has the funding for it, it does not however have the time (as in they need the solution to be fast because of SteamOS and Steam Machines)
Making an API is clearly a huge undertaking not just anyone could jump at. Valve has the funding for it, it does not however have the time (as in they need the solution to be fast because of SteamOS and Steam Machines)
0 Likes
QuotePersonally I have found Nvidia's closed-source drivers to be pretty good (if you use a recent driver version), while their open-source driver not so good at much at all.I know this is nit-picking but I would like to just clarify that Nvidia does not make open-source drivers. The folks over at freedesktop.org have been managing the Nouveau project and only recently Nvidia has begun contributing some code to the project.
0 Likes
I found this website about OpenGL and support of various drivers. FOSS drivers are not tested besides Intel ones but there is an interesting article for candidate features for OpenGL 5:
http://www.g-truc.net/post-0652.html#menu
http://www.g-truc.net/post-0652.html#menu
0 Likes
Erf... hope Khronos will eat the bullet: 99% of GL api is useless for modern GPUs, really.
opengl5 should be a reboot. A *bloody* real one and not the joke of gl4.
You can see than something is wrong somewhere when you know it's easier to program GPU bare metal than GL itself...
I do have a "vendor B" personal driver I'm working on, GL implementation complexity is *disgusting* compared to bare-metal programming simplicity.
The open source devs of vendor B are easily available and 99% of the time, they are really nice. Some hw specs are still not published.
opengl5 should be a reboot. A *bloody* real one and not the joke of gl4.
You can see than something is wrong somewhere when you know it's easier to program GPU bare metal than GL itself...
I do have a "vendor B" personal driver I'm working on, GL implementation complexity is *disgusting* compared to bare-metal programming simplicity.
The open source devs of vendor B are easily available and 99% of the time, they are really nice. Some hw specs are still not published.
0 Likes
Quoting: sylwareErf... hope Khronos will eat the bullet: 99% of GL api is useless for modern GPUs, really.
opengl5 should be a reboot. A *bloody* real one and not the joke of gl4.
You can see than something is wrong somewhere when you know it's easier to program GPU bare metal than GL itself...
I do have a "vendor B" personal driver I'm working on, GL implementation complexity is *disgusting* compared to bare-metal programming simplicity.
The open source devs of vendor B are easily available and 99% of the time, they are really nice. Some hw specs are still not published.
I agree that we need to stop adding more crap to GL and reboot it. But I don't agree that a bare metal API is going to be easier. For example a low level API should require explicit dependency handling. So you have to have events ALA OpenCL, something that is more difficult than the existing implicit handling.
And IMHO what is wrong with Khronos is that Vendor A doesn't seem to like change. They have a pretty good software stack and that gives them a competitive advantage over the other vendors. The other vendors are struggling to implement the full spec and/or fighting with bugs.
0 Likes
Patreon
PayPal
See more from me