Archives Discussions

[Ceq]

Hello, I think I've found a issue when you use a stream as a function parameter in SDK 1.1b. If you don't specify a size it won't compile. Example:

void str_red_aux(double2 input<> ) { }

Brook+ output:

str_red.br:1: Error (syntax error) before 'int'
void str_red_aux(double2 input<> ) {
^
Errors - Aborting parse.
***Unable to parse str_red.br

-----------------------

However if you write any number as a stream size it will work:

void str_red_aux(double2 input<9> ) { }

According to the documentation I think you don't really need to specify the size, moreover Brook+ translates it in something that doesn't need the size:

void str_red_aux(::brook::stream input) { }

==============


Second issue is related to a strange behavior, if you try to compile:

kernel void ker_copy(float4 a<>, out float4 b<> ) { b = a; }
kernel void ker_set1(out float4 c[], float i<> ) { c[ i ] = 1; }

You get a really verbose error, quite large to paste here. However if you split those lines in two different files it works OK.

==============


Last question: Was iterator support dropped? If you try to compile:

iter float it<10> = iter(0, 10);

The compiler will abort:

ERROR--1: Iterator not supported
str_inc.br:23: float it<10>
***Semantic check found 1 errors


Thanks.

[michael_chu]

Hi Ceq,

Yes, I believe iterator support was dropped.

Thanks for the bug reports! I'll forward those on to the engineering team!

Michael.

[michael_chu]

Hi Ceq, sorry about letting this one go for so long...

One of the engineers pointed out that in your first case, you are trying to pass a stream into a normal function which isn't valid from a language point of view. Streams can only be passed to kernels and Brook+ assumes that and treats anything that has a stream as a parameter as a kernel.

Michael.

[Ceq]

Thanks Michael, I'm quite surprised because this was a standard feature in Stanford's Brook project, you can see in "prog/test" folder a few examples like "accumulate", "pack_vout" or "scan".
Even in Brook+ it is working correctly, you just have to use the workaround mentioned above.

I think this is a good feature and is a pity to remove it, for example:
It can be used to split work in several functions, calling kernels from each one of them and passing the results of the previous function as a parameter, this way you can avoid having huge functions that need to setup all the streams and launch all related kernels.

Using StreamWrite, passing it to another function as a pointer and then perform StreamRead again would be very slow.
I think it would be particulary useful in large works or in order to reuse certain functions.