On Fri, Sep 06, 2019 at 02:20:52PM +0200, Thomas Zimmermann wrote: > Generic fbdev emulation maps and unmaps the console BO for updating it's > content from the shadow buffer. If this involves an actual mapping > operation (instead of reusing an existing mapping), lots of debug messages > may be printed, such as > > x86/PAT: Overlap at 0xd0000000-0xd1000000 > x86/PAT: reserve_memtype added [mem 0xd0000000-0xd02fffff], track write-combining, req write-combining, ret write-combining > x86/PAT: free_memtype request [mem 0xd0000000-0xd02fffff] > > as reported at [1]. Drivers using VRAM helpers may also see reduced > performance as the mapping operations can create overhead. > > In v3 and later of the patch set, this problem is being solved by lazily > unmapping the buffer as suggested by Gerd. Unmapping with drm_gem_vram_kunmap() > only changes a reference counter. VRAM helpers later perform the unmapping > operation when TTM evicts the buffer object from its current location. If > the buffer is never evicted, the existing mapping is reused by later calls > to drm_gem_vram_kmap(). > > v4: > * lock kmap with ttm_bo_reserve() > * acquire lock only once for vmap() > * warn about stale mappings during buffer cleanup > v3: > * implement lazy unmapping > v2: > * fixed comment typos > > [1] https://lists.freedesktop.org/archives/dri-devel/2019-September/234308.html > > Thomas Zimmermann (4): > drm/vram: Add kmap ref-counting to GEM VRAM objects > drm/vram: Acquire lock only once per call to vmap()/vunmap() > drm/vram: Add infrastructure for move_notify() > drm/vram: Implement lazy unmapping for GEM VRAM buffers Reviewed-by: Gerd Hoffmann <kraxel@xxxxxxxxxx> cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
