Downsides of OpenGL [Blogpost]

[Jodell88]

Rich Geldreich is a Valve employee that has worked on all of Valve's OpenGL efforts so far. He went on a bit of a rant today, but what he has written I pretty much agree with even though I am a fan of OpenGL more than I am DirectX.

What drives him nuts about OpenGL
http://richg42.blogspot.com/2014/05/things-that-drive-me-nuts-about-opengl.html

I think OpenGL's compatibility is a double edged sword. It's both nice to have and it's Achilles Heel. It will be interesting to see how the Khronos group will sort this out.

The truth about OpenGL driver quality.
http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driver-quality.html

Boy, is that a mess.

If anyone is wondering what the Vendors are.

Vendor A = Nvidia
Vendor B = AMD
Vendor C Driver #1 = Intel Linux Driver
Vendor C Driver #2 = Intel Windows Driver

Nvidia's and AMD's OpenGL driver are the same on at Windows/Linux, it could be the same one they use on Mac OSX as well.

 

[sandorski]

Hardly sounds worth using.

 

[monstercameron]

cross platform mantle or the underlying theory behind mantle seems to be a necessity.

Why have the driver team work constantly to make games work and have the game devs work constantly work to maintain compatibility[or vice versa] when they could have a static entity for the game devs to build against.

Empower the devs and make life easier!

 

[postmortemIA]

My guess that vendor c drivers #1 AND #2 is linux, not one windows... see the paragraphs how intel can afford to have two linux driver teams

this is not surprising at all. Anybody who worked with AMD graphics knows they are F***up in both hardware and software

 

[Jodell88]

My guess that vendor c drivers #1 AND #2 is linux, not one windows

No, Intel has two driver teams. The Linux driver and other Open Source efforts come out of Intel's Open Source Technology Center. The Windows DirectX and OpenGL driver is done somewhere else. Both are separate from each other and do not overlap.

 

[dn7309]

what was the last major game that used open GL?

 

[Jodell88]

Hardly sounds worth using.

I don't believe that at all OpenGL is used at some point in most content creation suites, from games to movies. Maya et al. do not use DirectX, and if they did they would end up with an inferior product since DirectX does not have the precision of OpenGL.

They also wouldn't be cross platform.

 

[blackened23]

What he says about NV's driver for OGL (far from perfect apparently):

What most devs use because this vendor has the most capable GL devs in the industry and the best testing process. It's the "standard" driver, it's pretty fast, and when given the choice this vendor's driver devs choose sanity (to make things work) vs. absolute GL spec purity. Devs playing at home use this driver because it has the sexiest, most fun to play with extensions and GL support. Most of what you hear about the amazing things GL will be able to do in order to compete against D3D12/Mantle are by devs playing with this driver. Unfortunately, we can't just target this driver or we miss out on large amounts of market share.

Even so, until Source1 was ported to Linux and Valve devs totally held the hand's of this driver's devs they couldn't even update a buffer (via a Map or BufferSubData) the D3D9/11-style way without it constantly stalling the pipeline. We're talking "driver perf 101" stuff here, so it's not without its historical faults. Also, when you hit a bug in this driver it tends to just fall flat on its face and either crash the GPU or (on Windows) TDR your system. Still, it's a very reliable/solid driver.

Vendor A supports a zillion extensions (some of them quite state of the art) that more or less work, but as soon as you start to use some of the most important ones you're off the driver's safe path and in a no man's land of crashing systems or TDR'ing at the slightest hickup.

This vendor's tools historically completely suck, or only work for some period of time and then stop working, or only work if you beg the tools team for direct assistance. They have enormous, perhaps Dilbert-esque tools teams that do who knows what. Of course, these tools only work (when they do work) on their driver.

This vendor is extremely savvy and strategic about embedding its devs directly into key game teams to make things happen. This is a double edged sword, because these devs will refuse to debug issues on other vendor's drivers, and they view GL only through the lens of how it's implemented by their driver. These embedded devs will purposely do things that they know are performant on their driver, with no idea how these things impact other drivers.

What he says about AMD's GL driver team: (even more far from perfect):

A complete hodgepodge, inconsistent performance, very buggy, inconsistent regression testing, dysfunctional driver threading that is completely outside of the dev's official control. Unfortunately this vendor's GPU is pretty much standard and is quite capable hardware wise, so you can't ignore these guys even though as an organization they are idiots with software. Basic stuff like glTexStorage() crashes (on a shipped title) for months on end with this driver. B's driver devs try to follow the spec more closely than Vendor A, but in the end this tends to do them no good because most devs just use Vendor A's driver for development and when things don't work on Vendor B they blame the vendor, not the state of GL itself.

Vendor B driver's key extensions just don't work. They are play or paper extensions, put in there to pad resumes and show progress to managers. Major GL developers never use these extensions because they don't work. But they sound good on paper and show progress. Vendor B's extensions are a perfect demonstration of why GL extensions suck in practice.

This vendor can't get key stuff like queries or syncs to work reliably. So any extension that relies on syncs for CPU/GPU synchronization aren't workable. The driver devs remaining at this vendor pine to work at Vendor A.

Vendor B can't update its driver without breaking something. They will send you updates or hotfixes that fix one thing but break two other things. If you single step into one of this driver's entrypoints you'll notice layers upon layers of cruft tacked on over the years by devs who are no longer at the company. Nobody remaining at vendor B understands these barnacle-like software layers enough to safely change them.

So nvidia are the graphics mafia with their driver teams caring about their driver and their driver alone, and AMD are the incompetent idiots that can't program a GL driver to save their lives. Although neither side is great on the grand scale. According to this guy at Valve. Sounds about right. NV software: heavy handed mafia tactics, AMD software : hopeless idiots that aspire to work at nvidia instead. Well according to this guy. Is this blog verified to be his? Sounds like GL drivers across the board aren't very ideal. The AMD comments sound about right, though, although they seem to have improving a little as of late. In DX at least . Not as much as they should, mind you. Better than they were 2 years ago I guess.

His summation of the GL Driver situation overall:

To ship a major GL title you'll need to test your code on each driver and work around all the problems. May the "GL Gods" help you if you experience random GPU corruption, heap corruption, lockups, or TDR's. Be very nice to the driver teams and their managers/execs, because without them your chances aren't nearly as good.

 

[Gloomy]

Really puts the state of OGL into perspective... If Nvidia has a good driver, but strays from the spec, and AMD has a bad driver but follows the spec to the letter, while Intel has two completely different drivers. And nobody has dev tools. What is even the point?

This sounds like a hot mess <_<;;

@Blackened this has nothing to do with DirectX, AMD's driver is fine there. This isn't unexpected, the volume of games running on DX acts as a built-in regression test. OpenGL is completely different. Aside from professional applications, nothing uses it. So bugs have just piled up undisturbed for a while, until someone trips into them. My guess is Nvidia's developer following have contributed a lot to the state of their driver (while AMD's lack of developers doesn't help them one whit)

Here's Timothy Lottes' reply:

http://timothylottes.blogspot.co.uk/2014/05/re-things-that-drive-me-nuts-about.html

I like this idea a lot:

"glGet() API deficiencies ... glGetError() ... Can't query key things such as texture targets" --- IMO GL should be split into two APIs, the low-level driver API (simple to the metal) and an open-source high-level API which provides optional features for debug, safety and state shadowing, etc. This reduces the amount of work all vendors need to do and amortizes cost across anyone who is able to contribute a patch to the high-level API source.

 

[Jodell88]

Is this blog verified to be his?

It is https://twitter.com/richgel999

 

[blackened23]

What is even the point?

This sounds like a hot mess <_<;;

Well I don't disagree there. Sounds obvious why games aren't really using GL, although many professional apps use OGL. (for cross platform use, as Jodel mentioned). Sounds like developing using OGL for gaming is a headache at best.

 

[blackened23]

Another assessment of OGL driver quality, this one includes comments about ARM and Qualcomm:

(from the creators of the dolphin emulator)

https://dolphin-emu.org**************26/dolphin-emulator-and-opengl-drivers-hall-fameshame/

........I guess that's why OGL isn't getting much use for gaming. Although for mobile, i'm not sure.

 

[Jodell88]

*post*

Reading the blogpost from Timothy reminded me of something I heard from either an AMD or Nvidia dev. Most game engines use OpenGL 2 or at the very best case 3.x. Perhaps moving to a more up to date version of OpenGL can improve things by a reasonable factor. :hmm:

 

[DiogoDX]

Really puts the state of OGL into perspective... If Nvidia has a good driver, but strays from the spec, and AMD has a bad driver but follows the spec to the letter, while Intel has two completely different drivers. And nobody has dev tools. What is even the point?

This sounds like a hot mess <_<;;

@Blackened this has nothing to do with DirectX, AMD's driver is fine there. This isn't unexpected, the volume of games running on DX acts as a built-in regression test. OpenGL is completely different. Aside from professional applications, nothing uses it. So bugs have just piled up undisturbed for a while, until someone trips into them. My guess is Nvidia's developer following have contributed a lot to the state of their driver (while AMD's lack of developers doesn't help them one whit)

Here's Timothy Lottes' reply:

http://timothylottes.blogspot.co.uk/2014/05/re-things-that-drive-me-nuts-about.html

I like this idea a lot:

Seems like ironicaly AMD have some tools.

Interestingly, Vendor B has a tiny tools team that actually makes some pretty useful debugging tools that actually work much of the time - as long as you are using vendor B's GPU. Without Vendor B's tools togl and Source1 Linux would have taken much longer to ship.

For the text I think the only hope for AMD is improve they open source driver asap and let the OGL community improve the things.

 

[sandorski]

Really puts the state of OGL into perspective... If Nvidia has a good driver, but strays from the spec, and AMD has a bad driver but follows the spec to the letter, while Intel has two completely different drivers. And nobody has dev tools. What is even the point?

This sounds like a hot mess <_<;;

@Blackened this has nothing to do with DirectX, AMD's driver is fine there. This isn't unexpected, the volume of games running on DX acts as a built-in regression test. OpenGL is completely different. Aside from professional applications, nothing uses it. So bugs have just piled up undisturbed for a while, until someone trips into them. My guess is Nvidia's developer following have contributed a lot to the state of their driver (while AMD's lack of developers doesn't help them one whit)

Here's Timothy Lottes' reply:

http://timothylottes.blogspot.co.uk/2014/05/re-things-that-drive-me-nuts-about.html

I like this idea a lot:

I didn't get the impression that he thinks the Nvidia Driver is Good. Just that it's the best of the bunch.

 

[sandorski]

Seems like ironicaly AMD have some tools.



For the text I think the only hope for AMD is improve they open source driver asap and let the OGL community improve the things.

Given the state of OGL, making Mantle into a complete Multiplatform replacement might be a better alternative.

 

[Headfoot]

Given the state of OGL, making Mantle into a complete Multiplatform replacement might be a better alternative.

I am very hopeful for this. A new API based on the hardware/OS realities of today without 20 years of built up backwards compatibility muck. Every once and a while a full rewrite is easier than trying to refactor such a gnarly pile of spaghetti

 

[Jodell88]

Given the state of OGL, making Mantle into a complete Multiplatform replacement might be a better alternative.

Not happening. AMD does not have the resources both financially and in human resources to do it.

 

[Jodell88]

For the text I think the only hope for AMD is improve they open source driver asap and let the OGL community improve the things.

The Open Source AMD driver isn't as buggy as the Catalyst driver. However, the catalyst driver when it works performs better, but that is changing quickly.

 

[postmortemIA]

The Open Source AMD driver isn't as buggy as the Catalyst driver. However, the catalyst driver when it works performs better, but that is changing quickly.

that has been story for the last 5 yrs. And every time AMD releases new chip, they go back to the drawing board.

 

[Jodell88]

that has been story for the last 5 yrs. And every time AMD releases new chip, they go back to the drawing board.

That's because they don't give the Open Source devs the documentation for the hardware until the hardware has been released. :|

Meanwhile, over at Intel, support for their next gen platforms are in place or is currently being put in place so that when the hardware is released you have support on day one.

That said, AMD has talked about plans that the Linux kernel graphics stack would be shared between Catalyst and the Open Source driver at some point in the future. The user land will remain separate.

This may raise the quality of the Catalyst driver a bit and give the open source driver better hardware support quicker.

 

[BrightCandle]

This isn't uncommon in programming though. Every android phone has its own list of bugs you have to workaround, the platform itself is really buggy especially for backwards compatibility. Working around bugs in the software stack is a common programmer activity, no software is perfect yet.

 

[Fox5]

Really puts the state of OGL into perspective... If Nvidia has a good driver, but strays from the spec, and AMD has a bad driver but follows the spec to the letter, while Intel has two completely different drivers. And nobody has dev tools. What is even the point?

This sounds like a hot mess <_<;;

@Blackened this has nothing to do with DirectX, AMD's driver is fine there. This isn't unexpected, the volume of games running on DX acts as a built-in regression test. OpenGL is completely different. Aside from professional applications, nothing uses it. So bugs have just piled up undisturbed for a while, until someone trips into them. My guess is Nvidia's developer following have contributed a lot to the state of their driver (while AMD's lack of developers doesn't help them one whit)

Here's Timothy Lottes' reply:

http://timothylottes.blogspot.co.uk/2014/05/re-things-that-drive-me-nuts-about.html

I like this idea a lot:

AMD and Nvidia both support OpenGL4.4, and AMD created some of the extensions that eventually became Nvidia's 0 driver overhead OpenGL.

This seems kind of blown out of proportion though. I don't know of a single OpenGL game or emulator that won't run on both AMD and Nvidia.
Intel basically locks their driver updates to the hardware, so you only get like 1 to 2 years of updates for their gpus.

 

[Arkadrel]

Really puts the state of OGL into perspective... If Nvidia has a good driver, but strays from the spec, and AMD has a bad driver but follows the spec to the letter, while Intel has two completely different drivers. And nobody has dev tools. What is even the point?

This sounds like a hot mess <_<;;

Yep This is why we need cross OS mantle.

 

[Arkanius]

What we need is OpenGL to stop being such a mess. Valve is parte of Khronus, I wonder if they will try to save it, similar to what they are trying to do with Linux.