Re: [patch] VRAM detection in controlfb

On Sun, Jun 04, 2000 at 10:08:39AM -0500, Tony Mantler wrote:

dcbi = data cache block invalidate. If you do this on a dirty cache block,
data will be lost.

dcbf = data cache block flush. If you do this on a block that isn't in a
coherent state, data will be lost.

If you have a block that's both dirty and incoherent... well, don't do that. :)

Ew.  I wonder if that's our problem...

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On   4 Jun, this message from Daniel Jacobowitz echoed through cyberspace:

On Sun, Jun 04, 2000 at 10:08:39AM -0500, Tony Mantler wrote:

quoted

dcbi = data cache block invalidate. If you do this on a dirty cache block,
data will be lost.

dcbf = data cache block flush. If you do this on a block that isn't in a
coherent state, data will be lost.

If you have a block that's both dirty and incoherent... well, don't do that. :)

Ew.  I wonder if that's our problem...

Would make sense, and I thought so too.... dcbi is wrong in any case for
us, since we did modify that block. However, I wonder whether caching is
on at all for the framebuffer adresses? (And if so, is that a good idea?
Do we want to trash the cache with a xsetroot?)

Anyway, a quick test showed no changes in the detection with dcbf
instead of dcbi. I'll have to test more thoroughly, but only after I get
Xpmac to run again...

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

At 12:48 AM -0500 6/5/2000, Michel Lanners wrote:

On   4 Jun, this message from Daniel Jacobowitz echoed through cyberspace:

quoted

On Sun, Jun 04, 2000 at 10:08:39AM -0500, Tony Mantler wrote:

[...]

quoted

quoted

If you have a block that's both dirty and incoherent... well, don't do
that. :)

Ew.  I wonder if that's our problem...

Would make sense, and I thought so too.... dcbi is wrong in any case for
us, since we did modify that block. However, I wonder whether caching is
on at all for the framebuffer adresses? (And if so, is that a good idea?
Do we want to trash the cache with a xsetroot?)

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.

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.

Anyways, that's the long answer. The short answer is: no, you probably
don't want to cache the framebuffer.


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/

Anyways, that's the long answer. The short answer is: no, you probably
don't want to cache the framebuffer.

Thanks for the long answer, and all those nasty gremlins have actually
been observed long time ago when people started to play with the
framebuffer drivers. At least on m68k, the framebuffer address space was
set non-cacheable right from the start (in head.S). I would hope that
somehow translated to PPC as well :-)

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Hi all,

On   6 Jun, this message from Michael Schmitz echoed through cyberspace:

quoted

Anyways, that's the long answer. The short answer is: no, you probably
don't want to cache the framebuffer.

Thanks for the long answer, and all those nasty gremlins have actually
been observed long time ago when people started to play with the
framebuffer drivers. At least on m68k, the framebuffer address space was
set non-cacheable right from the start (in head.S). I would hope that
somehow translated to PPC as well :-)

That's what fbmem.c does in its default mmap(). However, at least for
control (and maybe other comparable video implementations as well), you
get much better performance on scroll and other fb-to-fb copy
operations, without visible inconvenients, when the framebuffer is set
to write-through caching.

For fun, I tried write-back caching as well. Makes for some really nice
visual effects when your killed netscape starts to fade away as the
cache gets slowly flushed ;-))) And it doesn't even get you any speed
improvement...

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Tue, 6 Jun 2000, Michel Lanners wrote:

On   6 Jun, this message from Michael Schmitz echoed through cyberspace:

quoted

quoted

Anyways, that's the long answer. The short answer is: no, you probably
don't want to cache the framebuffer.

Thanks for the long answer, and all those nasty gremlins have actually
been observed long time ago when people started to play with the
framebuffer drivers. At least on m68k, the framebuffer address space was
set non-cacheable right from the start (in head.S). I would hope that
somehow translated to PPC as well :-)

That's what fbmem.c does in its default mmap(). However, at least for
control (and maybe other comparable video implementations as well), you
get much better performance on scroll and other fb-to-fb copy
operations, without visible inconvenients, when the framebuffer is set
to write-through caching.

| $ grep ioremap drivers/video/amifb.c
| 	videomemory = (u_long)ioremap_writethrough(videomemory_phys, videomemorysize);

It does mean that if the accel engine draws something, and the CPU wants to
chnge that, that there may be a cache incoherency. For amifb that doesn't
matter since it's unaccelerated.

Summarized: use write-through cachine for unaccelerated hardware, no caching
for accelerated hardware.

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/