Michel Dänzer skrev: > On Thu, 2009-08-27 at 17:33 -0400, Kristian Høgsberg wrote: > >> 2009/8/27 Thomas Hellström <tho...@shipmail.org>: >> >>> b) It requires the master to act as a scheduler, and circumvents the DRM >>> command submission mechanism through the delayed unpin callback. If this >>> is to workaround any inability of GEM to serve a command submission >>> while a previous command submission is blocked in the kernel, then IMHO >>> that should be fixed and not worked around. >>> >> It's not about workarounds. Your suggestion *blocks the hw* while >> waiting for vsync. My patch doesn't do that, it lets other clients >> submit rendering to pixmap or backbuffer BOs that aren't involved in >> the pending page flip. If you're willing to block the command stream, >> GEM can keep the buffer pinned for you until the swap happens just >> fine. Just like it does for any other command - it's not about that. >> In fact, I think using the scheduler to keep buffers pinned for >> scanout is conflating things. The scheduler pulls buffers in and out >> of the aperture so that they are there for the GPU when it needs to >> access them. Pinning and unpinning buffers for scanout is a different >> matter. >> > > How is scanout not GPU access? :) I'd look at it the other way around: > pinning a scanout buffer is a workaround which is only needed while > there are no outstanding fences on it. > > Hmm, I missed this part. Yeah using the scheduler synchronization to protect buffers which have pending commands on them in the fifo is quite natural and also falls out quite neatly as detailed before. The workaround needed for page-flipping is that the buffers need to be pinned / unpinned just after validation.
/Thomas ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
