From: Antonino D. <ad...@po...> - 2002-06-01 12:31:35
|
On Sat, 2002-06-01 at 03:56, James Simmons wrote: > > > I don't think we can totally avoid mixing direct > > graphics memory access with hardware blitting. > > In userland true. In the kernel we can work around it. > > > In order to avoid that, should we: > > > > a. Just force a hardware sync after each blit?; or > > > (a) is probably simpler (matrox is already doing that) but might > > decrease performance a bit (not significant since fbcon is dealing with > > text) > > 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? Personally, whether we sync after each blit or sync only when needed does not matter. Since fb is dealing mostly with discontiguous regions (character cells), except for the occasional clear screen, perfomance degradation is not significant. So, is it agreed that for drivers that need sync's, they will just have to do it after each blit? It's just that it defeats the purpose of those FIFO's and buffers. > > > 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. > > > (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. > > Orginally I had that. Then I realized this doesn't fit all hardware > models. You are right tho. The one time where we do need a sync is for Still, a driver can always assign a NULL to fb_sync if it is not needed. > > 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. > > We had this discussion sometime ago. We discovered it was just impossible > to handle all the possible different color formats in the higher levels. > We ended up with way to many #ifdefs. So it was decided to let the drivers > handle it instead. Actually if you wanted it to be useable to userland > then it makes even more sense to use the color map index instead. Think > about all the if() statements you would need in userland. > I agree that fbcon-accel will be swamped by if-else/case-switch statements, and passing palette indices may be the best solution overall. The price, though, is that those drawing functions may only be usable within the kernel. If these drawing functions are to be exported to userland, then the current implementation will necessitate a workaround. Within the kernel we are dealing with 16 colors, and color palettes (in pseudocolor) have a practical limit of 256. In userland we are dealing with thousands to millions of colors. So how will I convert a particular 16-bit RGB colorvalue into a palette index? a. Reset the colormap so that a particular colorvalue can be indexed from the map and keep track which colorvalue is in the map or not. b. Tell the accelerator that it is not actually a palette index, but treat it as directcolor; c. Or allocate a colormap that will encompass the entire color range (insane). I can't really think of any other way, so correct me if I'm wrong. In the end though, it's much simpler to just pass the appropriate color value. Secondly, if I'm going to use, for instance, imageblit to tile and expand an 8x8 mono bitmap, then for each tile, the accelerator has to lookup the color which is too inefficient. On the other hand, if the color is looked up in the upper layer, then it's done only once. Of course, this is not done in the console, so it's a bad example. Tony |