On Friday, September 28, 2007 12:51 pm Ian Romanick wrote:
> > No, I'm not sure what should happen in this case. Doing a vblank
> > sync'd buffer swap or vblank wait on an offscreen drawable doesn't
> > make much sense does it? In what cases might those calls occur?
>
> The spec doesn't say that an application can't call glXGetViewSyncSGI
> when a pbuffer is bound, so you can be sure that someone does.
Yeah, the question is: what should it do? With the posted code, I think
it'll get either the primary pipe's counter (if the drawable has never
been a window) or the last pipe it was associated with. That seems
sufficient...
> >> I was thinking of something like:
> >>
> >> if (pdraw == NULL) {
> >> return GLX_BAD_CONTEXT;
> >> }
> >>
> >> if (pdraw->getMSC != NULL) {
> >> ....
> >> } else if (psc->driScreen.getMSC != NULL) {
> >> ....
> >> }
> >>
> >> return (ret == 0) ? 0 : GLX_BAD_CONTEXT;
> >
> > Ok, that looks good. I'll fix it up.
>
> I take that back. I looked at the unpatched code (instead of just
> looking at the patch). The code already returns GLX_BAD_CONTEXT if
> the return from __glXGetCurrentContext is NULL. This means that
> pdraw *cannot* be NULL.
Yeah I looked again right after posting the last patch and the current
code seems ok. I'll remove the pdraw == NULL checks.
> > No, in that case the MSC will change and possibly decrease. But
> > drivers can handle that case by tracking which output a given
> > drawable is on (or mostly on), so that the drawable is sync'd to
> > the right value.
>
> That's bad. The MSC for a drawable should never decrease. I can
> easily envision cases where that would cause problems for apps.
>
> Drivers will have to make sure that getMSC returns values that only
> increase. We can easily do that by keeping two values in the
> drawable private. One value tracks a base MSC, and the second value
> tracks the initial MSC on the current pipe when the base MSC was set.
> The driver's getMSC would then return "base + (pipe_current_MSC -
> pipe_base_MSC)".
Wouldn't we want to increment the base value by the difference between
the last pipe value and the current one?
But yeah, handling a drawable that moves between outputs with different
vblank counters is a little tricky, I think we could handle making it
monotonic in driDrwableGetMSC32 by using per-drawable, per-pipe vblSeq
values as you suggest.
Jesse
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
