From: Thomas H. <th...@sh...> - 2009-08-31 08:40:50
|
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 |
From: Jerome G. <gl...@fr...> - 2009-08-31 17:14:53
|
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. 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 |
From: Thomas H. <th...@sh...> - 2009-08-31 19:10:04
|
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 > > |