Mapping the framebuffer into kernel space

Mapping the framebuffer into kernel space

[Jon Smirl]

I looked at a few fbdev drivers and they are mapping the framebuffer
into kernel space.

Example from radeonfb:
  rinfo->mapped_vram = min_t(unsigned long, MAX_MAPPED_VRAM, rinfo->video_ram);
 do {
     rinfo->fb_base = ioremap (rinfo->fb_base_phys,
                                       rinfo->mapped_vram);

Isn't the only consumer of this kernel mapping fbconsole? If so
shouldn't fbconsole be doing the mapping instead of doing it in the
drivers? Doing it in fbconsole would let us map exactly the amount of
VRAM needed for the console. Right now the driver has to guess the
maximum consumption.  This would minimize the amount of kernel address
space consumed by fbdev. It could also remove a bunch of redundant
code.

Then in my case where I'm running radeonfb but not fbconsole there
would be no kernel address space consumed at all.

Minimizing kernel address space consumption is important for x86
systems with more than 1GB of memory. Address space going to fbdev
pushes system pages from low into high memory and slows them down.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix

Re: Mapping the framebuffer into kernel space

[James Simmons]

> Isn't the only consumer of this kernel mapping fbconsole? 

No that is not the case. fb_read and fb_write use the kernel mapping.



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Mapping the framebuffer into kernel space

[James Simmons]

> I don't see a good solution here for implementing fb_read/write for
> the framebuffer. I would still vote for removing all kernel
> framebuffer mapping from the fbdev driver. Then fbconsole would kernel
> map just the piece it needs to implement the console.

I like to see the mappings go away as well. The solution is for fb_read 
and fb_write to use fb_imageblit. We don't need to touch the framebuffer 
memory in that case. The logic is a little tricky. You could have 1 to 3 
images blitted to the display.



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Mapping the framebuffer into kernel space

[James Simmons]

> What if we just got rid of fb_read/write and converted fbconsole to
> use fb_imageblt?

   fbconsole does use only fb_imageblit. The only place where screen_base 
is used is fb_write and fb_read in fbmem.c. If that could be converted to use 
the accelerated image blitting functions then we could replace it. To do 
that requires one thing and that is to add image blitting from screen 
memory to system memory. Currently no driver including the software 
blitting supports that. Plus we have no standard api to handle that. 
   So first we have to come up with a standard way to handling image 
blitting from card memory to system memory without breaking badly the 
current api. Second we have to add bi directional blitting to every 
driver. Then once we are done we can convert the fb_read and fb_write 
functions to using the fb_imageblit functon. Have have plans to do this 
but have not yet done it.




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Mapping the framebuffer into kernel space

[James Simmons]

> >    fbconsole does use only fb_imageblit. The only place where screen_base
> > is used is fb_write and fb_read in fbmem.c. If that could be converted to use
> > the accelerated image blitting functions then we could replace it. To do
> 
> So if fbconsole doesn't use fb_read/write then who does?

/dev/fb



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Mapping the framebuffer into kernel space

[James Simmons]

> > > So if fbconsole doesn't use fb_read/write then who does?
> > 
> > /dev/fb
> 
> and what app uses /dev/fb with read/write instead of mmaping the framebuffer?

I can't say off the top of my head. We should assume there are apps that 
do use those functions. 


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Mapping the framebuffer into kernel space

[James Simmons]

> > I can't say off the top of my head. We should assume there are apps that
> > do use those functions.
> 
> fb_read/write has been broken on radeon for a couple of years now and
> nobody has noticed.

I have a hard time believing that. Do a cat /dev/urandom > /dev/fb0
and see what the results are. I can give it a try.



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Mapping the framebuffer into kernel space

[James Simmons]

> This does imply that we could switch read/write to kernel map VRAM a
> page or two at a time on demand. But this is significant work and I
> don't think there are any apps using read/write. If we find one it
> would just be easier to convert it to mmap than to support read/write
> in the kernel.

Yuck. Why not just us the image blitter for reading and writing the 
framebuffer?



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Mapping the framebuffer into kernel space

[James Simmons]

> > Yuck. Why not just us the image blitter for reading and writing the
> > framebuffer?
> 
> Could you generically rewrite fb_read/write to just use the image blitter? 

Yes.

> Is this a solution to eliminating the kernel mmap?

Yes.

We would need to make imageblit bi-directional tho for all the drivers.



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click

Re: Mapping the framebuffer into kernel space

[Geert Uytterhoeven]

On Wed, 11 May 2005, James Simmons wrote:
> > > Yuck. Why not just us the image blitter for reading and writing the
> > > framebuffer?
> > 
> > Could you generically rewrite fb_read/write to just use the image blitter? 
> 
> Yes.

No.

The imageblit routines convert between chunked pixels and the actual frame
buffer representation.
fb_{read,write}() access the raw frame buffer.

Probably the best solution is to set up a small ioremap()'ed window that can be
moved in fb_{read,write}() (assumed moving such a window is much cheaper than
ioremap() + iounmap()).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click

Re: Mapping the framebuffer into kernel space

[James Simmons]

> > > Could you generically rewrite fb_read/write to just use the image blitter? 
> > 
> > Yes.
> 
> No.
> 
> The imageblit routines convert between chunked pixels and the actual frame
> buffer representation.
> fb_{read,write}() access the raw frame buffer.

That means that we will never uses the hardware acceleration ever in this 
case :-( It will always be slow!!!!

> Probably the best solution is to set up a small ioremap()'ed window that can be
> moved in fb_{read,write}() (assumed moving such a window is much cheaper than
> ioremap() + iounmap()).

Does such functionality exist? Second can you do the same thing with 
request_region? We need to so fbcon and /dev/fb don't step on each other 
toes.



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click

Re: Mapping the framebuffer into kernel space

[Jon Smirl]

On 5/12/05, James Simmons <jsimmons@www.infradead.org> wrote:
> 
> > > > Could you generically rewrite fb_read/write to just use the image blitter?
> > >
> > > Yes.
> >
> > No.
> >
> > The imageblit routines convert between chunked pixels and the actual frame
> > buffer representation.
> > fb_{read,write}() access the raw frame buffer.
> 
> That means that we will never uses the hardware acceleration ever in this
> case :-( It will always be slow!!!!
> 
> > Probably the best solution is to set up a small ioremap()'ed window that can be
> > moved in fb_{read,write}() (assumed moving such a window is much cheaper than
> > ioremap() + iounmap()).
> 
> Does such functionality exist? Second can you do the same thing with
> request_region? We need to so fbcon and /dev/fb don't step on each other
> toes.

Before we get too far into this, has anyone determined if any user
space app exists that does read/write from fbdev? I can't see a real
need to keep this feature if no one is using it. If no one is using
it, it would be much simpler just to remove the functions.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_ids93&alloc_id\x16281&op=click

Re: Mapping the framebuffer into kernel space

[Geert Uytterhoeven]

On Thu, 12 May 2005, Jon Smirl wrote:
> On 5/12/05, James Simmons <jsimmons@www.infradead.org> wrote:
> > 
> > > > > Could you generically rewrite fb_read/write to just use the image blitter?
> > > > Yes.
> > >
> > > No.
> > >
> > > The imageblit routines convert between chunked pixels and the actual frame
> > > buffer representation.
> > > fb_{read,write}() access the raw frame buffer.
> > 
> > That means that we will never uses the hardware acceleration ever in this
> > case :-( It will always be slow!!!!
> > 
> > > Probably the best solution is to set up a small ioremap()'ed window that can be
> > > moved in fb_{read,write}() (assumed moving such a window is much cheaper than
> > > ioremap() + iounmap()).
> > 
> > Does such functionality exist? Second can you do the same thing with
> > request_region? We need to so fbcon and /dev/fb don't step on each other
> > toes.
> 
> Before we get too far into this, has anyone determined if any user
> space app exists that does read/write from fbdev? I can't see a real
> need to keep this feature if no one is using it. If no one is using
> it, it would be much simpler just to remove the functions.

I think the only programs really using this are some screenshot programs, like
cfb8toppm (which I wrote as a frame buffer sample program many years ago),
fbshot, and fbgrap (in Debian).

Of course these can be converted to use mmap().

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click

Re: Mapping the framebuffer into kernel space

[Jon Smirl]

On 5/12/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > Before we get too far into this, has anyone determined if any user
> > space app exists that does read/write from fbdev? I can't see a real
> > need to keep this feature if no one is using it. If no one is using
> > it, it would be much simpler just to remove the functions.
> 
> I think the only programs really using this are some screenshot programs, like
> cfb8toppm (which I wrote as a frame buffer sample program many years ago),
> fbshot, and fbgrap (in Debian).
> 
> Of course these can be converted to use mmap().

Seems to me that it would be easier to drop the feature and update the apps.


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_ids93&alloc_id\x16281&op=click

Re: Mapping the framebuffer into kernel space

[James Simmons]

> > > Before we get too far into this, has anyone determined if any user
> > > space app exists that does read/write from fbdev? I can't see a real
> > > need to keep this feature if no one is using it. If no one is using
> > > it, it would be much simpler just to remove the functions.
> > 
> > I think the only programs really using this are some screenshot programs, like
> > cfb8toppm (which I wrote as a frame buffer sample program many years ago),
> > fbshot, and fbgrap (in Debian).
> > 
> > Of course these can be converted to use mmap().
> 
> Seems to me that it would be easier to drop the feature and update the apps.

Since you are in a hurry why not just create a write and a read function 
for radeon that just returns EINVAL. There are hooks in fb_info for this.



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click

Re: Mapping the framebuffer into kernel space

[Jon Smirl]

On 5/13/05, James Simmons <jsimmons@www.infradead.org> wrote:
> 
> > > > Before we get too far into this, has anyone determined if any user
> > > > space app exists that does read/write from fbdev? I can't see a real
> > > > need to keep this feature if no one is using it. If no one is using
> > > > it, it would be much simpler just to remove the functions.
> > >
> > > I think the only programs really using this are some screenshot programs, like
> > > cfb8toppm (which I wrote as a frame buffer sample program many years ago),
> > > fbshot, and fbgrap (in Debian).
> > >
> > > Of course these can be converted to use mmap().
> >
> > Seems to me that it would be easier to drop the feature and update the apps.
> 
> Since you are in a hurry why not just create a write and a read function
> for radeon that just returns EINVAL. There are hooks in fb_info for this.

There is no hurry, radeonfb is already not mapping the entire
framebuffer. But we should make a decision on this and implement it
consistently going forward.

Summary of my points:
1) kernel x86 address space is 1GB
2) ATI is shipping 512MB cards, with 1GB cards planned
3) mapping the entire framebuffer in to kernel space is probably
impossible on x86
4) fbconsole can do it's own map for the limited piece it needs
5) that leaves fb_read/fb_write. I propose eliminating them and
removing the ability to read/write the framebuffer from the fbdev
device. Then fix up the few apps using read/write to use mmap instead.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_ids93&alloc_id\x16281&op=click

Re: Mapping the framebuffer into kernel space

[Geert Uytterhoeven]

On Thu, 5 May 2005, James Simmons wrote:
> > What if we just got rid of fb_read/write and converted fbconsole to
> > use fb_imageblt?
> 
>    fbconsole does use only fb_imageblit. The only place where screen_base 
> is used is fb_write and fb_read in fbmem.c. If that could be converted to use 
> the accelerated image blitting functions then we could replace it. To do 
> that requires one thing and that is to add image blitting from screen 
> memory to system memory. Currently no driver including the software 
> blitting supports that. Plus we have no standard api to handle that. 
>    So first we have to come up with a standard way to handling image 
> blitting from card memory to system memory without breaking badly the 
> current api. Second we have to add bi directional blitting to every 
> driver. Then once we are done we can convert the fb_read and fb_write 
> functions to using the fb_imageblit functon. Have have plans to do this 
> but have not yet done it.

What if the graphics memory format is not chunked pixels? In that case
fb_{read,write}() will behave differently than mmap().

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Mapping the framebuffer into kernel space

[James Simmons]

> >    So first we have to come up with a standard way to handling image 
> > blitting from card memory to system memory without breaking badly the 
> > current api. Second we have to add bi directional blitting to every 
> > driver. Then once we are done we can convert the fb_read and fb_write 
> > functions to using the fb_imageblit functon. Have have plans to do this 
> > but have not yet done it.
> 
> What if the graphics memory format is not chunked pixels? In that case
> fb_{read,write}() will behave differently than mmap().

Is that a bad thing? It would be nice to have a application behave sanely 
in all cases. Even for pack pixel formated cards they might misbehave. 
For the Epson135X family we have the issue of only being able to write 16
bits at a time to the framebuffer memory. Unless you write the code 
knowing before hand this issue you will drop every other pixel for both 
mmap and write cases. Now if we rework fb_write then that chip would 
behave the same as other chips for the read/write function. The other 
bonus with a nice read/write function is you can NFS mount the fbdev 
device and read/write to it. To my knowledge you can't use mmap remotely.



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Mapping the framebuffer into kernel space

[Antonino A. Daplas]

On Friday 29 April 2005 11:55, Jon Smirl wrote:
> I looked at a few fbdev drivers and they are mapping the framebuffer
> into kernel space.
>
> Example from radeonfb:
>   rinfo->mapped_vram = min_t(unsigned long, MAX_MAPPED_VRAM,
> rinfo->video_ram); do {
>      rinfo->fb_base = ioremap (rinfo->fb_base_phys,
>                                        rinfo->mapped_vram);
>
> Isn't the only consumer of this kernel mapping fbconsole? If so
> shouldn't fbconsole be doing the mapping instead of doing it in the
> drivers? Doing it in fbconsole would let us map exactly the amount of
> VRAM needed for the console. Right now the driver has to guess the
> maximum consumption.  This would minimize the amount of kernel address
> space consumed by fbdev. It could also remove a bunch of redundant
> code.

It can be done but not without difficulty.  A few drivers use sections of
the framebuffer space for the cursor, DMA buffer and whatever.  So
when fbcon starts mapping the framebuffer space, it must make sure
that it does not overlap with the driver's, or the space left to the driver
is of the correct size and alignment.

Tony




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Re: Mapping the framebuffer into kernel space

[James Simmons]

> > It can be done but not without difficulty.  A few drivers use sections of
> > the framebuffer space for the cursor, DMA buffer and whatever.  So
> > when fbcon starts mapping the framebuffer space, it must make sure
> > that it does not overlap with the driver's, or the space left to the driver
> > is of the correct size and alignment.
> 
> We have to start transitioning to a new model. 512MB cards are
> shipping today. There is only 1GB of x86 kernel address space and the
> kernel has to fit into it too. Blindly mapping the entire VRAM into
> kernel space has to be replaced with a scheme that only maps what is
> required.

This can be done. I was moving that way using fb_pixmap. See my 
resource.diff patch I posted some time ago. Using request_region we should
be able to lock down a area so no one else can use it.

> Space for the cursor, DMA buffer, etc doesn't have to stay mapped. The
> driver can map it in, write the cursor and then map it out. DMA
> buffers don't need to be mapped in.

The cursor is really small memory. Mapping and unmapping it would be 
expensive with fbconsole because it flashs the cursor. As for DMA that
can be mapped and unmapped. 
 
> Another issue is multihead cards. For two heads it makes sense to put
> the two scanout buffers at either end of VRAM. But these buffers can
> change size. A better model might be:
> 
> cursor
> head 1 scanout
> free VRAM
> head 2 scanout
> cursor
> 
> The location of these items would be pointed to by a field in fb_info.

Each struct fb_info represent each displayable surface with a cursor[s].
It has the data the fbcon needs to function. The function check_var
needs to valided if changing one head can safely affect the other.
The function set_par would handle doing the moving around of resources.

> What's the least painful way to start a transition?

Design a clean buffer implementation that dri and fb would use.


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click