[Libre-soc-bugs] [Bug 230] Video opcode development and discussion

[bugzilla-daemon at libre-soc.org]

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

--- Comment #49 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #46)
> Another note, there are highly likely to be pixel decoding/encoding
> load/stores

eek! really? :)  well... like in the oringinal POWER1 i don't mind too much if
that's done by micro-coding (LD goung straight into this new SR FSM), although
honestly the thought of fitting both LDST semantics and encoding schemes for
pixels *and* getting that into SV does not fill me with great glee :)

if they can be kept separate without there being a huge penalty for needing to
use large chunks of the regfile for the raw data that would be a relief.

> since those are needed for GPU framebuffer read/write, texture
> read, and format interconversion, see the Vulkan spec for the full list:
> https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/chap43.
> html#features-required-format-support
> 
> We are also planning on supporting planar and packed YUV formats.

okaay.  so that's a hell of a long list, including 4-bit RGB.  i think this is
where the shift-range-extract idea was stemming from: being able to get at
4-4-4 or 5-6-5 or 2-10-10-10 and throw them into  the individual elements of a
vec3 or vec4 (and back again).

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