Re: [RFC][PATCH 00/13] drm: Introduce GEM-UMA memory management

[Thomas Zimmermann <tzimmermann@suse.de>]

Hi

Am 10.12.25 um 10:21 schrieb Boris Brezillon:
[...]
> n that, I agree.
>
>> Also what stops you from fixing any of this in the context of gem-uma?
> That's exactly what I want to do, except that, rather than fixing it,
> I'd like to get it right from the start and progressively move existing
> GPU/accel drivers using gem-shmem to gem-uma. If you blindly move every
> GPU/accel drivers currently using gem-shmem to gem-uma (which is just a
> rebranded gem-shmem), you're just moving the problem, you're not
> solving it. And all of a sudden, gem-uma, which I wanted to be this

Just to be clear, I'm trying to get the simple drivers out of the way 
first. Nothing more. Solving problems with the UMA drivers is out of 
question wrt this series.

> clean slate with well defined rules, on top of which we can more
> easily add building blocks for advanced stuff (reclaim, sparse
> allocation, ...), is back to this far west.

I've done something similar with GEM VRAM helpers a few years back. We 
had drivers running TTM on cinsiderably simple hardware. They all went 
to VRAM helpers at some point Still that took quite some time. With UMA 
the problem seems more complex and the drivers are moving targets. I 
feel like this will take years until you see the fruits of that work. 
All while you have to maintain GEM's UMA and SHMEM code at the same time.

>
>> It should even be easier, as you won't have to keep my use cases in mind.
> I might be wrong, but KMS use cases are probably not the problematic
> ones.
>
>> In parallel, gem-shmem could go in its own direction.
> My understanding is that you're primarily targeting KMS drivers, so why
> don't you fork gem-shem with something called gem-shmem-for-kms (or
> gem-shmem-dumb) that does just enough for you, and nothing more?
>
> I'm saying that with a bit of sarcasm, and I certainly get how painful
> it is to go and patch all KMS drivers to rename things. But if you think
> about it for a second, it's just as painful (if not more) to fork
> gem-uma in all users that might get in the way of a cleaner
> abstraction. Not only that, but all of a sudden, you need a lot more
> synchronization to get that approved, and until that happens, you're
> blocked on the real stuff: designing something that's sounds for
> more complex use cases GPU/accel drivers care about.

There's nothing sarcastic about that. Forking from GEM SHMEM in the 
'opposite direction' would be the other alternative. I can try to 
provide something like GEM sysmem helpers with a simplified 
implementation of GEM shmem that provides what the simple drivers need.

Best regards
Thomas

>
>> I'd like to do
>> some changes and simplifications there, which conflict with where
>> gem-uma will be heading.
> Just to be clear, I'm not going to block this if that's the direction
> people want to take, but I wanted to point out that making it easier for
> you might mean making others' life harder. When I initially proposed to
> fork gem-shmem it was not with the goal of pulling all current
> GPU/accel users in directly, but rather design something that provides
> the same set of features (with the ability to add more), with better
> defined rules, so we don't end up in the same situation. What you're
> doing here is the opposite: gem-uma becomes the gem-shmem's
> forget-about box, and as a result, it becomes someone else's problem.
>
> Regards,
>
> Boris

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)