[Mesa-dev] (intel) looking for opinions on how to deal with UMS/CMS differences in ARB_texture_multisample

[Paul Berry]

Cc-ing mesa-dev--I don't want to make this design decision in a vacuum.

For those entering the conversation, the question on the table is how to
make ARB_texture_multisample deal with the fact that on Gen7, compressed
(CMS) and non-compressed (UMS or IMS) multisampled surfaces require a
different set of sampler messages to be used.  My opinion is below.


On 23 January 2013 01:51, Chris Forbes <chrisf at ijw.co.nz> wrote:

> I've been looking at possible workarounds for this, and noticed that
> there's an otherwise unused value plumbed through from surface state
> to the sampleinfo message - the `sample position palette index`, whose
> only purpose is apparently to be exposed in sampleinfo. Assuming the
> sampleinfo message works and has acceptable latency, we could expose
> the mode to the shader through this.
>
> Otherwise, in order of decreasing desirability, I think the options would
> be:
>
> - Plumbing through a magic uniform (r600 has some cases where it has
> to do horrid things like this, to w/a a buggy resinfo)
> - Generating specialized shader code based on the modes actually in
> use for whatever is bound to the samplers, and just make apps suffer
> if they force us to generate lots of variants
> - Forcing the mode for multisample textures based on sampler type --
> it looks like we'd be forcing UMS always for isampler2DMS and
> isampler2DMSArray to work around the SINT+CMS errata.
>
> Thoughts?
>

I'm not comfortable using the "sample position palette index" for this
purpose without some further research to try to figure out what purpose
this hardware feature was intended for.  In my experience, it's rare for
the hardware designers to give us anything for free, especially if it costs
transistors (and this feature likely does), so it's likely that there is
some feature in OpenGL (or an extension) that these bits were intended for.
 If we co-opt the bits for our UMS vs CMS workaround, we'll be painting
ourselves into an awkward corner for when we need to use the bits for their
intended purpose.

(Then again, it's always possible that these bits are only needed for a
DirectX feature that doesn't exist in OpenGL, in which case we might be ok
after all.  But without further info I'm worried.)

As for the other options, my preference is for "generating specialized
shader code based on the modes actually in use".  Although we don't like
having to recompile shaders based on GL state, we have all the plumbing
necessary to do so, and the chances of a recompile happening in this
particular case are really low, so in all likelihood this option will give
us the best performance.

Paul


>
> -- Chris
>
> On Wed, Jan 23, 2013 at 6:30 PM, Paul Berry <stereotype441 at gmail.com>
> wrote:
> > On 22 January 2013 20:59, Chris Forbes <chrisf at ijw.co.nz> wrote:
> >>
> >> This might be problematic --
> >>
> >> The IvyBridge PRM Vol 4 Part 1 p77 says that if RENDER_SURFACE_STATE
> >> dw6.0 (MCS Enable) is 0, the MCS surface may still be accessed by
> >> ld_mcs.
> >>
> >> -- Chris
> >
> >
> > Oh, argh.  Well spotted, Chris.  I think this puts the nail in the
> coffin of
> > my hopes that we could use the same code for UMS and CMS surfaces :(
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130123/eee8f707/attachment.html>