[Beignet] [hpc12/tools] build of 'sum' on 'Intel(R) HD Graphics IvyBridge M GT2' failed
Zhigang Gong
zhigang.gong at gmail.com
Mon Sep 1 07:58:47 PDT 2014
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 <david.c.liebman at gmail.com> 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
>>>>> <david.c.liebman at gmail.com> 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 at 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 <zhigang.gong at linux.intel.com>
>>>>>>> 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 <zhigang.gong at linux.intel.com>
>>>>>>> ---
>>>>>>> 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
>>> Beignet at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/beignet
>
>
More information about the Beignet
mailing list