NVIDIA Blogs About The Beauty Of Vulkan

[DrYak]

What you see here is the birth of Nvulkan. The Way It's Meant to be Played™.

That's what frightens me.

Indeed, on first look, Nvidia's actions seems nice (let's give more tools to make life of the poor future vulkan developpers easier).
But there's a high risk that, because of the Nvidia-specific proprietary tools and extensions, Nvidia becomes the default-to-go platform when developping games (because it has all these nice tools) and AMD becomes an second-grade/after-though platform (the things you port your vulkan stuff once you've finished developping it with the nice NV tools). That AMD will get less tested, and less debbugged because of this.
And eventually, that devs will end up coding for the quirks and peculiarities of Nvidia instead of coding to the standard. (= this has been reported to already happen in the current crop of API. Some of the "buggy driver" problems of AMD aren't as much actual bugs in the drivers, but games that expect the bugs and standard-violating behaviour found on Nvidia drivers).

It would be very ironic if that comes to be, given that Vulkan has basically been built upon the ground work of AMD's Mantle.

[theriddick]

The second someone figures out howto hack in freesync with Nvidia cards, I will jump ship most likely. AMD is continuously in perpetual disappointment mode for me when it comes to driver feature and performance, their latest info about slacking off on supporting GCN 1.1 cards is mighty disappointing!

[bridgman]

With respect, we didn't say anything about not supporting GCN 1.1 and Michael didn't say anything either. All he said was *if* our future Vulkan support turned out to be limited to just the chips supported by *default* in upstream amdgpu today then that would be just VI and up.

Please read the article again.

[bridgman]

Aww, this is getting stupid. Every second post I make is going into the moderation queue. Then I get:

This forum requires that you wait 30 seconds between posts. Please try again in 1 seconds.

Auggh !!

Anyways, theriddick you are reacting to something that neither AMD nor Michael actually said. Michael is trying to stir up some controversy, since that's what people like to read, and he's doing a good job of it. The trick is to enjoy the controversy but read critically so you don't end up believing something that wasn't said.

[theriddick]

We will see...

[artivision]

Nvidia slowly does the simple thing to run state trackers (OGL) upon Vulkan. That is something MESA must also do and let Gallium go. Also OGL have the sub-function for a mainly OGL game, to directly target a lower level for some shaders, like Vulkan or ISA (ARB_get_program_binary).

[mike4]

Looking forward to play Flightgear etc. with some Vulkan aside OpenGL while using both my Intel and Nvidia graphics simultaneously.

[DrYak]

Nvidia slowly does the simple thing to run state trackers (OGL) upon Vulkan.

...which isn't that much different than what Mesa does, running a GL state tracker (handles lots of complex processing) above Gallium3D (low lovel back-end that simply expose the hardware functionnality which is available on the hardware

That is something MESA must also do

As said, they are already doing it.

and let Gallium go.

Huh... how about: nope.

I'm not a big expert in gpu drivers, but from what I've gathered:
- vulkan is a rather recent low-level api that targets quite a specific set of hardware feature. Not every single legacy card that is currently supported by a gallium3D back-end can actually run vulkan (and I mean technical limitation, not just "we didn't target that family of hardware because we concerntrate our limited ressources on higher priority targets.
- that would also make Mesa dependant on the presence of a vulkan driver. which means needing either depending on a closed source 3rd party library (good luck hoping that Nvidia's Vulkan implementation will be anything but closed source), risking needing to write your own straigh vulkan-on-bare-hardware implementation (say if, eg. ADM doesn't provide same-day GCN 1.1 family support).
- whereas Gallium can work with anything modern enough (anything with programmable vertex and pixel shaders).

Which means throwing the whole Gallium stack right now would be a very bad idea, because that would be throwing away support for tons of GPU still in wild (and that's including older ATI/AMD GPUs for which the opensource radeon driver *IS* the official recommended one).

At best, for the time being you could see *A* Gallium3D back-end that runs on Vulkan (being a simple vuklan-to-gallium translation layer. Which is possible given that both are supposedly similarly low-level).

(It's kind of the same situation while Virtual Machine need to implement openGL pass-through and can't only count on having the inner openGL state tracker communicating with the host back-end : not everyone runs gallium, and some would like 3D acceleration with closed source drivers).

Then maybe several years down the line, once pre-vulkan hardware is as rare as purely-fixed-pipeline GPUs are today, then mayber Mesa will move from gallium back-ends to vulkan back-ends. But for now, it simply doesn't seem reasonnable.

[SystemCrasher]

So, nvidia is all about vendor locks and overengineered halfassy crap. Sure, it would be stupid to doubt it, even for a second. All hail M$ of GPU world.