[Libre-soc-isa] [Bug 1077] evaluate removing /vec234 from instructions, move subvl to SVSTATE

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1077

--- Comment #18 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Dmitry Selyutin from comment #7)
> So we free 2 bits in RM (thus for each instruction) and move these two into
> SVSTATE (thus global). Before doing this, few questions:
> 1. Do we have use for two bits freed in RM? Perhaps some specifiers can be
> simplified.

yes.  the 5-bit mode is terribly cramped. modes that should be possible
together (independently) are mutually-exclusive.  source/dest-zeroing
is mostly disabled (crippled). and there's no future expansion room.

> 2. Do we have a real need in vec2/vec3/vec4 at all? If it can be emulated
> and emulation is cheap and/or this is a rarely used functionality, I'd
> simply drop it.

in GPU code and in vector pack/unpack it is incredibly useful.  imagine
being able to "unzip" RGB data, process it, then "zip" it back up again.
like this:

   https://libre-soc.org/openpower/sv/load-store.svg

so although the data (from memory or registers doesn't matter which)
could be R G B R G B you actually want to process all Rs together,
process all Gs together, process all Bs together, so UNPACK with
a vec3 will do precisely that: grab all R R R R R in sequence
grab all G G G G G in sequence grab all B B B B B in sequence.

VSX *only* has dual (twin) pack/unpack.  it does *not* have 3-wide
and it does not have 4-wide.  vpkss.  they're fixed size only.
basically back around 2003 when screens were 15-bit RGB, IBM added some
hard-coded instructions to cope with that. then things moved on...

-- 
You are receiving this mail because:
You are on the CC list for the bug.