[Mesa-dev] [PATCH 1/3] gallium: add basic support for ARB_sample_shading

Ilia Mirkin imirkin at alum.mit.edu
Tue Apr 1 07:42:02 PDT 2014


On Tue, Apr 1, 2014 at 10:25 AM, Roland Scheidegger <sroland at vmware.com> wrote:
>> guidance. Also FWIW, gl_NumSamples gets converted to a constbuf lookup
>> somewhere upstream of mesa/st (I was a bit surprised by that). Perhaps
>> the sample position should be as well? Or is nvidia hardware unusual
>> in not having an instruction to look up sample position?
> I don't know the latter but I suspect the gl_NumSamples being a constbuf
> lookup is a bit a limited solution (since in d3d10 you can query
> resources that way, and they can of course have different number of
> samples - I'd not be surprised if some hw could get that number directly
> neither. Though for d3d10 needs we could always do something completely
> different for asking sample position of rasterizer vs. asking sample
> position of resources.

Yeah, on nvc0+, there's the pixinfo/pixld instruction which can look
up various information about... some object, like sample count as
well. Presumably to match d3d10. (Still no clue how to use it to query
rasterizer state.) But gl_NumSamples is a uniform, and so is
gl_SamplePosition (well, a uniform array indexed on gl_SampleID). So
one way we can defer this question is to just treat it as such in
mesa/st, and then gallium never needs to know about sample pos in the
first place, only gl_SampleID. But I'm not sure if mesa/st is set up
to do stuff like that, or if it would be an intrusive change. On nv50,
we use that for a few things already (texture ms info for sampler2DMS,
user clip planes, a few other oddities).


More information about the mesa-dev mailing list