<div dir="ltr">Cc-ing mesa-dev--I don't want to make this design decision in a vacuum.<div><br></div><div>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.<br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On 23 January 2013 01:51, Chris Forbes <span dir="ltr"><<a href="mailto:chrisf@ijw.co.nz" target="_blank">chrisf@ijw.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've been looking at possible workarounds for this, and noticed that<br>
there's an otherwise unused value plumbed through from surface state<br>
to the sampleinfo message - the `sample position palette index`, whose<br>
only purpose is apparently to be exposed in sampleinfo. Assuming the<br>
sampleinfo message works and has acceptable latency, we could expose<br>
the mode to the shader through this.<br>
<br>
Otherwise, in order of decreasing desirability, I think the options would be:<br>
<br>
- Plumbing through a magic uniform (r600 has some cases where it has<br>
to do horrid things like this, to w/a a buggy resinfo)<br>
- Generating specialized shader code based on the modes actually in<br>
use for whatever is bound to the samplers, and just make apps suffer<br>
if they force us to generate lots of variants<br>
- Forcing the mode for multisample textures based on sampler type --<br>
it looks like we'd be forcing UMS always for isampler2DMS and<br>
isampler2DMSArray to work around the SINT+CMS errata.<br>
<br>
Thoughts?<br></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>(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.)</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>Paul</div><div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-- Chris<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Jan 23, 2013 at 6:30 PM, Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> wrote:<br>
> On 22 January 2013 20:59, Chris Forbes <<a href="mailto:chrisf@ijw.co.nz">chrisf@ijw.co.nz</a>> wrote:<br>
>><br>
>> This might be problematic --<br>
>><br>
>> The IvyBridge PRM Vol 4 Part 1 p77 says that if RENDER_SURFACE_STATE<br>
>> dw6.0 (MCS Enable) is 0, the MCS surface may still be accessed by<br>
>> ld_mcs.<br>
>><br>
>> -- Chris<br>
><br>
><br>
> Oh, argh.  Well spotted, Chris.  I think this puts the nail in the coffin of<br>
> my hopes that we could use the same code for UMS and CMS surfaces :(<br>
</div></div></blockquote></div><br></div></div></div>