The Truth on OpenGL Driver Quality

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

by jcastro • 12 years ago

165 109 12 years ago

richg42.blogspot.com

ZenoArrow2• 12 years ago

So... Vendor A - NVidia, Vendor B - AMD, Vendor C - Intel. What are the two Intel drivers?

Spidler• 12 years ago

Windows and Linux drivers.

zdw• 12 years ago

I'd assume:

    Vendor C #1 = Intel on Linux
    Vendor C #2 = Intel on Windows

Given the "open source wiz kids to keep driver #1 plodding forward" and "GL on this platform is totally a second class citizen" comments in each description.

bhousel• 12 years ago

I had to smile at this. I've been out of the graphics programming space for the last 15 years and it seems like not much has changed.

kelnos2• 12 years ago

Sheesh, has it really been the same for that long? I dropped out (only) about 5 years ago and had a similar thought. I enjoyed how the author didn't name names but made it pretty obvious to anyone who's dealt with this stuff before, even tangentially.

vernie• 12 years ago

The write-up by the Dolphin team is also worth reading: https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and...

clarry3• 12 years ago

It's not just affecting 3D applications that need OpenGL though. I find it sad that we have no modern standard akin to VESA / VBE -- to get any reasonable graphics at all at your native display resolution, you have to live with an incredibly complicated (and unreliable) graphics stack. Purely CPU based rendering (which was fast enough in the 90s) is no longer a choice really.

rasz_pl2• 12 years ago

SDL

euank2• 12 years ago

To expound on this comment: SDL1 defaults to fully software rendered output. You can hack in opengl hardware rendering, but it's fairly common for SDL1 games and such to be fully software rendered and run fine.

SDL2 in general is hardware rendered.

SDL1 is a good counter-example to "software rendering isn't quick enough anymore". You can make perfectly performant 2d games with sdl1's software rendering... 3d, not so much.

clarry3• 12 years ago

I am talking about the layers below SDL. The layers that give rise to questions like will the graphics card be supported on my favorite OS if I buy this new computer?. These layers are responsible for detecting and configuring your adapters & monitors, setting the resolution, colour depth, interrupts for vsync, dma for fast frame copying, etc. If these things do not work right, you are in for a sad sad desktop experience, even if your CPU were fast enough to do all the 3D magic you want.

Hilariously, using software SDL for your framebuffer (at least on X.org) will be much slower than using OpenGL PBOs. Don't talk about hardware acceleration here -- all we're doing is transferring a finished frame to the display. At this point, we already need much more than the "small" amount of code to implement KMS. Can it break? Yes it can. Does it break? Yes it does. Graphics driver issues are still among the most common problems I witness people struggle with, as far as getting their OS to run smoothly goes.

datenwolf3• 12 years ago

to get any reasonable graphics at all at your native display resolution, you have to live with an incredibly complicated (and unreliable) graphics stack.

Actually no. OpenGL in no way deals with setting up the display or creating a window on the screen. That has always been the responsibility of the underlying graphics infrastructure (KMS, X11, GDI, etc.)

Purely CPU based rendering (which was fast enough in the 90s) is no longer a choice really.

In fact on Linux you can use KMS and the fbdev without making use of OpenGL. Heck, mplayer and ffmpeg even support do operate on the fbdev without going through a windowing system – just naked writes to the graphics framebuffer.

I find it sad that we have no modern standard akin to VESA / VBE

Actually there is such a standard, it's called EGL. However EGL by itself is graphics stack agnostic and has been designed to be usable on a wide range of plattforms and graphics infrastructures. So you still have to use some kind of operating system dependent API to open the display device, but then you can use that display device handle with EGL to create abstract surfaces that OpenGL, OpenVG and other API can use to draw on.

wtallis• 12 years ago

EGL is completely different from VBE. VBE was a hardware interface that got you modesetting, a framebuffer, and vsync for any hardware with a single driver that was always there as a fallback. EGL's just an API for applications to talk to the drivers the same way regardless of the window system, but you still need the multitude of drivers. The modern analogue to VBE would be one of the EFI graphics standards, if there weren't two of the damn things, and if anybody would bother properly implementing EFI.

AshleysBrain2• 12 years ago

In my experience of writing a GL Windows desktop app alone, driver bugs have been the #1 cause of stability problems for real end users. It's a complete nightmare, with pretty much every manufacturer. I guess that's what happens when hardware companies need to write software.

kevingadd4• 12 years ago

Have you considered shipping a D3D rendering backend for your Windows clients? Or is it too much duplication?

AshleysBrain2• 12 years ago

No time for a startup, and we had previously used D3D and had other annoying problems (horrible text rendering, annoying redist issues, etc), so it just had its own set of problems.

Vektorweg• 12 years ago

I think the greatest problem is still OpenGL itself. Vendors have a hard time implementing these and other Khronos specs.

overgard4• 12 years ago

I don't know why you were downvoted for this. OpenGL spec is a mess. I think a lot of the driver issues arise from the fact that OpenGL has so much backwards compatibility and so much complexity.

vitd• 12 years ago

Not to mention how obtuse it is to learn. Even without the backwards compatibility issues (which are very real), the entire mental model of how OpenGL works is completely messed up.

Things like having a texture ID, which you then bind to a particular target on a particular texture unit in order to use it make so little sense to someone learning it for the first time. On the CPU, I just pass the pointer to my image to a function to manipulate it. I don't have to put it into a special slot of a special structure in a special place in memory! It took me years to understand many of these things, and I see others struggling in the exact same way on Stack Overflow, for example. So sad.

kevingadd4• 12 years ago

The difficulty of implementation is at most half the problem, IMO. Driver vendors can afford to maintain a 'merged' version of the spec with extension diffs applied, and can pay experts to acquire and retain knowledge on the breadth of the spec.

The challenges arise in validation and actual development. Validating that a driver works correctly is VERY difficult due to the complexity of the spec, and you can't really afford to have a huge test team with as much experience and knowledge as your driver development team. Even once you've validated and shipped your driver, you can't know how end-users are going to exercise it.

Then as a developer, not only do you have poor knowledge of the spec, but you have no knowledge of how each vendor interpreted the spec and whether or not their implementation matches their expectations.

As the surface area of OpenGL and the complexity of each entry point grow, this is only getting worse.

rwbt2• 12 years ago

ATI drivers are horrible on the Mac OS X platform too, even though Apple controls all their drivers on the platform. Even though Intel's GPUs are slow their drivers are very stable and work most of the time.

mwfunk2• 12 years ago

That's actually not true, the NVIDIA and ATI drivers are maintained by the vendors.

mrec3• 12 years ago

It's a bit of both. I believe Apple maintain the app-facing side of the GL implementation. Backend plugins are provided by IHVs to talk to their specific hardware, but with Apple still controlling the release channels.

AFAIK there's no route for an IHV to get an updated driver to a user without going through Apple, put it that way.

duaneb• 12 years ago

Then how come you can't manually install driver updates? Because Apple controls the release channels and public facing interface.

dkarapetyan2• 12 years ago

Can someone explain why the drivers are closed source. Is it the fear that the hardware can be reverse engineered from just the driver?

mschuster915• 12 years ago

I believe that much of this originates from the legal department, at least in the NVIDIA case. Probably patent or IP-related.

jra101• 12 years ago

Driver optimizations are a competitive advantage.

wtracy2• 12 years ago

That, and sometimes device A is x% faster than competing device B because the driver for device A is faster, not because of the silicon. Open that up, and you give away your competitive advantage.

Also, there are always rumors about $LOW_COST_PRODUCT being the same silicon as $HIGH_COST_PRODUCT from the same manufacturer, just with a few features turned off in the driver. This probably isn't true, but nobody can rule it out.

mschuster915• 12 years ago

Rumors? Uh, no. NVIDIA is known for this (http://www.tomshardware.com/news/Nvidia-GTX-680-GTX-770-BIOS...). IIRC one could also flash a consumer-grade card with a Tesla BIOS and "convert" a couple-hundred-dollars-card into a thousand-dollars-card.

caust1c• 12 years ago

I think that's actually happened a few times before. I can remember some hardware hacks that actually caused the gfx card to be recognized as a higher end card, causing it's features to become enabled.

Wether or not that's in the ROM or driver is up for debate though.

Edit: Found an example more recent than I was thinking, but it's been around a long time: http://www.eevblog.com/forum/chat/hacking-nvidia-cards-into-...

sp332• 12 years ago

It's not a rumor, I mean nvidia advertised the same chip in e.g. the GTX 680 and the Quadro K5000. The K5000 got ECC RAM and a lower clock rate, but the GPU die was the same. All the difference was in the drivers.

izacus3• 12 years ago

That's partially true.

There are also game / application specific optimizations and tricks in those drivers that show up as those "30% increase of performance in game X" changelogs.

pjc50• 12 years ago

And some of the drivers will blatantly cheat the benchmarks. I remember stories of one driver that behaved differently if called from an executable named QUAKE.EXE - if you renamed Quake you got slower, more "correct" rendering.

izacus3• 12 years ago

That.

Also those drivers are huge (really, HUGE) and have incorporated pieces of code with widely differing IPs, patents previous companies and other sources for which opensourcing would probably be a major legal hassle and lawsuit risk.

Also... if you're nVidia / ATi... what's the gain in giving optimization paths and software optimization database to the competitor? Those drivers are full of application / game specific optimizations to make them look better / run faster / workaround bugs.

kevingadd4• 12 years ago

Primary issue is IP rights. For example, DXTC (S3TC) is patent-encumbered, but many GPU features are not only patent-encumbered but are trade secrets - vendors like NVIDIA have in the past had trade secret, vendor-only extensions for things like a special texture filtering algorithm for shadow maps. So in many cases a driver vendor may not even be able to open their source if they want to, because it contains proprietary trade secrets from a third party, where they're using third party code to compile shaders or whatever.

sounds2• 12 years ago

Along with all the good responses to your question, it's worth pointing out that Intel has completely open-sourced their driver and GPU, and ATI has open-sourced their GPU and produced a driver that can do about 90% of what the closed-source driver can do.

P.S. Broadcom open-sourced a part of their GPU for the Raspberry Pi. (Specifically the VideoCore IV VPU on the BCM21553 which RasPi is porting to the BCM2835 http://www.raspberrypi.org/a-birthday-present-from-broadcom/ )

slashdotaccount• 12 years ago

Corrections:

Intel open sourced their driver not their GPUs.

Broadcom open sourced part of the software running on one of their GPUs, not their GPUs.

awalton2• 12 years ago

Embedded [nVidia] developers "optimizing" games by rewriting and hand compiling shaders to replace shaders in shipped games isn't enough of a clue as to why these drivers aren't OSS for you?

The article is rich with the reasons behind this. Some of it is IP encumbered, some of it is benchmark hubris. All of it is the shroud of secrecy that the graphics market prided itself on coming back to bite them in the ass as their driver stacks are now massive piles of virtually unmaintainable code - code that can't even be rewritten because the companies themselves (well, at least AMD and Intel) are hiding details about how the hardware works from itself!

dkarapetyan2• 12 years ago

I really thought the part about embedded developers was a joke.

zurn• 12 years ago

When left to their own devices companies have little tendency to cooperate on that level. The proprietary drivers represent an enormous investment, it would be near-impossible for a new company to enter the market and develop competitive proprietary driver stacks for DirectX and OpenGL.

Maybe some day in the future the various GPUs will have code gen backends in LLVM/Microsoft compilers without needing secret & broken vendor drivers and we'll be down to one set of bugs per platform, instead of <dx-win|ogl-win|ogl-mac|ogl-linux-proprietary|ogl-linux-free> x <amd|nvidia|intel> = 15 combos.

mschuster915• 12 years ago

I'm completely missing the mobile space in this writeup, but I bet it is a situation even worse than ATI (no way to update the GPU drivers, short of a full OS upgrade on Android)

simcop2387• 12 years ago

It absolutely is from what I've heard. There are devices where the Mali GPU works well in some games/apps with one version of the OS and are severely broken in a newer version because the driver broke a lot of things to make other apps work.

It's one of the big reasons I'm hoping that with efforts like the driver for GPU for the RPI being open sourced that we'll start to see some more consistent drivers for mobile chipsets.

mschuster915• 12 years ago

I more fear of a world like DOS/W3.11-era games - that games ship their own drivers like back in the old days it was done for soundcards...

pjmlp2• 12 years ago

John Carmack has commented on the replies section that is much worse.

sharpneli2• 12 years ago

I have the misfortune of developing OpenGL ES stuff. And I cannot overstate how bad the drivers are.

It's pure bliss to use normal desktop gl implementations because they don't constantly crash on you. They don't have weird breaking bugs. They don't leak memory like no tomorrow. They don't play fast and loose with precision. They don't have absolutely retarded performance regressions.

Basically the drivers only work if you use Unity or some other well known engine. The driver makers don't really bother making real ES drivers, they just make something that doesn't crash Unity.

I could go on and on about this.

socialist_coder• 12 years ago

Speaking of Unity + Android, our mobile game is seeing a huge increase in crashes on Android 4.4.2 (the latest) on Samsung GPUs (PowerVR). Apparently it's due to a bug in the driver. So, I guess the mantra of "don't crash Unity" doesn't always succeed =)

ah-• 12 years ago

Any idea wether the Intel osx driver is related to the Windows one or also completely different?

overgard4• 12 years ago

Not a vendor per se, but since they pretty much prevent you from installing any updated drivers I'll also say: Apple's OpenGL support is horrid. Like, buggy, entirely behind the times, incredibly slow. I tend to reboot my mac into windows whenever I need to do actual graphics coding, which is a shame.

wlesieutre2• 12 years ago

A friend of mine was working on a cross platform OpenGL project and wanted to use some OpenGL extension that was originally proposed by a couple of people from Apple and somebody at Nvidia.

You would assume that having proposed it, Apple would have implemented it. Nope. Windows only.

Apple advertises their support for OpenGL 4 in Mac OS 10.9, but they're only up to 4.1. That's the version of the spec from 2010. No tessellation or compute shaders, among other things that were added in 4.2, 4.3, or 4.4. In particular, 4.3 would be a big step because of parity with OpenGL ES 3.

mattst88• 12 years ago

Tessellation shaders were a part of GL 4.0. See https://developer.apple.com/graphicsimaging/opengl/capabilit...

ekianjo2• 12 years ago

Apple's OpenGL support is horrid.

Funny, they still do get a lot more game ports than Linux so far (while Linux is progressively getting there).

gcb0• 12 years ago

By your logic you'd buy a pinto instead of a Ferrari or a model S

maccard• 12 years ago

larger (proven) market share is my guess. I have no stats on that by the way, it's a pure guess. The closest thing I ahve is I looked at the humble bundle stats, and scrolled down to the first games bundle which is : http://support.humblebundle.com/customer/portal/attachments/...

Looking at the graph, I can't differenciate between mac and linux on it, but the next one (humble indie bundle 9): http://support.humblebundle.com/customer/portal/attachments/...

the mac purchases are more substantial than the linux ones. This could be due to any number of factors, but like I said, it's only a guess.

overgard4• 12 years ago

Well, sure, but I don't see what that proves. Game developers find a lot of hacks to work around bad software if there's a market.

izacus3• 12 years ago

Most of those things pretty much stem from the fact that OpenGL is nowhere near priority for those companies - D3D game performance in benchmarks is what sells the accelerators. Additional features like HW video encoders are second.

OGL support is far behind.

svdree• 12 years ago

This guy should try some OpenGL-ES development on Android. Suddenly vendors A, B and C don't sound so bad anymore...

mattgreenrocks• 12 years ago

What's horrible is I've done almost zero OpenGL dev and I could pick these out immediately based on anecdotal experiences with drivers on Windows. Vendor B might be getting better (supposedly), but I still have a tendency to shy away from their drivers (thus, them) due to past experiences.

anon42• 12 years ago

Well let me put it like this. I bought a Radeon 9600 back in 2003 when ATi still existed as an independent company. In the time since then, I haven't seen enough improvement to justify buying anything other than nVidia.

To be fair, they are better - I haven't heard them lately crashing the kernel so hard the alt-sysrq combos don't work.

veesahni• 12 years ago

Is it practical to create a driver abstraction that masks cross vendor issues and provides a consistent interface to the dev? Like what jquery did for browsers.

Negitivefrags• 12 years ago

Yes. It's called OpenGL.

cleversoap• 12 years ago

A lot of engines do this to some extent (eg. OGRE3D, Irrlicht, et al.) but there are pitfalls there as well. While jquery does a good job of shimming in hacks for older browsers the world of graphics programming isn't really that flexible and even newer drivers can still be a total grab bag of what they support - think of it like this: you have the latest version of Firefox and you can support everything but rendering text in italics. How would you shim that in? Can you? What if it tells you it supports it but it actually slants text the other way? What if it renders correctly but doing it the normal way takes an hour but there's a hack for only this operating system and version of Gecko that works. Also there really isn't a manual and StackOverflow is full of questions that contain all your search terms but are actually for a completely unrelated matter.

So you drop it from the common interface that your abstraction presents because it's just not consistent enough....

There are also a TONNE of shader abstraction languages that transcribe to HLSL or GLSL on the fly for the same reason.

tldr; Engine developers stare into the abyss and somehow the abyss gives back a projection matrix.

exDM692• 12 years ago

Is it practical to create a driver abstraction that masks cross vendor issues and provides a consistent interface to the dev? Like what jquery did for browsers.

Yes and no. The situation with OpenGL and drivers is quite different to browsers and jQuery.

OpenGL drivers are generally quite good in implementing the API as it is specified and this is tested with a huge bunch of conformance suites. It's not like ancient browsers where one vendor's understanding of the CSS box model is different from the others'.

However, OpenGL has a huge number of different versions, some require hardware support (major versions like GL 4.x vs. 3.x), while others might be software only additions (minor versions, GL 3.2 to 3.3). And then there are lots of API extensions that may or may not be available. This is a relatively simple problem to solve and we have tools like Regal and ANGLE to patch the little things.

But the real problem is functional bugs. Incorrect pixels on the screen ranging from a minor annoyance to a completely destroyed image. And more severe issues like application crashes, completely corrupted display/desktop to blue screens and kernel hangs. This is something that cannot be fixed.

lolo_• 12 years ago

Not to stray too off topic but what does TDR stand for? :)

klodolph• 12 years ago

Apparently, it is a feature where Windows detects that a video card is unresponsive and resets it.

http://nvidia.custhelp.com/app/answers/detail/a_id/3335/~/td...

Someone• 12 years ago

"you can git your hands dirty and try to fix it and submit a patch."

Typo or funny wordplay?

awalton2• 12 years ago

Intel's OSS driver is maintained in git.

So, wordplay.

ksec2• 12 years ago

I have been wondering about this for long time. The biggest cost in GPU development isn't the Hardware itself. But the drivers. Nvidia famously said they have much more software engineers then hardware guys. And as history can tell having great Hardware on paper means nothing when your Drivers aren't being up to standard ( S3, PowerVR on Desktop). Hence the smaller group of GPU maker were forced out because they dont have the resources to complete on the software front.

And yet over the decades nothing has improved. When Browser wanted to do hardware Acceleration there were many Laptop GPU being blacklisted simply because they dont have any drivers update. Situation is much better on Mac because the drivers and testing happens to be the same people.

There are people who wanted the GPU to be just another CPU. Intel Larrabee. But none of them has succeeded.

I wouldn't have thought with GPU IP taking rounds, drivers quality being in the hands of vendor would have improve the situation abit. However it seems no one wants to invest into it.

So do we have no solution for this? Rumors has it Apple are designing their own GPU. May be they are tackling the drivers problem themselves by getting rid of it?

anon42• 12 years ago

Larrabee did succeed - it just got rebranded as Xeon Phi and is sold as a high-performance computing PCI card.

pjmlp2• 12 years ago

Not really, at least for those of us that seated at an Intel talk about Larrabbe on GDCE back in 2009, on how Larrabee would revolutionize graphics programming.

ksec2• 12 years ago

It did in terms of HPC. Not Gfx, which failed miserably.

MichaelGG• 12 years ago

What do they mean by nVidia embedding developers on teams? Like covertly getting nVidia employees hired by game teams to sabotage non-nVidia?

mcpherrinm• 12 years ago

Not covert at all. Nvidia engineers come to your office and work on your code for you. They know more secret sauce and contacts inside their company, so they can help you get your performance up on their chips.

nitrogen2• 12 years ago

So, they're Field Application Engineers, basically?

dman• 12 years ago

Any ideas on whether Nvidia and Intel will support opencl 1.2 on their gpus on linux anytime soon?

sharpneli2• 12 years ago

Even though this is offtopic I'll answer: Not going to happen.

Nvidia hates OpenCL as it eats their Cuda business and Intel performs market segmentation, therefore their Linux implementation supports only CPU and Xeon Phi and Windows supports the GPU. They don't want server builders to purchase their desktop chips with GPU's. They want them to purchase the massively expensive Xeon Phi and use normal Xeon CPU's.

programminggeek• 12 years ago

I assume driver incompatibility and things of this nature are one reason why so many games are built on engines like Unreal, Crytek, Unity, etc.? At some point you need to be working on shipping a game, not writing driver compatibility code that a framework could/should handle for you.

The Truth on OpenGL Driver Quality

Related Stories