diff options
author | Keith Packard <keithp@keithp.com> | 2008-08-05 14:44:53 -0700 |
---|---|---|
committer | Keith Packard <keithp@keithp.com> | 2008-08-05 14:44:53 -0700 |
commit | ceb3d5e3834452f9d54f974b8066f90168467443 (patch) | |
tree | fc04302cf176bf9fe059c2ab5c68c9ec70f3f6db /linux-core/radeon_mode.h | |
parent | 8e41ce17b4ab72f526cc6e9acd75c3fa81a60433 (diff) |
[gem-intel] Don't clear write_domain until flush completes
In i915_gem_object_wait_rendering, if the object write domain is being
written by the GPU, the appropriate flushing commands are written to the
device and an additional request queued to mark that flush. Finally, the
function blocks on that new request.
The bug was that the write_domain in the object was cleared before the
function blocked.
If the wait is interrupted by a signal, the flushing commands may still be
pending. With the current write_domain information lost, the restarted
syscall will drop right through the write_domain test as that value was
lost, and so the function will not block at all. Oops.
Fixed by simply moving the write_domain clear until after the wait_request
succeeds. Note that the restarted system call will generate an additional
flush sequence and request, but that should be 'harmless', aside from a
slight performance impact.
Someday we'll track flushing more accurately and clear write_domains more
efficiently, but for now, this should suffice.
This bug was discovered in the 2d gem development by running x11perf
-copypixwin500 and noticing that the window got cleared accidentally.
Diffstat (limited to 'linux-core/radeon_mode.h')
0 files changed, 0 insertions, 0 deletions