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

[Luke Kenneth Casson Leighton]

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?


>
>
> 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?
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?

I like 16 bit colour for embedded scenarios.

Also will 8 bit FP work? If not i suggest we skip 8bit FP entirely




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68