On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
On Tue, Nov 08, 2016 at 10:35:08AM +0000, Chris Wilson wrote:That's not a trivial task to work out which of the fence contexts within
On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:My thoughts are that in atomic_check drivers just fill in the fence from
From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx>Explicit fencing is not a superset of the implicit fences. The driver
Hi,
This is yet another version of the DRM fences patches. Please refer
to the cover letter[1] in a previous version to check for more details.
may be using implicit fences (on a reservation object) to serialise
asynchronous operations wrt to each other (such as dispatching threads
to flush cpu caches to memory, manipulating page tables and the like
before the flip). Since the user doesn't know about these operations,
they are not included in the explicit fence they provide, at which point
we can't trust their fence to the exclusion of the implicit fences...
the reservation_object (i.e. the uapi implicit fencing part). If there's
any additional work that's queued up in ->prepare_fb then I guess the
driver needs to track that internally, but _only_ for kernel-internally
queued work.
the reservation object are required and which are to be replaced by the
explicit fence, esp. when you have to consider external fences.
The reason for that is that with explicit fencing we want to allowI'm just suggesting the danger of that when userspace doesn't know
userspace to overwrite any existing implicit fences that might hang
around.
everything and the current interfaces do not allow for userspace to know,
we only tell userspace about its own action (more or less).
-Chris