> linker> I dunno, if it's a loadable module.. Who cares? If were just
> linker> an abstract method of allowing userspace to quickly do
> linker> accelleration it would be better..
>
> It may be simpler for user space application writers, however using a
> library like libGGI or a portable SVGAlib makes more sense from the
> application programmers view, thus he/she doesn't need to know how to
> fiddle with the registers.
Ok, we agree. :)
> As for space I do care - imagine having to do Linux installation
> floppies and having to put 50 video drivers on there which includes
> acceleration code just to get a simple console display ... its bad
> enough with the amount of drivers as it is already.
I dont think the the KGIcon people want that.. And I know I dont.
What I would see is a small set of BASIC drivers (like vesafb) that get
you going. If you want/need better performance you can get an optimized
driver and load it at runtime..
Yesturday I got KGIcon working.. It took awhile because the ggi package
didn't want to compile.. :)
Heres my expirence (I have a matrox II card):
I setup a stock 2.1.116-2 kernel with framebuffer support and compliation
fixes. I installed this.
I then compiled libggi and kgicon (which took me hours to get to compile)
KGIcon was compiled with support for my Video, Ramdac, clockchip, and
monitor. I made NO kernel modifications.
I booted up using vesafb (though I could have just used text mode).
Then I ran a little script that loaded kgicon.o and then ran a little
utility that moves the console onto the kgi frame buffer.
My console video was instantly TONS faster. (yes, vesafb is slow!)
GGI apps would run either way, but faster with the accelerated driver.
My computer crashed with lotsa oppsen in a little bit, it doesn't look
like the KGI code is SMP safe. :)
> Most cards do X fine in user space as it is now and it works pretty
> well. Having the kernel work as an arbiter telling the library and/or
> processes whether or not they can use acceleration will solve the
> problem.
I can hardly call 'running as root with direct hardware access' userspace.
Perhaps we need a name for things like that.. Dangerspace? :)
Actually, we are missing out on the features of newer X86 video cards
because of this. My matrox has the ability to do scather-gather dma and to
use IRQs, be we can't really do this from userspace.
Furthermore, X is prone to messing up the computer BAD. It's both faster
and safer to have video support in the kernel. I'm not advocating putting
all of X in the kernel.. Just the basics and I feel that the basic frame
buffer driver should be seperate from an accelerated driver.
GGI supports talking to dumb drivers, smart drivers, or acting as it's own
smart driver by banging the hardware directly. You can happily use the
first (by just loading the unaccelerated driver, a 'safe' approach) or the
third (not safe, and on some hardware not as fast as #2).. While I load an
accelated module into the kernel and use method #2 (and achieve the
balence of safty, and speed I want)..
You obviously approve to method #3, so why not keep an open mind about #2.
#2 doesn't need to be in the kernel itself. Those accelerated drivers
would be maintailed by outside people (like Xfree is). All they need is
the proper interfaces to stay in the kernel.
> linker> No, he's saying that people who dont wish to use accelerated
> linker> drivers with libGGI can never have acceleration on the current
> linker> FBCON driver. You could write your own libggi target that
> linker> banged the hardware and got acceleation.
>
> Same thing, no difference.
No, thats not the case. There are three main ways of doing video:
1. Dumb frame buffers in the kernel (we have this, it's slow, it's safe)
2. Userland banging the hardware (we have this, it's fairly fast, it's unsafe)
2a. same but with an arbrator.. (a little safer)
3. Accellerated Frame buffer in ther kernel (kgicon, it's safe, it's fast,
and you don't like it :))..
GGI supports all of these. So I can write an APP using GGI (like an X
server or a game) and when I use this app it will use #3. When you use it
it will use #2 (like Xfree) and when someone with a Neomagic uses it it
will use vesafb and #1..
So there is no reason for you to object to the existance of #3 drivers. If
those are not available it will fall back to #2,#1 depending on how you
care about safty and whats available. You can happily pretend that #3
drivers dont exist and never go download them.
> linker> It should go into the kernel, thats the only place it can be
> linker> multiplexed, used fully (irqs,dmas, atomic operations), and
> linker> used safely.
>
> And be slow.
No when done correctly it's fast. You can't use DMA in userspace right
now, so with cards that do that it has the potential of being MUCH faster.
Furthermore future cards will make more use of these features: AGP adds
alot of stuff that can't be done from userspace.
> Ok lets put it another way: A lot of people use older installations
> and are not very much interested in upgrading kernels regularly due to
> the `if it works now, don't try to install something that may break
> something else' strategy. Thus if we tie the whole graphics
> acceleration stuff (which primarily means X) to the kernel it means
> that people will have to run and get new kernels to get the new and
> improved X servers that can run using acceleration on their hardware
> same goes for bug fixes.
I'm not suggesting we only allow acceleration in the kernel. I'm saying to
give people a choice.
> So far X has developed parallel to the kernel and people have been
> able to run new X servers with older kernels - using something like
> vesafb will allow this to work in the future, ie. you can continue to
> use your known to be stable kernel to set the video modes and get the
> new accelerated X server when it becomes available. Afaik X servers
> often first become available in a non-accelerated version and later
> comes the smart and improved version.
Thats fine, they can still use an X server that bangs the hardware.
The only thing that needs to be upto date in the kernel is the basic video
support to get the computer to boot up.
> linker> Ok fine, I'll take your bet and double it. What PROPER
> linker> hardware can I get for X86 that can do FULL ACCELERATION
> linker> safely from userspace? It would need to have support for
> linker> hardware context switches and be able to get steller
> linker> performance without the use of DMAs or IRQs. AFIK there is
> linker> NONE, and if there it it's not common..
>
> Someone mentioned the Matrox cards, but admittedly I don't know PC
> graphics cards that well. Anyway what I am opposed to is the idea that
> because some PC hardware is broken, we degrade the performance for
> everybody by putting it in the kernel as default (I don't expect
> anybody to seriously want that we have two parallel developments of
> graphics drivers).
Nope, the matrox cards have some of the normal PC brokenness. Furthermore,
to get full performance you need DMA support.
How about we just have video drivers that can be compiled so that they are
kernel modules, or compiled so that they work from userspace. Dont laugh,
that's that the GGI people are upto..
I'm not suggesting accelerated drivers should be the default, I dont even
want them shipped with the kernel. I want dumb drivers as the default
(like the current 2.1s have) and the ability to either bang the hardware
from userland (like we have) or the ability to load a modules to give an
accerated kernel driver (like we have but you dont like).
> linker> But again, you've wanted us to include various strange network
> linker> drivers in the kernel which never outta be included in the
> linker> kernel. :)
>
> Those you can just decide not to compile in (I asume you are referring
> to the HIPPI stuff) - on the other hand if I want to build something
> generic I need to put in a ton of graphics drivers and the
> introduction of new PC graphics cards on the market seems to be going
> a lot faster than anybody can keep up with.
Then you can just not go download the accelerated drivers.
> linker> Come on, this isn't a microkernel here. It's monilithic. We
> linker> include HARDWARE drivers in the kernel..
>
> Just because its a hardware driver it doesn't necessarily need to go
> in the kernel.
Then lets remove all the hardware from the kernel. It's possible. :)
Lets see.. Heres some DUs
8496 scsi
3324 video
8992 net
5102 char
2948 sound
Wow, that would shrink the tree by alot. :)
You are saying video should go in the kernel because there are too many
cards? I imagine that if you combine scsi, sound and network you have ALOT
more new devices per year then video.
I dont think new devices are that much of a problem, they arn't under
windows. At least our dumb drivers are better then windows's (without a
driver you are luckey to get >16 colors under windows, unless the generic
svga driver works, which only gets you 256 colors), with vesafb any person
with a new card should have basic unaccelerated graphics as soon as it
comes out..
> I thought the EvStack concept was killed on linux-kernel earlier as
> multiheading could be done a lot simpler.
Multiheading can be done easier. However multicant.. I'de love to be able
to get a nice dual 300 with 256mes of ram and share it with my girlfriend
(who's computer is next to mine) this would save me the bother of having
two seperate computers for us but allow us to use it at the same time..
This how this would go over in a computer lab..
A single PII dual 300 with two mice/kbds/screens costs less then two
single 266s with their own stuff. Further more, when user A is idle user B
gets more processing. Furthermore, computers today have more CPU then most
people need. When they do need CPU is only in short little bursts, like
when they open up apps and such.. 90% of the time the computer is IDLE..
So putting 4 people to a single fairly fast computer is a great way to
save money, and they would only notice when they all load differnt things
at once..
> Jes
Gregory Maxwell
-
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.altern.org/andrebalsa/doc/lkml-faq.html