Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Byte Addressability And Beyond
Date: Sun, 5 May 2024 02:41:30 -0500
Organization: A noiseless patient Spider
Lines: 100
Message-ID: <v17d7d$1o5mm$1@dont-email.me>
References: <v0s17o$2okf4$2@dont-email.me>
 <2024May3.171330@mips.complang.tuwien.ac.at> <v13olm$p9ih$9@dont-email.me>
 <v144s1$1r3q$1@gal.iecc.com> <v1491h$10fkm$1@dont-email.me>
 <v14lfr$12s06$3@dont-email.me> <v168k8$1der7$1@dont-email.me>
 <59dc9467ddadd2cdabd06f3f05049823@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 05 May 2024 09:41:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cc08dcaf13314637553bde0ccb7c7647";
	logging-data="1840854"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19fpD9aF2wxEJ4bjTXGXudIMe6ZXY1sZAs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:OS9HdACwDizIPz2CEhSlRdRBL7A=
In-Reply-To: <59dc9467ddadd2cdabd06f3f05049823@www.novabbs.org>
Content-Language: en-US
Bytes: 5127

On 5/4/2024 7:11 PM, MitchAlsup1 wrote:
> BGB wrote:
> 
>> On 5/4/2024 1:44 AM, Lawrence D'Oliveiro wrote:
>>> On Fri, 3 May 2024 22:11:44 -0500, BGB wrote:
>>>
>>>> Not a huge use-case in graphics, as noted, in most cases this is done
>>>> with 16 or 32 bit pixels; and bit-plane graphics are long since dead.
>>>
>>> What happens if we go beyond 32 bits? For example, hardware might
> support
>>> 10 bits per pixel component.
> 
>> A few typical formats:
>>    RGB555: 0rrrrrgg-gggbbbbb
>>    RGBA32: aaaaaaaa-rrrrrrrr-gggggggg-bbbbbbbb
>>    RGB30 : 00rrrrrr-rrrrgggg-ggggggbb-bbbbbbbb  (10-bit component RGB)
> 
>> Though, for RGB30, there are variants with 10-bit linear RGB, and 
>> E5.F5 floating-point (sometimes used for HDR in OpenGL, as opposed to 
>> 4x Binary16).
> 
>> None of these would really benefit from bit addressable memory though.
> 
> Nor are they serviced by any SIMD ISA.
> 


Converter ops can make it work...

For working with RGB555, Pack/Unpack ops and SIMD are still a lot faster 
than using a bunch of shift-and-mask...



>> Though, for LDR, going beyond 8-bit color depth doesn't gain much even 
>> if the monitor supports it natively. And had noted before when using a 
>> cheap LCD TV as a monitor, that it only seemed to be working at a 
>> roughly 6-bit color depth (like, it was seemingly slightly better than 
>> RGB555, but not by much).
> 
> Most people's eyes cannot even see the difference unless it is pointed
> out to them.
> 

If you mean, cheap LCD TV being ~ 6 bit.

Yeah, pretty much, was still plenty usable, though slightly annoying 
when doing graphics editing tasks.


Apparently also a lot of VGA and SVGA cards had 6 bit DAC's, so one was 
only actually getting ~ 6-bit/component depth in TrueColor modes.

And, also, similar for a lot of early LCD monitors.
To some extent, 16M colors was a lie, it was more like 256K colors.

But, it was "good enough" that most people didn't notice (wheres, with 5 
or 4 bits, they would have noticed).


>> Now I am using a 4K OLED, which does support 10b/component, but it 
>> doesn't make much difference in practice (and even if it did, most 
>> software wont make much use of it).
> 
>> But, say, 5 to 8 bits per component is at least noticeable (better 
>> colors and less banding artifacts), 8 to 10 bits, not so much. Though, 
>> with the main exception being HDR (but then, over the 0.5 to 1.0 
>> range, E5.F5 is only about as accurate as a 6-bit component).
> 
> Posterization is still a problem at 8-bits.

I hadn't really noticed any issue at (true) 8 bits.

But, it is a bit more obvious at 5 bits.
But, RGB555 is half the size of RGBA32 / RGBA8888, and "mostly good 
enough" for many tasks (and ironically, RGB555 tends to be slightly 
preferable to 565 because 565 can't accurately recreate shades of gray, 
so a gray gradient will have alternating green and purple tinted bands...).


Generally, RGB555 is still a significant improvement over 256-color.

Like, no obvious "good" way to get good quality from 256 color.
One traditional option being 216 color (6*6*6 R*G*B), but, while it can 
be colorful, it does rather poorly with things like gradients or 
graphics dominated by light-vs-dark features (IOW: pretty much 
everything that isn't a UI element or cartoon drawing).

Had ended up with a 14 shades of 18 colors scheme, which trades off 
being worse for color fidelity, with being a lot better at gradients.

Then ended up encoding the palette and hicolor -> indexed tables as a 
256x256 bitmap (where, it is 256x256 rather than 256x128, mostly as to 
allow for dithering). And, storing this table because it takes an 
annoyingly long time to rebuild the lookup table from a color palette on 
a 50 MHz CPU.

....