Re: [Beignet] [PATCH] Utest: Porting to GCC6

On 2016.06.14 05:43:32 +0800, Xiuli Pan wrote: > From: Pan Xiuli > > Due to the change of GCC 6 headers: > https://gcc.gnu.org/gcc-6/porting_to.html > std::abs now need cmath header. > This patch fix some codes form OCL20 branch. > > Signed-off-by: Pan Xiuli

[Beignet] [PATCH] Flush kernel source dump stream

If kernel source dump is requested (OCL_OUTPUT_KERNEL_SOURCE), try to always flush output stream when dump to get full content under possible interrupt. Signed-off-by: Zhenyu Wang <zhen...@linux.intel.com> --- backend/src/backend/program.cpp | 2 +- 1 file changed, 1 insertion(+), 1 de

[Beignet] [PATCH] First reference beignet's CL header to build

header in build/install. Signed-off-by: Zhenyu Wang <zhen...@linux.intel.com> --- CMakeLists.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 3c6c373..147bb25 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -32,7

[Beignet] [PATCH 3/5] Add doc for CL Intel performance query extension

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com --- docs/performance_query | 95 ++ 1 file changed, 95 insertions(+) create mode 100644 docs/performance_query diff --git a/docs/performance_query b/docs/performance_query new file mode 100644

[Beignet] [PATCH 1/5] Ignore emacs backup file in .gitignore

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 90fd161..3f0cd6b 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ +*~ *.o CMakeCache.txt CMakeFiles/ -- 2.1.4

[Beignet] [PATCH 0/5][RFC] CL Intel performance query extension

This RFC series try to add new extension for CL Intel performance query. It's based on performance query extension definition for GL, so have similiar API definition. Currently this patch supports to get compute basic performance counters on HSW based on i915 PMU driver for perf support. To try

[Beignet] [PATCH 2/5] Add new CL_Intel_performance_query extension support

This adds new extension to get Intel hardware performance counter through i915 perf event interface. This extension is mostly based on GL_Intel_performance_query extension which is a generic method to access performance metrics on Intel GPU. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com

[Beignet] [PATCH 5/5] Add simple perf query example

This is based on a simple CL test program to be added with CL intel performance query extension support. To show how to get perf query/counter info and get performance data. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com --- CMakeLists.txt | 6 + examples/perf_query

Re: [Beignet] 9e8874c breaking (more) Haswell systems?

On 2015.04.18 22:16:07 +0100, Rebecca N. Palmer wrote: http://cgit.freedesktop.org/beignet/commit/?h=Release_v1.0id=9e8874c7a16b029d5b857a11ff9b23102752b4db was intended to catch the silently does nothing on large arrays bug, and does so (with the message drm_intel_gem_bo_context_exec() failed:

Re: [Beignet] [PATCH v3 1/2] Add example to show v4l2 buffer sharing with extension clGetMemObjectFdIntel.

On 2015.04.09 08:41:20 +, Weng, Chuanbo wrote: What about design for import buffer possibly from EGL/libva? [Chuanbo]For GL, there is already a Khronos official extension(cl_khr_gl_sharing) which support create cl memory object from gl bo. For libva, we have added extensions

Re: [Beignet] [PATCH v3 1/2] Add example to show v4l2 buffer sharing with extension clGetMemObjectFdIntel.

On 2015.04.08 14:50:47 +0800, Chuanbo Weng wrote: This example captures yuy2 frame directly to cl buffer object by the way of dma, processed by OpenCL kernel, then convert to nv12 format and shown by libva. One thing confusing here is that for current beignet's clGetMemObjectFdIntel(), you

Re: [Beignet] [PATCH] CL/Driver: enable atomics in L3 for HSW.

On 2014.12.31 10:02:30 +0800, Zhigang Gong wrote: This could get more than 10x boost for some atomic stress workloads. But this will be filtered by cmd parser. From kernel log, commit f3fc4884ebe6ae649d3723be14b219230d3b7fd2 Author: Francisco Jerez curroje...@riseup.net Date: Wed Oct 2

Re: [Beignet] [PATCH] Separate flush and invalidate in function intel_gpgpu_pipe_control.

On 2014.12.26 14:57:58 +0800, Yang Rong wrote: From: Luo Xionghu xionghu@intel.com HSW has a limitation when PIPECONTROL with RO Cache Invalidation: Prior to programming a PIPECONTROL command with any of the RO cache invalidation bit set, program a PIPECONTROL flush command with CS

Re: [Beignet] [PATCH] Remove obsolete MI_FLUSH

On 2014.12.29 09:43:45 +0800, Zhigang Gong wrote: If remove the MI_FLUSH, we need to add instruction cache invalidate flag to the corresponding pipe control command. Like flush, kernel will do invalidate for you with instruction cache invalidate bit set. I've done all utest with this patch

Re: [Beignet] [PATCH] Remove obsolete MI_FLUSH

On 2014.12.29 10:06:58 +0800, Zhigang Gong wrote: When does the kernel do instruction cache invalidate for us? Could you give a pointer to the related code. You may check i915_gem_execbuffer_move_to_gpu() function. I also tested it and found many utests failures. My kernel version is as

Re: [Beignet] [PATCH 2/2] Add aub dump support

On 2014.12.25 14:30:40 +0800, Zhigang Gong wrote: One normal case is that the application will enqueue many kernels one by one. Could you enhance this patch to output per kernel aub file, something like kernel_a.aub, kernel_b.aub, etc. I'm not quite understand what you mean, maybe you can

[Beignet] [PATCH] Use libdrm interface to get device id

device debugging with fulsim emulator by choosing any device you want and don't need hw metal at all. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com --- src/intel/intel_driver.c | 21 ++--- src/intel/intel_driver.h | 3 --- 2 files changed, 2 insertions(+), 22 deletions(-) diff

Re: [Beignet] [PATCH] runtime: fix bug in cl_enqueue_read_buffer.

yeah, also need for enqueue write for userptr buffer. On 2014.11.13 06:52:39 +, Guo, Yejun wrote: LGTM, thanks. -Original Message- From: Beignet [mailto:beignet-boun...@lists.freedesktop.org] On Behalf Of Zhigang Gong Sent: Thursday, November 13, 2014 1:43 PM To:

Re: [Beignet] [PATCH V2 1/3] support CL_MEM_USE_HOST_PTR with userptr for cl buffer

Overall looks fine to me except some indent issues and better keep with /* */ comment style in C files. On 2014.11.06 09:40:05 +0800, Guo Yejun wrote: + +#ifdef HAS_USERPTR +//currently only cl buf is supported, will add cl image support later +if ((flags CL_MEM_USE_HOST_PTR)

Re: [Beignet] beignet doesnt compile with LLVM 3.6

, suppose the LLVM 3.6 approach to stable now, I am working to support LLVM 3.6 now. Hope could finish it soon. One option is to explicitly say the llvm version that beignet does support and refuse to go on otherwise, like below one? From: Zhenyu Wang zhen...@linux.intel.com Date: Tue, 4 Nov 2014 15

Re: [Beignet] [PATCH 1/2] support CL_MEM_USE_HOST_PTR with userptr for cl buffer

On 2014.11.03 10:30:32 +0800, Guo Yejun wrote: @@ -260,7 +263,29 @@ cl_mem_allocate(enum cl_mem_type type, /* Allocate space in memory */ bufmgr = cl_context_get_bufmgr(ctx); assert(bufmgr); + +#ifdef HAS_USERPTR +//currently only cl buf is supported, will add cl image

Re: [Beignet] [PATCH 3/5] Remove intel_gpgpu_check_binded_buf_address()

On 2014.10.27 17:53:51 +0800, Zhenyu Wang wrote: On 2014.10.27 12:57:59 +0800, Zhenyu Wang wrote: On 2014.10.24 18:10:36 +0800, Zhigang Gong wrote: This assertion is just to make sure we will not get a NULL pointer for a normal buffer. The OpenCL spec doesn't give a very specific

[Beignet] [PATCH v2] Remove intel_gpgpu_check_binded_buf_address()

to be fixed otherwise. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com --- src/intel/intel_gpgpu.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/src/intel/intel_gpgpu.c b/src/intel/intel_gpgpu.c index d6ef3e9..724ce63 100644 --- a/src/intel

Re: [Beignet] [PATCH 3/5] Remove intel_gpgpu_check_binded_buf_address()

On 2014.10.27 12:57:59 +0800, Zhenyu Wang wrote: On 2014.10.24 18:10:36 +0800, Zhigang Gong wrote: This assertion is just to make sure we will not get a NULL pointer for a normal buffer. The OpenCL spec doesn't give a very specific statement about a NULL buffer object. But it does allow

Re: [Beignet] [PATCH 3/5] Remove intel_gpgpu_check_binded_buf_address()

On 2014.10.24 18:10:36 +0800, Zhigang Gong wrote: This assertion is just to make sure we will not get a NULL pointer for a normal buffer. The OpenCL spec doesn't give a very specific statement about a NULL buffer object. But it does allow to pass a NULL to a buffer object. Thus some one may

Re: [Beignet] [PATCH] Fix AUX buffer for really page aligned

On 2014.10.22 08:49:53 +, Guo, Yejun wrote: three comments in line, thanks. Thanks for review this. gpgpu-aux_offset.surface_heap_offset = size_aux; size_aux += sizeof(surface_heap_t); @@ -784,7 +782,10 @@ intel_gpgpu_state_init(intel_gpgpu_t *gpgpu,

[Beignet] [PATCH v2 5/5] Fix AUX buffer for page alignment

Apply ALIGN() for aux buffer size from beginning has no effect. Move to the end of all state offsets set for page alignment. v2: Update comments Signed-off-by: Zhenyu Wang zhen...@linux.intel.com --- src/intel/intel_gpgpu.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff

[Beignet] [PATCH 2/5] Clear batch buffer pointer after unmap

Fix libdrm warning about unmap the unmapped buffer, as when batch terminate we will try to do unmap again, but batch has already been unmapped. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com --- src/intel/intel_batchbuffer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [Beignet] [drm] stuck on render ring

On 2014.10.20 13:17:23 +0100, Ernst Lenzer wrote: I used that to solve this error: Assertion gpgpu-binded_buf[i]-offset != 0 At least with new enough drm-intel kernel with full PPGTT, this will surely be hit. And I don't know why we need that, do we have some limitation on some HW? I have a

[Beignet] [PATCH 3/4] Remove intel_gpgpu_check_binded_buf_address()

On recent kernel with full PPGTT support, we can possibly bind buffer offset with 0, but intel_gpgpu_check_binded_buf_address() always thinks it's invalid, which is not true. So simply remove the check. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com --- src/intel/intel_gpgpu.c | 9

[Beignet] [PATCH 1/4] Make use of write enable flag for mem bo map

. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com --- src/cl_api.c | 10 +- src/cl_command_queue.c | 2 +- src/cl_enqueue.c | 18 +- src/cl_enqueue.h | 1 + src/cl_mem.c | 18 +- src/cl_mem.h | 4 ++-- 6 files changed

[Beignet] [PATCH 2/4] Clear batch buffer pointer after unmap

Fix libdrm warning about unmap the unmapped buffer, as when batch terminate we will try to do unmap again, but batch has already been unmapped. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com --- src/intel/intel_batchbuffer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[Beignet] [PATCH] Make use of write enable flag for mem bo map

. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com --- src/cl_api.c | 10 +- src/cl_command_queue.c | 2 +- src/cl_enqueue.c | 18 +- src/cl_enqueue.h | 1 + src/cl_mem.c | 18 +- src/cl_mem.h | 4 ++-- 6 files changed

Re: [Beignet] [PATCH] Use pkg-config to check modules

On 2014.04.09 10:45:40 -0400, Daniel McLellan wrote: I cannot seem to build HEAD CMake Error at utests/CMakeLists.txt:204 (ADD_LIBRARY): Cannot find source file: generated/builtin_acos_float.cpp generated/builtin_acos_float2.cpp I didn't see this error, have you re-run cmake with

Re: [Beignet] [PATCH] Use pkg-config to check modules

On 2014.04.10 10:00:02 +0800, Zhenyu Wang wrote: On 2014.04.09 10:45:40 -0400, Daniel McLellan wrote: I cannot seem to build HEAD CMake Error at utests/CMakeLists.txt:204 (ADD_LIBRARY): Cannot find source file: generated/builtin_acos_float.cpp generated/builtin_acos_float2

Re: [Beignet] [PATCH] Use pkg-config to check modules

On 2014.04.10 11:02:18 +0800, Zhigang Gong wrote: You can try 92e6260.. ok. But I don't know why this is a mesa related problem? Sorry I didn't mention that it fails at src/intel/intel_dri_resource_sharing.c:42:27: fatal error: intel_context.h: No such file or directory #include