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
