Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.arch
Subject: Re: Misc: Applications of small floating point formats.
Date: Mon, 5 Aug 2024 01:20:22 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <v8p9cl$ai44$2@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>
	<v8ot42$8n7n$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 05 Aug 2024 03:20:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9703e35b9105f1543e11e482bcc52d23";
	logging-data="346244"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18bi7FrCHpUU7Fhc7+v7atW"
User-Agent: Pan/0.159 (Vovchansk; )
Cancel-Lock: sha1:TZWPA/xfvKDsS2j5h3t1gRA3dq8=
Bytes: 4004

On Sun, 4 Aug 2024 16:50:50 -0500, BGB wrote:

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

There is a definite line of evolution OpenGL → OpenGL ES → Vulkan.

The original OpenGL had a fixed-function pipeline with a fixed number of 
lights and material characteristics and so on.

Then later “shaders” were introduced, written in a special language 
(GLSL), so that you could define your lighting and materials how you 
liked. (I think the idea of a shader language originated with Pixar’s 
RenderMan.)

Then OpenGL ES got rid of the old fixed-function pipeline, and required 
you to use the shader functionality. Interesting that GL ES 2.0 (and 
later) was not backward-compatible with GL ES 1.x in this regard.

And of course Vulkan takes the whole idea to its logical conclusion.

On the downside, it makes things harder for the newbie wanting to learn 
about all this stuff. Luckily, the old OpenGL APIs haven’t completely gone 
away (yet), so you can still start your learning on the fixed-function 
pipeline, then add some shaders, then once you are proficient in those, 
you can drop the fixed-function training wheels and take flight.

> 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).

Blender does its entire GUI with OpenGL, and the minimum version it 
requires is 4.3 nowadays.

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

That’s how things used to be done, back in the 1990s or so. Then it was 
realized that the graphics card vendors really only needed to worry about 
3D acceleration, because the 3D APIs worked perfectly well for 2D work. I 
think it was Apple than pioneered this idea in OS X, though it was very 
quickly adopted by other platforms.

> Nothing is stopping them from being used for offline rendering.

They are not really best thought of as “rendering” APIs, they are just 
“drawing” APIs.