Does anyone have some insight behind the “fixedsamplelocations” argument to glTexImage2DMultisample()?
Is there hardware out there now that supports using a different number of samples per pixel for rasterization? How about a different sample placement per pixel?
void TexImage2DMultisample(enum target, sizei samples,
int internalformat,
sizei width, sizei height,
boolean fixedsamplelocations);
...
If <fixedsamplelocations> is TRUE, the image will use identical
sample locations and the same number of samples for all texels in
the image, and the sample locations will not depend on the
internalformat or size of the image.
I don’t know what their driver actually reports for fixedsamplelocations, or what the sample pattern looks like.
Well, on a Fermi, GL_TEXTURE_FIXED_SAMPLE_LOCATIONS returns the same value you passed in for the fixedsamplelocations arg of glTexImage2DMultisample. And even if you are doing a custom resolve that presumes the same number of samples per texel, it is not corrupted even when you set “fixedsamplelocations” to false. In fact, the two resolves (one with fixedsamplelocations, one without) are identical.
This suggests that the number of samples per texel is probably not varying, and that the sample positions are probably not changing.
that the sample positions are probably not changing.
How would you be able to tell? If I recall correctly, I don’t think there’s a way to ask a multisample texture what the location of a particular sample is.
I think the idea behind this value is to differentiate the case of doing multisample resolve and just general texture work with multisample textures. If you’re rendering to a texture and are implementing custom resolve, you don’t care that the sample pattern may change depending on what you are rendering to.
However, if you’re doing something like fragment shader blending with multisample, it’s very important to know that the same sample pattern used to generate the texture will be used when writing out the new texels.
Also, i cant really understand why would this be texture state …
How could it be anything other than texture state? If the sample locations in a texture can vary that’s something OpenGL needs to know about that particular texture.
How could it be anything other than texture state? If the sample locations in a texture can vary that's something OpenGL needs to know about that particular texture.
This seems very counter intuitive to me.
I dont really think that texture memory layout changes with sample location setting (no reson why should it), so the only change when using fixed and non-fixed textures is actually the operation of fixed functions that cares about sample positions.
Why is this fixed function controlled by parameter passed to texture???
Texture itself doesnt care (unless im missing something), and this state really belongs to context (kinda-like per sample shading operation).
Now i can imagine somebody could make up different texture layout for non-fixed textures where each pixel holds additional data for samples offsets, but that just feels like sci-fi.
I dont really think that texture memory layout changes with sample location setting (no reson why should it)
Well, if each pixel can have different sample locations, then it could. I could see some rasterizers having 4 or 8 sample configurations, all identified by some kind of index stored per pixel.
Well, you never know without ARB giving some kind of serious rationale. Could in fact be that way. That would imply additional bandwidth consumption though.
Still seems awfully complicated to me - if its just 4/8 configs it could be more efficiently encoded with texel location & simple function.
Than again, perhaps not …
As is now, i consider it more of spec quirk, just like quirks that allow for 0 integer samples in MS textures.
Also, just out of curiosity, is there a similar feature in DX?
How would you be able to tell? If I recall correctly, I don’t think there’s a way to ask a multisample texture what the location of a particular sample is.[/QUOTE]
It is likely that different subsamples would be hit during MSAA rasterization in some pixels when you compare: 1) same # samples and sample positions with 2) different # samples and/or diff sample positions.
Yet if I capture post-resolve screenshots with each, and subtract them, the result is 0 for all pixels.
This doesn’t prove it. But given that I was drawing spheres and planes with diagonal lines not at 45 degrees and such, it suggests that we’re not getting variability in the subsample pattern between different settings of fixedsamplelocations. A better test needs a rasterization patterns designed to detect this. Something like this.