linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Dri-devel] Re: [adaplas@pol.net: Re: [Linux-fbdev-devel] Fwd: Re: [Dri-devel] future of DRI?]

[Antonino D. <ad...@po...>]

On Mon, 2003-03-03 at 09:25, Alan Cox wrote:

> On early athlon you prefetch non cached memory and the cpu corrupts its
> cache, on PII, PII mmap frame buffer against a cached page, but the
> right kind of instruction in a loop with the instruction bridging the
> two memory types and run it in a tight loop

Wonderful :-(  Thanks for the info.

Tony
 

Re: [Linux-fbdev-devel] [PATCH] Tile Blitting

[Antonino D. <ad...@po...>]

On Sun, 2003-03-02 at 20:14, Geert Uytterhoeven wrote:
> On Thu, 27 Feb 2003, James Simmons wrote:
> > > On Don, 2003-02-27 at 15:15, Antonino Daplas wrote: 
> > > > On Thu, 2003-02-27 at 09:18, James Simmons wrote:
> > > >  
> > > > > > Thus, the restriction that the buffer must be completely copied by the
> > > > > > driver before returning.  And because of this restriction, an extra copy
> > > > > > which might be unnecessary cannot be avoided (this was noted by Petr).
> > > > > > 
> > > > > > Treating the buffer as a ringbuffer, we eliminate these restrictions.
> > > > > 
> > > > > I didn't realize that the below was a ringbuffer implementation. The name
> > > > > threw me off. 
> > > > 
> > > > Well, it's not strictly a ringbuffer implementation.  This would require
> > > > a head and tail pointer where fbcon will adjust the tail and the
> > > > driver/hardware will adjust the head.  This will be very difficult to
> > > > implement in a device independent manner.  So we just cheat by issuing
> > > > an fb_sync() per loop to flush all pending commands.
> > > 
> > > That still seems suboptimal though. What the DRM often does is have the
> > > chip write an age value to a scratch register when it's done processing
> > > something. Maybe something like that could be used to avoid waiting for
> > > the chip to go idle at all?
> > 
> > Don't waste your time. I'm removing all the changes that have been done 
> > since 2.5.51. After that I will no longer be co-maintainter of the 
> > framebuffer layer. 
> 
> Are you sure about that?!?!?
> 

I agree.  Actually, I'm not worried about Tile blitting.  It should be
mature since it's basically a rehash of the 2.4 API.  If I'm going to
worry about something, it's the standard accel_putcs() code, especially
if thread-safety is an issue.

Is thread-safety a real problem?  That was also my concern before, which
is why I looked at vt.c.  From what I can see, there's always an
"acquire_console_sem()" before calling any of the console methods. The
console semaphore is supposed to guarantee serialization and exclusive
access to the console (see linux/kernel/printk.c).

Tony

Re: [Linux-fbdev-devel] Re: FBdev updates.

[Geert U. <ge...@li...>]

On Mon, 3 Mar 2003, Petr Vandrovec wrote:
>   My main concern now is 12x22 font... Accelerator setup
> is so costly for each separate painted character that for 8bpp 
> accelerated version is even slower than unaccelerated one :-(
> (and almost twice as slow when compared with 2.4.x).

Have you already tried Antonino's patches to use one imageblit for multiple
characters with (fontwidth % 8) != 0? It should help.

BTW, I still have to try it with amifb.

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

Re: [Linux-fbdev-devel] Re: FBdev updates.

[Petr V. <van...@vc...>]

On Fri, Feb 21, 2003 at 08:24:17AM +0800, Antonino Daplas wrote:
> On Fri, 2003-02-21 at 02:29, Petr Vandrovec wrote:
> > 
> > I was for five weeks in U.S., so I did not do anything with
> > matroxfb during that time. I plan to use fillrect and copyrect
> > from generic code (although it means unnecessary multiply on
> > generic side, and division in matroxfb, but well, if we gave
> > up on reasonable speed for fbdev long ago...). But I simply
> > want loadfont and putcs hooks for character painting. And if 
> > fbdev maintainer does not want to give me them, well, then 
> > matroxfb and fbdev are not compatible.
> 
> Petr,
> 
> I submitted the Tile Blitting patch to James some time ago, it has
> tilefill, tilecopy and tileblit hooks.  These hooks should eliminate the
> "multiply in fbcon, divide in driver" bottleneck.
>
> It should result in the same behavior as you would expect in the the 2.4
> API, so you can use text mode with your matroxfb driver.  These same
> hooks will also help optimize drawing if we need to use fonts like
> 12x22.

Hi,
  while waiting on these updates I updated matroxfb a bit
(ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz),
so that it now uses fb_* for cfb modes, and putcs/... hooks for
text mode. I have still dozen of changes in fbcon.c which I have
to eliminate (mainly logo painting and cursor handling - for now
I still use revc method, mainly because of I did not make into it yet).

  But main thing is that I'd like to apologize to James - character
painting is much faster for 8x16 fonts under 2.5.x than it was under 2.4.x,
8bpp unaccelerated 8x16 under 2.5.x is even faster than accelerated
under 2.4.x.

  Algorithm for obtaining times was same as described in 
Documentation/fb/matroxfb.txt, with two differences: (1) hardware is 
G550 in P4/1.6GHz, and (2) there was 30MBps video stream feed to 
secondary G550 head of G550 during 2.4.19-pre6 tests, so I made 2.5.x 
tests twice, once with fbtv running and once without.

  My main concern now is 12x22 font... Accelerator setup
is so costly for each separate painted character that for 8bpp 
accelerated version is even slower than unaccelerated one :-(
(and almost twice as slow when compared with 2.4.x).

  And one (or two...) generic questions: why is not pseudo_palette
u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
And why we do not fill this pseudo_palette with
i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp
pseudocolor? This allowed me to remove couple of switches and tests
from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect,
but I did not changed these two in my benchmarks below).

						Best regards,
							Petr Vandrovec
							van...@vc...


NOACCEL, 8x16
	2.4.19+fbtv	2.5.63+fbtv	2.5.63
8bpp	10.02		 6.96		 5.62
16bpp	20.05		13.25		10.62
24bpp	30.03		19.05		15.13
32bpp	45.00		25.74		20.54

ACCEL, 8x16
	2.4.19+fbtv	2.5.63+fbtv	2.5.63
8bpp	 7.48		 3.38		 3.00
16bpp	 7.50		 3.38		 3.01
24bpp	 7.53		 3.56		 3.53
32bpp	 8.95		 4.37		 4.33

NOACCEL, 12x22
	2.4.19+fbtv	2.5.63+fbtv	2.5.63
8bpp	11.54		13.35		10.93
16bpp	20.00		22.02		18.03
24bpp	30.03		35.83		29.53
32bpp	40.12		44.48		36.75

ACCEL, 12x22
	2.4.19+fbtv	2.5.63+fbtv	2.5.63
8bpp	 8.57		14.87		12.90
16bpp	 8.57		14.93		12.92
24bpp	 8.56		15.13		13.10
32bpp	 8.56		15.52		13.76

Re: [Dri-devel] Re: [adaplas@pol.net: Re: [Linux-fbdev-devel] Fwd: Re: [Dri-devel] future of DRI?]

[Alan C. <al...@lx...>]

On Mon, 2003-03-03 at 00:01, Antonino Daplas wrote:
> > For some cases. The truth is a bit more horrible, and current fbdev has
> > the same problem here. Any early Athlon, and almost any PII/PIII derived
> > chip allows the user to bring the box down if they have access to 
> > a mix of cached and uncached RAM.
> > 
> 
> I do not understand.  Do you mean such as writing to framebuffer memory
> and making it execute?

On early athlon you prefetch non cached memory and the cpu corrupts its
cache, on PII, PII mmap frame buffer against a cached page, but the
right kind of instruction in a loop with the instruction bridging the
two memory types and run it in a tight loop

Re: [adaplas@pol.net: Re: [Linux-fbdev-devel] Fwd: Re: [Dri-devel] future of DRI?]

[Antonino D. <ad...@po...>]

On Mon, 2003-03-03 at 08:27, Alan Cox wrote:

Sven,

Thanks for posting this.  I was actually waiting for the fbdev
maintainers (Geert and James) to respond first.  Seems Geert is
receptive to the idea.

> On Sun, 2003-03-02 at 21:57, Sven Luther wrote:
> > 1. fbdev will be secure.  Without access to the MMIO regions, crashing
> > the chipset is unlikely or at least difficult.  Even malicious blit
> > commands (blits to/from system memory) will not work.  
> 
> For some cases. The truth is a bit more horrible, and current fbdev has
> the same problem here. Any early Athlon, and almost any PII/PIII derived
> chip allows the user to bring the box down if they have access to 
> a mix of cached and uncached RAM.
> 

I do not understand.  Do you mean such as writing to framebuffer memory
and making it execute?

[snip]
> > In linux-2.5, fbcon is already separate from fbdev.  Perhaps in 2.7,
> > fbdev can be further reduced to a minimal core, moving the rest of the
> > code to fbaa.  Exporting the mmio regions to userland must be
> > disallowed. 
> 
> I disagree here. There are chips with useful safe mmio areas for many 
> things. "Exporting mmio regions must be up to the DRM layer"
> 

I was speaking more of fbdev which allows mmapping of the mmio besides
graphics memory.  DirectFB does its acceleration this way. So, yes, this
task can relegated to DRM. 
 
> > Any comments? 
> 
> Take a look at the SiS DRM. It has the memory manager and fb in one
> module but otherwise its not that disimilar to your basic description
> 

Thanks. 

Tony

Re: [adaplas@pol.net: Re: [Linux-fbdev-devel] Fwd: Re: [Dri-devel] future of DRI?]

[Alan C. <al...@lx...>]

On Sun, 2003-03-02 at 21:57, Sven Luther wrote:
> 1. fbdev will be secure.  Without access to the MMIO regions, crashing
> the chipset is unlikely or at least difficult.  Even malicious blit
> commands (blits to/from system memory) will not work.  

For some cases. The truth is a bit more horrible, and current fbdev has
the same problem here. Any early Athlon, and almost any PII/PIII derived
chip allows the user to bring the box down if they have access to 
a mix of cached and uncached RAM.

DRM and fbdev already make this tradeoff.

> 3.  Because DRM will handle both 2D and 3D and is pretty much the only
> one with hardware access, performance might actually increase.  

It gives you real DMA of 2D texture objects. It also improves the
situation with tv cards on buggy chipsets no end because you can run
two DMA operations via main memory on busted hardware (eg ALi Magik)

> In linux-2.5, fbcon is already separate from fbdev.  Perhaps in 2.7,
> fbdev can be further reduced to a minimal core, moving the rest of the
> code to fbaa.  Exporting the mmio regions to userland must be
> disallowed. 

I disagree here. There are chips with useful safe mmio areas for many 
things. "Exporting mmio regions must be up to the DRM layer"

> Any comments? 

Take a look at the SiS DRM. It has the memory manager and fb in one
module but otherwise its not that disimilar to your basic description

[adaplas@pol.net: Re: [Linux-fbdev-devel] Fwd: Re: [Dri-devel] future of DRI?]

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

Hello, ...

BTW, here is a response from Antonino Daplas, to Linus's message, that
Jon Smirl forwarded to the fbdev mailing list.

I think it doesn't make much sense to have such discution happening
separatedly on two different mailing list, where most peoples involved
only follow one of the two, so i forward the response from Antonino and
also start a cross-thread (or whatever that is called). I hope it is ok
for all of you.

Friendly,

Sven Luther

----- Forwarded message from Antonino Daplas <ad...@po...> -----

On Sun, 2003-03-02 at 02:42, Jon Smirl wrote: 
> --- Linus Torvalds <tor...@tr...> wrote:
> > From: Linus Torvalds <tor...@tr...>
> > To: Keith Whitwell <ke...@tu...>
> > CC: Jon Smirl <jon...@ya...>, Ian Romanick
> > <id...@us...>,
> >         "DRI developer's list"
> > <dri...@li...>
> > Subject: Re: [Dri-devel] future of DRI?
> > Date: Sat, 1 Mar 2003 10:15:06 -0800 (PST)
> > 
> > 
> > On Sat, 1 Mar 2003, Keith Whitwell wrote:
> > > 
> > > Interesting you mention it.  This is what Brian &
> > I've done in the Mesa 
> > > embedded branch -- layered the radeon dri driver
> > on top of fbdev.  I can also 
> > > build regular DRI drivers from a minimal tree &
> > sane set of makefiles.
> > 
> > Personally, I'd rather see DRI _underneath_ fbdev
> > rather than on top of. 
> > Since fbdev would require at least to know of (and
> > obey) the DRI locking 
> > code - and would likely want to use all the same DRI
> > command execution for 
> > things like blits etc (this is on the assumption
> > that 2d and 3d will 
> > eventually use the same engine, which is probably a
> > safe assumption).
> > 
> > I _assume_ that what you really mean is that you use
> > fbdev really only to
> > set up the screen modes and do things like
> > initialize the graphics
> > buffers.
> > 
> > 		Linus
> > 
Yes, this is the sanest way.  In my opinion, this is how fbdev and DRI
should operate: 

1. fbdev 
- provide a means to initialize and change the video state. 

- provide pointers to graphics/rendering memory, MMIO, DMA/ringbuffers 

- graphics memory may or may not be available to everyone, but the MMIO
and command buffers will only be available to DRI 

- fbdev must not touch any registers besides those required to
initialize the hardware.  No 2D, no 3D. 

2. fbaa 

- or framebuffer acceleration architecture or whatever you want to call
it.  This will be equivalent to Xfree86's XAA. It provides a 2D
abstraction layer for clients residing in kernel space (ie fbcon). It
will have software versions and optionally accelerated versions.  The
accelerated version has intimate knowledge of the 2D engine, but instead
of accessing the hardware directly, it will rely on DRM to pass commands
to the hardware. 

- in its current form, this will be the fb_imageblit(), fb_copyarea()
and fb_fillrect(). 

3. fbcon 

- this is the console driver that runs on top of fbaa 

4. DRM - will get mmio pointer and command buffers from fbdev and will
generally retain its original functions (interrupt handling, locking,
arbitration, DMA interface, the works).  It must also provide an
interface for fbaa. 

5. Userland apps - should only see the graphics memory pointer via
fbdev.  If they need to access the hardware, they have to go through
DRM. 

Advantages:  

1. fbdev will be secure.  Without access to the MMIO regions, crashing
the chipset is unlikely or at least difficult.  Even malicious blit
commands (blits to/from system memory) will not work.  

2. Single point of entry for hardware access (DRI).  You can run
multiple clients trying to access the hardware simultaneously via DRM.  
And because of DRM's features, it will take care of command
verification, arbitration, locking, context switching, etc.  

3.  Because DRM will handle both 2D and 3D and is pretty much the only
one with hardware access, performance might actually increase.  


Disadvantages: 

1. very linux specific.  Xfree86 was designed to run on different
platforms.  Having one code for linux and another for the rest will be
difficult for XFree86 developers to accept. 

2. this will break fb-based apps that require chipset access, ie
DirectFB. 

3. a lot of code are difficult to implement in kernel space, ie
initialization of secondary cards.  Full video bios access can only be
done, from a practical standpoint, in user space (the Intel 830, for
instance, may require this). 

4. Not all fbdev drivers has a DRI counterpart.  For these chipsets,
fbaa still has to access the hardware directly. 


In linux-2.5, fbcon is already separate from fbdev.  Perhaps in 2.7,
fbdev can be further reduced to a minimal core, moving the rest of the
code to fbaa.  Exporting the mmio regions to userland must be
disallowed. 

Secondly, a module to access DRM services from within the kernel will be
needed. 

Any comments? 

Tony  



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-fbdev-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

----- End forwarded message -----

Re: [Linux-fbdev-devel] Fwd: Re: [Dri-devel] future of DRI?

[Geert U. <ge...@li...>]

On Sun, 2 Mar 2003, Sven Luther wrote:
> I personnaly like this proposal, but you really need to comunicate it
> beyond the linux-fbdev list. The DRI list is where this discution got
> started, the above mail from Linus was forwarded from there, and there
> are people doing embeded mesa on top of fbdev there, and xfree86 is just
> starting to think about 5.0.

Me too!

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

Re: [Linux-fbdev-devel] [PATCH] Tile Blitting

[Geert U. <ge...@li...>]

On Thu, 27 Feb 2003, James Simmons wrote:
> > On Don, 2003-02-27 at 15:15, Antonino Daplas wrote: 
> > > On Thu, 2003-02-27 at 09:18, James Simmons wrote:
> > >  
> > > > > Thus, the restriction that the buffer must be completely copied by the
> > > > > driver before returning.  And because of this restriction, an extra copy
> > > > > which might be unnecessary cannot be avoided (this was noted by Petr).
> > > > > 
> > > > > Treating the buffer as a ringbuffer, we eliminate these restrictions.
> > > > 
> > > > I didn't realize that the below was a ringbuffer implementation. The name
> > > > threw me off. 
> > > 
> > > Well, it's not strictly a ringbuffer implementation.  This would require
> > > a head and tail pointer where fbcon will adjust the tail and the
> > > driver/hardware will adjust the head.  This will be very difficult to
> > > implement in a device independent manner.  So we just cheat by issuing
> > > an fb_sync() per loop to flush all pending commands.
> > 
> > That still seems suboptimal though. What the DRM often does is have the
> > chip write an age value to a scratch register when it's done processing
> > something. Maybe something like that could be used to avoid waiting for
> > the chip to go idle at all?
> 
> Don't waste your time. I'm removing all the changes that have been done 
> since 2.5.51. After that I will no longer be co-maintainter of the 
> framebuffer layer. 

Are you sure about that?!?!?

What about adding a pointer to a

    struct con_ops {
      set_font();
      putc();
      putcs();
    } 
    
to struct fb_info as an interim solution, until tile blitting has matured? That
would make Petr (matroxfb) and Davem (sbusfb) happy?

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

[Linux-fbdev-devel] [PATCH] typo in linux-2.5.63/drivers/video/console/fbcon.c (fwd)

[Geert U. <ge...@li...>]

---------- Forwarded message ----------
Date: Sun, 2 Mar 2003 04:02:41 -0800
From: Norbert Kiesel <nk...@tb...>
To: ge...@li...
Subject: [PATCH] typo in linux-2.5.63/drivers/video/console/fbcon.c

Hi,
found a small typo in this driver.

so long
	Norbert

--- linux-2.5.63/drivers/video/console/fbcon.c~	2003-02-24 11:05:37.000000000 -0800
+++ linux-2.5.63/drivers/video/console/fbcon.c	2003-03-02 03:03:34.000000000 -0800
@@ -456,7 +456,7 @@
 	region.color = attr_bgcol_ec(p, vc);
 	region.rop = ROP_COPY;
 
-	if (rw & !bottom_only) {
+	if (rw && !bottom_only) {
 		region.dx = info->var.xoffset + rs;
 		region.dy = 0;
 		region.width = rw;

Re: [Linux-fbdev-devel] Fwd: Re: [Dri-devel] future of DRI?

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

On Sun, Mar 02, 2003 at 06:39:51AM +0800, Antonino Daplas wrote:
> On Sun, 2003-03-02 at 02:42, Jon Smirl wrote: 
> > --- Linus Torvalds <tor...@tr...> wrote:
> > > From: Linus Torvalds <tor...@tr...>
> > > To: Keith Whitwell <ke...@tu...>
> > > CC: Jon Smirl <jon...@ya...>, Ian Romanick
> > > <id...@us...>,
> > >         "DRI developer's list"
> > > <dri...@li...>
> > > Subject: Re: [Dri-devel] future of DRI?
> > > Date: Sat, 1 Mar 2003 10:15:06 -0800 (PST)
> > > 
> > > 
> > > On Sat, 1 Mar 2003, Keith Whitwell wrote:
> > > > 
> > > > Interesting you mention it.  This is what Brian &
> > > I've done in the Mesa 
> > > > embedded branch -- layered the radeon dri driver
> > > on top of fbdev.  I can also 
> > > > build regular DRI drivers from a minimal tree &
> > > sane set of makefiles.
> > > 
> > > Personally, I'd rather see DRI _underneath_ fbdev
> > > rather than on top of. 
> > > Since fbdev would require at least to know of (and
> > > obey) the DRI locking 
> > > code - and would likely want to use all the same DRI
> > > command execution for 
> > > things like blits etc (this is on the assumption
> > > that 2d and 3d will 
> > > eventually use the same engine, which is probably a
> > > safe assumption).
> > > 
> > > I _assume_ that what you really mean is that you use
> > > fbdev really only to
> > > set up the screen modes and do things like
> > > initialize the graphics
> > > buffers.
> > > 
> > > 		Linus
> > > 
> Yes, this is the sanest way.  In my opinion, this is how fbdev and DRI
> should operate: 

Maybe you should have cross posted this to the DRI mailing list, and
maybe even the xfree86 one ?
> 
> 1. fbdev 
> - provide a means to initialize and change the video state. 
> 
> - provide pointers to graphics/rendering memory, MMIO, DMA/ringbuffers 
> 
> - graphics memory may or may not be available to everyone, but the MMIO
> and command buffers will only be available to DRI 
> 
> - fbdev must not touch any registers besides those required to
> initialize the hardware.  No 2D, no 3D. 
> 
> 2. fbaa 
> 
> - or framebuffer acceleration architecture or whatever you want to call
> it.  This will be equivalent to Xfree86's XAA. It provides a 2D
> abstraction layer for clients residing in kernel space (ie fbcon). It
> will have software versions and optionally accelerated versions.  The
> accelerated version has intimate knowledge of the 2D engine, but instead
> of accessing the hardware directly, it will rely on DRM to pass commands
> to the hardware. 

It would be real neat if we could re-use the same code as XFre86 XAA
drivers, but i don't think this will ever happen. but then we are on the
verge of the X 5.0 discution, so ...

> - in its current form, this will be the fb_imageblit(), fb_copyarea()
> and fb_fillrect(). 
> 
> 3. fbcon 
> 
> - this is the console driver that runs on top of fbaa 
> 
> 4. DRM - will get mmio pointer and command buffers from fbdev and will
> generally retain its original functions (interrupt handling, locking,
> arbitration, DMA interface, the works).  It must also provide an
> interface for fbaa. 
> 
> 5. Userland apps - should only see the graphics memory pointer via
> fbdev.  If they need to access the hardware, they have to go through
> DRM. 
> 
> Advantages:  
> 
> 1. fbdev will be secure.  Without access to the MMIO regions, crashing
> the chipset is unlikely or at least difficult.  Even malicious blit
> commands (blits to/from system memory) will not work.  
> 
> 2. Single point of entry for hardware access (DRI).  You can run
> multiple clients trying to access the hardware simultaneously via DRM.  
> And because of DRM's features, it will take care of command
> verification, arbitration, locking, context switching, etc.  
> 
> 3.  Because DRM will handle both 2D and 3D and is pretty much the only
> one with hardware access, performance might actually increase.  

Notice that the radeon X driver already does this when possible.

I think you would still need to do context swaps and such though.

> Disadvantages: 
> 
> 1. very linux specific.  Xfree86 was designed to run on different
> platforms.  Having one code for linux and another for the rest will be
> difficult for XFree86 developers to accept. 

No problem, XFree86 should provide a wrapper around its xaa code, which
would either use the drm when available or use the mmio/whatever accesses
when no drm is available.

When no fbdev is available, it should use its own initialization code,
and that is it. For 5.0, we should lobby xfree86 that they separate more
the initialization code from the rest of it.

> 2. this will break fb-based apps that require chipset access, ie
> DirectFB. 

Why ? They should use the drm also, and everything would be nice, it
would mean a rewrite though.

> 3. a lot of code are difficult to implement in kernel space, ie
> initialization of secondary cards.  Full video bios access can only be
> done, from a practical standpoint, in user space (the Intel 830, for
> instance, may require this). 

Yes, this may be a problem.

> 4. Not all fbdev drivers has a DRI counterpart.  For these chipsets,
> fbaa still has to access the hardware directly. 

Notice that above you spoke about the drm, you would write a drm driver
for each graphic chipset, that it has or not a DRI above it.

> In linux-2.5, fbcon is already separate from fbdev.  Perhaps in 2.7,
> fbdev can be further reduced to a minimal core, moving the rest of the
> code to fbaa.  Exporting the mmio regions to userland must be
> disallowed. 
> 
> Secondly, a module to access DRM services from within the kernel will be
> needed. 

I personnaly like this proposal, but you really need to comunicate it
beyond the linux-fbdev list. The DRI list is where this discution got
started, the above mail from Linus was forwarded from there, and there
are people doing embeded mesa on top of fbdev there, and xfree86 is just
starting to think about 5.0.

Friendly,

Sven Luther
> 
> Any comments? 
> 
> Tony  
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Linux-fbdev-devel] Fwd: Re: [Dri-devel] future of DRI?

[Antonino D. <ad...@po...>]

On Sun, 2003-03-02 at 02:42, Jon Smirl wrote: 
> --- Linus Torvalds <tor...@tr...> wrote:
> > From: Linus Torvalds <tor...@tr...>
> > To: Keith Whitwell <ke...@tu...>
> > CC: Jon Smirl <jon...@ya...>, Ian Romanick
> > <id...@us...>,
> >         "DRI developer's list"
> > <dri...@li...>
> > Subject: Re: [Dri-devel] future of DRI?
> > Date: Sat, 1 Mar 2003 10:15:06 -0800 (PST)
> > 
> > 
> > On Sat, 1 Mar 2003, Keith Whitwell wrote:
> > > 
> > > Interesting you mention it.  This is what Brian &
> > I've done in the Mesa 
> > > embedded branch -- layered the radeon dri driver
> > on top of fbdev.  I can also 
> > > build regular DRI drivers from a minimal tree &
> > sane set of makefiles.
> > 
> > Personally, I'd rather see DRI _underneath_ fbdev
> > rather than on top of. 
> > Since fbdev would require at least to know of (and
> > obey) the DRI locking 
> > code - and would likely want to use all the same DRI
> > command execution for 
> > things like blits etc (this is on the assumption
> > that 2d and 3d will 
> > eventually use the same engine, which is probably a
> > safe assumption).
> > 
> > I _assume_ that what you really mean is that you use
> > fbdev really only to
> > set up the screen modes and do things like
> > initialize the graphics
> > buffers.
> > 
> > 		Linus
> > 
Yes, this is the sanest way.  In my opinion, this is how fbdev and DRI
should operate: 

1. fbdev 
- provide a means to initialize and change the video state. 

- provide pointers to graphics/rendering memory, MMIO, DMA/ringbuffers 

- graphics memory may or may not be available to everyone, but the MMIO
and command buffers will only be available to DRI 

- fbdev must not touch any registers besides those required to
initialize the hardware.  No 2D, no 3D. 

2. fbaa 

- or framebuffer acceleration architecture or whatever you want to call
it.  This will be equivalent to Xfree86's XAA. It provides a 2D
abstraction layer for clients residing in kernel space (ie fbcon). It
will have software versions and optionally accelerated versions.  The
accelerated version has intimate knowledge of the 2D engine, but instead
of accessing the hardware directly, it will rely on DRM to pass commands
to the hardware. 

- in its current form, this will be the fb_imageblit(), fb_copyarea()
and fb_fillrect(). 

3. fbcon 

- this is the console driver that runs on top of fbaa 

4. DRM - will get mmio pointer and command buffers from fbdev and will
generally retain its original functions (interrupt handling, locking,
arbitration, DMA interface, the works).  It must also provide an
interface for fbaa. 

5. Userland apps - should only see the graphics memory pointer via
fbdev.  If they need to access the hardware, they have to go through
DRM. 

Advantages:  

1. fbdev will be secure.  Without access to the MMIO regions, crashing
the chipset is unlikely or at least difficult.  Even malicious blit
commands (blits to/from system memory) will not work.  

2. Single point of entry for hardware access (DRI).  You can run
multiple clients trying to access the hardware simultaneously via DRM.  
And because of DRM's features, it will take care of command
verification, arbitration, locking, context switching, etc.  

3.  Because DRM will handle both 2D and 3D and is pretty much the only
one with hardware access, performance might actually increase.  


Disadvantages: 

1. very linux specific.  Xfree86 was designed to run on different
platforms.  Having one code for linux and another for the rest will be
difficult for XFree86 developers to accept. 

2. this will break fb-based apps that require chipset access, ie
DirectFB. 

3. a lot of code are difficult to implement in kernel space, ie
initialization of secondary cards.  Full video bios access can only be
done, from a practical standpoint, in user space (the Intel 830, for
instance, may require this). 

4. Not all fbdev drivers has a DRI counterpart.  For these chipsets,
fbaa still has to access the hardware directly. 


In linux-2.5, fbcon is already separate from fbdev.  Perhaps in 2.7,
fbdev can be further reduced to a minimal core, moving the rest of the
code to fbaa.  Exporting the mmio regions to userland must be
disallowed. 

Secondly, a module to access DRM services from within the kernel will be
needed. 

Any comments? 

Tony  

[Linux-fbdev-devel] Fwd: Re: [Dri-devel] future of DRI?

[Jon S. <jon...@ya...>]

--- Linus Torvalds <tor...@tr...> wrote:
> From: Linus Torvalds <tor...@tr...>
> To: Keith Whitwell <ke...@tu...>
> CC: Jon Smirl <jon...@ya...>, Ian Romanick
> <id...@us...>,
>         "DRI developer's list"
> <dri...@li...>
> Subject: Re: [Dri-devel] future of DRI?
> Date: Sat, 1 Mar 2003 10:15:06 -0800 (PST)
> 
> 
> On Sat, 1 Mar 2003, Keith Whitwell wrote:
> > 
> > Interesting you mention it.  This is what Brian &
> I've done in the Mesa 
> > embedded branch -- layered the radeon dri driver
> on top of fbdev.  I can also 
> > build regular DRI drivers from a minimal tree &
> sane set of makefiles.
> 
> Personally, I'd rather see DRI _underneath_ fbdev
> rather than on top of. 
> Since fbdev would require at least to know of (and
> obey) the DRI locking 
> code - and would likely want to use all the same DRI
> command execution for 
> things like blits etc (this is on the assumption
> that 2d and 3d will 
> eventually use the same engine, which is probably a
> safe assumption).
> 
> I _assume_ that what you really mean is that you use
> fbdev really only to
> set up the screen modes and do things like
> initialize the graphics
> buffers.
> 
> 		Linus
> 
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dri-devel mailing list
> Dri...@li...
>
https://lists.sourceforge.net/lists/listinfo/dri-devel


=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: [Linux-fbdev-devel] Situation on radeonfb

[Hanno <ha...@gm...>]

> Marcello and Linus will recieve an update in the next week or so.

Did you send anything? Can you post a copy of your patches to the list?

cu,

Hanno

Re: [Linux-fbdev-devel] [PATCH] Tile Blitting

[Antonino D. <ad...@po...>]

On Fri, 2003-02-28 at 02:25, Michel D=E4nzer wrote:
> On Don, 2003-02-27 at 15:15, Antonino Daplas wrote:=20
> > On Thu, 2003-02-27 at 09:18, James Simmons wrote:
> > =20
> > > > Thus, the restriction that the buffer must be completely copied by =
the
> > > > driver before returning.  And because of this restriction, an extra=
 copy
> > > > which might be unnecessary cannot be avoided (this was noted by Pet=
r).
> > > >=20
> > > > Treating the buffer as a ringbuffer, we eliminate these restriction=
s.
> > >=20
> > > I didn't realize that the below was a ringbuffer implementation. The =
name
> > > threw me off.=20
> >=20
> > Well, it's not strictly a ringbuffer implementation.  This would requir=
e
> > a head and tail pointer where fbcon will adjust the tail and the
> > driver/hardware will adjust the head.  This will be very difficult to
> > implement in a device independent manner.  So we just cheat by issuing
> > an fb_sync() per loop to flush all pending commands.
>=20
> That still seems suboptimal though. What the DRM often does is have the
> chip write an age value to a scratch register when it's done processing
> something. Maybe something like that could be used to avoid waiting for
> the chip to go idle at all?
>=20

Yes, it is certainly suboptimal. But the fb_sync() will be done only
when the pointer wraps to the beginning of the buffer and only if the
buffer can be DMA'd by the chip.

To support these types of buffers, we can change pixmap.offset to head
and tail. The buffer is empty when head =3D=3D tail.  Then, fbcon
continually adjusts the tail to tail+size, and when the chip is done
processing that particular bitmap, it will adjust the head to
head+size.  Then instead of doing an fb_sync(), fbcon will just busy
loop waiting for the buffer to have enough space for the next set of
bitmaps.

This will involve per chipset support, the reason why I did not do it
like this.  It can be added, but it will not be default behavior.

PS:  I remember that practically all drivers do some form of syncing
before each operation, and no one complained :-).

Tony =20
=20

Re: [Linux-fbdev-devel] Possible Bug in radeonfb (?)

[Andrea M. <ama...@us...>]

On 02/26, Antonino Daplas wrote:
> Probably does not matter, unless you intend to use very, very low
> dotclocks (< 10MHz).
Yes. My intention is to use the Frame Buffer drivers for TVs and Arcade
Monitors. Generally they need very low pixel clocks, like 5-6 MHz.

-- 
Andrea Mazzoleni
935A 2D3C 5C70 BCD6 CB0C  ED89 7C19 4321 6340 3F6D

Re: [Linux-fbdev-devel] [PATCH] Tile Blitting

[James S. <jsi...@in...>]

> On Don, 2003-02-27 at 15:15, Antonino Daplas wrote: 
> > On Thu, 2003-02-27 at 09:18, James Simmons wrote:
> >  
> > > > Thus, the restriction that the buffer must be completely copied by the
> > > > driver before returning.  And because of this restriction, an extra copy
> > > > which might be unnecessary cannot be avoided (this was noted by Petr).
> > > > 
> > > > Treating the buffer as a ringbuffer, we eliminate these restrictions.
> > > 
> > > I didn't realize that the below was a ringbuffer implementation. The name
> > > threw me off. 
> > 
> > Well, it's not strictly a ringbuffer implementation.  This would require
> > a head and tail pointer where fbcon will adjust the tail and the
> > driver/hardware will adjust the head.  This will be very difficult to
> > implement in a device independent manner.  So we just cheat by issuing
> > an fb_sync() per loop to flush all pending commands.
> 
> That still seems suboptimal though. What the DRM often does is have the
> chip write an age value to a scratch register when it's done processing
> something. Maybe something like that could be used to avoid waiting for
> the chip to go idle at all?

Don't waste your time. I'm removing all the changes that have been done 
since 2.5.51. After that I will no longer be co-maintainter of the 
framebuffer layer. 

Re: [Linux-fbdev-devel] [PATCH] Tile Blitting

[Michel <mi...@da...>]

On Don, 2003-02-27 at 15:15, Antonino Daplas wrote: 
> On Thu, 2003-02-27 at 09:18, James Simmons wrote:
>  
> > > Thus, the restriction that the buffer must be completely copied by the
> > > driver before returning.  And because of this restriction, an extra copy
> > > which might be unnecessary cannot be avoided (this was noted by Petr).
> > > 
> > > Treating the buffer as a ringbuffer, we eliminate these restrictions.
> > 
> > I didn't realize that the below was a ringbuffer implementation. The name
> > threw me off. 
> 
> Well, it's not strictly a ringbuffer implementation.  This would require
> a head and tail pointer where fbcon will adjust the tail and the
> driver/hardware will adjust the head.  This will be very difficult to
> implement in a device independent manner.  So we just cheat by issuing
> an fb_sync() per loop to flush all pending commands.

That still seems suboptimal though. What the DRM often does is have the
chip write an age value to a scratch register when it's done processing
something. Maybe something like that could be used to avoid waiting for
the chip to go idle at all?


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

Re: [Linux-fbdev-devel] [PATCH] Tile Blitting

[Antonino D. <ad...@po...>]

On Thu, 2003-02-27 at 09:18, James Simmons wrote:
> > As Geert and DaveM has
> > mentioned to me, the current implementation might not be thread-safe
> > (although I see more of a concurrency problem between CPU and GPU).
> 
> I agree I see more of a problem with CPU GPU syncing issue. I do have a 
> fix in BK with allocating and deallocating continuely but it is the wrong
> approach.
> 

We can avoid concurrency problems by assigning different sections of the
buffer per call to fb_imageblit(). There is really no need to map/unmap
or allocate/deallocate buffers unless you do not trust the drivers to
behave :-).  The buffer will not be exposed to userland, unlike DRM
which has to implement "map->user access->unmap->pass to hardware".
 
> > Thus, the restriction that the buffer must be completely copied by the
> > driver before returning.  And because of this restriction, an extra copy
> > which might be unnecessary cannot be avoided (this was noted by Petr).
> > 
> > Treating the buffer as a ringbuffer, we eliminate these restrictions.
> 
> I didn't realize that the below was a ringbuffer implementation. The name
> threw me off. 

Well, it's not strictly a ringbuffer implementation.  This would require
a head and tail pointer where fbcon will adjust the tail and the
driver/hardware will adjust the head.  This will be very difficult to
implement in a device independent manner.  So we just cheat by issuing
an fb_sync() per loop to flush all pending commands.

> 
> Do you still have the original patch?
> 

Here's a revised one. Driver's can choose to fill up the following
structure, or leave it empty:

#define FB_PIXMAP_DEFAULT 1     /* used internally by fbcon */
#define FB_PIXMAP_SYSTEM  2     /* memory is in system RAM  */
#define FB_PIXMAP_IO      4     /* memory is iomapped       */
#define FB_PIXMAP_SYNC    256   /* set if GPU can DMA       */

struct fb_pixmap {
        __u8  *addr; 
	__u32 size;  
	__u32 offset;
	__u32 buf_align; 
	__u32 scan_align; 
	__u32 flags; 
	void (*outbuf)(u8 dst, u8 *addr); 
	u8   (*inbuf) (u8 *addr);
	unsigned long lock_flags;
	spinlock_t lock; 
};

The buffer can be anywhere, system or io.  If it's in special memory
(ie, offscreen graphics), access methods must be specified (outbuf,
inbuf).  If the buffer is DMA'able by the GPU, then FB_PIXMAP_SYNC must
be set (it issues an fb_sync()), otherwise leave it cleared (ie soft
accels). The buf_align and scan_align are hardware specific.  This will
let fbcon format the bitmap into a form acceptable by the hardware.  The
modified rivafb sets the alignment according to its needs, which greatly
simplified the rivafb_imageblit() function.

The spinlock may be necessary because fbcon_cursor, which is called via
timer or interrupt, might also use fb_imageblit().  You can change it to
a more appropriate locking method if you want.

The patch should work without driver breakage.  

Diff is against linux-2.5.61 + your fbdev.diff.gz + my accel_putcs
optimization patch + Geert's logo updates.  I know you already applied
them all in your tree.

Tony
 

[Linux-fbdev-devel] Re: [Linux-fbdev-users] framebufer and radeonfb

[Brad D. <br...@ne...>]

On Wed, 2003-02-26 at 11:30, James Simmons wrote:
> > On Mon, 2003-02-24 at 06:49, leif gensert wrote:
> > > it still does not work :(
> > > 
> > My mistake.  The radeonfb needs "video=radeon:", ie without the 'fb'.
> > 
> > "video=radeon:1024x768"
> 
> Perhaps we should convert them all to end with fb?

I agree.  I believe this was discussed a few years ago and we
standardized on [driver]fb.  If we are all in agreement, I will go ahead
and make the changes.

-- 

Brad Douglas
br...@ne...

 37.493353 N
121.928953 W

Re: [Linux-fbdev-devel] [PATCH] Tile Blitting

[James S. <jsi...@in...>]

> For model 2, do we have to allocate/deallocate per iteration?  

I'm looking at the streaming DMA model used by filesystem buffers being 
written/read by a SCSI device. You are right tho. If you use pci_dma_sync 
then you don't need to create and remove the mappings. The question is 
there any hardware to limited where we have to create/destory mapping 
constantly? 

> Secondly, we cannot deallocate the memory
> until the GPU is done rendering.  This means we have to synchronize for
> each imageblit, further slowing it down.  Modern GPU's have deep
> pipelines, let's take advantage of it.

Okay good point.
 
> So, how about letting the driver allocate the memory for us, and this
> will last throughout the lifetime of the driver?  This also becomes a
> consistent mapping.  The main difference is, we treat this memory as a a
> ringbuffer, ie:
> 
> Memory is at address p, size N. 
> 
> The first bitmap, in terms of time of arrival, (bitmap1) will be at 'p',
> bitmap2 at 'p+size1', bitmap 3 at 'p+size1+size2' and so on and so
> forth.  Once fbcon reaches the end of the buffer, 'p+N', it calls
> fb_sync() and start all over again, at 'p'.
> 
> The advantages of the above are:
> 
> 	1. no need to allocate/deallocate memory which is disproportionately
> more expansive relative to the bitmap sizes fbcon is dealing with.
> 
> 	2. no chance of memory becoming unavailable during
> memory-starved/emergency states.

Very good. 

> 	3. the whole process is very fast and asynchronous.  The GPU can be
> rendering, while the CPU is preparing the bitmap.  The only time fbcon
> synchronizes is during the "wrap-around".

> This is actually the initial patch that I submitted to you months ago,
> but you rejected it.  

Well I was wrong :-( I rejected because I was hoping to keep the api 
object orientated (rectangle and bitmap/pixmaps). Now I see that without 
this kind of solution we end up with a bigger mess. I admit I made the 
wrong judgement call on this. 

> As Geert and DaveM has
> mentioned to me, the current implementation might not be thread-safe
> (although I see more of a concurrency problem between CPU and GPU).

I agree I see more of a problem with CPU GPU syncing issue. I do have a 
fix in BK with allocating and deallocating continuely but it is the wrong
approach.

> Thus, the restriction that the buffer must be completely copied by the
> driver before returning.  And because of this restriction, an extra copy
> which might be unnecessary cannot be avoided (this was noted by Petr).
> 
> Treating the buffer as a ringbuffer, we eliminate these restrictions.

I didn't realize that the below was a ringbuffer implementation. The name
threw me off. 

> So:
> 
> struct fb_pixmap {
> 	__u8 *addr;
> 	__u32 size;
> 	__u32 tail;
> 	__u32 buf_align;
> 	__u32 scan_align;
> 	__u32 flags;
> }
> 
> a. addr - pointer to memory
> 
> b. tail - this is the current offset to the buffer
> 
> c. buf_align - start alignment per bitmap
> 
> d. scan_align - alignment for each scanline, cfb_imageblit requires 1,
> i810fb, 2, rivafb and tgafb(?) 4. 
> 
> e. flags = location of buffer (system or graphics/pci/dma) so fbcon can
> choose how to access the memory.
> 
> The structure is prepared by the driver at initialization. If it chooses
> not too, addr should be NULL and fbcon will just allocate memory for it,
> and use default values (size = 8K, buf_align = 1, scan_align = 1, flags
> = system).

Do you still have the original patch?

Re: [Linux-fbdev-devel] [PATCH] Tile Blitting

[Antonino D. <ad...@po...>]

On Thu, 2003-02-27 at 04:11, James Simmons wrote:
> 
> Boy this has been tricky to handle. I have been thinking about how to 
> handle image blitting from normal memory to texture mappings to tiles.
> Then after that I have to make it abstract to fit all these models. 
> Pretty much I have come to the conclusion that we have two models.
> 
> Model 1: Consistent mappings. 
> 
> 	In this model we allocate one time a buffer to store image data.
> 	The fbcon classic is loadfont. It could also be creating texures
> 	and saving it in a permentant texture map buffer that is present 
>         on the card. Same for tiles. We create a bunch of tiles and save 
>         them somewhere. We then use a index of some kind later to draw 
> 	the image.
> 
> Model 2: Streaming mappings. 
> 
> 	This model has us create a temporary memory pool to store data 
> 	then draw it. After drawing is complete we release the memory. 
> 	
> 
> As you can see the standard imageblit function falls into model 2. At 
> present we allocate a static buffer :-( Now for a PCI DMA based card we 
> want a hook to allocate a chunck of memory via pci_alloc_consittent. To 
> free the memory we use pci_free_consistent. Also for AGP there could be 
> hooks just for it. So model 2 can be broken into 2 parts.
> 
> A) Memory mangement. We first allocate the memory needed. After drawing
>    the image free the memory.
> 
> B) Draw the image. This occurs between the two events in A.
> 

For model 2, do we have to allocate/deallocate per iteration?  First, we
are not dealing with large-sized bitmaps here (a single character at
most will have 64 bytes).  Secondly, we cannot deallocate the memory
until the GPU is done rendering.  This means we have to synchronize for
each imageblit, further slowing it down.  Modern GPU's have deep
pipelines, let's take advantage of it.

So, how about letting the driver allocate the memory for us, and this
will last throughout the lifetime of the driver?  This also becomes a
consistent mapping.  The main difference is, we treat this memory as a a
ringbuffer, ie:

Memory is at address p, size N. 

The first bitmap, in terms of time of arrival, (bitmap1) will be at 'p',
bitmap2 at 'p+size1', bitmap 3 at 'p+size1+size2' and so on and so
forth.  Once fbcon reaches the end of the buffer, 'p+N', it calls
fb_sync() and start all over again, at 'p'.

The advantages of the above are:

	1. no need to allocate/deallocate memory which is disproportionately
more expansive relative to the bitmap sizes fbcon is dealing with.

	2. no chance of memory becoming unavailable during
memory-starved/emergency states.

	3. the whole process is very fast and asynchronous.  The GPU can be
rendering, while the CPU is preparing the bitmap.  The only time fbcon
synchronizes is during the "wrap-around".

This is actually the initial patch that I submitted to you months ago,
but you rejected it.  That's why I came up with the simpler
implementation (statically allocated buffer).  As Geert and DaveM has
mentioned to me, the current implementation might not be thread-safe
(although I see more of a concurrency problem between CPU and GPU).
Thus, the restriction that the buffer must be completely copied by the
driver before returning.  And because of this restriction, an extra copy
which might be unnecessary cannot be avoided (this was noted by Petr).

Treating the buffer as a ringbuffer, we eliminate these restrictions.

So:

struct fb_pixmap {
	__u8 *addr;
	__u32 size;
	__u32 tail;
	__u32 buf_align;
	__u32 scan_align;
	__u32 flags;
}

a. addr - pointer to memory

b. tail - this is the current offset to the buffer

c. buf_align - start alignment per bitmap

d. scan_align - alignment for each scanline, cfb_imageblit requires 1,
i810fb, 2, rivafb and tgafb(?) 4. 

e. flags = location of buffer (system or graphics/pci/dma) so fbcon can
choose how to access the memory.

The structure is prepared by the driver at initialization. If it chooses
not too, addr should be NULL and fbcon will just allocate memory for it,
and use default values (size = 8K, buf_align = 1, scan_align = 1, flags
= system).

Tony

Re: [Linux-fbdev-devel] [PATCH] Tile Blitting

[James S. <jsi...@in...>]

Boy this has been tricky to handle. I have been thinking about how to 
handle image blitting from normal memory to texture mappings to tiles.
Then after that I have to make it abstract to fit all these models. 
Pretty much I have come to the conclusion that we have two models.

Model 1: Consistent mappings. 

	In this model we allocate one time a buffer to store image data.
	The fbcon classic is loadfont. It could also be creating texures
	and saving it in a permentant texture map buffer that is present 
        on the card. Same for tiles. We create a bunch of tiles and save 
        them somewhere. We then use a index of some kind later to draw 
	the image.

Model 2: Streaming mappings. 

	This model has us create a temporary memory pool to store data 
	then draw it. After drawing is complete we release the memory. 
	

As you can see the standard imageblit function falls into model 2. At 
present we allocate a static buffer :-( Now for a PCI DMA based card we 
want a hook to allocate a chunck of memory via pci_alloc_consittent. To 
free the memory we use pci_free_consistent. Also for AGP there could be 
hooks just for it. So model 2 can be broken into 2 parts.

A) Memory mangement. We first allocate the memory needed. After drawing
   the image free the memory.

B) Draw the image. This occurs between the two events in A.


Now for model 1. A example would be the matrox fbdev driver for fast 
fonts. We allocate a region to store the font images before using them.
This buffer is pretty much permanent. Then we use indices to tell which
section of the allocated buffer to have the graphics engine use. 


So this is the model I have come up with. The tricky part I haven't 
figured out yet is working with irqs and how to relate fbcon with it. 
Comments?

[Linux-fbdev-devel] Re: [Linux-fbdev-users] framebufer and radeonfb

[James S. <jsi...@in...>]

> On Mon, 2003-02-24 at 06:49, leif gensert wrote:
> > it still does not work :(
> > 
> My mistake.  The radeonfb needs "video=radeon:", ie without the 'fb'.
> 
> "video=radeon:1024x768"

Perhaps we should convert them all to end with fb?