Objet : Developers list for StarPU
Archives de la liste
- From: Samuel Thibault <samuel.thibault@ens-lyon.org>
- To: Usman Dastgeer <usman.dastgeer@liu.se>
- Cc: "starpu-devel@lists.gforge.inria.fr" <starpu-devel@lists.gforge.inria.fr>
- Subject: Re: [Starpu-devel] OpenCL problem
- Date: Thu, 4 Aug 2011 19:18:11 +0200
- List-archive: <http://lists.gforge.inria.fr/pipermail/starpu-devel>
- List-id: "Developers list. For discussion of new features, code changes, etc." <starpu-devel.lists.gforge.inria.fr>
Hello,
Thanks for the sample. We indeed have an issue here, which shows up when
the data is already available on the OpenCL device before partitioning,
in which case StarPU simply partitions the data in-place, without
reallocation. And that's the case in your test since the first task
loaded it. In that case,
T* input = (T *)STARPU_VECTOR_GET_PTR(vector);
gets a sorta bogus value: it's the cl_mem plus the offset (which then is
not zero).
I tried to replace
clSetKernelArg(kernel, 0, sizeof(cl_mem), (void*)&input);
with
clSetKernelArg(kernel, 0, sizeof(cl_mem), (void*)&vector->dev_handle);
(dev_handle is in this case the original cl_mem for the whole data).
and then it produces correct values.
I don't know OpenCL so much, but I guess that cl_mem is only a handle,
not a data pointer, so StarPU should actually use clCreateSubBuffer to
be able to provide the application with a cl_mem handle which points
inside the original buffer, so the application can use it for kernel
arguments.
Samuel
- Re: [Starpu-devel] OpenCL problem, Samuel Thibault, 04/08/2011
Archives gérées par MHonArc 2.6.19+.