Path: ...!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: Misc: Applications of small floating point formats.
Date: Sun, 4 Aug 2024 16:50:50 -0500
Organization: A noiseless patient Spider
Lines: 224
Message-ID: <v8ot42$8n7n$1@dont-email.me>
References: <v8ehgr$1q8sr$1@dont-email.me> <v8eloq$1qs1a$1@dont-email.me>
 <v8flo3$23t8l$1@dont-email.me> <v8h4iv$2e5g0$4@dont-email.me>
 <v8h8hv$2epjk$1@dont-email.me> <v8hg7p$2k3mm$1@dont-email.me>
 <v8hok5$2lec3$1@dont-email.me> <v8hruh$2m1tt$1@dont-email.me>
 <v8hv6d$2mklf$1@dont-email.me> <v8i709$2o7ho$1@dont-email.me>
 <v8jsbj$32llf$3@dont-email.me> <v8k2ld$37juv$1@dont-email.me>
 <v8kfcu$39ic7$2@dont-email.me> <v8ko4j$3br9u$1@dont-email.me>
 <v8m6up$3kkjg$2@dont-email.me> <v8m803$3k5d7$2@dont-email.me>
 <v8mv6l$3t1j0$2@dont-email.me> <v8oh4r$68n2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 04 Aug 2024 23:50:59 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c32050a719119dc254c8037f903ff5f9";
	logging-data="285943"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/zM7VeokQo0ND/V5urt4pJepgVkyFSqZc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MfPU0bdxICbBCUdk5gYCDJ4Cc1I=
Content-Language: en-US
In-Reply-To: <v8oh4r$68n2$1@dont-email.me>
Bytes: 9975

On 8/4/2024 1:26 PM, Chris M. Thomasson wrote:
> On 8/3/2024 9:14 PM, Lawrence D'Oliveiro wrote:
>> On Sat, 3 Aug 2024 14:38:11 -0700, Chris M. Thomasson wrote:
>>
>>> On 8/3/2024 2:20 PM, Lawrence D'Oliveiro wrote:
>>>
>>>> On Sat, 3 Aug 2024 03:01:16 -0500, BGB wrote:
>>>>
>>>>> On 8/3/2024 12:32 AM, Lawrence D'Oliveiro wrote:
>>>>>
>>>>> But, what I am saying is, a lot of stuff doesn't need raytracing.
>>>>
>>>> Like I said, there are non-raytraced renderers inspired by video-game
>>>> engines. They don’t use OpenGL.
>>>
>>> They are becoming few and far between wrt the big titles, so to speak.
>>
>> No they aren’t. A well-known example is the “Eevee” renderer built into
>> Blender (alongside the ray-traced “Cycles” renderer).
> 
> I was referring to new state of the art games; they don't use OpenGL.
> 

Yeah.

For mainstream games, there has been a move away from both OpenGL and 
Direct3D towards Vulkan.

Arguably, in some ways Vulkan is "better" for high-end games on modern 
GPUs, but is a lot harder to use (the amount of work needed to get even 
basic rendering working is very high).

Similarly, some targets, such as Android and Raspbian, were using GLES2 
rather than OpenGL proper.


I have less immediate focus on Vulkan as it makes little sense in the 
absence of a high-end GPU. It would not make sense for a CPU based 
rasterizer or for a GPU with a fixed-function pipeline.




Contrast, OpenGL 1.x has a lower barrier to entry; and makes some sense 
as a more general purpose graphics API (can also be used for GUI and 
other things).

Though, yes, this includes keeping a lot of the stuff that was 
deprecated in the later "Core Profile", which is seemingly much more 
focused on high-end gaming (and not so much on things relevant to "basic 
3D rendering" or UI).

Early on, there was also Glide, which could support an OpenGL subset via 
a wrapper. A lot of 90s era games (including Quake 1/2/3) were mostly 
targeted at this subset.

General priority I think is to have something like the "OpenGL 
Compatibility Profile".


Though, my implementation still left out some things that "pretty much 
no one uses" (such as Display Lists), and there is still some amount of 
stubs for non-used features.

Some other stuff hasn't really be well tested, such as GL_LIGHTING or 
GL_FOG (but, theoretically exists).


One can argue though that OpenGL is arguably a heavyweight option for 
general GUI rendering. An intermediate option could be an API more 
focused on 2D UI drawing tasks (with an aim to allow for a more 
efficient software implementation; allowing parts of the OpenGL pipeline 
to be sidestepped).


Though one design goal could be that (unlike the Windows GDI/User32 
stuff), such an API and OpenGL could freely interoperate, probably 
sharing the same context and buffers. Ideally, the API should be able to 
be implemented as a thin wrapper on top of OpenGL as well.


Beyond functionality covered by things like "glDrawPixels", could mostly 
have stuff related to drawing from textures into 2D rectangles.

Might make sense to provide something to draw a block of pixels into a 
2D rect using a BITMAPINFOHEADER or similar.

Say, hypothetically:
   tkxglEmitTexturedRect(
     float x0, float y0, float x1, float y1,
     float s0, float t0, float s1, float t1,
     float cr, float cg, float cb, float ca);
Which may sidestep GL if in the correct mode, else draws it as a 
rectangular polygon, though may delay drawing until later (allowing it 
to build an internal list of QUADs if needed). Will depend on the 
currently bound texture.
   tkxglFinishRects();
Draw any queued rects, at which point one is free to return to using 
OpenGL as normal.

Likely:
   tkxglBind(int target, int tex);
Wraps glBind, but may also emit QUADs if operating as a GL wrapper; 
needed mostly to allow operation as a wrapper.

May also provide special calls for setting up a 2D transform, so that 
the API knows it is in the correct mode for 2D drawing (projection set 
as glOrtho, MODELVIEW is either identity or a 2D translation, ...).

....

Would have to decide though whether to treat like a 2D extension API, or 
like a separate API that just so happens to overlap with GL (but would 
need to provide some amount of semi-redundant functionality, such as for 
uploading textures and similar).

Could maybe also provide for other UI-relevant things, like API calls 
for drawing text using OS provided fonts. And, stuff for drawing various 
sorts of UI widgets and dealing with user-input and input focus and similar.




At the moment, mostly working on getting TKRA-GL able to work with 
32-bit pixels.

Currently, this works by a mode change:
   Basic mode:
     Uses RGB555A for everything (framebuffer/textures);
     Uses a 16-bit Z-buffer (Z12.S4);
     Uses UTX2 for compressed textures;
     ...
   RGBA32 Mode:
     Uses RGBA32 for framebuffer and textures;
     Uses 32-bit Z-buffer (Z24.S8);
     Uses UTX3 for compressed textures;
     ...

Could then add an HDR32 mode:
   Basically RGBA32 Mode, but with FP8U texels and modified blending ops.

While quality will be worse in the Basic Mode, it will still have the 
advantage (why I went this route originally) of using less memory 
bandwidth and being faster.

Current approach is that the mode will be a global setting for the GL 
context, mostly for sake of "implementation sanity" (while, say, RGB555 
and UTX2 textures could still make sense in RGBA32 mode, it means more 
code paths to deal with for now).

Similarly, the HDR32 mode will convert everything over to FP8U 
internally (say, when one tries to upload an LDR texture, it will be 
auto-converted). Similar when trying to upload DXT1 or DXT5 (they will 
be converted and mapped to 0.0 to 1.0 range).



For sake of HDR32 mode, could consider allowing FP8U images to be drawn 
via TKGDI, would just sort of need to come up with a good way to express 
it in the "BITMAPINFOHEADER" structure.

I guess, one possibility:
   biCompression: "hdru";
   biBitCount: 32;
   biClrUsed: Repurposed as an HDR gamma-adjust vector (2x Binary16).
   biClrImportant: Reserved / MBZ.

Where, pixel transfer is:
   Temp = FP8U RGB * GammaScale + GammaBias;
   With the values between 0.0 and 1.0 mapped to the LDR range
     (ye olde RGB555).
========== REMAINDER OF ARTICLE TRUNCATED ==========