Re: [Dri-devel] vertical blank woes

[Michel <mi...@da...>]

On Mit, 2003-04-09 at 20:51, Ian Romanick wrote:
> Michel Dänzer wrote:
> > I discovered a problem with LIBGL_THROTTLE_REFRESH: it always starts
> > with 0 for vbl_seq, so if there have been more than 2^23 vertical blanks
> > since the IRQ was installed (takes less than 39 hours at 60 Hz),
> > DRM(vblank_wait) times out, and the Mesa driver aborts.
> > 
> > As the texmem to trunk merge is imminent, I'm working on the texmem code
> > to address this. How about this patch? It determines the current
> > sequence number and only actually waits when necessary.
> > 
> > As for the DRM side, I guess it doesn't make sense for DRM(vblank_wait)
> > to allow waiting for longer than the timeout? :) Or is there a
> > legitimate use for waiting for more than 3 seconds using vertical
> > blanks?

No opinion on this BTW?


> We can't squish VBLANK_FLAG_INTERVAL and VBLANK_FLAG_THROTTLE together. 
>   If the GLX API version is less than 20030317, then 
> gc->driContext.swap_interval (accessed on line 250 of your patched 
> version) does not exist.  Try using that client-side driver with a 
> libGL.so from the trunk.  :)

I did, and while it didn't work as expected, it didn't crash and burn
either, but I understand now that was just luck. :)

> By potentially eliminating the do_wait call any time curr_MSC > 
> target_MSC, we also lose synchronization and can cause tearing.  

There's no difference. In the cases where this code doesn't wait,
do_wait would return immediately in the old code.

> Perhaps the test should be 'if (original_seq != 0)'.  Then we can only 
> have a tear once every 2^32 frames.

That was my first idea as well, but why resort to a hack when we can
have a clean solution.


> I have another question for you.  Is there any way that the driver can 
> get a signal from the DRM when the target MSC has occured?  

Yes, at least on Linux - I think it's not implemented on BSD yet, so
there'd have to be a code path for sleeping as well.

> It *sucks* to have to sleep to wait to swap buffers.  There's quite a 
> bit of rendering that could be queued in parallel with the wait.

How would you queue it though? You can't do it on the hardware, can you?
Or maybe you can have the hardware wait for something that can be
triggered on the swap?

> The other option is to change the way the swap ioctls work.  Have the 
> ioctls internally queue the swap.  Then the client-side driver would 
> have to poll the kernel to make sure the swap is done.

Maybe we could even add a flag to the vertical blank ioctl? Then you
could have it swap buffers and then send you a signal on vertical blank.
:) The question is whether the swap can be done from the interrupt
handler. I guess at least writing the frame age would have to be moved
to the bottom half.


-- 
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \     http://svcs.affero.net/rm.php?r=daenzer