It may be another kernel driver issue. CC to Rong, could you help to check whether this is a kernel related issue. The kernel version is 3.16.1-301.fc21.x86_64.
Thanks, Zhigang Gong. On Mon, Sep 1, 2014 at 8:59 PM, David Liebman <[email protected]> wrote: > 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
