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. 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
