| Message ID | 20190807133745.4110-1-lionel.g.landwerlin@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/syncobj: add syncobj sideband payload for threaded submission | expand |
Well first of all I strongly suggest to make the sideband information a separate IOCTL and not use the existing signal/query IOCTLs for it. Then as far as I see this basically sets a sequence number to use for binary semaphores, is that correct? If yes then that would be a rather elegant idea. Christian. Am 07.08.19 um 15:37 schrieb Lionel Landwerlin: > Hi, > > The goal of this feature is to solve an issue that was seen in our > testing. After discussing on [1] I thought we could solve this problem > with stalling the application thread after each vkQueueSubmit() call > where a binary semaphore is signaled but I don't think it's a good > option because of performance impacts on the application. > > Unfortunately there isn't a good way to reproduce this problem 100% > because it essentially exposes a race between the application thread > and the submission thread. > > I've uploaded tests in the Khronos repository to try to expose the > issue. > > Thanks, > > [1] : https://lists.freedesktop.org/archives/dri-devel/2019-August/229188.html > > Lionel Landwerlin (2): > drm/syncobj: add sideband payload > drm/syncobj: add submit point query capability > > drivers/gpu/drm/drm_syncobj.c | 132 ++++++++++++++++++++++------------ > include/drm/drm_syncobj.h | 9 +++ > include/uapi/drm/drm.h | 5 +- > 3 files changed, 100 insertions(+), 46 deletions(-) > > -- > 2.23.0.rc1
On 07/08/2019 16:49, Koenig, Christian wrote: > Well first of all I strongly suggest to make the sideband information a > separate IOCTL and not use the existing signal/query IOCTLs for it. It felt like at least the query ioctl was the right place to get the sideband value. I can change. > > Then as far as I see this basically sets a sequence number to use for > binary semaphores, is that correct? If yes then that would be a rather > elegant idea. Yeah that's pretty much it. From the vulkan API point view, this doesn't even need to be atomic, it just needs to happen within vkQueueSubmit(). Again to explain the issue, it's that syncobj is container and we might race picking up the fence from one thread while the submission thread updates the fence. Essentially reusing the fence chain mechanism solve the issue because we can wait on a particular replacement sequence number (matching a vkQueueSubmit() call). -Lionel > > Christian. > > Am 07.08.19 um 15:37 schrieb Lionel Landwerlin: >> Hi, >> >> The goal of this feature is to solve an issue that was seen in our >> testing. After discussing on [1] I thought we could solve this problem >> with stalling the application thread after each vkQueueSubmit() call >> where a binary semaphore is signaled but I don't think it's a good >> option because of performance impacts on the application. >> >> Unfortunately there isn't a good way to reproduce this problem 100% >> because it essentially exposes a race between the application thread >> and the submission thread. >> >> I've uploaded tests in the Khronos repository to try to expose the >> issue. >> >> Thanks, >> >> [1] : https://lists.freedesktop.org/archives/dri-devel/2019-August/229188.html >> >> Lionel Landwerlin (2): >> drm/syncobj: add sideband payload >> drm/syncobj: add submit point query capability >> >> drivers/gpu/drm/drm_syncobj.c | 132 ++++++++++++++++++++++------------ >> include/drm/drm_syncobj.h | 9 +++ >> include/uapi/drm/drm.h | 5 +- >> 3 files changed, 100 insertions(+), 46 deletions(-) >> >> -- >> 2.23.0.rc1