Vulkan-docs: Can we have extensions for additional primitive typologies exposed ?

[Degerz]

I would like to have VK_EXT_Line_Loop exposed as in GL_LINE_LOOP. Can we also get VK_EXT_Polygon as in GL_POLYGON ? I would also like to have a multi-vendor version of VK_NV_fill_rectangle as VK_EXT_Rectangle_Lists as well where the whole bounding box of the three vertices are rasterized.

I know all three desktop hardware graphics vendors such as AMD, Intel, and including Nvidia can support all these additional primitive typologies so it would be very much appreciated if we can get extensions for them!

As for mobile hardware graphics vendors when I examined their open source drivers, I believe both ARM and Qualcomm can support line loops. Where I think they are different in this case is that support for polygons (in additions to quads) are mutually exclusive to ARM hardware and support for rectangle lists are mutually exclusive to Qualcomm hardware ... (representatives from either can feel free to correct me on this information)

[TomOlson]

@Degerz, those primitives (especially polygons) are not common in modern APIs. It's certainly possible to add them, but there is significant cost. Right now, we don't see a compelling need; do you have specific use cases in mind, where supporting these in the driver (rather than the app) would be a significant win?

[Degerz]

@TomOlson Thanks for the response!

Support for line loops and polygon primitive typologies aren't all that compelling since their mostly for compatibility or emulation purposes but the main reason to have them is to avoid the CPU overhead of having to generate an index buffer for every draw call in the case that these primitive typologies are used with indexed draws and primitive restarts. The working group are considering adding in quad lists and quad strips typology for similarly previously mentioned reasons. CPU overhead is a sore spot for relatively modern game console emulation so not having to generate an index buffer for every draw call would be a noticeable performance win in that case. Is it still a possibility that we'll be able to get these primitive typologies as an extension just like quad lists/strips ?

As for rectangle lists, these are ideal for GPU font rendering since it's useful to avoid generating extra fragments along the interior edges to sidestep the double shading issue. It would be very useful in the case of the Slug library where glyphs are represented using a bounding box. There's vendor extensions from both AMD (only D3D11) and Nvidia exposing this functionality and even console APIs have it as well so it would be very nice if we could get this as a multi-vendor or a standardized extension in Vulkan.

[TomOlson]

@Degerz, we discussed again internally. The argument for adding quads is that there are a lot of CAD modelling and visualization renderers that have them wired pretty deeply into their representations. A number of them are considering moving to Vulkan, and we'd like to make that easy for them. (On the other hand, all known implementations turn quads into triangles under the hood, and you can argue that Vulkan should just expose the hardware.) Line loops and polygons are as you say more niche, and the hardware guys would rather you didn't use primitive restart for the reasons described by @magcius in #878, so they are a pretty low priority.

We've had other people ask about rectangle lists, and with your request we're raising the priority. There's no draft yet and I can't give you a timeline, but it is definitely on the radar. The big problem with it is that everyone's hardware does something different, so it's challenging to find something that is both useful and widely supportable.

The working group has an internal tracker for rectangle lists, referencing this and the other requests. Up to you whether to close this issue or leave it open, but TBH we're unlikely to do anything with other topologies unless a lot more use cases turn up. But we won't forget that you asked. Thanks for your input!

[magcius]

It might be worth investing in a small, optimized CPU library that others can reuse that generates an index buffer for non-standard topologies. I'm unsure if a compute shader implementation would be worthwhile but it might be helpful for emulation cases where CPUs are already constrained.

I'm of the opinion that one of the things that made OpenGL so difficult was that there were a large number of mediocre options and staying on the driver's fast path required more tea leaf reading than engineering, and I'd hate to see Vulkan make the same mistakes just to please ISVs who don't want to invest in modernizing their renderer.

[Degerz]

@TomOlson Thanks for the heads up ...

It's slightly disheartening that the working group isn't considering exposing line loops or polygons but I can understand why their undesirable features among the hardware people especially with primitive restart. For cases where primitive restart isn't emulated on other hardware with these topologies, it's still very helpful CPU performance wise to not generate an index buffer from from the CPU side.

Awesome news to hear about the working group going towards exposing rectangle lists though! As long as the resulting AABB of the triangle/diagonal line is rasterized without generating the interior edges then I'm a happy camper. If we have to specify a full 4 vertices as the lowest common denominator because some other hardware vendor's implementation rather than 3 (AMD/NV) or possibly even 2 vertices in some hypothetical hardware implementation cases then that's fine. The working group doesn't even have to expose extra modes or other functionality and we can leave vertex attribute interpolation undefined as well. The only deal breaker would be is if the hardware implementation was generating extra fragments along interior edges because at that point the main benefit of exposing rectangle lists to avoid the double shading problem is gone.

I'll leave the issue open as is until an extension for rectangle lists is released but you can feel free to close this issue as well once that happens. If the working group can reconsider their stance for adding in the other primitive topologies then it would be helpful if you can provide a notification or an update here in this issue and you can close this issue immediately altogether.

[ReinUsesLisp]

On the other hand, all known implementations turn quads into triangles under the hood

As far as a I know from my experience on low-level Nvidia GPUs emulation, quads, quad strips, line loops and polygons are all handled in hardware and not in the driver. I'm not talking about a compute shader invocation or a CPU conversion, rather a fixed pipeline feature in hardware capable of processing these primitives.

[Degerz]

@ReinUsesLisp I think he might be talking about the setup engine rather than what the drivers are doing. For quad lists/strips and polygons, the hardware can purely accept them as inputs inside the vertex buffer without having to pre-transform them into triangles with an index buffer but what happens underneath inside the hardware is that those primitives will just get decomposed into triangles since the rasterizer can only generate fragments using 3 edge equations.

The working group would much rather prefer it if developers used Vulkan just like D3D instead where there are no uncommon primitive topologies as seen in OpenGL since there is fundamentally no performance benefit on the GPU side to using them which is certainly the case since there is no known hardware implementations of a rasterizer which can generate fragments from an arbitrary number of edge equations.