New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a setting to disable gpu acceleration #15211

Open
SpaceShot opened this Issue Nov 8, 2016 · 53 comments

Comments

Projects
None yet
@SpaceShot
Copy link

SpaceShot commented Nov 8, 2016

  • VSCode Version: 1.7.1-1478180561
  • OS Version: ubuntu 16.04 LTS
    more info:
    Guest OS using VM on VirtualBox 5.0.26,
    Guest Additions installed,
    unity_support_test reports Unity 3D supported = yes (everything is lit up with green yes)

Steps to Reproduce:

  1. Start VSCode. This can be when docked in Launcher or launched via GUI or launched from command line
  2. Window appears, screen stays black. There might be grey rectangles or a blinking cursor, moving the window usually results in tearing.

Workaround
Launch from command line with code . --disable-gpu
If first window is launched this way, subsequent windows launched by any method follow option of currently open window(s)

Proposed Workaround
Once I identify that this machine can't run VSCode effectively without --disable-gpu, can we have a way to add to settings.json and be done with it?

Thank you for consideration

@SpaceShot

This comment has been minimized.

Copy link
Author

SpaceShot commented Nov 8, 2016

Forgot VS Code version (sorry). -fixed-

@bpasero

This comment has been minimized.

Copy link
Member

bpasero commented Nov 9, 2016

@SpaceShot are you saying that you see the first window with GPU disabled but subsequent windows are not?

@bpasero bpasero added this to the Backlog milestone Nov 9, 2016

@bpasero

This comment has been minimized.

Copy link
Member

bpasero commented Nov 9, 2016

There is app.disableHardwareAcceleration, but it needs to be set very early.

@SpaceShot

This comment has been minimized.

Copy link
Author

SpaceShot commented Nov 10, 2016

My proposal is that it would be nice to not have to set this every time from the command line because I know for this configuration (OS and guest VM) I have to run with --disable-gpu

As a minor complaint, this also means docking Code in the launcher is somewhat pointless because I need to go to terminal and use the --disable-gpu option.

I simply was adding more information that I tried a few things, such as opening with --disable-gpu and then seeing what happened if I opened more windows.

@bpasero bpasero changed the title Disable gpu setting in user settings Add a setting to disable gpu acceleration Nov 11, 2016

@bpasero bpasero removed this from the Backlog milestone Nov 11, 2016

@bpasero bpasero removed their assignment Nov 11, 2016

@billscheidel

This comment has been minimized.

Copy link

billscheidel commented Dec 10, 2016

I have the same configuration and disabled the gpu in a similar manner. But now I'm seeing really bad screen tearing on scroll. Basically every time I scroll, I need to stop scrolling then scroll a little bit up or down to refresh the ui and fix the issue. Is there any way to fix this?

@faustotnc

This comment has been minimized.

Copy link

faustotnc commented Sep 19, 2017

I'm having to do the same. Otherwise, VSCode won't respond until 0.6/2 seconds after performing any action like typing, scrolling or even opening small files (20 - 40 lines).

I know that opening the terminal, typing code --disable-gpu, and pressing enter seems like a really small set of steps, but when you have to do it every day, you realize that those steps are way more than just clicking on the app's icon to launch it.

Is there any chance that this option will be added to the settings?

@luncht1me

This comment has been minimized.

Copy link

luncht1me commented Sep 30, 2017

add --disable-gpu to your shortcut or alias code="code --disable-gpu"

@amitkvmz

This comment has been minimized.

Copy link

amitkvmz commented Dec 12, 2017

go to properties / compatibility / run this program in compatibility mode for windows 7.

And everything will be working as you want.

@GazizovMarat

This comment has been minimized.

Copy link

GazizovMarat commented Jan 4, 2018

@amitkvmz Thanks a lot. Also it works fine with the Windows 8 compatibility mode.

@fleps

This comment has been minimized.

Copy link

fleps commented Mar 21, 2018

I hope this gets added as setting also, because every time VSCode updates, it rewrites the shortcut so I lose the --disable-gpu.
The workaround is to create a manual shortcut, which is kind of a lame workaround you know =)

@mindplay-dk

This comment has been minimized.

Copy link

mindplay-dk commented Mar 22, 2018

Had to disable this to make a (window) screen recording with OBS.

I didn't find the disableHardwareAcceleration setting in User Settings?

I had to disable it by creating a custom shortcut with the --disable-gpu flag added.

@koffmoff

This comment has been minimized.

Copy link

koffmoff commented Apr 17, 2018

I'd also like a machine wide config of this. Running VSCode in Win10 VMWare Guest and can't get decent peformance without --disable-gpu. But the command line option is not an alternative when opening code from explorer (context menu, double clicking, etc.).

@scarolan

This comment has been minimized.

Copy link

scarolan commented Apr 19, 2018

I'm running VSC on a Surface Book 2, Windows 10 with WSL. The integrated terminal was super laggy and would even cause the entire program to lock up. After stumbling around and searching I discovered --disable-gpu which seems to have fixed the problem.

+1 for a way to permanently set this.

@fleps

This comment has been minimized.

Copy link

fleps commented May 9, 2018

Guys, now that VS Code is getting new versions / updates consistently we REALLY need this option to be part of the settings.

Every time I update VS Code it overwrites my shortcut removing --disable-gpu from it, and it's getting annoying having to remember to add it each time.

We need a better solution that is permanent, even if this is a separate shortcut that you guys create each update, whatever you think is best.

Please.

@chwzr

This comment has been minimized.

Copy link

chwzr commented May 9, 2018

how to make a custom shortcut? or how to add the commandline flag in the dock in osx?
please add a user setting to disable the gpu soon!!!
its so annoying to always open the terminal before opening a document from finder...

@maccurt

This comment has been minimized.

Copy link

maccurt commented Jun 9, 2018

Come on there has to be a fix for this!!

@johnbindel

This comment has been minimized.

Copy link

johnbindel commented Jul 29, 2018

Okay... I've just finished investigating.

So how can we make this work without the --disable-gpu flag?

It all starts at the bootstrap of VS Code: https://github.com/Microsoft/vscode/blob/master/src/main.js#L434

With a call to app.disableHardwareAcceleration() this problem seems to be fixed (though perhaps also setting "terminal.integrated.rendererType": "dom" in addition).

So how can we make this --disable-gpu thing a viable setting that a user can enable/disable? Well if we create the setting then we have a few options for how we can address it:

  1. Find environmentService.appSettingsPath and manually parse this setting on bootstrap (somewhere near https://github.com/Microsoft/vscode/blob/master/src/main.js#L434). This would occur once here and then would still need to be loaded again in ConfigurationService.

  2. Create another file prestartSettings.json for settings that are needed before electron starts. This file can be saved when the regular app setting changes (in reloader.contribution.ts). Then read these settings before electron starts in the bootstrap sequence.

  3. Refactor app settings loading before electron starts

  4. Introduce a custom build that has hardware acceleration disabled. Not a great solution-- it would double the number of build configurations.

  5. Don't fix this. Make developers work around the problem.

I'm open to feedback or other suggestions as some of these are fairly core changes. What do you think @joaomoreno, @bpasero, VS Code community?

@ebelew

This comment has been minimized.

Copy link

ebelew commented Aug 22, 2018

Would an environment variable be simpler than refactoring the entire configuration framework?

@johnbindel

This comment has been minimized.

Copy link

johnbindel commented Aug 22, 2018

@ebelew It would be simpler (and I think I would be happy enough with it) but can this issue be solved with an environment variable? Please post a proposed solution.

@AbstractFlame

This comment has been minimized.

Copy link

AbstractFlame commented Aug 23, 2018

@ebelew : just think about that how many people use this cool software and sum this little stresses of all users. Than you can see it is a big stress overall. You can make happier a lot of people with correct this very basic problem. (Using mouse wheel is one of the main functionality in a code editor).

@aleksijuvani

This comment has been minimized.

Copy link
Contributor

aleksijuvani commented Aug 27, 2018

Please add a configuration option for this. I have to always launch VS Code with --disable-gpu, but every time the app restarts due to an update, it won't remember the launch options that I used and will re-launch without --disable-gpu. Sometimes I forget this, and this is especially frustrating when I'm profiling a GPU-heavy application, because if VS Code has hardware acceleration enabled, it will skew the results significantly.

@perlun

This comment has been minimized.

Copy link

perlun commented Sep 3, 2018

@johnbindel

Create another file prestartSettings.json for settings that are needed before electron starts. This file can be saved when the regular app setting changes (in reloader.contribution.ts). Then read these settings before electron starts in the bootstrap sequence.

I think this option is perhaps one of the better ones. Clearly, this relates to "startup settings" for Electron and there might potentially (in the future) be other command line options we would like/need to add to Electron's startup. So, making some kind of mechanism to handle such things gracefully would be very nice.

(For reference: electron/electron#4380 which describes why I desperately need this flag.)

@darren-dev

This comment has been minimized.

Copy link

darren-dev commented Sep 13, 2018

Working on a PIXI (Browser 2D engine) application completely destroys the usability of VSCode unless the ---disable-gpu flag is set. How is this still not a feature after all this time?

@bpasero

This comment has been minimized.

Copy link
Member

bpasero commented Sep 13, 2018

People that face UI issues and need to run with --disable-gpu, I am releasing VSCode exploration builds with Electron 3.0.x and Chrome 66. If that builds fixes the issues for you, I would love to get more selfhosting and feedback. I keep these builds updated manually every 2-3 days with latest from master:

Download:

@johnbindel

This comment has been minimized.

Copy link

johnbindel commented Sep 13, 2018

Night-and-day difference for me, @bpasero! Thank you for following up on this issue. I hope Electron 3 / Chrome 66 will be a fix that works for everyone.

What timeframe might we expect to see this get to Insiders and then Mainstream release?

@bpasero

This comment has been minimized.

Copy link
Member

bpasero commented Sep 13, 2018

@johnbindel still maybe 2-3 months out. if you stick to the exploration build you will get insiders (= nightly) quality but everything should work fine. We in the team have some people also using these builds daily, so we would see breakage quite quickly and resolve it.

Night-and-day difference for me

Can you elaborate what exactly is better now?

@darren-dev

This comment has been minimized.

Copy link

darren-dev commented Sep 13, 2018

@bpasero Update from my side:

While developing for a PIXI game, my GPU usage peaks at around 96%, and on average is at 92% on a complex scene (So this would be considered an extreme case). I noticed an overall improvement in typing delay, (strangely) recompilation of webpack through the integrated console, and smoother scrolling.

The delays in the above will of course still be there due to the strain on the overall system (Though I should note there is no lag on moving the window as a whole, but there is definitely lag in moving the window sections inside VSCode [stable and your insider])

So winding down to a more manageable 70% GPU usage, the difference become less apparent

Hope this helps!

@johnbindel

This comment has been minimized.

Copy link

johnbindel commented Sep 13, 2018

@bpasero Previously scrolling in the console would grind VS code to a halt- so bad that I would not use the embedded console. This is now snappy, just as I would hope for. Back to integrated development!

Every 1-3 hours of use the application would be very(!) sluggish to scrolling and clicking. This could be resolved by minimizing or full-screen toggling the app and it would immediately be faster. I'm not seeing this behavior yet, and I'm optimistic that it is resolved.

@bpasero

This comment has been minimized.

Copy link
Member

bpasero commented Sep 13, 2018

Previously scrolling in the console would grind VS code to a halt- so bad that I would not use the embedded console. This is now snappy, just as I would hope for. Back to integrated development!

@Tyriar fyi on that, I thought we would fallback to DOM rendering (not sure that applies here).

Every 1-3 hours of use the application would be very(!) sluggish to scrolling and clicking. This could be resolved by minimizing or full-screen toggling the app and it would immediately be faster. I'm not seeing this behavior yet, and I'm optimistic that it is resolved.

Interesting, not sure I heard of that before. What OS are you on?

@darren-dev thanks for sharing

@Tyriar

This comment has been minimized.

Copy link
Member

Tyriar commented Sep 13, 2018

fyi on that, I thought we would fallback to DOM rendering (not sure that applies here).

There was a regression in 1.26 which is fixed in 1.27 that would draw everything in the terminal when only a subset of the lines were required so this was mixed in with some of the GPU issues. Everything should be back to normal now and the fallback notification occurs if frames are slow.

@kittle31

This comment has been minimized.

Copy link

kittle31 commented Sep 14, 2018

This worked for me -- maybe it can help others

On my windows PC, i have an nvidia card, so I added a profile for vs code in the control panel, and disabled all the anti-alias settings. All the text is now clear and readable.

@leecommamichael

This comment has been minimized.

Copy link

leecommamichael commented Sep 24, 2018

People that face UI issues and need to run with --disable-gpu, I am releasing VSCode exploration builds with Electron 3.0.x and Chrome 66. If that builds fixes the issues for you, I would love to get more selfhosting and feedback. I keep these builds updated manually every 2-3 days with latest from master:

Download:

* macOS: [Download](https://az764295.vo.msecnd.net/exploration/86ff36a1cca2c5763c9c57bda2ec8d3443538c89/VSCode-darwin-exploration.zip)

* Linux: [Download](https://az764295.vo.msecnd.net/exploration/86ff36a1cca2c5763c9c57bda2ec8d3443538c89/code-exploration_1.28.0-1536650436_amd64.deb)

* Windows: [Download](https://az764295.vo.msecnd.net/exploration/86ff36a1cca2c5763c9c57bda2ec8d3443538c89/VSCodeUserSetup-x64-1.28.0-exploration.exe)

This fixed my lag experienced in 43137, there is a general issue with macOS' WindowServer process eating CPU, but not in this build. Thank you!!! Scrolling is finally smooth and responsive again!

@givethemheller

This comment has been minimized.

Copy link

givethemheller commented Oct 14, 2018

Why don't we allow this just for the sake of battery performance?

I run an older MBP - it's been upgraded to keep up with modern hardware, only efficiency being battery life (it's been replaced recently). Why should I kill 45 min to an hour of operation for GPU acceleration?

@thesleort

This comment has been minimized.

Copy link

thesleort commented Oct 14, 2018

@givethemheller usually you want GPU acceleration, since the GPU is more efficient than your CPU at certain tasks, and therefore will give you more battery life than disabling the GPU. Problem is that sometimes the GPU is not told properly what to do and how to do it, which can result in graphical artefacts. In these cases it is nice to be able to disable the GPU acceleration.

@givethemheller

This comment has been minimized.

Copy link

givethemheller commented Oct 15, 2018

Well, I guess to that end - why would I want to be using the discrete GPU instead of the chip-set GPU? I would expect there to be performance increase on the discrete GPU with a hit to battery life vs the on board chip set gpu.

@aurelienrb

This comment has been minimized.

Copy link

aurelienrb commented Oct 17, 2018

I use VSCode from virtual machines with Virtual Box and I can confirm that it still runs very slowly if not started with the --disable-gpu option.
Having a dedicated option would make things simpler than manually creating and patching Gnome launchers.

@Craig-Macomber

This comment has been minimized.

Copy link

Craig-Macomber commented Dec 12, 2018

People that face UI issues and need to run with --disable-gpu, I am releasing VSCode exploration builds with Electron 3.0.x and Chrome 66. If that builds fixes the issues for you, I would love to get more selfhosting and feedback. I keep these builds updated manually every 2-3 days with latest from master:

Download:

On my Linux setup I got all kinds of graphical issues and bad performance (mostly disappearing rectangles of UI including the terminal, text editors, bottom bar, but also other parts of the UI) when I moved to an AMD graphics card from my Nvidia one (I changes a few things at the same time, but I suspect it was the GPU and driver swap). --disable-gpu does not fix my problems, however your exploration build fixes it: its fast and renders correctly :) (and I have no other work around, I was going to have to get a different editor!)

@Tyriar

This comment has been minimized.

Copy link
Member

Tyriar commented Dec 12, 2018

@Craig-Macomber I guess Chrome 58 was just really buggy on your hardware. FYI if you see that in the terminal you should be able to work around it by switching the renderer to use the DOM:

"terminal.integrated.rendererType": "dom"
@shalkam

This comment has been minimized.

Copy link

shalkam commented Dec 14, 2018

So, the --disable-gpu flag doesn't work at all for me, I guess it's no longer supported in electron.js
I had to go and add app.disableHardwareAcceleration(); directly into /usr/share/code/resources/app/out/main.js

like this app.on("will-finish-launching",function(){app.disableHardwareAcceleration();
inside the callback for will-finish-launching event

@rpavlik

This comment has been minimized.

Copy link

rpavlik commented Dec 17, 2018

People that face UI issues and need to run with --disable-gpu, I am releasing VSCode exploration builds with Electron 3.0.x and Chrome 66. If that builds fixes the issues for you, I would love to get more selfhosting and feedback. I keep these builds updated manually every 2-3 days with latest from master:
Download:

On my Linux setup I got all kinds of graphical issues and bad performance (mostly disappearing rectangles of UI including the terminal, text editors, bottom bar, but also other parts of the UI) when I moved to an AMD graphics card from my Nvidia one (I changes a few things at the same time, but I suspect it was the GPU and driver swap). --disable-gpu does not fix my problems, however your exploration build fixes it: its fast and renders correctly :) (and I have no other work around, I was going to have to get a different editor!)

I had the same issue (chunks disappearing on an AMD RX580 on Linux), which I had blamed on a bad GPU - but now the GPU has been replaced and works on Windows, and still got chunks. This test build (exploration 1.28.0) seems to work well so far, but am now updating and am transfered to Insider - will update if it changes.

@perlun

This comment has been minimized.

Copy link

perlun commented Jan 29, 2019

@shalkam Something like this, or do you mean straight inside the will-finish-launching handler?

    app.on("will-finish-launching", function () {
        app.on("open-url", t)
        app.on("will-finish-launching",function() { app.disableHardwareAcceleration(); }) // <-- added line
    }), global.getOpenUrls = function () {
        return app.removeListener("open-url", t), r
    }

FWIW, the problem has gotten worse for me. I put my (Linux) desktop to sleep every night when heading home from work; every morning now, VSCode is unresponsive and can't even be closed with the UI controls. I have to killall code to restart it. Highly annoying.

Here is the exact version I'm running:

$ code --version
1.30.2
61122f88f0bf01e2ac16bdb9e1bc4571755f5bd8
x64

nVidia GPU; I recently upgraded my Debian to latest packages (I am running unstable), so this might affect the problem also. Here is the package version:

$ dpkg -l nvidia-driver
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  nvidia-driver  390.87-2     amd64        NVIDIA metapackage
@shalkam

This comment has been minimized.

Copy link

shalkam commented Feb 13, 2019

@perlun you're adding will-finish-launching twice, which is wrong
You just need to add this part app.disableHardwareAcceleration(); only after the curly bracket

app.on("will-finish-launching",function(){app.disableHardwareAcceleration()
@perlun

This comment has been minimized.

Copy link

perlun commented Feb 17, 2019

@shalkam Thanks! Yes, the way I wrote it looked kind of insane. =)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment