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), 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? I'll poke around the page flipping & buffer swap code to see if I can make sense of it. Would be nice to have that feature available on 965, and preferably enable it by default if it works. > > > 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). > > My current thinking is that the only non-racy way to handle the "in > > vblank" case is to only use the frame counter to keep the vblank count > > accurate across interrupt disabled periods. While the interrupt is > > enabled, however, the driver should internally keep a counter going > > based on the vblank interrupt and use that to return a value to the > > core. > > > > If the radeon driver has to do something similar, we could probably > > just update the core drm_handle_vblank() function to use the atomic > > counter instead, which would save a bunch of duplicated driver code... > > Any thoughts there? > > I've been thinking about this as well, should be worth a try. > > Something else I think we need to do before merging vblank-rework into > the kernel is to keep the vblank interrupts enabled and use an atomic > counter until the 2D driver calls the modeset ioctl (or a kernel > modesetting driver does the corresponding thing to indicate it handles > this correctly). Yeah, that would be a good compatibility measure. I'll try adding that when I hack up what's described above. Thanks, Jesse ------------------------------------------------------------------------- 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
