Anyone who's read Raymond Chen's blog, or ever encountered MKCOMPAT.EXE (https://en.wikipedia.org/wiki/Make_Compatible), will know that Windows is full of application-specific hacks to maintain compatibility. I suspect every complex system component has something similar for the same reasons. I doubt it's for any nefarious purpose.
>Kyle Bennett at the HardOCP found that replacing every instance of “quake” with “quack” in the Quake III executable changed the Radeon 8500’s performance in the game substantially.
At least for graphics drivers it's common that the driver applies tons of game-specific workarounds and optimizations, I guess this is also the main reason why there are monthly driver updates (fixes for new games), and why graphics drivers have become so massively big.
Assuming that the same game-specific tweaking happens for CPU performance and compatibility doesn't seem like a far stretch.
> it has a security descriptor allowing Everyone + Low IL R/W Access, and an IOCTL interface with absolutely no Probes/SEH, which yes, dereferences wild pointers.
> I guess this is also the main reason why there are monthly driver updates (fixes for new games), and why graphics drivers have become so massively big.
I don't think so, otherwise it would be limited to graphics drivers. Since other kinds of Windows "gamer"-type drivers (keyboards, mice, motherboards, etc...) have also bloated over time, I think it's more about including useless things in them, as well as the use of inefficient frameworks like Electron.
You can buy other mice and keyboards, even the gamer type, without pushy dark-pattern crapware, if you avoid certain brands, e.g. Razer.
Anyway, I think they're roughly right about gpu driver bloat. Release frequency has a lot to do with new app-specific optimizations, in between updates to support new hardware configs. As far as size, even without the GeForce experience-type stuff, the packages are still huge. They're supporting multiple generations of complicated devices with a sprawling set of features and APIs, but it's also those host hardware and app-specific tweaks building up.
I don't know why they need to disguise this driver, but every single GPU vendor does this, there's a reason nVidia heavily advertises "$LATEST_BIG_GAME Driver Support" every time a new AAA game comes out, it's all AppCompat flags, all the way down.
I remember these tricks being discovered as early as ~2000, and it's been a scandal every time it was found NVidia or ATI did it. Not much has changed over the past 20 years.
They had to work around bugs in games and even Windows had hard coded fixes for things like use after free errors in SimCity2000. The scandal was when they were caught using that to reduce render quality in benchmarks to get better results.
The game I work on is in the list and early on we saw a bunch of inexplicable crashes from Zen hardware (looking through the dumps we would see $rip had gotten itself into impossible places or we'd get exceptions at addresses that were not involved in the crashing thread).
As these crash faded from our bug leaderboard we assumed it was people upgrading their BIOS to get microcode fixes; I guess these runtime checks were a desperate attempt to avoid crashes in the interim? Windows Update is pretty bossy but it never demands that you update your BIOS.
How our game got on that list is baffling to me, though -- I don't know how AMD would have gotten the crash reports in the first place.
Maybe. But it's more likely they're replacing shaders with game- or engine-specific workarounds for hardware bugs. Used to do exactly that in my first GPU driver job. The goal wasn't to cheat, but to fix issues in popular games that for one reason or another wouldn't be patched for your GPU on its release.
I wonder why they don't just call the game developers on the phone and say "here is AMD, you must fix your shaders, here is the code". Certainly I would jump if I got contacted by AMD or NVIDIA.
Now someone is going to say, if a game breaks people are going to blame AMD, so it is their problem. But AMD would just have to play hardball once, pick a smallish publisher and say "XY refuses to fix their broken code, we even did the work for them, we don't reccommend buying their games".
From what I hear a lot of game engines have horrendous bugs that is terrible for performance (like people straight up using DirectX incorrectly, not being aware of the quadrillion performance hacks that AMD/Nvidia are keenly aware of)--so what AMD and Nvidia does is they "fix" the game engine by making it more performant.
Potentially it might be better for them to contact the game dev for a collaboration or just to tell them to fix their shit, but it might a) be more annoying than to just silently patch their code b) might benefit their competitor.
Ha, having been on the game dev side of this, it's _also_ often c) the teams of lawyers between the developers and the outside world won't allow collaboration.
The situation is _much_ better nowadays, but in the oughts and early tens it was basically a given that the game source code was considered too valuable to risk sharing.
Right, the above suggestion might work with coordination, where AMD and NVIDIA both bullied a publisher. But if people want to play a game and NVIDIA makes it work great, despite software bugs, and AMD writes a blog post, I think it's pretty reasonable to say "maybe next time I'll buy NVIDIA."
Also I don't think developers would be quite so receptive. It works on every card that exists in the market today, that's kinda your problem if your unreleased chip breaks this is a fairly good argument.
> I wonder why they don't just call the game developers on the phone and say "here is AMD, you must fix your shaders, here is the code".
From my experience as a member of an away team, your own goals is not the home team's goals. Thus the home team has close to zero motivation to rethink their schedule and program just because someone else, who just happened to release their product, happened to find an issue that is only observed and reproduced in a very specific platform that no one uses (yet).
Who has all the motivation to see that bug fixed? The ones releasing the product. Thus, the fixes go in the driver, because that's the only thing in their control.
There are many situations where this doesn't work:
• Old games. People still want to play these, even though the developers don't maintain them, or no longer exist.
• Game engines. If there's a bug in e.g. Unity or Unreal, that means an unimaginable number of broken games. Likewise for middleware. And it's not the engines or middleware devs who pay the main cost here: all the games using them must be updated. Which may be quite difficult if e.g. the fix is only in the new engine version, but a game project is using an old engine version, and there was some backwards-compatibility break in-between.
• Competition! If one GPU vendor doesn't fix things, its competitors will, and it will lose customers because consumers (rightly) expect that any GPU runs any releases game.
• Gamedevs may not be able to quickly or easily fix a bug. Also bear in mind that in traditional game development, once the game ships, the team is wound down. There's nobody — and no budget — to maintain it.
• New hardware. Gamedevs can't test against your next-gen GPU that hasn't been released yet. If a bug only causes problems on that hardware, how do you get them to fix it and prevent it reoccurring?
When I've worked in big companies, it was hard enough to get working contact information and then convince them to fix bugs in a reasonable time frame for real issues that were important.
In the couple of times I've tried to that accross companies, it's even worse, unless the other company is very accomidating, my company has a direct relationship, and either my company is a major customer or a major expense and the fix will save them a lot of money (and me a lot of headache). If we don't have a direct relationship, it takes months to get in touch with the right person, and then quarters to get a fix into their release schedule, so if I have a fix that works for me and my customers, I'll still put a little effort into reaching out to get it fixed properly, but then I'll just do what works.
You don't have direct line to every successful developer on the planet when you work on a GPU. And even if you did, why would game developers drop everything for bugs in YOUR hardware?
because the program might have been a pci driver which also does executable detection in the past, or ecause it still does some pci driver related stuff, or because on windows there are some people which delete everything where deleting it doesn't seem to directly show some visible functional degradation... ( I'm not kidding, even if it sounds like that).
Apparently for a while AMD's graphics drivers were improving their performance on some games by replacing shaders that used table lookups to approximate trigonometric functions with actual trig instructions, presumably improving accuracy, because that happened to be faster on their hardware.
