Hi all,
[about caching and framebuffers]
I'm not sure of the design specifics of the Control video, but most of the
Apple video designs I've seen put the high-bandwidth low-latency video ram
right on the main bus, so it's already half way to being a cache in and of
itself (I seem to recall apple's sound manager using vram for buffer
space), and would benefit very little from the CPU cache, except perhaps in
a multi-cpu machine to keep bus chatter down to a minimum, but the exact
tradeoffs of that would take a bit of consideration to quantify.
In the case of control, the VRAM seems to be the same basic type as main
RAM (i.e. 60/70ns DRAM), and it is conceptually behind a PCI bridge. So
by itself it is not faster than main RAM....
Besides that, unlike main ram, what has and hasn't been written back to the
framebuffer makes a big difference in what you see on screen. Caching would
probably make for some mighty weird flicker, jumpy or inconsistent video
playback, and all sorts of evil visual gremlins. You could always cache the
framebuffer as write-through, but then any value you might have got from
the caching goes right out the window, as framebuffer writes should
outnumber framebuffer reads by an order of magnitude.
The main reason for marking the VRAM cacheable (_how_ is a different story)
would be so that the CPU can burst to it; the net result being (as I have
understood it, but I may be wrong) that the CPU can fill the PCI bridge's
buffer with fast burst writes, and let the bridge take care of getting
the data to VRAM. According to Apple's doc on their PCI implementation,
all address space excpet main RAM is marked uncacheable by default, but
only cacheable space gets bursted to by the CPU.
So I guess the optimum would be to mark the VRAM cacheable, but in a way that
writes don't go into the cache. Would that be write-through?
Anyways, that's the long answer. The short answer is: no, you probably
don't want to cache the framebuffer.
Except for the above reasons ;-)
Cheers
Michel
-------------------------------------------------------
.sig enjoying a day off
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Mon, 5 Jun 2000, Michel Lanners wrote:
So I guess the optimum would be to mark the VRAM cacheable, but in a way that
writes don't go into the cache. Would that be write-through?
That's indeed write-through. Note that writes will still be cached in such a
way that a consecutive read from the same location will return the cached
value. But writes will immediately be sent to the host bridge.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
At 9:15 AM -0500 6/5/2000, Geert Uytterhoeven wrote:
On Mon, 5 Jun 2000, Michel Lanners wrote:
quoted
So I guess the optimum would be to mark the VRAM cacheable, but in a way
that
writes don't go into the cache. Would that be write-through?
That's indeed write-through. Note that writes will still be cached in such a
way that a consecutive read from the same location will return the cached
value. But writes will immediately be sent to the host bridge.
True enough. Is the vram genuinley behind the PCI bridge, or is it just
magically managed as a PCI resource from the main bus? If the reads and
writes don't really go through the bridge then, again, I don't see that
there would be much benefit in using a write-through cache, with perhaps
the exception of SMP.
It would atleast be worthwhile mapping it non-cached until the driver can
be proven 100% stable (well, 95% atleast) :), then turn caching back on
(write-through, of course) and see what breaks again, knowing this time
that it's definatley cache-related.
And I mean, if all else fails, stability should always prevail over speed,
right?... right?... *tumbleweed rolls by*
;)
Cheers - Tony :)
--
Tony Mantler Renaissance Nerd Extraordinaire nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada http://nicoya.feline.pp.se/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
At 4:15 PM +0200 6/5/00, Geert Uytterhoeven wrote:
On Mon, 5 Jun 2000, Michel Lanners wrote:
quoted
So I guess the optimum would be to mark the VRAM cacheable, but in
a way that
writes don't go into the cache. Would that be write-through?
That's indeed write-through. Note that writes will still be cached in such a
way that a consecutive read from the same location will return the cached
value. But writes will immediately be sent to the host bridge.
Unfortunately a side effect of write-through mode is that it prevents
burst writes. Memory must be cacheable in copy-back mode for
existing PowerPC CPUs to perform burst writes.
Many Intel CPUs implement write combining for precisely this region.
In a memory region marked as OK for write combining, the CPU is free
to wait and collect data from several writes to perform a burst write
rather than performing a write immediately.
Tim Seufert
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/