From f84a33ac9b1040419ac3a23671eae4f06ab97504 Mon Sep 17 00:00:00 2001 From: lkcl Date: Mon, 13 Jun 2022 18:58:36 +0100 Subject: [PATCH] --- openpower/sv/mv.swizzle.mdwn | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/openpower/sv/mv.swizzle.mdwn b/openpower/sv/mv.swizzle.mdwn index 958231ad5..b6b121875 100644 --- a/openpower/sv/mv.swizzle.mdwn +++ b/openpower/sv/mv.swizzle.mdwn @@ -174,13 +174,15 @@ may be assumed to be 4. **Effect of Saturation on Vectorised Swizzle** -``` -one thing that occurred to me: we need fmv.swizzle and maybe mvfixed[u].swizzle too (integers where 0.0 maps to 0 and 1.0 maps to the max signed/unsigned integer -- used for fixed-point swizzle such as pixel data -- we need signed ints for efficient bump map support for some programs). the 0.0 and 1.0 constants should map to 0, 1 for mv.swizzle, 0.0, 1.0 for fmv.swizzle, 0, UINT_MAX for mvfixedu.swizzle, and 0, INT_MAX for mvfixed.swizzle. - -i like the idea of a SKIP option! - -Jacob -``` +A useful convenience for pixel data is to be able to insert values +0x7f or 0xff as magic constants for arbitrary R,G,B or A. Therefore, +when Saturation is enabled and a Swizzle=0b011 (Constant 1) is requested, +the maximum permitted Saturated value is inserted rather than Constant 1. +`sv.mv.swiz/sats/vec2/ew=8 RT.v, RA.v, Y1` would insert the 2nd subelement +(Y) into the first destination subelement and the signed-maximum constant +0x7f into the second. A Constant 0 Swizzle on the other hand still inserts +zero because there is no encoding space to select between -1, 0 and 1, and +0 and max values are more useful. # RM Mode Concept: -- 2.30.2