On Tue, Apr 1, 2014 at 10:25 AM, Roland Scheidegger <srol...@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). _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
