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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux