[Beignet] [hpc12/tools] build of 'sum' on 'Intel(R) HD Graphics IvyBridge M GT2' failed
Yang, Rong R
rong.r.yang at intel.com
Tue Sep 2 19:57:10 PDT 2014
Yes, linux kernel mainstream have already include this fix. The commit id is c9224faa59c3071ecfa2d4b24592f4eb61e57069.
I will update the document.
> -----Original Message-----
> From: Zhigang Gong [mailto:zhigang.gong at linux.intel.com]
> Sent: Wednesday, September 03, 2014 9:40 AM
> To: Yang, Rong R
> Cc: Zhigang Gong; David Liebman; Igor Gnatenko;
> beignet at lists.freedesktop.org
> Subject: Re: [Beignet] [hpc12/tools] build of 'sum' on 'Intel(R) HD Graphics
> IvyBridge M GT2' failed
>
> Rong,
>
> Does this issue fixed in latest kernel? Could you update the document
> accordingly?
> It's better to document it officially to indicate which kernels affected by this
> issue, and what's the eaxct kernel patch which already addressed this issue.
>
> Thanks,
> Zhigang Gong.
>
> On Tue, Sep 02, 2014 at 02:39:27AM +0000, 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
> > > >
> > > >
> > _______________________________________________
> > Beignet mailing list
> > Beignet at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/beignet
More information about the Beignet
mailing list