From: Kenneth Johansson <ken@canit.se>
  To  : andreas.beck@ggi-project.org
  Date: Sun, 14 Feb 1999 03:21:54 +0100

Re: What about LibGGI 2.0 Beta 2?

becka@rz.uni-duesseldorf.de wrote:

> Hi !
>
> > Two things I have thought about is refreshrate controll
>
> This is IMO not a LibGGI issue. If at all, one could put it the "misc"
> extension. It is more of a KGI issue and a question of monitor
> configuration. I'd rather let the _user_ explicitly reconfigure that
> (using a script for convenience, if he wants) for an app that benefits from
> it, as I'd be _VERY_ annoyed, if each and every app would use another mode
> (one at 60Hz, one at 70, one at 72, ...) and I'd constantly have to adjust
> my monitor settings.
>
>

hey! as long as its possible to detect what is going on I'am happy. 2D games that
scrolls works best when they update in sync with refreshrate.


> > Second to make a square blitt of offscreen memory you have to use a
> > virtual screen and blit from that.
>
> Just a second: Please define "offscreen". Are you talking about video-RAM
> or system RAM ?
>

Video mem.


>
> > This can be very bad as it is very
> > possible that every new src data line now happens to be in a different
> > dram page.
>
> If you are talking about vidmem, there is another more important issue:
> Can we use the accelerator ?
>

You mean the accelerator is locked at the same layout for the data for both src
and dest data. hmm I have not tried but reading the mach64 spec it looks like it
have a full description for both src and dest independently so is should work.
ET6000 also have independent src/dest offset values(the address to add when going
from one line to another) as they call it.

>
> Almost any card has a "CopyBox" like function, that can be used to blit
> around areas.
> Only few cards have some kind of linear->rectangle blit.
>

Are you shure? even my old amiga had this.

>
> Thus it is often faster to do it with a rectangular organization of the
> blit source, as we can then use the accelerator.
>

Well if you are right about this it is. But my card have 1 cycle access for the
same page and 7 for a new one. Page=512(64bit word) hmm maybe I jumped the gun on
this one. With this numbers the overhead is not that great.but then again a game
with 3-4 layers working with 16*16 bit blocks could be hurt by this but probably
not to much.

Bestcase senario from an overhead point of view: The accelerator is braindead it
has to access memory for every pixel(probably not true).

16*16 = 256 accesses. 640*480 16 bit display with virtual screen same width gives
5 page faults on every block total of 286 cycles. Thats 11% slowdown for read.
5.5% for whole operation. Reality is probably worse as the bus often is 128

>
> > This makes the blitt slow. Src data should be continous in
> > memory. That is a src block should not have any stride value on the data.
> > Can this be done now?
>
> If you are talking about system RAM, this is how Get/PutBox work now.
>
>

What about AGP ?? Now the graphics card can access system memory or??  I'am not
shure how AGP card handle system memory. Is it like onboard memory? can the card
use accelerated function on system memory ?