tgsi: clarify the semantics of DFRACEXP
authorNicolai Hähnle <nicolai.haehnle@amd.com>
Fri, 15 Sep 2017 16:34:48 +0000 (18:34 +0200)
committerNicolai Hähnle <nicolai.haehnle@amd.com>
Fri, 29 Sep 2017 10:07:50 +0000 (12:07 +0200)
commit3c78215a1cf4e3d58295a6d3171a2c34c51875d5
treed5850687d051945e6580725268d6c71062414a4a
parentdbe7fc00d5715bcc08acc3141414da037938bbdd
tgsi: clarify the semantics of DFRACEXP

The status quo is quite the mess:

1. tgsi_exec will do a per-channel computation, and store the dst[0]
   result (significand) correctly for each channel. The dst[1] result
   (exponent) will be written to the first bit set in the writemask.
   So per-component calculation only works partially.

2. r600 will only do a single computation. It will replicate the
   exponent but not the significand.

3. The docs pretend that there's per-component calculation, but even
   get dst[0] and dst[1] confused.

4. Luckily, st_glsl_to_tgsi only ever emits single-component instructions,
   and kind-of assumes that everything is replicated, generating this for
   the dvec4 case:

     DFRACEXP TEMP[0].xy, TEMP[1].x, CONST[0][0].xyxy
     DFRACEXP TEMP[0].zw, TEMP[1].y, CONST[0][0].zwzw
     DFRACEXP TEMP[2].xy, TEMP[1].z, CONST[0][1].xyxy
     DFRACEXP TEMP[2].zw, TEMP[1].w, CONST[0][1].zwzw

Settle on the simplest behavior, which is single-component calculation
with replication, document it, and adjust tgsi_exec and r600.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
src/gallium/auxiliary/tgsi/tgsi_exec.c
src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h
src/gallium/docs/source/tgsi.rst
src/gallium/drivers/r600/r600_shader.c