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