Issue metadata
Sign in to add a comment
|
Gamma shift occurs when GPU acceleration is enabled
Reported by
haydst...@gmail.com,
Mar 25 2018
|
|||||||||||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Example URL: www.youtube.com Steps to reproduce the problem: 1. Make sure hardware acceleration is enabled in chrome 2. Play a youtube video 3. Note that everything is light, even when no content is displayed (i.e. 'black screen') the screen is still grey. What is the expected behavior? black screen is black, when video is playing in chrome it should look exactly the same as in other browsers or when playing locally What went wrong? The black parts of the video are grey and all of the video is lighter than when it is played in another browser, locally, or in chrome with HW acceleration turned off. Did this work before? Yes Not entirely sure, it was before v63 though Is it a problem with Flash or HTML5? Both Does this work in other browsers? Yes Chrome version: 65.0.3325.181 Channel: stable OS Version: 6.3 Flash Version: Shockwave Flash 29.0 r0 Contents of chrome://gpu: HW ACC DISABLED Graphics Feature Status Canvas: Software only, hardware acceleration unavailable CheckerImaging: Disabled Flash: Software only. Hardware acceleration disabled Flash Stage3D: Software only. Hardware acceleration disabled Flash Stage3D Baseline profile: Software only. Hardware acceleration disabled Compositing: Software only. Hardware acceleration disabled Multiple Raster Threads: Enabled Native GpuMemoryBuffers: Software only. Hardware acceleration disabled Rasterization: Software only. Hardware acceleration disabled Video Decode: Software only. Hardware acceleration disabled WebGL: Software only, hardware acceleration unavailable WebGL2: Software only, hardware acceleration unavailable Problems Detected Native GpuMemoryBuffers have been disabled, either via about:flags or command line. Disabled Features: native_gpu_memory_buffers Checker-imaging has been disabled via finch trial or the command line. Disabled Features: checker_imaging Version Information Data exported 2018-03-25T14:04:47.907Z Chrome version Chrome/65.0.3325.181 Operating system Windows NT 6.3.9600 Software rendering list URL https://chromium.googlesource.com/chromium/src/+/dc3469be277cc962ba01d9c0cb5bb1a265676c36/gpu/config/software_rendering_list.json Driver bug list URL https://chromium.googlesource.com/chromium/src/+/dc3469be277cc962ba01d9c0cb5bb1a265676c36/gpu/config/gpu_driver_bug_list.json ANGLE commit id 2c9cc8b6e810 2D graphics backend Skia/65 8a3e0b31927ae78bc3e9c342b1290a6a64233674- Command Line "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --force-color-profile=srgb --flag-switches-end Driver Information Initialization time 104 In-process GPU false Passthrough Command Decoder false Direct Composition false Supports overlays false Sandboxed true GPU0 VENDOR = 0x1002, DEVICE= 0x6798 *ACTIVE* Optimus false Optimus false AMD switchable false Desktop compositing Aero Glass Diagonal Monitor Size of \\.\DISPLAY2 20.0" Diagonal Monitor Size of \\.\DISPLAY3 20.1" Diagonal Monitor Size of \\.\DISPLAY1 20.0" Driver vendor Advanced Micro Devices, Inc. Driver version 21.19.407.0 Driver date 12-23-2016 Pixel shader version 1.00 Vertex shader version 1.00 Max. MSAA samples 4 Machine model name Machine model version GL_VENDOR Google Inc. GL_RENDERER Google SwiftShader GL_VERSION OpenGL ES 2.0 SwiftShader 4.0.0.0 GL_EXTENSIONS GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_depth32 GL_OES_depth_texture GL_OES_depth_texture_cube_map GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_element_index_uint GL_OES_framebuffer_object GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives 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_3D GL_OES_vertex_half_float GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_draw_buffers GL_EXT_instanced_arrays GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_texture_compression_dxt1 GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_CHROMIUM_texture_filtering_hint GL_NV_fence GL_NV_framebuffer_blit GL_NV_read_depth Disabled Extensions Disabled WebGL Extensions Window system binding vendor Google Inc. Window system binding version 1.4 SwiftShader 4.0.0.0 Window system binding extensions EGL_KHR_create_context EGL_KHR_get_all_proc_addresses EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_fence_sync EGL_KHR_image_base EGL_ANDROID_framebuffer_target EGL_ANDROID_recordable Direct rendering Yes Reset notification strategy 0x0000 GPU process crash count 0 Compositor Information Tile Update Mode One-copy Partial Raster Enabled GpuMemoryBuffers Status ATC Software only ATCIA Software only DXT1 Software only DXT5 Software only ETC1 Software only 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 BGRX_1010102 Software only BGRA_8888 Software only RGBA_F16 Software only YVU_420 Software only YUV_420_BIPLANAR Software only UYVY_422 Software only Display(s) Information Info Display[2528732444] bounds=-1680,0 1680x1050, workarea=-1680,30 1680x1020, scale=1, external Color space information {primaries:BT709, transfer:IEC61966_2_1, matrix:RGB, range:FULL} Bits per color component 8 Bits per pixel 24 Info Display[2779098405] bounds=1680,0 1680x1050, workarea=1680,30 1680x1020, scale=1, external Color space information {primaries:BT709, transfer:IEC61966_2_1, matrix:RGB, range:FULL} Bits per color component 8 Bits per pixel 24 Info Display[2841568472] bounds=0,0 1680x1050, workarea=0,30 1680x1020, scale=1, external Color space information {primaries:BT709, transfer:IEC61966_2_1, matrix:RGB, range:FULL} Bits per color component 8 Bits per pixel 24 Video Acceleration Information Encode h264 baseline up to 1920x1088 pixels and/or 30.000 fps Encode h264 main up to 1920x1088 pixels and/or 30.000 fps Encode h264 high up to 1920x1088 pixels and/or 30.000 fps Diagnostics ... loading ... Attached images are comparisons of the video playing in chrome and firefox. The name of each attachment indicates which website was being used, and whether or not hardware acceleration was enabled in chrome.
,
Mar 25 2018
Looks very similar to this issue https://bugs.chromium.org/p/chromium/issues/detail?id=748076 That was on MacOS though, I reported this issue on that issues page and was asked to create a new bug report if the issue still persisted.
,
Mar 26 2018
,
Mar 26 2018
Tested the issue on chrome reported version 65.0.3325.181 using Windows-7 with steps mentioned below: 1) Launched chrome reported version and navigated to URL's: https://youtu.be/K5WQzgRYnZ0, http://www.lagom.nl/lcd-test/black.php & http://www.lagom.nl/lcd-test/gradient.php as per comment#2 2) Able to see the video playing same like in other browsers Observations: Tested this by enabling an disabling the hardware acceleration in chrome://settings, didn't observed any black parts of the video are grey in color @Reporter: Please find the attached screen cast for your reference and let us know if we missed anything in verifying the issue, if possible could you please provide any test file/URL which reproduces the issue, which helps us in further triaging the issue in better way, any further inputs on it from your end maybe helpful. Thanks!
,
Mar 26 2018
Hi there, Thanks for the quick reply and the test. This seems to be specific to certain hardware I think, because it's not happening for everyone, it's definitely happening to more than just me though. Please see attached screen cast where I follow the same examples. The change is most notable on the youtube video, although some increase in gamma is visible on the lcd black test. Almost indistinguishable on the gradient page. This is very very noticeable on videos, but not very much on images at all.
,
Mar 26 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 26 2018
,
Mar 27 2018
Unable to reproduce the issue on chrome reported version 65.0.3325.181 using Windows-7 with steps mentioned below: 1) Launched chrome reported version and navigated to URL's: https://youtu.be/K5WQzgRYnZ0 as per comment#5 2) Able to see the video playing same like in other browsers Observations: Tested this issue by playing the video on YouTube with above mentioned URL, see same behaviour in Firefox and Chrome @Reporter: Please find the attached screen cast for your reference and provide your feedback on it which helps in further triaging it. Thanks!
,
Mar 27 2018
As I mentioned in my previous post, this seems to be specific to certain hardware. The issue does not happen for everyone, but it definitely happens for more than just me. I'm not sure why you attached another screen cast when you can see the issue definitely happens on my hardware. Happy to be involved in beta testing on my hardware if that will help.
,
Mar 27 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 28 2018
As per comment#4 & 8, unable to reproduce the issue from TE end hence removing Needs-Bisect label. Requesting some one from the Internals > Media team have a look at this issue. Thanks!
,
Apr 3 2018
All of the displays here have an sRGB color profile, so it's not on the display side. Maybe there's an issue with the video color space? Maybe hubbe@ has ideas.
,
Apr 10 2018
give to hubbe@ to take a look.
,
Apr 12 2018
I seem to be having the same issue - I've been seeing this for a while now in Vivaldi, but only now have finally managed to verify the same issue is present in Chromium and Chrome for me as well. For me, though, it seems to be definitely related to monitor profile. If I'm using my normal XYZLUT color profile for my monitor, this is what I see with hardware acceleration enabled: https://photos.smugmug.com/photos/i-nQ27wpM/0/10a18b95/O/i-nQ27wpM.png If I disable HW acceleration, this is what I get using the same monitor profile: https://photos.smugmug.com/photos/i-jPqLjM6/0/1faffa7b/O/i-jPqLjM6.png As you can see, the dark tones are way too bright with HW acceleration turned on. The display profile was created using DisplayCAL and Spyder 3, but I've also tried generating one using the default Spyder 3 software and the same thing happens, so it doesn't seem like it's strictly DisplayCAL related. The only way I was able to get the same result with both HW accel enabled and disabled was by either just using the generic sRGB monitor profile, or creating a simple single curve profile using DisplayCAL. With single curve profile, this is what I get regardless of HW acceleration setting in Chromium: https://photos.smugmug.com/photos/i-NTZ4J8w/0/2e1c5c06/O/i-NTZ4J8w.png Neither is much of a solution, obviously, since this pretty much equals to not using color management at all or very basic in case of the single curve profile. Same applies to forcing Chromium to sRGB via flags, which also seems to work, but obviously disables the custom color profile. Needless to say the XYZLUT profile works perfectly fine in any other color managed application including Firefox, it is just Chromium (and Chromium based browser, such as the aforementioned Vivaldi) that exhibit such issues. Attached are the chrome://gpu output, as well as both the working (1xcurve) and not working (XYZLUT) DisplayCAL-generated profile, plus the profile generated using the default Spyder software, which, as mentioned above, exhibits the same issue.
,
Apr 13 2018
When HW acceleration is disabled, we do no color management. It sounds from #14 that the issue here is our handling of LUT-based color profiles. Our ICC profile library currently does not support non-parametric color spaces (see issue 820233).
,
Apr 13 2018
@ccameron I'm assuming you are referring to Comment #14 as the original reported bug is using sRGB
,
May 18 2018
I think this might be a driver bug and/or setting. On this platform we use the DX11 video processor to conver the NV12 data before we return it to the browser. It's possible that we give the wrong parameters to the video processor I suppose. Note, #14 is a separate issue and should be filed separately.
,
Dec 7
,
Dec 8
Same as issue 902550 I think, we should probably just disable color correction prior to Win10.
,
Dec 11
For those of you on Windows 7, do you still see this issue when Chrome is launched with --disable-features=video-blit-color-accuracy ?
,
Dec 11
I have windows 8.1, is that a similar comparison as it is pre-10?
,
Dec 11
Yeah, that's worth testing too. Thanks!
,
Dec 11
Aaaaaand, thats now my default launch option :) Completely fixes it as per screencaps
,
Dec 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/925f40e1f40b6ffb40cf152efa6d92b7af6fbae1 commit 925f40e1f40b6ffb40cf152efa6d92b7af6fbae1 Author: Sunny Sachanandani <sunnyps@chromium.org> Date: Mon Dec 17 21:48:57 2018 Fix incorrect D3D11 color range configuration Color range was being set incorrectly presumably due to a typo. Bug: 851216, 825578, 902550 Change-Id: I22c1af549619c2fad194990a39f11ae7600ca684 Reviewed-on: https://chromium-review.googlesource.com/c/1379035 Reviewed-by: Kenneth Russell <kbr@chromium.org> Reviewed-by: ccameron <ccameron@chromium.org> Reviewed-by: Dale Curtis <dalecurtis@chromium.org> Commit-Queue: Dale Curtis <dalecurtis@chromium.org> Cr-Commit-Position: refs/heads/master@{#617242} [modify] https://crrev.com/925f40e1f40b6ffb40cf152efa6d92b7af6fbae1/ui/gfx/color_space_win.cc
,
Dec 17
The above change may fix the issues with washout. I'll let you know which Chrome Canary version gets that commit. Once available, please test if the issue is fixed there _without_ disabling video-blit-color-accuracy.
,
Dec 18
Thank you, you are both a hero amongst men Dale :) I will test as soon as its in a canary build
,
Dec 18
As per comment# 4 & 8, unable to reproduce the issue from our end. haydster7@ Could you please try to test this issue on latest chrome# 73.0.3644.0 and help us in verifying the fix. Thanks!
,
Dec 18
Is that canary? It is happening in the most recent version of Chrome for windows 70.0.3538.110
,
Dec 18
Yes the change above made it into Chrome Canary 73.0.3644.0, can you try that version? If it's still not fixed, also let me know if things are no longer fixed with --disable-features=video-blit-color-accuracy
,
Dec 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a30440e4cfc7016d4f75a4e108025667e130b78b commit a30440e4cfc7016d4f75a4e108025667e130b78b Author: Dale Curtis <dalecurtis@chromium.org> Date: Thu Dec 20 01:09:43 2018 Fix one more instance of incorrect color range. Another incorrect usage of RGB_Range=1/LIMITED and 0-255 for the nominal range. This switches the code to use GetD3D11ColorSpace for consistency; which may change some behaviors -- it sets matrix, rgb, and range based on color_space instead of always using full range. Per discussion with hubbe@ we're expecting this to make a direct copy so it shouldn't affect anything, but that's an unverified assumption. BUG=851216, 825578, 902550 TEST=none R=sunnyps Change-Id: I55d192de607a26cb76238cc70a46f4343bb8f290 Reviewed-on: https://chromium-review.googlesource.com/c/1383325 Commit-Queue: Dale Curtis <dalecurtis@chromium.org> Reviewed-by: Frank Liberato <liberato@chromium.org> Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org> Cr-Commit-Position: refs/heads/master@{#618054} [modify] https://crrev.com/a30440e4cfc7016d4f75a4e108025667e130b78b/media/gpu/windows/dxva_video_decode_accelerator_win.cc
,
Jan 3
Hi there, sorry it took me so long. Results in Canary 73.0.3660.0 are identical to Chromes behaviour throughout this thread, that is: - No wash out when hardware acceleration is disabled - No wash out when --disable-features=video-blit-color-accuracy is used - All other times wash out occurs
,
Jan 8
Thanks, will try some other things. It's surprising you're not seeing wash out with the blit color accuracy disabled, another user is seeing washout with it disabled in issue 851216 -- though they are on Windows 7. |
||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||||||||||
Comment 1 by haydst...@gmail.com
, Mar 25 2018