3 ms·

I don't know man, did you watch the video I linked from AMD's FSR lead? "we won't support [an open source API/framework] because it might be used to plug thing

by paulmd 4y ago

I don't know man, did you watch the video I linked from AMD's FSR lead? "we won't support [an open source API/framework] because it might be used to plug things we don't like" is pretty explicitly hostile to both user freedom and open source as a whole. The freedom to do things that you might not want me to or that you won't do is really the only user freedom in this sense, right? What happens when some game won't update to FSR 2.2 and you're stuck on FSR 2.1 forever? That's the thing open-source user freedom is supposed to fix, right? AMD doesn't get to determine that "our software is the best and alternatives offer no benefits" either, that's the end-user's choice, and when that's followed by "therefore we will work against adoption of pluggability and interoperability standards" that crosses into openly hostile. The lead is being very diplomatic and careful but that's a very coached way to say that "this interoperability standard isn't good for us and we will work to kill it and prevent adoption, regardless of its open-source nature. Our product is better than theirs and we are going to work to deny you the freedom to choose otherwise." That's some microsoft level embrace-extend-extinguish shit right there: this is them embracing upscaling tech, extending it with their own proprietary implementation and deliberately kneecapping interoperability, with the goal of eventually extinguishing DLSS. They're just saying the quiet bit out loud and generally being delusional to think they could ever make this happen. -- Look, big-picture here: AMD did the open-source driver on linux thing because it was a way to get a force-multiplier on their dev time - the community does the work instead of employees that AMD has to pay for. It's a niche community with a DIY mentality and AMD (and Intel before them) leaned on that to get more work done. AMD's not open-sourcing drivers on Windows. They slap down open APIs like Streamline when it doesn't support their business strategy. The same thing is happening with ROCm - everyone else does software this way, but, AMD wants you to do it that way, even though it's more work and more cumbersome for end-users, because it results in more lock-in for their software ecosystem. Is that not fundamentally the same thing as people accuse NVIDIA of doing? And that's how they've handled FSR too - user freedom doesn't really matter that much as a principle, actually they've stated they're explicitly against users having these freedoms. They want people statically compiling it because if they embraced user freedom it would help users move more freely between these ecosystems and they don't want that, they are fine with lock-when you're locked into their ecosystem. What they mean by "user freedom" is they want to prevent users from plugging a library that interfaces with their competitor's hardware accelerators. That's actually the opposite of user freedom. And where does PSP fit into user freedoms - a whole closed processor running underneath your user experience doing god knows what? Wasn't that something people flipped an absolute fucking shit over with Intel ME? Yeah it's got closed-source elements that make it a problem to open, but isn't that also true of the NVIDIA drivers people constantly whinge about? What's the reason for giving AMD a pass on external IP but not NVIDIA? Blobs don't matter anymore if it's AMD? Or the platform lock - literally preventing secondhand resale of server cpus (and now desktop CPUs too) if they're ever used in a branded system. Note that it's not locked to a motherboard - it's not about preventing parts swapouts. It's locked to a brand, so you can swap any other HP-locked cpu into a HP-locked system. Clearly 100% targeted at killing the secondhand market, and that's pretty damn anti-user-freedom as well, why shouldn't I have the freedom to buy a used CPU if I want? Because it would impact AMD's bottom line I guess? Like, at the end of the day AMD is rolling in the anti-user-freedoms shit same as everyone else. It's a bit, when you're the underdog you need an angle to get people to buy you. When the incentives align and you and AMD are both seeing a benefit from the open-source strategy it's great, but it's not something they "are in favor of as a company", they're happy to say no to open-source when it gives them a strategic advantage.

JonChesterfield 4y ago
I didn't watch the youtube link. I have now and looked up who the speaker is. He's not aligned with my philosophy. In a past life I made proprietary tools for games studios releasing proprietary products. Most games dev is decidedly hostile to open source, and most windows development is likewise, so I'm not hugely surprised to see that position stated. There may be similar factors at play with the drivers on windows, not my sandbox. I remember the epyc processor lock story breaking. I don't know how that played out in practice. I do know I'm going to be _really_ angry if it turns out my chip only works in asrock motherboards since that was the first one I put it in. I'd forgotten about that when buying it :( It seems plausible that whoever is presently the underdog makes nice with open source and whoever is presently on top is not. See e.g. Microsoft over time. I don't think ROCm will go proprietary because the commercial pressure is in the direction of supercomputers. Specifically, customers of these computers have their own engineers working directly on the open source upstream of the ROCm stack. Both writing optimisations targeting the applications they care about and fixing bugs that trouble them. I mostly get my code reviewed by people outside of AMD. That sort of dynamic doesn't work if you tell customers they need to connect through your VPN and deal with the internal bug tracking systems in order to request changes, as opposed to patching the toolchain themselves. I am absolutely sure that the overall ROCm architecture was not designed to achieve user lock-in. To the extent I can see an overarching design, it looks like doing the simplest thing we can think of that works OK on clusters. I do see what looks like scar tissue from an initial bring up during the period where AMD was flirting with bankruptcy. OpenCL was implemented first and then apparently ignored by industry. The current compute model (HSA) was designed in collaboration with various other companies, of which I think Qualcomm are still using it but noone else is. I believe there are commercial reasons why we can't implement CUDA (and thus created HIP, which looks pretty similar and I'm told runs on amdgpu or on nvptx). Clang's OpenMP is converging on identical implementations for amdgpu and nvptx and will do the same for intel if they ever show up. That'll already compile a program that runs on either GPU arch if you ask it to. Obviously I can't totally rule out a change in policy - some corporate mandate may come down that GPU compute is done with this open source model and customers will just have to accept what they're given. There are evidently factions within the company who would claim it is the right thing to do and there's a lag on consequences to changes like that. Hopefully maximising HPC sales will imply open source software for a long time.

by paulmd 4y ago

JonChesterfield 4y ago

I didn't watch the youtube link. I have now and looked up who the speaker is. He's not aligned with my philosophy. In a past life I made proprietary tools for games studios releasing proprietary products. Most games dev is decidedly hostile to open source, and most windows development is likewise, so I'm not hugely surprised to see that position stated. There may be similar factors at play with the drivers on windows, not my sandbox. I remember the epyc processor lock story breaking. I don't know how that played out in practice. I do know I'm going to be _really_ angry if it turns out my chip only works in asrock motherboards since that was the first one I put it in. I'd forgotten about that when buying it :( It seems plausible that whoever is presently the underdog makes nice with open source and whoever is presently on top is not. See e.g. Microsoft over time. I don't think ROCm will go proprietary because the commercial pressure is in the direction of supercomputers. Specifically, customers of these computers have their own engineers working directly on the open source upstream of the ROCm stack. Both writing optimisations targeting the applications they care about and fixing bugs that trouble them. I mostly get my code reviewed by people outside of AMD. That sort of dynamic doesn't work if you tell customers they need to connect through your VPN and deal with the internal bug tracking systems in order to request changes, as opposed to patching the toolchain themselves. I am absolutely sure that the overall ROCm architecture was not designed to achieve user lock-in. To the extent I can see an overarching design, it looks like doing the simplest thing we can think of that works OK on clusters. I do see what looks like scar tissue from an initial bring up during the period where AMD was flirting with bankruptcy. OpenCL was implemented first and then apparently ignored by industry. The current compute model (HSA) was designed in collaboration with various other companies, of which I think Qualcomm are still using it but noone else is. I believe there are commercial reasons why we can't implement CUDA (and thus created HIP, which looks pretty similar and I'm told runs on amdgpu or on nvptx). Clang's OpenMP is converging on identical implementations for amdgpu and nvptx and will do the same for intel if they ever show up. That'll already compile a program that runs on either GPU arch if you ask it to. Obviously I can't totally rule out a change in policy - some corporate mandate may come down that GPU compute is done with this open source model and customers will just have to accept what they're given. There are evidently factions within the company who would claim it is the right thing to do and there's a lag on consequences to changes like that. Hopefully maximising HPC sales will imply open source software for a long time.