Gpuweb: Should we have a core "stencil8" format?

[kainino0x]

It would have to be emulated in a lot of cases. (According to #211, it is not available on D3D. It is not required in Vulkan. It is always available in Metal.)

[kvark]

As someone who suggested this previously, I think there is a good value in "stencil8". In some cases (like 2D drawing) the application needs stencil but doesn't care about the depth. On many (if not most) platforms by requesting "stencil8" they would get exactly that. On some platforms, they'd actually get "Depth24Stencil8".

[litherum]

Right, NV_path_rendering uses the stencil buffer, but not depth. That's a pretty important use case.

In Metal, it's best practice to split the depth texture and the stencil texture into distinct textures if they are going to be accessed separately (rather than using views).

Surely it can be emulated on D3D. I guess the effect would be that stencil8 textures use 4x as much memory as the developer would expect there.

[kvark]

Wanted to reflect the suggestion from the meeting: have a query for the format size, in addition to exposing Stencil8. Users would be able to make decisions on what format to use, and it would help to Depth24Plus formats as well.

[kainino0x]

Discussed in meeting.

I am currently leaning toward Jeff's idea of having an x_stencil8 (née x0plus_stencil8) in core, and a stencil8 extension. The stencil8 extension is strictly better than an x_stencil8_format_is_compact flag because it lets us expose additional capabilities as well. It also mirrors how we intend to expose various concrete depth formats.

That said, I'm interested in Dzmitry's suggestion above too, possibly in addition.

In the meeting I forgot there is no X24S8 format in D3D12. There is only D24S8 and D32_FLOAT_S8X24. We would be emulating on D24S8. So I'm pretty sure there's no possibility that D3D12 drivers are implementing a compact S8 format in any case. (All the other relevant formats are typeless so I don't think it's possible for them to "compress" away the remaining storage.)

[kainino0x]

If there's no additional functionality that would be enabled by a concrete-stencil8 extension, Dzmitry convinced me that an extension would be worse: Applications could be written to require the extension, when really they shouldn't (they would work fine with x_stencil8).

Queries for format sizes for depth24plus-* and x0plus-* would be fine with me.

[kainino0x]

Discussed again: resolution: have an x-stencil8 format (name tbd) and a way to query the size of x-stencil8, depth24plus, and depth24plus-stencil8.