diff options
| author | Jesse Barnes <jbarnes@nietzche.localdomain> | 2009-03-19 13:25:29 -0700 |
|---|---|---|
| committer | Carl Worth <cworth@cworth.org> | 2009-03-19 16:33:44 -0700 |
| commit | e2465249a90b9aefe6d7a96eb56a51fde54698a0 (patch) | |
| tree | 5d280a5866e804e052a8a0d60c1be52a75159e8f /src/exa_wm_src_projective.g4a | |
| parent | 1883d912c75238e73b3662580e08d3455d2efb33 (diff) | |
Don't install fences if the kernel is managing them
If execbuffer is setting up fences, it also means that the kernel is
managing them at pin time, so installing one in the 2D driver in that
case is an error. The fence should stick around as long as the buffer
is pinned (the kernel won't steal these), though it will be freed at
leavevt and re-allocated at entervt.
On 965+ chips, the pin ioctl will *not* install a fence reg, but that's
also ok because all 965+ operations include tiling bits, and sw
fallbacks will be protected by prepare/finish access hooks, which will
either access the backing store or use the GTT, which will ensure proper
fencing at fault time.
Fixes #20265.
Acked-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 636d252f3b1eac687f7b11952e949c383cb86ed4)
Diffstat (limited to 'src/exa_wm_src_projective.g4a')
0 files changed, 0 insertions, 0 deletions