Earlier quoted context omitted.
the open kernel driver also fundamentally breaks the limitation about geforce gpus not being licensed for use in the datacenter. that provision is a driver provision and CUDA does not follow the same license as the driver... really the only significant limitation is that you aren't allowed to use the CUDA toolkit to develop for non-NVIDIA hardware, and some license notice requirements if you redistribute the sample p…
Can you link the source code for CUDA please? Thanks. Edit since I'm being downvoted: I did search for it and could not find it.
NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
251–259 of 259 posts
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#252Earlier quoted context omitted.
That's simply not how LLMs work, and are actually awful at reverse engineering of any kind.
Are you saying that they cant explain the contents of machine code in human readable format? Are you saying that they can’t be used in a system that iteratively evaluates combinations of inputs and check their results?
Just that they're horrible at it
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#253Earlier quoted context omitted.
that's what nvidia told everyone in mar 23... but there's a reason why h800 were included last minute on the embargo in oct 23.
That's not what NVIDIA claimed, that's what I have personally verified. > there's a reason why h800 were included last minute No. Oct 22 restrictions are by itself significantly easier than Oct 23 one. NVIDIA just need to kill 4 NVLink lanes off A100 and you get A800. For H100 you kill some more NVLink until on paper NVLink bandwidth is roughly at A800 level again and then voila. BIS is certainly pissed off by NVIDIA…
I see. thanks for the details.
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#254Earlier quoted context omitted.
Same, can't understand people evangelizing Wayland I have a laptop 10.1 2560x1600 with a 32' monitor, and another 27', never had any problem Wayland has practically no advantages, you have to spend hours configuring, and still have apps working badly... they are always just a month away from having "everything" fixed Maybe Wayland is the future but I'll keep using Xorg distros for the foreseeable future
You guys must be using some different X11 than the rest of us. Basically, with X11 and hidpi, all you can do is to set up the system to announce dpi with certain value and hope, that the clients will cope. Some can (I know of exactly two of them: Chrome and Firefox), others will up bump up the font size and hopefully are using a layout, so the window sizes will adjust to accommodate the textboxes, but all the non-tex…
It's possible there might be a misunderstanding as to what "working" means. For me, if there's vaseline anywhere on my screen, that's strictly worse than tiny fonts I need a magnifying glass for. I'd rather have no scaling than nearest neighbour interpolation.
> You guys must be using some different X11 than the rest of us.
Speak for yourself, I know plenty of people who are able to get non-96-DPI working on X with just Xft.dpi and some environment variables.
> Some can (I know of exactly two of them: Chrome and Firefox), others will up bump up the font size and hopefully are using a layout, so the window sizes will adjust to accommodate the textboxes, but all the non-text assets will stay low-res how they were, because they do not have any other.
This is an application bug (non text assets not getting scaled up) and will hardly be fixed with anything other than vaseline the text and icons on an equivalently non-DPI-change supporting application on wayland.
The vast majority of modern software works just fine.
> Apps for remote desktop access or vm console won't be able to display remote/vm correctly.
Does Wayland solve this in any other way other than to vaseline it all up? xfreerdp has /scale. When it comes to VMs I use through spice you just set their DPI settings individually to match your host, then you get nice scaling without vaseline. AFAIK in wayland this all gets vaselined.
> And this is just the hidpi issue with single display. Won't go into the problems when running with multiple displays, with different dpi.
Don't run multiple displays with different DPI. It's an unsolvable problem in the X11/Wayland ecosystem. You need to keep everything as postscript or something equivalent all the way up until the point you know which monitor it's rendered on.
Of all the things Wayland could have actually gone out and fixed, this is one they eschewed in favour of "ah screw it, just give all the applications some graphics buffers and let them figure it out".
> I also do not have a faintest idea of what "setting up Wayland" might mean. What did you set up? How? The only thing that needs to "set up" is to pick a wayland session in the display manager. There's no xorg.conf for wayland, setting up drivers, etc. What did you configure "for hours"?
I know exactly what guilhas means.
Some people are not content with Ubuntu Gnome at a integer scaling factor, they're running highly bespoke setups where everything from the display manager to the screen-grab stuff is customized or custom written. So you spend a lot of time and effort switching to sway, switching to wayland, switching to wayland native versions of a terminal, fixing firefox so it starts in wayland mode, fiddling with the nonsensical scaling settings to actually get firefox to render at the right size, figuring out how to get your screenshot binding to work again, figuring out how to get all your applications to start in the right version, being dismayed when something which still uses X11 runs in XWayland and looks like vaseline because of weird design decisions which are incomprehensible (meanwhile that same application with Xft.dpi set to the right value renders flawlessly).
Eventually you get it all back up and running and you play with it for a week and you spot 20 things which subtly work differently or outright break, you spend hours looking for a solution to only get half of it working.
Right now wayland works mostly fine for the Ubuntu Gnome user or the Kubuntu user (except issues getting non-integer scaling factors working or issues with things needing XWayland) but it's nowhere near as easy to get up and running for someone running a non-standard setup.
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#255Throwing the tarball over the wall and saying "fetch!" is meaningless to me. Until they actually contribute a driver to the upstream kernel, I'll be buying AMD.
You can just use Nouveau and NVK for that if you just need workstation graphics (and the open-gpu-modules source code/separate GSP release has been a big uplift to Nouveau too, at least.)
IIRC hardware video decoding of HEVC didn't work for me with nouveau
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#256How is the NVIDIA driver situation on Linux these days? I built a new desktop with an AMD GPU since I didn't want to deal with all the weirdness of closed source or lacking/obsolete open source drivers.
I got my nvidia 1060 back then during the crypto crysis when the price of AMD GPUs were inflated due to miners. Hesitant and scepital about Linux support, I upgraded the same machine with that GPU since 2016 von Ubuntu 14.04, to 18.04 and now 24.04 - without any nvidia driver issues anytime whatsoever. When I read about issues with nvidias drivers, it is mostly people with rare distro or rolling release ones, with changing kernel versions very frequently and failure to recompile with the binary drivers. For LTS distros you will likely have no issues.
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#257Earlier quoted context omitted.
why switch to amd and not just switch to X? :D
once you go Wayland you usually don’t go back :)
I tried wayland (on amd) and found it annoying to work with compaired to x11 without any apparent benefits, wayland is definitely the future, but i don't think the future is now
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#258Earlier quoted context omitted.
It is meaningful because, as you note, it enables a fully opensource userspace driver. Of course the firmware is still proprietary and it increasingly contains more and more logic.
The GLX libraries are the elephant(s) in the room. Open source kernel modules mean nothing without these libraries. On the other hand AMD and Intel uses "pltform GLX" natively, and with great success.
Mesa already provides good open source GLX and Vulkan libraries. An open source NVIDIA kernel driver enables interoperability with Mesa exactly like Intel and AMD.
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#259Earlier quoted context omitted.
The GLX libraries are the elephant(s) in the room. Open source kernel modules mean nothing without these libraries. On the other hand AMD and Intel uses "pltform GLX" natively, and with great success.
Mesa already provides good open source GLX and Vulkan libraries. An open source NVIDIA kernel driver enables interoperability with Mesa exactly like Intel and AMD.
Half of the trade secrets NVIDIA has are living in their own GLX libraries. Even if you install the open source kernel module, these GLX libraries are installed (just did it on a new cluster).
I’m not holding my breath about these libraries to be phased out and NVIDIA integrates to the platform GLX any time soon.
I think NVIDIA will resist moving to a firmware only model (ala AMD & Intel) as long as they can, preferably forever.