From: Steve Fábián
Sent: Wednesday, August 20, 2008 6:42 AM
Subject: RE: [Open Forum-t-404] VGA memory
>
> Rex Clark wrote:
> | Is there away to map "on board VGA memory" into the systems memory
> | pool Example say VGA card has 512mb and your not using a GPU/memory
> | intensive app "GAME/PHOTO EDITING" etc
> | and assuming 32MB would be adequate for general everyday window GUI
> | usage but when needed all VGA memory is available to the GPU
>
> I seriously doubt it is possible to map memory on an external device,
e.g.,
> a video card in a PCI or even in an AGP slot, into the main system memory.
> The hardware access mechanisms are different.
Actually, it is my understanding that precisely this is possible, and it is
in fact how video memory is typically accessed. Part of the memory
management system -- I'm not sure if it's within the CPU or on the
motherboard but I suspect the latter -- can be programmed to redirect
accesses to specific memory addresses to hardware devices. It is also used
for network card buffer transfers and some kinds of sound cards that do
accelerated multichannel mixing.
Back in the day, I used to code fun little graphical things for DOS (mostly
in QuickBASIC :-), and the video framebuffer, at least when the entire thing
fit into a single segment (as with video mode 0x13, 320x200 8bpp), was
directly accessible at memory address 0x000A0000 (segment 0xA000). In that
model, only 64 KB of the memory on the video card could be exposed at once;
which 64 KB was determined by the video card. Typically, it would provide an
interrupt call for changing which "bank" or "plane" of memory (depending on
the video mode) was visible. Note that the physical memory for that address
did exist, it was simply inaccessible as long as the video memory mapping
was in place. Everything from 640 KB up (which is where 0x000A0000 starts)
was called the "high memory area" and was mapped to various devices,
including the CMOS EEPROM memory. (Technically speaking, the video card got
128 KB of mapped space; monochrome text adapters put their text framebuffer
at 0x000B0000 and colour adapters put text information at 0x000B8000. I
honestly don't know why it wasn't possible, for cards that had 128 KB or
more of memory on them, to have the entire 128 KB range from 0x000A0000 to
0x000BFFFF mapped and usable, but that did not seem to be the case.)
Nowadays, a 64KB window would be pretty much useless, but I suspect the "AGP
window" in most BIOSes is a very similar concept -- a region in the memory
address space dozens (or hundreds?) of megabytes long that directly maps
across the AGP bus to the video card's RAM. I could be wrong, though, as I
haven't read up on it.
I remember discussions back in the day about using video memory to store
things. Remember, DOS was very constrained -- 16-bit real mode gave you
about 450 KB of memory to work with with the OS loaded. Typically, VRAM is
extremely fast for things running on the video card, but significantly
slower than system memory for regular usage because of having to cross over
a generally narrower and slower bus. Though it probably doesn't apply
nowadays, when I was playing with such things, the VRAM in question would be
used pretty much exclusively for the framebuffer, and would get locked
temporarily for each scan of the screen. Obviously the video card's DAC gets
top priority to the memory, so if you were using it for something else, your
code would often be made to wait until the video chip hit the end of the
current row being sent to the CRT. :-)
In any event, even though VRAM *is* mappable to memory address ranges, there
is no general framework within Windows for doing so that allows the memory
to be used in the same way as system memory. An application wanting to use
VRAM for additional storage would have to be specially written to support
it.
Jonathan Gilbert
