search

pauldmccarthy / fsleyes

This is a mirror. Feel free to use the issue tracker. PRs welcome.
https://git.fmrib.ox.ac.uk/fsl/fsleyes/fsleyes/
Other
22 stars 11 forks source link

High CPU usage #92

Closed Tj-Ward closed 2 years ago

Tj-Ward commented 3 years ago

After loading even a very small binary volume, single core CPU usage shoots to 100% and the program becomes almost unresponsive. It has been about 2 months since I last used FSLeyes on this computer so I am unsure which updates are causing the problem. I have tested on x11 and wayland.

OpenSUSE Tumbleweed (Gnome 41) Dell XPS 9310 (intel 11th gen i7 and Iris Xe gpu) Installed via conda

No errors visible when launched from the terminal.

Downgrading to fsleyes-1.1.0 in conda fixed the issue. I have not tried 1.2.

pauldmccarthy commented 3 years ago

Hi @Tj-Ward, a couple of questions:

Tj-Ward commented 3 years ago

Upgrading from 1.1.0 to 1.2.0 did not cause any problems. Upgrading again to 1.3.0 (latest) did not reproduce the problem either (python 3.7 by the way).

The only way I can reproduce the problem is creating a new conda environment and installing the latest version of FSLeyes.

To better describe the issue, loading a volume takes a little longer than usual. Once fully loaded, ~6 seconds, cpu drops down to normal. Attempting to change voxel location requires another ~2-6 seconds of full cpu for each change in coordinate. If I attempt to scroll through the volume quickly, it will cause long delays lasting up to several minutes where the application is unresponsive.

pauldmccarthy commented 3 years ago

Sounds like indexed_gzip is not getting installed for some reason - it is required for efficient navigation through gzipped 4D volumes. Can you share the output of conda list in both a behaving and mis-behaving environment?

Tj-Ward commented 3 years ago

Seems to be a mesalib version difference which fixed the problem for me. Both environments on my end have indexed_gzip. The broken environment has a few packages that the working env does not, the working env has no packages that the broken one does not.

Full lists attached: fsleyes_broken_list.txt fsleyes_list.txt

Summary of difference:

$ diff fsleyes_broken_list.txt fsleyes_list.txt < bzip2 < elfutils < gnutls < libarchive < libdrm < libmicrohttpd < libpciaccess < lzo < nettle < xorg-damageproto < xorg-fixesproto < xorg-glproto < xorg-libxdamage < xorg-libxfixes < xorg-libxrandr < xorg-randrproto < xorg-util-macros < xorg-xf86vidmodeproto

If I remove the extra packages and look at package versions:

$ diff fsleyeslist2.txt fsleyesbroken_list2.txt

< docutils 0.17.1 py37h89c1867_1 conda-forge > docutils 0.16 py37h89c1867_3 conda-forge < ipykernel 6.5.0 py37h6531663_1 conda-forge > ipykernel 6.5.1 py37h6531663_0 conda-forge < jinja2 2.11.3 pyh44b312d_0 conda-forge > jinja2 3.0.3 pyhd8ed1ab_0 conda-forge < mesalib 18.3.1 h590aaf7_0 conda-forge > mesalib 21.2.5 h0e4506f_2 conda-forge < parso 0.8.2 pyhd8ed1ab_0 conda-forge > parso 0.8.3 pyhd8ed1ab_0 conda-forge < typing_extensions 4.0.0 pyha770c72_0 conda-forge > typing_extensions 4.0.1 pyha770c72_0 conda-forge < wxpython 4.1.1 py37h28db2d3_2 conda-forge > wxpython 4.1.1 py37h28db2d3_3 conda-forge < xorg-libx11 1.7.2 h7f98852_0 conda-forge > xorg-libx11 1.6.12 h36c2ea0_0 conda-forge < xorg-libxext 1.3.4 h7f98852_1 conda-forge \< xorg-libxrender 0.9.10 h7f98852_1003 conda-forge > xorg-libxext 1.3.4 h516909a_0 conda-forge > xorg-libxrender 0.9.10 h516909a_1002 conda-forge

mesalib stood out to me so I tried creating an environment with 18.3.1:

$ conda create -n fsleyes_fixed -c conda-forge python=3.7 fsleyes mesalib=18.3.1

This worked for me.

Final output of conda list inside a fresh environment with mesalib18 fsleyes_conda_fixed_list.txt

pauldmccarthy commented 3 years ago

Right, it seems that the mesalib package on conda forge has recently changed somehow, such that it is now providing a copy of <conda-env>/lib/libGL.so, which is taking precedence over your OS-provided GL driver, and causing a software-based GL renderer to be used instead of your mesalib.

I need to look into this a bit more, and decide whether I should drop mesalib from the list of dependencies - FSLeyes only needs it for off-screen rendering, so the issue you have experienced is an unintentional side-effect.