cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

entity279
Adept II

kernel(float, out float3) issues



kernel void expand_copy(float distances<>,out float3 new_distances<>
{

 new_distances.x=distances;
 new_distances.yz=0;
 
}


When I run this kernel, it doesn't fill the .yz output with 0s. Instead, it just fills the output stream with all the values form the input one, just as if the output were a 3 times larger float stream. So yeah, after one third of new_distances, there are only zeroes in it.

So i don't understand what in this kernel allows the .xyz assignments to be almost completly bypassed (almost because the assiments do happen, just in an unexpected way).

 

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

0 Likes
5 Replies
Methylene
Journeyman III

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)x;
  {
   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.x, t3.y, t3.z);
}



0 Likes

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

0 Likes

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?

 

 

0 Likes

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.

0 Likes

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..