On 17/12/14 05:20, Mario Kleiner wrote: > On 12/17/2014 05:49 AM, Keith Packard wrote: >> Mario Kleiner <mario.kleiner...@gmail.com> writes: >> >>> It's just that i need access to both, the old behaviour i described, and >>> the new "drop frame" behaviour, and i need a way to select what i want >>> at runtime via api without the need for easily overwhelmed and confused >>> users to change config files or environment variables. I also always >>> need meaningful and trustworthy feedback, at least for page-flipped >>> presents, about what really happened for a presented frame - was it >>> flipped, copied, exchanged, skipped, or did some error happen? >> Present reports precisely what it did with each frame; flipped, copied, >> or skipped. >> >>> That's why i'd like to have an extension to INTEL_swap_events to also >>> report some new completion type "skipped" and "error" and that one patch >>> 5/5 of mine for mesa reviewed and included, to make sure the swap_events >>> don't fall apart so easily. >> You can use Present events on the target drawable; they're generated to >> whoever requests them, so you don't need to rely on the intel swap >> events alone. > > Never thought about that. Could you show me some short example snippet > of XLib/GLX code how i reliably detect at runtime if Present is present, > and then enable this? That would probably do for the moment and at the > same time solve the problem that i don't know how to reliably detect at > runtime if i'm on DRI2 or DRI3/Present. Making good use of this will > require separate code-path and a way to select the right one. > > It's still important to fix that wraparound handling bug from my patch > 5/5 for INTEL_swap_events. > >>> As some kind of stop gap measure one could also think about defining a >>> new vblank_mode to enable the new behaviour instead of the old one. >> I really don't have a good suggestion here, given that we have such a >> limited API available. >> > > I thought i just made a suggestion how we could wiggle through it within > existing api? > And we can define new one for future extensions? > Adding Mathias and Frank Binns to the Cc list.
So taking into account the discussion so far, including Mathias's input that the official nvidia driver does the same/similar form of cheating: - Should we revert on master until a decision(alternative solution) is available ? - Curious if we can have some form of consensus on what the next steps would be. Keith, Any plans on taking a look at patch 4/5 [1] and 5/5 [2] from rev 3 of the series ? The former is reviewed by Eric while the latter lacks any comments :'( Thanks Emil [1] http://lists.freedesktop.org/archives/mesa-dev/2014-December/072078.html [2] http://lists.freedesktop.org/archives/mesa-dev/2014-December/072079.html _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
