[Please note, that I am normally not on the list - too much additional traffic,
so please CC replies to me.]
> > >> No, that would be "Some people have valid objections to the current state
> > >> of ggi without knowing what is being worked on in the project :)"
> > > IMHO, GGI still has no strong concepts to support accelerated operations
> > > on PC GX cards. [...]
> > Define "strong concept". [...]
>
> not something like this:
>
> - ioctl() [... sloooow]
> - page fault [... sloooow]
> - soft-queueing of GX commands [... latency problem]
Please give a better option for badly designed PC hardware.
KGI deals with security-issues. And one important security issue (and IMHO
the very strong point of Linux) is system stability and availability.
Thus it is not a good idea to let simple user applications directly access
hardware registers in the average case.
Right, you cannot do this under normal Linux as it is now, too, so we are safe.
But then you can only do graphics as root.
The problem with this is :
Being root is fine for the X server (though one might want to check
rootshell.com to see what slight errors in there can already pose a serious
security problem), but definitely not for a binary-only commercial game.
I could give you several examples where running a suid-root graphics application
has left my system in an unusable state that required a reboot.
The conclusion from this is :
If you want non-root-graphics on badly designed PC hardware which doesn't
have a "safe" register set that can be exported directly to userspace
(this is something that people that really know how to do graphics, like
Linas Vepstas, the SGI folks, SciTech, ... [and we have them all on our
list ...] have been demanding for a long time, but noone hears them,
because the mass market OS(es) have no notion of stability being a
security concern ...),
you have to switch to some piece of priviledged code to access the hardware.
This can either be a server process like X or the kernel.
A change of protection ring is expensive. No matter how it is done.
OTOH it is necessary, if we want to preserve system stability.
> i did not say it can not be done, i just say that it's at least 70% of the
> really hard work. And the attitude was always 'acceleration? ah, we'll do
> that on another afternoon as well'.
??? I have an accelerated KGI driver running here on an S3 964. Performance
measurements show it being 4 times faster than the unaccelerated version
on the operations that are supported by the chipset, _though_ it is using
the "slow" ioctl code. And yes, I have written the code on one afternoon.
Surely performance could be improved by directly banging on the hardware,
but this would OTOH allow me to hang the system, too.
We could enhance performance a slight bit, by using something more direct
than an ioctl, yes, but that wouldn't cut it. Please note, that KGI drivers
are designed to be independant of the underlying OS, so the fact, that
Linux is for now using ioctls to access accelerator commands is something
that could be changed pretty easily, if someone comes up with a really fast
way of getting into a protected code-area.
> > I lurk on the GGI mailing list, and this is a
> > hot topic of discussion. Several drivers already do accelerated
> > operations on their PC GFX cards.
> yes, for millisec-latency tasks like clearing the whole screen. Just to
> mention one huge problem, on a considerable percentage of current PC
> cards, it is lethal to access the framebuffer from the CPU side, and let
> the accelerator chip access it too from the video card side. Virge cards
> last i remember corrupt random areas of the frame buffer in such cases.
> GGI currently lets users map the framebuffer.
Yes. Drivers for these cards either :
- enforce blocking mode acceleration, i.e. accel calls only return when
they have done their job (in the cases where double-sided-access
hangs the card) or
- synchronize mmaped buffer and running accelerator using the ggiFlush()
call (when nothing really bad happens, if some jerk doesn't do it
right).
We have noted that problem and taken care of it.
And it is the hardware that is actually braindead/broken. KGI handles it
just right - it prevents that these misdesigns cause system instability.
Cards that are designed nicely with a safely mappable register area
are accessed from usermode. As fast as possible.
We are however considering to allow KGI drivers to be built as linkable
libraries for those who don't give a damn about security and want all
possible speed. Will require SUID again, but has no penalties due to
change in protection ring.
> > Have you *tried* GGI? We have GGI Descent, many GGI demos, etc. Once
> > you've tried it, you can comment on whether or not the speed is sane.
> i have tried XGGI, and it's kinda slow.
I have _measured_ XGGI performance. It is exactly up to XFree86 except for
the accelerated parts, that are not implemented in XGGI.
When I hold the acceleration gain I measure with other applications against
it, we are quite exactly par with XFree.
The reason why acceleration in XGGI (only in the server, the drivers _are_
accelerated) is not implemented is simple :
The guy maintaining XGGI is - as he himself says - pretty clueless about X
and X servers. Noone that really knows X servers has yet bothered to help
us putting the accelerated commands of LibGGI in the right places.
It should be pretty easy - it's just noone seems to bother enough.
So much for the mail.
Now for some general GGI information I want to get known to avoid further
confusion:
1. We are not considering ourselves to be ready for kernel inclusion as the
default behaviour at this time.
We are actively working on a new console scheme we call EvStack and the patch
for this (which is really small ... 32377 bytes for 2.1.85) is designed for
smooth transition. The resulting kernel can be operated in 3 modes :
a) traditional mode. The patch is almost completely disabled, the system all
uses the old code and you should not see any differences. This mode can be
selected at kernel compile time.
b) compatibility mode. When you select the new drivers at compile time, you
can still get traditional behaviour, by simply loading a few modules that
re-establish almost all of the Linux-console features. I.e. traditional
apps like SVGATextMode and XF86 still run.
c) EvStack mode. Loading a KGI driver shuts off compatibility mode and will
thus break several old applications. If you want to run them, you can still
unload drivers again and go back to b).
When linux finally moves to 2.3.0, we hope to be ready. The frequent changes in
Linux kernel don't make our job easier (no, I'm not asking you to stop :-),
but we still seem to have some time left to improve our own code :-).
2. Flaming some project/people doesn't do any good. Please don't do it.
Constructive criticism is very welcome, and I am sure only such will come
from people that have read the mail that far.
[P.S.: Flamers - here is your chance: If I get enough ignorant, stupid and
insulting replies, I'll definitely head for another target. FreeBSD, Mach,
Solarisx86, Win32 - they are all just about two files away ...]
3. Why is our progress so slow ?
It ain't. It is a huge task, and we are only few. Note that GGI isn't just
yet another /dev/fb.
The KGI drivers are designed to run on multiple OSes (we still have to code
the interfaces for other OSes, because all of us seem to be interested in
Linux only ... :-)
And we do not only care about hardware drivers we also have :
- a set of portable graphics libraries that are capable of displaying on
about anything (KGI, X, SVGAlib, LibAA, termcap, memory, ...)
- a replacement system for the Linux console that allows for simple
implementation of alternate consoles (say ANSI, Xterm, SUN, whatever you
like), alternate input devices/methods, ...
- mutihead capabilities (yes, this works)
- several libs/apps we port/keep up to date, to show it is easily possible
( Mesa, XGGI, Descent, Doom, ...)
- compatibility modules that allows applications written for other APIs to
run on GGI. We want to be OPEN to everyone and everything.
4. Why do several ggi snapshots I tried not compile ?
Because our policy about committing to the repository is a bit "sloppy".
There are sometimes changes that affect several areas and it takes some
time until all maintainers have catched up. If you do not want to do
development and are thus prepared to force soime minor hurdles,please use
a stable release version or to be very sure, maybe you rather want to try
the single-disk-demo (found on my private webpage - this is nothing
impressive, just something to show it works, don't show it everybody ...
we can do better, but we need someone to maintain this beast ...).
5. Why is documentation so bad ?
Because most of us are of the general programmer type. We hate doing
documentation beyond some comments in code to show our fellow coders
what to take care of. Maybe some people here would like to lend us a hand ?
It seems to me, that there are quite some misunderstandings out there about
GGI. We would really like to clarify some of them.
Thus I volunteer to do the following (as if I hadn't enough work already,
but I think this really is important ...) :
Please send me any questions and comments you have about GGI. I will collect
them for a while, try to include them in our FAQ and post the results.
CU,ANdy
-- ============================================================================== = Andreas Beck | Email : <andreas.beck@ggi-project.org> = === World-Wide-Web URL : http://sunserver1.rz.uni-duesseldorf.de/~becka === ======== GGI - The Right Thing To Do : http://synergy.foo.net/~ggi/ ======== ==============================================================================- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu