SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,095
Original Poster
Rep:
Quote:
NVIDIA Lands Fix To Avoid High CPU Usage When Using The KDE Desktop
Written by Michael Larabel in KDE on 26 March 2019 at 05:38 AM EDT.
For nearly six years there has been a bug report about high CPU load when using the NVIDIA proprietary driver causing high CPU load when running the KDE desktop and making use of double buffering. This issue has been finally resolved.
Bug #322060 has finally been closed following a recent commit to KWin by NVIDIA engineer Erik Kurzinger -- this is the same developer working on the EGLStreams code for KDE/KWin, albeit in this case this bug fix is on the X.Org side and unrelated to that effort........
......This didn't end up being a NVIDIA driver issue itself but rather KWin making an incorrect assumption about GLX's swap buffers operation...........
........The news coverage of NVIDIA figuring out the fix for KDE also happened to help GNOME developers in figuring out some long-standing similar troubles on their side. Canonical's prolific GNOME contributor, Daniel Van Vugt, has been looking at the NVIDIA high CPU usage bug and was able to confirm he already ended up having a previous but still open merge request that fixes the issue by accident.......
Last edited by cwizardone; 04-01-2019 at 09:55 AM.
April 10th, 2019 - Windows 425.30, Linux 418.52.03
New:
VK_EXT_pipeline_creation_feedback
VK_KHR_surface_protected_capabilities
Fixes:
Performance improvement for some content on Windows laptops
Fix rare startup instability on Windows
April 19th, 2019 - Windows 425.42, Linux 418.52.05
New:
VK_PRESENT_MODE_IMMEDIATE_KHR present mode is now available for Windows
VK_NV_ray_tracing is now available on the following non-RTX GPUs:
Pascal: TITAN Xp, TITAN X, GeForce GTX 1080 Ti, GeForce GTX 1080, GeForce GTX 1070 Ti, GeForce GTX 1070, GeForce GTX 1060 6GB
Volta: TITAN V
Turing: GeForce GTX 1660 Ti, GeForce GTX 1660
VK_NV_coverage_reduction_mode
Extension specification will be available soon.
Fixes:
Fix bug in vkCmdCopyImage with compressed images and some non-zero mipmap level dimensions
Fix bug with OpPhi and relaxed precision
Some minor performance improvements
Added support for the following GPU:
GeForce GTX 1650
GeForce GTX 1650 with Max-Q Design
GeForce GTX 1660 Ti with Max-Q Design
Fixed a bug that could cause the display to be driven at a low
resolution when configuring PRIME display offloading with
nvidia-xconfig --prime`.
Added HEVC YUV 4:4:4 decode support to the NVIDIA VDPAU driver.
Added the new per-decoder profile capability bit
VDP_DECODER_PROFILE_SUPPORTED_CHROMA_TYPES to the NVIDIA VDPAU driver.
Added new VdpYCbCrFormats VDP_YCBCR_FORMAT_Y_UV_444 and
VDP_YCBCR_FORMAT_Y_U_V_444 for accessing YUV 4:4:4 surfaces via
VdpVideoSurfaceGetBitsYCbCr() and VdpVideoSurfacePutBitsYCbCr()
in the NVIDIA VDPAU driver.
Added support for creation of YUV 4:4:4 video surfaces in the NVIDIA VDPAU driver.
Raised the minimum supported X.Org xserver version to 1.7 (video driver ABI version 6).
Updated the NVIDIA VDPAU driver to support allocating VDPAU video surfaces with explicit field or frame picture structure.
Added support for the GL_NV_vdpau_interop2 OpenGL extension, which allows VDPAU/OpenGL surface sharing with explicit field or frame picture structure. Picture structure selection by applications can avoid the need for implicit surface structure conversion by the OpenGL implementation.
Updated nvidia-installer for better compatibility with ncurses when libncurses.so.6 exposes the ncurses reentrant ABI, such as on openSUSE Leap 15 and SUSE Linux Enterprise 15.
Does the 430.09 driver contain the VK_EXT_host_query_reset extension, or not? I'm hearing that only the 418 series does, and I'm hearing that 430.09 does. Documentation isn't overly clear, either. (Application ran fine on the 430.09 driver, so I'm assuming that latest drivers include everything in 418.52.x?)
I don't see why Nvidia would remove an updated Vulkan specification once added. So yes, it's likely to be present in the newer driver releases...uunless Khronos drops it.
Updated nvidia-settings to allow continued interaction with other pages and help content while editing application profiles.
Added a new kernel module parameter, NVreg_RestrictProfilingToAdminUsers, to allow restricting the use of GPU performance counters to system administrators only.
Updated nvidia-installer for better compatibility with ncurses when libncurses.so.6 exposes the ncurses reentrant ABI, such as on openSUSE Leap 15 and SUSE Linux Enterprise 15.
Improved performance of the Vulkan title, DiRT4.
Added support for presentation from queue families which only expose VK_QUEUE_COMPUTE_BIT. This improves performance of Steam Play title, Wolfenstein II: The New Colossus.
Fixed a bug that could cause the display to be driven at a low resolution when configuring PRIME display offloading with `nvidia-xconfig --prime`.
Added HEVC YUV 4:4:4 decode support to the NVIDIA VDPAU driver.
Added the new per-decoder profile capability bit VDP_DECODER_PROFILE_SUPPORTED_CHROMA_TYPES to the NVIDIA VDPAU driver.
Added new VdpYCbCrFormats VDP_YCBCR_FORMAT_Y_UV_444 and VDP_YCBCR_FORMAT_Y_U_V_444 for accessing YUV 4:4:4 surfaces via VdpVideoSurfaceGetBitsYCbCr() and VdpVideoSurfacePutBitsYCbCr() in the NVIDIA VDPAU driver.
Added support for creation of YUV 4:4:4 video surfaces in the NVIDIA VDPAU driver.
Raised the minimum supported X.Org xserver version to 1.7 (video driver ABI version 6).
Updated the NVIDIA VDPAU driver to support allocating VDPAU video surfaces with explicit field or frame picture structure.
Added support for the GL_NV_vdpau_interop2 OpenGL extension, which allows VDPAU/OpenGL surface sharing with explicit field or frame picture structure. Picture structure selection by applications can avoid the need for implicit surface structure conversion by the OpenGL implementation.
Updated nvidia-installer to avoid problems with commands whose proper functionality may be dependent on system localization (e.g. via the LANG environment variable.) For example, some kernel configurations may produce unusable kernel modules if LANG is set to a language other than English.
Last edited by cwizardone; 05-14-2019 at 04:05 PM.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,095
Original Poster
Rep:
RE:
Quote:
Sat May 11 00:24:01 UTC 2019
x/libglvnd-1.1.1-x86_64-1.txz: Added.
This is the GL Vendor-Neutral Dispatch library, which allows multiple
drivers from different vendors to coexist on the same machine. When
libglvnd is present, the NVIDIA driver will not overwrite any system
files. Note that this is known to work when installing the NVIDIA driver
using the .run installer. Other methods may require adjustment.
This library is now a dependency of Mesa.
Thanks to Heinz Wiesinger.
FWIW, it is still necessary to blacklist the nouveau driver before installing the Nvidia driver.
Last edited by cwizardone; 05-14-2019 at 04:33 PM.
Nvidia-430.14 buildscripts submitted to Slackbuilds.org. Bug reports welcome!
Since libglvnd is now part of Slackware-current, this will be the last SBo release to include the non-glvnd libraries.
Does this mean the SBo release targets -current as well? If so, I did a clean install of -current multilib this week and saw some warnings (with Plasma 5, but it's not relevant) when the machine booted for the first time:
Code:
/sbin/ldconfig: /usr/lib/libGLX.so.0 is not a symbolic link
/sbin/ldconfig: /usr/lib/libOpenGL.so.0 is not a symbolic link
/sbin/ldconfig: /usr/lib/libGLdispatch.so.0 is not a symbolc link
/sbin/ldconfig: /usr/lib64/libGLX.so.0 is not a symbolic link
/sbin/ldconfig: /usr/lib64/libOpenGL.so.0 is not a symbolic link
/sbin/ldconfig: /usr/lib64/libGLdispatch.so.0 is not a symbolc link
I simply went in and made them symlinks manually. My setup:
1. Used 9 Jun 2019 slackware64-current-install-dvd.iso, don't install KDE
2. Set up multilib
Code:
lftp -c 'open https://slackware.nl/people/alien/multilib/ ; mirror -c -e current'
cd current
upgradepkg --reinstall --install-new *.t?z
upgradepkg --install-new slackware64-compat32/*-compat32/*.t?z
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
