On Tue, 17 Dec 2002, Rodolphe Ortalo wrote: > Is it also the case for putc, puts (and possibly copybox)? I have some > strange output with them.
If the put* functions are implemented in software, yes, and indeed the generic renderers do call PREPARE_FB before beginning to draw. An analysis of whether it is more efficient to copy the pixel data into a texture buffer and transfer it to KGI for hw blitting would be welcome here. I think if KGI drivers did so, it would neatly sidestep the whole syncing issue (all ops would go through the accel, so the only time syncing needs to be considered is with directbuffer) not to mention possibly providing a speedup (DMA/AGP/whatever handles slow VRAM bus accesses while the CPU simultaneuously runs at normal memory bandwidth and allows the app to prepare the next commands.) Of course, with faster VRAM these days the performance equation would be less compelling, perhaps even worse, for newer cards. However, that's what LibBuf "swatch" buffers are supposed to be for -- to allow an application to access DMA/AGP-capable RAM buffers and use them in put* operations. Implementing KGI support for that would be the highest possible performance. > I also have some strange things around clipping. It seems I need to call > GGI_kgi_Gx00_idleaccel() myself from my GGI_kgi_Gx00_gcchanged() function > as soon as some clipping modifications are involved. If I don't, some of > the output of "./demo" is incorrect wrt hline, vline of box tests. Yeah, well if the card does that, then it must be handled correctly, so you'll be needing to sync the accelerator before altering the scissor registers. It's too bad that this is the case -- if I were designing a GPU it would latch the clip region and other GC variables for the duration and not allow changing their values to affect a running accelerator operation :-/ -- Brian.
