On Tue, Sep 23, 2014 at 10:19:02AM +0100, Chris Wilson wrote: > On Tue, Sep 23, 2014 at 10:26:26AM +0200, Daniel Vetter wrote: > > On Fri, Sep 19, 2014 at 09:00:00PM +0100, Chris Wilson wrote: > > > On Fri, Sep 19, 2014 at 06:21:46PM +0000, Tian, Kevin wrote: > > > > > From: Chris Wilson > > > > > The implementation also looks backwards. To work correctly with the GTT > > > > > allocator, you need to preallocate the reserved space such that it can > > > > > only allocate from the allowed ranges. Similarly, it should evict any > > > > > conflicting nodes when deballooning. > > > > > > > > Could you elaborate a bit for above suggestion? > > > > > > My expectation was that the dev_priv->gtt.base.vm would contain exactly > > > two holes after setup (in the mappable and non-mappable range). To do > > > that you would explicitly reserve everything barred from this client > > > using a set of drm_mm_reserve_node() > > > > Essentially a reserve_node implements what you open-code with > > insert_node_range right now. > > Heh, there is a big difference. One inserts exactly where you ask and > fails if it conflicts, the other inserts where it feels like within that > range. Well if the the requested size matches the range exactly then it will be the same. Which iirc is what's going on here I think. > > One issue aside with both this and with the PDE reservations for gen7 is > > that there are now other thins in the ggtt drm_mm allocator than just gem > > objects. Which means our debugfs files are now less useful. > > > > It might be useful to augment that dumper with one that dumps everything. > > We could add a few bits of driver-private tags in drm_mm_node (there's > > space) to figure out what kind of object it is. Would be a great follow-up > > task. > > I think moving the other way and making them all objects so that we can > tie them into evection and the shrinker, use more interesting allocation > strategies, improve integration with debugging etc. Hm, not sure yet since it will be a lot of work at least. But I guess we could untangle the meaning of obj->pin a bit and add an unbind vfunc which adds some magic. But there's a lot of stuff attached to a gem bo that just doesn't make a lot of sense really, so maybe a better option would be to subclass a struct i915_ggtt_vma with special magic. Dunno really. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
