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

Re: What about LibGGI 2.0 Beta 2?

becka@rz.uni-duesseldorf.de wrote:

>
> > > 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
>
> BTW: You assume split read/write pages here, or am I missing something ?
>
> Other than that, we need some kind of "sprite/bob" library anyway, so we can
> take care for it there. It's not a "basic-functionality" thing anyway.

As I dont know what you mean by split read/write I try to describe the problem more in
detail.

DRAM is divided into pages. When reading from dram two addresses is used first you
send RAS that opens a page then CAS that adresses bits in that page. If you next
access is to the same page you only have to send CAS saving some cycles. The
variations on this theme is endless but it al end in that it is much faster to read
from the same dram page than a new one. So this page thing has nothing to do with what
the CPU is calling pages.

A 640*480 screen with 16 bit (2 byte) will hit a new DRAM page every 3.2 line (4096
bytes page size on my cards DRAM)this is nothing we can do anything about but the
virtual screen that we now uses to hold al our 16*16 pixel tiles also has the same
width as the real screen and that makes the data spread on 5 different pages in dram
for al tiles. A continous layout would fit 8 tiles on the same drampage. This is
something a sprite library would not solve unless we have an line->rec bitlblit. My
card has what sound to me a very hi penelty 7 to 1 for this kind of accress and the
minimum slowdown is 5,5% I dont have al data so I can't say what it really is but its
more than that number for sure.