Re: Byte Addressability And Beyond

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.
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).
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).
So, mostly falls into a similar category as 96 kHz / 24-bit audio; or monitor refresh rates like 120 or 240 Hz. It all seems pretty moot as there is no perceptible difference.
Say, 44.1 16-bit is basically peak (usable) audio quality, and 60Hz is fine (admittedly, it could probably be 30Hz and I am not sure I would notice).
But, some things I do notice, like if a show uses 11kHz or 16kHz audio for most of the background music and sound-effects, I will notice this (well, along with cases where sound effects were seemingly yanked from Doom/Quake/Half-Life/etc...).
In misc news:
In my project, got around to getting preemptive multitasking working in TestKern, mostly because my attempt at a text editor was locking everything up in GUI mode for what seemed (to me) like a pointlessly minor issue (the structure of the input handling loop wasn't right, so it effectively ended up never yielding).
This was enough to push me into actually making it work.
Though, I ended up doing it with two stages:
* It will first start trying to preempt at a system call if it has been running more than 50ms;
* If it reaches 150ms and still hasn't yielded, it will be rescheduled on the next timer interrupt.
Rescheduling at a system call was preferable:
Comparably less added overhead, as we would have been performing a task switch here either way;
Likely to be safer than rescheduling at an arbitrary location in the program, as most ordering sensitive events are unlikely to have a system-call right in the middle.
But, this time, I have it working and it isn't resulting in a bunch of crashing and instability, so this is a benefit.
It did originally result in keyboard-input issues after launching programs in the shell, but this is because at present the shell doesn't wait for the program to terminate before returning to the command-line; but, with preemptive scheduling, the shell was actually running, and it spinning in the relevant "gets()" loop was eating the keyboard inputs before the program could get to them (sort of hacked over it for the time being, namely that if the text-console is disabled and the task is not assigned to a virtual console/terminal, then the "gets()" will instead just sleep).
Where, say, the idea is that tasks may be assigned to a virtual terminal (or "vtty"), given as an internal handle number. In GUI mode, a vtty exists for each of the tabs in the terminal window, but in normal text mode, it is merely assigned to '0', which represents the text-mode console.
Better though would be for the shell to wait for the launched program to finish running (indirectly, this is what happened originally, but got broke when multiple tasks were added, and the console got moved into a task which effectively uses a "CreateProcess();" haven't really gotten it fixed...).
Though, FWIW, this is generally the behavior Windows uses when launching GUI programs via the CMD shell, so isn't too unheard of (even though, on traditional Unix style shells, one needs "program &" for this to happen, default behavior being for the shell to block until the called program terminates).
...