--- Nicolai Haehnle <[EMAIL PROTECTED]> 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 don't like option (1) because it somehow assumes that the user
> program
> 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
> switch
> away from Quake for some reason (incoming messages, whatever), the
> server
> 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
thread ?Doom3?.
A video game typicaly lookes like this...
Get user input/Network Input
Process
Draw/Play/Network Responce
Loop
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
gethostbyname.
> - Imagine a chat application that uses some fancy 3D graphics for
> whatever
> reason (glitz, for example). Now this application may just be in the
> middle
> of drawing something when the user moves some other application above
> it.
> 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
> out
> 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.
>
> cu,
> Nicolai
>
> >
> > Keith
>
> ATTACHMENT part 2 application/pgp-signature
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
-------------------------------------------------------
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
