kernel void expand_copy(float distances<>,out float3 new_distances<>
{
new_distances.x=distances;
new_distances.yz=0;
}
And I'm using this aparently stupid code to get the minimum out of a two dimensional stream, along with the indexes of thouse dimensions, in a single pass; since i can't reduce a float to a float 3 directly(brook won't let me), I have to implement the reduce from a float3 to a float3 - the expand() kernel prepares that by transforming the float stream into a float3 one
I just tested the code exactly as you posted it, using a buffer initialized to 10 values from 0-9
Output is:
1: 0.000000 0.000000 0.000000
2: 1.000000 0.000000 0.000000
3: 2.000000 0.000000 0.000000
4: 3.000000 0.000000 0.000000
5: 4.000000 0.000000 0.000000
6: 5.000000 0.000000 0.000000
7: 6.000000 0.000000 0.000000
8: 7.000000 0.000000 0.000000
9: 8.000000 0.000000 0.000000
10: 9.000000 0.000000 0.000000
I'm using 1.2.1 on Ubuntu 8.10 with the 8.552 driver (catalyst 8.11).
What OS are you using? SDK version?
If I do .yz = 1, yz are both set to 1.
How are you parsing your data? And also be sure your streams have the right types (trying to map using float where it should be float3 can lead to some fun and interesting errors)
In fact I think this is what happened... Here's code and output...
#include
//***float input, float3 output!
kernel void test(float distances<>, out float3 new_distances<>
{
new_distances.x = distances;
new_distances.yz = 1;
}
int main(int argc, char** argv)
{
float* t = NULL;
float3* t3;
int x = 0;
t = (float*)malloc(sizeof *t * 10);
t3 = (float3*)malloc(sizeof *t3 * 10);
for(x = 0; x < 10; x++)
t
{
float i<10>;
// **********************************************
// o should most definitely be float3, it makes sense that mapping to a float would do
// exactly that, it's only 1 float!
float o<10>;
streamRead(i, t);
test(i, o);
streamWrite(o, t3);
}
for(x = 0; x < 10; x++)
printf("%d: %f %f %f \n", x + 1, t3
}
Doh clumsy fingers there...
Output:
1: 0.000000 1.000000 2.000000
2: 3.000000 4.000000 5.000000
3: 6.000000 7.000000 8.000000
4: 9.000000 0.000000 0.000000
5: 0.000000 0.000000 0.000000
6: 0.000000 0.000000 0.000000
7: 0.000000 0.000000 0.000000
8: 0.000000 0.000000 0.000000
9: 0.000000 0.000000 0.000000
10: 0.000000 0.000000 0.000000
note above where I edit in a comment on the problematic line
well yeah ran your code with o as float3 and it works as intended, just like in the first output table you posted. As I already said, with my code the output is the undesired one in your second post.
I have Stream 1.2, Vistax64.
Refering to my code
distances<> is float distance_gather<tot_vect>;
new_distances is float3 new_distances<tot_vect>;
(call ofcourse is: expand_copy(distance_gather,new_distances) ) .
So these are unidimensional streams and can't see why your code worked and mine didn't. I'm trying to figure out though. And how din you after all achieve the second output - the incorrect one - you talk about?
the just by designating o to be float rather than float 3... What you're talking about occurs because there is only room to map 1 value, and then the output along the way is cast to a float3 and when you index into it all of the values are in the beginning, and the rest is (probably) unallocated... So you end up making what appears to be a few float3s but really you're just indexing into a float array with a bunch of space tacked on due to the cast.
I've made this mistake a lot as I was starting out with Brook+. Just search through your code and insure that the kernel says float3 new_distances as well as the stream declaration, and the memory you finally write it to. I'd be surprised if the problem was located anywhere besides the stream declaration.
Fixed, thanks for the help. I mean you had set me on the good search path. The error was stupid eneough, I was outputing a simple float stream instead of the float3 stream i had calculated with my expand_copy() kernel. Should have noticed this earrlier though..
Once again, thanks..