[PATCH 9/9] drm: move ttm_execbuf_util into vmwgfx

[Thomas Hellström (Intel)]

Hi,

On 3/9/23 06:14, Zack Rusin wrote:
> On Wed, 2023-03-08 at 10:10 +0100, Christian König wrote:
>> Am 08.03.23 um 06:14 schrieb Zack Rusin:
>>> On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
>>>> VMWGFX is the only remaining user of this and should probably moved over
>>>> to drm_exec when it starts using GEM as well.
>>> Is this because vmwgfx piggybacks buffer-id relocations on top of ttm
>>> validations or
>>> did you just find it too hard to port it over? I'd prefer to avoid ttm moves to
>>> vmwgfx and at least have a clear idea of what we need to do to port.
>> I've just found it to hard to port it over because vmwgfx does some
>> strange things with the validation code here.
>>
>> If you want we can take a deeper look at this together, but I need to
>> find some time.
>>
>> Alternatively just tell me how to do it and I will add that to the patch
>> set :)
> I don't want to hold up the set (it looks good btw), because I had to look at
> something else today and tomorrow.
>
> We overload the validation lists to do quite a bit more than just reservations
> though.
>
> There are, I think, four separate things that need to be refactored there
> (Christian, feel free to skip this section, this is mainly for VMware folks on the
> team):
> 1) Relocations - userspace uses the id's of the bo's in the command stream, but on
> the kernel side those id's are different (or in vmwgfx terminology gem id != mob
> id), so the buffer id's in the command stream need to be replaced,
> 2) Resource validation. vmwgfx splits the userspace objects into buffers and
> resources (shaders, surfaces, contexts). The resources are not buffers but are
> backed by them. A single buffer can back multiple different resources and sometimes
> the kernel has to actually allocate a buffer to back a resource and attach it to it
> (i.e. in common terminology buffer is the memory and resources are placed in it) .
> Now this shouldn't be in the kernel at all, the resources shouldn't have been kernel
> objects and instead we should have left them completely to userspace.

The reason behind this is partly historical, since initially the 
resources (IIRC surfaces and shaders at that time),
were per-device and not per context and not backed by buffer objects.

The main reason for not doing the transition to user-space for resources 
was the SVGA device "between-draw-call-validation". If you for example 
unbound a mob that was backing a resource that was bound to a context, 
you'd need to start a whole chain of resource invalidations to avoid the 
device complaining about invalid setups at awkward moments, for example 
when it felt like suspending.

Not sure whether that is gone now though, or whether there are better 
ways to handle that.

/Thomas


> 3) Coherency tracking. We use validation lists as a central place for tracking which
> bo's/resources are used in a command buffer and we use it to keep track of which
> buffers/resources will endup dirty to implement coherency.
> 4) Central place to allocate memory for relocation/validation nodes.
>
> Where we want to endup is with 2 completely gone from the kernel side and 1, 3 and 4
> refactored and cleaned up. I think there's at least 4 separate patches to this port,
> so it's not a trivial thing. We will take a look at this on Friday in more detail to
> see what we can do.
>
> z