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
pgpov51HV92mP.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
