lkml.org 
[lkml]   [1998]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel videocard support YES or NO?
On Sun, Mar 29, 1998 at 06:34:21PM +0200, Harald Koenig wrote:

> > * 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.

> > * In userspace you can't do DMA well, and DMA is very useful with never
> > videocards and there are some whose performance would be poor without it.
> > (eg. Pyramid 3D)
> I have seen tests with S3 ViRGE chips using DMA in user-level code
> to transfer images. performace tests showed it's not worth at all
> (for this specific setup, of course YMMV -- but it's tecnically possible!).

True. But, for example the Pyramid chip almost can't do hardware acceleration
without DMA.

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.

> > * In userspace it is not a good idea to do a cli(). It's a big stability
> > risk. However, this is needed for many graphic cards to communicate with.
> not true that is needed `for many graphic cards to communicate with'.
> please check tecnical docs and X sources before inserting more and more
> myths here :-(
> > (You should cli() even for a standard VGA, because of at least one register
> > that's flipflopping between index and data state.)
> there is exacly one driver (called `The X Server [tm]) touching the graphics
> chip, so this isn't needed. and if you're thinking about multiple threads
> rendering simultaneously you'd need locking etc. no matter if you're running
> in kernel or user mode.

You're right; sorry.

> > * In userspace you can't do good console switching, because many videocards
> > (eg. SPEA Mirage P-64) have write-only registers, and with that it's
> > impossible to properly save and restore video state when you don't have
> > centralized support for it.
> because of write-only registers you have to use fixed setup tables
> for those registers (which will cause other problems).
> again, this won't depend on user or kernel mode. either you run
> something like SVGATextmode, or put this code in X server's exit handler,
> or ...

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.

> > * In userspace you need to have root privileges to control the video
> > subsystem, which inherits security and stability risks. (Eg. A buffer
> > overflow in the application can give you root access)
> so we need a much better security handling, priviledges shared libs
> and much other things. but this isn't a topic for KGI because the
> X server is not the only suid-root problem (at least not in my system;).

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.

> > * Acceleration support should be in the kernel, too, because most of the 3D
> > accelerated cards use DMA, which can't be well used outside kernel, and, if
> > done, must be restricted to root privileged user only, because it gives you
> > a complete control of the system. Thus you'd need setuid graphic programs.
> again, prove that it's usefull at all! and please don't claim it's not
> possible in user mode with minimal kernel support.

I don't. I don't say how much of support should be in the kernel, just that there
should be some support for acceleration, for example checking the destination
adresses for a memory move using DMA ... so that this interface could be open
to any non-root user without security risks.

> 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. ;)

> 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.


Vojtech Pavlik.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.216 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site