NVIDIA Continues Ramping Up Their Vulkan Articles

[starshipeleven]

I wonder how well a Vulkan game that was developed today will work unmodified on an new NVIDIA card 4 years from now. Right now NVIDIA makes sure that new games work well with their GameReady Drivers, but now I guess the app developer will have to make sure that an old game runs good on newer hardware? How much driver optimization is still there for NVIDIA & Co to tune the driver for newer games? I fear that an OpenGL application will run better on a card 4 years into the future without ever touching it again than the same game on Vulkan, because the OpenGL driver will always see development but applications might be abandoned.

"Game Ready Drivers" are actually "Drivers + A Bunch Of Gaming Profiles", that is, the driver recognizes the game and pulls a bunch of pre-configured lower-level tricks to help that specific game, because the game is calling an abstract API and cannot get more low-level than that.
And there are profiles because what helps a game might be annoying for another (or because it might not be good to boost games that didn't pay NVIDIA for this service).

With Vulkan/DX12 that "optimization" should be completely unnecessary because that's a lower-level API so optimizations should theoretically happen on the game engine side, not on the driver side.

As long as the driver keeps the same API, the games should work fine at any point in the future.

[pixeljetstream]

yes heuristic tuning ideally is less of a necessity for low-level apis. However they would still "age" if untouched as well. Vulkan will get new versions, too, exposing new features...

Chances are a game run on 4 year "newer hardware" will likely not need to leverage that particular hardware at its peak to still work just fine. And if a title was such important software to reach its peak, vendors may tune their Vulkan drivers again and use heuristics (and they can afford to do so as the game was designed for 4 year older hw, meaning there could be "space" to tune). When OpenGL started it was also "low-level", the hardware was fixed function and enable/disables mapped to hw registers well... and the transition to programmable hw worked okay as the CPUs were also faster to account for some of the "translation". Vulkan is just a bigger re-base. But indeed if all is leveraged well it would continue to scale (scale with CPU cores and GPU cores). And chances are if something is important it will see updates along those years... or new versions of itself...

starshipeleven, why dou you think developers would pay for such service? Imo that would make little sense. The hardware companies have a genuine interest to shine in big titles that see a lot of media attention. That is what fuels them optimizing certain titles, so that their customers have a good experience and so that they sell hardware. For a game developer paying for this would not have a direct incentive, as say 10 fps more in some benchmark is not gonna sell that game over another game. Likewise if the game runs bad for some vendor vs another, that most likely falls back on the hardware vendor, not the game developer.

[Philip]

I wonder how well a Vulkan game that was developed today will work unmodified on an new NVIDIA card 4 years from now. Right now NVIDIA makes sure that new games work well with their GameReady Drivers, but now I guess the app developer will have to make sure that an old game runs good on newer hardware? How much driver optimization is still there for NVIDIA & Co to tune the driver for newer games? I fear that an OpenGL application will run better on a card 4 years into the future without ever touching it again than the same game on Vulkan, because the OpenGL driver will always see development but applications might be abandoned.

That seems a reasonable concern to me, though it should be partly mitigated by GPUs 4 years from now being much faster than today's, so even if the game doesn't map as optimally to the new hardware it may still run fast enough.

I suspect a bigger danger is that games will be full of bugs in their Vulkan usage, because there was some error the validation layer didn't detect or because they made a last-minute change and didn't even run the validation layer, or because they saw the validation error but it's 2am on a Sunday and they really want to go home, and they will just do QA on the current popular hardware and ship it. Then a future GPU will have slightly different timings that trigger some race condition, or slightly different memory management so it doesn't flush caches when the game implicitly expected it to, and everything will break in horribly subtle ways, and the developers won't care enough to fix it or their original engine experts might have left the company so nobody can even understand the problem. Then the GPU vendors will have the pain of reverse-engineering the game's logic from its low-level API calls and adding hacks to make it work again, because customers won't buy new GPUs that break their favourite old game.

(Mantle lets applications provide the name and version of the application and of their engine, which I assume is specifically to let the driver apply application/engine-specific hacks in a slightly nicer way than looking at the .exe's filename, so they were already anticipating that need.)

Still, that's probably better than the situation with OpenGL, because at least it starts with the game and the drivers cooperating with a fairly direct API, instead of the game trying to trick the complex undocumented driver heuristics into choosing the fast path and the driver simultaneously trying to trick the game into choosing the fast path.

It might be bad news for games on minority platforms like Linux, if the driver code isn't shared with Windows, because there won't be the resources to add the driver hacks to make old games run correctly (never mind making them run fast). But it might be better for open source games, because anyone can fix the problems in the game itself instead of in the driver.

[starshipeleven]

yes heuristic tuning ideally is less of a necessity for low-level apis. However they would still "age" if untouched as well. Vulkan will get new versions, too, exposing new features...

Which are probably irrelevant for the "older" game, as long as the API it is using are not changed, it will work exactly the same.

vendors may tune their Vulkan drivers again and use heuristics

That's assuming it makes any sense to do so, and it's not a given.
If most of the optimizable code is not in the driver, they may very well not have any headroom/reason to optimize, or no way to optimize it for that single game (maybe a feature that is the same for everyone) and simply make a better driver that works for all.

[Kano]

I think it will take some time to get fully optimized Vulkan games. It should be certainly possible to do much more tuning to use all cpu cores (most eON based games are limited by just 1 thread). I doubt that magically AMD cards reveal the full power with the first games, but fglrx tends to be earkier CPU limited than Nvidia (without game specific profile) so maybe we will still se a gain. Vulkan tends to be much more low level, so drivers are simpler and can be optimized just like the Mantle approach AMD invented before - so AMD might be better prepared. On the other hand: Nvidia does not need to cut down development to make profit. They see OpenGL and Vulkan as base to sell chips for Android for gamers - AMD has the main focus on PC games, so how many will use Vulkan on Windows soon, that's one important question.

[pixeljetstream]

If most of the optimizable code is not in the driver, they may very well not have any headroom/reason to optimize, or no way to optimize it for that single game (maybe a feature that is the same for everyone) and simply make a better driver that works for all.

you are right, it is more likely in that kind of api that we see more extensions (new versions) and usage flags exposed, if certain "patterns" benefit from being expressed explicitly.

I suspect a bigger danger is that games will be full of bugs in their Vulkan usage, because there was some error the validation layer didn't detect or because they made a last-minute change and didn't even run the validation layer, or because they saw the validation error but it's 2am on a Sunday and they really want to go home, and they will just do QA on the current popular hardware and ship it. Then a future GPU will have slightly different timings that trigger some race condition, or slightly different memory management so it doesn't flush caches when the game implicitly expected it to, and everything will break in horribly subtle ways, and the developers won't care enough to fix it or their original engine experts might have left the company so nobody can even understand the problem. Then the GPU vendors will have the pain of reverse-engineering the game's logic from its low-level API calls and adding hacks to make it work again, because customers won't buy new GPUs that break their favourite old game.

That is a bit too pessimistic imo. The people who will use Vulkan for shipping products, are most likely knowing what they are doing. Because the added responsibility on their end is an investment and a chance to squeeze out more. It is not some hobby developer who wants to get some triangles on the screen, I don't think the developers would be that sloppy. Of course what you describe could in theory happen, but chances are if the developers were that sloppy, the game would have other issues on release already, and not 4 years later

Also the fact that when something gets released it will be tested either before or after launch on multiple hardware architectures, and while not all vendors may need all the flags "correctly" chances are the sum of them complete the "matrix" (after all that is why the API is like it is today, so all vendors can extract the bits they need). It's not like people will ship products with full "must have" vulkan that soon. They will soon release things using Vulkan (like CroTeam announced already), but in an early development phase, so that all part of Vulkan get tested more (driver, application, tool layers, compilers...), I guess it will take a year until all that stabilizes well for production use. Hardware vendors also have to see what developers send to the driver and want to achieve to find out the "do's and don'ts" and then give recommendations to maximize perf for their hardware.

[Stebs]

Those nvidia articles give an atmosphere as if nvidia isn't happy at all about Vulkan, they are basically saying that Vulkan has the same flaws that OpenGL has and that it will require specific hardware code paths like OpenGL does... Also all the effort they are doing to mix OpenGL with Vulkan smells like their drivers is going to run Vulkan in top of OpenGL and not the other way around...

It is far worse, some Insider told me, Vulkan is not really implemented in the driver, they are going to use streaming for that. At first, you don't have to pay, but after some time (source was not sure about time-frame), the first bills are incoming, all sanctioned by the Agreement you clicked on while updating the driver.
The Source (with deep voice) even heard about the area where Nvidia is locating their new GPU-Racks for processing the streaming: They got a ranch they call number fifty-one
(can't see it all 'less you're flying by)!

Seriously....

[computerquip]

From what I read there this extension is provisional. It proposes adding a bunch of built-in functions. Those are taken from glsl but not exclusive to it. You will find the same functions in directx.

Not to kick up an old thread but...

This is an incorrect assumption. The GLSL extension is currently the only instructions we can use to actually do calculations. For instance, floor is not in SPIR-V core. It is a provisional extension, however, in order for anything else to be supported, it would have to be supported by the driver itself, which we sadly can't rely on. Thankfully, while it's based on GLSL syntax, it's really just a bunch of common graphics functions documented for use in a Spir-V format.