On Monday, January 03, 2011 04:50:50 pm Francisco Jerez wrote:
The lockup goes away if the timeout in the kernel is disabled (I think that's
what you mean, i.e., that the GPU is allowed to finish whatever it is doing). I
found no evil effects from this at all. The overloaded channel grinds away
until it's finished, meanwhile the system is completely responsive. I set up a
test with the time renewed every 3 seconds, printing a message into the syslog
just to see what was going on. It looked quite orderly. I didn't include the
removal of the timeout in my posting because I thought someone would object to
it and it's not so necessary with the other remedy applied.
I confess to not looking at how it's done with the other drivers. I think what
you are suggesting to do it would have problems. The fence is only updated
when you ask about it (with nouveau_fence_signalled), or call
__nouveau_fence_wait so what would you map to? I will ponder your comments
further, but I have doubts.
Anyway thanks for your input.
BG
> Bob Gleitsmann <rjgle...@bellsouth.net> writes:
> > Hello everyone,
> >
> > When trying the demo program copytex for the first time recently, I
> > noticed pathological behavior: after running for a long time it asserted
> > out and locked up X. Investigation showed this to be due to the glFinish
> > function acting like glFlush and not waiting as it is supposed to for
> > completion of whatever commands had been issued. I took up the task of
> > remedying this.
>
> Thank you for having a look at this, I've been meaning to fix it for a
> while.
>
> > There are, as usual, a variety of different ways of doing so. Influenced
> > by the current gallium code, I planned a separate call to the kernel to
> > wait for the fence created by the pushbuf flush ioctl to complete. After
> > completing the implementation in this way, it occurred to me that it
> > would be more economical to modify the pushbuf flush ioctl call with a
> > flag to indicate whether it should wait for completion or not. This
> > would require modifying the FIRE_RING inline which appears in numerous
> > places. Perhaps my original plan is adequate. The code changes required
> > for the original plan involve mesa, drm, and the kernel.
>
> ATM the nouveau DRM API doesn't let you wait on a fence (it doesn't even
> have the concept of "fence"), instead, you're supposed to wait for a
> specific buffer using the CPU_PREP IOCTL. I think the simplest way to get
> nouveau an
>
> implementation of the screen fence stuff would be something like:
> | struct nouveau_fence {
> |
> | struct nouveau_bo *bo;
> | boolean signalled;
> |
> | }
>
> IOW, a fence would just hold a reference to a buffer object being rendered
> to when the fence was created. nouveau_screen_fence_finish() would call
> nouveau_bo_map()/unmap() with the BO as argument to make sure the fenced
> rendering has landed. The BO selection process would look a bit like
> r300_finish() and it could be done from nvfx/nv50_context.c.
>
> > This forum seems like the best starting point to solicit feedback, since
> > the whole thing is motivated by mesa. The Xorg nouveau driver does not
> > seem to need anything of this nature. I have tested on my current
> > hardware, x86-64 dual opteron and 7300 GT card.
> >
> > The assert out noted in the beginning was due to timeout in the
> > __nouveau_fence_wait function in the kernel. Unfortunately, it does not
> > exit gracefully. The patches that I came up with eliminate the timeout
> > in the case of copytex, but this is clearly a flaw that someday should
> > have a more complete fix.
>
> Perhaps, it sounds like the kernel is just misdetecting a lockup in this
> case. Does it actually hang if you remove that timeout completely?
>
> > Please let me know if I should send the kernel and drm patches to another
> > forum (like dri-devel). For now I will post them here.
> >
> > Best Wishes,
> >
> > Bob
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
