[EGIT] [core/efl] master 01/01: wayland_shm: Speed up dmabuf on intel

2016-07-22 Thread Derek Foreman
derekf pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=6108aa942cb933478fb1c72ab05d012fb9375276

commit 6108aa942cb933478fb1c72ab05d012fb9375276
Author: Derek Foreman 
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);

-- 




Re: [E-devel] [EGIT] [core/efl] master 01/01: wayland_shm: Speed up dmabuf on intel

2016-07-22 Thread The Rasterman
On Fri, 22 Jul 2016 12:34:59 -0700 Derek Foreman  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... :(

> derekf pushed a commit to branch master.
> 
> http://git.enlightenment.org/core/efl.git/commit/?id=6108aa942cb933478fb1c72ab05d012fb9375276
> 
> commit 6108aa942cb933478fb1c72ab05d012fb9375276
> Author: Derek Foreman 
> 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


Re: [E-devel] [EGIT] [core/efl] master 01/01: wayland_shm: Speed up dmabuf on intel

2016-07-23 Thread Derek Foreman
On 22/07/16 10:52 PM, Carsten Haitzler (The Rasterman) wrote:
> On Fri, 22 Jul 2016 12:34:59 -0700 Derek Foreman  
> 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 
>> 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


Re: [E-devel] [EGIT] [core/efl] master 01/01: wayland_shm: Speed up dmabuf on intel

2016-07-23 Thread The Rasterman
On Sat, 23 Jul 2016 08:36:29 -0500 Derek Foreman  said:

> On 22/07/16 10:52 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Fri, 22 Jul 2016 12:34:59 -0700 Derek Foreman 
> > 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 
> >> 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 proto