Menu
▾
▴
linuxconsole-dev
|
From: James S. <jsi...@li...> - 2001-03-07 18:50:19
|
>I was wondering if it could be worthwhile (speedwise) to implement >a fonctcache for fast character display. If you think about it we already have something like that with teh current system execpt instead of it being in card memory it is in system memory. 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). I though about using a Glyhp approach. The voodoo 3 card has a pattern buffer for up to 64 Glyphs which can then be very quickly painted on the display. The problem is the console system supports alot more characters than that. In the future I hope even more. >So I was wondering about a good ol' font cache : using regular >fbcon_cfbXX_putc() in ofscreen memory once per character (on- >demand, likely), and just _bmove() them to proper place. > >On the pm3, that would cost 4 memory access to the registers >(in PCI memory space) (6 if not properly aligned, for the >scissors stuff) plus the hardware copy, compared to whatever >fbcon_cfbXX_putc() use. > >Would that be worth the hassle of adding the fontcache ? >(I have no idea what putc() actually cost). > >Would that be worth adding a more generalized implemetation >on top of existing _bmove() so that every hardware-accelerated >board could use it ? (those without HW-accel putc(), that is) > >Is that already planned for the 2.5.x API ? (haven't seen >anything to that extent in 'ruby' but I might have >overlooked something) Yes. This is the way the ruby tree handles it. I just got it working in the ruby tree. The only problem is their is some bug in take_over_console I have to chase down but I do have fbcon running using a voodoo 3 along side my MDA. There are 3 functions. One is rectfill which does things like clear the margins etc. Then their is fb_copyarea which copys a area of the screen to another area of the screen. The last function is fb_imageblit which transfers data from host memory to screen memory. This is used to draw the penguin and text. Yes it is simpler to use the accel engine. A good example is the new tdfx driver in the ruby CVS. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@li...> - 2001-03-10 17:53:01
|
>> 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 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 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. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Sven L. <lu...@dp...> - 2001-03-12 10:41:45
|
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 |
|
From: Geert U. <ge...@li...> - 2001-03-12 11:15:34
|
On Mon, 12 Mar 2001, Sven LUTHER wrote:
> 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 ?
[...]
> 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 ?
Before we go to far into this discussion, all we want is a (fast) text console
implementation. That means
- rectangle copy
- rectangle fill
- monochrome expansion for text drawing
- pixmap drawing for penguin
No OpenGL, mesa, DRM, DRI, textures, ...!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Sven L. <lu...@dp...> - 2001-03-12 11:27:27
|
On Mon, Mar 12, 2001 at 12:16:06PM +0100, Geert Uytterhoeven wrote: > On Mon, 12 Mar 2001, Sven LUTHER wrote: > > 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 ? > > Before we go to far into this discussion, all we want is a (fast) text console > implementation. That means > - rectangle copy > - rectangle fill > - monochrome expansion for text drawing > - pixmap drawing for penguin Yes, sure, ... > No OpenGL, mesa, DRM, DRI, textures, ...! Err, i was speaking of userland accelerated mesa support, not openGL in fbdev, which i know will not be welcome in the kernel. That said : Some cards do text drawing by applying textures, i think i saw some such in the X permedia2 driver, not sure though There were speaks of DMA, which we can do, as opposed to X which needs kernel support for it. This could (well maybe) be a good thing. But if i understood all things correctly, the drm kernel module was writen to permit X/OpenGL to do DMA accesses to the chip, that is filling buffers that are then DMA sent to the chip. I may be wrong, but i had the impression that it is not sane us to do DMA without speaking to DRM about it. That said, maybe using DMA is not the nicest thing to do, maybe it is wastefull for us, ... Also there is the fact that on most chips, the using of DRM/DRI on X and fbdev together is often severly broken, or is it ? That said, i am not aware of the last kernel politics regarding this, so please excuse me if i may have tripped into something best laid dormant. Friendly, Sven Luther |
|
From: Brad D. <br...@ne...> - 2001-03-12 21:14:19
|
On 12 Mar 2001 11:43:07 +0100, Sven LUTHER wrote: > 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 ? No. That is well beyond the scope of fbdev. All we really want is fast text. :-) We'll be using DMA more like how storage controllers use it, not how X uses it. > Will this enable us to do accelerated Mesa on fbdev ? Hmm. I suppose in theory you could, but it would be card dependent with lots of userland help. Brad Douglas br...@ne... http://www.linux-fbdev.org |
|
From: James S. <jsi...@li...> - 2001-03-12 20:15:56
|
>>I'm working on the removal of the console_spinlock so we can use DMA. >>This will greatly speed up fbcon. > >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 ? No. For some cards like the intel i810 we have to use DMA/irq because we have no choice. Their is no mmio mode for these types of cards. Once of the big changes for 2.5.X is the comcept of a console state and a graphics state. When you open explictly /dev/fb or /dev/drm the console system shutdowns, via being replaced by dummy con. This prevents any conflicts while using the accel engine directly. >Will this enable us to do accelerated Mesa on fbdev ? No. But I do have plans to merge fbdev and dri at some point in the future :-) >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 ? Yep. From what I seen in the specs this is the case. In fact their is no real framebuffer for the voodoo 1. With some magic we get a fbdev driver going. >But notice that textures can be expensive to use, if other means are >easily available, which are handled only in the fb access units. I agree. I'm just showing it is possible to make drawimage flexiable enough to do this. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Brad D. <br...@ne...> - 2001-03-12 21:25:30
|
On 12 Mar 2001 04:19:06 -0800, James Simmons wrote: > > >>I'm working on the removal of the console_spinlock so we can use DMA. > >>This will greatly speed up fbcon. > > > >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 ? > > No. For some cards like the intel i810 we have to use DMA/irq because we > have no choice. Their is no mmio mode for these types of cards. Once of > the big changes for 2.5.X is the comcept of a console state and a graphics > state. When you open explictly /dev/fb or /dev/drm the console system > shutdowns, via being replaced by dummy con. This prevents any conflicts > while using the accel engine directly. Ok, good. This is something I was going to bring up. Most cards will require that they be in PIO mode before starting X. Being in ProMo4 will surely render the machine a temporary doorstop. It will probably have to be extended some way to change PCI access modes when X starts regardless of /dev/drm. How can we accomplish this (without modifying the X driver)? > >Will this enable us to do accelerated Mesa on fbdev ? > > No. But I do have plans to merge fbdev and dri at some point in the > future :-) Hmm. I'm going to take a gander at DRI API again. I know it has changed signifigantly since the last time I looked at it. Maybe it wouldn't be such a bad idea to use DRI to get in and out of ProMo4, allocate buffers, etc. I wonder what kinds of implications that would have on X. Brad Douglas br...@ne... http://www.linux-fbdev.org |
|
From: Ghozlane T. <gt...@pr...> - 2001-03-13 10:23:43
|
From: "James Simmons" <jsi...@li...> > >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 ? > > Yep. From what I seen in the specs this is the case. In fact their is no > real framebuffer for the voodoo 1. With some magic we get a fbdev driver > going. speaking of that : what is the simplest/safest solution to allow the use of direct access to the accel engine with the fb driver ? in my example, how can I make the use of glide safe with the fb driver on voodoo 1 ? how does "normal" fb driver cope with this kind of things , say switching from the console using the frame buffer to X using "native" access to the board ? ghoz |
|
From: James S. <jsi...@li...> - 2001-03-12 20:27:45
|
>I think we should differentiate between pattern expansion fills and image
>writes (as said before). Also some card offer both a limited size pattern
>fill (mostly 32x32 i guess), but also a more generic patterned rendering,
>where any kind of bitmap can be expanded. (well a rectangular area of
>anysize). This would be faster by a factor of (depth of framebuffer) that
>using image writed for monochrome fonts.
No problem. I think the api is felxiable enough. Example psuedo code:
struct fb_image {
__u32 width; /* Size of image */
__u32 height;
__u16 x; /* Where to place image */
__u16 y;
__u32 fg_color; /* Only used when a mono bitmap */
__u32 bg_color;
__u8 depth; /* Dpeth of the image */
char *data; /* Pointer to image data */
};
xxxfb_drawimage(struct fb_info *p, struct fb_image *image)
{
if (image->depth == 1) {
/* Use pattern fill */
} else {
/* Draw a color image */
}
}
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [jsi...@li...] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
|
|
From: James S. <jsi...@li...> - 2001-03-10 17:42:03
|
>Well, but mostly the expensive part of it is passing from the system >memory to the card memory, where the bus is limiting us. I know. That is why I'm pushing this fbcon to accel-con move. >but you could use this 64 glyphs as a cache, or something such, uploading >only the most used chars or something such. > >That said, other cards can use standard FB memory for font cache, and >then either do a blit or a pattern expansion to the screen. True. You could do this for cards that have the avaliable memory. If fbcon is running at a resolution that occupies the entire memory then you are in trouble. You can do many fancy tricks. I leave it up to the driver writer to be fancy. The goal is to draw some image. Keep in mind I wanted to also want to have the function draw the penguin. It is very miss leading the name of the function. It should be drawimage instead. Also for cards that lack this function a software emulated drawimage has to be done. Could people post all the possible ways a "fontcache" could work. I see imagedraw is going to the touchy one. >What about pattern fills ? Where you provide a bitmap, and the accel >engine copies this bitmap, putting 1 color for the 1s and another (or >transparent) for 0s. Same thing. The goal of the function is to draw some image. How it is implemented is up to the driver. Another way to do it is make textures of fonts and using texture mapping to draw the characters. I seen something like this used for a X server before. The windowing was done with the z buffer which was used to act like hardware window IDs. Each window then was textured mapped with whatever the program was trying to display. The texture map changed when needed. X term wa steh trickiest. Alot of little texture maps but it still was fast. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Geert U. <ge...@li...> - 2001-03-11 20:16:20
|
On Sat, 10 Mar 2001, James Simmons wrote:
> True. You could do this for cards that have the avaliable memory. If fbcon
> is running at a resolution that occupies the entire memory then you are in
> trouble. You can do many fancy tricks. I leave it up to the driver writer
> to be fancy. The goal is to draw some image. Keep in mind I wanted to also
> want to have the function draw the penguin. It is very miss leading the
> name of the function. It should be drawimage instead. Also for cards that
> lack this function a software emulated drawimage has to be done. Could
> people post all the possible ways a "fontcache" could work. I see
> imagedraw is going to the touchy one.
>
> >What about pattern fills ? Where you provide a bitmap, and the accel
> >engine copies this bitmap, putting 1 color for the 1s and another (or
> >transparent) for 0s.
>
> Same thing. The goal of the function is to draw some image. How it is
> implemented is up to the driver. Another way to do it is make textures of
> fonts and using texture mapping to draw the characters. I seen something
> like this used for a X server before. The windowing was done with the z
> buffer which was used to act like hardware window IDs. Each window then
> was textured mapped with whatever the program was trying to display. The
> texture map changed when needed. X term wa steh trickiest. Alot of little
> texture maps but it still was fast.
With a font cache you store all fonts in an off-screen area of graphics memory,
and let the graphics acceleration engine do monochrome-to-color expansion for
each individual character.
For systems that don't have hardware acceleration for monochrome-to-color
expansion and that have bitplanes (the Amiga comes to mind :-), it's much
faster to not draw individual characters at the monochrome-to-color expansion
level, but to prepare a bitmap for a bunch of characters and let that expand by
software (using 32-bit accesses instead of 8-bit accesses for individual
characters).
So here we have a trade-off: do we want to draw individual character bitmaps
(possibly hardware accelerated), or do we glue individual characters together
and draw the composite bitmap?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Romain D. <do...@ir...> - 2001-03-12 08:52:49
|
Geert Uytterhoeven wrote: > So here we have a trade-off: do we want to draw individual character bitmaps > (possibly hardware accelerated), or do we glue individual characters together > and draw the composite bitmap? There's hardware that accelerate Glyph stuff, it might be useful to provide a way to use that (the pm3 does, even if I don't know how to use it) - I don't think that would be easy with concatenated strings. Just my .02 euros. -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Sven L. <lu...@dp...> - 2001-03-12 09:44:10
|
On Sun, Mar 11, 2001 at 09:15:43PM +0100, Geert Uytterhoeven wrote: > On Sat, 10 Mar 2001, James Simmons wrote: > > True. You could do this for cards that have the avaliable memory. If fbcon > > is running at a resolution that occupies the entire memory then you are in > > trouble. You can do many fancy tricks. I leave it up to the driver writer > > to be fancy. The goal is to draw some image. Keep in mind I wanted to also > > want to have the function draw the penguin. It is very miss leading the > > name of the function. It should be drawimage instead. Also for cards that > > lack this function a software emulated drawimage has to be done. Could > > people post all the possible ways a "fontcache" could work. I see > > imagedraw is going to the touchy one. > > > > >What about pattern fills ? Where you provide a bitmap, and the accel > > >engine copies this bitmap, putting 1 color for the 1s and another (or > > >transparent) for 0s. > > > > Same thing. The goal of the function is to draw some image. How it is > > implemented is up to the driver. Another way to do it is make textures of > > fonts and using texture mapping to draw the characters. I seen something > > like this used for a X server before. The windowing was done with the z > > buffer which was used to act like hardware window IDs. Each window then > > was textured mapped with whatever the program was trying to display. The > > texture map changed when needed. X term wa steh trickiest. Alot of little > > texture maps but it still was fast. > > With a font cache you store all fonts in an off-screen area of graphics memory, > and let the graphics acceleration engine do monochrome-to-color expansion for > each individual character. > > For systems that don't have hardware acceleration for monochrome-to-color > expansion and that have bitplanes (the Amiga comes to mind :-), it's much > faster to not draw individual characters at the monochrome-to-color expansion > level, but to prepare a bitmap for a bunch of characters and let that expand by > software (using 32-bit accesses instead of 8-bit accesses for individual > characters). > > So here we have a trade-off: do we want to draw individual character bitmaps > (possibly hardware accelerated), or do we glue individual characters together > and draw the composite bitmap? Why not provide both, and have the driver tell the rest of the stuff which way he prefers to do it via a flag or somethign such ? This way we can best support a wider array of hardware kind. (but then i may be influenced by my Xfree86 experience, and don't have the long range fbdev vision in mind a lot right now ...) Friendly, Sven Luther |
|
From: Sven L. <lu...@dp...> - 2001-03-12 10:36:30
|
On Sat, Mar 10, 2001 at 01:45:12AM -0800, James Simmons wrote:
>
> >Well, but mostly the expensive part of it is passing from the system
> >memory to the card memory, where the bus is limiting us.
>
> I know. That is why I'm pushing this fbcon to accel-con move.
>
> >but you could use this 64 glyphs as a cache, or something such, uploading
> >only the most used chars or something such.
> >
> >That said, other cards can use standard FB memory for font cache, and
> >then either do a blit or a pattern expansion to the screen.
>
> True. You could do this for cards that have the avaliable memory. If fbcon
> is running at a resolution that occupies the entire memory then you are in
> trouble. You can do many fancy tricks. I leave it up to the driver writer
> to be fancy. The goal is to draw some image. Keep in mind I wanted to also
> want to have the function draw the penguin. It is very miss leading the
> name of the function. It should be drawimage instead. Also for cards that
> lack this function a software emulated drawimage has to be done. Could
> people post all the possible ways a "fontcache" could work. I see
> imagedraw is going to the touchy one.
Like said before, what X is doing is :
we have blit accel, fill accel, mono8x8 pattern fills, ColorExpand Fills,
WriteImage and WriteBitmap. (well there are more, but these are supported by
the glint driver).
Well, in fbdev, we already support the first two, isn't it ? for emptying
screen and scrolling, and you do a wrtieimage or something like it for drawing
fonts, but that's it.
When drawing fonts, you copy the color info to the framebuffer, but mostly
each font is one color only, so you send the same color info to each position,
err that would be the same color to each lit pixel, and the background color
to the background. It is much more efficient to set the foreground/background
color to use and then write bitmaps that will be color expanded to it, either
trough a font cache or directly.
you could then provide a write image function, but this would only be used for
writing images (like the penguin logo) or maybe colored fonts (if or when
those exists).
That said, you have to be aware, that on most hardware that have a bypass unit
(err direct framebuffer access, that is) if you don't do fancy things (like
blending and logic opps) then the direct framebuffer access may be faster than
the image write, since you have to pass the data trough the bus anyway, and it
will either be written directly to the FB, or go trough the graphic core, in
which case, you have to send additional info for the graphic core to be
configured right.
> >What about pattern fills ? Where you provide a bitmap, and the accel
> >engine copies this bitmap, putting 1 color for the 1s and another (or
> >transparent) for 0s.
>
> Same thing. The goal of the function is to draw some image. How it is
> implemented is up to the driver. Another way to do it is make textures of
> fonts and using texture mapping to draw the characters. I seen something
> like this used for a X server before. The windowing was done with the z
> buffer which was used to act like hardware window IDs. Each window then
> was textured mapped with whatever the program was trying to display. The
> texture map changed when needed. X term wa steh trickiest. Alot of little
> texture maps but it still was fast.
Err, no, you want to use the same function to do two different things :
What i would propose, but then i only know well the glint family of chips is
the following :
* you have a function for setting the fore/background.
* you have a function for writing bitmap to the offscreen memory.
* you have a function for write expanding bitmaps to fore/background color
directly from bitmap data you provide the chip.
* you have one for doing color expansion from the offscreen memory.
Driver would provide both, or either one of them, or none, and provide a flag
telling the rest of it which one to use. Maybe be we could use a flag also to
set the relative expense of using each method, so the upper layer can choose
which one to use, depending of the font size or something such.
and writing data would be (in the direct case) :
* set the font color. (maybe 2 register writes, one for each color).
* while the font color does not change, just repeat :
- expand one char at a time (usually chips can do upto 32x32 chars or
somethign such, other may be limited to 8x8 one).
The cost of this would be 1 32bit register per 32pixels, or 1 register
write per line of font. You could even combine various 8 or 16 width
fonts in one if your hardware don't support automatic
padding/compression.
If you use font caching, you need to know what font are in the cache (using a
bitmap) if not all are, and jsut send the few register command to draw them,
or if it is not present, upload it, and then do the expansion.
This makes much more sense than a image write function that will maybe only be
used for the penguin, and may be done faster using the direct framebuffer
access, if yo don't do fancy stuff (which may not be supported anyway by the
fbdev, or used in the common layer, userland apps may do this kind of things
though.)
As for the planar hardware, i guess this is similar to just writing to one
plane, or only writing to the planes that are needed by the color selected. I
guess it is faster when using only as much colors as there are planes ?
Ok, that's all i had to say about this, but iam not really that familiar with
fbdev, and this may have been done already, or thought off and discarded. If
such is the case, plase excuse me of taking your time this way ...
Friendly,
Sven Luther
|
|
From: James S. <jsi...@li...> - 2001-03-10 17:58:59
|
> That's a more generalized _clear + _clear_margins ? Yes. Also you can use different ROP with rectfill. Right now XOR and COPY are supported. XOR is used for fbcon_recv. > better _bmove ? (if only I could get _that_ one to work > reliably) Yep. > > The last function is fb_imageblit > > which transfers data from host memory to screen memory. > > Thats seems new to me (I only know 2.2 and 2.4, as I only grep'ped > through Ruby). Could be useful... Yes it is a ruby thing. >I calculated that for small fonts, just sending the font data may require >less register writes than seting up a blit). This is naturally not true >for bigger fonts (like 32x32 fonts, but do we use that ?) Well if we want to draw the penguin (80x80) then yes. Image draw and except any size image. This is a strenght. We don't have to say you can only use 8,16,32 fonts. You can use any size. This is much more powerful. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Geert U. <ge...@li...> - 2001-03-11 20:17:53
|
On Sat, 10 Mar 2001, James Simmons wrote:
> >I calculated that for small fonts, just sending the font data may require
> >less register writes than seting up a blit). This is naturally not true
> >for bigger fonts (like 32x32 fonts, but do we use that ?)
>
> Well if we want to draw the penguin (80x80) then yes. Image draw and
> except any size image. This is a strenght. We don't have to say you can
> only use 8,16,32 fonts. You can use any size. This is much more powerful.
Note that I prefer to have limitations on size and position. Do you really want
to code the `generic' case for bitplanes? Limiting sizes and positions to
multiple of 8 helps a lot here to keep the code simple. And you don't really
need more for a text console.
For modern cards with packed pixels this doesn't matter that much, especially
in a mode with 32 bits per pixel :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Sven L. <lu...@dp...> - 2001-03-12 10:44:57
|
On Sat, Mar 10, 2001 at 02:02:10AM -0800, James Simmons wrote: > > > That's a more generalized _clear + _clear_margins ? > > Yes. Also you can use different ROP with rectfill. Right now XOR and COPY > are supported. XOR is used for fbcon_recv. > > > better _bmove ? (if only I could get _that_ one to work > > reliably) > > Yep. > > > > The last function is fb_imageblit > > > which transfers data from host memory to screen memory. > > > > Thats seems new to me (I only know 2.2 and 2.4, as I only grep'ped > > through Ruby). Could be useful... > > Yes it is a ruby thing. > > >I calculated that for small fonts, just sending the font data may require > >less register writes than seting up a blit). This is naturally not true > >for bigger fonts (like 32x32 fonts, but do we use that ?) > > Well if we want to draw the penguin (80x80) then yes. Image draw and > except any size image. This is a strenght. We don't have to say you can > only use 8,16,32 fonts. You can use any size. This is much more powerful. I think we should differentiate between pattern expansion fills and image writes (as said before). Also some card offer both a limited size pattern fill (mostly 32x32 i guess), but also a more generic patterned rendering, where anykind of bitmap can be expanded. (well a rectangular area of anysize). This would be faster by a factor of (depth of framebuffer) that using image writed for monochrome fonts. Friendly, Svne Luther |
|
From: Sven L. <lu...@dp...> - 2001-03-07 20:21:21
|
On Wed, Mar 07, 2001 at 02:53:17AM -0800, James Simmons wrote: > > >I was wondering if it could be worthwhile (speedwise) to implement > >a fonctcache for fast character display. > > If you think about it we already have something like that with teh current > system execpt instead of it being in card memory it is in system memory. > Using a image blitter you can translate that data from normal RAM to the Well, but mostly the expensive part of it is passing from the system memory to the card memory, where the bus is limiting us. > video card memory. The nice thing about a image blitter is you can do > depth translations (mono to depth X). I though about using a Glyhp > approach. The voodoo 3 card has a pattern buffer for up to 64 Glyphs which > can then be very quickly painted on the display. The problem is the > console system supports alot more characters than that. In the future I > hope even more. but you could use this 64 glyphs as a cache, or something such, uploading only the most used chars or something such. That said, other cards can use satndard FB memory for font cache, and then either do a blit or a pattern expansion to the screen. That's how X does it at least. > >fbcon_cfbXX_putc() in ofscreen memory once per character (on- > >demand, likely), and just _bmove() them to proper place. > > > >On the pm3, that would cost 4 memory access to the registers > >(in PCI memory space) (6 if not properly aligned, for the > >scissors stuff) plus the hardware copy, compared to whatever > >fbcon_cfbXX_putc() use. > > > >Would that be worth the hassle of adding the fontcache ? > >(I have no idea what putc() actually cost). > > > >Would that be worth adding a more generalized implemetation > >on top of existing _bmove() so that every hardware-accelerated > >board could use it ? (those without HW-accel putc(), that is) > > > >Is that already planned for the 2.5.x API ? (haven't seen > >anything to that extent in 'ruby' but I might have > >overlooked something) > > Yes. This is the way the ruby tree handles it. I just got it working in > the ruby tree. The only problem is their is some bug in take_over_console > I have to chase down but I do have fbcon running using a voodoo 3 along > side my MDA. There are 3 functions. One is rectfill which does things like > clear the margins etc. Then their is fb_copyarea which copys a area of the > screen to another area of the screen. The last function is fb_imageblit > which transfers data from host memory to screen memory. This is used to > draw the penguin and text. Yes it is simpler to use the accel engine. A > good example is the new tdfx driver in the ruby CVS. What about pattern fills ? Where you provide a bitmap, and the accel engine copies this bitmap, putting 1 color for the 1s and another (or transparent) for 0s. Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2001-03-08 09:29:33
|
James Simmons wrote: > If you think about it we already have something like that with teh current > system execpt instead of it being in card memory it is in system memory. The idea was to avoid going over the bus : PCI is slow (in particular the sh*tty implementation in my PM7500) > 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 though about using a Glyhp > approach. The voodoo 3 card has a pattern buffer for up to 64 Glyphs which > can then be very quickly painted on the display. The problem is the > console system supports alot more characters than that. In the future I > hope even more. There's some "glyph" stuff in the pm3, unfortunately, I can only get nice little rectangle ATM. Not very useful. I haven't managed to get it to use the glyph data I (try to) send :-( If only 3DLabs would distribute the doc :-( > Yes. This is the way the ruby tree handles it. I just got it working in > the ruby tree. The only problem is their is some bug in take_over_console > I have to chase down but I do have fbcon running using a voodoo 3 along > side my MDA. There are 3 functions. One is rectfill which does things like > clear the margins etc. That's a more generalized _clear + _clear_margins ? > Then their is fb_copyarea which copys a area of the > screen to another area of the screen. better _bmove ? (if only I could get _that_ one to work reliably) > The last function is fb_imageblit > which transfers data from host memory to screen memory. Thats seems new to me (I only know 2.2 and 2.4, as I only grep'ped through Ruby). Could be useful... > This is used to > draw the penguin and text. Yes it is simpler to use the accel engine. A > good example is the new tdfx driver in the ruby CVS. The idea was to avoid the bus ; maybe I'm biased (or totally wrong), but the less things go over the bus, the better I feel... thanks for the answer, -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Sven L. <lu...@dp...> - 2001-03-08 10:40:33
|
On Thu, Mar 08, 2001 at 10:31:12AM +0100, Romain Dolbeau wrote: > James Simmons wrote: > > > If you think about it we already have something like that with teh current > > system execpt instead of it being in card memory it is in system memory. > > The idea was to avoid going over the bus : PCI is slow (in particular > the sh*tty implementation in my PM7500) > > > 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) Are you trully using color glyphs ? the glyphs are mostly just a bitmap, you can store them in system or offscreen memory, and after that, do a pattern fill using any color you want for foreground/background, or even use the Glyph stuff ... > > I though about using a Glyhp > > approach. The voodoo 3 card has a pattern buffer for up to 64 Glyphs which > > can then be very quickly painted on the display. The problem is the > > console system supports alot more characters than that. In the future I > > hope even more. > > There's some "glyph" stuff in the pm3, unfortunately, I can only > get nice little rectangle ATM. Not very useful. I haven't managed > to get it to use the glyph data I (try to) send :-( :))) > If only 3DLabs would distribute the doc :-( :((( > > Yes. This is the way the ruby tree handles it. I just got it working in > > the ruby tree. The only problem is their is some bug in take_over_console > > I have to chase down but I do have fbcon running using a voodoo 3 along > > side my MDA. There are 3 functions. One is rectfill which does things like > > clear the margins etc. > > That's a more generalized _clear + _clear_margins ? > > > Then their is fb_copyarea which copys a area of the > > screen to another area of the screen. > > better _bmove ? (if only I could get _that_ one to work > reliably) > > > The last function is fb_imageblit > > which transfers data from host memory to screen memory. > > Thats seems new to me (I only know 2.2 and 2.4, as I only grep'ped > through Ruby). Could be useful... > > > This is used to > > draw the penguin and text. Yes it is simpler to use the accel engine. A > > good example is the new tdfx driver in the ruby CVS. > > The idea was to avoid the bus ; maybe I'm biased (or totally wrong), > but the less things go over the bus, the better I feel... What kind of fonts are in use anyway, mostly they are 8x8 or 8x16 or somethign such, isn't it, i think there is also the sunc fonts (22x12 or something such). I calculated that for small fonts, just sending the font data may require less register writes than seting up a blit). This is naturally not true for bigger fonts (like 32x32 fonts, but do we use that ?) Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2001-03-08 15:54:22
|
Sven LUTHER wrote: > On Thu, Mar 08, 2001 at 10:31:12AM +0100, Romain Dolbeau wrote: > > Yes, that was killed my current (test) implementation : 16 colors > > mean 16 copies of each glyph. Yuck (8 Mb for 512 glyhs, 16x16 32bpp) > > Are you trully using color glyphs ? No. I was fbcon_cfb32_putc()'ing in offscreen memory on the first call, and pm3fb_cfbX_bmove()'ing to put character in place. but: 1) it doesn't work 2) even if it did, that would eat up half my board memory, plus 512bit for the flags (not-yet-written in offscreen) 3) I haven't yet tried to check color, so the current implementation would use the color of the first displayed char (OK, it uses less memory that way - but it would look ugly, given that I use color-ls...) So I guess that it's not really worth the hassle, there's likely a better way. > the glyphs are mostly just a bitmap, you can store them in system or offscreen > memory, and after that, do a pattern fill using any color you want for > foreground/background I have no yet fully understood pattern fill on the pm3 > or even use the Glyph stuff ... I have no clue how to use it properly Maybe 3DLabs will answer m ...(I've tried contacting specific people that I believe are in the tech dpt. mail didn't bounce...). > What kind of fonts are in use anyway, mostly they are 8x8 or 8x16 or somethign > such, isn't it, i think there is also the sunc fonts (22x12 or something > such). 8x16 seems default, 8x8 works with pm3fb. Don't think Sun22x12 are supposed to work on anything but Sun FB (cg3, cg6, ffb & friends) > I calculated that for small fonts, just sending the font data may require less > register writes than seting up a blit). This is naturally not true for bigger > fonts (like 32x32 fonts, but do we use that ?) Non-scissored _bmove is 4 register writes on pm3, where a 8x16 font seems to need 8 32 bits memory accesses _per rows_ with cfb32, i.e. 128 memory acesses. And 32 in cfb8. So I'm still looking for a way to do in-FB memory font rendering... -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Sven L. <lu...@dp...> - 2001-03-08 16:12:53
|
On Thu, Mar 08, 2001 at 04:56:01PM +0100, Romain Dolbeau wrote: > Sven LUTHER wrote: > > On Thu, Mar 08, 2001 at 10:31:12AM +0100, Romain Dolbeau wrote: > > > Yes, that was killed my current (test) implementation : 16 colors > > > mean 16 copies of each glyph. Yuck (8 Mb for 512 glyhs, 16x16 32bpp) > > > > Are you trully using color glyphs ? > > No. I was fbcon_cfb32_putc()'ing in offscreen memory on the first > call, and pm3fb_cfbX_bmove()'ing to put character in place. > but: > > 1) it doesn't work > 2) even if it did, that would eat up half my board memory, > plus 512bit for the flags (not-yet-written in offscreen) > 3) I haven't yet tried to check color, so the current implementation > would use the color of the first displayed char (OK, it uses less > memory that way - but it would look ugly, given that I use > color-ls...) > > So I guess that it's not really worth the hassle, there's likely > a better way. :))) > > the glyphs are mostly just a bitmap, you can store them in system or offscreen > > memory, and after that, do a pattern fill using any color you want for > > foreground/background > > I have no yet fully understood pattern fill on the pm3 mostly you do expand a bitmap so that all 1s become the foreground color and all 0s are either transparent or background color. look at writebitmap and cpu2screencolor expansion code in the glint driver. I cannot say more about it. > > or even use the Glyph stuff ... > > I have no clue how to use it properly Same here ... > Maybe 3DLabs will answer m ...(I've tried contacting specific people > that I believe are in the tech dpt. mail didn't bounce...). mmm, i hope you luck on this. > > What kind of fonts are in use anyway, mostly they are 8x8 or 8x16 or somethign > > such, isn't it, i think there is also the sunc fonts (22x12 or something > > such). > > 8x16 seems default, 8x8 works with pm3fb. Don't think Sun22x12 are > supposed > to work on anything but Sun FB (cg3, cg6, ffb & friends) Well, yes they work nicely on high resolution fbdevs, try reading 8x8 fonts on resolutions above 1024x768 on a 15" monitor ... > > I calculated that for small fonts, just sending the font data may require less > > register writes than seting up a blit). This is naturally not true for bigger > > fonts (like 32x32 fonts, but do we use that ?) > > Non-scissored _bmove is 4 register writes on pm3, where a 8x16 font > seems to need 8 32 bits memory accesses _per rows_ with cfb32, i.e. > 128 memory acesses. And 32 in cfb8. So I'm still looking > for a way to do in-FB memory font rendering... glyph should bring that donw to 4 32 bit register writes, and 2 for 8x8 fonts. Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2001-03-08 16:16:40
|
Sven LUTHER wrote: > mostly you do expand a bitmap so that all 1s become the foreground color and > all 0s are either transparent or background color. look at writebitmap and > cpu2screencolor expansion code in the glint driver. I cannot say more about > it. Maybe it won't be needed to tell in the near future :-) :-) > mmm, i hope you luck on this. Thanks, maybe it helped :-) > Well, yes they work nicely on high resolution fbdevs, try reading 8x8 fonts on > resolutions above 1024x768 on a 15" monitor ... 1024x768 15" is my setup, and 8x8 font are readable IHMO. Not comfortable, but I can read them without much effort... > glyph should bring that donw to 4 32 bit register writes, and 2 for 8x8 fonts. that would be a win... -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Geert U. <ge...@li...> - 2001-03-08 16:29:31
|
On Thu, 8 Mar 2001, Romain Dolbeau wrote:
> > What kind of fonts are in use anyway, mostly they are 8x8 or 8x16 or somethign
> > such, isn't it, i think there is also the sunc fonts (22x12 or something
> > such).
>
> 8x16 seems default, 8x8 works with pm3fb. Don't think Sun22x12 are
> supposed
> to work on anything but Sun FB (cg3, cg6, ffb & friends)
Works fine with all fbcon-cfb* drivers, and many accelerated drivers (atyfb,
matroxfb). I'm using it in 1024x768 on my ATI Rage II+.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X