Add a way for userspace to specify the sequence number fence used to track completion of the submit. As the seqno fence is simply an incrementing counter which is local to the submitqueue, it is easy for userspace to know the next value. This is useful for native userspace drivers in a vm guest, as the guest to host roundtrip can have high latency. Assigning the fence seqno in the guest userspace allows the guest to continue without waiting for response from the host.
Showing the changes to include/uapi (1 of 3 files). Show all
Unified · Split
| @@ -232,6 +232,7 @@ struct drm_msm_gem_submit_bo { · 231 unmodified lines | ||
| 232 | 232 | #define MSM_SUBMIT_SUDO 0x10000000 /* run submitted cmds from RB */ |
| 233 | 233 | #define MSM_SUBMIT_SYNCOBJ_IN 0x08000000 /* enable input syncobj */ |
| 234 | 234 | #define MSM_SUBMIT_SYNCOBJ_OUT 0x04000000 /* enable output syncobj */ |
| 235 | +#define MSM_SUBMIT_FENCE_SN_IN 0x02000000 /* userspace passes in seqno fence */ | |
| 235 | 236 | #define MSM_SUBMIT_FLAGS ( \ |
| 236 | 237 | MSM_SUBMIT_NO_IMPLICIT | \ |
| 237 | 238 | MSM_SUBMIT_FENCE_FD_IN | \ |
| @@ -239,6 +240,7 @@ struct drm_msm_gem_submit_bo { · 1 unmodified line | ||
| 239 | 240 | MSM_SUBMIT_SUDO | \ |
| 240 | 241 | MSM_SUBMIT_SYNCOBJ_IN | \ |
| 241 | 242 | MSM_SUBMIT_SYNCOBJ_OUT | \ |
| 243 | + MSM_SUBMIT_FENCE_SN_IN | \ | |
| 242 | 244 | 0) |
| 243 | 245 | |
| 244 | 246 | #define MSM_SUBMIT_SYNCOBJ_RESET 0x00000001 /* Reset syncobj after wait. */ |
| @@ -258,7 +260,7 @@ struct drm_msm_gem_submit_syncobj { · 13 unmodified lines | ||
| 258 | 260 | */ |
| 259 | 261 | struct drm_msm_gem_submit { |
| 260 | 262 | __u32 flags; /* MSM_PIPE_x | MSM_SUBMIT_x */ |
| 261 | − __u32 fence; /* out */ | |
| 263 | + __u32 fence; /* out (or in with MSM_SUBMIT_FENCE_SN_IN flag) */ | |
| 262 | 264 | __u32 nr_bos; /* in, number of submit_bo's */ |
| 263 | 265 | __u32 nr_cmds; /* in, number of submit_cmd's */ |
| 264 | 266 | __u64 bos; /* in, ptr to array of submit_bo's */ |