[Chromium-dev] gets on NOP SPU

[<aac...@ad...>]

From nop.py, notice it calls 'crState' for 'get' statements and 'nop' for everything else...I was curious about the 'crState'.  Is this some form of state-tracking and how does it work?  See crState in line '2' below.

nop.py code from the bottom of file
...
1 elif "get" in apiutil.Properties(func_name):
2 	print '\t{ "%s", (SPUGenericFunction) crState%s },' % (func_name, func_name )
3 else:
4 	print '\t{ "%s", (SPUGenericFunction) nop%s },' % (func_name, func_name )
 



---- Brian Paul <bri...@tu...> wrote: 
> aac...@ad... wrote:
> > Hi.
> > 
> > I had a question about the NOP spu. I noticed that for Extended Opcode
> > calls which return information all happen to call functions within the
> > state_tracker\state_regcombiner.c file.
> 
> The NOP SPU doesn't do anything like that.  See spu/nop/nopspu.c
> 
> 
> > I assume this is to maintain some sort of state on the crserver
> > side. Does the application client sit and wait to receive a return
> > call (crNetSend->crNetRecv) for these Extended Opcode calls, or is it
> > left waiting forever?
> > 
> > Does anyone have a good explanation as to what the NOP does when it
> > receives these Extended Opcodes?
> 
> Are you sure you're talking about the NOP SPU?
> 
> -Brian
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev