Fixed
Status Update
No update yet.
Comments
jh...@chromium.org
[Empty comment from Monorail migration]
wt...@google.com
seawater4ever: Thank you for the bug report.
Dale: Could you please take a look at this? Thanks.
Dale: Could you please take a look at this? Thanks.
wt...@google.com
[Empty comment from Monorail migration]
ph...@chromium.org
As the owner of the issue is already available, changing the status to "Assigned".
kb...@chromium.org
[Empty comment from Monorail migration]
[Monorail components: Internals>GPU>Internals]
[Monorail components: Internals>GPU>Internals]
se...@gmail.com
wtc: You're welcome.
su...@chromium.org
This might be expected behavior since we don't do any tone mapping in Chrome.
Rafael: Does DWM do any tone mapping when rendering HDR swap chains on SDR displays?
Rafael: Does DWM do any tone mapping when rendering HDR swap chains on SDR displays?
kb...@chromium.org
During today's W3C ColorWeb community group meeting it was discovered that this code path was deliberately removed in https://crbug.com/chromium/1015599 . I suspect that the resolution of this bug will be WontFix - working as intended. Website authors need to query for HDR support and serve up the correct content.
ra...@microsoft.com
@Sunny, DWM does not do any tone mapping for HDR swap chains on SDR displays. That is the responsibility of the application.
Windows includes a tonemapper, which you're free to use if you wish. Seehttps://docs.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range for an overview of how to use it. This tonemapper is used by the picture viewer that's part of the Windows shell.
I sympathize with the bug reporter. While I do think the web browser, as a platform, should give web developers tools they need to pick images based on the characteristics of the display, not all content on the Internet is fully in control of the web page author. In those cases, the web browser should serve the same role as the picture view that's part of the OS.
Windows includes a tonemapper, which you're free to use if you wish. See
I sympathize with the bug reporter. While I do think the web browser, as a platform, should give web developers tools they need to pick images based on the characteristics of the display, not all content on the Internet is fully in control of the web page author. In those cases, the web browser should serve the same role as the picture view that's part of the OS.
su...@chromium.org
Rafael: Thanks for the pointer to the D2D tonemapper effect. Sounds promising, but something we'll have to prioritize for later.
liberato: c#9 FYI
liberato: c#9 FYI
da...@chromium.org
This is working as intended at least for now. We expect HDR images and video to only be served to HDR displays.
da...@chromium.org
Clients are expected to check for HDR support presence before sending HDR images.
Especially for HDR video, most content authors do not want to send a HDR clip that will automatically (with a huge variation in quality) mapped to SDR. They would instead prefer to send the SDR stream. The current approach follows the same expectation for images and video.
Especially for HDR video, most content authors do not want to send a HDR clip that will automatically (with a huge variation in quality) mapped to SDR. They would instead prefer to send the SDR stream. The current approach follows the same expectation for images and video.
da...@chromium.org
(I've marked the issue as available since patches welcome and all that, but we have no plans to implement a tone mapping algorithm at this time).
mg...@gmail.com
Having this be the responsiblity of the website (contrary to firefox) is a huge pain. It will force all websites to store two versions of a video. If a website cares (if it is relevant to their business) they can of course auto-detect and show it, but if a video player gets content it cannot show on the device it is configured to then it should do something sensible or refuse to play it.
mg...@gmail.com
This is especially an issue for CMS/DMS systems where users upload videos from e.g. iphones where the users don't know and don't care what format it is which now forces the CMS/DMS to tone-map into sRGB space. And while there are many different choices to be made a simple LUT to compress the range to sRGB is not that hard even if imperfect. Clients with higher fidelity requirements already check and will continue to do so.
su...@chromium.org
[gpu triage] Downgrading to P3 since we aren't actively working on it.
mg...@gmail.com
da...@chromium.org
[Empty comment from Monorail migration]
da...@chromium.org
[Empty comment from Monorail migration]
cc...@chromium.org
On macOS, HDR videos are tonemapped appropriately (using some OS-specific magic). It seems a bit odd not to support this on Windows and CrOS (using some cross-platform non-magic), and to also not support it for HDR photos.
Relatedly, HLG photos should use the full display capabilities of the output device (so, use the full SDR range, and not clip), which we currently don't do.
I have some thoughts on how and where to add this capability.
Relatedly, HLG photos should use the full display capabilities of the output device (so, use the full SDR range, and not clip), which we currently don't do.
I have some thoughts on how and where to add this capability.
fg...@google.com
Hi Chris, I agree we are going to have to address this issue better, so everyone can use HDR.
zm...@google.com
[Empty comment from Monorail migration]
[Monorail components: Internals>GPU>Video>HDR]
[Monorail components: Internals>GPU>Video>HDR]
al...@gmail.com
[Comment Deleted]
al...@gmail.com
I'm not understanding how one can expect a user to figure out that their videos being uploaded from their phone are HDR and that they will fail on their fairly recent monitors and laptops. i.e. the solution cannot be to go buy a HDR display.
How about just find a way to render HDR on a non HDR display? And also, why is it that Firefox can deal with it and Chrome cannot?
my 2 cents.
How about just find a way to render HDR on a non HDR display? And also, why is it that Firefox can deal with it and Chrome cannot?
my 2 cents.
da...@chromium.org
That was our expectation when HDR was effectively only premium content. We acknowledge that we now need a solution for user generated content.
al...@gmail.com
OK - good to hear dalec.. any idea on when this might make it into mainstream? 1, 2, 3, months? I only ask because we share content and a lot of people use chrome. thx
da...@chromium.org
Should already be fixed on macOS, other platforms will take a bit longer.
al...@gmail.com
OK thanks for that info dalec... and for getting this sorted. We're Windows 10 here.
sb...@google.com
It seems that an immediate improvement for HLG might be to simply interpret it as if it were an SDR signal if the display is SDR: after all, it was explicitly designed to make that approach yield acceptable results (albeit with some color shifts). Alternatively, if the brightness of the display is known or can be reasonably estimated, the “proper” OOTF is not too difficult to implement (and that should be done even for HDR displays anyway).
Taking “hdr_cosmos01650_cicp9-16-0_lossless.avif” from the Netflix repository as an example (https://raw.githubusercontent.com/AOMediaCodec/av1-avif/master/testFiles/Netflix/avif/hdr_cosmos01650_cicp9-16-0_lossless.avif ) and converting it to HLG, here is the result of those approaches. cosmos-hlg.avif contains the result of the HLG conversion, cosmos-hlg-sdr.jpg contains the result of keeping the same pixel values but assigning a profile with Rec. 2020 primaries and sRGB transfer function (which causes color shifts but no clipped highlights), and cosmos-hlg-{100,300,600,1000}.jpg contain the result of applying the OOTF for those target display luminances.
Taking “hdr_cosmos01650_cicp9-16-0_lossless.avif” from the Netflix repository as an example (
sb...@google.com
I just noticed that for HLG content, it seems to be the scene light that gets scaled to around 0-1000 cd/m² (?) without the OOTF applied, which means that HLG content would look too light even on a 1000 cd/m² HDR display, due to not having a gamma of 1.2 applied to its luminance.
If we compute the system gamma using the extended, luminance-invariant model (https://www.itu.int/pub/R-REP-BT.2390-9-2021 pages 28-29, https://www.itu.int/rec/R-REC-BT.2100-2-201807-I page 8, or https://www.bbc.co.uk/rd/publications/display-high-dynamic-range-images-varying-viewing-conditions pages 8-9), i.e. γ = 1.2 · 1.111^(log₂(Lw / 1000)) if ignoring surround luminance, we find that it’s for a peak luminance of approximately 300 cd/m² that γ=1. So, until the HLG OOTF is implemented in Chrome, perhaps the scaling should be to 0-300 cd/m² instead of 0-1000? As a bonus, it would map the reference level for diffuse white proposed in https://www.itu.int/pub/R-REP-BT.2408-4-2021 to just under 80 cd/m², so SDR displays would at least get to diffuse white before clipping.
If we compute the system gamma using the extended, luminance-invariant model (
da...@chromium.org
Current state of things:
- SDR tone mapping works on macOS Big Sur+
- SDR tone mapping works on Intel Icelake+ GPUs on Windows via VideoProcessorBlt interface.
SDR tone mapping doesn't work elsewhere. The options for implementing on Windows are:
- Wait for NVIDIA, AMD, or Microsoft to implement tone mapping via VideoProcessorBlt.
- Use Direct2D interface:https://docs.microsoft.com/en-us/windows/win32/direct2d/hdr-tone-map-effect and https://docs.microsoft.com/en-us/windows/win32/Direct2D/direct2d-and-direct3d-interoperation-overview (c#9)
Since we also want this to work on ChromeOS, Linux, and Android we likely still need our own tone mapper. One option is restoring the old path and getting it working with SkiaRenderer:
-https://chromium-review.googlesource.com/c/chromium/src/+/1913613
-https://chromium-review.googlesource.com/c/chromium/src/+/1982764
(The old path did what c#31 suggests for HLG content and something a bit more complicated for PQ)
@ccameron: You've indicated you have thoughts on what we should do here (c#21). What's your proposal?
- SDR tone mapping works on macOS Big Sur+
- SDR tone mapping works on Intel Icelake+ GPUs on Windows via VideoProcessorBlt interface.
SDR tone mapping doesn't work elsewhere. The options for implementing on Windows are:
- Wait for NVIDIA, AMD, or Microsoft to implement tone mapping via VideoProcessorBlt.
- Use Direct2D interface:
Since we also want this to work on ChromeOS, Linux, and Android we likely still need our own tone mapper. One option is restoring the old path and getting it working with SkiaRenderer:
-
-
(The old path did what c#31 suggests for HLG content and something a bit more complicated for PQ)
@ccameron: You've indicated you have thoughts on what we should do here (c#21). What's your proposal?
gi...@appspot.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/e8c942026a23b4af2e122318d1346c0bf4730f4b
commit e8c942026a23b4af2e122318d1346c0bf4730f4b
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Thu Nov 11 01:50:44 2021
Fix some of the things broken with SDR tone mapping on Windows.
This doesn't actually make HDR->SDR tone mapping work, but fixes a
couple of broken things:
- Setting Output HDRMetadata instead of Stream HDRMetadata from
SetStreamXXX function.
- Guessing 10-bit for 8-bit H264 HDR content, this fails initialization
entirely so D3D11VD never gets a chance to detect the right bit depth.
R=tmathmeyer
Bug: 1216691
Change-Id: I57b0884d3ecb93b60fb1d03507abf3ec01cd1cab
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/3268576
Reviewed-by: Ted Meyer <tmathmeyer@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#940609}
[modify]https://crrev.com/e8c942026a23b4af2e122318d1346c0bf4730f4b/media/gpu/windows/d3d11_video_decoder.cc
[modify]https://crrev.com/e8c942026a23b4af2e122318d1346c0bf4730f4b/media/gpu/windows/d3d11_video_processor_proxy.cc
commit e8c942026a23b4af2e122318d1346c0bf4730f4b
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Thu Nov 11 01:50:44 2021
Fix some of the things broken with SDR tone mapping on Windows.
This doesn't actually make HDR->SDR tone mapping work, but fixes a
couple of broken things:
- Setting Output HDRMetadata instead of Stream HDRMetadata from
SetStreamXXX function.
- Guessing 10-bit for 8-bit H264 HDR content, this fails initialization
entirely so D3D11VD never gets a chance to detect the right bit depth.
R=tmathmeyer
Bug: 1216691
Change-Id: I57b0884d3ecb93b60fb1d03507abf3ec01cd1cab
Reviewed-on:
Reviewed-by: Ted Meyer <tmathmeyer@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#940609}
[modify]
[modify]
da...@chromium.org
Using the VideoProcessor MFT on Windows is tricky. It only supports PQ and overlays. However, we currently don't support overlay of software decoded 10-bit videos -- adding support appears tricky and restoring the HLG as 2.2 change seems fairly easy for all platforms.
I'll keep looking at the VideoProcessor for PQ support.
https://chromium-review.googlesource.com/c/chromium/src/+/3297136
https://chromium-review.googlesource.com/c/chromium/src/+/3297063
Should make HLG content look reasonably on all platforms.
I'll keep looking at the VideoProcessor for PQ support.
Should make HLG content look reasonably on all platforms.
gi...@appspot.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/79b276ad13a9f78d854f013f5059683f674ea369
commit 79b276ad13a9f78d854f013f5059683f674ea369
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Wed Nov 24 03:15:23 2021
Treat HLG as GAMMA22 when D3D11VideoDecoder operates in SDR mode.
8bit HDR content is handled via the gfx::ColorTransform, but since
we can't seem to bind P010 in SDR mode (DCHECK in GrSurfaceProxy),
we still need the P010 -> BGRA copying path.
On the copying path we should treat HLG as GAMMA22 content when
the VideoProcessor lacks support for tone mapping to get reasonable
results.
R=liberato, tmathmeyer
Bug: 1216691
Change-Id: I2412b8099e6266af5f5f03740ea6fa96e60edebc
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/3299071
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Ted Meyer <tmathmeyer@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#944811}
[modify]https://crrev.com/79b276ad13a9f78d854f013f5059683f674ea369/media/gpu/windows/d3d11_video_processor_proxy.h
[modify]https://crrev.com/79b276ad13a9f78d854f013f5059683f674ea369/media/gpu/windows/d3d11_video_processor_proxy.cc
[modify]https://crrev.com/79b276ad13a9f78d854f013f5059683f674ea369/media/gpu/windows/d3d11_copying_texture_wrapper.cc
commit 79b276ad13a9f78d854f013f5059683f674ea369
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Wed Nov 24 03:15:23 2021
Treat HLG as GAMMA22 when D3D11VideoDecoder operates in SDR mode.
8bit HDR content is handled via the gfx::ColorTransform, but since
we can't seem to bind P010 in SDR mode (DCHECK in GrSurfaceProxy),
we still need the P010 -> BGRA copying path.
On the copying path we should treat HLG as GAMMA22 content when
the VideoProcessor lacks support for tone mapping to get reasonable
results.
R=liberato, tmathmeyer
Bug: 1216691
Change-Id: I2412b8099e6266af5f5f03740ea6fa96e60edebc
Reviewed-on:
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Ted Meyer <tmathmeyer@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#944811}
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/8b719230ffd41bd45b193861891049cadf924940
commit 8b719230ffd41bd45b193861891049cadf924940
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Wed Nov 24 03:24:12 2021
Restore SDR conversion for HLG content.
With the rise of consumer generated HDR content, the expectation
that HDR content will only be delivered to HDR displays is no
longer true. We should provide basic support for viewing HDR
content on SDR displays.
This restores gfx::ColorTransform behavior of treating HLG content
as gamma 2.2 (was 2.4 before, but literature suggests 2.2).
R=ccameron, sunnyps
Bug: 1216691
Change-Id: I73361f239a62d0c2c7f04a88e3a06da9abb9b6c2
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/3297136
Reviewed-by: ccameron <ccameron@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#944814}
[modify]https://crrev.com/8b719230ffd41bd45b193861891049cadf924940/ui/gfx/color_transform.cc
[modify]https://crrev.com/8b719230ffd41bd45b193861891049cadf924940/ui/gfx/color_transform_unittest.cc
commit 8b719230ffd41bd45b193861891049cadf924940
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Wed Nov 24 03:24:12 2021
Restore SDR conversion for HLG content.
With the rise of consumer generated HDR content, the expectation
that HDR content will only be delivered to HDR displays is no
longer true. We should provide basic support for viewing HDR
content on SDR displays.
This restores gfx::ColorTransform behavior of treating HLG content
as gamma 2.2 (was 2.4 before, but literature suggests 2.2).
R=ccameron, sunnyps
Bug: 1216691
Change-Id: I73361f239a62d0c2c7f04a88e3a06da9abb9b6c2
Reviewed-on:
Reviewed-by: ccameron <ccameron@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#944814}
[modify]
[modify]
gi...@appspot.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/0bf2df4e0810d1467e7f8c228a2956446fe60fe5
commit 0bf2df4e0810d1467e7f8c228a2956446fe60fe5
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Wed Nov 24 03:35:34 2021
Pass through HDR in D3D11VideoDecoder when tonemapping unsupported.
This lets gfx::ColorTransform handle the tonemapping when the
video processor can't do tonemapping.
Ideally we'd just bind P010 even when HDR is disabled, but this
triggers a CHECK inside of GrSurfaceProxy since it can't seem to
handle P010 textures in SDR mode.
R=liberato
Bug: 1216691
Change-Id: Ieb898cb4d4566191ad983aaa24eaae3163c5b932
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/3299433
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Frank Liberato <liberato@chromium.org>
Auto-Submit: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#944817}
[modify]https://crrev.com/0bf2df4e0810d1467e7f8c228a2956446fe60fe5/media/gpu/windows/d3d11_texture_selector.cc
[modify]https://crrev.com/0bf2df4e0810d1467e7f8c228a2956446fe60fe5/media/gpu/windows/d3d11_video_decoder.cc
[modify]https://crrev.com/0bf2df4e0810d1467e7f8c228a2956446fe60fe5/media/gpu/windows/d3d11_video_device_format_support.cc
[modify]https://crrev.com/0bf2df4e0810d1467e7f8c228a2956446fe60fe5/media/gpu/windows/d3d11_video_device_format_support.h
commit 0bf2df4e0810d1467e7f8c228a2956446fe60fe5
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Wed Nov 24 03:35:34 2021
Pass through HDR in D3D11VideoDecoder when tonemapping unsupported.
This lets gfx::ColorTransform handle the tonemapping when the
video processor can't do tonemapping.
Ideally we'd just bind P010 even when HDR is disabled, but this
triggers a CHECK inside of GrSurfaceProxy since it can't seem to
handle P010 textures in SDR mode.
R=liberato
Bug: 1216691
Change-Id: Ieb898cb4d4566191ad983aaa24eaae3163c5b932
Reviewed-on:
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Frank Liberato <liberato@chromium.org>
Auto-Submit: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#944817}
[modify]
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/0f8348d1fa4098dc69732af644818a003144b0fd
commit 0f8348d1fa4098dc69732af644818a003144b0fd
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Wed Nov 24 03:37:40 2021
Treat HLG images as 2.2 gamma on SDR displays.
This dramatically improves the quality of these images and is a
simple fix until real tone mapping can be provided.
Bug: 1216691
Change-Id: I8bde11bf4649f46115775d45472c099489b25a1b
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/3297063
Reviewed-by: ccameron <ccameron@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#944819}
[modify]https://crrev.com/0f8348d1fa4098dc69732af644818a003144b0fd/cc/tiles/gpu_image_decode_cache.cc
[modify]https://crrev.com/0f8348d1fa4098dc69732af644818a003144b0fd/cc/paint/paint_image.h
[modify]https://crrev.com/0f8348d1fa4098dc69732af644818a003144b0fd/cc/paint/paint_image.cc
commit 0f8348d1fa4098dc69732af644818a003144b0fd
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Wed Nov 24 03:37:40 2021
Treat HLG images as 2.2 gamma on SDR displays.
This dramatically improves the quality of these images and is a
simple fix until real tone mapping can be provided.
Bug: 1216691
Change-Id: I8bde11bf4649f46115775d45472c099489b25a1b
Reviewed-on:
Reviewed-by: ccameron <ccameron@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#944819}
[modify]
[modify]
[modify]
gi...@appspot.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/ee8d2a0289ed5df7dd01734f64091a9cf5d53d16
commit ee8d2a0289ed5df7dd01734f64091a9cf5d53d16
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Wed Nov 24 21:42:47 2021
Restore PQ tonemapping support to gfx::ColorTransform.
This restores the code from prior tohttps://crrev.com/727611 and
updates it to work with SkiaRenderer. The results are good, but it
does introduce banding.
R=ccameron
Bug: 1216691
Change-Id: I242e7adb5eebc9daeb225756c018ed6badb0c8d1
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/3299365
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#945126}
[modify]https://crrev.com/ee8d2a0289ed5df7dd01734f64091a9cf5d53d16/ui/gfx/color_transform.cc
[modify]https://crrev.com/ee8d2a0289ed5df7dd01734f64091a9cf5d53d16/ui/gfx/color_transform_unittest.cc
[modify]https://crrev.com/ee8d2a0289ed5df7dd01734f64091a9cf5d53d16/components/viz/service/display/skia_renderer.cc
[modify]https://crrev.com/ee8d2a0289ed5df7dd01734f64091a9cf5d53d16/components/viz/service/display/renderer_pixeltest.cc
commit ee8d2a0289ed5df7dd01734f64091a9cf5d53d16
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Wed Nov 24 21:42:47 2021
Restore PQ tonemapping support to gfx::ColorTransform.
This restores the code from prior to
updates it to work with SkiaRenderer. The results are good, but it
does introduce banding.
R=ccameron
Bug: 1216691
Change-Id: I242e7adb5eebc9daeb225756c018ed6badb0c8d1
Reviewed-on:
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#945126}
[modify]
[modify]
[modify]
[modify]
da...@chromium.org
Okay, we have something in place now for everything except PQ images on SDR displays. HLG/PQ video will tone map to something okay on SDR displays and HLG images will be treated as GAMMA22. I'm not sure there's an easy fix for PQ images on SDR without applying the tone map during decoding, but I'll keep looking.
da...@chromium.org
Whoops, actually due to 0f8348d1fa4098dc69732af644818a003144b0fd, PQ images are treated as GAMMA22 as well... which is definitely not great, but looks worlds better than no treatment, so I'll leave that for now.
da...@chromium.org
[Empty comment from Monorail migration]
da...@chromium.org
[Empty comment from Monorail migration]
wp...@gmail.com
#43 no, https://bugs.chromium.org/p/chromium/issues/detail?id=1284655 is a different issue than this one. I tried Chrome 98 beta and the issue is still there using the D3D11 Angle backend. The issue is not there with the D3D11on12 backend. The issue happens in SDR and in HDR modes. I can do another video to show it in Chrome 98, if you want.
gi...@appspot.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e
commit b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e
Author: Christopher Cameron <ccameron@chromium.org>
Date: Mon May 02 18:11:00 2022
Windows HDR: Plumb DXGIInfo instead of boolean
Change DirectCompositionSurfaceWin::IsHDRSupported to instead be the
function GetDXGIInfo. This will return in a gfx::mojom::DXGIInfo the
list of the DXGI_OUTPUT_DESC1 for all IDXGIOutputs on all
IDXGIAdapters. This information includes the maximum luminance, along
with per-output HDR capability.
Plumb this all the way through to GpuDataManagerImplPrivate to
ScreenWin::SetDXGIInfo.
Use the resulting data to compute an appropriate HDR relative maximum
luminance.
Merge the Windows and macOS code for computing the minimum HDR relative
maximum luminance code into a common constant,
kMinHDRCapableMaxLuminanceRelative.
Bug: 1299293, 1216691
Change-Id: I4ec8e78d35bc994c474fd516588b509df756eda2
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/3617146
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/main@{#998452}
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/ui/gfx/mojom/BUILD.gn
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/services/viz/privileged/mojom/gl/BUILD.gn
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/gpu/ipc/service/gpu_channel_test_common.cc
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/media/mojo/services/BUILD.gn
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/ui/gl/BUILD.gn
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/gpu/ipc/service/gpu_channel_manager_delegate.h
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/services/viz/privileged/mojom/gl/gpu_service.mojom
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/content/browser/gpu/gpu_process_host.cc
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/ui/display/BUILD.gn
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/services/viz/privileged/mojom/gl/gpu_host.mojom
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/ui/display/win/screen_win.cc
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/components/viz/host/gpu_host_impl.h
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/content/browser/gpu/gpu_data_manager_impl_private.cc
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/content/browser/gpu/gpu_data_manager_impl.h
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/components/viz/host/gpu_host_impl.cc
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/content/browser/gpu/gpu_process_host.h
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/media/mojo/services/gpu_mojo_media_client_win.cc
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/ui/display/mac/screen_mac.mm
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/ui/display/win/screen_win.h
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/content/browser/gpu/gpu_data_manager_impl.cc
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/ui/display/types/display_constants.h
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/components/viz/service/gl/gpu_service_impl.cc
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/ui/gl/direct_composition_surface_win.cc
[add]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/ui/gfx/mojom/dxgi_info.mojom
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/components/viz/host/host_gpu_memory_buffer_manager_unittest.cc
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/content/browser/gpu/gpu_data_manager_impl_private.h
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/content/browser/gpu/peak_gpu_memory_tracker_impl_browsertest.cc
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/components/viz/service/gl/gpu_service_impl.h
[modify]https://crrev.com/b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e/ui/gl/direct_composition_surface_win.h
commit b3ae6ff48c691df693cf0bfce6e16bd1cbc2cf3e
Author: Christopher Cameron <ccameron@chromium.org>
Date: Mon May 02 18:11:00 2022
Windows HDR: Plumb DXGIInfo instead of boolean
Change DirectCompositionSurfaceWin::IsHDRSupported to instead be the
function GetDXGIInfo. This will return in a gfx::mojom::DXGIInfo the
list of the DXGI_OUTPUT_DESC1 for all IDXGIOutputs on all
IDXGIAdapters. This information includes the maximum luminance, along
with per-output HDR capability.
Plumb this all the way through to GpuDataManagerImplPrivate to
ScreenWin::SetDXGIInfo.
Use the resulting data to compute an appropriate HDR relative maximum
luminance.
Merge the Windows and macOS code for computing the minimum HDR relative
maximum luminance code into a common constant,
kMinHDRCapableMaxLuminanceRelative.
Bug: 1299293, 1216691
Change-Id: I4ec8e78d35bc994c474fd516588b509df756eda2
Reviewed-on:
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/main@{#998452}
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[add]
[modify]
[modify]
[modify]
[modify]
[modify]
zh...@bytedance.com
I did some fixup in this CL: https://chromium-review.googlesource.com/c/chromium/src/+/3693182 , and tested both PQ and HLG content on NVIDIA RTX3070, AMD RX6600, and Intel HD750 GPUs, and thought this should fix the D3D11VideoDecoder tone mapping issue finally and produce a better and unified result on all three GPU vendors.
I also create a demo page with some PQ/HLG hevc content:https://lf-tk-sg.ibytedtos.com/obj/tcs-client-sg/resources/video_demo_hevc.html (you may need passing --enable-featurs=PlatformHEVCDecoderSupport to enable hevc feature in chrome canary and chromium).
I also create a demo page with some PQ/HLG hevc content:
zh...@bytedance.com
For nvidia card, the PQ content should already renderer well, because nvidia gpu doesn't support D3D11_VIDEO_PROCESSOR_FEATURE_CAPS_METADATA_HDR10 and the previous logic already use gfx::colorTransform do PQ tone mapping so no diff on PQ content for nvidia gpu.
The HLG content tone mapping should be better now.
The HLG content tone mapping should be better now.
zh...@bytedance.com
For AMD card, the PQ content previously did not renderer well, because AMD gpu does support D3D11_VIDEO_PROCESSOR_FEATURE_CAPS_METADATA_HDR10 and the previous logic already use VideoProcessor do PQ tone mapping but the result is not good and over exposed so after the fix since we can use gfx instead of VideoProcessor do the tone mapping, the result should be much better.
The HLG content previously did not renderer well, and after the fix, tone mapping should be better because we force set source transfer to Gamma2.2 and output colorspace to sRGB.
The HLG content previously did not renderer well, and after the fix, tone mapping should be better because we force set source transfer to Gamma2.2 and output colorspace to sRGB.
zh...@bytedance.com
Also tested on NVIDIA GTX1050Ti, and have the same result.
Since the gpu doesn't support hw decode av1, so no test_pq diff here.
Since the gpu doesn't support hw decode av1, so no test_pq diff here.
zh...@bytedance.com
For Intel card, the PQ content previously did not renderer well, because HD750 gpu does support D3D11_VIDEO_PROCESSOR_FEATURE_CAPS_METADATA_HDR10 and the previous logic already use VideoProcessor do PQ tone mapping. the results is clearly different from the result that amd rx5500 produced,so after the fix since we can use gfx instead of VideoProcessor do the tone mapping, the result should be much better.
The HLG content previously did not renderer well, and after the fix, tone mapping should be better because we force set source transfer to Gamma2.2 and output colorspace to sRGB.
The HLG content previously did not renderer well, and after the fix, tone mapping should be better because we force set source transfer to Gamma2.2 and output colorspace to sRGB.
zh...@bytedance.com
@ccameron, we may also use gfx::ColorTransform to do HLG tone mapping, but for now, based on what I see with my naked eyes, it seems the result after tone mapping for HLG is darker and less saturated compared with the previous gfx tone mapping algo or the result from VideoProcessor, and shows clear different result compared with other video player like Windows Movie and TV or Davince Resolve.
gi...@appspot.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/137a2f73d618c2059a1bbabb4105128efa2127ea
commit 137a2f73d618c2059a1bbabb4105128efa2127ea
Author: Sida Zhu <zhusida@bytedance.com>
Date: Fri Jun 17 19:07:51 2022
Video: Better HLG/PQ tone mapping on SDR Display
For HLG contents, VideoProcessor doesn't supports tone mapping of
DXGI_COLOR_SPACE_YCBCR_XXX_GHLG_TOPLEFT_P2020 but supports Gamma2.2 and this
has nothing to do with D3D11_VIDEO_PROCESSOR_FEATURE_CAPS_METADATA_HDR10
feature cap, so we can always set input to Gamma2.2 and output to sRGB,
and the result should be better and unified on different gpu vendors.
For PQ contents, VideoProcesser does poor tone mapping between different
gpu vendors no matter if D3D11_VIDEO_PROCESSOR_FEATURE_CAPS_METADATA_HDR10
feature caps is supported or not, but gfx::ColorTransform indeed handle
PQ content well, so reset colorspace to use gfx do tone mapping, and the
result should be better and unified on different gpu vendors.
Tested on AMD RX 6600, NVIDIA RTX 3070, GTX 1050Ti, Intel HD750 and the results have
been attatched tocrbug.com/1216691#c47 , crbug.com/1216691#c48 , crbug.com/1216691#c49 , crbug.com/1216691#c50
Bug: 1305892
Bug: 1216691
Change-Id: I2f2cc5fd26f02703f71d977dee2d1a3a530abde9
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/3693182
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1015464}
[modify]https://crrev.com/137a2f73d618c2059a1bbabb4105128efa2127ea/media/gpu/windows/d3d11_texture_selector.h
[modify]https://crrev.com/137a2f73d618c2059a1bbabb4105128efa2127ea/media/gpu/windows/d3d11_texture_selector.cc
[modify]https://crrev.com/137a2f73d618c2059a1bbabb4105128efa2127ea/media/gpu/windows/d3d11_video_processor_proxy.h
[modify]https://crrev.com/137a2f73d618c2059a1bbabb4105128efa2127ea/media/gpu/windows/d3d11_video_decoder.cc
[modify]https://crrev.com/137a2f73d618c2059a1bbabb4105128efa2127ea/media/gpu/windows/d3d11_video_processor_proxy.cc
[modify]https://crrev.com/137a2f73d618c2059a1bbabb4105128efa2127ea/media/gpu/windows/d3d11_copying_texture_wrapper.cc
[modify]https://crrev.com/137a2f73d618c2059a1bbabb4105128efa2127ea/media/gpu/windows/d3d11_video_device_format_support.cc
[modify]https://crrev.com/137a2f73d618c2059a1bbabb4105128efa2127ea/media/gpu/windows/d3d11_video_device_format_support.h
[modify]https://crrev.com/137a2f73d618c2059a1bbabb4105128efa2127ea/media/gpu/windows/d3d11_texture_selector_unittest.cc
commit 137a2f73d618c2059a1bbabb4105128efa2127ea
Author: Sida Zhu <zhusida@bytedance.com>
Date: Fri Jun 17 19:07:51 2022
Video: Better HLG/PQ tone mapping on SDR Display
For HLG contents, VideoProcessor doesn't supports tone mapping of
DXGI_COLOR_SPACE_YCBCR_XXX_GHLG_TOPLEFT_P2020 but supports Gamma2.2 and this
has nothing to do with D3D11_VIDEO_PROCESSOR_FEATURE_CAPS_METADATA_HDR10
feature cap, so we can always set input to Gamma2.2 and output to sRGB,
and the result should be better and unified on different gpu vendors.
For PQ contents, VideoProcesser does poor tone mapping between different
gpu vendors no matter if D3D11_VIDEO_PROCESSOR_FEATURE_CAPS_METADATA_HDR10
feature caps is supported or not, but gfx::ColorTransform indeed handle
PQ content well, so reset colorspace to use gfx do tone mapping, and the
result should be better and unified on different gpu vendors.
Tested on AMD RX 6600, NVIDIA RTX 3070, GTX 1050Ti, Intel HD750 and the results have
been attatched to
Bug: 1305892
Bug: 1216691
Change-Id: I2f2cc5fd26f02703f71d977dee2d1a3a530abde9
Reviewed-on:
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1015464}
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
do...@googlemail.com
I tried the images on the latest Chrome Release as well as Canary on a Oneplus 7, Oneplus 2, and Galaxy S20 FE. The HDR images look completely broken with severe color bands that are not present in the SDR versions. On Desktop Linux it looks fine.
Though this might be a different issue, I thought it might be appropriate to mention this here because it is also about HDR.
Though this might be a different issue, I thought it might be appropriate to mention this here because it is also about HDR.
da...@chromium.org
@dorianrudo97: What version of Android were you testing? The code for tonemapping should be enabled the same on android as desktop for images. On a Pixel 6 Pro w/ S the image looks correct on canary.
do...@googlemail.com
The OnePlus 7 is running Oxygen OS 11.0.8.1.GM57AA. I don't have access to
the other devices right now. But should it even be doing tone mapping? The
phone does support HDR (at least in YouTube and the HDR check app).
the other devices right now. But should it even be doing tone mapping? The
phone does support HDR (at least in YouTube and the HDR check app).
va...@chromium.org
On Android we always composite to SRGB as of now, so tone mapping is needed, but should be happening same on other platforms.
cc...@chromium.org
Re https://crbug.com/chromium/1216691#c53 , please file a separate bug on that issue (something is going very wrong in that image, and it'll need its own attention).
Marking this as fixed (we are tone mapping PQ and HLG on SDR displays -- any desired tweaks to tone mapping should get their own bugs -- I'm sure we'll iterate on the algorithms there for a while to come).
Marking this as fixed (we are tone mapping PQ and HLG on SDR displays -- any desired tweaks to tone mapping should get their own bugs -- I'm sure we'll iterate on the algorithms there for a while to come).
va...@gmail.com
Tonemapping on Android for PQ AVIF is horrible: (AVIF PQ, rename it): https://user-images.githubusercontent.com/104958042/174458649-ccff6eb4-0d6c-449c-a60a-7c0c8c817779.jpeg
Only not tagged as top-left, sorry about that!
P.S. Not to mention my display supports HDR and WCG SDR.
Only not tagged as top-left, sorry about that!
P.S. Not to mention my display supports HDR and WCG SDR.
gi...@appspot.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/5d213d82b79c459d4160fe67e0db3a2539cc4e82
commit 5d213d82b79c459d4160fe67e0db3a2539cc4e82
Author: Sida Zhu <zhusida@bytedance.com>
Date: Fri Sep 30 18:22:28 2022
Video: Use gfx instead of video processor do HLG HDR tone mapping
Our gfx tone mapping algorithm for HLG is stable and correct now when compared with the result months ago.
Switch to use gfx has the following benefits:
1. All device vendor should have an unified tone mapping result both
for PQ and HLG contents, and thus chrome should have a better and
precise output color control.
2. Gfx tone mapping has a better performance when compared with d3d11
video processor.
The result tested with several 4K 60P HLG HEVC videos on an
intel i5-1135G7 + 8GB memory laptop, visible drop frames can be seen
when using video processor, but not able to be seen when switch to gfx.
Bug: 1216691
Change-Id: Ia840f454d0015a239da5328a26ed19c37346be9a
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/3930065
Commit-Queue: 朱思达 <zhusida@bytedance.com>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1053670}
[modify]https://crrev.com/5d213d82b79c459d4160fe67e0db3a2539cc4e82/media/gpu/windows/d3d11_texture_selector.cc
[modify]https://crrev.com/5d213d82b79c459d4160fe67e0db3a2539cc4e82/media/gpu/windows/d3d11_copying_texture_wrapper.cc
commit 5d213d82b79c459d4160fe67e0db3a2539cc4e82
Author: Sida Zhu <zhusida@bytedance.com>
Date: Fri Sep 30 18:22:28 2022
Video: Use gfx instead of video processor do HLG HDR tone mapping
Our gfx tone mapping algorithm for HLG is stable and correct now when compared with the result months ago.
Switch to use gfx has the following benefits:
1. All device vendor should have an unified tone mapping result both
for PQ and HLG contents, and thus chrome should have a better and
precise output color control.
2. Gfx tone mapping has a better performance when compared with d3d11
video processor.
The result tested with several 4K 60P HLG HEVC videos on an
intel i5-1135G7 + 8GB memory laptop, visible drop frames can be seen
when using video processor, but not able to be seen when switch to gfx.
Bug: 1216691
Change-Id: Ia840f454d0015a239da5328a26ed19c37346be9a
Reviewed-on:
Commit-Queue: 朱思达 <zhusida@bytedance.com>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1053670}
[modify]
[modify]
is...@google.com
This issue was migrated from crbug.com/chromium/1216691?no_tracker_redirect=1
[Auto-CCs applied]
[Multiple monorail components: Internals>GPU>Internals, Internals>GPU>Video>HDR, Internals>Media]
[Monorail blocked-on:crbug.com/chromium/1015599 ]
[Monorail mergedwith:crbug.com/chromium/1233351 , crbug.com/chromium/1237301 , crbug.com/chromium/1284655 ]
[Monorail components added to Component Tags custom field.]
[Auto-CCs applied]
[Multiple monorail components: Internals>GPU>Internals, Internals>GPU>Video>HDR, Internals>Media]
[Monorail blocked-on:
[Monorail mergedwith:
[Monorail components added to Component Tags custom field.]
Description
Example URL:
Steps to reproduce the problem:
On a SDR display, open any HDR video or HDR image (that uses PQ or HLG transfer function).
(Example A) Go to this page:
(Example B) Two testfiles are attached to this report and more HDR AVIF testfiles are available on AVIF's official Github :
(Example C) Force YouTube to play HDR video on SDR display by following steps below:
(C.1) Go to chrome://flags/#force-color-profile
(C.2) In the section "Force color profile" choose scRGB
(C.3) Click on "Relaunch"
(C.4) Play any HDR YouTube video. This one for example:
What is the expected behavior?
What went wrong?
HDR contents are blown out. My guess is that the HDR content is converted to scRGB and in then clipped to sRGB instead of being tonemapped.
Did this work before? No
Is it a problem with Flash or HTML5? N/A
Does this work in other browsers? No
Chrome for Android, Opera, Opera mobile, Samsung Internet, Edge, Brave
Chrome version: 91.0.4472.77 (Build officiel) (64 bits) (cohort: Stable) Channel: n/a
OS Version: 10.0
Flash Version:
Contents of chrome://gpu:
Graphics Feature Status
Canvas: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Hardware accelerated
OpenGL: Enabled
Rasterization: Hardware accelerated
Skia Renderer: Enabled
Video Decode: Hardware accelerated
Vulkan: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
Driver Bug Workarounds
check_ycbcr_studio_g22_left_p709_for_nv12_support
clear_uniforms_before_first_program_use
decode_encode_srgb_for_generatemipmap
disable_accelerated_av1_decode_d3d11
disable_accelerated_vp9_decode
disable_decode_swap_chain
disable_direct_composition_sw_video_overlays
enable_bgra8_overlays_with_yuv_overlay_support
exit_on_context_lost
max_msaa_sample_count_4
msaa_is_slow
disabled_extension_GL_KHR_blend_equation_advanced
disabled_extension_GL_KHR_blend_equation_advanced_coherent
Problems Detected
Some drivers are unable to reset the D3D device in the GPU process sandbox
Applied Workarounds: exit_on_context_lost
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
On Intel GPUs MSAA performance is not acceptable for GPU rasterization: 527565
Applied Workarounds: msaa_is_slow
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
Decode and Encode before generateMipmap for srgb format textures on Windows: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
VP9 decoding is too slow on Intel Broadwell, Skylake, and CherryTrail: 616318
Applied Workarounds: disable_accelerated_vp9_decode
Disable DecodeSwapChain for Intel Gen9 and older devices: 1107403
Applied Workarounds: disable_decode_swap_chain
Intel GPUs fail to report BGRA8 overlay support: 1119491
Applied Workarounds: enable_bgra8_overlays_with_yuv_overlay_support
8x MSAA for WebGL contexts is slow on Win Intel: 1145793
Applied Workarounds: max_msaa_sample_count_4
High D3D11VideoDecoder error rates for AV1 content on Intel GPUs: 1181358
Applied Workarounds: disable_accelerated_av1_decode_d3d11
Disable software overlays for Intel GPUs. All Skylake+ devices support hw overlays, older devices peform poorly.: 1192748
Applied Workarounds: disable_direct_composition_sw_video_overlays
Check YCbCr_Studio_G22_Left_P709 color space for NV12 overlay support on Intel: 1103852
Applied Workarounds: check_ycbcr_studio_g22_left_p709_for_nv12_support
ANGLE Features
allow_compressed_formats (Frontend workarounds): Enabled: true
Allow compressed formats
disable_anisotropic_filtering (Frontend workarounds): Disabled
Disable support for anisotropic filtering
disable_program_binary (Frontend features) anglebug:5007: Disabled
Disable support for GL_OES_get_program_binary
disable_program_caching_for_transform_feedback (Frontend workarounds): Disabled
On some GPUs, program binaries don't contain transform feedback varyings
enable_capture_limits (Frontend features) anglebug:5750: Disabled
Set the context limits like frame capturing was enabled
lose_context_on_out_of_memory (Frontend workarounds): Enabled: true
Some users rely on a lost context notification if a GL_OUT_OF_MEMORY error occurs
scalarize_vec_and_mat_constructor_args (Frontend workarounds) 1165751: Disabled: false
Always rewrite vec/mat constructors to be consistent
sync_framebuffer_bindings_on_tex_image (Frontend workarounds): Disabled
On some drivers TexImage sometimes seems to interact with the Framebuffer
add_mock_texture_no_render_target (D3D workarounds) anglebug:2152: Disabled: isIntel && capsVersion < IntelDriverVersion(4815)
On some drivers when rendering with no render target, two bugs lead to incorrect behavior
allow_clear_for_robust_resource_init (D3D workarounds) 941620: Enabled: true
Some drivers corrupt texture data when clearing for robust resource initialization.
allow_translate_uniform_block_to_structured_buffer (D3D workarounds) anglebug:3682: Enabled: IsWin10OrGreater()
There is a slow fxc compile performance issue with dynamic uniform indexing if translating a uniform block with a large array member to cbuffer.
call_clear_twice (D3D workarounds) 655534: Disabled: isIntel && isSkylake && capsVersion < IntelDriverVersion(4771)
Using clear() may not take effect
depth_stencil_blit_extra_copy (D3D workarounds) anglebug:1452: Disabled
Bug in some drivers triggers a TDR when using CopySubresourceRegion from a staging texture to a depth/stencil
disable_b5g6r5_support (D3D workarounds): Disabled: (isIntel && capsVersion < IntelDriverVersion(4539)) || isAMD
Textures with the format DXGI_FORMAT_B5G6R5_UNORM have incorrect data
emulate_isnan_float (D3D workarounds) 650547: Disabled: isIntel && isSkylake && capsVersion < IntelDriverVersion(4542)
Using isnan() on highp float will get wrong answer
emulate_tiny_stencil_textures (D3D workarounds): Disabled: isAMD && !(deviceCaps.featureLevel < D3D_FEATURE_LEVEL_10_1)
1x1 and 2x2 mips of depth/stencil textures aren't sampled correctly
expand_integer_pow_expressions (D3D workarounds): Enabled: true
The HLSL optimizer has a bug with optimizing 'pow' in certain integer-valued expressions
flush_after_ending_transform_feedback (D3D workarounds): Disabled: isNvidia
Some drivers sometimes write out-of-order results to StreamOut buffers when transform feedback is used to repeatedly write to the same buffer positions
force_atomic_value_resolution (D3D workarounds) anglebug:3246: Disabled: isNvidia
On some drivers the return value from RWByteAddressBuffer.InterlockedAdd does not resolve when used in the .yzw components of a RWByteAddressBuffer.Store operation
get_dimensions_ignores_base_level (D3D workarounds): Disabled: isNvidia
Some drivers do not take into account the base level of the texture in the results of the HLSL GetDimensions builtin
mrt_perf_workaround (D3D workarounds): Enabled: true
Some drivers have a bug where they ignore null render targets
pre_add_texel_fetch_offsets (D3D workarounds): Enabled: isIntel
HLSL's function texture.Load returns 0 when the parameter Location is negative, even if the sum of Offset and Location is in range
rewrite_unary_minus_operator (D3D workarounds): Disabled: isIntel && (isBroadwell || isHaswell) && capsVersion < IntelDriverVersion(4624)
Evaluating unary minus operator on integer may get wrong answer in vertex shaders
select_view_in_geometry_shader (D3D workarounds): Disabled: !deviceCaps.supportsVpRtIndexWriteFromVertexShader
The viewport or render target slice will be selected in the geometry shader stage for the ANGLE_multiview extension
set_data_faster_than_image_upload (D3D workarounds): Enabled: !(isIvyBridge || isBroadwell || isHaswell)
Set data faster than image upload
skip_vs_constant_register_zero (D3D workarounds): Disabled: isNvidia
In specific cases the driver doesn't handle constant register zero correctly
use_instanced_point_sprite_emulation (D3D workarounds): Disabled: isFeatureLevel9_3
Some D3D11 renderers do not support geometry shaders for pointsprite emulation
use_system_memory_for_constant_buffers (D3D workarounds) 593024: Enabled: isIntel
Copying from staging storage to constant buffer storage does not work
zero_max_lod (D3D workarounds): Disabled: isFeatureLevel9_3
Missing an option to disable mipmaps on a mipmapped texture
Version Information
Data exported 2021-06-05T01:02:15.851Z
Chrome version Chrome/91.0.4472.77
Operating system Windows NT 10.0.19042
Software rendering list URL
Driver bug list URL
ANGLE commit id 788efd1c721a
2D graphics backend Skia/91 71fcb16fc206466727cb49cbf318b765f8a9d5a7
Command Line "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --origin-trial-disabled-features=SecurePaymentConfirmation --flag-switches-begin --force-color-profile=scrgb-linear --flag-switches-end
Driver Information
Initialization time 144
In-process GPU false
Passthrough Command Decoder true
Sandboxed true
GPU0 VENDOR= 0x8086, DEVICE=0x1916, SUBSYS=0x00151414, REV=7, LUID={0,50600} *ACTIVE*
GPU1 VENDOR= 0x1414, DEVICE=0x008c, LUID={0,51621}
Optimus false
AMD switchable false
Desktop compositing Aero Glass
Direct composition true
Supports overlays true
YUY2 overlay support SCALING
NV12 overlay support SOFTWARE
BGRA8 overlay support SCALING
RGB10A2 overlay support SOFTWARE
Diagonal Monitor Size of \\.\DISPLAY1 12.2"
Driver D3D12 feature level D3D 12.1
Driver Vulkan API version Vulkan API 1.1.0
Driver vendor Intel
Driver version 24.20.100.6299
GPU CUDA compute capability major version 0
Pixel shader version 5.0
Vertex shader version 5.0
Max. MSAA samples 16
Machine model name
Machine model version
GL_VENDOR Google Inc. (Intel)
GL_RENDERER ANGLE (Intel, Intel(R) HD Graphics 520 Direct3D11 vs_5_0 ps_5_0, D3D11-24.20.100.6299)
GL_VERSION OpenGL ES 2.0.0 (ANGLE 2.1.15374 git hash: 788efd1c721a)
GL_EXTENSIONS GL_ANGLE_base_vertex_base_instance GL_ANGLE_client_arrays GL_ANGLE_depth_texture GL_ANGLE_explicit_context GL_ANGLE_explicit_context_gles1 GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_get_serialized_context_string GL_ANGLE_get_tex_level_parameter GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_memory_size GL_ANGLE_multi_draw GL_ANGLE_multiview_multisample GL_ANGLE_pack_reverse_row_order GL_ANGLE_program_cache_control GL_ANGLE_provoking_vertex GL_ANGLE_request_extension GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_color_buffer_float_rgb GL_CHROMIUM_color_buffer_float_rgba GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_lose_context GL_CHROMIUM_sync_query GL_EXT_EGL_image_external_wrap_modes GL_EXT_blend_func_extended GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_draw_elements_base_vertex GL_EXT_float_blend GL_EXT_frag_depth GL_EXT_instanced_arrays GL_EXT_map_buffer_range GL_EXT_multisampled_render_to_texture GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_bptc GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc_srgb GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_KHR_parallel_shader_compile GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_compressed_EAC_R11_signed_texture GL_OES_compressed_EAC_R11_unsigned_texture GL_OES_compressed_EAC_RG11_signed_texture GL_OES_compressed_EAC_RG11_unsigned_texture GL_OES_compressed_ETC2_RGB8_texture GL_OES_compressed_ETC2_RGBA8_texture GL_OES_compressed_ETC2_punchthroughA_RGBA8_texture GL_OES_compressed_ETC2_punchthroughA_sRGB8_alpha_texture GL_OES_compressed_ETC2_sRGB8_alpha8_texture GL_OES_compressed_ETC2_sRGB8_texture GL_OES_depth24 GL_OES_depth32 GL_OES_draw_elements_base_vertex GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_border_clamp GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_texture_stencil8 GL_OES_vertex_array_object GL_WEBGL_video_texture
Disabled Extensions GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent
Disabled WebGL Extensions
Window system binding vendor Google Inc. (Intel)
Window system binding version 1.5 (ANGLE 2.1.15374 git hash: 788efd1c721a)
Window system binding extensions EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_CHROMIUM_sync_control EGL_EXT_pixel_format_float EGL_KHR_surfaceless_context EGL_ANGLE_display_texture_share_group EGL_ANGLE_display_semaphore_share_group EGL_ANGLE_create_context_client_arrays EGL_ANGLE_program_cache_control EGL_ANGLE_robust_resource_initialization EGL_ANGLE_create_context_extensions_enabled EGL_ANDROID_blob_cache EGL_ANDROID_recordable EGL_ANGLE_image_d3d11_texture EGL_ANGLE_create_context_backwards_compatible EGL_KHR_create_context_no_error EGL_KHR_reusable_sync
Direct rendering version unknown
Reset notification strategy 0x8252
GPU process crash count 0
gfx::BufferFormats supported for allocation and texturing R_8: not supported, R_16: not supported, RG_88: not supported, BGR_565: not supported, RGBA_4444: not supported, RGBX_8888: not supported, RGBA_8888: not supported, BGRX_8888: not supported, BGRA_1010102: not supported, RGBA_1010102: not supported, BGRA_8888: not supported, RGBA_F16: not supported, YVU_420: not supported, YUV_420_BIPLANAR: not supported, P010: not supported
Compositor Information
Tile Update Mode One-copy
Partial Raster Enabled
GpuMemoryBuffers Status
R_8 Software only
R_16 Software only
RG_88 Software only
BGR_565 Software only
RGBA_4444 Software only
RGBX_8888 GPU_READ, SCANOUT
RGBA_8888 GPU_READ, SCANOUT
BGRX_8888 Software only
BGRA_1010102 Software only
RGBA_1010102 Software only
BGRA_8888 Software only
RGBA_F16 Software only
YVU_420 Software only
YUV_420_BIPLANAR Software only
P010 Software only
Display(s) Information
Info Display[2528732444] bounds=[0,0 1368x912], workarea=[0,0 1368x872], scale=2, rotation=0, panel_rotation=0 internal.
Color space (all) {primaries:BT709, transfer:LINEAR_HDR (slope 1.0000, SDR white point 80.0000 nits), matrix:RGB, range:FULL}
Buffer format (all) RGBA_F16
SDR white level in nits 80
Bits per color component 10
Bits per pixel 30
Refresh Rate in Hz 59
Video Acceleration Information
Decode h264 baseline 64x64 to 4096x4096 pixels
Decode h264 main 64x64 to 4096x4096 pixels
Decode h264 high 64x64 to 4096x4096 pixels
Encode h264 baseline 0x0 to 1920x1088 pixels, and/or 30.000 fps
Encode h264 main 0x0 to 1920x1088 pixels, and/or 30.000 fps
Encode h264 high 0x0 to 1920x1088 pixels, and/or 30.000 fps
Vulkan Information
Device Performance Information
Total Physical Memory (Gb) 7
Total Disk Space (Gb) 236
Hardware Concurrency 4
System Commit Limit (Gb) 17
D3D11 Feature Level 12_1
Has Discrete GPU no
Intel GPU Generation 9
Software Rendering No
Diagnostics
0
b3DAccelerationEnabled true
b3DAccelerationExists true
bAGPEnabled true
bAGPExistenceValid true
bAGPExists true
bCanRenderWindow true
bDDAccelerationEnabled true
bDriverBeta false
bDriverDebug false
bDriverSigned false
bDriverSignedValid false
bNoHardware false
dwBpp 32
dwDDIVersion 12
dwHeight 1824
dwRefreshRate 59
dwWHQLLevel 0
dwWidth 2736
iAdapter 0
lDriverSize 2018600
lMiniVddSize 0
szAGPStatusEnglish Enabled
szAGPStatusLocalized Activé
szChipType Intel(R) HD Graphics Family
szD3DStatusEnglish Enabled
szD3DStatusLocalized Activé
szDACType Internal
szDDIVersionEnglish 12
szDDIVersionLocalized 12
szDDStatusEnglish Enabled
szDDStatusLocalized Activé
szDXVAHDEnglish Supported
szDXVAModes ModeMPEG2_A ModeMPEG2_C ModeWMV9_C ModeVC1_C
szDescription Intel(R) HD Graphics 520
szDeviceId 0x1916
szDeviceIdentifier {D7B78E66-5A56-11CF-3F6F-7120BCC2D535}
szDeviceName \\.\DISPLAY1
szDisplayMemoryEnglish 4184 MB
szDisplayMemoryLocalized 4184 MB
szDisplayModeEnglish 2736 x 1824 (32 bit) (59Hz)
szDisplayModeLocalized 2736 x 1824 (32 bit) (59Hz)
szDriverAssemblyVersion 24.20.100.6299
szDriverAttributes Final Retail
szDriverDateEnglish 11-10-18 02:00:00
szDriverDateLocalized 10/11/2018 02:00:00
szDriverLanguageEnglish English
szDriverLanguageLocalized Anglais
szDriverModelEnglish WDDM 2.1
szDriverModelLocalized WDDM 2.1
szDriverName C:\WINDOWS\System32\DriverStore\FileRepository\64gh6299.inf_amd64_94401bd29769cd59\igdumdim64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\64gh6299.inf_amd64_94401bd29769cd59\igd10iumd64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\64gh6299.inf_amd64_94401bd29769cd59\igd10iumd64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\64gh6299.inf_amd64_94401bd29769cd59\igd12umd64.dll
szDriverNodeStrongName oem32.inf:5f63e534f36b7c6d:iSKLD_w10_DS:24.20.100.6299:pci\ven_8086&dev_1916&subsys_00151414
szDriverSignDate Unknown
szDriverVersion 24.20.0100.6299
szKeyDeviceID Enum\PCI\VEN_8086&DEV_1916&SUBSYS_00151414&REV_07
szKeyDeviceKey \Registry\Machine\System\CurrentControlSet\Control\Video\{152D614E-A112-11EA-9129-A726F7FD756B}\0000
szManufacturer Intel Corporation
szMiniVdd inconnu
szMiniVddDateEnglish Unknown
szMiniVddDateLocalized inconnu
szMonitorMaxRes Unknown
szMonitorName Surface Display
szNotesEnglish No problems found.
szNotesLocalized Aucun problème n’a été détecté.
szOverlayEnglish Supported
szRankOfInstalledDriver 00D10001
szRegHelpText Unknown
szRevision Unknown
szRevisionId 0x0007
szSubSysId 0x00151414
szTestResultD3D7English Not run
szTestResultD3D7Localized Non exécuté
szTestResultD3D8English Not run
szTestResultD3D8Localized Non exécuté
szTestResultD3D9English Not run
szTestResultD3D9Localized Non exécuté
szTestResultDDEnglish Not run
szTestResultDDLocalized Non exécuté
szVdd inconnu
szVendorId 0x8086
Log Messages
GpuProcessHost: The info collection GPU process exited normally. Everything is okay.
This happens both in Windows and Android and for both videos and still images regardless of the codec.
On Android, HDR AVIF still images are converted to scRGB and then blown out. HDR videos however are not even converted to scRGB and are wrongly rendered as being SDR.