[Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)

[Christian König]

Am 27.02.19 um 00:04 schrieb Dave Airlie:
>>> At the end of the day, I don't really care that much.  I get it, we
>>> all have large projects with scarce resources.  I just think a few
>>> years down the road we'll all regret it as a community.
>> AMD and others have also spent years tuning TTM for both UMA and VRAM,
>> but especially VRAM.  It comes across a bit daft to complain about the
>> effort to move to TTM, but say nothing about the effort to tune GEM
>> for optimal VRAM performance.  Effort that has already been expended
>> that you could take advantage of.
> I'm with Alex here, the patches you have now are just the start, I
> realise you think they are all you'll need, but I expect once Chris
> gets going with real VRAM hardware he'll generate reams for stuff.
>
> People have been tuning and making TTM run on VRAM using GPUs for
> longer than you've been making VRAM using GPUs, there had better be
> good and well thought out reasons for avoiding using it, and so far
> you haven't made that argument to me all. In fact your scheduler
> arguments works against you. If we should have abstracted i915
> scheduler out and used it because it had more features and
> pre-existed, then i915 should be using TTM since it's already
> abstracted out and has more features.
>
> Like we've pulled other stuff out of TTM like reservation objects, I
> don't think i915 uses those yet either when it clearly could be. Maybe
> if we started by fixing that, moving to TTM would be less of a
> problem.

Just to make it extra clear: At least I absolutely won't mind if we 
decommission TTM further!

We have optimized TTM as much as we could without a fundamental design 
change, but essentially there are a couple of problem we can't fix 
without touching all drivers at once.

For example the layered design where TTM calls back into the driver to 
move stuff around or allocate something from a domain really needs to go 
away.

So my suggestion is that we filleting TTM into multiple independent 
components which a) can be used to implement the existing TTM interface 
and b) implement a clean and encapsulated functionality.

Those components can then be used by drivers independently of TTM to 
implement the necessary MM.

Regards,
Christian.

>
> Anyways, I expect moving to TTM is a big change for i915, and probably
> more than you are able to bite off at present, but I'm going to be
> watching closely what stuff you add on top of this sort of thing, and
> if it starts getting large and messier as you tune it, I'll have to
> start reconsidering how big a NO I have to use.
>
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel