Closed univerio closed 5 years ago
@univerio you might well be getting bitten by AMD radeon driver performance issues under Linux.
Someone else may want to chime in to confirm, but if I recall Sublime's UI prefers using hardware/3D acceleration and can fall back to software rendering where none is available.
Since Catalyst performance isn't great and you're using the open source (mesa) radeon driver, which is even slower this could well be the issue. It also explains why you don't see problems in Windows, because as we all know hardware accelerated gfx driver support on Windows is generally top-notch (for obvious reasons).
For me (Intel HD4000, Mint 17.1 Cinnamon) performance is smooth and stable, without nasty spikes. Are you running VM or native? At this point I doubt that this is anything but gfx related.
Perhaps a few others can comment on their experiences.
I'm running native (not VM).
What I don't understand is why this only happens in ST. Especially suspect is the fact that it appears to run (mostly) smoothly until after a period of idling. Compiz itself runs perfectly fine, and so does chrome (although I had to enable the "override software rendering list"). Is there something different about ST and its usage of OpenGL?
ST2 used software rendering exclusively, but I'm not sure about ST3; there have been "significant improvements" to rendering in ST3 generally but we don't have much in the way of specific info.
Edit: ST3's rendering used Cairo originally and moved over to Skia at build 3034. Skia uses hardware acceleration where available, but that doesn't mean that there isn't room for improvement in the way Sublime utilises it.
This might be somewhat reaching... since Chrome also uses Skia and you had to set "override software rendering list", that suggests that Skia may have a blacklist of platform drivers/gpus for which it kicks down to software rendering, as you suggested. Chrome has options to override this. If this option is handled by Skia, there may be some hope if Jon can add a setting to enable this in ST3 as well. Just a thought.
Some more Q's...
What resolution are you running?
Can you see if you experience the same issue in ST2? Try installing into a subfolder of your home using the .tar.gz download, load up the same files and report back whether the performance is significantly better, same or worse. If my hunch on Skia above is correct, I'd guess that you'll be seeing the same performance issue in ST2.
My resolution is 2560x1440.
You're right, the exact same thing happens in ST2, which means ST3 is also using software rendering? In that case, it seems bizarre that using fglrx gives even worse performance, if the GPU is not involved at all.
Is there a way to inspect / force hardware rendering? I'm running on Linux with open source NVIDIA nouveau driver
OpenGL renderer string: Gallium 0.4 on NV96 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.5.2
maybe that's the reason for the bad performance?
BTW: Chrome rendering is just fine on the same machine.
Same problem. Using Mint 17 and Radeon 8770
Same problem here.
Same problem:
Ubuntu 15.04 (XFCE), 8 GB Ram ST3 (3083) nVidia GeForce 610
Same issue for me, laggy scroll after idle:
Debian 8 Jessie ST3 (3083) nVidia GTX 560
Same problem for 2 configurations:
Config 1 Linux Mint 17 Intel i5-4690K nVidia GTX 960 using latest Nvidia drivers at this time
Config 2 (I removed the Nvidia graphics card) Linux Mint 17 Intel i5-4690K using Intel graphics drivers
Seeing ~100% CPU in both configs while scrolling any file.
Same issue here
Ubuntu 14.04 LTS AMD FX-8120, 8GB Ram Radeon R7 250 AMD fglrx driver
Same issue : Arch Linux - Enlightenment 20 Intel i7 950 Nvidia GeForce 8400 GS Rev. 2 using nvidia-340.96-3 driver st 3 - 3083
For the record, this no longer reproduces for me on the same machine. It's the same installation, albeit upgraded to 15.10 and many upgraded packages along the way.
$ uname -a
Linux jack-Desktop 4.2.0-23-generic #28-Ubuntu SMP Sun Dec 27 17:47:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
The only thing that I changed related to graphics is I installed this bleeding edge graphics drivers PPA. For you Debian, Ubuntu, or Linux Mint users perhaps you can try this (with open-source drivers, of course)? For @benfloyd it probably means you have to compile all those X libs from source.
Same issue, 100% CPU usage when scrolling with a fullscreen window ( resolution 3440x1440 )
Ubuntu 15.10 nvidia GTX 770 Intel i5-4670k
Latest nvidia drivers 261.28 ( had the issue with earlier drivers as well ) Sublime Text 3 Build: 3104
I noticed this too. I have a 2560x1440 monitor and the slow down is only noticeable when ST is maximized/fullscreen. I used perf top to analyze the problem and it looks like all time is spent in these functions:
58.72% sublime_text [.] 0x00000000001a800f 23.48% libpixman-1.so.0.30.2 [.] sse2_blt.part.10
It looks like ST is using cairo/pixman instead of skia now, or maybe it does its own drawing but uses pixman? And the SSE2 blit suggests that it's using software rendering. Of course we don't know what the symbol for the address inside the sublime text binary is.
I'm running ST dev build 3109 x64 on Ubuntu 14.04 with kernel 3.13.0-83-generic and nvidia driver 340.96. The system has an Intel Xeon E5-1650 with Nvidia Quadro K600.
Same issue, but I partly resolved it by downgrading graphics drivers.
Tried with ST: 3083, 3103, and 3109. Tried to revert to a newly installed state? No
OS: Ubuntu 14.04 GPU: NVIDIA Corporation GK107GLM [Quadro K1100M] Display resolution: 2560x1440 Graphics driver: 361.42 (installed via the graphics-drivers ppa: https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa)
uname -a
Linux james 3.13.0-79-generic #123-Ubuntu SMP Fri Feb 19 14:27:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Scrolling using the mouse wheel or page up/down stuttered and sublime would take several moments to redraw the file contents. Scrolling also caused sublime_text and Xorg to spike in CPU usage (as observed using top
). The problem became worse the larger Sublime text window was.
"scroll_speed": 0
in user preferences resolved the cpu spike and scrolling stuttering.I don't think changing the graphics driver would impact this issue in any way. If I run lsof -p sublime_text_pid I don't see any GLX/GL libraries loaded. For some reason ST refuses to use hardware compositing (i.e. OpenGL textures) on my system.
Here's a video demonstration that someone recorded on IRC: https://www.youtube.com/watch?v=pug-RRDHMpEtcc
Build: 3103, OS: arch
Do any of you notice a difference with build 3110?
I don't. Can we get some explanation of how ST does its rendering? jps mentioned that ST switched to using skia at some point but I see cairo also being used e.g. the pixman blit above is part of a cairo fill path. Is hardware accelerated rendering (e.g. caching rasterized content to GL textures) used in any way? If yes, is it gated behind a whitelist/blacklist of GPUs/drivers? Is this something we can toggle at run time?
Just downloaded 3110 and changed scroll_speed
back to 1. No difference, sorry :(
@sunnyps Sublime Text uses Skia for most 2D drawing operations, however font rendering is done using the native library for the OS.
On Linux, cairo/pixman is used for to draw the canvas on the screen. On OS X we use OpenGL since it is a fairly controlled environment. On Windows we use GDI.
The changes in 3110 have to do with optimizing the composition of the interface on the off screen buffers. If you are not seeing a difference with 3110 or 3111, then likely the performance issue is related to copying the offscreen buffers to the screen. If memory bandwidth or allocation was an issue, it should have been alleviated with the rendering improvements.
Because of those facts, and the fact that the issue only seems to affect some Linux users, and some users have noticed a difference with different drivers, I think collecting information about the machines affected may help in the process of seeing if there is a solution.
For those seeing the issue, could you try build 3111 in a clean state (no third-party packages), and then post:
To get to a clean state, follow the directions at https://www.sublimetext.com/docs/3/revert.html, just ensure you move your config folder so you can restore it afterwards.
I realize that some of you have provided this information before, but some are missing some bits, there have been changes in ST3, and it sounds like some drivers have improved.
@sunnyps I should clarify, Sublime Text uses cairo, but doesn't specifically do anything with OpenGL, so I presume it is using pixman. We use a canvas to compose the text and various graphical elements and then that buffer is copied using cairo.
Thanks for your work on this.
I reverted back to a clean state with build 3111 and am still seeing the issue. Here is the information you asked for:
The machine I am using is a Lenovo W541 and the graphics card is a NVIDIA Quadro K1100M. There is also onboard Intel graphics, but it is not in use.
lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K1100M] (rev a1)
Cairo:
sudo apt-cache policy libcairo2
libcairo2:
Installed: 1.13.0~20140204-0ubuntu1.1
Ubuntu 14.04
uname -a
Linux james 3.13.0-79-generic #123-Ubuntu SMP Fri Feb 19 14:27:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
@jjudd Thanks for taking the time to look into all of that! Are you running Unity?
I no longer have the machine having switched jobs, but I used to have a W520 with a Quadro 2000m, running 2x 2560x1600 via nouveau (it had better hotplug of external displays) and never noticed the issue, and usually I ran ST3 maximized. This was during 2013 to early 2014, and I was running Arch, which is a rolling release. All of that is just to say it seems that there can be differences even with similar machines!
Unfortunately I don't have a physical Linux machine right now to try different distros on. I am planning on doing some experimental work to see if we can work around it somehow.
I am running Gnome 3 at the moment.
gnome-shell --version
GNOME Shell 3.10.4
I'll drop into Unity real quick and see if it happens there.
I was running Gnome Shell also, so nothing different there.
Same thing on Unity
I'm experiencing the same exact issue jjudd described with build 3110 and on ward.
On my laptop which has an Intel HD 4400 GPU, Scrolling text on 3111 is silky smooth. I wanna say that it is Nvidia's fault but everything was fine before I upgraded to 3110. (upgrading to 3111 from 3110 made scrolling a little better)
Graphics card manufacturer and model matt@matt-disco:~$ lspci | grep VGA 03:00.0 VGA compatible controller: NVIDIA Corporation G84GL [Quadro FX 570](rev a1)
Driver name and version (nvidia, nouveau, catalyst, etc) NVIDIA Driver Version: 304.131
Version of cairo libcairo2: Installed: 1.14.6-1 Candidate: 1.14.6-1 Version table: *\ 1.14.6-1 500 500 http://gb.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status
Window size when you start noticing the lag Somewhere between a quarter and a third of the 1920x1200 monitor width
The color depth of your screen (16, 24, 32) 24
Linux distribution and version Ubuntu 16.04 LTS \n \l
If you see the stutter after no scrolling for a few seconds Happens every time I scroll
If you see the lagginess constantly (low fps) Only when scrolling
Additional Xorg and sublime_text processes jump to ~ 100% when scrolling. Sublime Text behaves in exactly the same manner in the xubuntu installation on this desktop.
I can confirm this too, when I use sublime in fullscreen in my 4k monitor scrolling is painfully slow, Xorg and Sublime jumps to 100% cpu usage, reducing the window size minimizes the stuttering.
Build 3103 Ubuntu 16.04 LTS NVIDIA GeForce GTX 660/PCIe/SSE2 (driver 361.42) Unity Desktop with resolution 3840x2160
Additional Setting "scroll_speed" to 0 is a workaround, however I still notice the Xorg/Sublime jumping to almost 100% cpu usage.
I don't have access to my Linux machine to test but does this line from Build 3112 changelog suppose to fix the issue? Linux: Fixed a regression that caused some graphical glitches
I think that changelog item is about the graphical glitch in rendering and not performance. That being said I can't reproduce the stutter in scrolling on build 3112 so maybe something else got fixed as well?
Scrolling responsiveness is much improved with 3112 using Nvidia 364.19 drive. Still not as good as windows though.
I have the same issue:
Dell M3800 Ubuntu 14.04 Nvidia Quadro K1100M, driver 361.42 Display res: 3840x2160
Currently using build 3103, but also tried on dev build 3112. It's clearly related to the number of pixels covered by the window. I noticed that if I drop my screen resolution to 1920x1080 AND set scroll_speed to 0 AND turn off the mini map, it starts to scroll at a reasonable speed.
Similar issue Lenovo W530 Debian SID Nvidia Quadro K100M driver 361.42, 364.19 Display Res 1600x900, 1920x1200 (with either, or both enabled) Version 2.0.2 2221 & 3114 libcairo: 1.14.6-1+b1 python-cairo: 1.8.8-2 window size: full screen depth 24
If you see the stutter after no scrolling for a few seconds
yes, text editing is laggy, but not nearly as bad as scrolling
If you see the lagginess constantly (low fps)
yes
So I beat on my laptop heavily, either gaming or working with virtual machines. I've noticed that sublime grinds to a halt when the system is under heavy gpu load (it seems to be indifferent to other cpu / memory pressure), i.e. when I'm editing files when a video game is rendering. This only started being a problem the last few months for me so I suspect either the recent change of my nvidia driver as the problem. I was on the same old release of sublime text 2 and updated to 3 to see if it might solve the problem, alias it barely did anything for me in this condition. While in this state, the text input is like that of a distant terminal with a high latency ~200-500ms response. If we start scrolling then the latency is between 2-10 sec
I had no problems with nvidia drivers on Ubuntu, or with Intel drivers, but after switching to the modesetting driver (Ubuntu 16.04, running at 4K resolution on an Intel HD Graphics 4600), scrolling (and everything else in Sublime) became extremely slow and choppy. I work around it with
"scroll_speed": 0,
"animation_enabled": false,
but scrolling a file still seems to lag behind input (Sublime Text is still handling the old input when there are already new scroll events.)
Sublime is close to outright useless on huge displays (3880x2160 in my case). This is an exceptionally capable system (Google Chrome, Intellij, etc --- all scroll without any performance overhead --- hell, i've been playing the new (for Linux) Tomb Raider release all weekend and I suspect it is slightly more strenuous then working with a file buffer. ;-)
My system is a Lenovo P70 running Ubuntu Xenial, the proprietary Nvidia drivers (v367.27), with 32 GB of ECC RAM and a 4-core (so, with HT, that'd be 8 logical threads) Intel Xeon E3-1505M v5 @2.8GHz --- with Btrfs running on top of an NVMe-based Samsung 960 Pro SSD..... The issue isn't in the hardware ;-).
Yet scrolling is often delayed by multiple seconds in Sublime. I've included a short screen recording to help demonstrate (any "jitter" or frame drop you may notice in normal operations like Gnome animations is a consequence of the screen recorder and not present in-person, though the behavior of Sublime is straight-up obvious regardless): https://youtu.be/74HTv_FY00Y
Hopefully a fix for this makes its way into a release soon. At this point in time (and I never thought I'd say this), but Intellij-based IDEs (despite the overhead of the JRE and their historical performance difficulty) operate light-years ahead of Sublime. Which is horribly disappointing and frustrating. ;-)
This behavior has not always been the case, either. I cannot pin-point an exact Sublime release, but I can say that performance was nominal (not great, but absolutely usable) pre-Skia-rewrite (https://en.wikipedia.org/wiki/Skia_Graphics_Engine). Post-Skia-rewrite...not so much.
uname -a
Linux oompa 4.4.0-24-generic #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
nvidia-settings -g (or glxinfo)
GLX Information for oompa:1.0:
direct rendering: Yes
[...]
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
[...]
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro M4000M/PCIe/SSE2
OpenGL version string: 4.5.0 NVIDIA 367.27
lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 16.04 LTS
Release: 16.04
Codename: xenial
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 94
model name : Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz
stepping : 3
microcode : 0x84
cpu MHz : 2701.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
bugs :
bogomips : 5615.86
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
[...]
dpkg -l | grep -P "(xorg|nvidia|wayland)"
ii gnome-session-wayland 3.18.1.2-1ubuntu1.16.04.1 amd64 GNOME Session Manager - GNOME 3 session
ii libva-wayland1:amd64 1.7.0-1 amd64 Video Acceleration (VA) API for Linux -- Wayland runtime
ii libwayland-client0:amd64 1.9.0-1 amd64 wayland compositor infrastructure - client library
ii libwayland-cursor0:amd64 1.9.0-1 amd64 wayland compositor infrastructure - cursor library
ii libwayland-dev 1.9.0-1 amd64 wayland compositor infrastructure - development files
ii libwayland-egl1-mesa:amd64 11.2.0-1ubuntu2 amd64 implementation of the Wayland EGL platform -- runtime
ii libwayland-server0:amd64 1.9.0-1 amd64 wayland compositor infrastructure - server library
ii nvidia-367 367.27-0ubuntu0~gpu16.04.1 amd64 NVIDIA binary driver - version 367.27
ii nvidia-opencl-icd-367 367.27-0ubuntu0~gpu16.04.1 amd64 NVIDIA OpenCL ICD
ii nvidia-prime 0.8.2 amd64 Tools to enable NVIDIA's Prime
ii nvidia-settings 367.18-0ubuntu0~gpu16.04.1 amd64 Tool for configuring the NVIDIA graphics driver
ii python3-xkit 0.5.0ubuntu2 all library for the manipulation of xorg.conf files (Python 3)
ii xorg 1:7.7+13ubuntu3 amd64 X.Org X Window System
ii xorg-docs-core 1:1.7.1-1ubuntu1 all Core documentation for the X.org X Window System
ii xorg-sgml-doctools 1:1.11-1 all Common tools for building X.Org SGML documentation
ii xserver-xorg 1:7.7+13ubuntu3 amd64 X.Org X server
ii xserver-xorg-core 2:1.18.3-1ubuntu2.2 amd64 Xorg X server - core server
ii xserver-xorg-input-all 1:7.7+13ubuntu3 amd64 X.Org X server -- input driver metapackage
ii xserver-xorg-input-evdev 1:2.10.1-1ubuntu2 amd64 X.Org X server -- evdev input driver
ii xserver-xorg-input-synaptics 1.8.2-1ubuntu3 amd64 Synaptics TouchPad driver for X.Org server
ii xserver-xorg-input-vmmouse 1:13.1.0-1ubuntu2 amd64 X.Org X server -- VMMouse input driver to use with VMWare
ii xserver-xorg-input-wacom 1:0.32.0-0ubuntu3 amd64 X.Org X server -- Wacom input driver
ii xserver-xorg-legacy 2:1.18.3-1ubuntu2.2 amd64 setuid root Xorg server wrapper
ii xserver-xorg-video-all 1:7.7+13ubuntu3 amd64 X.Org X server -- output driver metapackage
ii xserver-xorg-video-amdgpu 1.1.0-1 amd64 X.Org X server -- AMDGPU display driver
ii xserver-xorg-video-ati 1:7.7.0-1 amd64 X.Org X server -- AMD/ATI display driver wrapper
ii xserver-xorg-video-fbdev 1:0.4.4-1build5 amd64 X.Org X server -- fbdev display driver
ii xserver-xorg-video-intel 2:2.99.917+git20160325-1ubuntu1 amd64 X.Org X server -- Intel i8xx, i9xx display driver
ii xserver-xorg-video-nouveau 1:1.0.12-1build2 amd64 X.Org X server -- Nouveau display driver
ii xserver-xorg-video-qxl 0.1.4-3ubuntu3 amd64 X.Org X server -- QXL display driver
ii xserver-xorg-video-radeon 1:7.7.0-1 amd64 X.Org X server -- AMD/ATI Radeon display driver
ii xserver-xorg-video-vesa 1:2.3.4-1build2 amd64 X.Org X server -- VESA display driver
ii xserver-xorg-video-vmware 1:13.1.0-2ubuntu3 amd64 X.Org X server -- VMware display driver
ii xwayland 2:1.18.3-1ubuntu2.2 amd64 Xwayland X server
I've only spent 5 minutes with the build released today, but I am no longer stuttering when scrolling. CPU usage is still high when scrolling, but the stuttering seems to be gone.
I'm also seeing an incredible difference with this dev build. Much improved scrolling -- still some very slight stutter if I scroll as fast as possible, but nothing as severe as earlier.
Yes scrolling got much better with latest update. I was about to get an AMD card just for this issue :smile:
I have no lagging anymore with build 3120 (Fedora 24 x86_64, NVIDIA proprietary drivers).
I have extremely high CPU usage with build 3120 on Arch (core2duo, Intel GM965E)
Is there any news on this? My SublimeText 3 is almost impossible to use if my Titan X GPU is running at 100%. The scrolling stutters a lot (!). I have tried disabling all the plugins and testing when nothing is running on the GPU, but I have isolated the problem definitely to be the GPU utilization plus ST. As a work-around, is there any way to force rendering on on-board CPU graphics for ST?
ST Build: 3126 NVIDIA Driver: 361.77 OS: Linux Mint 17
Similar problems:
Sublime Text : Build 3126
Graphics Card: GTX 1080
CORE SPECS: DL580 G7 / 4 x E7-4870 / 512GB DDR3
Dual Monitor setup with two Xorg servers running with native driver.
HORIZONTAL MST : 5120 × 2880
VERTICAL OVER MST : 3840 × 2160
11:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce GTX 1080] (rev a1)
X.Org X Server 1.18.4
Nvidia Driver Version: 367.57
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial
Linux alfa 4.4.0-45-generic #66-Ubuntu SMP Wed Oct 19 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
nvidia-settings -g
...
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
...
OpenGL renderer string: GeForce GTX 1080/PCIe/SSE2
OpenGL version string: 4.5.0 NVIDIA 367.57
libcairo2:
Installed: 1.14.6-1
Candidate: 1.14.6-1
Version table:
*** 1.14.6-1 500
500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
100 /var/lib/dpkg/status
cat /proc/cpuinfo
processor : 0 ... 79
vendor_id : GenuineIntel
cpu family : 6
model : 47
model name : Intel(R) Xeon(R) CPU E7- 4870 @ 2.40GHz
stepping : 2
microcode : 0x37
cpu MHz : 1064.000
cache size : 30720 KB
physical id : 0
siblings : 20
core id : 0
cpu cores : 10
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt aes lahf_lm epb tpr_shadow vnmi flexpriority ept vpid dtherm ida arat
bugs : clflush_monitor
bogomips : 4794.87
clflush size : 64
cache_alignment : 64
address sizes : 44 bits physical, 48 bits virtual
power management:
libcairo2:
Installed: 1.14.6-1
Candidate: 1.14.6-1
Version table:
*** 1.14.6-1 500
500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
100 /var/lib/dpkg/status
Similar problem just showed up for me after installing Ubuntu Gnome 16.10. The laggy scroll is so bad that I'm about to drop Sublime as my editor.
Have the same problem on Ubuntu after some time after upgrading to 16.10.
den@elitebook ~[0] $ subl -v
Sublime Text Build 3126
den@elitebook ~[1] $ lspci | grep VGA
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Thames [Radeon HD 7550M/7570M/7650M]
den@elitebook ~[0] $ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 58
Model name: Intel(R) Core(TM) i7-3540M CPU @ 3.00GHz
Stepping: 9
CPU MHz: 2499.938
CPU max MHz: 3700.0000
CPU min MHz: 1200.0000
BogoMIPS: 5986.12
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 4096K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts
den@elitebook ~[0] $ uname -a
Linux elitebook 4.8.0-34-generic #36-Ubuntu SMP Wed Dec 21 17:24:18 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
I can't use Sublime like before.
Impossible to use when GPU is 100% busy with e.g. CUDA workload. Scrolls very slowly, in fact whole window is almost unresponsive, including the window decorations. Absolutely everything else in the system is responsive and working well. When CUDA-utilising process stops Sublime becomes fast again.
I've recently moved to a 4K screen in my system with an NVIDIA GPU, and scrolling takes a full second most of the time. I notice when scrolling that hte Xorg process jumps to 100% CPU usage, and the GPU jumps to 70% (from <5%).
Is ST passing large buffers around, or using something particularly inefficient operations for NVIDIA GPUs? I don't see the same problem in Intel systems, even though their GPUs are less powerful. If needed I can provide debug logging or other necessary info.
OS: Linux (mainly Ubuntu 15.04, but also reproduces on Fedora 22) ST Version: 3083 Tried to revert to a freshly installed state? Yes
Description
When scrolling, the framerate (normally ~60fps) will sporadically tank (down to 10-15fps), while simultaneously spiking the CPU usage for X to 100%, before returning to normal. This issue reproduces more consistently when the following conditions are met:
Speculation/Comments/Additional Information
Hardware specs: i7 5830k, 32GB RAM, Radeon R9 280 Graphics Drivers: radeon
Note that the issue does not reproduce on Windows on the same machine, so it's unlikely to be directly a hardware issue. However, it does (sort of) reproduce when using fglrx, albeit more dramatically, in that X is at 100% CPU usage all the time while scrolling.
As such, I speculate that ST sometimes falls back to software rendering for whatever reason, causing the stuttering.