# uvesafb is very slow

## Ormaaj

It takes about 5 seconds to finish scrolling when pressing 'page down' while reading a manpage. If looking at compiler or rsync output, it will take forever to finish unless I switch to a different VT for a few seconds to let it scroll. I really have nothing to go on as far as debugging. There are no obvious errors in dmesg. It works very fast on another nearly identically configured x86_64 Gentoo instillation. Could this be a video card problem? (1GB Radeon 4870 HD)

Radeonfb doesn't work on 64 bit.

Heres my kernel parameters. It does work at my monitor's native resolution

```
kernel /linux-2.6.31.1 root=/dev/sda4 video=uvesafb:1920x1200-32@60,mtrr:3,ywrap lockd.nlm_udpport=37358 lockd.nlm_tcpport=34159 memory_corruption_check=1
```

----------

## pappy_mcfae

So use VESA VGA, and be done with it. Consult one of my seeds. They are all set for vesa vga.

Blessed be!

Pappy

----------

## Ormaaj

 *pappy_mcfae wrote:*   

> So use VESA VGA, and be done with it. Consult one of my seeds. They are all set for vesa vga.
> 
> Blessed be!
> 
> Pappy

 vesa is no faster. It must be my card. Running it in 8 bit makes it significantly faster. It is odd because on other machines I have had no trouble with uvesafb.

I can't figure out how to set the vga modes properly, they don't seem to line up with what it says in the documentation.

----------

## pappy_mcfae

an example from lilo.conf:

```
#

# VESA framebuffer console @ 1024x768x64k

#

  vga = 791

```

An example from /boot/grub/grub.conf:

```
title 2.6.29-zen2

root (hd0,0)

kernel /usr/src/linux-2.6.29-zen2/arch/x86/boot/bzImage root=/dev/sda1 vga=791

```

The important part is the vga=791. That will set for the full maximum resolution of your frame buffer device. 

This works on all but KMS. 

Blessed be!

Pappy

----------

## dmpogo

 *Ormaaj wrote:*   

>  *pappy_mcfae wrote:*   So use VESA VGA, and be done with it. Consult one of my seeds. They are all set for vesa vga.
> 
> Blessed be!
> 
> Pappy vesa is no faster. It must be my card. Running it in 8 bit makes it significantly faster. It is odd because on other machines I have had no trouble with uvesafb.
> ...

 

Here what I wrote at another place

vesafb usually support strange video modes as well, if card manufactures programmed them. If you have a laptop, the probability is high that the manufacturer has defined the VESA mode for the native resolution of the screen. The problem is that the codes for those modes are non-standard.

The tool to find the VESA codes for the modes your card supports is vbespy package from the bottom of

http://en.wikipedia.org/wiki/VESA_BIOS_Extensions

run it as

./vbetest 2> /dev/null

Note that the codes for non-standard VESA modes can vary from card to card. For example on my laptop mode 361 is 1440x900x8, while on my desktop the same code refers to 1680x1050x32.

You need to convert the VESA codes that vbetest reports to kernel codes passed as vga=. The rule is to add 512 and optionally convert to hex.

i.e 361+512=873 (decimal)=0x369 hex

But I concur that vesafb is not particularly fast, at least  for high rez/high bpp non-standard modes.

----------

## pappy_mcfae

I am not all that concerned with the frame buffer's speed, or lack thereof. I use X almost exclusively. 

When I'm not in an X session, I'm most likely emerging something that blew up and is preventing X from starting. At that point, the speed of the frame buffer is immaterial. I'm going to have to wait for compilation to finish. Once that's done, then I'm back running X, and then frame buffer speed is completely immaterial, unless I decide to pop into a CLI session while X is running. I don't do that a lot.

Blessed be!

Pappy

----------

## Evincar

The framebuffer (uvesafb) IS the bottleneck in my machine for many operations, specially decompression.

----------

## pappy_mcfae

So try an alternative. The kernel offers several: uvesa, standard VESA VGA, VGA, and the native frame buffer for your video card. I'll bet you get better performance with anything other than uvesa.

Blessed be!

Pappy

----------

## Evincar

 *pappy_mcfae wrote:*   

> So try an alternative. The kernel offers several: uvesa, standard VESA VGA, VGA, and the native frame buffer for your video card. I'll bet you get better performance with anything other than uvesa.
> 
> Blessed be!
> 
> Pappy

 

Nah, haven't really tried. I don't see why VESA VGA would be any faster (but if you say it is, I will try), and the NV buffer conflicts with the NVidia driver. 

I have simply added the "quiet" option to my boot to avoid hundreds of lines slowing it down, and switch to another terminal during emerges. The CPU fan is an instant giveaway if it fails, anyway.

----------

## pappy_mcfae

 *Quote:*   

> Nah, haven't really tried. I don't see why VESA VGA would be any faster (but if you say it is, I will try), and the NV buffer conflicts with the NVidia driver. 

 

I'm not saying it will be. It might be. I've used the VESA VGA for quite some time, and I don't see any speed issues whatsoever. Also, since VESA VGA doesn't need a userspace program, like uvesa, it's most certainly faster.

The only way you are going to find resolution to this issue is to experiment. That is why I suggested using different frame buffers until you find the one that works.

Blessed be!

Pappy

----------

## rjw8703

I have noticed that it is significantly faster(7x faster) compiling in an X environment than in a console.  I have tried all 3 of vesa implementations in the kernel and all of them were slower.  I have never understood why this happens.  In my mind, compiling should be faster in a console because of less overhead.  Can anyone explain why?

----------

## dmpogo

 *rjw8703 wrote:*   

> I have noticed that it is significantly faster(7x faster) compiling in an X environment than in a console.  I have tried all 3 of vesa implementations in the kernel and all of them were slower.  I have never understood why this happens.  In my mind, compiling should be faster in a console because of less overhead.  Can anyone explain why?

 

Well, there can be lots of reasons, all of them, probably, meaning that both modern hardware and drivers are much more optimizied for 2D graphics than framebuffer text output.

----------

