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

Dave Airlie airlied at gmail.com
Tue Feb 26 23:04:08 UTC 2019


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

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.


More information about the dri-devel mailing list