Thomas Hellström wrote: > Eric Anholt wrote: > >> >> Going from CACHED_MAPPED back to uncached even with buffer reuse is a >> 22% performance drop (but at least it's not the 79% hit to the face you >> get without buffer reuse). >> >> > Hmm, this sounds odd. That simply means you must still be doing a lot > of buffer binding / unbinding? Relocations using master drm will also > be slow of course. Oh, and of course one must make sure that display list VBOs don't end up in WC memory if we're doing any software vertex processing. Otherwise apps like gears will read vertex data from WC memory which will kill performance. That means adjusting intel_buffer_objects.c to make sure VBOs end up CACHED. >> So, I want DRM_BO_FLAG_CACHED_MAPPED to be the default for our DRM when >> you don't ask for cached buffers, determined by the driver flagging it >> as doable on this chipset. >> > I see two problems with this: One is cosmetic in that > DRM_BO_FLAG_CACHED_MAPPED doesn't have the same semantics as > !DRM_BO_FLAG_CACHED. You can't use it for user-space buffer pools. ... And thinking more about this, you can't really use it for scanout buffers either, unless you want to clflush() twice and chipset flush for each write operation. > > /Thomas > > /Thomas
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel