8:42 a.m.
Hi,
To whoever is packaging the Nvidia GPU driver in Fedora / RPM Fusion,
overclocking support is currently broken. Not even nvidia-settings is
able to set a GPU core offset value via GUI despite a correct coolbits
value being set. This use to work some updates ago. Wayland is not being
used.
Command used to install the driver and related utils:
rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
xorg-x11-drv-nvidia-libs nvidia-settings nvidia-xconfig
xorg-x11-drv-nvidia-cuda xorg-x11-drv-nvidia-cuda-libs
Attempting to set an overclocking value via command line just results in
an "unknown error" message. nvidia-settings doesn't even know what's
going on in Fedora Silverblue 30.
Can this please be looked into & fixed?
9:48 a.m.
Le lun. 8 juil. 2019 à 16:30, Ty Young <youngty1997(a)gmail.com> a écrit :
Hi,
To whoever is packaging the Nvidia GPU driver in Fedora / RPM Fusion,
overclocking support is currently broken. Not even nvidia-settings is
able to set a GPU core offset value via GUI despite a correct coolbits
value being set. This use to work some updates ago. Wayland is not being
used.
Command used to install the driver and related utils:
rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
xorg-x11-drv-nvidia-libs nvidia-settings nvidia-xconfig
xorg-x11-drv-nvidia-cuda xorg-x11-drv-nvidia-cuda-libs
Attempting to set an overclocking value via command line just results in
an "unknown error" message. nvidia-settings doesn't even know what's
going on in Fedora Silverblue 30.
Can this please be looked into & fixed?
Not yet, you need to provide more useful info as stated in the RPM Fusion wiki
https://rpmfusion.org/Howto/NVIDIA#Bug_Report
Once we can determine the driver is in good state, a strace log of
nvidia-settings would be useful.
Please report to bugzilla.rpmfusion.org for now, but if it's
reproducible and not related to packaging, you will have to forward to
nvidia directly.
Thx
--
-
Nicolas (kwizart)
1:49 p.m.
Bug filed: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5307
The driver itself seems perfectly fine in that the system boots and OpenGL
works perfectly fine. Games are playable.
How do I output strace to a file directly? It spits out way too much info.
The bug is reproducible by doing a fresh install on a new downloaded ISO
but really the likelihood that this is a bug caused by Nvidia is slim to
none. Arch Linux(what I primarily use) has the same driver version and
everything works perfectly fine.
Regardless of whether or not this specific bug was by a packaging issue or
Nvidia, the way Fedora packages the Nvidia drivers is bad:
-nvidia-smi isn't specific to CUDA and is a core Nvidia library interface
that should come with the base driver as it does in Windows.
-nvidia-settings is the Linux alternative to Window's control panel and if
not included by default, *should* be included via a "meta" package for
desktop users.
-OpenGL not packaged with the driver(or again, installable via a meta
package)? Who wants a graphics driver without OpenGL/Vulkan support?
-it isn't clear if the command I posted(above) installs the 32-bit
libraries or not. Really, meta packages would go a long way in simplifying
GPU driver installs!
Neither Windows nor even other Linux distros fragment the driver this much.
You'd have to add 32-bit libraries alongside the 64 bit driver and 64 bit
libraries to equal Fedora's fragmented driver packaging in some distros.
Why?
On Mon, Jul 8, 2019 at 10:37 AM Nicolas Chauvet <kwizart(a)gmail.com> wrote:
Le lun. 8 juil. 2019 à 16:30, Ty Young <youngty1997(a)gmail.com>
a écrit :
>
> Hi,
>
>
> To whoever is packaging the Nvidia GPU driver in Fedora / RPM Fusion,
> overclocking support is currently broken. Not even nvidia-settings is
> able to set a GPU core offset value via GUI despite a correct coolbits
> value being set. This use to work some updates ago. Wayland is not being
> used.
>
>
> Command used to install the driver and related utils:
>
>
> rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
> xorg-x11-drv-nvidia-libs nvidia-settings nvidia-xconfig
> xorg-x11-drv-nvidia-cuda xorg-x11-drv-nvidia-cuda-libs
>
>
> Attempting to set an overclocking value via command line just results in
> an "unknown error" message. nvidia-settings doesn't even know
what's
> going on in Fedora Silverblue 30.
>
>
> Can this please be looked into & fixed?
Not yet, you need to provide more useful info as stated in the RPM Fusion
wiki
https://rpmfusion.org/Howto/NVIDIA#Bug_Report
Once we can determine the driver is in good state, a strace log of
nvidia-settings would be useful.
Please report to bugzilla.rpmfusion.org for now, but if it's
reproducible and not related to packaging, you will have to forward to
nvidia directly.
Thx
--
-
Nicolas (kwizart)
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
3:59 p.m.
Le lun. 8 juil. 2019 à 21:29, Ty Young <youngty1997(a)gmail.com> a écrit :
Bug filed: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5307
The driver itself seems perfectly fine in that the system boots and OpenGL works
perfectly fine. Games are playable.
How do I output strace to a file directly? It spits out way too much info.
The bug is reproducible by doing a fresh install on a new downloaded ISO but really the
likelihood that this is a bug caused by Nvidia is slim to none. Arch Linux(what I
primarily use) has the same driver version and everything works perfectly fine.
Regardless of whether or not this specific bug was by a packaging issue or Nvidia, the
way Fedora packages the Nvidia drivers is bad:
-nvidia-smi isn't specific to CUDA and is a core Nvidia library interface that should
come with the base driver as it does in Windows.
That's moot, but the comparison
with nvidia on Windows is not
relevant. if you want nvidia-smi, please install
xorg-x11-drv-nvidia-cuda
Previously nvidia-smi relied on any cuda lib, so it was moved on the
cuda side, but we can re-evaluate this, I take take a RFE.
With that said, the appropriate doc is here:
https://rpmfusion.org/Howto/NVIDIA
It is only mentioned to install akmod-nvidia and xorg-x11-drv-nvidia
that's the interface we rely on. (Everything else should be
auto-detected on purpose).
Also to wait a few for the module to build and install and reboot
(it's explicitly required).
-nvidia-settings is the Linux alternative to Window's control
panel and if not included by default, *should* be included via a "meta" package
for desktop users.
It's a separate package, but it is required by the drivers as
it's
mandatory indeed. So I don't understand the metapackage thing, it's a
solution for others distros, the Fedora ways is different. (virtual
provides , booleans dependencies, etc).
-OpenGL not packaged with the driver(or again, install-able via a
meta package)? Who wants a graphics driver without OpenGL/Vulkan support?
Well, some
people want to have selectables sub-packages as
appropriate, and the split made by RPM Fusion is carefully minded. But
we still welcome improvements.
-it isn't clear if the command I posted(above) installs the
32-bit libraries or not. Really, meta packages would go a long way in simplifying GPU
driver installs!
In regular Fedora, it will install the 32bit libraries on purpose
with
the nvidia driver if you have at least a package that requires 32bit
libGL. (same for cuda-libs).
Neither Windows nor even other Linux distros fragment the driver this
much. You'd have to add 32-bit libraries alongside the 64 bit driver and 64 bit
libraries to equal Fedora's fragmented driver packaging in some distros. Why?
Well, It could be worst. You could have sub-packages depending on the
need to run headless or without Xorg or without wayland dependencies
etc.
That's constraints you might not have, but a good packaging should
works everywhere.
With that said the rpm-ostree line you have used is silly with respect
to the need to llst all sub-packages. Can you point me to the
documentation you have used ?
Thx
--
-
Nicolas (kwizart)
1:46 a.m.
New subject: Nvidia GPU overclocking in Fedora Silverblue 30 is currently
broken
On 7/8/19 3:59 PM, Nicolas Chauvet wrote:
Le lun. 8 juil. 2019 à 21:29, Ty Young <youngty1997(a)gmail.com>
a écrit :
> Bug filed: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5307
>
> The driver itself seems perfectly fine in that the system boots and OpenGL works
perfectly fine. Games are playable.
>
> How do I output strace to a file directly? It spits out way too much info.
>
> The bug is reproducible by doing a fresh install on a new downloaded ISO but really
the likelihood that this is a bug caused by Nvidia is slim to none. Arch Linux(what I
primarily use) has the same driver version and everything works perfectly fine.
>
> Regardless of whether or not this specific bug was by a packaging issue or Nvidia,
the way Fedora packages the Nvidia drivers is bad:
>
> -nvidia-smi isn't specific to CUDA and is a core Nvidia library interface that
should come with the base driver as it does in Windows.
That's moot, but the comparison with nvidia on Windows is not
relevant. if you want nvidia-smi, please install
xorg-x11-drv-nvidia-cuda
Previously nvidia-smi relied on any cuda lib, so it was moved on the
cuda side, but we can re-evaluate this, I take take a RFE.
Arch simply includes it with the driver utils(see
https://www.archlinux.org/packages/extra/x86_64/nvidia-utils/files/).
The most equivalent package in Fedora would be the Nvidia-utils package
in Fedora(see
https://fedora.pkgs.org/30/rpmfusion-nonfree-x86_64/xorg-x11-drv-nvidia-l...)
The main thing is that noone will ever know that nvidia-smi is apart of
the CUDA package without digging through the provides listings.
With that said, the appropriate doc is here:
https://rpmfusion.org/Howto/NVIDIA
It is only mentioned to install akmod-nvidia and xorg-x11-drv-nvidia
that's the interface we rely on. (Everything else should be
auto-detected on purpose).
Also to wait a few for the module to build and install and reboot
(it's explicitly required).
That gets you a working driver but not OpenGL or any of the core Nvidia
driver utils/libs such as nvidia-smi, nvidia-settings, nvidia-xconfig,
etc. If you try to install Steam for example it will blow up real bad.
> -nvidia-settings is the Linux alternative to Window's control panel and if not
included by default, *should* be included via a "meta" package for desktop
users.
It's a separate package, but it is required by the drivers as it's
mandatory indeed. So I don't understand the metapackage thing, it's a
solution for others distros, the Fedora ways is different. (virtual
provides , booleans dependencies, etc).
If memory serves me correctly nvidia-settings *is* silently installed
but not explicitly. In other words, you can see and launch the
application in Gnome 3 without explicitly installing it but doing:
rpm-ostree install nvidia-settings
Will still work and "install" the package despite it already been
installed. I'll have to do another reinstall and install just the driver
to make sure. Could be smoking shrooms here but I remember it being there...
I'd like to pose the question though, is this really a good thing?
People don't like it when you silently install things behind their back.
A meta package(at least in the form I'm thinking of) is different as it
points to other packages and says to install those packages. If you want
more information on what those packages contain you should be able to
lookup what each package provides.
> -OpenGL not packaged with the driver(or again, install-able via a meta package)? Who
wants a graphics driver without OpenGL/Vulkan support?
Well, some people want to have selectables sub-packages as
appropriate, and the split made by RPM Fusion is carefully minded. But
we still welcome improvements.
...which is fine. A meta package(one that points to many sub packages)
would allow this.
> -it isn't clear if the command I posted(above) installs the 32-bit libraries or
not. Really, meta packages would go a long way in simplifying GPU driver installs!
In regular Fedora, it will install the 32bit libraries on purpose with
the nvidia driver if you have at least a package that requires 32bit
libGL. (same for cuda-libs).
That doesn't work for 32-bit games though since they don't use the
package manager and Steam does need 32-bit libs if not installed via
Flatpak. Yes, Steam provides many 32-bit libs but as they have said
during the whole Ubuntu 32-bit support mess, they still use system libs.
Which libs? I don't know, they'd probably have a good idea.
It isn't possible to play Proton games using Fedora Steam but is
possible with Flatpak Steam for example which I can only assume is
because of missing 32-bit libs. Installing Wine would probably pull in
the requires 32-bit libs since Proton is Wine...
> Neither Windows nor even other Linux distros fragment the driver this much. You'd
have to add 32-bit libraries alongside the 64 bit driver and 64 bit libraries to equal
Fedora's fragmented driver packaging in some distros. Why?
Well, It could be worst. You could have sub-packages depending on the
need to run headless or without Xorg or without wayland dependencies
etc.
That's constraints you might not have, but a good packaging should
works everywhere.
I've never heard of a situation where you would *just* want the driver
and *not* (at the very least) OpenGL support. Are there any examples?
Can CUDA be used without OpenGL?
With that said the rpm-ostree line you have used is silly with respect
to the need to llst all sub-packages. Can you point me to the
documentation you have used ?
https://fedora.pkgs.org/30/rpmfusion-nonfree-x86_64/
rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia = core working driver
rpm-ostree install xorg-x11-drv-nvidia-libs = OpenGL/Vulkan
rpm-ostree install nvidia-settings = explicitly installed nvidia-settings
rpm-ostree install nvidia-xconfig = x config utility for Nvidia
rpm-ostree install xorg-x11-drv-nvidia-cuda xorg-x11-drv-nvidia-cuda-libs = nvidia-smi
> Thx
>
3:25 a.m.
Le mar. 9 juil. 2019 à 09:42, Ty Young <youngty1997(a)gmail.com> a écrit :
For more clarity, please answer in bugzilla (either as new RFE or the
current report).
> With that said, the appropriate doc is here:
> https://rpmfusion.org/Howto/NVIDIA
> It is only mentioned to install akmod-nvidia and xorg-x11-drv-nvidia
> that's the interface we rely on. (Everything else should be
> auto-detected on purpose).
> Also to wait a few for the module to build and install and reboot
> (it's explicitly required).
That gets you a working driver but not OpenGL or any of the core Nvidia
driver utils/libs such as nvidia-smi, nvidia-settings, nvidia-xconfig,
etc. If you try to install Steam for example it will blow up real bad.
If you
install steam from flatpak, we cannot know which tools are
needed on the "host" side, so this become a documentation issue.
The "no OpenGL driver" is a situation that cannot arise with the
nvidia packaged driver because we rely default to install it. So it's
more probably a delay between the availability of the nvidia-gl
overlay ?
I'm not sure to understand what you mean here. Unless you mean the
OpenGL.so over the "legacy" libGL.so ?
>> -nvidia-settings is the Linux alternative to Window's
control panel and if not included by default, *should* be included via a "meta"
package for desktop users.
> It's a separate package, but it is required by the drivers as it's
> mandatory indeed. So I don't understand the metapackage thing, it's a
> solution for others distros, the Fedora ways is different. (virtual
> provides , booleans dependencies, etc).
If memory serves me correctly nvidia-settings *is* silently installed
but not explicitly. In other words, you can see and launch the
application in Gnome 3 without explicitly installing it but doing:
rpm-ostree install nvidia-settings
Will still work and "install" the package despite it already been
installed. I'll have to do another reinstall and install just the driver
to make sure. Could be smoking shrooms here but I remember it being there...
I'd like to pose the question though, is this really a good thing?
People don't like it when you silently install things behind their back.
A meta package(at least in the form I'm thinking of) is different as it
points to other packages and says to install those packages. If you want
more information on what those packages contain you should be able to
lookup what each package provides.
A meta package is yet-another-package that do
not provide any content.
It's totally spurious in Fedora packaging land. (over boolean deps,
virtual provides, etc).
The other point is that usually, you should enable the nvidia driver
from the "software" application. On regular fedora the
rpmfusion-nonfree-nvidia-driver is selectable from the interface
(don't know about silverblue, but it was intended).
You just have to install the driver by selecting it, so you don't even
have to worry about the gory details of the packaging name.
>> -it isn't clear if the command I posted(above) installs
the 32-bit libraries or not. Really, meta packages would go a long way in simplifying GPU
driver installs!
> In regular Fedora, it will install the 32bit libraries on purpose with
> the nvidia driver if you have at least a package that requires 32bit
> libGL. (same for cuda-libs).
That doesn't work for 32-bit games though since they don't use the
package manager and Steam does need 32-bit libs if not installed via
Flatpak. Yes, Steam provides many 32-bit libs but as they have said
during the whole Ubuntu 32-bit support mess, they still use system libs.
Which libs? I don't know, they'd probably have a good idea.
Theses libs are
know as soon as the support
It isn't possible to play Proton games using Fedora Steam but is
possible with Flatpak Steam for example which I can only assume is
because of missing 32-bit libs. Installing Wine would probably pull in
the requires 32-bit libs since Proton is Wine...
No, this is wrong, I have proton
support in regular Fedora. with the
steam package from RPM Fusion.
>> Neither Windows nor even other Linux distros fragment the
driver this much. You'd have to add 32-bit libraries alongside the 64 bit driver and
64 bit libraries to equal Fedora's fragmented driver packaging in some distros. Why?
> Well, It could be worst. You could have sub-packages depending on the
> need to run headless or without Xorg or without wayland dependencies
> etc.
> That's constraints you might not have, but a good packaging should
> works everywhere.
I've never heard of a situation where you would *just* want the driver
and *not* (at the very least) OpenGL support. Are there any examples?
Can CUDA be used without OpenGL?
Yes, only few cuda functions requires OpenGL
interrop,
>
> With that said the rpm-ostree line you have used is silly with respect
> to the need to llst all sub-packages. Can you point me to the
> documentation you have used ?
https://fedora.pkgs.org/30/rpmfusion-nonfree-x86_64/
Please reference
https://rpmfusion.org/Howto/NVIDIA or
https://download1.rpmfusion.org/nonfree/fedora/releases/30/Everything/x86...
But the above site is not affiliated to either fedora or rpmfusion and
might provide a totally in-accuratte information.
rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia = core working
driver
Nope, It's the default interface to install the driver not the
"Core" one.
rpm-ostree install xorg-x11-drv-nvidia-libs = OpenGL/Vulkan
False, it's a dependency of the xorg-x11-drv-nvidia, this is the usual
multilibs split, so it's very much a trivial packaging meme.
rpm-ostree install nvidia-settings = explicitly installed
nvidia-settings
Wrong, it's mandatory for any desktop usage so far it cannot be
bypassed.
rpm-ostree install nvidia-xconfig = x config utility for Nvidia
Wrong, it's a deprecated tool only needed for sample, it shouldn't be
used on fedora (or even documented, sorry but too much bad history on
this tool).
rpm-ostree install xorg-x11-drv-nvidia-cuda
xorg-x11-drv-nvidia-cuda-libs = nvidia-smi
Wrong, xorg-x11-drv-nvidia-cuda will
requires
xorg-x11-drv-nvidia-cuda-libs, (same packaging meme as above).
As I said I can evaluate a RFE to move the nvidia-smi to the default
set of packages, maybe enforce the -cuda to be installed by default
(with recommends).
But let's move to bugzilla.
Thx for the report.
--
-
Nicolas (kwizart)
5:42 a.m.
I've made a bug report for moving nvidia-smi here:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5308
If you install steam from flatpak, we cannot know which tools are
needed on the "host" side, so this become a documentation issue.
The "no OpenGL driver" is a situation that cannot arise with the
nvidia packaged driver because we rely default to install it. So it's
more probably a delay between the availability of the nvidia-gl
overlay ?
I'm not sure to understand what you mean here. Unless you mean the
OpenGL.so over the "legacy" libGL.so ?
I don't remember what the error was, I just remember that attempting to
launch Proton games(GTA 5) would fail under system Steam but worked under
Flatpak Steam. I'll have to reinstall it to see...
Theses libs are know as soon as the support
Can you rephrase this?
The other point is that usually, you should enable the nvidia driver
from the "software" application. On regular fedora the
rpmfusion-nonfree-nvidia-driver is selectable from the interface
(don't know about silverblue, but it was intended).
You just have to install the driver by selecting it, so you don't even
have to worry about the gory details of the packaging name.
Just installed Fedora 30 and I'm not seeing anything in Gnome Software
despite the repo existing and enabled from within Gnome Software itself(The
Nvidia and Steam one that is) besides Gnome 3 extensions for Nvidia.
Something is broke if Gnome Software is supposed to allow Nvidia GPU driver
installs. Nothing under "add-ons" either which i've seen
"hardware-drivers"
listed in Arch.
Regardless, that still doesn't install the *whole* Nvidia driver that you
would get in Windows or Ubuntu and what a user is probably wanting.
Nope, It's the default interface to install the driver not the
"Core" one.
(and etc)
That doesn't make any sense. If they were installed rpm-ostree would spit
out an error saying they where already requested or installed if you where
to install those packages step by step...
Could rpm-ostree not be registering that recommended or optional packages
are installed and are reinstalling them despite being installed? Pretty
sure even if you were to not reboot and keep installing ontop of the same
rpm-ostree image it will still resolve for the next image and error out...
False, it's a dependency of the xorg-x11-drv-nvidia, this is the
usual
multilibs split, so it's very much a trivial packaging meme.
Oh... That's kinda confusing. How is someone to know it includes multiarch
without looking into what it provides?
Wrong, xorg-x11-drv-nvidia-cuda will requires
xorg-x11-drv-nvidia-cuda-libs, (same packaging meme as above).
That seems really odd to me. If nvidia-cuda-libs is installed anyway and
nvidia-cuda requires it shouldn't it just be merged into the driver
package(or its libs?). I take it this is what would happen if
nvidia-smi(nvidia-cuda) was merged into the driver package itself or libs
right?
On Tue, Jul 9, 2019 at 4:22 AM Nicolas Chauvet <kwizart(a)gmail.com> wrote:
Le mar. 9 juil. 2019 à 09:42, Ty Young <youngty1997(a)gmail.com>
a écrit :
For more clarity, please answer in bugzilla (either as new RFE or the
current report).
> > With that said, the appropriate doc is here:
> > https://rpmfusion.org/Howto/NVIDIA
> > It is only mentioned to install akmod-nvidia and xorg-x11-drv-nvidia
> > that's the interface we rely on. (Everything else should be
> > auto-detected on purpose).
> > Also to wait a few for the module to build and install and reboot
> > (it's explicitly required).
>
>
> That gets you a working driver but not OpenGL or any of the core Nvidia
> driver utils/libs such as nvidia-smi, nvidia-settings, nvidia-xconfig,
> etc. If you try to install Steam for example it will blow up real bad.
If you install steam from flatpak, we cannot know which tools are
needed on the "host" side, so this become a documentation issue.
The "no OpenGL driver" is a situation that cannot arise with the
nvidia packaged driver because we rely default to install it. So it's
more probably a delay between the availability of the nvidia-gl
overlay ?
I'm not sure to understand what you mean here. Unless you mean the
OpenGL.so over the "legacy" libGL.so ?
> >> -nvidia-settings is the Linux alternative to Window's control panel
and if not included by default, *should* be included via a "meta" package
for desktop users.
> > It's a separate package, but it is required by the drivers as it's
> > mandatory indeed. So I don't understand the metapackage thing, it's a
> > solution for others distros, the Fedora ways is different. (virtual
> > provides , booleans dependencies, etc).
>
>
> If memory serves me correctly nvidia-settings *is* silently installed
> but not explicitly. In other words, you can see and launch the
> application in Gnome 3 without explicitly installing it but doing:
>
>
> rpm-ostree install nvidia-settings
>
>
> Will still work and "install" the package despite it already been
> installed. I'll have to do another reinstall and install just the driver
> to make sure. Could be smoking shrooms here but I remember it being
there...
>
>
> I'd like to pose the question though, is this really a good thing?
> People don't like it when you silently install things behind their back.
> A meta package(at least in the form I'm thinking of) is different as it
> points to other packages and says to install those packages. If you want
> more information on what those packages contain you should be able to
> lookup what each package provides.
A meta package is yet-another-package that do not provide any content.
It's totally spurious in Fedora packaging land. (over boolean deps,
virtual provides, etc).
The other point is that usually, you should enable the nvidia driver
from the "software" application. On regular fedora the
rpmfusion-nonfree-nvidia-driver is selectable from the interface
(don't know about silverblue, but it was intended).
You just have to install the driver by selecting it, so you don't even
have to worry about the gory details of the packaging name.
> >> -it isn't clear if the command I posted(above) installs the 32-bit
libraries or not. Really, meta packages would go a long way in simplifying
GPU driver installs!
> > In regular Fedora, it will install the 32bit libraries on purpose with
> > the nvidia driver if you have at least a package that requires 32bit
> > libGL. (same for cuda-libs).
>
>
> That doesn't work for 32-bit games though since they don't use the
> package manager and Steam does need 32-bit libs if not installed via
> Flatpak. Yes, Steam provides many 32-bit libs but as they have said
> during the whole Ubuntu 32-bit support mess, they still use system libs.
> Which libs? I don't know, they'd probably have a good idea.
Theses libs are know as soon as the support
> It isn't possible to play Proton games using Fedora Steam but is
> possible with Flatpak Steam for example which I can only assume is
> because of missing 32-bit libs. Installing Wine would probably pull in
> the requires 32-bit libs since Proton is Wine...
No, this is wrong, I have proton support in regular Fedora. with the
steam package from RPM Fusion.
> >> Neither Windows nor even other Linux distros fragment the driver this
much. You'd have to add 32-bit libraries alongside the 64 bit driver and 64
bit libraries to equal Fedora's fragmented driver packaging in some
distros. Why?
> > Well, It could be worst. You could have sub-packages depending on the
> > need to run headless or without Xorg or without wayland dependencies
> > etc.
> > That's constraints you might not have, but a good packaging should
> > works everywhere.
>
>
> I've never heard of a situation where you would *just* want the driver
> and *not* (at the very least) OpenGL support. Are there any examples?
> Can CUDA be used without OpenGL?
Yes, only few cuda functions requires OpenGL interrop,
> >
> > With that said the rpm-ostree line you have used is silly with respect
> > to the need to llst all sub-packages. Can you point me to the
> > documentation you have used ?
>
>
> https://fedora.pkgs.org/30/rpmfusion-nonfree-x86_64/
Please reference https://rpmfusion.org/Howto/NVIDIA or
https://download1.rpmfusion.org/nonfree/fedora/releases/30/Everything/x86...
But the above site is not affiliated to either fedora or rpmfusion and
might provide a totally in-accuratte information.
> rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia = core working driver
Nope, It's the default interface to install the driver not the "Core" one.
> rpm-ostree install xorg-x11-drv-nvidia-libs = OpenGL/Vulkan
False, it's a dependency of the xorg-x11-drv-nvidia, this is the usual
multilibs split, so it's very much a trivial packaging meme.
> rpm-ostree install nvidia-settings = explicitly installed nvidia-settings
Wrong, it's mandatory for any desktop usage so far it cannot be bypassed.
> rpm-ostree install nvidia-xconfig = x config utility for Nvidia
Wrong, it's a deprecated tool only needed for sample, it shouldn't be
used on fedora (or even documented, sorry but too much bad history on
this tool).
> rpm-ostree install xorg-x11-drv-nvidia-cuda
xorg-x11-drv-nvidia-cuda-libs = nvidia-smi
Wrong, xorg-x11-drv-nvidia-cuda will requires
xorg-x11-drv-nvidia-cuda-libs, (same packaging meme as above).
As I said I can evaluate a RFE to move the nvidia-smi to the default
set of packages, maybe enforce the -cuda to be installed by default
(with recommends).
But let's move to bugzilla.
Thx for the report.
--
-
Nicolas (kwizart)
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
3:19 p.m.
New subject: Nvidia GPU overclocking in Fedora Silverblue 30 is currently
broken
On 7/8/19 11:46 PM, Ty Young wrote:
rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia = core working
driver
rpm-ostree install xorg-x11-drv-nvidia-libs = OpenGL/Vulkan
rpm-ostree install nvidia-settings = explicitly installed nvidia-settings
rpm-ostree install nvidia-xconfig = x config utility for Nvidia
rpm-ostree install xorg-x11-drv-nvidia-cuda
xorg-x11-drv-nvidia-cuda-libs = nvidia-smi
Does rpm-ostree use dnf? Does it handle rich dependencies the same way?
3:57 a.m.
Not a developer nor do I know the inner workings of rpm-ostree but...
After doing yet another reinstall of Fedora Silverblue 30 I can confirm
that nvidia-settings *is* installed by doing:
rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia
Which it is supposed to. However, doing:
rpm-ostree install nvidia-settings
results in the package being installed with the output of:
https://pastebin.com/hE4BeNfi ...despite nvidia-settings already being
installed and usable.
In other words, packages weren't added but 1.9 GB was added to the
image(which was fast since this is a 5400RPM drive and it took like 2
minutes...). OK, so what happens if you try installing it again? It gives
an error: error: Package/capability 'nvidia-settings' is already requested
...and if you try removing it after it's been layered you get:
https://pastebin.com/6BGxZCz9
Again, it removed nothing but freed 79 MB of space. The output doesn't make
a whole lot of sense...
On Tue, Jul 9, 2019 at 4:07 PM Samuel Sieb <samuel(a)sieb.net> wrote:
On 7/8/19 11:46 PM, Ty Young wrote:
> rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia = core working driver
> rpm-ostree install xorg-x11-drv-nvidia-libs = OpenGL/Vulkan
> rpm-ostree install nvidia-settings = explicitly installed nvidia-settings
> rpm-ostree install nvidia-xconfig = x config utility for Nvidia
> rpm-ostree install xorg-x11-drv-nvidia-cuda
> xorg-x11-drv-nvidia-cuda-libs = nvidia-smi
Does rpm-ostree use dnf? Does it handle rich dependencies the same way?
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
1769
days inactive
1771
days old
8 comments
3 participants
participants (3)
-
Nicolas Chauvet -
Samuel Sieb -
Ty Young