On Fri, Oct 25, 2002 at 10:34:35AM -0700, Ian Romanick wrote:
> Time step 1:
> - Buffer 0 is being displayed (front buffer / display buffer).
> - Buffer 1 is the render buffer (back buffer).
> ...
> Time step 3:
> - Finish rendering to buffer 2,  and queue it to be displayed on the next
>   frame (front buffer).
> - Buffer 0 is still being displayed.  Vertical beam is, say, 2/3rd of the
>   way down the screen now (display buffer).
> - Buffer 0 becomes the render buffer (back buffer).
> 
> Time step 4:
> - Hey!  What happened to the bottom of my display?!?
> ...
>  The sollution was to use a vblank interrupt to (basically)
> fence the buffers, though I didn't know the term 'fence' at the time.  You
> still /might/ have to wait, but only if you have a very high frame rate.
> That's why I only saw the problem after increasing my CPU speed by a factor
> of 10. :)

whats wrong with simply changing the way you do next-frame queueing, and
make it most-recent, instead of always progressing?

eg: at step 3, 
  - finish rendering to buffer 2
  - mark buffer2 as next to be displayed
  - if buffer 0 still being displayed,  start rendering to buffer 1
  [-] else 0 must be free, start rendering to buffer 1

?

Is the problem that the prior commands are already "in the queue"?

If you are queuing up 3d commands way ahead of the video card draw speed,
then maybe the trick would be to make sure that queue buffers were no more
than [X rendertime] long.

ideally, so that you would have the case where there would be multiple
dmabuffers, looking like:

dmabuf1 [ draw draw draw ]
dmabuf2 [ draw showbuffer1 ]
dmabuf3 [ draw draw draw ]
dmabuf4 [ (being filled) ]

So if the videocard is still working on buf1, then buf2 is not "active"(?)
so you might be able to yank it, remove the showbuffer1 command,
then put showbuffer2 in the dmabuf4 queue, and THEN start rending to
buffer 1 again.

if videocard has reached buf2, then you just wait for a few cycles, since
you now shouldnt have long to wait.

related to that - if you are tripple-buffering, maybe mandate that
the [showbufferX] should always be in a dmabuffer BY ITSELF.
So it is "easy" (?) to yank it if required.



-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to