Vulkan 1.0.12 Specification Update Adds VK_AMD_rasterization_order

[VikingGe]

I bet this will evolve into a KHR extension (or whatever official Vulkan extensions are called) some time soon. No reason to rely on vendor-specific extensions, just view it as a draft/proposal for the future.

The name suggests that this is the counterpart to Dx12's ROVs. Vulkan doesn't expose that kind of feature yet (which is funny because OpenGL apparently does have such an extension already), so it's pretty much a given that other vendors (at least Nvidia and Intel) will want to support it somehow.

[mdias]

struct VkPipelineRasterizationStateRasterizationOrderAMD

Dear lord

This is 1000x better than:

struct VkPRSROAMD

or tens of single-letter variable names in the same scope as is commonly found in the wild.

[haagch]

Khronos launched the Vulkan 1.0 specification on February 16th, 2016 and Khronos members released Vulkan drivers and SDKs on the same day.

A really soft launch...
Still only one full game with Vulkan support and it's just now beginning to take advantage of more advanced Vulkan Features.

Valve still hasn't managed to push Dota 2 with Vulkan out. Are they really just waiting for the scaleform UI? They are one of the most profitable companies in the sector. Just give them a ton of money to do that FFS!

Drivers...
After I mentioned LunarG's hologram demo not working, someone from intel looked at it and fixed it: https://github.com/LunarG/VulkanSamples/pull/73, thanks for that. Now it runs on ivy bridge... with glorious 5 fps while slowing down the X server a lot - which is what they will be looking at next. I also heard there's something in the works which will hopefully help with the "Cannot obtain 'vkCmdCopyQueryPoolResults()' device function" error that The Talos Principle produces on ivy bridge. Also vkcube, one of the simple demos, is currently broken on at least haswell and ivy bridge.

Meanwhile AMD is hoping to get the first public code out in the next couple of weeks for support SI in amdgpu and hopefully Vulkan support.

Looks like many, many consumers will still have to wait at least "a couple of weeks" before they can get anything at all out of Vulkan.

[Kano]

I think an Intel dev mentioned problems with glslang, out of spec SPIR-V does not work with Intel. Talos Principle uses this translator. So there are 2 ways to fix, optimize glslang or allow some "bad" code. But Vulkan is certainly progressing with small steps every week, let's see when 1.0.x jumps to 1.1. Maybe after 40 weeks or every year 1.a.b - a yearly, b weekly increased...

[VikingGe]

Kano do you happen to have a link or something or do you recall what exactly the problem was?

I mean, SPIR-V should be treated like any other shading language - driver gets the code, translates it to its IR and optimizes the hell out of it. If this works with GLSL, I don't see why it shouldn't work with a language that can actually be represented by GLSL.

VkPipelineRasterizationStateRasterizationOrderAMD

Well, at least it's consistent with the rest of the API, and the name immediately tells you what it is for. This isn't even comparable to Java's infamous AbstractSingletonProxyFactoryBean.

[1ace]

Step 1: vendors implement whatever the hell they want using a prefix like SGI_, IBM_, ATI_, NV_, etc. (Look at the "Vendor and EXT Extensions by number" section in the linked page)

FYI, SGI (SIlicon Graphics, Inc.) are the original authors of OpenGL, before it was handed over to Khronos 10 years ago

[Kano]

@VikingGE

Look at the bug marked issues:

https://github.com/KhronosGroup/glslang/issues

[nomadewolf]

Yeah, and there was exactly nothing about Nvidia's extensions that made them Nvidia-only either. But that didn't stop the usual suspects from screaming about how Nvidia was going to single-handedly kill Vulkan.

You cannot kill what is already dead!

[ssokolow]

FYI, SGI (SIlicon Graphics, Inc.) are the original authors of OpenGL, before it was handed over to Khronos 10 years ago

I'm aware of that. They may have created OpenGL, but they still chose to produce vendor-prefixed extensions as evidenced by the list I linked.