Accéder au contenu.
Menu Sympa

starpu-devel - Re: [Starpu-devel] initialised SCRATCH buffer

Objet : Developers list for StarPU

Archives de la liste

Re: [Starpu-devel] initialised SCRATCH buffer


Chronologique Discussions 
  • From: Xavier Lacoste <xavier.lacoste@inria.fr>
  • To: starpu-devel@lists.gforge.inria.fr
  • Subject: Re: [Starpu-devel] initialised SCRATCH buffer
  • Date: Thu, 05 Jan 2012 11:12:14 +0100
  • 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>

Le 05/01/2012 10:58, Samuel Thibault a écrit :
Xavier Lacoste, le Thu 05 Jan 2012 10:33:44 +0100, a écrit :
I would like StarPU to build the array using a function of the codelet
arguments at the same time he moves data to the executing device.
Do you mean that the initialization value needs to depend on the
parameters of the task? Can't the codelet do the initialization itself
in such case, since it'll have to be done for each task anyway?

What we were planning to implement was only a way to initialize the
scratch buffer when it is allocated, i.e. once for good and not once for
each task (unless the buffer gets evicted due to low memory conditions).

Samuel

Yes this is what I mean this array depends on parameters of the task.
It is build from the bloc number and the whole sparse matrix structure which are given through cl->args.
The bloc number is on the computing device but the sparse matrix is just a pointer to the data and the GPU can't see what is pointed to as it is not copied.

Yes I could build the array in my codelet using my cl->args, then send it to the GPU.
But that data transfer may be covered by computation if it was performed at the same time data are copied to device.
And I wanted to let StarPU manage all data transfer.

Xavier.






Archives gérées par MHonArc 2.6.19+.

Haut de le page