> contain complete compilers that munge your code with a focus on speed over correctness
If you’re a developer, the right tools are available. Set D3D11_CREATE_DEVICE_DEBUG when creating the device, also run debug builds of your HLSL shaders. You’ll get huge amount of error checking and diagnostics this way, including very detailed and specific messages about incorrect API use.
> GPU-focused debuggers are incredibly buggy and feature-poor
I indeed found and reported bugs in GPUs and their drivers (mostly Intel GPUs), but it only was a few times over my career. The majority of times they were bugs in my code, not in GPU drivers, and renderdoc.org helped a lot fixing them.
I generally agree GPU debugging is harder than CPU debugging, but I don’t see how open source driver gonna help. It’s an unfortunate combination of execution model (many thousands hardware threads running your code in parallel), external piece of hardware completely separate and asynchronous from the CPU, and very limited ways to interact or even output data (you can’t printf messages, nor allocate dynamic memory, from GPU code).
the Servo/WebRender folks maintain such a list of driver bugs with workarounds, you may find useful:
The majority of their Windows bugs aren't GPU driver bugs, they are bugs of compatibility layers like Angle and SPIRV-Cross.
IMO when using native stack i.e. D3D11 or 12 and HLSL, the quality of GPU drivers is usually OK on modern Windows.
Funny you say that. I've seen many developers praising the open source stack under Linux, as you can step right into the driver and fix it yourself, instead of landing in symbols land.
Feral Interactive mentioned it there, for instance: https://www.gamingonlinux.com/articles/interview-with-feral-...
It's 2020 and I still sometimes swap my renderer from OpenGL to D3D9 when I need to debug a graphics issue because the D3D9 graphics debugging tools are that much better than cutting-edge GL debuggers. (I'd use the D3D11 debugging tools but my 11 backend doesn't work right)
This is not true. Driver quality is a major differentiating factor between GPUs and absolutely influences purchasing decisions.
GPU makers don't want their competitors to be able to take parts of their drivers and benefit from them. They want to protect trade secrets. They want to avoid revealing how many of their competitors' patents they are violating. They don't own the rights to some third party code or trade secrets that are incorporated in their drivers. They want to avoid revealing future product plans.
Of course it's debatable whether closed source drivers actually help with all of the above reasons, or whether they are good reasons to begin with. But those are the reasons.
No, Not at all.
If we go all the way back to 3Dfx era, we have seen dozens of GPU ( or 2D/3D Graphics Accelerator before the term GPU was coined ) trying to compete in the PC space, 3D Labs, Matrox, PowerVR, Intel I740, S3, ATI, Nvidia, Rendition, ( These are on top of my head, sorry if I missed any of your favourite ). None of them had much problem with designing hardware, their maximum triangles, ( If I remember correctly it was one of the unit used to market graphics card before GFLOPS were used ) were all on par with each other. And some even exceed the current dominant players, but in the end they all failed.
Why? Because they cant get the drivers / software to optimise the use of their Hardware. They do not perform any where close to their potential in Tomb Raider or DOOM. There are huge amount of optimisation built up over the years. As Nvidia once said ( That was even before their huge bet on CUDA ), 60% of their engineers are Software.
To point where the I am going to say, the Driver IS the GPU. You are just paying the hardware to use it.
* And now I feel very old just typing this up. :/
Your second point is correct, that open source drivers do get better support. AMD has better support on Linux than NVIDIA because it has an officially supported open source driver (AMDGPU). However, the support they receive from open-sourcing the drivers is not always the R&D required to gain a competitive performance advantage, limiting the competitiveness of an open source driver (at least compared to proprietary).
Would there be some sort of uproar if people found out that Firefox had special optimizations for common websites, for instance?
> Would there be some sort of uproar if people found out that Firefox had special optimizations for common websites, for instance?
It would ruffle a few feathers if Chrome was optimized for Google properties, but ran their competitors' code with a performance penalty.
One of the issues in United States v Microsoft was that IE used optimized APIs that Microsoft's competitors, like Netscape, didn't have access to.
It is: https://9to5google.com/2018/07/25/youtube-chrome-firefox-edg...
As long as they aren't actively sabotaging your software, I don't see why this is a problem. Adobe is clearly the market leader in photo editing. If adobe pays nvidia to improve performance of photoshop, why is that an issue? They aren't paying nvidia to make gimp worse.
Also "sweetheart deal" is a loaded term. What is your definition of sweetheart deal here?
> A "sweetheart settlement" may also occur in a legal context. For example, in a class-action lawsuit the attorneys representing a class of plaintiffs may reach an agreement with the defendant in which the primary result is a lucrative fee for the attorneys rather than maximum compensation for the class members.
> Noted instances and allegations
> In a 1947 unionization dispute, San Francisco area grocery store owners claimed that other stores who had "given-in" to union demands had signed sweetheart deals with the unions.
> In a 1949 dispute between the rival American Federation of Labor (AFL) and the Congress of Industrial Organizations (CIO) involving unionization of the laundry industry in Indianapolis, Indiana, a lawyer for the 42 laundry and dry-cleaning plants testified before the National Labor Relations Board that an AFL union contract was not a sweetheart deal between the employers and AFL union officials, as alleged by the CIO.
There was a comment on this site a few days ago that claimed Google was being anti-competitive by hard-coding a list of their web properties into Chrome for it to send diagnostic info when visiting them, so yes, anything where there's a special path for some 1st/3rd parties but not others could be construed in many ways that look bad for the author.
With open source drivers, AMD or Intel could just walk in and steal whatever optimizations nvidia has made for a game.
> The specification must include a written description of the invention and of the manner and process of making and using it, and is required to be in such full, clear, concise, and exact terms as to enable any person skilled in the technological area to which the invention pertains, or with which it is most nearly connected, to make and use the same.
You don't have to provide code, but you have to teach the reader of your patent how to make and use the invention.
It does? Exactly zero of the companies I've worked for in my career have forbidden me from reading patents.
Given how many patents are vaguely worded, and how, um, interesting the decisions in patent cases sometimes come out, many companies decide that it isn't worth the risk.
Note well: IANAL. I've just been in companies that had this practice (don't read patents), and I remember why.
You'd think that, but understand that Nvidia's primary advantage is actually in the drivers. In the graphics industry it's known that AMD GPUs often perform better at various tasks as they become highly optimized. However Nvidia GPUs most often benchmark better. As it turns out Nvidia drivers have an enormous set of optimizations it can enable based on heuristics which end up being the key to making up most of the difference.
The USPTO is terrible at performing prior art searches and terrible at rejecting obvious claims, so there are legions of trolls waiting in the wings to jump on them if they go open source.
Opening the source to drivers as they exist now might expose IP that might not be yours to share, IP that you aren't licensed to use or open you up to liability because of how bad your drivers actually are.
That said, I do believe hardware companies should prioritize open-source drivers to benefit themselves and their customers.
It may on may not end up improving support, but you can't really know that ahead of time. Then you have the risk of people using your code against you, finding vulnerabilities, patent/IP violations or simply reverse-engineering your hardware more easily. You also won't be able to cheat in benchmarks anymore.
There's a cultural aspect to it too. Paying all these engineers to write that code was expensive, and now you want to give it all away for free? Most companies never do that for anything, why would they make an exception?
It's dumb, I too would love for these drivers to become open source, but it doesn't look like it will be happening any time soon.
I'm not saying it doesn't exist, but I've been doing professional software development for more than twenty years and have never encountered this. There's plenty of "we should be paid for our work and innovation" but nothing so reflexive as what you describe here.
But embedded GPUs are so fucking obnoxious. There’s about a million of them and they pretty much all have proprietary binary blobs. Pretty worrying for something that could potentially allow any device to be remotely compromised via some malicious webGL or something. Good luck getting the manufacturer to continue supporting it 3 years from now though
The state of the art in debugging GPU issues is to have a closet full of random hardware purchased used on eBay that hopefully contains something close enough to what you need to reproduce the issue you're working on.
Most fancy debugging tools pretend that GPUs don't exist and GPU-focused debuggers are incredibly buggy and feature-poor, not to mention hardware specific in many cases.