[Beignet] [hpc12/tools] build of 'sum' on 'Intel(R) HD Graphics IvyBridge M GT2' failed

[David Liebman]

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.
>