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
