Making Use Of Vulkan's Validation Layers

[juno]

Not having insider infos, but I'm saying no.
They started porting their engines before the spec was even open to the public. Now they have the final, official spec and they work on their own implementation being conformant, then it will work with conformant hardware/drivers. And of course, they could have been testing with the other IHVs' hardware.

[bug77]

Honest question, because I do not know: Is not passing the conformance test an issue for game devs, that stops them from starting to port their engines or test their games?

No, but it's annoying as hell when you can't tell whether something does not render right because of the driver or because you did something wrong.

[kpedersen]

they are teaching game devs, who already have access also to the linux driver as AMD said multiple times here in the forums.

I work for a game development company. But no, we do not want any AMD binary linux drivers near our test machines thank you very much .
The NVIDIA binary is the best of a bad bunch but I sure am looking forward to the day everything supporting Vulkan is open-source and in the Linux kernel

[juno]

we do not want any AMD binary linux drivers near our test machines
[...]
I sure am looking forward to the day everything supporting Vulkan is open-source and in the Linux kernel

So you are telling me you are developing games and not testing on ANY AMD hardware during the development ever?

Vulkan in Linux kernel? I think not. That is clearly userspace-stuff.

[kpedersen]

That is clearly userspace-stuff.

Nope. Drivers that Vulkan can interface with obviously need to be in the kernel (or kernel module if being pedantic).

So you are telling me you are developing games and not testing on ANY AMD hardware during the development ever?

?.. Nope..
Avoiding catalyst drivers != Avoiding AMD hardware

Open-source drivers exist for AMD hardware and they are our priority. Besides, the proprietary catalyst drivers are now being deprecated in common Linuxes like Ubuntu so we see little point (https://www.phoronix.com/scan.php?pa...Dropping-fglrx).

[rabcor]

Relax guys, I was just poking fun at 'em. I don't mind the driver release being a bit late since as people have said there is no end-user use for it yet (and I don't even use AMD; I kinda want to, but I'm stuck with green, cus I'm one of these more hardcore gamers and AMD's performance just isn't on par so far; I really want to change over though, but besides their actual performance being beneath nvidia in general, it doesn't help that their linux drivers still suck compared to the windows one)

While AMD's attitude towards Linux is significantly better than Nvidia's (can't argue against AMDGPU), up till this point their effort towards making things work on Linux aren't of the same caliber as Nvidia as can be seen from their driver performance.

[CrystalGamma]

Nope. Drivers that Vulkan can interface with obviously need to be in the kernel (or kernel module if being pedantic).

Sure, command submission has to be kernel space, but I would hope the cmd buffer construction and especially the shader compiler would be in a library …

[kpedersen]

shader compiler would be in a library …

Well the shader compiler now *is* Vulkan (https://www.khronos.org/registry/spi...WhitePaper.pdf). The intermediate form (SPIR-V) is generated by the compiler provided by Vulkan rather than the vendor specific driver. This is actually more similar to how DirectX works and reduces work needed to be done by the driver.

Quite where the device specific "bytecode" is generated from this intermediate form is done, I don't really care. So long as it is not done within the catalyst driver harhar.