Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 20 users
Status: Fixed
Closed: May 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment
Get rid of outdated gpu driver bug workarounds
Project Member Reported by, Mar 4 2014 Back to list
Just tested with MacOSX 10.9 with Intel/NVIDIA/AMD gpus, most workarounds are no longer necessary as the driver bugs have been fixed.

It would be nice to clean up the house once in a while.

Need to check Linux and Windows and do the same.
Project Member Comment 1 by, Mar 9 2014
r255833 | | 2014-03-09T07:09:00.902211Z

Changed paths:

Clean up outdated gpu driver bug workarounds for Mac 10.9

Tested with NVIDIA, AMD, Intel HD 3000/4000

Actually I also tested with 10.8.5, but at this point I don't
think it's worth making any changes on 10.8.5.

BUG= 349137 

Review URL:
Please, do the same on Linux. There are worlds of difference between Mesa 8.x and Mesa 10.0 or 10.1 when it comes to support properly AMD GPUs.

On a related note, please, for the love of whatever you care about most, DO NOT APPLY THE SAME WORKAROUNDS TO MESA/RADEON AND CATALYST. Those are two completely different beasts, with two different sets of bugs, and even two possible courses of action (Catalyst: workaround; Mesa: file a bug upstream and workaround, keeping track of the workaround because the bug may be fixed)
Comment 3 by, Mar 17 2014

Can you provide about:gpu content on whatever linux machines you have with AMD drive?

I'd love to separate the two group of drivers for Linux AMD, but don't have the time to install and test out mesa drivers.
My AMD-Linux machine is an E-450 (Radeon HD 6320 Wrestler), with Mesa 10.0.4. about:gpu is attached. I'm using Chrome 35 normally with no blacklist, but I reenabled the blacklist to send my report.

Here's what I have to comment.

"ATI/AMD cards with older or third-party drivers in Linux are crash-prone. Disabled features: ALL"
-  Issue 71381 : Filed on January 2011, against Catalyst. Doesn't affect me.
-  Issue 76428 : March 2011, against Mesa 7.something. I've never seen that.
-  Issue 73910 : February 2011, against Mesa 7.something. Ditto.
-  Issue 101225 : October 2011, against Catalyst. Unblacklist. Doesn't affect Mesa.
-  Issue 136240 : July 2012. Blacklist some Catalyst releases. Doesn't affect Mesa.

"Accelerated 2d canvas is unstable in Linux at the moment
Disabled Features: accelerated_2d_canvas"
Chrome 35 runs well here.

"Clear uniforms before first program use on all platforms: 124764, >349137<
Applied Workarounds: clear_uniforms_before_first_program_use
Mesa drivers in Linux handle varyings without static use incorrectly: 333885
Applied Workarounds: count_all_in_varyings_packing
Linux AMD drivers incorrectly return initial value of 1 for TEXTURE_MAX_ANISOTROPY: 348237
Applied Workarounds: init_texture_max_anisotropy"
Those are the only workarounds that Chrome applies when I unblacklist my card.

7.6 KB View Download
Google Chrome 35 with the "Disable GPU blacklist" flag enabled.

If you can, please, institute as an automated policy that every GPU blacklist related to Mesa expires in a year. Mesa 10.1 is expected to expose OpenGL 3.3 to all R600 and RadeonSI users (Radeon HD 2000 to Radeon R9 series)
7.0 KB View Download
Comment 7 by, Mar 25 2014
Thanks for providing the information.  I can definitely whitelist AMD with newer Mesa drivers.
Comment 8 by, Mar 31 2014
Enabled AMD with newer mesa drivers.  See 
Comment 9 by, May 7 2015
Status: Fixed
I think I cleaned up most of them. The remaining's removal might cause some risk that it's still affecting some users, so closing this for now.
I still see:
Linux AMD drivers incorrectly return initial value of 1 for TEXTURE_MAX_ANISOTROPY: 348237
Applied Workarounds: init_texture_max_anisotropy


But I'm using the mesa drivers, not the AMD ones.
9.7 KB View Download
Project Member Comment 11 by, Apr 11 2016
The following revision refers to this bug:

commit 4091119bc4913cdb22f720ee0b3f71db5c8a3ca8
Author: Philippe Hamel <>
Date: Thu Apr 07 20:45:50 2016

Add workaround to always call useProgram after a successful link.

This workaround is meant to reproduce the behavior of the
use_current_program_after_successful_link workaround in
Chromium ( )

The workaround was shown to be unnecessary for MacOSX 10.9 and
higher (

BUG= 349137 

Change-Id: I3023f053aa1593ba7044a889dd47746b8f7e0581
Reviewed-by: Geoff Lang <>
Commit-Queue: Jamie Madill <>
Commit-Queue: Geoff Lang <>


Project Member Comment 12 by, Apr 12 2016
The following revision refers to this bug:

commit fb8e85d5fa76718e228e17f05f93c6b9664c46f7
Author: geofflang <>
Date: Tue Apr 12 19:37:31 2016

Roll ANGLE d4102f0..52b09c2

BUG= 349137 ,600758


Review URL:

Cr-Commit-Position: refs/heads/master@{#386764}


Hi, it's me again. It's time for another round of GPU workaround pruning, since all my Intel and AMD powered boxes have Mesa 11.2.1 and lots of bugs have been fixed.

This is how I'm running with an old Intel machine, Core 2 Duo E4400 Conroe, G33 chipset. You see that, save for the native GPU buffers (not supported on this chipset, too old) and GPU rasterization (the same, also, super buggy), I'm running with no workarounds, and Chromium runs fantastic.

On a related note, I got similar results with my laptop, Core i5-4210Y and Intel HD 4200 Graphics (Haswell). No workarounds, I have enabled native GPU buffers, and GPU rasterization is still buggy, and so, rightly disabled. 

I'm attaching the chrome://gpu output for my old Intel machine.
6.6 KB View Download
Sign in to add a comment