Re: [linux-fbdev] Is a FontCache worth implementing ?

[Sven L. <lu...@dp...>]

On Sat, Mar 10, 2001 at 01:56:07AM -0800, James Simmons wrote:
> 
> >> Using a image blitter you can translate that data from normal RAM to
> >> the video card memory. The nice thing about a image blitter is you can
> >> do depth translations (mono to depth X).
> >
> >Yes, that was killed my current (test) implementation : 16 colors
> >mean 16 copies of each glyph. Yuck (8 Mb for 512 glyhs, 16x16 32bpp)
> 
> I agree with you about the PCI bus. Slow to go over. I want to maximize
> fbcon as much as possible. I'm working on the removal of the
> console_spinlock so we can use DMA. This will greatly speed up fbcon. I

Err, ...

so this would mean using the drm/dri stuff for doing DMA ?

what about cards that don't have drm support yet ?

Or will we just mess up things if we want to run simoultanous with
X+Accelerated OpenGL ? 

Will this enable us to do accelerated Mesa on fbdev ?

> need to rename that function. The goal is to draw some image. It depends on
> the hardware how you approach it. I like to see AGP used by fbcon to do
> the transfering of font images to the console. You can even make them
> textures if you want. In fact I was thinking of doing that for the voodoo

Textures is only one of the way of doing this. I guess games oriented 3dfx HW
will only have textures, and not dedicated 2d font mapping stuff, like bitmap
expansion or direct glyph writing ?

> 1 card. It has 4 megs for the framebuffer, 4 megs for register space and 4
> megs for texture space. So I could place font data in the texture space.
> The big thing I like is the hardware translation from whatever to the
> current depth. Some hardware has this seperate. I leave up to the driver
> programmer how to approach this problem.

But notice that textures can be expensive to use, if other means are easily
available, which are handled only in the fb access units.

Friendly,

Sven Luther