Am 15.06.2017 um 05:59 schrieb Dave Airlie:
On 1 June 2017 at 11:06, Dave Airlie <airlied@xxxxxxxxx> wrote:
From: Dave Airlie <airlied@xxxxxxxxxx>
This creates a new command submission chunk for amdgpu
to add in and out sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new
chunks, one for syncobj pre submission dependencies,
and one for post submission sync obj signalling,
and just takes a list of handles for each.
This is based on work originally done by David Zhou at AMD,
with input from Christian Konig on what things should look like.
In theory VkFences could be backed with sync objects and
just get passed into the cs as syncobj handles as well.
NOTE: this interface addition needs a version bump to expose
it to userspace.
TODO: update to dep_sync when rebasing onto amdgpu master.
(with this - r-b from Christian)
Hey Christian,
did you have a chance to re-review this, I think this
has the last changes you asked for done properly.
Sorry for the delay, holidays and dentist visits seem to eat up all my
time at the moment.
Patches #1-#3 in this series are Acked-by: Christian König
<christian.koenig@xxxxxxx>.
Patch #4 already has my rb.
Patch #5 in this Series is Reviewed-by: Christian König
<christian.koenig@xxxxxxx>.
If so I'd like to get Alex to get drm-next + pull these in on top at some
point, or if I already have the dep_sync changes in my tree I can just
fix it up and apply them there.
Any approach works for me as long as Alex is fine with it.
Additional to your set I synced up two more ideas with out internal
Vulkan team which seem to make a lot of sense to upstream as well:
1. An IOCTL to reset a sync object to it's initial state. E.g. reset the
fence the sync objects wraps back to NULL.
2. The ability to merge multiple sync objects into one. Essentially the
same thing we have for the sync file, but handle based instead of fd.
I'm going to work on that in the next week or so. Shouldn't be to much
of a problem to come up with some sane code, but probably finding use
cases for this in the open source userspace might be challenging.
Regards,
Christian.
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
