On 22/07/16 10:52 PM, Carsten Haitzler (The Rasterman) wrote: > On Fri, 22 Jul 2016 12:34:59 -0700 Derek Foreman <der...@osg.samsung.com> > said: > > oh really. this sounds bizarre to just magically have 2 funcs that map either > cached or uncached with nothing in their names to tell you that... :(
Indeed! I think the gtt one is for mapping something specifically as a gpu source/target, but the mapping I changed is only using it as a target for software render. It's not the compositor side mapping. There are also ioctls for managing coherency manually that might improve performance even more (you can avoid the map/unmap entirely most of the time and just flush with an intel specific ioctl). I'll mess with that sometime after the release. But for now this seems to bring back all the lost performance from switching to dmabuf on software compositor, and should be a net win on hardware (though I've not measured it) because it saves a texture upload. >> derekf pushed a commit to branch master. >> >> http://git.enlightenment.org/core/efl.git/commit/?id=6108aa942cb933478fb1c72ab05d012fb9375276 >> >> commit 6108aa942cb933478fb1c72ab05d012fb9375276 >> Author: Derek Foreman <der...@osg.samsung.com> >> Date: Fri Jul 22 14:32:37 2016 -0500 >> >> wayland_shm: Speed up dmabuf on intel >> >> using map_bo/unmap_bo instead of gem_map_bo_gtt/gem_unmap_bo_gtt >> results in a cacheable mapping and a large performance boost. >> >> (dmabuf will still remain turned off by default for the release) >> --- >> src/modules/evas/engines/wayland_shm/evas_dmabuf.c | 12 ++++++------ >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/src/modules/evas/engines/wayland_shm/evas_dmabuf.c >> b/src/modules/evas/engines/wayland_shm/evas_dmabuf.c index 1f22626..ed8e1b1 >> 100644 >> --- a/src/modules/evas/engines/wayland_shm/evas_dmabuf.c >> +++ b/src/modules/evas/engines/wayland_shm/evas_dmabuf.c >> @@ -87,8 +87,8 @@ static Dmabuf_Buffer *_evas_dmabuf_buffer_init >> (Dmabuf_Surface *s, int w, int h); static void _evas_dmabuf_buffer_destroy >> (Dmabuf_Buffer *b); >> drm_intel_bufmgr *(*sym_drm_intel_bufmgr_gem_init)(int fd, int batch_size) = >> NULL; -int (*sym_drm_intel_gem_bo_unmap_gtt)(drm_intel_bo *bo) = NULL; >> -int (*sym_drm_intel_gem_bo_map_gtt)(drm_intel_bo *bo) = NULL; >> +int (*sym_drm_intel_bo_unmap)(drm_intel_bo *bo) = NULL; >> +int (*sym_drm_intel_bo_map)(drm_intel_bo *bo) = NULL; >> drm_intel_bo *(*sym_drm_intel_bo_alloc_tiled)(drm_intel_bufmgr *mgr, const >> char *name, int x, int y, int cpp, uint32_t *tile, unsigned long *pitch, >> unsigned long flags) = NULL; void (*sym_drm_intel_bo_unreference) >> (drm_intel_bo *bo) = NULL; int (*sym_drmPrimeHandleToFD)(int fd, uint32_t >> handle, uint32_t flags, int *prime_fd) = NULL; @@ -136,7 +136,7 @@ _intel_map >> (Dmabuf_Buffer *buf) drm_intel_bo *bo; >> bo = (drm_intel_bo *)buf->bh; >> - if (sym_drm_intel_gem_bo_map_gtt(bo) != 0) return NULL; >> + if (sym_drm_intel_bo_map(bo) != 0) return NULL; >> return bo->virtual; >> } >> >> @@ -146,7 +146,7 @@ _intel_unmap(Dmabuf_Buffer *buf) >> drm_intel_bo *bo; >> >> bo = (drm_intel_bo *)buf->bh; >> - sym_drm_intel_gem_bo_unmap_gtt(bo); >> + sym_drm_intel_bo_unmap(bo); >> } >> >> static void >> @@ -174,8 +174,8 @@ _intel_buffer_manager_setup(int fd) >> if (!drm_intel_lib) return EINA_FALSE; >> >> SYM(drm_intel_lib, drm_intel_bufmgr_gem_init); >> - SYM(drm_intel_lib, drm_intel_gem_bo_unmap_gtt); >> - SYM(drm_intel_lib, drm_intel_gem_bo_map_gtt); >> + SYM(drm_intel_lib, drm_intel_bo_unmap); >> + SYM(drm_intel_lib, drm_intel_bo_map); >> SYM(drm_intel_lib, drm_intel_bo_alloc_tiled); >> SYM(drm_intel_lib, drm_intel_bo_unreference); >> SYM(drm_intel_lib, drm_intel_bufmgr_destroy); >> >> -- >> >> > > ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
