Re: [RFC PATCH 00/42] Introduce memory region concept (including device local memory)

[Joonas Lahtinen <joonas.lahtinen@linux.intel.com>]

Quoting Christian König (2019-02-27 04:17:01)
> 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.

This is exactly what I was hoping we could do, too. So I'm glad to hear
this suggestion. 

Incrementally extracting and sharing the components would lead to less
disruptions than halting the progress while doing a major rewrite of
the driver.

As I mentioned in IRC, one good step for both the scheduler and memory
management would be to actually map out the feature sets. It is clear
that we have confusion about what the feature set of the respective
components are (at least I do seem to have about TTM / DRM scheduler).

Then when we understand what it is that we actually have, it should be
easier to start discussing which are the components that could be reused.

I think one good way to take on this would be to look into sharing as
much of the test assets as possible. We have plenty of testcases
excercising the low-on-memory conditions and scheduling corner cases
that we've had to tackle. And I'm sure there are tests for the above
mentioned TTM VRAM tuning, too.

I'll look into and discuss the reservation objects Dave mentioned, and
I'm happy to hear about other suggestions.

I'd also like to hear comments about the buddy allocator suggestion. It
should help in enabling >4K page support for pretty much any driver.

Regards, Joonas

> 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@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx