Details On NVIDIA's Vulkan Driver, Sounds Like It Will Be A Same-Day Release

[xeekei]

Async compute, eh? And that game doesn't even use that much of it? Imagine the coming titles. Maybe The AMD Renaissance is coming! At least on Windows.

[dragorth]

I see plenty people talking about Vulkan, but no open source driver devs among them. My assumption is that they either don't have access to it, or are in general not interested in it.

You didn't have the assumption that the Open Source devs that were working on it aren't allowed to talk about it due to NDA? Many of them may in principle support open source, but most of them won't mind an NDA for a period while they test everything before releasing it. This is how patches are done anyway, they usually exist on some machine somewhere until the dev thinks it is ready, then is published. They just have to wait for the release announcement, then they can talk about it. And many of them are probably talking about it to each other in places that you can't see.

[dragorth]

It's not that you need prior OpenGL experience per se, but knowing how a GPU pipeline works from top to bottom is really indispensable, and if you've worked with OpenGL before you generally know how it works. In retrospect, learning OpenGL itself wasn't really the hard part, it was learning how the GPU operates that took the most getting used to.

This seems to be the biggest problem with the getting into 3D graphics. Not only are you having to wrangle OpenGL/DXxx, mixed in with that you have to learn about the GPU system, and if your math skills aren't ready, you also need to wrangle somewhat advanced mathematics. (This last is relative, but can be a showstopper for the wrong mindset.)

[liam]

Keep in mind that:

1.) Oxide seems to be the only game dev studio that hypes Async compute to no end.
2.) Their website has a big AMD logo on it. www.ashesofthesingularity.com
3.) When they released their Star Swarm Benchmark for Mantle to show how great AMDs Mantle is NVIDIA released a driver update for their DX11 driver that even beat AMD cards with Mantle in this benchmark. http://wccftech.com/nvidias-directx-...api-benchmark/

Read the article. The dev claimed they worked far more with nvidia. Nvidia claimed their implementation worked...
What this seems to indicate is something I've suspected for awhile. Nvidia has a really hacked together driver. They use their resources to work with all the big titles, and game engines. When it comes to things they haven't hyped the situation is different.

[artivision]

Read the article. The dev claimed they worked far more with nvidia. Nvidia claimed their implementation worked...
What this seems to indicate is something I've suspected for awhile. Nvidia has a really hacked together driver. They use their resources to work with all the big titles, and game engines. When it comes to things they haven't hyped the situation is different.

Or simply Nvidia Hardware "driver independent" takes Synchronous graphics and operates on them as Asynchronous tiles. AMD Hardware operates them as Synchronous bulk input and output, so you need to write them Asynchronous. As far as i know only AMD has that problem and not any other vendor from mobile or standard computing. Something is missing from Radeon Hardware.

[mr_tawan]

Pretty much off-topics, Ryan Gordon (SDL, icculus) has some interesting way to describe Vulkan. He wrote :

Okay, here's a wild oversimplification that is likely to make OpenGL implementors' heads explode, but this is the best way I can explain the value of Vulkan/Metal/Mantle/DX12 to you.

If you have a recent Intel GPU on Ubuntu 14.10, this is exactly the code that runs deep deep deep in the core of Mesa when you try to draw a triangle with OpenGL:

http://cgit.freedesktop.org/mesa/mes...b12b1da06#n645

Line 645. See that for-loop? It cycles through a bunch of "atoms," which in this case means "small units of data we want to push to the GPU." One function pointer is called for each atom in that loop. One might set a new fragment shader, another might upload a buffer of vertex data to the GPU, or change the viewport state on the hardware, or whatever. The draw call I'm looking at in Unreal Engine 4 at the moment has 54 atoms to run through.

To get to this for-loop after you call glDrawArrays(), an enormous amount of code runs. The GL validates all sorts of stuff, it updates a bunch of internal state, it goes through various checks where various GL extensions might conflict or your GL target might not offer features you are trying to use.

For Vulkan? Some of this work will move into your app (and won't need to run on each draw call!), but more or less? Delete everything from the driver but that for-loop.

And then delete the if-statement inside that for-loop, too.

https://plus.google.com/+RyanGordon/posts/aWzbUSTd7zU

[humbug]

Async compute, eh? And that game doesn't even use that much of it? Imagine the coming titles. Maybe The AMD Renaissance is coming! At least on Windows.

Vulkan does the same thing. So it's not tied to windows.

[kalrish]

First off, from what I've been able to glean, Vulkan is a lot more than SPIR-V, just as GL is a lot more than GLSL. Secondly while the nouveau codegen lives inside mesa, it is in no (significant) way attached to it. The conversion would be from SPIR-V to nv50 ir (don't let the name fool you, it's not nv50-specific, just the name of everything in there), not to TGSI.

r600/sb also has a separate IR and is also fairly separate from the rest of mesa -- would need to create SPIR-V -> sb ir adapter for it as well.

Once the basic SPIR-V parsing is available, the adapters are likely to be moderately simple to create. (Probably a week or two's work for someone who knows what's up.)

Thank you. It's nice to hear that! I didn't mean to reduce Vulkan to SPIR-V, though (just speculated on which changes supporting Vulkan would require).

[kalrish]

There was something on the mailing list about it a while ago. I'm pretty sure it was Chris Forbes, but don't hold me to that.

It was just one or two messages mentioning that it was happening, no details on how it is going or anything. I assume everyone is being quiet about it since Vulkan is still under NDA inside Khronos.

Thank you.

[liam]

Or simply Nvidia Hardware "driver independent" takes Synchronous graphics and operates on them as Asynchronous tiles. AMD Hardware operates them as Synchronous bulk input and output, so you need to write them Asynchronous. As far as i know only AMD has that problem and not any other vendor from mobile or standard computing. Something is missing from Radeon Hardware.

Maybe. What we know is that nvidia doesn't seem to do as well as gcn with these dx12 benchmarks (Ashes hasn't been there only example).

edit: BTW, I don't own stock, contribute code, or own any nvidia/amd hardware (aside from what's in my consoles)