On Sat, 23 Jul 2016 08:36:29 -0500 Derek Foreman <der...@osg.samsung.com> said:
> 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. it will be a win. i remember an argument with a certain gpu vendor about hmmm 5 years ago asking to get zero copy gl texture access so we can just map, write and unmap. they jumped up and down telling us how it'd be slower etc. etc. etc. - i went "ummm no."... so with persistence such an extension was implemented and guess what? like a 60% speedup for the test cases where we cpu-side modified a texture every frame. :) if done right such things are a win. they can be bigger wins indeed with special flush ioctl's to avoid the map/unmap and even being able to flush ONLY the memory modified etc. :) > >> 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); > >> > >> -- > >> > >> > > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
