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

[utack]

VULKAN is more than "some 2% happy Linux people".
It is Steam machines and building a reputation in a whole new area.
I really think AMD will be ready.

[tuke81]

Well here's more on siggraph's next generation graphics api lessons power points, in case you missed them:

http://nextgenapis.realtimerendering.com/

[imirkin]

It seems that, in the open Linux stack, Vulkan drivers would
On the other hand, nouveau's (I'm talking about the nouveau Gallium driver) shader compiler lives inside Mesa, so it should be a bit harder to reuse it for Vulkan: it would involve not only extracting the code, but also developing a conversion pass between SPIR-V and TGSI IR (which is what nouveau's compiler takes, I think). The same would apply for any driver whose compiler backend lived inside Mesa, although it would be even harder for those who aren't part of Gallium: they would require a different conversion pass between SPIR-V and whatever IR they use internally.

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

[blackout23]

The coolest thing is that the NVIDIA driver will be able to use OpenGL and Vulkan at the same time without slowing the Vulkan side down.
Presentation was done by Piers Daniell, btw.

[justmy2cents]

Nice, I was a bit worried about when Vulkan would be supported for linux. The sooner it's available, the sooner devs will adopt it. It's a little unfortunate that only the nvidia closed source driver will support it at first, but it's better than no support at all.

I just hope mesa gets completed soon. I imagine supporting vulkan will slow down the already relatively slow development process of openGL. But, I figure a lot of the code for Vulkan can be taken directly from the existing mesa code, which hopefully will speed that up.

PowerVR demo driver for GDC was written by 2 people in 2 weeks. go figure.

[Ancurio]

Would be the other way round, in my opinion. The whole point of vulkan is simpler drivers. A lot of work is moved on the developer's hand. This might not be a bad thing in the end, since the developer then has more freedom, and doesn't has to work against the driver. But a simple triangle code is said to be ~800 lines. Of course, there will be libraries to abstract difficulties away, and the new architecture will mostly profit big engines; but vulkan might in the end be simpler to use for a classic C developer with no or little prior OpenGL experience (like me :P). Manual memory allocation, and command buffer management, for instance, IIRC.

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.

[smitty3268]

How do you know that? (I am genuinely interested: lately, I've been paying attention to the mailing list and didn't see anything, and I didn't notice anything related here either)

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.

[liam]

That's nice. It appears there might be some reason to think that gcn is a better fit for these next generation apis, however.

extremetech.com/gaming/213202-ashes-dev-dishes-in-dx12-amd-vs-nvidia-and-asynchronous-compute

[xeekei]

That's nice. It appears there might be some reason to think that gcn is a better fit for these next generation apis, however.

extremetech.com/gaming/213202-ashes-dev-dishes-in-dx12-amd-vs-nvidia-and-asynchronous-compute

I think those results is more due to AMD having a lousy DX11 implementation, and Nvidia a good one. And with DX12 the raw power of the GPUs gets released and not held back by the big inefficient driver. I could be wrong though, anyone's guess is as good as mine.

[dungeon]

IIRC, AMD hasn't supported OpenGL 4.5 yet...

I'm not sure but I highly doubt it. For openGL they only have to add a few features to reach 4.5 specifications.

By that logic, we should already have OGL 4.5.

AFAIK OpenGL 4.5 is there with Catalyst 15.7 CCC shows 4.5, fglrxinfo too... only glxinfo version shipped in Ubuntu does not completely, but git version shows it too.

Catalyst 15.7 is actually only driver for any hardware on earth currently which supports OpenGL 4.5 and OpenCL 2.0 ... also as OpenCL 2.1 will share SPIR-V with Vulkan, i think people don't have what to afraid for