[Beignet] [hpc12/tools] build of 'sum' on 'Intel(R) HD Graphics IvyBridge M GT2' failed
Yang, Rong R
rong.r.yang at intel.com
Mon Sep 1 19:39:27 PDT 2014
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