Rahul: Does the following patch queued up to for-linus in the kernel help you?
commit 07f4f3e8a24138ca2f3650723d670df25687cd05
Author: Kristian Høgsberg <email address hidden>
Date: Wed May 27 14:37:28 2009 -0400
i915: Set object to gtt domain when faulting it back in
When a GEM object is evicted from the GTT we set it to the CPU domain,
as it might get swapped in and out or ever mmapped regularly. If the
object is mmapped through the GTT it can still get evicted in this way
by other objects requiring GTT space. When the GTT mapping is touched
again we fault it back into the GTT, but fail to set it back to the
GTT domain. This means we fail to flush any cached CPU writes to the
pages backing the object which will then happen "eventually", typically
after we write to the page through the uncached GTT mapping.
[anholt: Note that userland does do a set_domain(GTT, GTT) when starting
to access the GTT mapping. That covers getting the existing mapping of the
object synchronized if it's bound to the GTT. But set_domain(GTT, GTT)
doesn't do anything if the object is currently unbound. This fix covers the
transition to being bound for GTT mapping.]
Fixes glyph and other pixmap corruption during swapping. fd.o bug #21790
Signed-off-by: Kristian Høgsberg <email address hidden>
Signed-off-by: Eric Anholt <email address hidden>
Vytautas: Does the following patch queued up to for-linus in the kernel help you?
commit 07f4f3e8a24138ca2f3650723d670df25687cd05
Author: Kristian Høgsberg <email address hidden>
Date: Wed May 27 14:37:28 2009 -0400
i915: Set object to gtt domain when faulting it back in
When a GEM object is evicted from the GTT we set it to the CPU domain,
as it might get swapped in and out or ever mmapped regularly. If the
object is mmapped through the GTT it can still get evicted in this way
by other objects requiring GTT space. When the GTT mapping is touched
again we fault it back into the GTT, but fail to set it back to the
GTT domain. This means we fail to flush any cached CPU writes to the
pages backing the object which will then happen "eventually", typically
after we write to the page through the uncached GTT mapping.
[anholt: Note that userland does do a set_domain(GTT, GTT) when starting
to access the GTT mapping. That covers getting the existing mapping of the
object synchronized if it's bound to the GTT. But set_domain(GTT, GTT)
doesn't do anything if the object is currently unbound. This fix covers the
transition to being bound for GTT mapping.]
Fixes glyph and other pixmap corruption during swapping. fd.o bug #21790
Signed-off-by: Kristian Høgsberg <email address hidden>
Signed-off-by: Eric Anholt <email address hidden>
(swapping isn't the only case that this bug can fix, but it's the most common as the cpu cache of the object will be hot with writes at the time we don't want it)
Rahul: Does the following patch queued up to for-linus in the kernel help you?
commit 07f4f3e8a24138c a2f3650723d670d f25687cd05
Author: Kristian Høgsberg <email address hidden>
Date: Wed May 27 14:37:28 2009 -0400
i915: Set object to gtt domain when faulting it back in
When a GEM object is evicted from the GTT we set it to the CPU domain,
as it might get swapped in and out or ever mmapped regularly. If the
object is mmapped through the GTT it can still get evicted in this way
by other objects requiring GTT space. When the GTT mapping is touched
again we fault it back into the GTT, but fail to set it back to the
GTT domain. This means we fail to flush any cached CPU writes to the
pages backing the object which will then happen "eventually", typically
after we write to the page through the uncached GTT mapping.
[anholt: Note that userland does do a set_domain(GTT, GTT) when starting
to access the GTT mapping. That covers getting the existing mapping of the
object synchronized if it's bound to the GTT. But set_domain(GTT, GTT)
doesn't do anything if the object is currently unbound. This fix covers the
transition to being bound for GTT mapping.]
Fixes glyph and other pixmap corruption during swapping. fd.o bug #21790
Signed-off-by: Kristian Høgsberg <email address hidden>
Signed-off-by: Eric Anholt <email address hidden>
Vytautas: Does the following patch queued up to for-linus in the kernel help you?
commit 07f4f3e8a24138c a2f3650723d670d f25687cd05
Author: Kristian Høgsberg <email address hidden>
Date: Wed May 27 14:37:28 2009 -0400
i915: Set object to gtt domain when faulting it back in
When a GEM object is evicted from the GTT we set it to the CPU domain,
as it might get swapped in and out or ever mmapped regularly. If the
object is mmapped through the GTT it can still get evicted in this way
by other objects requiring GTT space. When the GTT mapping is touched
again we fault it back into the GTT, but fail to set it back to the
GTT domain. This means we fail to flush any cached CPU writes to the
pages backing the object which will then happen "eventually", typically
after we write to the page through the uncached GTT mapping.
[anholt: Note that userland does do a set_domain(GTT, GTT) when starting
to access the GTT mapping. That covers getting the existing mapping of the
object synchronized if it's bound to the GTT. But set_domain(GTT, GTT)
doesn't do anything if the object is currently unbound. This fix covers the
transition to being bound for GTT mapping.]
Fixes glyph and other pixmap corruption during swapping. fd.o bug #21790
Signed-off-by: Kristian Høgsberg <email address hidden>
Signed-off-by: Eric Anholt <email address hidden>
(swapping isn't the only case that this bug can fix, but it's the most common as the cpu cache of the object will be hot with writes at the time we don't want it)