Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

2016ë 03ì 29ì 22:23ì Rob Clark ì(ê) ì ê:
> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae <inki.dae@xxxxxxxxxxx> wrote:
>>
>> In addition, I wonder how explicit and implicit fences could coexist together.
>> Rob said,
>> "Implicit sync ofc remains the default, but userspace could opt-in to explicit sync instead"
>>
>> This would mean that if we use explicit sync for user-space then it coexists with implicit sync. However, these two sync fences can't see same DMA buffer because explicit fence has a different file object from implicit one.
>> So in this case, I think explicit fence would need to be hung up on the reservation object of dmabuf object somehow. Otherwise, although they coexist together, are these fences - explicit and implicit - used for differenct purpose separately?
>>
> 
> I'm not entirely sure about coexistance at the same time.  It ofc
> shouldn't be a problem for one kernel to support both kinds of
> userspace (pure explicit and pure implicit).  And how this would work
> on kms atomic ioctl (compositor/consumer) side seems clear enough..
> ie. some sort of flag, which if set user provides an explicit fence
> fd, and if not set we fall back to current behaviour (ie. get fences
> from resv object).

With this patch series, users can register explicit fence(s) to atomic kms(consumer side) through kms property interface for the explicit sync.

However, now several DRM drivers(also consumer) already have beeen using implicit fence. So while GPU(producer side) is accessing DMA buffer after registering its explicit fence to atomic kms, and if atomic commit is requested by user-space, then atomic helper framework will try to synchronize with the producer - waiting for the signal of GPU side(producer), and device specific page flip function will also try to do same thing.

As of now, it seems that this wouldn't be optional but mandatory if explicit fence support is added to the atomic helper framework. This would definitely be duplication and it seems not clear enough even if one of them is just skipped in runtime.

> 
> On the gpu/producer side, I think what makes sense is to both attach
> the fence to the resv objects and (optionally, specified by an submit
> ioctl flag) return a fence fd.  The other option is to add a new ioctl
> to convert an internal per-ring fence/seqno (that is already returned
> by submit ioctl) to a fence fd.. but I think that would end up with
> duplicate 'struct fence' objects on the kernel side (not sure if that

I think the problem is not that kernel just keeps duplicate fence objects separately but is that these fences can be performed separately for same purpose.

> would cause issues somehow), and might be unneeded since with
> EGL_ANDROID_native_fence_sync since we should know before glFlush() is
> called whether we want an fd or not.  But main thing I'm pondering

So I think this is not user-space issue. All users don't have to know whether DMA drivers support implicit fence or not so as soon as user uses explicit fence, the duplication would happen.

There may be something I missed so your comment would be helpful in understanding it.


Thanks,
Inki Dae

> here is how to sanely support the old way of userspace gl driver
> internal synchronization with new userspace on old kernel, but also
> conditionally support EGL_ANDROID_native_fence_sync if you have a new
> enough kernel.
> 
> BR,
> -R
> 
>