Archives Discussions

[syskin]

mysterious cb0[]

Hi

Because of some evil limitations of Brook and non-triviality of my kernel, I decided to write my kernel in Brook+, compile to IL and run from CAL.

All's sensible, except a mysterious constant table generated by Brook. Apparently all reduction kernels have it - it's referenced as cb0[1] and apparently it's three-word long (cb0[0].xyz ever used, w unused).

To run kernel from CAL I need to populate this cb0, but I have no idea with what. Tracking the kernel code didn't help, tracking Brook-generated C++ leaves me confused as well.

Anyone has any idea what to put in this cb0?

To reproduce: The simplest reduction kernel of

reduce void k(int input<>, reduce int output ) { output += input; }

Thanks in advance.

[gaurav_garg]

Reduction is a difficult problem to solve with this approach. As reduction is really a multi-pass algorithm implemented by runtime. The constants that you  see are the ones those runtime need to pass run that kernel.

e.g. if you scroll down the generated header file. You see the following line -

.constant(0, brook::CONST_REDUCTIONFACTOR)

It means a constant is passed to the kernel. To really understand what values you need to pass, you need to understand the runtime.

I think if you want to experiment with this path, you should first try with non-reduction, non-scatter kernels where the mapping of constants is straight forward and no extra constants are generated in generated kernel. Let me know if you have more questions.

[syskin]

Thanks for reply.

I "think" I have no trouble with non-reduction kernels - I mean I've never tried, but I see what's going on.

What I need is a reduction kernel though...

Yes I've seen this brook::CONST_REDUCTIONFACTOR and it only left me confused - it's simply an integer-sized enum, and as you say the actual brook runtime must be doing something with it.

I'll install Brook source and see if I can deduce something...

Is there a magic way for me to use Brook after all? The difficulty I have is D3D interoperbility, source data is in a D3D9 surface. Can I somehow mix CAL and Brook to work around this? CAL can give me source stream, Brook can handle reduction.

[gaurav_garg]

Hi syskin,

I think the right approach for you should be modify Brook+ interface to get CALresource. Changing interface to get these CAL handles should be easier than understanding and implementing various internal Brook+ virtualization algorithms.

As a side note we have an RFE to support D3D interoperability at Brook+ level. So, you can be sure that these features will be available at Brook+ level in future release.