On Wed, Feb 13, 2019 at 12:05 PM Mario Kleiner <mario.kleiner.de@xxxxxxxxx> wrote: > > On Wed, Feb 13, 2019 at 10:56 AM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > > > Quoting Daniel Vetter (2019-02-13 09:50:55) > > > On Tue, Feb 12, 2019 at 10:32:31PM +0100, Mario Kleiner wrote: > > > > I think all kms drivers try to call drm_crtc_handle_vblank() at start > > > > of vblank to give Mesa the most time for frontbuffer rendering for > > > > classic X. But vblank events are also used for scheduling bufferswaps > > > > or other stuff for redirected windowed rendering, or via api's like > > > > OML_sync_controls glXWaitForMscOML, so there might be other things > > > > affected by a more delayed vblank handling. > > > > > > The frontbuffer rendering is very much X driver specific, and I think > > > -amdgpu/radeon is the only one that requires this. No i915 driver ever > > > used the vblank interrupt to schedule frontbuffer blits, we use some > > > CS-side stalls. > > > > Fwiw, the Present midlayer does use vblank scheduling for inplace copy > > updates. Not that I wish to encourage anyone to use frontbuffer > > rendering. > > -Chris > > Yes, that's what i meant. Under DRI2 at least AMD, Intel and nouveau > have throttling based on CS stalls to avoid tearing and do throttling. > DRI3/Present last time i checked just waited for a vblank event and > then triggered the blit - something that causes tearing even when > triggered at start of vblank. Hm, might be good to document all that stuff somewhere. But in the end I'd say the answer is "don't do frontbuffer rendering". I'm not sure we managed to document all the rules for existing vblank vs. flip interactions anywhere. At least I didn't find anything with a look at our docs. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
