Re: Misc: Applications of small floating point formats.

On 8/2/2024 7:18 PM, Chris M. Thomasson wrote:

On 8/2/2024 5:07 PM, Lawrence D'Oliveiro wrote:

On Fri, 2 Aug 2024 03:56:35 -0500, BGB wrote:
>

For batch rendering, it doesn't really need to be efficient though.

>
Of course it does. Ray-traced renderers can compute hundreds or thousands
of rays per pixel, taking anywhere from minutes to hours per frame. This
is how you produce those cinema-quality 4K (or even 8K) frames. Anything
that can shave a little bit off the time for a single ray computation can
very quickly add up.
>

General strategy would be to setup a context, render to the context, and
then fetch the rendered image using glReadPixels or similar.
>
The "glReadPixels()" function is not exactly new...

>
Almost verging on useless, in my (albeit limited) tests. OpenGL, Vulkan
and the like are targeted towards on-screen rendering, and that’s what you
should stick to using them for.
>
Don’t confuse this with the fact that programmable GPUs are adaptable to
run SIMD-oriented compute APIs like OpenCL/SYCL (and their proprietary
rivals), and that these are commonly used to implement high-quality
offline renderers like those I mentioned above. These have nothing to do
with OpenGL.

 Taking a screen shot? glReadPixels is okay, right?

Yes, basically, this is the idea.
Render whatever you need, fetch the drawn pixels, set up and render whatever else, etc.
You can get clever, and render only to fetch and load the image into a texture and render something else with the texture.
Around the time of OpenGL 3.0, they added FBO's (FrameBuffer Objects), which allowed rendering directly into a texture without needing to use glReadPixels followed by glTexImage2D.
Though, I wasn't talking about these, as these didn't exist in the OpenGL 1.x era (when shows like ReBoot and similar were being made).
...