Messages in this thread |  | | Date | Thu, 6 Jun 96 01:14 BST | From | Jamie Lokier <> | Subject | Re: SVGA kernel chipset drivers. |
| |
Here's my ramblings on the topic. I'd ignore them if I were you -- you must be bored with this thread by now.
Efficiency ==========
SVGAlib and X are just fine, especially with XFree86's DGA capabilities. I say this as a commercial game developer myself. I'm using Linux to develop, even though the final thing need only run under DOS and Windows 95. In fact, at the moment it runs about 20% faster with SVGAlib than with DOS VESA drivers, because SVGAlib can page-flip on my Cirrus card, which VESA doesn't support. (Though VBE == VESA 2.0 does).
One thing which can be slow is switching consoles. When I switch between X (which I don't use all that often) and textmode, it is a bit tedious watching the machine take 5 seconds to swap 2M of framebuffer. I would hope a kernel video driver could track the console ownership of individual VRAM pages, so switching from X only needs to save those few pages required for textmode. You get the idea.
Features ========
I still think we need a VM-simulated framebuffer, just so we graphics programmers can move on and forget about old PC video cards, but know that the software will run, albeit not very fast, with everything from VGA onwards. Microsoft DirectX does it (optionally), probably for a similar reason. (So they don't have to write lots of bank-switching rendering code -- they can concentrate on code that works well with modern cards).
For now, my rule is simple: if the memory aperture (usually 64k) is smaller than the screen area, just do everything in system memory and copy it to video memory later. This is not really a bad strategy, but I would prefer a VM framebuffer option.
Right now, you can't switch consoles when debugging an SVGAlib application -- because the switching process is suspended by GDB. This is an argument against SVGAlib, of course. Another problem with SVGAlib is that it can only clean up on a crash if you're not trying to use the signals for something else (as I am). Fortunately I have `rsh'... Again this is really an argument against SVGAlib but not for anything else particularly.
Suggestions ===========
Perhaps what we really need is XFree86/DGA to be able to take over other VCs. The idea is you have an X server permanently running on another console, even if you don't use X. When an application (SVGAlib or whatever) wants to use the screen, it connects to the X server somewhere and tells it to take over the application's console. The server already knows everything it needs to know about the video hardware.
Perhaps it would be better to move the video-specific part of XFree86 into a separate "video server", which will take over VCs on demand. Much like GPM provides mouse services to every VC.
IMO, GGI sounds about right. I think it is best to get the following features working for as many video cards as possible:
* Save/restore state when console switching.
* Screen start address/page flipping.
* Get/set palette.
* Wait for blit to complete; lock console until it is done.
* `mmap' framebuffer is moved to system memory when that console is not displayed -- the application needn't be aware of the change.
* VM-simulated framebuffer for non-framebuffer video cards.
* Record ownership of used VRAM pages.
* Support for VESA BIOS, just so that more cards get supported for free.
I/O port programming to set the video mode would be just fine in a setuid program. Just as long as the kernel driver knows about all of the state it has to restore. Preferably the program would sent the new state through an `ioctl' to the kernel, just so the VC doesn't have to be locked or even displayed while the program runs.
My view on X ============
Lots of people don't use X, because it uses lots of memory (only a problem for small machines), and because some people don't like it. I personally don't use X except when I have to, simply because, with my low-quality monitor, it gives me eye strain and a headache. (Guaranteed, after a couple of hours). Text mode is fine. Thus I would very much dislike being forced to use the X GUI to spawn graphics programs.
Compiles take longer with X swapped in too, even on a 16Mb machine. (Even `make' has been known to need 30Mb VM on my project 8-o).
I've nothing against using the X server to control the video hardware though. Presumably with DGA, it wouldn't even need to page in many parts of the X server. Just so long as all I see is text mode and the full-screen graphics application, I'm happy.
There, that wasn't really worth reading now was it?
-- Jamie
|  |