Perfect. It is still a good temporary solution. For coherency, my goal is top ensure it without the need of MI_FLUSH or pipe control. So, EUs must be able to do it themselves For ILK * on CPU, I used _mm_clflush (as the kernel does btw) to go through memory * on EUs, I used the render cache flush command For SNB * nothing special on CPU since LLC snoops cores caches * on SNB, the flush render cache command is gone. I therefore manually handled the flush abusing the policy and the associativity of the render cache As for the cachability on Gen, you can override page descriptors using surface descriptors. Cheers, Ben ________________________________________ From: Chris Wilson [chris@xxxxxxxxxxxxxxxxxx] Sent: Tuesday, December 14, 2010 2:59 AM To: Segovia, Benjamin; Segovia, Benjamin; Zhenyu Wang Cc: DRI Subject: RE: Intel DRM driver for SNB On Mon, 13 Dec 2010 20:32:42 -0800, "Segovia, Benjamin" <benjamin.segovia@xxxxxxxxx> wrote: > To be more explicit, my concern is that I read that Chris Wilson proposed a patch preventing the VM to swap pages still in GTT. I did not see any trace of this patch in the main line yet. No, because the mm maintainers corrected me by pointing out that a page will not be swapped whilst a reference is held and it remains off the zone LRU lists. (That said there remains a persistent nagging doubt that something smells fishy...) But as for what you want to do, it is possible with the current module. However as it deliberately evades the minimal security provisions we have, it should only be done from a privileged application. In principle, there should be sufficient knowledge within the kernel to maintain coherency for you. I'm interested in knowing how you plan to manage coherency to make sure we have not missed something. (Give or take the fixes for completely handing coherency of uncached/cached CPU mappings.) With ppGTT, we can be much more permissive and allow individual apps to reserve portions of the GTT without impacting other users of the system. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
