8 Replies Latest reply on Aug 5, 2008 4:38 PM by ryta1203

    CAL question

    ryta1203
        • CAL question
          MicahVillmow
          Ok, I see the issue here.
          First off, to answer your question about "i0". "i0" stands for input resource 0. This comes with the line in the IL code, dcl_resource_id(N)... where iN stands for the Nth+1 input resource that is declared.

          Second, the error you are seeing is because you are incorrectly mapping the input memory to the input name of the kernel. In the function call calCtxSetMem for the input memory, you are using inputMem, however, it is set to zero as you have not yet bound the memory to a resource. There is a binding done in the program via the calCtxGetMem, but that is for the mem variable and not the inputMem or outputMem variables. If you check out hellocal with respect to the tutorial code, it should make a little more sense. Hellocal is one of the simplest CAL programs you can write.
            • CAL question
              ryta1203
              Micah,

              Thanks, I now clearly see where the fault lies, I appreciate it.

              I was also wondering a second question: will GSA produced code work in CAL?

              For instance GSA is producing this code for me:

              #ifndef _UnknownShader_H
              #define _UnknownShader_H

              const char f_szUnknownShader[] =
              "il_ps_2_0"
              "dcl_input_position_interp(linear) v0.x___"
              "dcl_input_generic v1.x___"
              "dcl_output_generic o0"
              "dcl_resource_id(0)_type(1d)_fmtx(float)_fmty(float)_fmtz(float)_fmtw(float)"
              "dcl_resource_id(1)_type(1d)_fmtx(float)_fmty(float)_fmtz(float)_fmtw(float)"
              "sample_resource(0)_sampler(0) r0, v0.x"
              "sample_resource(1)_sampler(1) r1, v1.x"
              "mul o0, r0, r1"
              "ret_dyn"
              "end";

              #endif // _UnknownShader_H

              but when I enter this code I get compiling error, as if the syntax of the kernel is not correct, any ideas?
                • CAL question
                  uytvbn

                  The lines should be separated with \n.

                    • CAL question
                      ryta1203
                      Originally posted by: uytvbn

                      The lines should be separated with \n.



                      That's not it, but thanks for the response.

                      They (\n) are in my code, and in fact, I don't use the "UnknownShader..." stuff, I just use a string like above. I just copy and pasted this code directly from GSA not from my code.

                      I initialize resource(1) just like I do resource(0) in my setup code, calling it "i1".
                • CAL question
                  MicahVillmow
                  ryta,
                  As GSA doesn't use the CAL Compiler but uses a different compiler, it is not guaranteed to generate CAL usable code 100% of the time. In your above example, it seems that you are using v0.x and v1.x, which are incorrect. CAL only supports vWinCoord0.xy for the x/y coordinates and and vObjIndex for an integer index as input variables. There is one exception and that is if you use and setup correctly, via our extensions, your own interpolators and use calCtxRunProgramParams. This is the path used by Brook+. If you change to using vWinCoord0.x___, then your code should work.
                    • CAL question
                      ryta1203
                      Micah,

                      Thanks again! I was thinking that each input has to go into a separate input register, but in fact, using just vWinCoord0.x (for 1D) I can achieve different inputs via the different resource_id numbers. So where are the inputs stored exactly, in hardware if not in input registers (v0). Which memory?
                    • CAL question
                      MicahVillmow
                      ryta,
                      v0, vWinCoord0, vObjIndex0 are read-only input registers generated by the hardware when a thread is created. vWinCoord0 is equivalent to indexof(output_stream), whereas v0-v7 are equivalent to indexof(input_stream). vWinCoord0 is your position the execution domain, v0-v7 are your positions in the input streams(if you set it up correctly) relative to your position in the execution domain.
                        • CAL question
                          ryta1203
                          Micah,

                          So, vWinCoord.x should return a index value and not a value of an element? indexof() returns the index value of the kernel, not the value of that element of the variable in that index of the kernel.

                          My questions is when I do this:

                          "il_ps_2_0\n"
                          "dcl_input_position_interp(linear) vWinCoord0.x___\n"
                          "dcl_output_generic o0\n"
                          "dcl_resource_id(0)_type(1d,unnorm)_fmtx(float)_fmty(float)_fmtz(float)_fmtw(float)\n"
                          "dcl_resource_id(1)_type(1d,unnorm)_fmtx(float)_fmty(float)_fmtz(float)_fmtw(float)\n"
                          "dcl_literal l0, 0x0000001, 0x00000002, 0x00000002, 0x00000002\n"
                          "mov r1, l0\n"
                          "utof r2, r1\n"
                          "sample_resource(0)_sampler(0) r0, vWinCoord0.x\n"
                          "sample_resource(1)_sampler(1) r3, vWinCoord0.x\n"
                          "mul r1, r0, r3\n"
                          "div o0, r1, r2\n"
                          "ret_dyn\n"
                          "end\n";

                          What exactly is the "sample_resource(x)_samper(x) rx, vWinCoord0.x" statement doing? I didn't really gather this from the IL docs. If vWinCoord0.x is an "indexof()" then where is r0 getting it's value from, in Hardware?

                          Furthermore, does the statement go to the position of the resource(x) held by index vWinCoord0.x and return that value to rx?