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:[email protected]] On Behalf Of > David Liebman > Sent: Tuesday, September 02, 2014 8:34 PM > To: Yang, Rong R; Zhigang Gong > Cc: Igor Gnatenko; Zhigang Gong; [email protected] > 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:[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
