<br><tt><font size=2>> On Tuesday 29 May 2007, Brian Watt wrote:<br>
> > > On Tuesday 29 May 2007, Brian Watt wrote:<br>
> > ><br>
> > > You could do it in theory, but it would be horribly inefficient.
The <br>
> > > only<br>
> > > time that you can set SPE general purpose registers is when
the context<br>
> > > is saved in kernel memory. Making a function call to the
SPU this way<br>
> > > basically means having more overhead than starting the program
in the<br>
> > > first place.<br>
> > <br>
> > Hmmm, there is no "starting the program in the first place",
instead the<br>
> > SPU context would be created, and the program loaded once per
<br>
> > thread-of-control,<br>
> > then one or more SPE functions would be called as requested by
the PPE <br>
> > program<br>
> > using spe_context_run. So I don't see why there would be any
more overhead <br>
> > than<br>
> > today's starting of a main function or a SPE_RUN_USER_REGS function.<br>
> <br>
> The fundamental difference is that a context is created in saved state,<br>
> and then loaded into an SPU when you first call the spe_context_run<br>
> function.<br>
</font></tt>
<br><tt><font size=2>OK. I think I understand.</font></tt>
<br><tt><font size=2> <br>
> The registers are only accessible in saved state, so in order to<br>
> change them, the context needs to be suspended and written back<br>
> into kernel memory.<br>
</font></tt>
<br><tt><font size=2>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.</font></tt>
<br><tt><font size=2> <br>
> > Today there is a set_regs function in the run.c file that is
invoked by<br>
> > the spe_context_run. This function opens the register spufs file
and <br>
> > updates<br>
> > it with the register values. This could still be used for function
<br>
> > invocation,<br>
> > although I'm sure that it is an computationally expensive way
to update <br>
> > the<br>
> > registers. Possibly a direct program state approach might be
better, but<br>
> > I've not investigated this yet. That is another reason I'm taking
about<br>
> > it here and learning about the options.<br>
> > <br>
> > To allow the return of the result in a register, a new get_regs
function<br>
> > would need to be added to run.c which is invoked when the completion
stop<br>
> > and signal (0x2000) is received.<br>
> <br>
> The registers are not accessible through any memory map, neither in
the<br>
> kernel, nor through problem state registers.<br>
> The only way to set them is to run code on the SPU that actually reads<br>
> and writes them from/to memory, and copy that over.<br>
</font></tt>
<br><tt><font size=2>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.</font></tt>
<br><tt><font size=2> <br>
> Arnd <><<br>
</font></tt>