EXT_provoking_vertex: only exposed if `FIRST_VERTEX_CONVENTION` is *more* efficient, or *at least* as efficient?

[autumnontape]

It's great to see EXT_provoking_vertex as a draft extension already! I may volunteer to implement it in Firefox, and there's one line I want to draw attention to:

Implementations SHOULD only expose this extension when FIRST_VERTEX_CONVENTION is more efficient than the default behavior of LAST_VERTEX_CONVENTION.

I know of three types of platform API that WebGL2 may be layered over:

• One API that only supports LAST_VERTEX_CONVENTION, i.e. OpenGL ES. With the current wording, it's clear that this extension should not be exposed here.
• APIs that only support FIRST_VERTEX_CONVENTION natively, where the default LAST_VERTEX_CONVENTION must be emulated, i.e. Direct3D and Metal. With the current wording, it's clear that this extension should be exposed here.
• APIs that support both vertex conventions natively, i.e. Vulkan (when VK_EXT_provoking_vertex is available) and desktop OpenGL. This is where it gets a bit awkward.

In the last type of API, an application developer can currently expect both conventions to be equally efficient. But in the case of OpenGL, where both conventions are core and must be implemented regardless of their efficiency, this might not always be the case. The first-vertex convention has won out among current-generation graphics APIs, including Vulkan and WebGPU. I know of one currently existing OpenGL driver that emulates LAST_VERTEX_CONVENTION, Mesa's d3d12 driver, and none that emulate FIRST_VERTEX_CONVENTION. I don't think it's likely that this trend will reverse.

From an implementor's perspective, exposing EXT_provoking_vertex above the last type of platform API (and implying to apps that FIRST_VERTEX_CONVENTION should be preferred) seems like a safer bet to me than not doing so.

Of course, one counterpoint to this from a standards perspective is that leaving Android (where I believe WebGL is still usually layered over OpenGL ES, and certainly so on non-Vulkan-capable devices) as the only major platform without this extension would put it in an awkward position.

[kdashg]

"strictly more efficient" was the intent.
We only want to expose it if it is valuable.

[autumnontape]

I wanted to draw attention to whether it would be easier for implementations to comply with advice to expose the extension if and only if FIRST_VERTEX_CONVENTION is no less efficient than with advice to expose it if and only if it's strictly more efficient, but if you're not concerned by that question, I don't object.