Earlier quoted context omitted.
Or how Siri means "buttocks" in Japanese?
It’s oshiri, not Siri.
Actually the 'o' is a modifier for politeness. It seems there's a version of the word without an 'o'.
Libcu++: Nvidia C++ Standard Library
131–139 of 139 posts
Re: Libcu++: Nvidia C++ Standard Library
#132Earlier quoted context omitted.
I get the impression nvidia puts out a lot of their hardware supporting software themselves because they are hostile to open source community collaboration in general. This could be because nvidia is a big fan of vendor lock in. > 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 a…
> I get the impression nvidia puts out a lot of their hardware supporting software themselves because they are hostile to open source community collaboration in general. This could be because nvidia is a big fan of vendor lock in. 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 th…
I think Nouveau would be in better shape with a bit of collaboration from NVIDIA.
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.
Re: Libcu++: Nvidia C++ Standard Library
#133Earlier quoted context omitted.
A properly designed ABI is capable of expansion. The design risk is not so much being backed into a corner, as just accumulating a great deal of obsolete cruft over the years/decades. Win32 is a great example of this. It has been extensively overhauled, and best practice for writing a new application today is quite different from 25 years ago, but unmodified Windows 95 applications still usually run correctly.
The C++ standard library is a bit different from a platform API. The C++ standard library is a template system designed to conform exactly to your particular program. It should always be statically linked. I see zero advantage to dynamic linking of libc++. A platform API, on the other hand, is designed to stable, safe, and flexible, not fast --- because programs in general shouldn't be calling into the system so much…
Except when OSes happen to be written in C++, like most modern non-UNIX/POSIX clones, and security updates come into play.
Re: Libcu++: Nvidia C++ Standard Library
#134Earlier quoted context omitted.
> 1. Ever heard of Nights and Visual Studio plugins? Those are apples and oranges... also, you forget cuda-gdb. > OpenCL 1.2 got renamed as OpenCL 3.0. C++ bindings were dropped Well, yes, but also no. They were made optional, and transitioned to some other C++-cum-OpenCL initiative: https://github.com/KhronosGroup/Khronosdotorg/blob/master/ap... I'm not exactly sure how this differs and what's usable in practice tho…
While SYSCL might stand a chance against CUDA, thanks to it being backend agnostic and a compiler neutral standard, C++ for OpenCL is a clang specific project which remains to be seen if it ever will get any adoption. > For C++ kernel development, the OpenCL Working Group has transitioned from the original OpenCL C++ kernel language, defined in OpenCL 2.2, to the ‘C++ for OpenCL’ community, open-source project suppor…
> C++ for OpenCL is a clang specific project which remains to be seen if it ever will get any adoption.
About adoption - you're right. But about being Clang-specific - that's not an issue. That is, OpenCL is also specific to an OpenCL compiler; so the fact that compilation from C++-for-OpenCL to SPIR-V is clang-based is not a problem. We can still compile our host-side code with whatever compiler we like, but the runtime compiler of OpenCL C++ kernels will be clang-based.
Re: Libcu++: Nvidia C++ Standard Library
#135Earlier quoted context omitted.
It’s oshiri, not Siri.
Actually the 'o' is a modifier for politeness. It seems there's a version of the word without an 'o'. https://jisho.org/search/shiri
I'm aware... But the word isn't pronounced the same anyway, and I've never heard it used without the o either.
Re: Libcu++: Nvidia C++ Standard Library
#136Earlier quoted context omitted.
The C++ standard library is a bit different from a platform API. The C++ standard library is a template system designed to conform exactly to your particular program. It should always be statically linked. I see zero advantage to dynamic linking of libc++. A platform API, on the other hand, is designed to stable, safe, and flexible, not fast --- because programs in general shouldn't be calling into the system so much…
Except when OSes happen to be written in C++, like most modern non-UNIX/POSIX clones, and security updates come into play.
The OS implementation language is irrelevant: there's no reason that applications and the OS core need to use the same C++ standard library.
Re: Libcu++: Nvidia C++ Standard Library
#137Earlier quoted context omitted.
I get the impression nvidia puts out a lot of their hardware supporting software themselves because they are hostile to open source community collaboration in general. This could be because nvidia is a big fan of vendor lock in. > 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 a…
> I get the impression nvidia puts out a lot of their hardware supporting software themselves because they are hostile to open source community collaboration in general. This could be because nvidia is a big fan of vendor lock in. 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 th…
> 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).
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.
Re: Libcu++: Nvidia C++ Standard Library
#138Earlier quoted context omitted.
I get the impression nvidia puts out a lot of their hardware supporting software themselves because they are hostile to open source community collaboration in general. This could be because nvidia is a big fan of vendor lock in. > 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 a…
Aren’t we commenting in response to the posting of a new open source library that helps support a standard tool chain?
From my understanding it's an open source library to support a Nvidia hardware specific partially(mostly?) proprietary toolchain.
Re: Libcu++: Nvidia C++ Standard Library
#139Earlier quoted context omitted.
Aren’t we commenting in response to the posting of a new open source library that helps support a standard tool chain?
From my understanding it's an open source library to support a Nvidia hardware specific partially(mostly?) proprietary toolchain.
All implementations of a standard are hardware specific. This library is implementing part of the C++ standard, and the source is open. I don't understand why you're complaining about lack of openness in response to increasing openness. Would you prefer that the library was closed and proprietary?