GPU Acceleration for Chromium and VSCode

At meshcloud we believe in using the best tools money can buy. Most developers in our team use Linux Workstations with 2×27" 4K displays as their daily drivers. Working with text all day is certainly less straining on a 4K (or hi-dpi) display: the characters are sharper and more easily readable.

Unfortunately, Chromium and consequentally all electron based apps like VSCode disable GPU acceleration on Linux, claiming Linux GPU drivers too buggy to support. If you’re running a traditional Full-HD screen, falling back on (non-accelerated) software rendering is not a big deal. But for a 4K display your CPU has to push 4 times the amount of pixels and that can quickly lead to unpleasant input lag when working on code or a sluggish feeling browser. And all of that on powerful machines with tons of CPU cores, RAM and blazingly fast SSDs. Certainly not how a developer workstation should feel like in 2019.

With a clever combination of flags, you can force Chromium and VSCode to use GPU acceleration instead. You may experience a couple of graphic glitches here and there, but that’s a small price to pay for a much more responsive browser and text editor. The settings below worked for me and my machine running Fedora 30 and made Chromium and VScode much more enjoyable to use.

Chromium

For chromium, use these flags (depending on your distro, you can also write them to a launcher or config file):

chromium-browser --ignore-gpu-blacklist --enable-gpu-rasterization --enable-native-gpu-memory-buffers

This should results in the following acceleration status on chrome://gpu:

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
Out-of-process Rasterization: Disabled
Hardware Protected Video Decode: Hardware accelerated
Rasterization: Hardware accelerated
Skia Renderer: Disabled
Surface Control: Disabled
Surface Synchronization: Enabled
Video Decode: Hardware accelerated
Viz Service Display Compositor: Enabled
Viz Hit-test Surface Layer: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

VSCode

You can use the same flags on VScode (tested on v1.36) too to get GPU acceleration.

code --ignore-gpu-blacklist --enable-gpu-rasterization --enable-native-gpu-memory-buffers

You can check acceleration status using code --status while you have another instance of the editor already running. This should result in:

Version:          Code 1.36.1 (2213894ea0415ee8c85c5eea0d0ff81ecc191529, 2019-07-08T22:55:08.091Z)
OS Version:       Linux x64 5.1.17-300.fc30.x86_64
CPUs:             Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz (12 x 800)
Memory (System):  31.29GB (22.39GB free)
Load (avg):       1, 1, 1
VM:               0%
Screen Reader:    no
Process Argv:     --enable-gpu-rasterization --enable-native-gpu-memory-buffers
GPU Status:       2d_canvas:                     enabled
                  flash_3d:                      enabled
                  flash_stage3d:                 enabled
                  flash_stage3d_baseline:        enabled
                  gpu_compositing:               enabled
                  multiple_raster_threads:       enabled_on
                  native_gpu_memory_buffers:     enabled
                  oop_rasterization:             disabled_off
                  protected_video_decode:        unavailable_off
                  rasterization:                 enabled
                  skia_deferred_display_list:    disabled_off
                  skia_renderer:                 disabled_off
                  surface_synchronization:       enabled_on
                  video_decode:                  unavailable_off
                  viz_display_compositor:        disabled_off
                  webgl:                         enabled
                  webgl2:                        enabled

Note that I haven’t bothered with out of process rasterization yet. You can enable this using a flag too. But it appears not to be available on e.g. MacOS either, so I don’t expect it will make a big difference performance-wise.