[Mesa-dev] Proper implemtation of glFinish

[Francisco Jerez]

Bob Gleitsmann <rjgleits at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110103/9901e367/attachment.pgp>