From: Dr. Michael Weller (eowmob@exp-math.uni-essen.de)
Date: Wed 10 Apr 2002 - 18:03:04 IDT
On Wed, 10 Apr 2002, Steven Seeger wrote:
> I had to put a demo together on an Accelent StrongARM IDP over the weekend.
> I could not get SVGALib to work with the lcd screen's kernel FB driver
> despite everything. I debugged it and saw that SVGALib would crash the
> graphics hardware when trying to save or restore SVGA regs. Taking all those
> calls out didn't help, so I ended up writing my own code to work directly
> with /dev/fb0 and that worked fine.
>
> Then I got to wondering if that might be faster than using svgalib. I do
> most of the writing with memset and memcpy, and implemented my own double
> buffering technique and all that fun stuff. Would minimal code talking to
> /dev/fb0 using things like memcpy which use the rep/sz opcode be faster than
> having additional overhead involved with SVGALib and the GL lib? Or, am I
> better off with SVGALib using a PC-104 with a C&T driver on it because it
> supports the accel stuff?
>
> Just wondering if anybody ever did any testing.
>
> I might do some timing tests on it myself. It would be nice to standardize
> across platforms here, and if we get rid of SVGALib and use /dev/fb that
> gives us more options in the future to move to other platforms running Linux
> without having to redocument all the code.
Uhm.. well, you are poking into a wasp's nest (german proverb). You might
check old FAQs or so for detailed comments.
Svgalib is certainly a hack with regards to stability and the fact that an
application will take over hardware and some VC switching task which
should better be done by kernel in a non-cooperative multitasking manner.
On the other hand, there is or was a strong in urge in kernel land that
all graphics stuff is to kept far away out of kernel, one part due to the
believe that the graphics card and console is not a device shared among
non-cooperative processes like a disk where the kernel must take control,
the other part since all the existing work arounds: X11, svgalib, ... work
so well.
This is an endless thread.. it lead to the development of KGI and other
things, currently /dev/fb is an intermediate(?) solution, back ported from
linux variants not having SVGA cards like i386
Back to you original question: Doing the memcpy or whatever direct memory
access will be faster. For one: Svgalib does nothing else. However,
it needs to think about vga pages to flip and so on, which makes it use
'less simple and straight forward code'. With /dev/fb you can just use
fast memcpy operations, and either /dev/fb uses a linear, non-paged
frame buffer or page faults are generate by the CPU were needed.
You can believe me on that. I did such tests AGES ago.
Ok, you are talking about vgagl and acceleration. I claim from your
mail, that /dev/fb doesn't support graphix acceleration. svgalib, indeed,
does. If your operations may fit into this scheme and depending on the CPU
speed it might indeed be faster than memcpy. Alas, AFAIK, only two
cards support acceleration. Mach32 (by me) and C&T. You'll only benefit if
you have some of these (not really modern) cards. After having had a hard
time modeling Mach32 acceleration to fit into the C&T biased scheme, I had
to learn by its author C&T acceleration is not so mature either. Not
everything works and its not used everywhere.
Despite of the name vgagl only simple bitblt will be accelerated where
-still- a memcpy on a modern cpu and a modern bus interface to vga memory
can compete easily. Complex 3d operations aren't supported anyway. If you
need acceleration there, I suggest using Mesa or so and some X11
integrated 3d hardware where drivers for linux exist.
So, I think you should not make up your decision on bitblt acceleration.
There are more important points: Namely /dev/fb* is not supported in all
i386 setups, you need recent kernel hence recent installation which need
more memory & cpu power. /dev/fb* will not support all graphics cards
(like svgalib, but it might support one /dev/fb doesn't and vice versa)
On contrary, /dev/fb* is used one some non i386 (some, like Alpha, support
svgalib though.. but to which extend I don't know). Even if there is a
/dev/fb it might be controlled differently .
You should better make up your decision using such compatibility and
portability issues considering the expected user targets of your program.
Michael.
--
Michael Weller: eowmob@exp-math.uni-essen.de, eowmob@ms.exp-math.uni-essen.de,
or even mat42b@spi.power.uni-essen.de. If you encounter an eowmob account on
any machine in the net, it's very likely it's me.
------------------------------------------------------------------
Unsubscribe: To: listbot@svgalib.org
Body: unsubscribe linux-svgalib
This archive was generated by hypermail 2.1.4 : Wed 21 Jan 2004 - 22:10:24 IST