I've got CAL SDK and happy to use it. But I am interesting in possible arguments for some instructions like dcl_input[_usage(usage)] dst[.mask]. I've found this http://www.warthman.com/projects-ati-CAL-IL.htm, but I don't now were to get it.
You can get it in "doc" directory of CAL SDK on your machine after installing CAL SDK. The doc is named il.pdf.
That's not complete reference I think there are just 186 pages, and there are not enough information, I need to understand how to work with textures and how samplers realy work.
Originally posted by: kos
That's not complete reference I think there are just 186 pages, and there are not enough information, I need to understand how to work with textures and how samplers realy work.
I think we need to ask for that via email... Becouse it phisically exist somewhere in amd's company. I don't see any amd's moderators in this topic... why?
OK, can I access texture element by it's coordinate from any thread I want ? How to get thread number ? I can't understand one thing : writing il kernel I'm writing thread code or something else ?
Proper reques ? I thing that the complete manual realy exist...
Originally posted by: michael.chu@amd.com
Hi ryta1203,
I completely agree that you should not have to go the forum for your normal programming needs. You'll see a much cleaned up doc in AMD Stream SDK v1.2-beta.
As far as textures and samplers, the published IL reference was edited to show what we believed to be relevant from a compute stand point. However, your request is noted and I'll ask them to see if they can provide more texture and sampler information.
In addition to texture and sampler information, what other specific things are you looking for so I can make the proper request?
And, I apologize for being a little scarce on the forums recently! Too many duties, too little time!
Michael.
Originally posted by: MicahVillmow
Ryta,
The new documentation that we have been working on hopefully covers these concerns. As for the v0-v7 registers, please see calCtxRunProgramParams in cal_ext.h. The only example we have using this is the brook+ example. The basics of it is that you specify three corners of the rectangle you want to run for each of the eight inputs as a CALparam object and then you access them via the v0-v7 in the kernel. I have not used them myself, so can't really give much more information outside of that, but the brook+ source code does have a usage example.
Hey guys take a look at this : http://www.warthman.com/projects-ati-CAL-IL.htm. Is it real manual, which we need ?
Originally posted by: sgratton
Hi there,
I think you need to think about vWinCoord0 and v#'s like indices (or pointers) into arrays (the dcl_input_... instructions tell the compiler to set them up like this for you). "mov r0, vWinCoord0" moves the vWinCoord0 index itself into r0, NOT the associated value in an input array; vWinCoord0 is not automatically dereferenced. To get the value you need first to link up an array to a resource id using various cal functions on the cpp side and the dcl_resource_id(x)_... on the il side. For 8 input streams you'd declare 8 resources. Then you need to use e.g. sample_resource(3)_... r10, r0 to acually get the value in input array 3 corresponding to the position now stored in r0 into register r10. As Micah says, you could just write e.g. sample_resource(3)_... r10, vWinCoord0.xy if you wanted to. However, by loading vWinCoord0 into r0 you can play with the index (e.g. multiply by 4 say) first. You then load from multiple input arrays by using multiple sample_resource(x) instructions, and, by operating on the source register in between, you can load from different positions in each array.
Never having tried v1, v2..., I'm not sure, but from what I understand, they are just multiple indices set up for you and you'd just get any values you want by sampling as before, but with the appropriate index, like sample_resource(3)_... r13,v3. The point seems to be that you can get the hardware to precalculate input indices for you rather than you having to do it yourself.
The vWinCoord0 and v# registers in IL seem to be an abstraction and don't seem to correspond to any special registers in the GPUISA. Rather, the hardware "secretly" preinitializes the first few R# physical registers for you with the appropriate per-thread values before the shader runs.
Hopefully that's not too far off!
Best,
Steven.