Menu
▾
▴
linux-fbdev-devel
|
From: Sottek, M. J <mat...@in...> - 2002-05-30 21:25:56
|
I agree, I have some API's that I've been using for embedded applications and it always seems that if you allow mmap() you must have a sync() function. (A flush is nice too but not required) If you are going to allow user apps to drive the blitter you don't want to force a sync after each call. An application that is doing a lot of blitting would be wasting lots of time syncing when there is only need for just one sync at the end. The whole point of ring buffers is to pipeline instructions, you'd loose this if you always synced. -Matt -----Original Message----- From: Antonino Daplas [mailto:ad...@po...] Sent: Friday, May 31, 2002 8:07 PM To: fbdev Subject: [Linux-fbdev-devel] Adding an fb_sync() operation to fb_ops Hi, I have been tesing the 2.5 API for some time now, and I really like the new changes. The trend is to consolidate hardware acceleration into 3 functions, fillrect, copyarea and imageblit. However, there is still something bugging me. I don't think we can totally avoid mixing direct graphics memory access with hardware blitting. For instance, some drivers probably will have a mixture of accelerated and unaccelerated drawing functions which may lock up the graphics engine. In order to avoid that, should we: a. Just force a hardware sync after each blit?; or b. Add a new operation, fb_sync() which will be called whenever the framebuffer memory will be accessed? fb_sync() should guarantee that the graphics pipeline has been flushed and that there are no pending hardware operations. (a) is probably simpler (matrox is already doing that) but might decrease performance a bit (not significant since fbcon is dealing with text) (b) a bit more complicated, but should not be difficult to add since all drivers probably has some form of 'wait_for_idle' which can be wrapped. Then we can probably just add something like: if (info->fbops->fb_sync()) info->fbops->fb_sync(info); at the top of fb_write and fb_read. Secondly (not related to the topic), I was wondering if we can change the color value passed to fillrect and imageblit. Presently, the palette index is always passed regardless of the visual. Should the color value passed be reflective of the framebuffer format instead? Pass a palette index if pseudocolor, an RGB value for truecolor, etc. Doing the latter will simplify the low-level drawing function and at the same time, it will make the drawing functions more flexible -- ie, possiblity of exporting to userspace. Tony _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Linux-fbdev-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel |
|
From: Sottek, M. J <mat...@in...> - 2002-06-03 15:49:35
|
>> This depends. For traditional MMIO we need to sync up. For async DMA, Ring >> buffers, and FIFOs we don't need to sync up. That is why I have no hooks >> for syncing. I figure drivers can call the syncing functions if they need >> it inside their own accel functions. >Is it the other way around, async DMA, ringbuffers, and FIFOS that will >need the syncing? Tony is correct. I think James got it backwards. When you have DMA, Ring Buffers, Fifo's you don't know that the command has happened, you only know that it went into one of the aforementioned structures. (And actually in the case are DMA buffers you don't even know that the DMA buffer will ever be processes, which leads to the need for flush() in order to keep this simple we can just make sure that doesn't happen) So here is the obvious problem case. Application mmap's the framebuffer. Application Draws some pixels into the framebuffer. Application issues an ioctl that would lead to a blit, the command is put in a ring buffer but hasn't happened yet. The application draws some more pixels (via the mmap) in a region that intersects the previously blitted region. The hardware gets around to the blit command and overwrites the pixels you just put in the frambuffer. This is quite likely to happen when mixing direct access with asynchronous commands. It is also possible with synchronous commands but not as likely. The blitter does take time to process so if you access the framebuffer during the blit you could get mixed results. (And I hear that this can actually hang some hardware) -Matt |
|
From: Antonino D. <ad...@po...> - 2002-06-03 23:53:24
|
On Mon, 2002-06-03 at 23:49, Sottek, Matthew J wrote: > > So here is the obvious problem case. > > Application mmap's the framebuffer. > Application Draws some pixels into the framebuffer. > Application issues an ioctl that would lead to a blit, the command is put > in a ring buffer but hasn't happened yet. > The application draws some more pixels (via the mmap) in a region that > intersects the previously blitted region. > The hardware gets around to the blit command and overwrites the pixels you > just put in the frambuffer. > > And it does not have to happen outside the kernel. Within the kernel too. For instance, a particular accelerator may only support fillrect and copyarea, but not imageblit (neofb). It has no choice but to mix in cfb_imageblit and the sync problem will arise unless the accelerator forces a sync -- which neofb does by the way. Tony |
|
From: James S. <jsi...@tr...> - 2002-05-31 20:02:41
|
> I agree, I have some API's that I've been using for embedded applications > and it always seems that if you allow mmap() you must have a sync() > function. (A flush is nice too but not required) Hm. There is also the issue of the cache and memory going out of sync. The question is do we need device specific hooks? |
Thanks for helping keep SourceForge clean.
X