lkml.org 
[lkml]   [1998]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: useful ram on voodoo(2) cards?
On Mon, 14 Dec 1998, John Berthels wrote:

> Folks,
>
> Strange thoughts which I'd be grateful if someone could clear up for me:
>
> a) is the 8/12Mb of ram on a voodoo/voodoo2 card read/write-able? [I'd
> guess it should be writeable, given the card's function - but is it
> readable?]

I only have a Voodoo I, but if the VII is like the VI in this aspect
the answer is yes. There is a function in Glide which will let you acquire a
framebuffer lock and then returns a pointer to the framebuffer.

> b) If the answer to a) is 'yes'. Would it be possible to write a driver
> which provided a /dev/voodooram file

In a sense, this is already done by the little 3dfx.c file which
comes with the newer versions of Glide. This chunk of code compiles into a
loadable kernel module which adds a /dev/3dfx device to the kernel. This
device maps a linear region for the Voodoo framebuffer and one for its MMIO
space. You should be able to read and write directly to the framebuffer
without going through Glide this way, although given that Glide requires you
to acquire a FB lock I'd imagine that nasty things can happen sometimes if
you just read/write away blithely.

> and permitted people to do:
>
> mkswap /dev/voodooram
> swapon /dev/voodooram
>
> [Such a driver would presumably have to prevent simultaneous access to the
> card for graphics purposes or we would have some funky displays whilst the
> machine hosed itself.]
>
> And a subsidary question: given a), is this idea insufficiently ambitious
> and could/should such RAM be usable as real system memory, not just fast
> swap?

It probably can't even be used as fast swap. I suggested such an
idea in the old GGI FAQ, and someone later told me that the VRAM+memory
controller logic on standard video cards is designed around the assumption
that writing to video memory will happen much, much more often than reading
from video memory. I don't remember the particulars, but the upshot is that
bandwith reading from VRAM is maybe 1/4 of bandwidth writing to VRAM. As
such, VRAM reads will be so much slower than VRAM writes that any gains you
might have gotten from the extra RAM evaporate. If you have "normal" VRAM
I/O and maybe accels and DMA too (i.e. something is actually using the video
card for its intended purpose) going on simultaneously the situation gets
even worse.

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/

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