> On Mon, 8 Feb 1999, Shawn Leas wrote:
>
> You still want to go the way of DOS. I remember downloading a JPG
> veiwer called QPEG, and it had video drivers bundled with it.
>
> Sounds a little like X, eh?
>
> then again, use the right tool for the right job, and don't let
> principles get in the way of practicalities.
We are trying.
> Is the hassle of implementing full-blown, accelerated, concurrent
> access, graphics drivers in kernel worth the effort?
Yes. Clean solutions which do not affect performance and *add*
functionality should always be chosen. KGI is such a solution.
> how many people really need to have several processes
> concurrently writing to the graphics hardware?
Anyone who wants to run more than one acceleration-using program
of different VCs. Gotta be able to gracefully handle the VT switch.
> As it stands i can
> think of only two: X
X is not part of the kernel. It should not be handling VT
switches, which it must do in order to manage the hardware like you are
proposing. Plus this ties everyone to X. I am still at a loss as to why
people who are normally advocates of choice in the OSS world suddenly turn
extremely conservative when the subject is accelerated graphics or X.
People claim that KGI is forcing people to do everything "our way", but in
reality all it does it *manage* the graphics hardware, like ALSA does.
Plug 'n play and all that. KGI is to fbdev as ALSA is to OSS - more or
less the same thing, but one is much more intelligent than the other. And
that intelligence is *needed* and does NOT cause bloat.
> and a direct render graphics layer - which
> would have to co-operate with each other to be of practical use
> anyway.
A direct rendering layer is a good idea, but it must be an option.
As others have pointed out, unless you have SGI-style 'smart' hardware,
the software locking/validation that will be required for direct rendering
will destroy performance. In that situation, direct rendering is FAR
worse than having nothing at all. KGI can easily allow for direct
rendering when the hardware supports it - mmap() the registers and get out
of the way, basically. Zero overhead. But KGI also supports older
hardware which must have its accelerations wrapped in ioctls or another
form of abstraction in order to ensure stability.
> [X is the de facto UNIX graphics standard for the foreseeable
> future, for better of worse. {better imho}.]
Sure, and the new which is under development KGI fully supports
XAA and friends. We aren't stupid, of course X must be supported fully!
But there is absolutely no reason at all why X must be the *only* thing
supported. The X people have no justification for demanding that everyone
must do things their way and only their way, when their way can be fully
supported while simultaneously allowing non-X solutions to be able to take
full andvantage of hardware acceleration.
> If it was for a single platform with a reasonably limited range
> of graphics hardware - then maybe yes. But for an OS that covers
> so many platforms? and those platforms cover how many weird and
> wonderful different graphics hardware?
>
> And which cards are capable of what? How do you present a uniform
> interface? How would a uniform, rich, in-kernel, 3d & graphics
> implementation run on my P133 with Trident TGUI graphics card?
> Keep it too simple and you're wasting the more exotic hardware.
>
> So perhaps it's best to let the kernel stick to a limited
> knowledge of the graphics hardware, so that it can always
> clean-up if needs be. And let the higher level stuff sort it out
> between themselves as to what they want to do.
That is *exactly* what KGI is designed to do!!! The number of
people on this group who are bashing KGI and quite obviously don't know
even the basics of how it is designed and how it works is very disturbing
to me. I'm not specifically referring to you, but I have seen some real
howlers in this thread over the last couple of days.
> If needs be, some basic functions can always be migrated from the
> higher level into the kernel. but let X and co worry about
> concurrency and arbitration and things like that. The kernel has
> enough of that kind of stuff to worry about already.
You say this, but you do NOT say *why* concurrency and arbitration
in the kernel is bad. No do you state which types of concurrency and
arbitration you are referring to. KGI goes to great lengths to provide
userspace with the mimimum set of capabilities it needs to handle these
issues in e.g. LibGGI (which is a good chunk of what LibGGI does, in
fact), and the stuff that remains in the kernel is quite minimal and does
not impact performance unless you are using an old, braindead card in
which case you shouldn't be expecting good performance anyway.
> Eg, DEC faced this issue when they tried to go head to head with
> SGI with their PowerStorm graphics card. Their solution was to
> implement direct rendering with the X server handling concurrency
> issues.
That's the cheap way out. It works, but in a very restricted
hardware and software environment. As you mentioned above, Linux has to
run in a huge number of very different environments.
> X can then arbitrate between multiple X protocol and
> direct render clients, as it sees fit. Only that with direct
> render clients the X server doesn't need to do any rendering
> work, the direct render client and the X server just need to set
> things up via the X protocol.
>
> X is already an arbitrator, why reinvent the wheel when it can
> just be extended to arbitrate between more types of clients?
Because there's no reason to! Even if you do direct rendering,
why does the arbitrator have to be tied to X? The answer is that there
is absolutely no reason, other than that some people seem to have this
wierd, quasi-religious attachment to X in Unix environments.
> (Direct render clients can be anything by the way. Doesn't have
> to be OpenGL.)
Sure, and the arbitrator doesn't have to be X either.
> This way, we keep a standard and already uniform graphical
> interface, X. And we can write extensions to it to support a
> uniform high-performance graphics layer, "direct render" for more
> advanced graphics cards. And we don't clutter the kernel with
> highly complicated code that could run in user-space.
Some points:
* The 'clutter' is quite minimal.
* The 'clutter' does not exist unless you use an old card.
* The 'clutter' is as fast or faster than the current system
* The 'clutter' is absolutely 100% required in order to give Linux the
ability to multihead cleanly.
* The 'clutter' will allow everyone who wants to do accelerated graphics
on Linux to do so, with or without direct rendering or X.
> [eg: why can't the kernel do sound mixing? - so that 2 or more
> processes could write to /dev/dsp concurrently and produce a real
> mixed sound? the implementation itself exists.....]
Put that functionality in a module, so that the people who want
this functionality can have it and everyone else doesn't have to use it?
And maybe put a couple lines of code in ALSA which would allow it to use
the in-kernel mixer or a userspace mixer as needed?
Jon
> regards,
>
> Paul Jakma.
>
> (perhaps this thread should be on another list.).
Why? Doesn't this issue directly impact the kernel?
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/