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)
