Kristian Høgsberg <hoegsb...@gmail.com> writes: > On Mon, Mar 4, 2019 at 6:29 PM Dave Airlie <airl...@gmail.com> wrote: >> >> On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg <hoegsb...@gmail.com> wrote: >> > >> > On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig <aly...@rosenzweig.io> >> > wrote: >> > > >> > > > Why aren't we using regular dma-buf fences here? The submit ioctl >> > > > should be able to take a number of in fences to wait on and return an >> > > > out fence if requested. >> > > >> > > Ah-ha, that sounds like the "proper" approach for mainline. Much of this >> > > was (incorrectly) inherited from the Arm driver. Thank you for the >> > > pointer. >> > >> > I'm not sure - I mean, the submit should take in/out fences, but the >> > atom mechanism here sounds more like it's for declaring the >> > dependencies between multiple batches in a renderpass/frame to allow >> > the kernel to shcedule them? The sync fd may be a little to heavy >> > handed for that, and if you want to express that kind of dependency to >> > allow the kernel to reschedule, maybe we need both? >> >> You should more likely be using syncobjects, not fences. >> >> You can convert syncobjs to fences, but fences consume an fd which you >> only really want if inter-device. > > Fence fd's are also required for passing through protocol for explicit > synchronization.
Yeah, but you can get a syncobj from a sync_file fence fd and export a syncobj's fence to a sync_file. I've been doing that successfully in v3d and vc4 for our dependencies in the driver so you don't need multiple fence types as input/output from the submit ioctl.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
