Eric Anholt wrote: >> 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. >> The other one is that TG will be needing the functionality of >> !DRM_BO_FLAG_CACHED, so we need to provide a way to have that. I guess >> you will be needing it as well for things like scanout buffers? >> > > It would be fine for scanout buffers if we fixed the fact that we evict > the object as a signal that clflushing needs to occur. Then you're just > down to two clflushes and a chipset flush per map/unmap of that buffer. > The clflushing would be somewhat expensive, but may still beat uncached > access through the GTT. > Eric, What's extremely important to us is to keep the !DRM_BO_FLAG_CACHED functionality in i915 drm for upcoming Gallium drivers. We see no performance issues with the way transient buffers were handled in the i915tex driver and are planning to reuse that functionality. I'm realizing I'm not going to be able to convince you to do the same, but anyway I'd prefer that !DRM_BO_FLAG_CACHED have the same semantics as in other drivers and for other memory types. If not, we must be able to have a way to select them.
/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 > ------------------------------------------------------------------------- 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
