[Nouveau] Tesla shader ISA question

[Andy Ritger]

Hi Ilia, sorry for the slow response.

This isn't my area of expertise, but as I understand it:

* You've correctly decoded both instructions:
   * The first is a float32-to-float32 conversion, applying ceil()
   * The second is a float32-to-signed-int32 conversion, rounding to 
     the nearest even integer

* For the {float,int}-to-{float,int} operations, bit 48 indicates
 whether the input is signed (1==signed), but that bit is ignored when 
 the source format is float (always signed). That should apply across 
 the entire Tesla architecture.

Where did the Tesla shader come from that you were decoding? I assume 
it was produced by the NVIDIA proprietary driver?

If I had to guess, I'd speculate that the shader compiler in the NVIDIA 
proprietary driver used an uninitialized variable, and then overwrote the 
bits that mattered for the opcode it was producing, leaving uninitialized
data in the unused bits.

I hope that helps,
- Andy Ritger


On Thu, Feb 27, 2014 at 11:37:40PM -0800, Ilia Mirkin wrote:
> Hello,
> 
> I've recently run into an unknown bit in Tesla shaders, and was hoping
> you could shed some light on it. I believe they're related to clamping
> of some sort. Here are 2 examples (from diff shaders):
> 
> a0000401 cc054780     cvt rpi f32 $r0 f32 $r2 [unknown: 00000000 00010000]
> a000060d 8c014780     cvt rni s32 $r3 f32 $r3 [unknown: 00000000 00010000]
> 
> [This is intel-style syntax, cvt = convert/move, rni/rpi = rounding
> mode stuff, hope that clears up the syntax...]
> 
> The destination register tends to go to a texture-related instruction
> input, in some cases the layer (which is why I suspect clamping). Both
> of these were seen on shaders compiled for GT215+ chips. What effect
> does turning it on have exactly? Also, is this bit available on
> earlier chips (if so, how early)?
> 
> Thanks,
> 
>   -ilia