Archives Discussions

[malcolm3141]

I keep encountering the following error being reported by the CAL compiler calclCompile(...).

ILScanILBinary: Unsupported opcode for architecture.

The offending line is a texture sample instruction:

sample_resource(0)_sampler(0)_coordtype(unnormalized)_aoffimmi(0.0,1.0,0.0) r67.xyzw, r66.xyz

The strange thing is that in some cases putting a comment after the sample instruction stops the error from occuring. Also the SKA compiler can compile the IL without any issues.

I am running Catalyst 10.7, while SKA is still using an earlier compiler version (may explain the difference).

Any ideas? I'd love to know a good workaround for this issue...

Malcolm

[malcolm3141]

And with some more attempts to work around the issue I can now sometimes get an error:

ILScanILBinary: Fatal Error: Non constant buffer constant detected.

Out of curiosity, what is ILScanILBinary for?

Also of interest is what is a Non constant buffer constant?

Thanks,

Malcolm

[Jawed]

Perhaps it's worth a try without "_coordtype(unnormalized)".

The coordinate type can be declared:

dcl_resource_id(0)_type(2d,unnorm)_fmtx(float)_fmty(float)_fmtz(float)_fmtw(float)

Are you really using a 3D texture? My snippet above is assuming you're using 2D.

[malcolm3141]

I've managed to work around this issue somehow, although I am not altogether clear how I did it...

I believe that the IL compiler doesn't always accept a uniform syntax for all instructions. For instance I was intending only to use a 2D texture, and changing to 'r66.xy' for all these instances helped reduce the issue, but didn't completely remove the issue. Note that according to the IL docs, the swizzle on the address register should be meaningless beyond the first two args (checking the ASM generated, it usually is).

I also had issues using the Evergreen instruction bit_insert, and I have removed all references to this instruction as well. Together, both these changes (and a few more tweaks besides) seem to have worked around this issue. However, I am not convinced that I will not hit it again in the future.

Malcolm

PS. The _coordtype(unnormalized) is the same syntax used by ATI OpenCL compiler, so I figure it should be reasonably well supported going forwards.