-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/15/2011 06:17 PM, Eric Anholt wrote:
> On Tue, 15 Nov 2011 08:06:34 -0800, Chad Versace
> <chad.vers...@linux.intel.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 11/14/2011 04:03 PM, Eric Anholt wrote:
>>> On Mon, 14 Nov 2011 14:29:51 -0800, Chad Versace
>>> <chad.vers...@linux.intel.com> wrote:
>>>> Without 3, there were lots of bugs. But now that you ask, I don't
>>>> remember
>>>> exactly why the bug happened. I'm digging into that now.
>>>> (I wrote the patch at midnight, and I dont' remember much from that
>>>> hour...)
>>>
>>> Ah! It all makes sense now.
>>>
>>> I didn't guess that, because my midnight patches never have such good
>>> commit messages :)
>>
>> Do rb's for patches 5 and 6 come with your revelation?
>>
>> The patches really do fix bugs, and I'm feeling kinda lazy about splitting
>> them up now.
>
> I thought the conclusion yesterday was that the lacks-explanation third
> of patch 5 was likely not required. What happened, or am I
> misremembering?
Part 3 of patch 5 is required. I did some digging and discovered why. Let's
carefully walk through the reason.
Suppose that irb->wrapped_depth is installed at fb->_DepthBuffer and that
irb->wrapped_stencil is installed at fb->_StencilBuffer; that is, this patch
is applied without part 3.
When swrast_render_start is called, in general it is impossible to know which
buffers its caller will access. So we must map all three of
fb->Attachment[BUFFER_DEPTH]
fb->Attachment[BUFFER_DEPTH]->wrapped_depth (which is fb->_DepthBuffer)
fb->Attachment[BUFFER_DEPTH]->wrapped_stencil (which is fb->_StencilBuffer)
When swrast_render_finish() is called, in general it is impossible to know
which buffers were accessed. So we must unmap all three of the above buffers.
The order in which they are unmapped is signficant, because a scatter/gather
operation occurs for
intel_unmap_renderbuffer(fb->Attachment[BUFFER_DEPTH])
intel_unmap_renderbuffer(fb->Attachment[BUFFER_DEPTH]->wrapped_stencil)
Now consider two cases.
Case 1
- ------
Suppose that swrast_render_finish's caller wrote to fb->_StencilBuffer and did
not access fb->Attachment[BUFFER_DEPTH]. Then we must perform the unmaps in
this order:
1. fb->Attachment[BUFFER_DEPTH]
2. fb->Attachment[BUFFER_DEPTH]->wrapped_stencil
Why? Unmap 1 scatters the s8 bits of the s8z24 buffer into the stencil buffer
Unnmap 2 copies the temporary untiled stencil buffer into the tiled stencil
buffer. Since fb->_StencilBuffer now holds the real stencil buffer contents,
unmap 2 needs to win.
Case 2
- ------
Suppose that swrast_render_finish's caller does not access fb->_StencilBuffer
and writes to the stencil bits of fb->Attachment[BUFFER_DEPTH]. Then we must
perform the unmaps in this order:
1. fb->Attachment[BUFFER_DEPTH]->wrapped_stencil
2. fb->Attachment[BUFFER_DEPTH]
Since case 1 and 2 require conflicting orderings, intel_renderbuffer_unmap
must be incorrect. The only way to escape the problem is by part 3 of my
patch.
- ----
Chad Versace
chad.vers...@linux.intel.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOxE03AAoJEAIvNt057x8iDGYP/Rcd3uZRc18Vq+3Q4NK5UmMp
mGcGW0XMFxNSKhSGk0yoBgDT+LuhOY8WgAYK/qUbwK5Y3cL+zG8/vGJKb67Qp29w
8qsqrz/ONbEufDr6er+srOIGhM91lg23yW1wRAJkcnpxcoujVm2N4ljWyWigbShf
YywwbFbxVIIJq5+wskp4H1ENg/pjyCJGrCPKRsGF2B0+2k+Hnr/Cwnqr3ASI0lYt
S4CtfXrEkx1PvH3s8ZxxmXS2UFe6fcbgChEnvUko6Q0xTKzurr3Zam+35HKRWK0k
DmmF4KeGCgrOWL0fsdOaHYvtr2eB7S/4ZRZVN53L+mpJN+oRVv/JVDk2OnkWsx1n
/pNsPrDxzUt4bxV+qsiHwNLDTdgRneWKCT6NccRtQrRGnboh67L/Ebgw3UvsyLWi
xkMU3rJ2LeDVQVampGtzSZZl7KEZ8BjhgGUViGAxa2iG93TMRjHl0KwKHztvNLaT
7lIgmBE/A3jRSq7U8DqGscT7wkKJG7OBCwJZju1ezAqujdESfEYwrOayTLbiM9oz
tG4F1gtNIjPwyefdyZbdnKlKJ1d8u90xaBvKcx/Qi6Q3jSDawS1NKYC0QLZnwNwH
23JYsDNCiHAz5IrQYr2yYV/FejadGNVCNhMt8ERCtgvXKw3EiaaafmRt6WhdLzWs
Gm6Ncq/l64B0ykLVYWPm
=5YD9
-----END PGP SIGNATURE-----
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
