Nouveau - Dec 2009 - [Bug 25806] New: NV40 vertex corruption (kernel BO deletion too early?)

http://bugs.freedesktop.org/show_bug.cgi?id=25806

           Summary: NV40 vertex corruption (kernel BO deletion too early?)
           Product: Mesa
           Version: git
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/nouveau
        AssignedTo: nouveau at lists.freedesktop.org
        ReportedBy: luca.barbieri at gmail.com


On my G71 system, several programs show vertex corruption issues. In
particular, vertices tend to be corrupted or randomly go to infinity, leading
to spiked triangles or random polygons, in several programs, such as
demos/engine, demos/dinoshade, Blender, Extreme Tux Racer.

The system is running:
Linux 2.6.33-rc2
libdrm 2.4.17
Mesa HEAD (b46bcd8e7b37aa2e9159e126c1cc88234a3c2790)
Detected an NV40 generation card (0x049800a2)
64 MB GART aperture
256 MB VRAM

The problem is solved by either of the following:
1. #define FORCE_SWTNL 1
2. Adding usleep(10000) at the end of nv40_draw_arrays
3. Making nouveau_screen_bo_del do nothing

It seems that the issue is that Mesa deletes a buffer object used for vertex
data while the GPU is still drawing to it. The kernel actually performs the
deletion without waiting for the GPU drawing, the memory (or GART mapping) is
reused, and corruption ensues.

http://bugs.freedesktop.org/show_bug.cgi?id=25806





--- Comment #1 from Luca Barbieri <luca.barbieri at gmail.com>  2009-12-27
14:13:14 PST ---
Upon further examination, the kernel does seem to have the required logic:
sending a pushbuffer creates a fence, which is put in bo->sync_obj, which is
then checked on deletion and if non-null, the buffer is put on a delayed
destroy list.

However, it seems to be somehow not working.

Maybe fencing is broken on my card? (i.e. the kernel thinks fences are signaled
when they aren't)
Or possibly fences are being signaled before the vertex shader is finished
running?

How can I test that fencing is working correctly?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=25806


Francisco Jerez <currojerez at riseup.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #2 from Francisco Jerez <currojerez at riseup.net>  2009-12-27
14:25:30 PST ---
(In reply to comment #1)
> Upon further examination, the kernel does seem to have the required logic:
> sending a pushbuffer creates a fence, which is put in bo->sync_obj,
which is
> then checked on deletion and if non-null, the buffer is put on a delayed
> destroy list.
> 
> However, it seems to be somehow not working.
> 
> Maybe fencing is broken on my card? (i.e. the kernel thinks fences are
signaled
> when they aren't)
> Or possibly fences are being signaled before the vertex shader is finished
> running?
That would be almost unprecedented... it's more likely that some caches in
the
GPU aren't being flushed often enough (or maybe the ones in the CPU... a bug
in
the kernel PAT code also used to cause the same symptoms, but that's
hopefully
already fixed).

I'm marking this as invalid because that's the current policy,
unfortunately
we're already aware of too many gallium bugs.
> 
> How can I test that fencing is working correctly?
> 

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.