I now have the patched version installed on my laptop. I ran the 'sum'
program and it didn't work. I will include the output of the 'sum'
program below, but it is the same as in previous emails. One thing to
note about the 'sum' program is that it does ask for the user to input
which platform you're using (iow, 'Intel(R) HD Graphics IvyBridge M GT2').
I also tried the beignet 'utest' folder's 'utest_run' program. My
results were terrible. Only 25 out of 665 passed.
Finally I even tried my PyOpenCL program which failed as it has been
doing all along.
I think there is still a problem. I am willing to try most anything to
see if I can get this to work. My kernel is 3.16.1-301.fc21.x86_64. I
saw on the beignet web site that if you're using 4th generation intel
products that you'd need to install a special patch for your kernel. Do
I need to consider doing something like that? My processor is described
as 'Intel Core i5-3210M CPU' and the OS reports the GPU as 'Intel
Ivybridge Mobile'.
Below is some test program output:
$ ./cl-demo 1000 10
Choose platform:
[0] Intel
Enter choice: 0
Choose device:
[0] Intel(R) HD Graphics IvyBridge M GT2
Enter choice: 0
---------------------------------------------------------------------
NAME: Intel(R) HD Graphics IvyBridge M GT2
VENDOR: Intel
PROFILE: FULL_PROFILE
VERSION: OpenCL 1.2 beignet 0.9
EXTENSIONS: cl_khr_global_int32_base_atomics
cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics
cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_icd
DRIVER_VERSION: 0.9
Type: GPU
EXECUTION_CAPABILITIES: Kernel Native
GLOBAL_MEM_CACHE_TYPE: Read-Write (2)
CL_DEVICE_LOCAL_MEM_TYPE: Global (2)
SINGLE_FP_CONFIG: 0x6
QUEUE_PROPERTIES: 0x2
VENDOR_ID: 358
MAX_COMPUTE_UNITS: 16
MAX_WORK_ITEM_DIMENSIONS: 3
MAX_WORK_GROUP_SIZE: 1024
PREFERRED_VECTOR_WIDTH_CHAR: 8
PREFERRED_VECTOR_WIDTH_SHORT: 8
PREFERRED_VECTOR_WIDTH_INT: 4
PREFERRED_VECTOR_WIDTH_LONG: 2
PREFERRED_VECTOR_WIDTH_FLOAT: 4
PREFERRED_VECTOR_WIDTH_DOUBLE: 0
MAX_CLOCK_FREQUENCY: 1000
ADDRESS_BITS: 32
MAX_MEM_ALLOC_SIZE: 268435456
IMAGE_SUPPORT: 1
MAX_READ_IMAGE_ARGS: 128
MAX_WRITE_IMAGE_ARGS: 8
IMAGE2D_MAX_WIDTH: 8192
IMAGE2D_MAX_HEIGHT: 8192
IMAGE3D_MAX_WIDTH: 8192
IMAGE3D_MAX_HEIGHT: 8192
IMAGE3D_MAX_DEPTH: 2048
MAX_SAMPLERS: 16
MAX_PARAMETER_SIZE: 1024
MEM_BASE_ADDR_ALIGN: 1024
MIN_DATA_TYPE_ALIGN_SIZE: 128
GLOBAL_MEM_CACHELINE_SIZE: 128
GLOBAL_MEM_CACHE_SIZE: 8192
GLOBAL_MEM_SIZE: 1073741824
MAX_CONSTANT_BUFFER_SIZE: 524288
MAX_CONSTANT_ARGS: 8
LOCAL_MEM_SIZE: 65536
ERROR_CORRECTION_SUPPORT: 0
PROFILING_TIMER_RESOLUTION: 80
ENDIAN_LITTLE: 1
AVAILABLE: 1
COMPILER_AVAILABLE: 1
MAX_WORK_GROUP_SIZES: 1024 1024 1024
---------------------------------------------------------------------
*** Kernel compilation resulted in non-empty log message.
*** Set environment variable CL_HELPER_PRINT_COMPILER_OUTPUT=1 to see more.
*** NOTE: this may include compiler warnings and other important messages
*** about your code.
*** Set CL_HELPER_NO_COMPILER_OUTPUT_NAG=1 to disable this message.
0.000039 s
0.309593 GB/s
BAD 1!
Aborted (core dumped)
$ cd ~/workspace/beignet/build/utest
$ . setenv.sh
$ ./utest_run
...(lots of output here)...
summary:
----------
total: 665
run: 665
pass: 25
fail: 638
pass rate: 0.040601
$ ./arrays_opencl.py
('a', array([ 0.], dtype=float32))
('b', array([ 0.], dtype=float32))
('c', array([ 0.], dtype=float32))
1 0.063902
('a', array([ 0., 1.], dtype=float32))
('b', array([ 0., 1.], dtype=float32))
('c', array([ 0., 0.], dtype=float32))
2 0.005048
('a', array([ 0., 1., 2.], dtype=float32))
('b', array([ 0., 1., 2.], dtype=float32))
('c', array([ 0., 0., 0.], dtype=float32))
3 0.004393
On 08/31/2014 08:59 PM, Zhigang Gong wrote:
I double checked and there is not anything missed in the patch. The patch
is to fix a error related "undefined symbol xxx". It seems that you haven't
met such an error from the beginning. I just doubt whether the PyOpenCL was
really using beignet. My suggestion is to do something to check which
platform/device the PyOpenCL is really using.
You may also need to try to run the beignet's utest according to the README's
instruction and see whether it work well.
On Sat, Aug 30, 2014 at 01:13:30PM -0400, David Liebman wrote:
maybe there's a change that you made that somehow didn't show up in
the patch? An edited header file or another c file??? You obviously
have a working copy. Your output is right. (!!)
On 08/30/2014 10:25 AM, David Liebman wrote:
today I removed the beignet package from my system and downloaded
the beignet source from this location:
git://anongit.freedesktop.org/beignet
I applied the patch cleanly and built/installed the package.
Everything went well while building it. Unfortunately the PyOpenCL
program doesn't work any better with the patched version of
Beignet.
('a', array([ 0.], dtype=float32))
('b', array([ 0.], dtype=float32))
('c', array([ 0.], dtype=float32))
1 0.010353
('a', array([ 0., 1.], dtype=float32))
('b', array([ 0., 1.], dtype=float32))
('c', array([ 0., 0.], dtype=float32))
2 0.002883
('a', array([ 0., 1., 2.], dtype=float32))
('b', array([ 0., 1., 2.], dtype=float32))
('c', array([ 0., 0., 0.], dtype=float32))
3 0.002828
I'm still getting zeros for 'c'. I recompiled PyOpenCL and tried
again. No luck.
On 08/30/2014 09:17 AM, Zhigang Gong wrote:
This should be a generic requirement for some applications and I think
PyOpenCL should be supported by
beignet. This patch should be pushed into the upstream repo after got
reviewed. And if you can test it locally
and let us know whether it fix your issue. It will be helpful.
As to whether this could be merged into the fedora 21 release, I think
Igor may have official answer.
BTW, we are going to release a new fix version 0.9.3 in the coming
week after LLVM 3.5 released.
This patch should be included in 0.9.3.
Igor, is it possible to get the 0.9.3 into the Fedora 21 release?
Thanks,
Zhigang Gong
On Sat, Aug 30, 2014 at 8:46 PM, David Liebman
<[email protected]> wrote:
On 08/30/2014 04:47 AM, Zhigang Gong wrote:
Just got some time to try you example with PyOpenCL. And it seems that
PyOpenCL depends on
a function which we haven't implemented. After apply the following
patch, I can run your example
correctly. The output is as below:
gongzg@gongzg-MBA:~/Downloads$ python test.py
('a', array([ 0.], dtype=float32))
('b', array([ 0.], dtype=float32))
('c', array([ 0.], dtype=float32))
1 0.010514
('a', array([ 0., 1.], dtype=float32))
('b', array([ 0., 1.], dtype=float32))
('c', array([ 0., 2.], dtype=float32))
2 0.004235
('a', array([ 0., 1., 2.], dtype=float32))
('b', array([ 0., 1., 2.], dtype=float32))
('c', array([ 0., 2., 4.], dtype=float32))
3 0.004166
From 81c9e5cf70ec01197833f8722f6aa16632a5f1a4 Mon Sep 17
00:00:00 2001
From: Zhigang Gong <[email protected]>
Date: Sat, 30 Aug 2014 16:34:44 +0800
Subject: [PATCH] Runtime: Implement
clGetExtensionFunctionAddressForPlatform.
It seems that this function is required for PyOpenCL.
Signed-off-by: Zhigang Gong <[email protected]>
---
src/cl_api.c | 19 +++++++++++++++++--
src/cl_khr_icd.c | 2 +-
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/cl_api.c b/src/cl_api.c
index 177a7e8..b463128 100644
--- a/src/cl_api.c
+++ b/src/cl_api.c
@@ -3156,8 +3156,8 @@ error:
if (strcmp(#x, func_name) == 0) \
return (void *)x;
-void*
-clGetExtensionFunctionAddress(const char *func_name)
+static void*
+internal_clGetExtensionFunctionAddress(const char *func_name)
{
if (func_name == NULL)
return NULL;
@@ -3180,6 +3180,21 @@ clGetExtensionFunctionAddress(const char
*func_name)
return NULL;
}
+void*
+clGetExtensionFunctionAddress(const char *func_name)
+{
+ return internal_clGetExtensionFunctionAddress(func_name);
+}
+
+void*
+clGetExtensionFunctionAddressForPlatform(cl_platform_id platform,
+ const char *func_name)
+{
+ if (UNLIKELY(platform != NULL && platform != intel_platform))
+ return NULL;
+ return internal_clGetExtensionFunctionAddress(func_name);
+}
+
#undef EXTFUNC
cl_int
diff --git a/src/cl_khr_icd.c b/src/cl_khr_icd.c
index 6d49db0..50a0898 100644
--- a/src/cl_khr_icd.c
+++ b/src/cl_khr_icd.c
@@ -154,7 +154,7 @@ struct _cl_icd_dispatch const
cl_khr_icd_dispatch = {
clEnqueueMigrateMemObjects,
clEnqueueMarkerWithWaitList,
clEnqueueBarrierWithWaitList,
- CL_1_2_NOTYET(clGetExtensionFunctionAddressForPlatform),
+ clGetExtensionFunctionAddressForPlatform,
CL_GL_INTEROP(clCreateFromGLTexture),
(void *) NULL,
(void *) NULL,
This is great. Thank you greatly for the patch. Now, should I
be waiting for
a new beignet package from fedora, or should I 'roll my own' and start
compiling from source, adding the patch myself? I would love
this to make it
to the fedora 21 release, but I don't know what that would
take. What is
normal procedure? Is there a need for this method in the
general community,
or am I the only one who's interested in this feature?
-Dave L.
_______________________________________________
Beignet mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/beignet
_______________________________________________
Beignet mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/beignet
