NV_explicit_multisample specification

Does anyone know where I can find this specification?

It is part of the 180.10 leaked drivers…

From EXT_direct_state_access:

<NV_explicit_multisample:  New texture renderbuffer object command
replaces "Tex" in name with "Texture" and add initial "uint texture"
    void TextureRenderbufferEXT(uint texture, enum target,
                                uint renderbuffer);
<NV_explicit_multisample: New multitexture texture renderbuffer command
prefixes "Multi" before "Tex" and add an initial "enum texunit"
parameter (to identify the texture unit)>
    void MultiTexRenderbufferEXT(enum texunit, enum target,
                                 uint renderbuffer); 





Well, I can’t say that I like that extension. The entire point of a RenderBuffer was that the driver knew that you could not use it as a texture. NV_explicit_multisample allows that.

It would have made far more sense to allow multisample as part of the internal format of a texture.

Eeek, this looks ugly. It does not support 2D multisample texture arrays,as DX10.0 does. But it contains access to the sample position, which is a DX10.1 feature. Strange blend.

It does not support 2D multisample texture arrays

That’s because it doesn’t support multisample textures. It merely allows you to bind a buffer object to a sampler.

Don’t have the 180 drivers to tinker with it, but the basic usage pattern seems to be something like…

// Create texture for sampling
uint rt;
GenTextures(1, &rt);

// Create MSAA renderbuffer with desired size, format, samples, etc …
uint rb;
GenRenderbuffers(1, &rb);

// Render to rb normally …

// Now just attach texture to renderbuffer for sampling

// Sample in GLSL using texelFetchRenderbuffer((i|u)samplerRenderbuffer sampler, ivec2 coord, int sample)
// GetActiveUniform returns type of (INT_|UNSIGNED_INT_)SAMPLER_RENDERBUFFER_NV

Seems to me it’s just a temporary binding of a texture and a renderbuffer - temporary mapping of the buffer object
for the purpose of sampling only (as Korval pointed out).

For arrays it looks like we’d need something like samplerRenderbufferArray… (I smell an extension here)

I smell an extension here

I hope not. This is a crappy way to expose this functionality, and I would hope that the ARB abandons it in favor of something more reasonable.