Issue metadata
Sign in to add a comment
|
Pages are not displayed properly when hardware acceleration is on
Reported by
lilha...@gmail.com,
May 12 2016
|
||||||||||||||||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2729.3 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Open any page (especially the ones with HTML5 videos) 2. 3. What is the expected behavior? display properly What went wrong? Black rectangles or white rectangles shades some parts of the pages. Does it occur on multiple sites: Yes Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? Yes Chrome version: 52.0.2729.3 Channel: dev OS Version: OS X 10.9.5 Flash Version: Shockwave Flash 22.0 r0 The browser was working properly when it was initially upgraded to 52.0.2729.3, but after I watched several videos on youtube, the issue appeared and spread to most of the pages. Chrome Canary version 52.0.2733.0 has the same issue. After I unchecked the hardware acceleration, it was back to normal. So I suppose it was another issue related to GPU acceleration on Haswell on Mavericks. (It reminds the previous issues displaying PDF when GPU acceleration was on)
,
May 12 2016
Issue 611501 has been merged into this issue.
,
May 12 2016
,
May 12 2016
,
May 12 2016
,
May 12 2016
Reporter is mac
,
May 12 2016
,
May 12 2016
I can repro this. - investigating now.
,
May 12 2016
Actually, looks like I may be reproing a different issue. lilhaya@, are you able to attach the output of about://gpu - this contains some error information as well, so it would be great if you could paste this after you've seen the issue described at least once. Thanks!
,
May 12 2016
@ericrk I switched the hardware acceleration back on and now my Chrome is displaying contents correctly, just like when it was initially upgraded to the current version. So I guess I will let it run for a while till the issue (possibly) comes back and I will report here asap. BTW I attached my current chrome://gpu page if it helps.
,
May 13 2016
Thus it seems that every time the issue appeared after I playing several <video> embedded videos.
,
May 16 2016
,
May 17 2016
,
May 18 2016
about:GPU seems to indicate a texture binding problem in PPAPI - so likely a flash video element (may be something else on screen, not the main video being watched). It looks like we're trying to create a texture with GL_TEXTURE_RECTANGLE_ARB directly via TexImage2D - we shouldn't hit this path. This seems to cause an incomplete framebuffer and a cascade of errors. Not sure why GPU raster affects this path - will continue to investigate.
,
May 19 2016
It looks like failing GPU Memory Buffer allocation would get us similar error messages (Although not an exact match) - might be something similar to this. I wonder if there are cases where IOSurface allocation can fail. We've only seen this on 10.9 so far, so this could be related to that OS version as well.
,
May 19 2016
It only appeared on OSX 10.9. So I guess Issue 594343 is a related And they fixed that one by checking if the OS was 10.9 and made it as an exception. https://bugs.chromium.org/p/chromium/issues/detail?id=594343#c56
,
May 19 2016
Thanks for linking to the other issue! It does look similar, but I'm not seeing the same kind of errors in the attached about:Gpu, so may not be quite the same. I'll keep investigating. lilhayah@, from your comment, it sounds like you have tried newer (non 10.9) macs and haven't seen the issue - is that correct?
,
May 20 2016
Oh, sorry, what I said was referring your previous comment"we've only seen this on 10.9 so far." I have not tried it on newer osx versions.
,
May 26 2016
Erick, can we have an update on this issue? We are close to M52 Beta Promotion- 05/25. Can we get a fixed soon.
,
May 26 2016
I can't get a repro locally, so I'm not sure how best to proceed. I may need to track down an OSX 10.9 device in hopes that it will repro there. Given the limited number of reports of the issue, and the fact that we are launching GPU rasterization via Finch (and can turn it off during Beta if need be), I'd push to change this to release-block Stable and hope that we can determine a better repro during Beta, hopefully with more reports.
,
May 26 2016
Note that the windows issue reported in #20 is likely unrelated - no GPU raster, and no IOSurfaces/Native GMBs (which appear to be involved in the issues here). nonemea.774@, if you see this again, can you file a new bug? Thanks!
,
May 27 2016
Changing this to releaseblock-stable - if we get more reports in Beta we can hopefully narrow down the problem to a specific OS/GPU and add that to the blacklist.
,
Jun 3 2016
,
Jun 6 2016
M52 is promoted to Beta, Eric can you please get started with your investigation as per #24.
,
Jun 16 2016
Ping, any update?
,
Jun 16 2016
A friendly reminder that M52 Stable is launching soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch by July 12. All changes MUST be merged into the release branch by 5pm on July 15 to make into the desktop Stable final build cut. Thank you!
,
Jun 17 2016
We haven't enabled GPU raster on Beta yet, as there were additional testing concerns. I'm hoping to enable on Beta soon and collect more data.
,
Jun 17 2016
Note that unless we specifically enable Gpu Raster on Stable via Finch, this issue won't appear, so no action needs to be taken for M52 unless we also decide to enable GPU raster stable for M52. Will make sure to address this before we make the Stable Go/no-go decision.
,
Jun 17 2016
Anantha, do you know if test has a Late 2013 or Mid 2014 13" MBP - this should match the GPU configuration seen here.
,
Jun 17 2016
ericrk@: as per comments 22/30, I'm wondering if this really should be a release block stable. If GPU raster can be turned off this doesn't seem like a release blocker.Your thoughts? Also have you gathered enough reports to have ideas of a fix or timeline? We go stable in about a month and turning it off in Finch might be best bet.
,
Jun 17 2016
Yeah, I agree, this isn't really a release blocker, just a "turn on finch for stable" blocker. I'll remove the tag. FYI, we have no reports (other than the user who filed this bug), so I don't have a great idea on fix/timeline.
,
Jun 18 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 10 2016
This issue is Pri-1 but has already been moved once. Lowering the priority and moving to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 14 2016
Thanks for the additional report! Was the chrome://gpu captured in #36 captured in the same browsing session as the bug appeared, or was it captured later, after your coworker may have worked around the bug (by disabling GPU rasterization for instance)? Also, was your coworker able to reproduce this more than once, and was there any pattern to the sites being browsed when this showed up? Thanks!
,
Jul 15 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/51630e3efbcde407cdc7c4e0f35cba88a2090601 commit 51630e3efbcde407cdc7c4e0f35cba88a2090601 Author: ericrk <ericrk@chromium.org> Date: Fri Jul 15 23:42:46 2016 Disable GPU raster for OSX 10.9 crbug.com/611310 contains a report of a rendering issue on 10.9. As I haven't been able to repro locally, I was hoping to get more data on this issue during beta/canary, but no additional reports have come in. In order to allow us to launch to stable with lower risk, this CL disables GPU raster on 10.9, which only accounts for ~7% of mac users. We may re-enable this for M53 Beta M54 Canary in order to track down the issue in question, and hopefully launch to 10.9 in M53. BUG= 611310 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2151393002 Cr-Commit-Position: refs/heads/master@{#405902} [modify] https://crrev.com/51630e3efbcde407cdc7c4e0f35cba88a2090601/gpu/config/software_rendering_list_json.cc
,
Jul 16 2016
The chrome://gpu information was captured after two reboots, so no, not while the problem was happening immediately. The problem did recur after the first reboot but cleared up at least for a time after the second. However, he didn't disable GPU rasterization or otherwise fiddle with Chrome settings. It's not clear whether it was triggered by a particular website, something about the state of the computer, or what. I'll ask him about what websites he saw the problem on, but I know it did appear on Gmail since that's the screenshot he sent.
,
Jul 18 2016
@ericrk I just reproduced the bug again today with my Chrome（53.0.2785.8 dev (64-bit)) when I was playing some HTML5 video.(I have switched the hardware acceleration back on). The symptoms are the same as I reported previously. While, this time, I think I can confirm another interesting phenomenon happened along with the bug: The Safari will encounter the similar displaying issues when the Chrome bug happens(only difference is that Chrome displaying black shades while Safari gets white out). It happened when I previously reported the Chrome bug but I didn't pay attention that time. It happened again this time with the Chrome bug thus I can confirm the existence. There was a program error report when I opened the Safari but I don't know if it's related. I am anyhow attaching the report with two Chrome://gpu pages.
,
Jul 18 2016
ps. my Safari version is Version 9.1.1 (9537.86.6.17)
,
Jul 18 2016
Would like to merge the fix into Beta to avoid issues on 10.9.
,
Jul 18 2016
[Automated comment] Less than 2 weeks to go before stable on M52, manual review required.
,
Jul 18 2016
Before we approve merge to M52, Could you please confirm whether this change is baked/verified in Canary and safe to merge?
,
Jul 18 2016
This is a very safe change (just updating a blacklist to be more conservative, no functional changes to code) - This has landed in canary and I've confirmed that it produces the expected results. I'm happy to let it bake for the rest of today and merge tomorrow morning/early afternoon.
,
Jul 18 2016
Ok, approving merge to M52 branch 2743 based on comment #45. Please merge tomorrow morning/early afternoon once it is baked in canary and it looks good. Thank you. Does this require a merge to M53 as well?
,
Jul 18 2016
Forgot about 53 - that should happen as well. Thanks for the reminder, added the request.
,
Jul 18 2016
Your change meets the bar and is auto-approved for M53 (branch: 2785)
,
Jul 18 2016
Eric, please merge the change to M52 & M53 asap, we are planning to cut the RC in the afternoon.
,
Jul 18 2016
I reported last week that my coworker got this problem. Now I'm getting what seems to be a similar one but with white patches as mentioned in Comment 40 (https://bugs.chromium.org/p/chromium/issues/detail?id=611310#c40). Screenshot and gpu.html file attached. The GPU information was captured as the problem was happening. This is on Version 54.0.2799.0 canary (64-bit) running on Mac OS X 10.11.6 beta, build 15G26a. I got the problem on YouTube. I didn't see it on a variety of other already open tabs. I opened a new YouTube tab and got it there, too. White rectangular patches flicker in and out of existence as you move the mouse around. Some of the patches remain as I moved the mouse. The main video window was unaffected. Some of the "stats for nerds" relating to the videos in question: Dimensions:854 x 480 * 2 Resolution:1280 x 720@60 Volume:100% Stream Host:r5---sn-vgqsdn7s Stream Type:https CPN:0Mt73gs8L8ib0Gkh Mime Type:video/mp4; codecs="avc1.4d4020" DASH:yes (298/140) Dimensions:854 x 480 * 2 Resolution:1920 x 1080@24 Volume:100% Stream Host:r3---sn-vgqsenlz Stream Type:https CPN:W3_vUyuWemUOEKqL Mime Type:video/webm; codecs="vp9" DASH: yes (248/251)
,
Jul 18 2016
Per offline discussion - This has already baked in Canary for a day (and it has been verified to be working as expected via UMA from that canary), so this is very low risk. Will merge to both M52 and M53 today, and will watch canary for another day to make sure nothing happens before the M52 roll tomorrow.
,
Jul 18 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/baae2f8fe610ab1e0115da7ea6ed18a3de410509 commit baae2f8fe610ab1e0115da7ea6ed18a3de410509 Author: Eric Karl <ericrk@chromium.org> Date: Mon Jul 18 20:08:19 2016 Disable GPU raster for OSX 10.9 crbug.com/611310 contains a report of a rendering issue on 10.9. As I haven't been able to repro locally, I was hoping to get more data on this issue during beta/canary, but no additional reports have come in. In order to allow us to launch to stable with lower risk, this CL disables GPU raster on 10.9, which only accounts for ~7% of mac users. We may re-enable this for M53 Beta M54 Canary in order to track down the issue in question, and hopefully launch to 10.9 in M53. BUG= 611310 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2151393002 Cr-Commit-Position: refs/heads/master@{#405902} (cherry picked from commit 51630e3efbcde407cdc7c4e0f35cba88a2090601) Review URL: https://codereview.chromium.org/2156003005 . Cr-Commit-Position: refs/branch-heads/2785@{#195} Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382} [modify] https://crrev.com/baae2f8fe610ab1e0115da7ea6ed18a3de410509/gpu/config/software_rendering_list_json.cc
,
Jul 18 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fe44ff56e7e2564a5f63ce78195946331a218f0a commit fe44ff56e7e2564a5f63ce78195946331a218f0a Author: Eric Karl <ericrk@chromium.org> Date: Mon Jul 18 21:53:30 2016 Disable GPU raster for OSX 10.9 crbug.com/611310 contains a report of a rendering issue on 10.9. As I haven't been able to repro locally, I was hoping to get more data on this issue during beta/canary, but no additional reports have come in. In order to allow us to launch to stable with lower risk, this CL disables GPU raster on 10.9, which only accounts for ~7% of mac users. We may re-enable this for M53 Beta M54 Canary in order to track down the issue in question, and hopefully launch to 10.9 in M53. BUG= 611310 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2151393002 Cr-Commit-Position: refs/heads/master@{#405902} (cherry picked from commit 51630e3efbcde407cdc7c4e0f35cba88a2090601) Review URL: https://codereview.chromium.org/2154343003 . Cr-Commit-Position: refs/branch-heads/2743@{#668} Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939} [modify] https://crrev.com/fe44ff56e7e2564a5f63ce78195946331a218f0a/gpu/config/software_rendering_list_json.cc
,
Jul 19 2016
Thanks for all the info. From what you are reporting (Safari messing up as well), it really sounds like this is a system-wide 10.9 issue (IOSurface allocation is somehow getting messed up for multiple apps on 10.9). I'm not sure that there's a great fix here, especially if this is beyond just Chrome. It may be that we just have to disable GPU rasterization on 10.9 for the time being. I've currently disabled GPU rasterization on 10.9 for all branches (Canary/Dev/Beta). I will re-enable in Canary during the Chrome 54 timeframe to see if we can track this down.
,
Jul 19 2016
The problem I had looks similar and is on Chrome Canary on OS X 10.11.6 beta, not 10.9. I haven't seen problems on Safari, though I only use that a few times a day.
,
Jul 19 2016
Thanks stshank@ - missed that comment - was the about://gpu you pasted taken from the same browser session where you experienced this issue? Not seeing any errors, so wondering if they may have been cleared by a restart. I'll spend some more time and see if I can reproduce the issue.
,
Jul 20 2016
Yep, as I mentioned, the chrome://gpu details were taken as the problem was happening. I saw white rectangles occluding content on YouTube, but later I also saw black rectangles occluding content on a CNET Roadshow page.
,
Jul 22 2016
Ok, there were two different issues here - there's an unknown 10.9 issue (mentioned earlier), and then there's a separate issue (on Canary only) that has to do with Partial raster code I was trying to enable. The issue reported by stshank@ strongly resembles the partial raster issue and should be fixed with crrev.com/406642. All issues should be resolved (either by blacklisting 10.9 or by fixing partial raster). Please re-open if these issues show up again on Canary.
,
Jul 30 2016
,
Jul 30 2016
@ericrk it turns out that the problem is still there after disabling the GPU Rasterization. After updated to the newest Chrome dev version(54.0.2810.2 (Official Build) dev (64-bit)), I switched the GPU acceleration back on and soon after when I was playing some HTML5 video, the displaying problem came back! And here is the Chrome://gpu report as attachment.
,
Jul 30 2016
The black tiles issue is a duplicate of issue 631485. The lower power video presentation path is leaking IOSurfaces somewhere, unreliably, on some machines. We have not yet seen this happen in person, so we're debugging with users' help.
,
Aug 1 2016
There were two issues in issue 631485. Duping instead over to the 10.9-specific issue with AVSampleBufferDisplayLayer in issue 632178 . This issue's fix will be pushed out with the M52 update this week. |
|||||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, May 12 2016