On Wed, 2009-12-16 at 12:11 +0100, Thomas Hellstrom wrote: > Jerome Glisse wrote: > > On Wed, 2009-12-16 at 11:56 +0100, Thomas Hellstrom wrote: > > > >> Hi guys, > >> > >> There is another TTM race bug that I'm going to fix but which doesn't > >> yet affect any upstream code AFAICT. > >> > >> The effect is that it may cause a deadlock in extremely rare cases if > >> there are two processes validating at the same time, and one process > >> needs to evict a buffer on which ttm_bo_block_reservation has been called. > >> > >> I'll fix that up before we upstream any driver that allows simultaneous > >> validation. AFAIK only openchrome and old Poulsbo did that. vmwgfx > >> probably will at some point. > >> > >> /Thomas > >> > >> > > > > GL app likely endup doing concurrent validation with the ddx on radeon. > > > > Jerome > > > > > I thought you had a command submission mutex that blocked this possibility? > > If not, you'll need the execbuf utilities to avoid deadlocks resulting > from multiple threads trying to reserve the same buffers but in reverse > order. Nouveau actually has an implementation of what ttm_eu did (we used it before the initial patch to the kernel which didn't include it) in the driver.
Now that ttm_eu exists again I should look at moving back to it. We also have a mutex blocking submission by multiple clients currently, I can't recall why I added it right now, but it's on my TODO list to remove at some point. Ben. > > /Thomas > > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
