> > > * In userspace you can't use interrupts, which some newer cards generate.
> > > (eg. Riva 128)
> > haven't seen any realy fact that you really _need_ interrupts and that
> > interrupts will improve performance and won't lower it due to costs
> > of interrupts. I don't know the Riva128 chip, but e.g. S3 chips have
> > very small coammnd FIFOs and here interrupts aren't worth.
>
> It is useful for 3D operations which take much longer time to accomplish.
> This is not in the current X servers, that's true.
I don't have any detailed experiance with 3D, but I assume basic operations
still are pretty fast and small because
- you need more parameters thus filling up the FIFO faster
- you want to render _small_ patches to get smoth pictures and small object rendering
is fast(er)
- even a full Linux clock tick (10ms ~= 100Hz for ix86) is only a fraction
of a full screen refresh and _long_ compared to 3D operations as you
usually want _many_ 3D operations per screen refresh.
but that's only a very rough estimate and I could miss here.
how large are command FIFOs for other 3D chips (Riva128 etc.) ?
> And, saying DMA in userland didn't perform well doesn't imply DMA wouldn't
> help, it could also mean that it can't be done fast enough in userland. Well,
> I can't see this far myself, so I don't say which is it.
to my understanding there is no performace difference once you've setup
the (contigious?) memory area for DMA (which is what you need kernel support for,
plus virt->phys. address conversion).
but again, this is theory as I haven't played with DMA myself.
> I'd have to put SVGATextMode into X's console switching routines, and into
> DOSEmu's console switching routines and, .... Or I would have to restrain
> myself to 80x25. Neither is what I like to do.
I'd guess that having SVGATextMode features in X is no big deal at all.
just one more mode line to be set, most of the VGA stuff can be reused
(and IIRC SVGATextMode shares code with X anyway?!).
additionally, most of the time it's really only the text mode pixel clock,
not the whole mode line stuff (standard VGA registers _can_ be saved).
don't know about dosemu (this one is a real argument and might be a problem
for some cards when not using 80x25 -- but just using non-80x25 is not
enough reason for my (personal opinion)). maybe it should be enough
to specify clockchip and text mode pixel clock rate here too.
> True. But it's 2 megs of code. Most other suid programs are much smaller,
> and thus the risk of an overflow hole is much smaller.
yep. but I still would like to dream of a much more generic solution
for all these SUID/root holes. no argument for current X, but no real big
argument for GGI too...
> > I stop here trying to argue against all those "X can't ..." and
> > "GGI/kernel will be able...". just write the code and show
>
> Okay, I'll try to. ;)
great! one of [few] the positive outlooks in this thread...
> > that it's that much better, safer, faster, than advertized for
> > a very long time and in may mails now and all users will happily
> > convert to GGI and vote for it. but now... ?!?!
>
> It's a bit shame you didn't comment my whole posting, just some parts of it.
> I'd like to hear your opinion.
sigh, I was afraid of that :-( this thread already takes _way_ too much
of my own time -- not to speak of the total sum of valuable developers' time.
but being nicely asked...
> * In XFree, there is a huge generic X11 code, and much smaller driver part.
> However, all of the code has access to the whole system, since it runs with
> root privs. Thus a crash anywhere in the 2 megs of code can crash your
> system. If the driver and generic parts were separated, crash in the generic
> X code would only result in X crashing (And restoring to text mode) and not
> system crashing.
when the X server SIGSEG-faults, it calls the signal/exit handler
to restore text mode. this works pretty well for _many_ crashes
(but a usual with software, nothing is perfect and everything can be improved).
if the system complete locks up it's either a hardware problem or
a programming bug or knowledge problem. neither depends on
user/kernel mode or big/small driver.
the real question is how you can separate basic X code and driver
farther from each other do increase reliability without adding
delays at the interface (either my task switches or user_mode->kernel calls).
if a X server crashes right now, this happens almost all the time
during running in some graphics routines. and here performace is much
more important. but in this situation, VGA/ramdac/clock setup is completed
and at a known state, so that restoring old/other settings in the exit handler
isn't a big problem.
> * Were the graphic card support in the kernel, the applications could work
> with abstract enough layer and not have to deal with every card possible,
> eg. it won't be needed to have many different X servers. (The whole
> abstraction layer wouldn't need to reside in the kernel, but in some
> library. In the kernel there could only be functions to safely use all the
> feature of the one specific card the driver is written for.)
again, you don't need kernel for that abstraction. XFree86 4.x will use
XAA as this abstraction layer and this layer will call _small_ (esp. when
compared to old S3 accel. code;) chip specific modules, which can really
be loaded (and upgraded) as single small modules then.
and the nice thing is that this is already running for many platforms
and many cards (thanks to the donation from Metro Link of the
modul loading technology...)
> * Were the graphic card support in the kernel, it'd be enough to add a new
> driver to the kernel, and not to have to write several drivers for XFree,
> SVGAlib, SVGATextMode, DOSemu .... Thus work could be saved.
it can't, at least IMHO. remember that XFree86 is not a Linux-only project,
which is one more reason that a Linux-only (and maybe some *BSDs too) kernel
interface wouldn't be enough for all our supported platforms (e.g. SCO,
Solaris, even OS/2 and others) and we'd still have to do the same user-level efforts
for them too (as long as KGI/GGI isn't ported to _all_ platforms).
and while I'm only using/working on Linux myself I consider this as
an _important_ point of freedom of X sources to support them in the future too!
(or if yoy like it that way: every system and OS using XFree86 is a system
where M$-WinXY isn't running, no matter if it's Linux or not;)
> * Were the graphic card support in the kernel, and the same .graphic. mode
> usetd both for X and on console, the switching would be lightning-fast, as
> the monitor won't have to resynchronize.
not true again. speed of mode switching is by no means limited by
user mode stuff (I know this resyncing very well from my own taxan,
for some cards/modes it even completely switches off).
the reason (at least for S3 stuff) for some cards syncing so slow
is that you have to wait a `long' time (compared to resync-timeout
of some monitors) for some clock chips to run in sync or being programmed
etc. or you have to wait for vertical retrace (one or more)
before you safely can change some register settings.
these delays depend on _hardware_ (or on it's specs at least;).
> * There is already fbcon for other (non-PC) architectures.
don't know very less about `other architectures' except a bit
on DEC AXP. and here X11 works fine right now and AFAIK
fbcon is no real problem running XFree86 (is it? don't know
too much here...)
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu