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