--- Nicolai Haehnle <prefect_@...> 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
> > >> of a glxgears window my machine locks up immediately, but sysrq
> > >> 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
> > > glxgears
> > > window and everything is fine, but as soon as the entire window
> > > incl. window
> > > decorations) is covered, it seems that the 2d driver is unable to
> > > 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
> 1. The command buffer contains a DISCARD command for a DMA buffer.
> 2. We simply drop that command buffer because there are no cliprects,
> nothing can be drawn.
> 3. As a consequence, DMA buffers aren't freed.
> 4. The rendering loop continues even though DMA buffers have been
> 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
> see two possible solutions to this problem:
> 1. Wait until we have a cliprect again before submitting command
> 2. Submit command buffers even when we have no cliprects. The kernel
> would basically ignore everything but the DISCARD commands.
> 3. Something else?
> I don't like option (1) because it somehow assumes that the user
> only cares about OpenGL (and that's quite selfish). There are many use
> cases where it is plainly the incorrect thing to do:
> - A user running something like Quake in listenserver mode; if they
> away from Quake for some reason (incoming messages, whatever), the
> will stop and eventuall all clients will timeout.
There are acctualy more common reasons why video games NEED a renderer
that dose not block or they should do all there rendering in another
A video game typicaly lookes like this...
Get user input/Network Input
If the Draw part above dose not return ASAP then user input and network
pings will suffer grately! What I mean is the player knowes about a
target(from a previous frame or sound) and he is stuck waiting 1/nth a
second for the nFPS OpenGL driver to return.
This is not the first time I have brought this up and I'm sad to see
that the point still has not been visable, must be getting cliped by
> - Imagine a chat application that uses some fancy 3D graphics for
> reason (glitz, for example). Now this application may just be in the
> of drawing something when the user moves some other application above
> The end result will be that the applications essentially becomes
> locked up
> until it becomes visible again; in the mean time, the chat might time
> and disconnect the user.
> So (1) clearly isn't a good solution.
> Option (2) is more correct, but it does seem a little bit hackish.
> Any better ideas? Perhaps tracking which buffers were discarded?
> That's not
> exactly beautiful either.
> > Keith
> ATTACHMENT part 2 application/pgp-signature
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.