Re: [PATCH 1/3] drm/v3d: Associate BOs with every job that accesses them

[Emma Anholt <anholt@igalia.com>]

On 2026-06-13 16:22, Maíra Canal wrote:
> Hi Emma,
> 
> On 12/06/26 14:44, Emma Anholt wrote:
>> On 2026-06-10 23:17, Iago Toral wrote:
>>> Hi Maíra,
>>>
>>> I have a couple of thoughts here:
>>>
>>> 1. The original code seems to very specifica about targeting this only
>>> for the last job, which makes it look like a very intentional decision,
>>> so I wonder if there is something we are missing here. I am adding Emma
>>> to the CC in case she has any thoughts about it.
>>>
>>> 2. I am not aware of any issues despite not having implicit sync for
>>> all the jobs in the chanin. Like you mention, this is because user-
>>> space is already trying to handle job depedencies, so I wonder if we
>>> should instead work on the opposite direction and try to drop implicit
>>> sync in the kernel entirely. Would that make sense? What are other
>>> drivers doing in this regard?
>> 
>> Yeah, you should be working toward dropping implicit sync entirely.
>> tu's VM_BIND is really nice and where you want to be eventually, but
>> even if not, then you at least want something like
>> MSM_SUBMIT_NO_IMPLICIT.
>> 
> 
> I believe the main issue we would have to implement something like
> VM_BIND is the fact that V3D only has one global page table (that we
> could switch on runtime, but it would come with the cost that all the HW
> queues would only be able to operate on BOs from one client).
> 
> NO_IMPLICIT would be a more reasonable option.

I had forgotten how bad v3d's mmu is, with the contiguous mem
requirement.  I don't think VM_BIND is going to be reasonable -- we
can't guarantee new page tables for other clients, so switching isn't
reasonable.

HW queues only being able to operate on BOs the client has imported is
the right behavior, though!  It's not a requirement from DRM, but it's a
very strong expectation from the software using it.  V3D should really
be using the GMP to mask the clients from each other.
> 
>> I probably just didn't think about this implicit sync case in the
>> initial implementation, because a bin job dependency on results from
>> another context is just not a thing that's going to happen in practice.
>> The implicit sync was mostly about render targets / texturing to be
>> ordered correctly with X11, and about lifetime management of the BO
>> (which only needed the last use).
>> 
> 
> But does it make sense to attach the implicit dependencies to the
> CACHE_CLEAN job (last job) and not to the RENDER job or the CSD job?
> 

You need to make sure that the BO list also gets added to at least the
first job (assuming they're in a dependency chain), because it should
correctly wait to implicit sync against queued writes to those BOs from
other clients.  And, if you ever do shrinker, then each job would need
to know its BOs.