On Thu, Sep 05, 2019 at 10:19:40AM +0200, Thomas Zimmermann wrote: > Hi > > Am 05.09.19 um 09:56 schrieb Daniel Vetter: > > On Thu, Sep 5, 2019 at 9:01 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > >> > >> Hi, > >> > >>> - imo we should fix this by using the io_mapping stuff, that avoids > >>> the overhead of repeated pat checks for map/unmap. > >> > >> Another idea: IIRC ttm has a move_notify callback. So we could simply > >> keep mappings active even when the refcount goes down to zero. Then do > >> the actual unmap either in the move_notify or in the destroy callback. > > > > Yeah that should be a really clean solution, and only needs changes in > > the vram helpers. Which is nice, more common code! > > But the console's BO is special wrt to mapping. Putting special code for > console handling into vram helpers doesn't seem right. I have no special handling in mind. I think we can simply do that for all gem objects, no matter whenever they are created by fbcon or userspace (wayland/xorg/whatever). vmap will create a mapping (or increase the reference count). vunmap decreases the reference count, when it goes down to zero unpin it but keep the mapping. The actual unmap happens when ttm wants move the object from VRAM to SYSTEM due to VRAM being full. In case vram has room for all our objects we simply never unmap. hope this clarifies, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
