[Beignet] [hpc12/tools] build of 'sum' on 'Intel(R) HD Graphics IvyBridge M GT2' failed
David Liebman
david.c.liebman at gmail.com
Tue Sep 2 05:33:59 PDT 2014
Yang Rong, all,
This fixed the problem. The 'sum' test works, the PyOpenCL program
works, and the 'utest_run' program works. I am not going to include
output from these programs. Thanks everyone for their time. As far as
I'm concerned, it's fixed.
-David Liebman
On 09/01/2014 10:39 PM, Yang, Rong R wrote:
> Hi, David
>
> It may be caused by drm's command parser. Can you disable the command parser simple and try again?
> The command parser disable by following command with root:
> echo 0 > /sys/module/i915/parameters/enable_cmd_parser
>
> Thanks,
> Yang Rong
>> -----Original Message-----
>> From: Zhigang Gong [mailto:zhigang.gong at gmail.com]
>> Sent: Monday, September 01, 2014 10:59 PM
>> To: David Liebman; Yang, Rong R
>> Cc: Zhigang Gong; Igor Gnatenko; beignet at lists.freedesktop.org
>> Subject: Re: [Beignet] [hpc12/tools] build of 'sum' on 'Intel(R) HD Graphics
>> IvyBridge M GT2' failed
>>
>> 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