[Bug 109113] KHR-GL43.compute_shader.resource-texture fails with MCS fast clears disabled

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Jan 5 00:27:33 UTC 2019


--- Comment #3 from Jason Ekstrand <jason at jlekstrand.net> ---
I spent some time this afternoon poking at this and oh, is it ugly...  Here's
what I've done so far:

 1) I have verified by hand that the slow clear is doing the right thing and
setting the correct MCS bits to 0x0 (all on layer 0) which is what we expect
for a single-color draw that covers all samples in a pixel.

 2) Reverse-engineered the test a bit and determined that the issue is with the
first, non-array, multi-sampled image and that it's returning 0 for all of the
odd rows of pixels.  The values for the first multi-samapled image are vec4s
896-1023 in the buffer_data array in the test for anyone who wants to know.  I
looked at the results from the two-layer image and they actually look ok.

 3) I experimented with unsetting the SurfaceArray bit in the surface state
thinking maybe it needed to be unset for single-layer MSAA.  It made no

 4) I ran it on the simulator, stepped through the shader, and used "view mem"
to verify that, when run in simulation, it produces the correct results. 
Whatever bug we're looking at is not reproduced in simulation.

 5) I hacked up the compiler to put the texture coordinate in .yz of the
texture result and the MCS value in .w.  With this information, I was able to
determine that, in the bad pixels, we're getting an MCS value of 0xff instead
of 0x0 like we would expect.

 6) I hacked up the aux buffer memset to write offset & 0xff into each byte
instead of 0xff.  Using this, I was able to determine that, for pixel (0, 1),
it's fetch from 0xc8 instead of 0x10 like one would expect.  As you go across
the line, (1, 1) is at 0xc9, (2, 1) is at 0xca, etc.  (If you're wondering
about high bits, I also tested filling the aux with (offset >> 8) & 0xff and
got zeros).  Doing a bit more prodding around, it looks very much like a tiling
calculation gone wrong.  There appears to be a logic to where it puts the
pixels but they're way off in the weeds.

 7) I experimented with passing more zero parameters to ld_mcs thinking that
maybe it was getting a garbage LOD or something.  Nothing seemed to make any

 8) On a hunch, I started experimenting with different image widths.  4 (the
width the test natively uses) is broken as are a smattering of other small
widths.  It appears like everything works again when the width >= 16 though
some smaller widths seemed to work.

Where does that leave us?  Well, we could deny MCS on any surface with a
128-bit format and width < 16.  However, I have no idea if that's actually the
correct limits because I have no idea what's actually going wrong.  All I know
is that some address calculation in the sampler is ending up in the weeds when
it does the MCS fetch.

You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20190105/152ca966/attachment.html>

More information about the intel-3d-bugs mailing list