Hi, Let's look at the IDirectFBSurface_DrawString function, assuming that it's the first time we call it and the internal surface used as a glyph cache isn't constructed yet. Also DSPF_A8 isn't hardware accelerated. Our goal is the following: We want to render a text on the primary surface, that's it. The following are the steps as I envision them.
1. IDirectFBSurface_DrawString will call dfb_font_get_glyph_data() (which will prepare the internal DSPF_A8 cache) and that function will actually call dfb_gfxcard_flush_texture_cache() near its end. The latter will only serve to commit the dirty cache lines relevant to the internal DSPF_A8 surface into the VRAM, we're not yet rendering to the primary screen. 2. IDirectFBSurface_DrawString will then call dfb_gfxcard_drawstring() which will blit the cached glyphs and do the real thing. 3. dfb_gfxcard_drawstring() will lock the destination surface, that's the primary surface, using gAcquire(). 4. The lock is a CSAF_CPU_WRITE access and thus the dfb_gfxcard_flush_read_cache() may be triggered if the allocated was accessed previously by the GPU, but this is pointless in our scenario. 4. The glyphs are blitted using gBlit(), one by one. 5. Then the primary surface is unlocked through gRelease(). The unlock doesn't flush the CPU cache and since the primary surface is cached (which is pretty much insane, I admit), one would have to commit the last cached writes to the VRAM by issuing an extra dfb_gfxcard_flush_texture_cache() and actually if we think about it for a while, we have to generalize this for any CSAF_CPU_WRITE lock when finishing writing into a video buffer using the CPU, just like dfb_font_get_glyph_data() is manually doing it. Any thoughts? Regards, Ilyes Gouta. On Wed, Oct 21, 2009 at 9:19 AM, Ilyes Gouta <ilyes.go...@gmail.com> wrote: > Hi, > >> DirectFB does not manage the cache stuff at unlock time but only at lock >> time. This is a "lazy" cache management. > > Yes, I know. > >> In the end, it remains to your gfxdriver to implement the FlushReadCache >> function to unsure the read cache is flushed when requested by DirectFB. > > That was implemented too. However, I'm still observing some rendering > glitches especially when drawing text on the primary surface. I'm > going to investigate a bit more and try to come back with a proper > scenario. > > Regards, > Ilyes Gouta. > > On Wed, Oct 21, 2009 at 12:49 AM, Lionel Landwerlin > <llandwer...@gmail.com> wrote: >> Le lundi 19 octobre 2009 à 14:42 +0100, Ilyes Gouta a écrit : >>> Hi, >>> >>> I'm dealing with a configuration where the video RAM is mapped into >>> the user-space application as a cached region. What happens if the >>> destination is the framebuffer (VRAM) which was locked and then >>> written to using the CPU? Don't we need a: >>> >>> if (allocation->accessed & CSAF_CPU_WRITE) >>> dfb_gfxcard_flush_texture_cache(); >>> >>> in dfb_surface_buffer_unlock() (surface_buffer.c) ? >>> >> >> Hi Ilyes, >> >> DirectFB does not manage the cache stuff at unlock time but only at lock >> time. This is a "lazy" cache management. >> When accessing a buffer (read or write), DirectFB first looks at the >> last operation done on this buffer, and according to this last operation >> it knows if there is some synchronization stuff to do. >> >> If you're interested in, have a look at the dfb_surface_buffer_lock >> function. Espacialy the "Manage access interlocks" part. >> >> In the end, it remains to your gfxdriver to implement the FlushReadCache >> function to unsure the read cache is flushed when requested by DirectFB. >> >> Regards, >> >> -- >> Lionel Landwerlin <llandwer...@gmail.com> >> >> _______________________________________________ >> directfb-dev mailing list >> directfb-dev@directfb.org >> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev >> > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
