[Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver

Eric Anholt eric at anholt.net
Tue Mar 5 18:27:16 UTC 2019


Kristian Høgsberg <hoegsberg at gmail.com> writes:

> On Mon, Mar 4, 2019 at 6:29 PM Dave Airlie <airlied at gmail.com> wrote:
>>
>> On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg <hoegsberg at gmail.com> wrote:
>> >
>> > On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig <alyssa at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190305/8d76cc95/attachment.sig>


More information about the mesa-dev mailing list