Re: [Dri-devel] Rage 128 + bttv patches
[ CC: to Mark to get the most competent comments on XAA ] Gerd Knorr wrote: the indirect buffers aren't flushed often enough. When I move a window with amiwm, the contents don't move at first. Only when I move it again do the contents appear in the current place. A quick comparison with the Radeon code didn't reveal any obvious difference, so I wonder what's wrong? I've noticed this too. Very good visible with mutt, when walking the mail index up and down. Killing all x clients which update the screen regular intervals (xload, xclock + friends) gives even better results. The FLUSH_RING machro does submit the buffer to the kernel. It is used by R128CCEWaitForIdle, which in turn is hooked into XAAInfoRecPtr-Sync. Maybe this is simply the wrong place? Don't know much about the XAA architecture... Hmm, yes and no. XAAInfoRecPtr-Sync is used to synchronize between accelerator and CPU access to the framebuffer, so while R128CCEWaitForIdle looks good to me, it's never called as long as there is no CPU access to the framebuffer. Mark, is there a way to flush DMA buffers after a batch of XAA operations right now? If not, could it be added easily? The only alternative I see is to put a FLUSH_RING at the end of each SubsequentXXX function, but that might kill performance... What exactly is the reason that the radeon has only a few accel functions implemented for 2D accel via CP? Are the other ones simply not implemented yet? Possible, maybe ATI didn't pay for more. :) Or isn't it worth the trouble due to the system call overhead? Wonder about that myself. I also wonder if Gareth's ati-5-0-1-branch did things the same way we're doing them now, or if it used the ring directly. Either way, I guess there are a few other operations which would be worthwhile to implement CCE acceleration for, in particular for the RENDER extension. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage 128 + bttv patches
On Thu, 20 Sep 2001, Michel Dänzer wrote: [ CC: to Mark to get the most competent comments on XAA ] Gerd Knorr wrote: the indirect buffers aren't flushed often enough. When I move a window with amiwm, the contents don't move at first. Only when I move it again do the contents appear in the current place. A quick comparison with the Radeon code didn't reveal any obvious difference, so I wonder what's wrong? I've noticed this too. Very good visible with mutt, when walking the mail index up and down. Killing all x clients which update the screen regular intervals (xload, xclock + friends) gives even better results. The FLUSH_RING machro does submit the buffer to the kernel. It is used by R128CCEWaitForIdle, which in turn is hooked into XAAInfoRecPtr-Sync. Maybe this is simply the wrong place? Don't know much about the XAA architecture... Hmm, yes and no. XAAInfoRecPtr-Sync is used to synchronize between accelerator and CPU access to the framebuffer, so while R128CCEWaitForIdle looks good to me, it's never called as long as there is no CPU access to the framebuffer. Mark, is there a way to flush DMA buffers after a batch of XAA operations right now? If not, could it be added easily? Wrap the BlockHandler and flush there. It gets called before the X-server goes back to waiting on its file descriptors. Mark. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage 128 + bttv patches
Mark Vojkovich wrote: Mark, is there a way to flush DMA buffers after a batch of XAA operations right now? If not, could it be added easily? Wrap the BlockHandler and flush there. It gets called before the X-server goes back to waiting on its file descriptors. Luckily, the r128 driver already has a BlockHandler of its own, works great, thanks! I'll commit this in a few minutes. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
