hack patch to fix dirty on offload screens
RFC PATCH 1/1 hack patch to fix dirty on offload screens
The offload screens on an nvidia gpu show dirt on them, this is due to the stuff not being flushed fully back to the CPU side and into main memory, for the secondary GPU to pick it up from.
This is the hack I used to have in UXA, which works here, however I'm sure this isn't acceptable for upstream, so let me know what else I could try.
Dave.
--- src/sna/sna_accel.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
src/sna/sna_accel.c +3 -1
@@ -17638,7 +17638,9 @@ fallback: box, n, COPY_LAST)) goto fallback; - flush = true; +kgem_submit (&sna->kgem); +kgem_bo_map (&sna->kgem,__sna_pixmap_get_bo (dst)); + }DamageRegionProcessPending (&dirty->slave_dst->drawable);
Signature · 6 lines
2.4.2 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoted 6 lines · Dave Airlie
The offload screens on an nvidia gpu show dirt on them, this is due to the stuff not being flushed fully back to the CPU side and into main memory, for the secondary GPU to pick it up from.
This is the hack I used to have in UXA, which works here, however I'm sure this isn't acceptable for upstream, so let me know what else I could try.
Hmm, thinking about it we need to make the dst uncached as well as a PCI device will bypass LLC.
So we do need the submit before the ProcessPending as that is where the slave will then do its copy. My fault for thinking the copy would be from its BlockHandler after amalgamating the damage.
-Chris
Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx