On Don, 2003-04-10 at 00:12, Ian Romanick wrote:
> Michel Dänzer wrote:
> > 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
> > No opinion on this BTW?
> Sorry. I forgot to reply to that in the first message. It seems
> reasonable to limit the amount of time it can block.
> >>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.
> Okay. The present solution seems reasonable, then.
I've been thinking a bit more about the very first swap though: right
now, it will basically occur immediately, unless it's attempted before
the very first vertical blank after the IRQ is enabled, which is very
unlikely. :) Would it be better to wait for a vertical blank instead?
> >>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.
> I know that the DRM can generate the signal, but how do we make sure
> it's handled by the client-side driver and not by the application?
The driver can choose whichever signal it wants, and if I'm not
mistaken, it can check for an existing signal handler, replace it with
its own and restore it afterwards.
> >>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 driver would just do everything that it could until it had to write
> something (new state, rendering commands, etc.) to the hardware. At
> that point it would have to block until the swap happened. If we had
> triple buffering, it wouldn't be as much of a problem. :) In that case
> the driver would only have to wait if there was still 2 swaps pending.
> A lot of apps do "simulation," then rendering. By having glXSwapBuffers
> return immediatly, those apps could do their simulation while the
> rendering / swapping was finishing up. That could be a big win for
> vsycn frame rates.
Ah yes, that makes sense.
> >>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.
> To get the right synchronization writing to the ring, we'd have to do
> all of it in the BH, wouldn't we? It could get tricky.
Right, I was only thinking of the page flipping case, which might be
doable without the ring. Without page flipping, I wonder if using the
ring from the bottom half would be any win at all over letting the
client handle it?
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer