I do wonder if we need the separate sem signal/wait interface, I think
we should just add
semaphore chunks to the CS interface.
Yeah, that's what I've said as well from the very first beginning.
Another question is if we should really create another implementation to
share semaphores between processes.
In other words putting the current fences inside the semaphore into a
sync_file with the signal_on_any bit set would have pretty much the same
effect, except that the resulting object then had the sync_file
semantics for adding new fences and can be used in the atomic IOCTLs as
well.
Regards,
Christian.
Am 09.03.2017 um 08:00 schrieb zhoucm1:
Hi Dave,
We have already completed implementation as the attached for both
kernel and libdrm. We discuss it on top of this.
Thanks,
David Zhou
On 2017年03月09日 12:24, Dave Airlie wrote:
I've attached two patches for RFC at the moment, I haven't finished
the userspace for these yet, but just wanted to get some
ideas/feedback.
Dave.
On 9 March 2017 at 13:52, Dave Airlie <airl...@gmail.com> wrote:
On 28 February 2017 at 11:46, zhoucm1 <david1.z...@amd.com> wrote:
Hi Dave,
The attached is our semaphore implementation, amdgpu_cs.c is drm
file, the
others are kernel file.
Any suggestion?
Thanks,
I've built a tree with all these in it, and started looking into the
interface.
I do wonder if we need the separate sem signal/wait interface, I think
we should just add
semaphore chunks to the CS interface.
I'm just playing around with this now.
Dave.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
