[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:30:43 PDT 2014
Thanks for you feedback.
The command parser is a new feature of intel drm, It would break beignet, and the intel drm have fix it in the mainstream. I will new a bug in fedora to include this fix.
> -----Original Message-----
> From: Beignet [mailto:beignet-bounces at lists.freedesktop.org] On Behalf Of
> David Liebman
> Sent: Tuesday, September 02, 2014 8:34 PM
> To: Yang, Rong R; Zhigang Gong
> Cc: Igor Gnatenko; Zhigang Gong; beignet at lists.freedesktop.org
> Subject: Re: [Beignet] [hpc12/tools] build of 'sum' on 'Intel(R) HD Graphics
> IvyBridge M GT2' failed
>
> 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
> >>>
>
> _______________________________________________
> Beignet mailing list
> Beignet at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/beignet
More information about the Beignet
mailing list