[Public WebGL] Rendering to HDR displays (10bits per color component)

Geoff Lang [email protected]
Fri Jul 13 11:44:03 PDT 2018


ANGLE is capable of creating swap chains with D3D11 using
DXGI_FORMAT_R16G16B16A16_FLOAT and DXGI_FORMAT_R10G10B10A2_UNORM for HDR
displays, we had to support this for HDR video output in Chrome.  There is
also ARB_color_buffer_float for desktop GL which adds floating point
backbuffer formats to WGL and GLX but I'm not sure about the guarantees on
how these are composited.

On Fri, Jul 13, 2018 at 2:35 PM Ken Russell <[email protected]> wrote:

> I'm not 100% sure how this is implemented nor on what platforms. The folks
> on [email protected] will know. My understanding is that it's on
> Windows (using D3D under the hood) and Android, and possibly macOS. On each
> of these platforms I believe that a platform-specific GPU memory buffer is
> allocated with a higher bit depth, it's bound to an OpenGL texture using
> platform-specific APIs, and ultimately presented to the window system's
> compositor again using platform-specific APIs.
>
> -Ken
>
>
> On Fri, Jul 13, 2018 at 11:30 AM Florian Bösch <[email protected]> wrote:
>
>> Afaik you cannot create a float16 frontbuffer with OpenGL because WGL's
>> setPixelFormat function does not support a type argument (only the
>> bitplanes) but from that it cannot infer what kind of buffer you where
>> meant to have (other than an integer one).
>>
>> It looks like you could in theory create a float16 frontbuffer with
>> Direct3Ds DXGI_SWAP_CHAIN_DESC which supports the format argument of the
>> type DXGI_FORMAT_R16G16B16A16_FLOAT. I have no idea what the hardware
>> support for that is, or if it even works at all as intended.
>>
>> On Fri, Jul 13, 2018 at 8:13 PM, Ken Russell <[email protected]> wrote:
>>
>>> Please do post to [email protected] . The folks working on HDR
>>> support are on that list, but not on this one.
>>>
>>> -Ken
>>>
>>>
>>> On Fri, Jul 13, 2018 at 11:09 AM Javi Agenjo <[email protected]>
>>> wrote:
>>>
>>>> Thanks Ken!, great news then, I will keep an eye on the status.
>>>>
>>>> Cheers
>>>>
>>>> On Fri, Jul 13, 2018 at 7:36 PM, Ken Russell <[email protected]> wrote:
>>>>
>>>>> Yes! There's work underway to support an HDR back buffer for the WebGL
>>>>> rendering context. The current proposed API is here:
>>>>>
>>>>> https://github.com/WICG/canvas-color-space/blob/master/CanvasColorSpaceProposal.md
>>>>>
>>>>> Color spaces and profiles are a complex topic (and I'm no expert) but
>>>>> my understanding is that the initial switch is to be able to allocate a
>>>>> float16 back buffer for WebGL. The browser will then assume responsibility
>>>>> for presenting that to the screen. The colorspace will, I think, be
>>>>> extended sRGB.
>>>>>
>>>>> I've heard from a co-worker who's actively working in this area that
>>>>> they have HDR output coming out of WebGL on an HDR monitor.
>>>>>
>>>>> Not sure of the standardization / shipment status of this. To
>>>>> understand the current status in Chrome, please sign up for this group and
>>>>> post to it:
>>>>> https://groups.google.com/a/chromium.org/forum/#!forum/graphics-dev
>>>>>
>>>>> -Ken
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 12, 2018 at 2:48 AM Javi Agenjo <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi:
>>>>>>
>>>>>> Now that Chrome supports HDR video rendering (in Windows 10) with
>>>>>> 10bits per color (using the VP9 Profile 2 10-bit) I was wondering if there
>>>>>> would be any changes that we can instantiate a WebGL Context that has more
>>>>>> than 8bits per color component, now that HDR displays are starting to roll
>>>>>> out commercially.
>>>>>>
>>>>>> Sorry if this topic has been brought before or if this feature is
>>>>>> already supported, but I did my research and couldnt find anything.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20180713/d0154a12/attachment.html>


More information about the public_webgl mailing list