[libre-riscv-dev] evaluation of bit-witdh scoreboards

[Jacob Lifshay]

On Sun, Dec 16, 2018 at 8:10 PM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Monday, December 17, 2018, Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> >
> > const uint8_t encode_sRGB_lut[1 << 12] = {...};
> > const float decode_sRGB_lut[1 << 8] = {...};
> >
> >
> Are these ROM or SRAM?
>
ROM, hence the const. since the decode_sRGB_lut is accessed several tens of
times per texture lookup, we need that part to be parallelized to 4x
per-clock or more. The encode table is accessed several times per pixel, so
we can probably get away with 1x or 2x per-clock.

>
>
> >
> >
> > The simplest texture read operations are basically several decode_sRGB or
> > decode_u8 calls then interpolation
>
>
> It looks very reasonable, very parallelisable.
>
>
> >
> > Since we're processing several pixels simultaneously, we need to
> vectorize
> > by an additional factor of 4*N
> >
> >
> no need for individual 8bit i take it. Can we do a 16 bit version as well?
>
Supporting 8/16/24-bit framebuffers/textures with 8-bit components is
required but they have reduced component counts (R, RG, RGB).

For the full list of required formats, see
https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#features-required-format-support

Or is it easier to post convert, or, is the A of ARGB a necessity,
> accumulating opacity at the pixel level, during z buffer buildup?
>

Supporting RGBA framebuffers is necessary. Most programs would use either
RGBA with the A channel being significant, or RGBA with the A channel being
ignored after blending (which happens before conversion to 8-bit per
channel).

>
> I like 16 bit colour for embedded scenarios.
>
I forgot to mention the R5G6B5 and R5G5B5X1 formats, they are very similar
to encode_u8/decode_u8.

>
> Also will 8 bit FP work? If not i suggest we skip 8bit FP entirely
>
We will never need 8-bit FP unless we think it will be useful for neural
networks or something. I would suggest leaving it out of the hw completely
but leaving space in the ISA to encode for it should we need it in the
future.

Jacob