I saw that you have work around the issue, right?
It is hard to support passing pointer to pointer in kernel argument.
This is restriction in OpenCL 1.2. documented in chapter 6.9 of OpenCL Spec.

> This is restriction in OpenCL 1.2. documented in chapter 6.9 of OpenCL Spec

That's fine.  I can rewrite the kernel to not pass any structs as kernel parameters:

struct Eigen__TensorEvaluator {
    global float* f0;
    float f1;
};

kernel void foo(global float *floats0, global float* floats1) {
    global struct Eigen__TensorEvaluator *pstruct = (global struct Eigen__TensorEvaluator *)floats0;
    pstruct[0].f0 = floats1;
    pstruct[0].f0[0] = pstruct[0].f1;
}

This crashes with the same error as before:

context <pyopencl.Context at 0x1a726b0 on <pyopencl.Device 'Intel(R) HD Graphics 5500 BroadWell U-Processor GT2' on 'Intel Gen OCL Driver' at 0x7fc1d0e61be0>>
ASSERTION FAILED: (isa<AllocaInst>(ptr) || ptrCandidate.empty()) && "storing/loading pointers only support private array"
  at file /home/ubuntu/git/beignet/backend/src/llvm/llvm_gen_backend.cpp, function void gbe::GenWriter::findPointerEscape(llvm::Value*, std::set<llvm::Value*>&, bool, std::vector<llvm::Value*, std::allocator<llvm::Value*> >&), line 953
Trace/breakpoint trap

From my understanding, the rewritten code is semantically the same as "pointer to pointer". because you still interpret the pointer as a "pointer to pointer". Could you tell me why you are storing the pointer to global memory? this is very strange because the pointer your store to global memory will be invalid after this NDRange. If you will use the stored pointer in the same kernel, can "storing the pointer in private array" solve your problem?

The pointer I'm storing is a valid pointer.  It's a global float *, passed in normally to the kernel, as a standard kernel parameter.

> this is very strange because the pointer your store to global memory will be invalid after this NDRange. 

This is just the start of the kernel.  the full kernel looks like this: https://github.com/hughperkins/cuda-on-cl/blob/9a7d9175629e9f267b05d63295308d2515929b82/test/eigen/generated/test_cuda_nullary-device.cl#L74

(well, like this: https://github.com/hughperkins/cuda-on-cl/blob/9a7d9175629e9f267b05d63295308d2515929b82/test/eigen/generated/test_cuda_nullary-device.cl#L164 )

(In reply to ruiling from comment #3)
> From my understanding, the rewritten code is semantically the same as
> "pointer to pointer". because you still interpret the pointer as a "pointer
> to pointer". Could you tell me why you are storing the pointer to global
> memory? this is very strange because the pointer your store to global memory
> will be invalid after this NDRange. If you will use the stored pointer in
> the same kernel, can "storing the pointer in private array" solve your
> problem?

@Ruiling, I believe what Perks want to do is to translate CUDA to OpenCL at IR level. And he may only want to use that pointers witin that kernel and will not access it after this kernel enqueue. @Perkins, correct me if I am wrong. Although I haven't found the related statement in OpenCL Spec, it is indeed doable based on our current implementation. But it's up to beignet team to whether adding this support.

Zhigang wrote:
> I believe what Perks want to do is to translate CUDA to OpenCL at IR level. And he may only want to use that pointers witin that kernel and will not access it after this kernel enqueue.

Yes, this is correct.

(In reply to Hugh Perkins from comment #5)
> (well, like this:
> https://github.com/hughperkins/cuda-on-cl/blob/
> 9a7d9175629e9f267b05d63295308d2515929b82/test/eigen/generated/
> test_cuda_nullary-device.cl#L164 )

I take a look at the kernel. Such kind of usage is supported by OpenCL 2.0.
currently the support of this feature is in OCL20 branch. Are you interested in having a try against the OCL20 branch? You need to use Linux kernel >=4.4 and libdrm >=2.4.66

Hi Ruiling,

Using 2.0 branch sounds great!  It looks like eg ubuntu 16.04 has the requirements you mention out of the box.  So, I can continue to use OpenCL 1.2 api, but use the 2.0 version of the Beignet driver, and all should work approximately in the way I'm looking for?

Hugh

(In reply to Hugh Perkins from comment #9)
> Hi Ruiling,
> 
> Using 2.0 branch sounds great!  It looks like eg ubuntu 16.04 has the
> requirements you mention out of the box.  So, I can continue to use OpenCL
> 1.2 api, but use the 2.0 version of the Beignet driver, and all should work
> approximately in the way I'm looking for?
> 
> Hugh

Yes, it should work using OpenCL 1.2 API. There may some little difference. But mostly it will not cause any issue to you.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/beignet/beignet/issues/5.