>I took to using X, with a single screen size xterm to present the
>illusion of console mode.
Cute trick. I have seen some slow text mode cards. As time goes on it will
get worst since text mode support is not the prime goal anymore. Especially
now that you see graphical BIOS interfaces. Some graphics cards manufactures
have dropped vga text mode support all together. In the next 5 years you
will see the elimination of vga text mode.
>Probably the lack of hardware area copies has something to do with
>this.
Yes this is problem. See my response to Paul about this. The only reason
I'm using MMX for the vesa framebuffer because it has no acceleration. MMX
gives a big boost for genuine intel chips. Other types of MMX are fast but
they don't seemed to be optimized for memory transfers like MMX on intel
chips. I also have regular code that does all kinds of tricks to optimize
data transfers over the bus. It needs more testing but from my comparison
between my voodoo 3 accel engine and this code it ran nearly as fast as
the accelerator at all depths :-)
Another idea for 2.5.X is to implement a font cache in video memory. Even
with AGP it is just to slow to constantly transfer font data over the bus.
Of course this requires a bit of work since we only have so much video
memory but it is worth it for the performance improvement.
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 [[email protected]] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
> Yes this is problem. See my response to Paul about this. The only reason
> I'm using MMX for the vesa framebuffer because it has no acceleration. MMX
> gives a big boost for genuine intel chips. Other types of MMX are fast but
> they don't seemed to be optimized for memory transfers like MMX on intel
> chips. I also have regular code that does all kinds of tricks to optimize
Then you are doing something badly wrong.
The MMX memcpy for CyrixIII and Athlon boxes is something like twice the
speed of rep movs. On most pentium II/III boxes the fast paths for rep movs
and for MMX are the same speed
Alan
On Mon, 2 Apr 2001, Alan Cox wrote:
> > Yes this is problem. See my response to Paul about this. The only reason
> > I'm using MMX for the vesa framebuffer because it has no acceleration. MMX
> > gives a big boost for genuine intel chips. Other types of MMX are fast but
> > they don't seemed to be optimized for memory transfers like MMX on intel
> > chips. I also have regular code that does all kinds of tricks to optimize
>
> Then you are doing something badly wrong.
>
> The MMX memcpy for CyrixIII and Athlon boxes is something like twice the
> speed of rep movs. On most pentium II/III boxes the fast paths for rep movs
> and for MMX are the same speed
As long as you are copying in real memory. So the PCI bus or the host bridge
implementation may be the actual limit.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
> > The MMX memcpy for CyrixIII and Athlon boxes is something like twice the
> > speed of rep movs. On most pentium II/III boxes the fast paths for rep movs
> > and for MMX are the same speed
>
> As long as you are copying in real memory. So the PCI bus or the host bridge
> implementation may be the actual limit.
The CyrixIII sits on the same host bridges as the intel processors
Alan Cox <[email protected]> writes:
> > > The MMX memcpy for CyrixIII and Athlon boxes is something like twice the
> > > speed of rep movs. On most pentium II/III boxes the fast paths for rep movs
> > > and for MMX are the same speed
> >
> > As long as you are copying in real memory. So the PCI bus or the host bridge
> > implementation may be the actual limit.
>
> The CyrixIII sits on the same host bridges as the intel processors
I don't know if it applies to this case but one thing I have seen make
a noticeable difference is whether or not write-combining is enabled.
If we have only be enabling MTRR's for intel this could do account
for it.
Eric
Eric W. Biederman wrote:
> I don't know if it applies to this case but one thing I have seen make
> a noticeable difference is whether or not write-combining is enabled.
> If we have only be enabling MTRR's for intel this could do account
> for it.
And on some laptops, even on Intel MTRRs are not enabled for 2.5M
framebuffers.
-- Jamie