Jerome Glisse wrote: > On Mon, 2009-08-31 at 10:40 +0200, Thomas Hellström wrote: > >> Jerome and other Radeon developers. >> >> You're probably aware of this, but I'd thought I'd mention it before the >> Radeon user-space interface is set in stone. >> >> There is a slight problem with the radeon bo wait idle ioctl if there >> are multiple threads or processes rendering to the same buffer without >> synchronization. >> The ioctl effectively guarantees that all graphics commands put in the >> pipeline before the ioctl was called are finished, but it can never >> guarantee that the buffer is idle on return. >> >> I'm not sure this is a problem in practice, though. >> >> /Thomas >> > > I think we all agreed at some point that synchronization on shared > buffer is userspace issue so it's up to sharing userspace process > to ensure that no one is doing stuff on their back on a shared buffer. > Right now i think the only sharing we have is btw GL process and > X server. I haven't looked at what happen in threaded or forked > application. > Yes, I don't think that's a problem with OpenGL at least since it requires the app to synchronize. Just wanted to make sure that you were aware of the limitations, (wait idle is really just a synchronization point).
/Thomas > That being said i don't think we should move out of testing for 2.6.32, > i really would like to merge read/write domain and i have an approach > which allow to keep same userspace while allowing new userspace > (like gallium) to use simpler approach. > > Jerome > > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
