This might be a duplicate of  Issue 648466 .

Submitter: can you please try quitting Canary, opening the Terminal, and running it via:

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --disable-features=WebGLImageChromium

Alternatively, to make 100% sure you're not just launching in the current running Canary instance:

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --disable-features=WebGLImageChromium --user-data-dir=/tmp/t2

Does this affect the behavior?

Note: I can't reproduce this on an older Mac Pro tower with AMD Radeon HD 7950 GPU.

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Hardware accelerated
Rasterization: Hardware accelerated
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
VPx Video Decode: Hardware accelerated
WebGL: Hardware accelerated
Driver Bug Workarounds
disable_framebuffer_cmaa
disable_multimonitor_multisampling
get_frag_data_info_bug
pack_parameters_workaround_with_pack_buffer
regenerate_struct_names
scalarize_vec_and_mat_constructor_args
set_zero_level_before_generating_mipmap
unfold_short_circuit_as_ternary_operation
unpack_alignment_workaround_with_unpack_buffer
use_intermediary_for_copy_texture_image
use_shadowed_tex_level_params
Problems Detected
Multisampling is buggy on OSX when multiple monitors are connected: 237931
Applied Workarounds: disable_multimonitor_multisampling
Unfold short circuit on Mac OS X: 307751
Applied Workarounds: unfold_short_circuit_as_ternary_operation
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
Mac drivers handle struct scopes incorrectly: 403957
Applied Workarounds: regenerate_struct_names
glGenerateMipmap fails if the zero texture level is not set on some Mac drivers: 560499
Applied Workarounds: set_zero_level_before_generating_mipmap
Pack parameters work incorrectly with pack buffer bound: 563714
Applied Workarounds: pack_parameters_workaround_with_pack_buffer
Alignment works incorrectly with unpack buffer bound: 563714
Applied Workarounds: unpack_alignment_workaround_with_unpack_buffer
copyTexImage2D fails when reading from IOSurface on multiple GPU types.: 581777
Applied Workarounds: use_intermediary_for_copy_texture_image
Mac Drivers store texture level parameters on int16_t that overflow: 610153
Applied Workarounds: use_shadowed_tex_level_params
Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198
Applied Workarounds: disable_framebuffer_cmaa
glGetFragData{Location|Index} works incorrectly on Max: 638340
Applied Workarounds: get_frag_data_info_bug
Version Information
Data exported 9/16/2016, 1:53:23 PM
Chrome version Chrome/55.0.2862.0
Operating system Mac OS X 10.11.6
Software rendering list version 11.13
Driver bug list version 8.98
ANGLE commit id 09cfac606ef5
2D graphics backend Skia/55 262052c9261a567f937ae05ade11ea7a3d280f4c
Command Line Args Chrome Canary.app/Contents/MacOS/Google Chrome Canary --flag-switches-begin --enable-nacl --flag-switches-end
Driver Information
Initialization time 50
In-process GPU false
Sandboxed true
GPU0 VENDOR = 0x1002, DEVICE= 0x679a ACTIVE
Optimus false
AMD switchable false
Driver vendor

Driver version 1.42.15
Driver date 
Pixel shader version 4.10
Vertex shader version 4.10
Max. MSAA samples 8
Machine model name MacPro
Machine model version 5.1
GL_VENDOR ATI Technologies Inc.
GL_RENDERER AMD Radeon HD 7950 OpenGL Engine
GL_VERSION 4.1 ATI-1.42.15
GL_EXTENSIONS GL_ARB_blend_func_extended GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader5 GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_shading_language_include GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_depth_bounds_test GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_mirror_clamp GL_EXT_texture_sRGB_decode GL_APPLE_client_storage GL_APPLE_container_object_shareable GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range GL_ATI_texture_mirror_once GL_NV_texture_barrier
Disabled Extensions 
Window system binding vendor

Window system binding version

Window system binding extensions

Direct rendering Yes
Reset notification strategy 0x0000
GPU process crash count 0
Compositor Information
Tile Update Mode Zero-copy
Partial Raster Enabled
GpuMemoryBuffers Status
ATC Software only
ATCIA Software only
DXT1 Software only
DXT5 Software only
ETC1 Software only
R_8 GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
BGR_565 Software only
RGBA_4444 Software only
RGBX_8888 Software only
RGBA_8888 GPU_READ, SCANOUT
BGRX_8888 GPU_READ, SCANOUT
BGRA_8888 GPU_READ, SCANOUT, GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
YVU_420 Software only
YUV_420_BIPLANAR GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
UYVY_422 GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT

Yes, launching canary 55.0.2868.0 canary (64-bit) with --disable-features=WebGLImageChromium fixes the problem.

Though the issue is still reproducible in this canary version when launched without the flag.

we managed to create simple test (in the attachment or http://appr.me/misc/test.html ). On the affected machines image is rendered only on two canvases (canvas1 and canvas2), while the third one in blank.

Deleted: test.html 2.5 KB

test.html 2.5 KB View Download

pavel.kakolin: thanks for the reduced test case.

Erik: is there still an experiment ongoing in Canary related to WebGLImageChromium? I thought it was turned on everywhere at this point.

We are seeing conflicting reports about whether the bug is present in Chrome 55 on these machines. This bug report indicates that it is; https://github.com/mrdoob/three.js/issues/9685#issuecomment-248841249 indicates that the bug is not present in M55.

Probably the safest approach would to be to add a GPU blacklist entry for WebGLImageChromium and blacklist it just on these two GPUs.

please note, that the issue on github is reported against 6750M, while this issue is reproduced on 6970M. not sure if they are considered "the same" in context of the problem.

I was assuming they have roughly the same behavior given that they're the same GPU family (Radeon 6000 series).

kbr: By default [and on Beta/Stable], WebGL Image Chromium is turned on. The experiment for 50/50 is still running on the Dev/Canary channels. I can see that that has been causing confusion. I'll turn the experiment off, but that also means that we will have pretty much no coverage of the non-Image Chromium.

Yes, that's confusing. Let's turn off the experiment and just make sure that we have pixel tests on our waterfall for the non-WebGLImageChromium path. But this means that there is definitely a problem on these older AMD GPUs that requires a GPU blacklist entry to be added. Can you own the task of creating that? https://codereview.chromium.org/2354423002/ is a recent simple CL adding and testing a new blacklist entry. Let me know if you're swamped.

I'm going to duplicate this into the other bug now since it's clear they're the same problem.