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:[email protected]] > Sent: Wednesday, September 03, 2014 9:40 AM > To: Yang, Rong R > Cc: Zhigang Gong; David Liebman; Igor Gnatenko; > [email protected] > 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:[email protected]] > > > Sent: Monday, September 01, 2014 10:59 PM > > > To: David Liebman; Yang, Rong R > > > Cc: Zhigang Gong; Igor Gnatenko; [email protected] > > > 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 > > > <[email protected]> > > > 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 > > > >>>>> <[email protected]> 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@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 <[email protected]> > > > >>>>>>> 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 <[email protected]> > > > >>>>>>> --- > > > >>>>>>> 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 > > > >>> [email protected] > > > >>> http://lists.freedesktop.org/mailman/listinfo/beignet > > > > > > > > > > _______________________________________________ > > Beignet mailing list > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/beignet _______________________________________________ Beignet mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/beignet
