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

Luke Kenneth Casson Leighton lkcl at lkcl.net
Mon Dec 17 04:09:22 GMT 2018

On Monday, December 17, 2018, Jacob Lifshay <programmerjake at gmail.com>

> 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

More information about the libre-riscv-dev mailing list