On 7 October 2012 17:10, Marek Olšák <span dir="ltr"><<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Mon, Oct 8, 2012 at 1:41 AM, Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> wrote:<br>
> On 6 October 2012 18:49, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote:<br>
>><br>
>> AFAIK, integer formats cannot be resolved, but only one sample is chosen<br>
>> and<br>
>> copied to the destination. However the chosen sample might not be at the<br>
>> center<br>
>> of the pixel, so the tests might never pass.<br>
><br>
><br>
> According to my reading of the spec, integer format MSAA resolves should<br>
> work fine--the samples should be averaged together, just as they are for<br>
> fixed-point and floating-point formats.  So unless I'm misreading the spec,<br>
> these tests should pass.  And in fact, on Intel hardware with Mesa they do.<br>
><br>
> I'm really interested in keeping these tests around because on Intel<br>
> hardware, the MSAA resolve is performed by a special-purpose shader that's<br>
> generated on the fly by the driver.  That shader has to be subtly different<br>
> when using integer formats (to avoid overflow, it has to use the integer AVG<br>
> instruction, rather than floating point ADDs followed by a division).  These<br>
> piglit tests are, at the moment, the only thing verifying that we've handled<br>
> the integer case correctly.<br>
><br>
> Integer format MSAA is a rare, but not unheard of, use case (in fact, GL 3.2<br>
> introduced a constant, GL_MAX_INTEGER_SAMPLES, to allow the driver to<br>
> advertise its level of support for it).  So I'd really rather not drop these<br>
> tests if we can avoid it.<br>
><br>
> I'm guessing that you want to drop the tests because they're failing on a<br>
> particular piece of hardware.  Have we ruled out the possibility of a driver<br>
> bug?  If there's no driver bug (e.g. the tests are failing because of a<br>
> hardware limitation), I'd recommend modifying the driver to report<br>
> FRAMEBUFFER_UNSUPPORTED for those formats that don't work (we currently do<br>
> this on Intel chipsets to work around some hardware bugs).  The multisample<br>
> formats tests will automatically skip any formats that report<br>
> FRAMEBUFFER_UNSUPPORTED.<br>
<br>
</div></div>It's not a driver bug. The tests are failing because my hardware<br>
cannot resolve integer textures. The format must be blendable for MSAA<br>
resolving to work. The hardware can fetch from those textures just<br>
fine though. I guess I can try to set the UNORM format for the source<br>
and destination resources and see what happens. I am sceptic it will<br>
work with the 32-bits-per-channel formats though.<br></blockquote><div><br></div><div>Ah, ok.  I wondered whether your hardware (r600, right?) had dedicated MSAA resolving logic built into it.  I'm envious :)  I'll be curious to hear if the UNORM idea works out.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Anyway, I don't plan to implement MSAA resolving in the fragment shader.<br></blockquote><div><br></div><div>I don't blame you--I wouldn't have done MSAA resolving in the fragment shader on Intel chips if there had been an alternative.</div>
<div><br></div><div>Assuming the UNORM idea doesn't work, are you ok with NAKing this patch and instead reporting FRAMEBUFFER_UNSUPPORTED for the formats where r600 can't do an MSAA resolve?  That would be best from my perspective, because it would allow the Intel logic to still be tested.</div>
</div>