Isn't this exactly what a GPU firmware is expected to do ? Why do they need to run software in the same memory space as my mail reader ?
> Why do they need to run software in the same memory space as my mail reader ?
It is a lot more expensive to build functionality and fix bugs in silicon than it is to do those same things in software.
At NVIDIA, we do as much as we possible can in software. If a problem or bug can be solved in software instead of hardware, we prefer the software solution, because it has much lower cost and shorter lead times.
Solving a problem in hardware takes 2-4 years minimum, massive validation efforts, and has huge physical material costs and limitations. After it's shipped, we can't "patch" the hardware. Solving a problem in software can sometimes be done by one engineer in a single day. If we make a mistake in software, we can easy deploy a fix.
At NVIDIA we have a status for hardware bugs called "Won't Fix, Fix in Next Chip". This means "yes, there's a problem, but the earliest we can fix it is 2-4 years from now, regardless of how serious it is".
Can you imagine if we had to solve all problems that way? Wait 2-4 years?
On its own, our hardware is not a complete product. You would be unable to use it. It has too many bugs, it doesn't have all of the features, etc. The hardware is nothing without the software, and vice versa.
We do not make hardware. We make platforms, which are a combination of hardware and software. We have a tighter coupling between hardware and software than many other processor manufacturers, which is beneficial for us, because it means we can solve problems in software that other vendors would have to solve in hardware.
> I really do not understand why a (very good) hardware provider is willing to create/direct/hint custom software for the users.
Because we sell software. Our hardware wouldn't do anything for you without the software. If we tried to put everything we do in software into hardware, the die would be the size of your laptop and cost a million dollars each.
You wouldn't buy our hardware if we didn't give you the software that was necessary to use it.
> Isn't this exactly what a GPU firmware is expected to do ?
Firmware is a component of software, but usually has constraints that are much more similar to hardware, e.g. long lead times. In some cases the firmware is "burned in" and can't be changed after release, and then it's very much like hardware.
The source data needs to appear on the GPU somehow. Similarly, the results computed on GPU are often needed for CPU-running code.
GPUs don’t run an OS and are limited. They can’t possibly access file system, and many useful algorithms (like PNG image codec) is a poor fit for them. Technically I think they can access source data directly from system memory, but doing that is inefficient in practice, because GPUs have a special piece of hardware (called copy command queue in d3d12, or transfer queue in Vulcan) to move large blocks of data over PCIe.
That library implements an easier way to integrate CPU and GPU pieces of the program.
How would a firmware help me write heterogeneous bits of c++ code that can run on either cpu or gpu?
When will we be able to use a future riscv-64 CPU with an nvidia GPU ? we will let the answer to nvidia ?
I would say .... The hardware must be sold independently of the software ... but it is a bit too complex, I know.
What do you even mean about 'it is not their role to do that.' and 'hardware must be sold independently of the software'?? Why are you saying this? Software interfaces are critical for all GPUs and all CPUs, just ask AMD & Intel. There is no such thing as CPU or GPU hardware independent of software. Plus, the specific library here is being sold independently of the hardware, it is doing exactly what you say you want, it's separate and doesn't require having any other nvidia hardware or software. (I can't think of any good reasons to use it without having some nvidia hardware, but it is technically independent, as you wish.)
To be clear, I don't think nvidia-paid developers should be able to write C++ Code for a nvidia-sold GPU. The world will be better if any developer (paid by nivida or not) is able to write code for any GPU (sold by nvidia or not). It is not nvidia role to say how or when software will be written. Their hardware is good and that's more than OK.
AI/CUDA code written specifically for nvidia is useless/deprecated in the long term. A lot of brain waste.
You’re free to write whatever you want. This is Nvidia providing interfaces to their hardware for those of us who don’t want to write them for ourselves.
It’s a gift. Take it or don’t. How in the world you can say Nvidia shouldn’t be allowed to write software for their GPUs makes no sense at all. Should the government stop them? Any developer can write anything they want - but Nvidia is obviously going to support their own hardware. How does it make any sense otherwise?
All code is “deprecated in the long term” for a long enough “long term”. That doesn’t equal useless. Your comment is nonsensical.
I wouldn't say it's a gift, though; it's part of what you pay for when you buy one of our products.
Sure, it's not listed as a spec on the box, but users expect that we're going to provide them with a good software stack and support it.
I'm not sure what you're saying here? You think another company or organization should write all the software for our hardware?
I don't think you understand the semiconductor industry.
Our business model relies on hardware and software engineers working closely together, as I've described in other replies.
We would not be able to produce a viable product that is solely raw hardware.
Also, what motivation does this other organization or company have to create software for our hardware?
> The world will be better if any developer (paid by nivida or not) is able to write code for any GPU (sold by nvidia or not).
This library is something that is designed to help you write Standard C++ code that runs on our GPU. Standard C++ runs everywhere.
> It is not nvidia role to say how or when software will be written.
Providing the SDKs and toolchains to program our platform is definitely part of our role in the ecosystem.
> Their hardware is good and that's more than OK.
Our hardware is useless without our software.
> AI/CUDA code written specifically for nvidia is useless/deprecated in the long term. A lot of brain waste.
I expect CUDA will be around for a while.
> Also, what motivation does this other organization or company have to create software for our hardware?
Typically an organization like this would be a user of nvidia hardware, that's like asking what motivation Microsoft has for writing software/toolchains for Intel hardware. Maybe this attitude is why nvidia is notorious for having a terrible open source software experience for Linux graphics.
> Our hardware is useless without our software.
It's not(https://nouveau.freedesktop.org/wiki/) but nvidia is considered one of the worst hardware vendors when it comes to having proper open source driver/toolchain support. The situation used to be even worse but it's still not great now.
It's not hostility, it's about agility. More so than other hardware vendors, we rely on really tight integration between hardware and software.
In some situations, we find a hardware bug that would require another manufacturer to do a "respin" (e.g. restart the manufacturing process with a new, fixed design). Because we have tight control over the software stack, we can workaround that bug. It's faster for us to do this when we have full control. Also, sometimes these bugs have security implications, etc.
That said, we've been moving in the direction of open source for a long time.
> It's not(https://nouveau.freedesktop.org/wiki/)
The other fellow was suggesting we should write no software at all. Nouveau's struggles is an excellent example of how difficult it is to write software for hardware without the engagement and interaction of the manufacturer of that hardware.
TL;DR you're talking about whether our software should open source versus closed source; the other fellow was suggesting we shouldn't have software at all.
About libcu++, you guys would not be doing it if it weren't a differentiator thanks to Universal Memory. All that is OK until GPUs become a strategic topic for governments, then you may be regarded as monopolistic.
Painting it as 'OSS frienly' or 'open' or 'standards compliant', when code written like that is likely to remain NVIDIA-only for many years seems intentionally deceiving.
Also, there is an industry standard that uses standard C++ (Sycl), that you refuse to participate in or implement.
Sure, but I think that's got less to do with the tight hardware/software integration and more to do with they type of bug and the skills of the engineers tasked with finding workarounds. When you can make changes to the entire OS by working with the community you can often workaround more severe bugs than would otherwise be possible.
> More so than other hardware vendors, we rely on really tight integration between hardware and software.
Which is fine when the software is reasonably open, plenty of software is tightly coupled to specialized hardware, but when a hardware manufacturer like Nvidia with a significant market-share does everything their own way and effectively refuses to work with the community in sufficient capacity when it comes to open source integration you end up with a situation where others are having to put in extra effort to make things work. This is a major reason why a lot of people are freaking out when it comes to Nvidia buying ARM, Nvidia has a pretty bad reputation among the open source community when it comes to these issues.
> Because we have tight control over the software stack, we can workaround that bug.
I really don't see why that tight control is necessary, Nvidia isn't all that unique here either, many vendors have hardware bugs that are ultimately worked around in the mainline Linux kernel for example.
> It's faster for us to do this when we have full control.
Participating in community/open development processes doesn't preclude Nvidia from directly distributing hot-fixes or even make distributing hot-fixes more difficult in any meaningful way. Mainlining proper Linux drivers can also make distribution of hot-fixes easier as they would get included in distro packaging systems and update cycles effectively automatically. One thing to keep in mind is that if Nvidia were to step up and dedicate a properly sized team to mainline open source driver development Nvidia would have a lot more control over the direction of the open source driver development for Nvidia hardware.
> Nouveau's struggles is an excellent example of how difficult it is to write software for hardware without the engagement and interaction of the manufacturer of that hardware.
Of course, that's really the big issue, Nvidia refuses to properly engage in community driver development, this lack of engagement is the source of a lot of animosity from developers. In general reverse engineered drivers like Nouveau are a last resort option usually only done when a vendor refuses to properly engage with the open source communities for development. Since graphics drivers are probably the most complex kernel drivers out there this is especially problematic for hardware like Nvidia GPU's.
> That said, we've been moving in the direction of open source for a long time.
Hopefully that is true, but it's something we've heard before, and to be fair things did look like they were on the right track for improvement but that seems to have stalled somewhat back in 2017 when Alexandre Courbot left Nvidia as he seemed to be the main developer who was spearheading engagement with the Nouveau project. A company of Nvidia's size can easily afford to dedicate a full time development team to open driver development, it would be great if Nvidia would step up to the plate and put in the resources to maintain the mainline kernel drivers for Nvidia hardware.
You are incorrect.
NVIDIA employs more software engineers than hardware engineers.
> We need smarter and more shining GPUs from nvidia, not software.
Software is a part of the GPU. You get better GPUs by having hardware and software engineers collaborate together.
It is extremely expensive to put features into hardware. It costs a lot of money and takes a very long time. It takes 2-4 years at a minimum to put features into hardware. And there are physical constraints; we only have so many transistors.
If we make a mistake in hardware, how are we supposed to fix it? At NVIDIA we have a status for hardware bugs called "Fix in Next Chip". The "Next Chip" is 2-4 years away.
So what do we do? We solve problems in software whenever possible. It's cheaper to do so, it has a quicker turnaround time, and most importantly, we can make changes after the product has shipped.
> I would say .... The hardware must be sold independently of the software ... but it is a bit too complex, I know.
We don't sell hardware and you don't want to buy hardware. Trust me, you wouldn't know what to do with it. It's full of bugs and complexity.
We sell a platform that consists of hardware and software. The product doesn't work without software.
If we tried to make the same product purely in hardware, the die would be the size of your laptop and would cost a million dollars.
The question is not about running code on CPUs, or running code on GPUs. It's about running code on both CPUs and GPUs at the same time. It's about enabling the code on the CPU and the code on the GPU to seamlessly interoperate with each other, communicate with each other, move objects and data to and from each other.
Who do you expect to make that happen?
> Until I buy a CPU from nvidia I want to keep some kind of independence
You can buy a CPU from NVIDIA, check out our Tegra systems. We also sell full systems, like DGX platforms, which use a 3rd party CPU.
> When will we be able to use a future riscv-64 CPU with an nvidia GPU ? we will let the answer to nvidia ?
Who else would answer this question?
Okay, you want to use <insert some future CPU> with our GPU.
Who is going to design and build the interconnect between the CPU and the GPU?
Who is going to provide the GPU driver?
The CPU manufacturer? Why would they do that? They don't make any money from selling NVIDIA products. Why should they invest effort in enabling that?
Actually, the basis of our modern GPU compute platform is a technology called Unified Memory, which allows the host and device processor to share access to memory spaces. We think this is the way going forward.
Of course, there's still the process isolation provided by your operating system.