Index: [thread] [date] [subject] [author]
  From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Sat, 15 May 1999 01:02:07 +0200

Re: GGi frame buffer and video memory question

> hardware: vid card ->Mill II 8 meg (4 visible, 4 upgrade).
> 		   display ->	20.1 NEC AMLCD
> images: 1280X1024 8bit

> My problem is that I need to display these images to a accuracy of approx.
> 5ms for a simulation, 

Hmm - that's very hard. Hmm - AMLCD - does that mean, it's an LCD screen ?

Oh - even if it is, the millenium still won't be faster ...

Say you can achive a hsync of 100Hz then you'd be limited to 10ms.

What you'd need would be 200Hz, but that would mean about 250kHz hsync and 
380MHz pixclock.
AFAIK the best Matrox cards out there today feature 275MHz DACs. Given your
size constraints, that would mean 180kHz Hsync (hope the monitor likes that) 
and 145Hz Vsync, resulting in around 7ms per frame

> I am using usleep() before flushing to achieve this.
> I can display 3 images correctly but for > 3 it appears that the framebuffer
> pointer is not starting in the right place. (image starts approx. 1/4 way
> into the screen and loops back around). I think that this is doing this
> because of the visible memory is only 4megs?

Very probably. You would need 5MB of visible memory to get all four pictures
in.

> 1. Is there any way to point the frame buffer pointer in the correct place?

I think not. This is a hardware limitation.

> 2. I am assuming that the program is using the non visible memory to store
> the images on as well as the visible (program loads all the images then
> pages between them). My understanding of the layout of this card is that it
> can only display from the visible portion of the video memory (could be
> wrong). Does this cause any significant delays when displaying the images to
> the screen?

I assume you use ggiSetDisplayFrame to toggle between images - right ?
(From the description of the problem you have I am pretty sure you do.)

Then the switch is always instantaneous as it is done in hardware.

The card stores all four "frames" consecutively in memory and just
changes the address at which it starts to display a new frame.

As the card does not have enough visible memory, you have some options to
correct that behaviour.

1. Turn down resolution a bit. Depends on your application if this is
feasible. If you come down below 1MB per picture it will work.

2. Blit from main memory. This is slow, but as you can double-buffer,
and it is only one MB, it shouldn't be too bad.
The idea is to paint each frame, ggiGetBox it, and then do something
like 

ggiSetDisplayframe(curframe);
curframe++;if (curframe>maxframes) curframe=0;
ggiSetWriteFrame(curframe);
ggiPutBox(...);


in a loop. If your pictures contain large borders or otherwise "same" areas,
one can eventually gain some additional speed by only PutBox()ing the
relevant portion.

Maxframes would be 3 for your above case, which gives triple-buffering,
which is preferred over double-buffering, as you are much less likely to
draw on the still visible "old" frame, if the card does not switch it's
addresses in the middle of a frame.

3. Try to blit from card memory. That should be faster and is done in quite
the same way, except that you use CopyBox. This may or may not work
depending on whether the extra memory above 4MB is accessible for the
blitting operation (it might be textures only or such).
However as you will need 5MB of card memory for the 4 pictures, that leaves
you only with 3MB for the actual display, forcing you to use doublebuffering
only. However as in-card blits are usually very fast you might even be able
to go without doublebuffering and just blitting to a single buffer
without getting nasty aritifacts.

> 3. Because the images are not being displayed 100% correct for >3
> framebuffers does this cause any timing delays?

No. It's just displayed wrong. The fb driver _thinks_ it has 8M, while 
it can actually only use 4M. That causes it to allow a 4-frame mode, 
which actually is more a 3-frame mode with a wraparound after 3.25 
images.

What you see when selecting image 4 is its first part (what fits between
the end of the third image and the 4MB boundary), plus the first
picture again, when the memory pointer wraps 4MB->0.

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =

Index: [thread] [date] [subject] [author]