[Cbe-oss-dev] Call/return from PPE to SPE functions

[Brian Watt]

> On Tuesday 29 May 2007, Brian Watt wrote:
> > > On Tuesday 29 May 2007, Brian Watt wrote:
> > >
> > > You could do it in theory, but it would be horribly inefficient. The 

> > > only
> > > time that you can set SPE general purpose registers is when the 
context
> > > is saved in kernel memory. Making a function call to the SPU this 
way
> > > basically means having more overhead than starting the program in 
the
> > > first place.
> > 
> > Hmmm, there is no "starting the program in the first place", instead 
the
> > SPU context would be created, and the program loaded once per 
> > thread-of-control,
> > then one or more SPE functions would be called as requested by the PPE 

> > program
> > using spe_context_run. So I don't see why there would be any more 
overhead 
> > than
> > today's starting of a main function or a SPE_RUN_USER_REGS function.
> 
> The fundamental difference is that a context is created in saved state,
> and then loaded into an SPU when you first call the spe_context_run
> function.

OK. I think I understand.
 
> The registers are only accessible in saved state, so in order to
> change them, the context needs to be suspended and written back
> into kernel memory.

That is fine, because I have no need to modify the registers while the 
context is executing. Instead I would only need to update the registers 
when the context is in a saved state prior to execution. Then the context 
would be executed which would execute the SPE program until it returns 
(though a completion stop and signal, 0x2000) whereby I assume the context 
is suspended and written back - therefore in a saved state. After this the 
registers could be read to get the results, and the process would repeat 
itself for the next call again by setting up the registers. So maybe I'm 
not understanding what the issue is that you are trying to explain to me, 
because I think the context is in the correct state as you suggest.
 
> > Today there is a set_regs function in the run.c file that is invoked 
by
> > the spe_context_run. This function opens the register spufs file and 
> > updates
> > it with the register values. This could still be used for function 
> > invocation,
> > although I'm sure that it is an computationally expensive way to 
update 
> > the
> > registers. Possibly a direct program state approach might be better, 
but
> > I've not investigated this yet. That is another reason I'm taking 
about
> > it here and learning about the options.
> > 
> > To allow the return of the result in a register, a new get_regs 
function
> > would need to be added to run.c which is invoked when the completion 
stop
> > and signal (0x2000) is received.
> 
> The registers are not accessible through any memory map, neither in the
> kernel, nor through problem state registers.
> The only way to set them is to run code on the SPU that actually reads
> and writes them from/to memory, and copy that over.

But today's LIBSPE does set the registers through set_regs and spufs 
access so somehow they are accessible in that case. However, if you are 
stating that direct problem (not program - oops) state does not provide 
any cability, thanks for this information and clarifying this. Given this, 
the current approach using set_regs then would be the only approach for 
setting registers in a context that is in saved state.
 
>    Arnd <><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/cbe-oss-dev/attachments/20070529/d453993c/attachment.htm>