Allow for DEPTH_STENCIL_TEXTURE_MODE to be sampler state

[kRogue]

Worried that I read the specification wrong, but I think it says that DEPTH_STENCIL_TEXTURE_MODE is texture state only (i.e. not sampler state, looking at table 23.15 vs 23.18 is how I think this).

At any rate, as a convenience, make DEPTH_STENCIL_TEXTURE_MODE also sampler state. As a side note, yes one can do the TextureView thing, but the sampler methodology seems much nicer.

Along those lines, why are not TEXTURE_COMPARE_MODE, TEXTURE_COMPARE_FUNC, and for that matter all the SWIZZLE's too in sampler too?

[Alfonse Reinheart]

I'm guessing that the ARB wants to keep Sampler Objects restricted to what their D3D equivalents do. This could be for hardware reasons (sampler objects representing some fundamental piece of hardware, with swizzle state and others being a different set of parameters) or just D3D compatibility ones.

Oh, and the comparison mode is already part of sampler state. I'm not sure how you missed that, since they're the second and third entries in 23.18

[kRogue]

Oh, and the comparison mode is already part of sampler state. I'm not sure how you missed that, since they're the second and third entries in 23.18

Truly, amazingly, embarrassing. Apparently I cannot read a table :P Oh my, there are two tables I cannot read correctly: looking at table 8.21, DEPTH24_STENCIL8 is NOT in the 32-bit column. So my initial comment about TextureView is wrong too.

What the?! This is insane, one can only read a DEPTH24_STENCIL8 as either stencil or depth but not both, even if one were to use 2 texture units?! This looks like an oversight to me, not a hardware issue.... Weird.

If it truly is not a hardware issue, doubles my case for it.

[Alfonse Reinheart]

From the paragraph right before that table:

The two textures’ internal formats must be compatible according to table 8.21 if the internal format exists in that table. The internal formats must be identical if not in that table.

[kRogue]

Oops. Indeed. Note to self: writing too late at night == writing junk.

So my initial comment on TextureView was correct, so.... since one can get the same functionality via TextureView, I have a hard time believing it is a hardware issue.

Seems silly to me to make a new texture view to change how to sample data... I'd argue that anything that affects sampling that does not touch the texture data should be in the sampler object API too.

I'd bet there were flame wars internally at the ARB about it too, but I cannot really figure out a side for the current situation.

[Alfonse Reinheart]

I looked over some of AMD's documentation, and it seems that their hardware (at least up to HD 6xxx's) has a clear dichotomy of state. There is texture state and sampler state. Sampler state is exactly what OpenGL and D3D's Sampler Objects cover: the sampling state parameters passed directly to the "fetch from texture" sampling opcode.

The parameters for texture swizzle (and it's likely that stencil texturing is nothing more than a special swizzle operation) is a part of the texture or buffer object resource itself.

It's not that they couldn't change it. It's that to do so would make the implementation less practical. As it stands, a sampler object can be represented as a few bytes that get uploaded to a certain place in memory. What you want means that there has to be cross-talk when the texture object and sampler object get used together.

Admittedly, it's very inelegant, as it's exposing a hardware limitation to the user in a way that's meaningless for the user. One would expect fetching parameters like swizzles to be part of the sampler object. But due to hardware restrictions, they don't do that.