Hacker News Reader

Comment by dkarapetyan | Hacker News Reader

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

View on HN

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.

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.

While technically the same hardware, isn't it the case that the "higher end" products are the units off the production line that met a higher QA bar?

That's my understanding of how it works for CPUs. A four-core CPU with questionable functionality on the 4th core may be sold as a "3 core" CPU. Depending on how "questionable" the 4th was though, it might be possible to use it anyway.

I don't think production quality is the only reason. Sometime it's cheaper to design one product and sell it as multiple products to capture more value. For example, some people are willing to pay 1k for a graphics card while others are only willing to pay 300. So you sell the same graphics card to both groups but for one you artificially lower it's capability. This allows you to capitalize on the market a lot more efficiently than selling your product either at a low price or a high price.

With Tesla cards, you get a professional-oriented driver that is good for Maya and CUDA, but not optimized for games. There are also a few hardware features that are important for pros but are not an issue for gamers --stuff like ECC RAM, double-precision fp, better handling of multiple 3D viewports.

But, it's my understanding that most of what you pay for when you buy a Tesla card is support. If you call Nvidia saying Maya has a driver problem with your Tesla card, they will pay attention. If Maya has a problem running on a GeForce card, they will direct you to the forums.

Especially you have only one product to produce on the highly expensive PCB/chip manufacturing lines - if you experience demand shifts, just reflash the BIOS and change the packaging.

Way cheaper (and more flexible!) than ramping up different production lines.

Lots of chip companies do this. I worked for a company that sold a whole line of different chips at different price points that all used the same die. They had different packages and they all had different internal pads on the die connected to ground so that the chip could detect what mode it was in. The firmware could read this and detect which hardware was enabled or disabled.

I remember the management being very secretive about this since they didn't want their customers to think they were being ripped off by buying the "expensive" chip…

I don't meant to sound critical of this practice… From an cost perspective it makes a lot of sense to do it this way—the cost to layout, test, and create all the masks for a custom chip is huge. So it makes sense to want to cram as much into one chip instead of making 2 or 3 or 4. That way the one time cost of creating the masks and tooling up at the foundry are amortized over all the products that use the die.

> 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.

No, this guy was soldering resistors on his $1000 card to spoof the PCI vendor:device IDs and fool the driver to enable a software features (4 displays at once). The same could have been done by patching the kernel.

IIRC Nvidia fixed the "bug" that made this work but enabled the feature on the consumer cards (it was available on Windows but not Linux for reasons unknown).

But he did not get access to the hardware features which are fused off.

And as others have said, every chip manufacturer out there does same. Intel has 20+ models of their most recent CPUs, which are probably all the same silicon or perhaps a few different designs. i5's are "crippled" i7's (perhaps ones that were not 100% successfully manufactured), but you get them at a discount.

I stand corrected.

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.

That's the norm these day. It's called application-profiling and done by every vendors in the market.

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.

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-...

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.

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!

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

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.

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.

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/ )

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.

I understand what you're saying, that the situation is not completely clear-cut (especially what Broadcom is doing).

But Intel has most definitely documented their GPU registers and hardware – not just the intel open source driver:

https://01.org/linuxgraphics/documentation/driver-documentat...

That is not the same as open sourcing the GPU itself. They haven't released HDL source for the chips themselves.

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.

Driver optimizations are a competitive advantage.

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

Reply on news.ycombinator.com