Nicolai Haehnle wrote:
On Friday 18 February 2005 16:03, Keith Whitwell wrote:
Ben Skeggs wrote:
I still have a 100% reproducable bug which I need to find the cause of,
but time is once again a problem for me. If I move a window over the
top
of a glxgears window my machine locks up immediately, but sysrq still
works
fine.
I just discovered (and should've checked before), that I can ssh in and
successfuly
kill glxgears, then X returns to normal. I can have a partially covered
glxgears
window and everything is fine, but as soon as the entire window (not
incl. window
decorations) is covered, it seems that the 2d driver is unable to update
the screen.
I think some of the other drivers do a 'sched_yeild()' or 'usleep(0)' in
the zero cliprect case to get away from this sort of behaviour.
Well, I can reproduce this bug and I tracked it down. There are a number of
problems here, and they all have to do with DMA buffer accounting.
The first (trivial) problem is that nr_released_bufs was never reset to 0.
I've already fixed that in CVS.
The real problem is that the following situation can occur when we have zero
cliprects:
1. The command buffer contains a DISCARD command for a DMA buffer.
2. We simply drop that command buffer because there are no cliprects, i.e.
nothing can be drawn.
3. As a consequence, DMA buffers aren't freed.
4. The rendering loop continues even though DMA buffers have been leaked,
which eventually causes all DMA buffers to be exhausted, and this causes an
infinite loop in r300RefillCurrentDmaRegion.
The root cause is that we drop the command buffers with the DISCARD. I can
see two possible solutions to this problem:
1. Wait until we have a cliprect again before submitting command buffers.
2. Submit command buffers even when we have no cliprects. The kernel module
would basically ignore everything but the DISCARD commands.
3. Something else?
I'm still rather new at this, so forgive me if this is a bad suggestion.
How about going with option 2, but only submitting the command buffer
anyway if nr_released_bufs != 0.
Would this cause any unwanted side effects? It seems better than just
always submitting buffers with no cliprects anyhow.
Ben Skeggs.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
