Google Chrome unstable with Quadro GPU

[Tarek Sherif]

This might be more of an nvidia issue, but I thought I'd let you know as it affects the browser that's included by default (Google Chrome), and there's a chance it might affect other applications.

I'm using an M3800 developer edition, 4k screen, with the factory-installed Ubuntu 14.04. Ran all the system updates after starting up. Only significant manual update I made was to upgrade the GPU driver from nvidia-340 to nvidia-352 (the latest).

What I noticed is that when the Quadro GPU is active, I start seeing a lot of tearing artifacts in Chrome (see attached image). It seems to occur mostly when HTML elements are overlaid on each other, so I suspect it has to do with the browser's compositor. WebGL is also disabled, suggesting that Google has blacklisted this graphics configuration, feeling it's too unstable to use for Chrome. I tried starting Chrome using --disable-gpu-blacklist to confirm, and that got WebGL working but made my system *extremely* unstable. The entire system would simply freeze up from time to time if I had used Chrome (even after I had closed it).

I don't see these issues in Firefox, though WebGL does seem to run more slowly than I would expect (that could be due to other parts of the browser, though, e.g. the JavaScript engine).

I haven't seen other applications misbehave in the same way, but I suspect any applications that use the GPU in similar ways to Chrome would experience similar issues. I've included Chrome's GPU report (from chrome://gpu). The key item would seem to be "Older drivers are unreliable for Optimus on Linux". Let me know if you need any other info.

Graphics Feature Status
- Canvas: Software only, hardware acceleration unavailable
- Flash: Software only, hardware acceleration unavailable
- Flash Stage3D: Software only, hardware acceleration unavailable
- Flash Stage3D Baseline profile: Software only, hardware acceleration unavailable
- Compositing: Software only, hardware acceleration unavailable
- Multiple Raster Threads: Enabled
- Rasterization: Software only, hardware acceleration unavailable
- Video Decode: Software only, hardware acceleration unavailable
- Video Encode: Software only, hardware acceleration unavailable
- WebGL: Unavailable

Driver Bug Workarounds
- clear_uniforms_before_first_program_use
- force_cube_complete
- init_gl_position_in_vertex_shader
- init_vertex_attributes
- scalarize_vec_and_mat_constructor_args
- use_current_program_after_successful_link
- use_virtualized_gl_contexts

Problems Detected
- Accelerated 2d canvas is unstable in Linux at the moment
Disabled Features: accelerated_2d_canvas
- Older drivers are unreliable for Optimus on Linux: 131308, 363418
Disabled Features: all
- Accelerated video decode is unavailable on Linux: 137247
Disabled Features: accelerated_video_decode
- Always call glUseProgram after a successful link to avoid a driver bug: 349137
Applied Workarounds: use_current_program_after_successful_link
- Program link fails in NVIDIA Linux if gl_Position is not set: 286468
Applied Workarounds: init_gl_position_in_vertex_shader
- Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
- Linux NVIDIA drivers don't have the correct defaults for vertex attributes: 351528
Applied Workarounds: init_vertex_attributes
- Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
- MakeCurrent is slow on Linux with NVIDIA drivers
Applied Workarounds: use_virtualized_gl_contexts
- NVIDIA fails glReadPixels from incomplete cube map texture: 518889
Applied Workarounds: force_cube_complete

[Tarek Sherif (tsherif)]

Re-installing the nividia drivers (and completely purging older versions) seems to have rectified this problem.