On 06/12/2012 12:27 PM, Olivier Galibert wrote:
>   Hi all,
> 
> I'm getting a little lost in all the interactions between the
> different parts of the GL standards and what I understand of the
> expectations when it comes to MSAA.  It would be nice if I could have
> some clarifications.
> 
> I'll start with what I think I understand (and please correct me when
> I'm wrong) and add a number of questions.  I'll also ignore the
> "resolve" part, which isn't an issue (at least for me :-).
> 
> 
> MSAA is a variant on the supersampling theme where the coverage is
> supersampled but depth, stencil and color may or may not be.  The
> destination buffer has enough space to store the full results of a
> complete supersampling, but some of the values may be duplicated.
> 
> The variable MIN_SAMPLE_SHADING_VALUE allows the application to
> control the minimum number of values that have to be computed.  It can
> say for instance that in a 16xMSAA case at least 4 samples per pixel
> are required.
> 
> So let's take a case of 16xMSAA (say with the DX11 pattern) and let's
> look at the pipeline.  First the coverage is sampled for the 16 fixed
> positions, leaving C active samples.  Then there should be early depth
> testing then shading, or the other way around, depending on the
> shaders.
> 
> First question: how many depths should be computed, and for which
> coordinates? Which of these values is associated with which sample?

One for each sample point. The depth buffer will be multisampled as well.
Coverage sampling (CSAA) where you have extra coverage samples that do
NOT (necessarily) correspond to color sample locations are not covered
by the GL spec, it's vendor-specific.

> 
> Second question: how many samples should be shaded, and for which
> coordinates?  What is the impact of depth testing failure?

As many as the user requested via glMinSampleShading, and the sample
locations to choose seem to be up to the implementation.

If the depth test fails for all the samples associated with a fragment
shader invocation, you can probably choose not to run it, which should
not be noticeable.

> 
> Third question: what happens when a variable has a "sample" qualifier
> in the fragment shader?  Or "centroid"?

>From GL spec 4.1/3.9 Fragment Shaders:

(Sorry if quoting the spec doesn't help, since you may have read it
already, but now that I looked up the relevant parts for the questions I
probably wouldn't formulate it much differently myself.)

"When interpolating variables declared using centroid in, the variable
is sampled at a location within the pixel covered by the primitive
generating the fragment."
"When interpolating variables declared using sample in when MULTISAMPLE
is enabled, the fragment shader will be invoked separately for each (!)
covered sample and the variable will be sampled at the corresponding
sample point."

> 
> Fourth question: how does gl_SampleMask interact with all that when
> more than one sample is evaluated.  And what does gl_SampleMaskIn look
> like in the same case?

"If the fragment shader is being evaluated at any frequency other than
per-fragment, bits of the sample mask not corresponding to the current
fragment shader invocation are ignored."

"When per-sample shading is active due to the use of a fragment input
qualified by sample, only the bit for the current sample is set in
gl_SampleMaskIn. When GL state specifies multiple fragment shader
invocations for a given fragment, the sample mask for any single
fragment shader invocation may specify a subset of the covered samples
for the fragment. In this case, the bit corresponding to each covered
sample will be set in exactly one fragment shader invocation."

> 
> I hope you people can help me clarify all that stuff :-)
> 
> Best,
> 
>   OG.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to