diff options
author | Nicolai Hähnle <[email protected]> | 2017-09-15 18:34:48 +0200 |
---|---|---|
committer | Nicolai Hähnle <[email protected]> | 2017-09-29 12:07:50 +0200 |
commit | 3c78215a1cf4e3d58295a6d3171a2c34c51875d5 (patch) | |
tree | d5850687d051945e6580725268d6c71062414a4a /src/gallium/auxiliary/rtasm | |
parent | dbe7fc00d5715bcc08acc3141414da037938bbdd (diff) |
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 <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
Diffstat (limited to 'src/gallium/auxiliary/rtasm')
0 files changed, 0 insertions, 0 deletions