On Tue, Aug 28, 2007 at 12:20:44AM +0200, Denis Oliver Kropp wrote: > Ville Syrjälä wrote: > > On Mon, Aug 27, 2007 at 11:29:04PM +0200, Denis Oliver Kropp wrote: > >> [EMAIL PROTECTED] wrote: > >>> New commits: > >>> http://git.directfb.org/?p=core/DirectFB.git;a=commit;h=0d9188ce2911c3aba09f9c4a5ea174ef7f9d2b33 > >>> commit 0d9188ce2911c3aba09f9c4a5ea174ef7f9d2b33 > >>> Author: Ville Syrjala <[EMAIL PROTECTED]> > >>> Date: Mon Aug 27 23:13:22 2007 +0300 > >>> > >>> Avoid unnecessary dfb_gfxcard_sync(). > >>> > >>> Avoid waiting for idle accelerator twice by clearing the GPU read > >>> access flag when handling GPU write access. > >>> > >>> src/core/surface_buffer.c | 2 ++ > >>> 1 files changed, 2 insertions(+), 0 deletions(-) > >>> > >>> http://git.directfb.org/?p=core/DirectFB.git;a=commit;h=22ac13e66da5409ff1b0b28bb6477aa144f9955d > >>> commit 22ac13e66da5409ff1b0b28bb6477aa144f9955d > >>> Author: Ville Syrjala <[EMAIL PROTECTED]> > >>> Date: Mon Aug 27 23:10:45 2007 +0300 > >>> > >>> Fix CPU read/write access confusion. > >>> > >>> CPU read access after GPU read does not need any handling. CPU write > >>> after > >>> a GPU read needs a sync. Flushing the texture cache is not needed. > >>> > >>> src/core/surface_buffer.c | 6 ++---- > >>> 1 files changed, 2 insertions(+), 4 deletions(-) > >>> > >>> http://git.directfb.org/?p=core/DirectFB.git;a=commit;h=fd596f8f4c906d78ebbf1d710448aaef01cfb208 > >>> commit fd596f8f4c906d78ebbf1d710448aaef01cfb208 > >>> Author: Ville Syrjala <[EMAIL PROTECTED]> > >>> Date: Mon Aug 27 23:06:42 2007 +0300 > >>> > >>> Flush the read cache only when a CPU read access is requested. > >> Thanks for all your fixes. In this case we always need to do the > >> flush because next time the flag might not be set anymore and we > >> don't flush at all. > > > > A CPU write to the framebuffer aperture will automatically flush the cache. > > Hmm, but of course there no quarantee that the entity requesting write > > access will actually write anything, so the next read access might > > return stale data from the cache. Is that the case you had in mind, or > > am I missing something more obvious? (it's quite late so my mind is fuzzy :) > > > > > /* Software read/write access... */ > if (access & (CSAF_CPU_READ | CSAF_CPU_WRITE)) { > /* If hardware has written or is writing... */ > if (allocation->accessed & CSAF_GPU_WRITE) { > /* ...wait for the operation to finish. */ > dfb_gfxcard_sync(); /* TODO: wait for serial instead */ > > /* Software read access after hardware write requires > flush of the (bus) read cache. */ > 1) if (access & CSAF_CPU_READ) > dfb_gfxcard_flush_read_cache(); > > /* ...clear hardware write access. */ > 2) allocation->accessed &= ~CSAF_GPU_WRITE; > /* ...clear hardware read access (to avoid syncing twice). */ > allocation->accessed &= ~CSAF_GPU_READ; > } > > > You flush the read cache conditionally at 1) but clear the flag for > entering this condition again at 2). > > It can happen that the read cache is never flushed. By issuing > - GPU_WRITE > - CPU_WRITE > - CPU_READ (miss flush)
OK, so it's the same case I was thinking. CPU_WRITE will implicitly flush the cache (unless no data is actually written). I suppose flushing is so cheap (1 mmio write) that it doesn't really matter even if we do it for write accesses too. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ _______________________________________________ directfb-cvs mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-cvs
