Vulkan-docs: Extension for vertex shading and input (uint8 index, topology, barycentrics)?

[elviras9t]

I want to suggest some things into one of extension for Vulkan API...

1. Add new VK_INDEX_TYPE_UINT8_EXT (= 2) type for index buffers (NVIDIA RTX can be supported it)
2. Add new VK_PRIMITIVE_TOPOLOGY_QUAD_LIST_EXT topology (if can be supported by hardware)
3. Merge barycentric support (from NV and AMD) into this extension, as any form of vertex extensions
4. Add device properties extension for that extension's

[ReinUsesLisp]

Quads and u8 indexes would be very useful on Nintendo Switch emulation - games using OpenGL or NVN can (and do) use them since it's natively supported in Maxwell hardware. Aside from VK_PRIMITIVE_TOPOLOGY_QUAD_LIST_EXT, there should be a VK_PRIMITIVE_TOPOLOGY_QUAD_STRIP_EXT.

Without these features we are forced to manually assemble the new indexes on the CPU - a task that's not only slow since it has to be done every draw call but it can also become a bit tricky when there are primitive restarts on uint8 indexes using quad strips.

That being said, AFAIK this was intentionally left out of Vulkan due to it being based on OpenGL ES 3.2 hardware where these is not mandatory.

I'd be grateful on seeing an EXT_ extension (or two, since they are unrelated) adding support for quads/quad strips and uint8 indexes.

[Degerz]

Can we please get a response on this issue from the working group ?

I can understand why Vulkan's limitations were modeled after OpenGL ES but isn't it a little bit of a ridiculous oversight how we don't have an equivalent GL_UNSIGNED_BYTE for indices in Vulkan especially since the feature is available in core OpenGL currently ?

As for quads, I realize they were deprecated a long time ago in OpenGL. With Vulkan, however I believe things will be different this time in terms of maintenance so there's no good reason anymore to not include quads into the API as an extension since all three current desktop graphics vendors (AMD, Intel, and Nvidia) have hardware support for them ...

Could the Vulkan working group willingly come to a compromise on behalf of the community to deliver these features just like it did before for transform feedback support ?

[pdaniell-nv]

I think these are valid and useful requests. I will investigate at a minimum a vendor extension, but will hopefully get support for a multi-vendor EXT extension.

[Degerz]

http://terathon.com/i3d2018_lengyel.pdf

Here's another use case for quads which is useful for doing GPU font rendering. As you can tell starting from slide 67 and onwards, he basically represents the glyph's bounding box as two triangles with an index buffer. The issue that arises by representing glyphs as two triangles instead of a quad or a rectangle causes double shading along the interior edges which makes makes the fragment shader more expensive. The cost of fragment shading becomes even more expensive as you go down rendering smaller font sizes ...

Conservative Rasterization + Quads/Rectangles makes for a very powerful combination in GPU font rendering ...

Note: Rectangle primitive is special in comparison to quads in that you only need to specify 3 corners compared to 4 corners ...

BTW, AMD has a D3D11 driver extension for exposing quad lists and screen rectangle primitives. There's also NV_fill_rectangle which is exposed in every API but that's different since it changes the rasterizer's mode to do a point in quad test rather than a point in triangle test instead of exposing raw quads as primitives and AMD also supports a subset of the extension's functionality AFAIK ...

Quads would also come in handy when doing particle/billboard/UI rendering as well ...

[magcius]

QUAD_LIST / QUAD_STRIP will not help the overdraw that Eric mentioned. API-level Quads are basically an alternate way to specify triangles. NV_fill_rectangle is a different feature that rasterizes the resulting screen-space bounding box of the transformed geometry. It has different tradeoffs from rasterizing the triangle itself.

I am not opposed to exposing this as a vendor extension, but you already need a fallback path for vendors that cannot support it. Topology conversion should be relatively fast on the CPU.

[Degerz]

You're right, quad list/strip alone doesn't change the fill mode but at least we won't need an index buffer for glyphs or particles ...

[magcius]

Why are you opposed to generating an index buffer?

[Degerz]

For disjoint quads like in the case of glyphs you shouldn't have to use an index buffer to emulate a quad when all hardware can likely consume quads as is and it's easier this way for the developer ...

I think a cross vendor quad fill mode (AMD & NV) is more necessary though as it would help in eliminating the double shading along the interior edges when rendering glyphs using a quad ...

[ReinUsesLisp]

@magcius with that argument we wouldn't need triangle strips or triangle fans since we can just convert them on the CPU.

[magcius]

That argument is more convincing than you might think. Primitive restart removes the ability for GPUs to process the index stream in parallel; it has to serially parse through it since the number of vertices in a single patch isn't a constant size. On some GPUs a compute shader is used to transform the topology to a triangle list before running the draw.

This is getting a bit off topic though. I'm not opposed to adding quads as a vendor extension for emulation purposes.

[Degerz]

@pdaniell-nv What's the internal status of these extensions within Khronos ? Has the issue been raised yet and if so which of these extension(s) are garnering multi-vendor support ?

[pdaniell-nv]

Both uint8 indices and quad topology are making their way through the working group. If all goes well they’ll be out in a month or so.

[Degerz]

@pdaniell-nv Will the quad topology extension also include quad strips as well ?

Great work BTW!

[Degerz]

I found some interesting information. Only 3rd generation GCN GPUs will be able to natively support uint8 indices in hardware so if the extension does release then it'll end up likely being emulated on prior GCN generations or not exposed at all on Vulkan. I guess this answered my question of why AMD's Mantle API didn't expose uint8 indices ... (quad lists/strips are supported through)

[Degerz]

@pdaniell-nv Thanks to the working group for exposing uint8 index type but what's the hold up with quad lists/strips ? Can we get an ETA for them as well ?

[pdaniell-nv]

Quads is taking a little more time because it's a little tricky to specify precisely in a way that'll work for all vendors. It's hard to put a precise ETA on it, but we're working on it. Hopefully soon.

[Degerz]

@pdaniell-nv Thanks, hopefully quads in Vulkan will be as powerful as they are in OpenGL compatibility profile with the same functionality as well. If that behaviour can't be standardized, I sincerely hope it can be made optional.

[FernandoS27]

@pdaniell-nv Thanks for the update. They are heavily needed by many CAD programs, hope you guys figure it out.

[Degerz]

@pdaniell-nv I can't help but wonder since it's almost the end of this year but can we get an update on how the quad topology extension is progressing inside the Vulkan working group ?

Can we expect the functionality to land in by early next year ?

[pdaniell-nv]

The extension is currently stalled, mostly because I've not been able to work on it due to higher priority stuff. No ETA at this time.