On Wed, Oct 21, 2009 at 1:03 PM, Ville Syrjälä <syrj...@sci.fi> wrote:
> > FlushTextureCache and FlushReadCache are for invalidating the caches on > the GPU. For CPU caches they may not be enough. Eg. with write back cache > you would need to to do the write back after a CPU write but before any > GPU access. FlushTextureCache would only be called for GPU read access, > not write access. And on a CPU access after a GPU write you would need to > invalidate the CPU cache. For this FlushReadCache would be enough since > it will be called for any CPU access. Ideally it would only be called for > a CPU read access since a CPU write would invalidate the cache anyway > (at least on Matrox hardware for which FLushReadCache was added), but > since there's no guarantee that a write access will happen even if a CPU > write lock was requested it was decided that FlushReadCache will be > called for any CPU access after a GPU write. > > I don't think you should even try to use FlushTextureCache and > FlushReadCache for CPU cache management. If you have a custom surface > pool you could do the cache management there (in Lock/Read/Write). > hmmm so you're using cache on both sides ;) I'm currently working with a 2d blitter that acts like a DMA, so I don't have this kind of problem. But still, you could implement the both operation in FlushReadCache and FlushTextureCache. FlushReadCache => write back GPU cache to RAM + flush CPU cache FlushTextureCache => flush GPU cache + write back CPU cache to RAM Anyway, there is still a missing FlushTextureCache when flipping the primary surface. -- Lionel Landwerlin
_______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
