Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=4327
------- Additional Comments From unichrome@... 2005-10-14 15:25 -------
OK, Hmm,
I wasn't reading too carefully. I thought the problem might be caused by a
back-to front blit occuring before the 3D engine had completed it's rendering to
the back buffer.
Anyway, I compiled the submitted code and the problem is reproduced, and I did
some sync testing in viaTexSubImage2D:
If VIA_FLUSH_DMA(vmesa) is replaced by viaWaitIdle(vmesa), the problem goes
away, so it seems clear that the texture memory is written to while the 3D
engine uses it. The problem seems to be how to sync without having to lock and
wait for engine idle.
If the command regulator really waits for 3D engine idle before issuing a
pending 2D blit, then the problem is easily solved by emitting a breadcrumb
after the DMA flush and wait for it to be read.
However, if the breadcrumb is blitted at the end of the command stream while the
3D engine still renders, there is a problem and we'll have to lock and wait for
3D engine idle. If this is really the case, then this must be done also before
back-to-front buffer blits otherwise parts of the image may not be completely
rendered before the blit occurs. Luckily, I don't think this is the case, and
really, commenting out
while(!viaCheckIdle(vmesa))
;
from viaWaitIdle still makes the sample case render correctly.
Also, while looking at this, some things strike me:
1) Breadcrumb 32-bit wraparounds don't seem to be correctly handled?
2) Shouldn't viaCheckIdle be called locked from within viaWaitIdle?
/Thomas
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|