On Mon, 2008-06-23 at 11:02 -0700, Jesse Barnes wrote: > On Monday, June 23, 2008 12:51 am Michel Dänzer wrote: > > On Fri, 2008-06-20 at 14:27 -0700, Jesse Barnes wrote: > > > On Friday, June 20, 2008 2:09 pm Jesse Barnes wrote: > > > > Michel, can you take a look at this? vblank wait is working really > > > > well for me with the latest bits, but I found what I think is a page > > > > flip related bug on 965. > > > > No this isn't correct, it also needs to wait for scheduled non-flip > > buffer swaps. > > > > Isn't this just a workaround for the lack of the 2D driver patch and not > > necessary with it? > > I'm not sure what 2D patch you mean (page flipping for 965 I suppose),
No, the modeset ioctl call patch. I thought the vbl_waited/pending fields were getting initialized and the only problem was the lack of that. > but clearly there's something wrong here since w/o this patch we end up doing > an > absolute wait on a 0 vblank count. :) Maybe I need to initialize the > vbl_pending/vbl_waited values somewhere else instead? Either that, or just disable this code in LOCK_HARDWARE() for the i965 driver I suppose, if it doesn't support scheduled buffer swaps. Note that I'm not sure about the status of intel page flipping and scheduled swaps on the current master/gem branches, it may be better to hold off on adding those features until things have settled down there. > > > > I've been testing with the attached pre- & post-modeset ioctl patch to > > > > the 2D driver. > > > > That one looks good; if anything, maybe slightly too careful about > > omitting redundant ioctl calls, but better safe than sorry I guess. :) > > > > > Oops, I've also been testing with this. > > > > Yeah, that driver workaround should definitely no longer be necessary. > > Ok, thanks for checking. Though in looking at the pre- & post-modeset code > again, I'm not sure what we have is optimal. The main reason for it is to > prevent the user visible vblank count from going backwards, so it seems like > we could just add the pre-modeset value to the post-modeset value and be done > with it, rather than treating mode set like a wraparound (which will cause > our counter to wraparound much more quickly). It isn't always treated as a workaround. Only if the driver counter has moved backwards does it compensate for the resulting spurious wraparound in drm_update_vblank_count(). -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
