> > Jon M. Taylor wrote:
> >
> > > Mike A. Harris wrote:
> > >
> > > Are you saying that swap to VRAM would be slower than swap to
> > > hard disk?
> >
> > No. I am saying that you'd better not be wanting to do any
> > serious video work with the video card if you do use it for swap. And
> > normal system [S]DRAM is cheaper and sits on a faster bus with no
> > contention from other I/O devices. AGP and/or UDMA architectures will
> > render this idea obsolete anyway.
>
> From my point of view, the idea comes pre-obsoleted and is not a
> mainstream thing. It is just a quick (fun) hack for the people who have a
> dual work/play machine.
Granted.
> When the card is in use, you had better not really be using swap (frame
> rate would not be good).
You had also better have some method of ensuring that your video
driver (XFree86, fbdev, KGI, Glide, whatever) does not allocate display
buffers on top of whatever VRAM you are using for your swap. For
fbdev/KGI drivers (as long as they are no being preempted by other
userspace drivers) this will be doable, but for Glide and XFree86 it will
take quite a bit of work.
> When the card isn't in use you might be doing some real work, so why not
> make use of that silicon sitting there in the box? [The PCI bus contention
> is one reason why not, but if you were swapping the data would be going
> over the bus anyway.]
Because it is a PITA to get "right". That is why it was never coded
by GGI - it's not worth the hassle. But it would be a neat hack, for sure.
Doing it right would be even cooler, and doing it optimally would be *really*
impressive. Optimally means that the size of the swap buffers in VRAM are
tuned on the fly in tandem with the needs of the video driver - framebuffer
size, the size of zbuffers/wbuffers/doublebuffers, mode timings,
accelerator/DMA needs, etc.
Another idea that was kicked around by GGI was adding a scheme for
RLE compressing per-console framebuffers for backing storage purposes.
Voodoo and some SGI-type workstation graphics hardware can do RLE stuff in
hardware so RLE backing storage could stay in VRAM, other cards would have to
compress/decompress using the CPU so that would be less efficient. But
especially if you use a lot of VCs with GUI stuff in their display buffers,
RLE compression for backing storage becomes a big win.
> >From the answers to the list it seems that an idea would be workable
> [Voodoos and similar cards seem to have drivers providing read/write
> framebuffer-like access already], so I'm encouraged to take a bit more of
> a look at it. It seems like a good way to learn about drivers anyway.
I seriously doubt you will be able to get enough programming info
about Voodoo chipsets to pull this off without violating a 3Dfx NDA or
reverse-engineering Glide. Too much of the particulars of the hardware
programming is locked up inside Glide. I have considered the idea of linking
the Glide library .so files with some kind of a wrapper that would allow
Glide to become a loadable kernel module with all the Glide API exported
through the wrapper to the rest of the kernel, but I have never done the
research to find out for sure whether or not this would be possible.
> [Disclaimer: I know so little about the kernel internals that it is
> embarassing. But it all looks very interesting.]
Do some studying. You will soon discover that it is not quite as
simple as you are making it out to be. But it *is* very interesting.
Especially the parts dealing with video hardware |->.
> [Of course, a rinky-dink solution would automagically migrate pages from
> the graphics card to disk swap when you wanted to use the card as nature
> intended - perhaps by pre-allocating the relevant disk swap. But now we're
> getting silly :-)]
Like I said above, you'd have to have the video driver be made aware
of this dual-use VRAM idea, and the Linux MM subsytem would also have to be
tweaked to be aware that this additional swap capability was available.
Sure, the idea *is* a bit silly, but part of the coolness of Linux is that,
since the source is available and hackable, every silly idea can be tried
out. Some of the silly ideas turn out not to be quite as silly as first
thought when they are implemented.
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/