More on Longhorn graphics architecture

[Diego Calleja]

El Tue, 3 May 2005 18:09:41 -0400,
Jon Smirl <jonsmirl at gmail.com> escribió:

> "What does this actually mean? 3D surfaces can be paged out to virtual
> memory as needed. This is critical in the Longhorn user interface,
> where every window will be a 3D surface. Applications can now be
> bigger than graphics card memory currently allows. Of course, this

There is a great review of mac os x 10.4 in arstechnica (which I assume everybody
here has probably read already, but...) which talks about something similar:

http://arstechnica.com/reviews/os/macosx-10.4.ars/14

"As it turns out, VRAM has been "virtualized" by Mac OS X since Quartz Extreme
debuted in Jaguar. Although the Jaguar Quartz diagram shows the backing store in
RAM, the Quartz Compositor is smart enough to cache those backing stores in VRAM
as well. The biggest limitation of Jaguar's Quartz implementation is that the actual
drawing is still done into the backing store in RAM, so the diagram accurately reflects
the sequence of events during an actual drawing operation. But as long as a window's
contents don't change, the Quartz Compositor can continue to use its VRAM cache of
the backing store instead of reading it from RAM every single time.

Implementing even this limited form of VRAM caching required facing up to the reality
that VRAM won't always be able to hold cached copies of all of the backing stores.
Worse, the amount of VRAM varies depending on the video card being used. To
simplify the Quartz implementation, Jaguar needed some way to make VRAM look
"limitless" even though it clearly isn't.

This problem has been solved before. The virtual memory system in a modern
OS makes RAM look "limitless." Well, okay, it makes it appears as if it is 2^32 or 2^64
bits long, for 32-bit and 64-bit CPUs, respectively. But that's almost certainly larger
than the amount of physical RAM installed (particularly in the 64-bit case).

Although the details are different, this is essentially what Jaguar did with VRAM.
To the operating system, VRAM looks a lot larger than it actually is. Quartz handles the
details of swapping data in and out of VRAM as needed, using a replacement algorithm
tuned to keep the most frequently used pieces of data in VRAM as much as possible.

In Jaguar's Quartz implementation, any backing stores cached in VRAM are simply
redundant copies of the backing stores in RAM. All backing stores must exist in RAM
in Jaguar because that's where drawing actually takes place. Quartz drawing
commands cause the backing stores in RAM to be modified. The completed backing
store is then (DMA) transferred to the video card where the Quartz Compositor blends
it into the scene and (perhaps) caches it in VRAM, just in case it needs to be used
again at some point before it's modified (in RAM, remember) by the application and
needs to be re-imported into VRAM.

In Tiger with Quartz 2D Extreme, Quartz 2D drawing commands now modify the
backing store in VRAM. The Quartz Compositor, also running on the video card, reads
from the very same backing store in VRAM. The backing store in RAM is no longer
needed at all.

Well, theoretically, anyway. Again remember that VRAM is finite. What doesn't fit in
VRAM has to be stored in RAM instead. Once VRAM is full, there is a constant dance
of data moving between RAM and VRAM as needed to (ideally) keep the most
frequently used data in VRAM. There's also another important reason a backing
store might be in RAM instead of VRAM."

[...]