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. I've been testing with the attached pre- & > post-modeset ioctl patch to the 2D driver. Changing modes, adding & > removing outputs and moving a window waiting on vblank events all seem > solid & tear free on my 965 (though on 915 we may still have some tearing > due to the way interrupts work on that chip, still have to test & fix if > necessary). > > What do you think?
Oops, I've also been testing with this. And looking again at c7ee6cc269c26d8e7ed98a16a272eca63daab201 (the "in vblank" handling). I think my 965 test machine is fast enough that I haven't seen much tearing on it yet, but I think for slower machines we'll definitely need a real fix. 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? 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
