HDR/EDR frame buffer best practices?

[framkant]

Hi (and thanks for a great toolkit!), I am trying to get EDR/HDR rendering working on a small app but can't get my head around how it is supposed to work when using sokol. I dev on Mac(but the goal is cross platform) and when using Metal + GLFW I have old code where I achieved HDR/EDR rendering like this:

`
NSWindow *nswin = glfwGetCocoaWindow(window);

CAMetalLayer *layer = [CAMetalLayer layer];
layer.device = device;
layer.pixelFormat = MTLPixelFormatRGBA16Float;// std is MTLPixelFormatBGRA8Unorm;
const CFStringRef name = kCGColorSpaceExtendedLinearDisplayP3;
CGColorSpaceRef colorspace = CGColorSpaceCreateWithName(name);
layer.colorspace = colorspace;
nswin.contentView.layer = layer;
nswin.contentView.wantsLayer = YES;
layer.wantsExtendedDynamicRangeContent = YES;
`

But no code similar to this is available anywhere in sokol as far as I can tell so I assume I have to add/hack it myself? If so, is there any recommended ways to approach it?

[floooh]

Can't be much of a help with this there unfortunately, I haven't tinkered with HDR framebuffers yet.

Currently sokol_app.h is using MTKVIew instead of managing a CAMetalLayer directly (however that's going to change at some point), that's probably the reason why you didn't find the above CAMetalLayer configuration, I'm not sure if MTKView exposes settings to configure a HDR framebuffer (from quickly looking at the docs it doesn't look like it).

[framkant]

Ok, thanks for a super quick answer. I had a look around and it seems you might be able to get the layer from the MTKView . However to have it play nice there is also some other places to change code in sokol_glue and sokol_app that is hardcoded to return BGR8 . (like "sapp_color_format()" etc )

Anyway: adding it as a quick hack like this:
`

    _sapp.macos.view.colorPixelFormat = MTLPixelFormatBGRA8Unorm;
    _sapp.macos.view.depthStencilPixelFormat = MTLPixelFormatDepth32Float_Stencil8;
    _sapp.macos.view.sampleCount = (NSUInteger) _sapp.sample_count;
    _sapp.macos.view.autoResizeDrawable = false;
    _sapp.macos.window.contentView = _sapp.macos.view;
    [_sapp.macos.window makeFirstResponder:_sapp.macos.view];
    _sapp.macos.view.layer.magnificationFilter = kCAFilterNearest;

     if (_sapp.desc.edr) {
        _sapp.macos.view.colorPixelFormat = MTLPixelFormatRGBA16Float;
        CAMetalLayer* metalLayer = (CAMetalLayer*)_sapp.macos.view.layer;
        metalLayer.colorspace = CGColorSpaceCreateWithName(kCGColorSpaceDisplayP3);
        metalLayer.wantsExtendedDynamicRangeContent = YES;
        _sapp.edr = true;
    }
    else {
        _sapp.edr = false;
    }

`

Does indeed make the window into some kind of EDR.

Together with setting color and depth format for env and swap like so:

`

   // Init
   ...
    sg_environment env = sglue_environment();
    env.defaults.color_format = SG_PIXELFORMAT_RGBA16F;
    env.defaults.depth_format = SG_PIXELFORMAT_DEPTH_STENCIL;
    sg_setup(&(sg_desc){
       .environment = env,
        .logger.func = slog_func,
    });

   // frame
   ...
   sg_swapchain chain = sglue_swapchain();
   chain.color_format = SG_PIXELFORMAT_RGBA16F;
   chain.depth_format = SG_PIXELFORMAT_DEPTH_STENCIL;
   sg_begin_pass(&(sg_pass){ .action = app_state.pass_action, .swapchain = chain });

`
Gives me the wanted results.

The question then mostly becomes: would you consider adding this into the API in some way?

I tested (as seen) by just adding in the option in the descriptor in a similar way as for "high_dpi" and then just set a 16F format as default EDR. The issue is of course that I have no idea how one would do this on DX11, webgpu or linux OpenGL.
But I do think this is not unreasonable:

`

SOKOL_API_IMPL int sapp_color_format(void) {
#if defined(SOKOL_WGPU)
    switch (_sapp.wgpu.render_format) {
        case WGPUTextureFormat_RGBA8Unorm:
            return _SAPP_PIXELFORMAT_RGBA8;
        case WGPUTextureFormat_BGRA8Unorm:
            return _SAPP_PIXELFORMAT_BGRA8;
        default:
            SOKOL_UNREACHABLE;
            return 0;
    }
#elif defined(SOKOL_METAL) || defined(SOKOL_D3D11)
    if(_sapp.edr )return _SAPP_PIXELFORMAT_RGBA16F;
    return _SAPP_PIXELFORMAT_BGRA8;
    
#else
    return _SAPP_PIXELFORMAT_RGBA8;
#endif
 }

`

[floooh]

sokol_app.h generally needs to be more configurable when it comes to the framebuffer, so far I had the following things on the list:

• request SRGB versus RGB frame buffer
• configure depth-stencil-buffer (e.g. none vs depth-only vs depth-stencil)

HDR/EDR support would be an extension of that list

[tettou771]

+1 for this feature!

I'd also love to see 10-bit support (RGB10A2) for swapchain, not just HDR16F.

For creative/visual applications, 10-bit output significantly reduces banding artifacts in gradients - even without full HDR. Many displays now support 10-bit, and it would be great to take advantage of that.

Looking forward to the framebuffer configuration improvements!

[floooh]

I did some more preparations for that in the experimental Vulkan update (e.g. sokol_app.h now has a sapp_pixel_format type which isn't used much yet though - but eventually this will be used in sapp_desc to setup the framebuffer pixel formats (and also finally allow to setup the sokol-app swapchain without depth- or stencil-buffer). Not sure yet how portable any HDR features will be though, and in any case the first step would be proper SRGB support.