4 Replies Latest reply on Nov 1, 2010 1:41 AM by unique_screenname_here

    Pixel Bender math bug...

    david van brink

      Hope this is an ok place for this info...

       

      I found that in Pixel Bender Toolkit, in CPU mode, some mod() operations return incorrect results.

       

      mod(a,1.0) should never return 1.0, right? Language spec defines mod(a,1.0) as a - floor(a).

       

      This pbk makes the screen all RED, in CPU mode, but not in GPU or Flash mode.

       

      About screen says: Version: 2.0.422584, I'm running on an Intel Mac.

       

       

      <languageVersion : 1.0;>

      kernel NewFilter

      <   namespace : "ns"; vendor : "v"; version : 1; description : "d";>

      {

          input image4 src;

          output pixel4 dst;

       

          void

          evaluatePixel()

          {

              float pi2 = 2.0 * 3.141592653;

       

              float theta = atan(-20.0,20.0);

              theta += 0.125 * pi2;

              float d = theta / pi2;

       

       

              float a = mod(d,1.0);

       

              // at this point, a should always be in [0,1), that is, never be 1.0.

              // let's draw RED if it is!

       

              if(a == 1.0) // cannot happen!

                  dst = float4(1,0,0,1);

              else

                  dst = float4(.2,.2,.5,1); // dull blue, normally

          }

      }

        • 1. Re: Pixel Bender math bug...
          unique_screenname_here Level 3

          This is definitely the right place to ask these questions and also to report bugs, so please keep it up.

           

          I don't believe this is a mod bug; the same result occurs if you replace your call to mod with "float a = d - 1.0 * floor(d/1.0);" (or that equation reduced to "float a = d - floor(d);" as you noted). Try wrapping d in "abs()" as in "float a = mod(abs(d),1.0);" if that won't break your equation. Alternately, you could wrap the result of the call to atan() in abs() as in "float theta = abs(atan(-20.0,20.0));". I'll ask the compiler guys if they can determine what's happening to d to cause this problem. I believe the problem is more likely caused by the call to arctan().

          • 2. Re: Pixel Bender math bug...
            Kevin Goldsmith Level 3

            yeah, I'm totally repro-ing the problem. I also tried some stuff around the logic to make sure that the result of the mod is exactly 1.0 on the CPU in the toolkit (as opposed to some other logic or math bug) and indeed it is being returned that way. I have to work through because neither

             

                void
                evaluatePixel()
                {
                    dst = sampleNearest(src,outCoord());
                    float a = mod(dst.r,1.0);
                    if ( a == 1.0 )
                    {
                        dst = float4(1.0, 0.0, 0.0, 1.0);
                    }
                }

             

            nor

             

                void
                evaluatePixel()
                {
                    dst = sampleNearest(src,outCoord());
                    float a = mod(dst.r+1.0,1.0);
                    if ( a == 1.0 )
                    {
                        dst = float4(1.0, 0.0, 0.0, 1.0);
                    }
                }

             

            shows the bug.

            • 3. Re: Pixel Bender math bug...
              david van brink Level 1

              Evening, USN, Kevin --

               

              Thanks for looking at this.

               

              Yeah, I couldn't figure out what the Magic Value is that's driving the problem, except that in working on my kernel, it came out of the atan along certain pixel diagonals. Then, simplified the code til getting to the exact example shown. Glad you can see it.

               

              Dem roundoffs! It's gonna be some flavor of .999999999, i can feel it.

               

              unique -- my workaround is pretty simple: if(x == 1.0) x = 0.0; fixes it 100%. But you can see that mod(a,1.0) should never be 1.0, right? (And should  behave the same on GPU vs CPU...)

               

              Cheers!

              ==> david

              • 4. Re: Pixel Bender math bug...
                unique_screenname_here Level 3

                David, sorry if I missed you're point. You're correct, "mod(x, 1.0)" should never be 1.0 and the results should match on both the CPU and GPU. However, my point was that I don't believe the underlying problem is as simple as a bug in mod()--I hope I'm wrong. I agree this definitely feels like, "some flavor of .999999999." Thanks again for reporting this problem.