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"
parameter>
<NV_explicit_multisample: New multitexture texture renderbuffer command
prefixes "Multi" before "Tex" and add an initial "enum texunit"
parameter (to identify the texture unit)>
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.
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
ActiveTexture(…);
BindTexture(TEXTURE_RENDERBUFFER_NV, rt);
TexRenderbufferNV(TEXTURE_RENDERBUFFER_NV, rb);
// 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)