Radeon ROCm Updates Documentation Reinforcing Focus On Headless, Non-GUI Workloads

[coder]

very simple how people inform themself and read forum and other info sites and the OpenCL situation do confuse them
and because of this confusing they end up using cuda.

abd believe me many people are confused about the openCL situation.

And the single biggest contributor to that is AMD. More than pretty much everyone else, combined!

Nvidia was always clear that they supported OpenCL 1.2. Apple washed their hands of it, a long time ago. If your issue is confusion, then you're barking up the wrong trees.

can't see that on AMD side they make it easy to port the CUDA software to ROCm...

How is that not hurting OpenCL? What AMD did was make it easy to port to HiP -- not OpenCL! That only helps CUDA and AMD. It gives people a false sense of assurance that they can use CUDA and not be locked into Nvidia, and then it lets AMD siphon off those few customers who try to escape Nvidia's icy embrace.

stop confuse people....

It's sounding like you're the one confused, here. You seem to have forgotten even what your argument was!

HiP is made to port CUDA apps to ROCm...

HiP is a CUDA-equivalent that only runs on ROCm (edit: and Nvidia's runtime). In theory, it can be ported to other runtimes (e.g. oneAPI), but any such efforts are very early and experimental and might never mature.

So far, if you use HiP, you're practically locked into AMD/Nvidia, just as much as one using CUDA is to Nvidia.

and i am 100% sure "Mandle compute.Metal compute, Vulkan compute, Dx12 directCompute"
all these will end up and will repleaced by:
https://de.wikipedia.org/wiki/WebGPU

Outside of a web browser, that doesn't even make sense. Probably most of the GPU-compute apps that exist today would not be a candidate for using that. And, of course, even to implement it, web browsers would need to use one of the lower-level frameworks you claim it's going to replace. All it's doing is just enabling GPU compute for web apps, which is good and all... But you're changing the subject, as usual.

remember the time microsoft was member of Kronos and they sapotaged openGL?

I don't know that, but they left because they saw it as no longer in line with their interests. Again, you're changing the subject.

Nvidia also has history of sapotaging OpenGL

I don't know, but let's say they did? All standards are battlegrounds for members trying to gain some advantage, such as aligning it with their existing technologies so they can get a lead on having better or earlier implementations. That doesn't fit the definition of sabotaging, because they're not actually trying to make the standard fail. In that case, they actually want it to succeed, so that it gives them greater market advantage.

in my point of view Nvidia did same to OpenCL.

And after all this, you're back to repeating your original claim with the same amount of evidence: zero. But, at least it gave us a chance to discuss who's been doing the most damage to the OpenCL ecosystem of late: AMD.

apple admit this because of this they do Metal/WebGPU what is the same as mandle and vulkan and directX12.

When did they admit to sabotaging OpenCL? Again, walking away from it is not the same as sabotaging it!

just ask bridgman...

No, I'm not going to try to drag the man into this, because he has far better things to be doing. Unlike you, he clearly realizes that your little crusades are pointless and will amount to nothing. It's just like those conspiracy theories you keep trying to post -- repeating a fiction any number of times does not make it true.

If you want to change the world, learn to code. If you already know how, than improve your skills. And if you're already a master coder, then get busy on doing something useful with your time and energy.

3.0 fix everything by making everything optional means no solution at all.

It's not a solution for those who need some feature that Nvidia is unwilling or unable to implement, but it removes the logjam that would prevent them from delivering other features that people want or need. In that sense, it is real progress.

[bridgman]

HiP is a CUDA-equivalent that only runs on ROCm. In theory, it can be ported to other runtimes, but any such efforts are very early and experimental and might never mature.

So far, if you use HiP, you're practically locked into AMD just as much as one using CUDA is to Nvidia. In fact, I'd say more, because I'm not aware of any tool for porting HiP code back to CUDA or anything else.

Sorry, just noticed this.

HIP code runs on both AMD/ROCm and NVidia/CUDA - that's the "P" part of "Heterogenous Interface for Portability".

There was a recent FOSDEM presentation where the author talked about their experiences porting CUDA code to HIP, in terms of both effort and performance. A question was raised about how the performance impact was measured, and it turned out that all of their testing had been on NVidia hardware - porting to HIP then running the HIP code directly over CUDA on their V100's:

https://www.phoronix.com/forums/foru...ng-with-openmp

Can I ask you to revisit your use of the term "locked-in", particularly since you are talking about people being "locked into" an open source solution ?

[coder]

HIP code runs on both AMD/ROCm and NVidia/CUDA - that's the "P" part of "Heterogenous Interface for Portability".

Thanks for pointing that out.

Can I ask you to revisit your use of the term "locked-in", particularly since you are talking about people being "locked into" an open source solution ?

I've updated my post to account for your points, but probably not as much as you'd like.

While HiP might've been the least-bad option for AMD, I think it's not the best for the GPU compute community. I prefer Intel's approach in how they opted to build oneAPI atop OpenCL and related standards, which pretty much means first class support for said standards. That's better for those of us who prefer non- vendor-specific APIs.

I have no more interest in ever writing HiP code than CUDA. I'll grant you that it's nice for HiP to be open source and to run on Nvidia hardware, but I'd still go for OpenCL whenever I had the choice.

I know you guys pushed OpenCL for a long time, and I appreciate that. But, from my narrow perspective, HiP was a distraction and a detour. Keep up the good work, as I hope to keep using AMD hardware into the future.

[vegabook]

Outside of a web browser, that doesn't even make sense. Probably most of the GPU-compute apps that exist today would not be a candidate for using that. And, of course, even to implement it, web browsers would need to use one of the lower-level frameworks you claim it's going to replace. All it's doing is just enabling GPU compute for web apps, which is good and all... But you're changing the subject, as usual.

Is this correct? I was under the impression that WebGPU via gpu-rs was going to allow us to use this outside of the browser. My sense was that the manufacturer drivers are all for once going to have to support this standard as web apps otherwise won't work with their hardware. That's a powerful argument for this standard, even if it might have a bit of overhead? Interested in your view.

[coder]

Is this correct? I was under the impression that WebGPU via gpu-rs was going to allow us to use this outside of the browser. My sense was that the manufacturer drivers are all for once going to have to support this standard as web apps otherwise won't work with their hardware. That's a powerful argument for this standard, even if it might have a bit of overhead? Interested in your view.

I'm no expert, but even if you can use it outside of a web browser (e.g. something akin to node.js), it's still going to be implemented atop a lower-level API.

I'm not even saying it's not a better API (I don't know nearly enough to say either way, and there's not even a 1.0 standard yet), but I think traditional graphics and GPU compute APIs are going to be with us for a long time to come, just as web apps haven't killed off conventional native apps and APIs. So, I just don't see what this nebulous, future API has to do with the discussion. Let's at least wait and see the 1.0 standard, so we can get into the specifics. Then, we can talk about it growing legs and where they might take it.

[coder]

i really do not want to offent you but you are wrong on all points...

That's your opinion, and I have no trouble with you feeling that way.

WebGPU/gpu-rs is the future of GPU-Compute and it is supported by apple,intel,amd,microsoft and all others.

also read my last post... only WebGPU/gpu-rs is the solution what is supported by all vendors.

These guys also support standards like HTML 5, but MS, Apple, Google, and others don't ditch their native GUI libraries.

Just because there's a standard which has functional overlap with an existing standard or API doesn't mean it's a replacement. They can be complementary.

Everyone knows that the web "hates" proprietary stuff (e.g. Shockwave/Flash, ActiveX, Java ...all failed). So, it makes sense that, when it comes to web technologies, vendors would all embrace standards. And no one wants to be left out of helping to shape it, because the stakes are so high. That doesn't mean they have embraced it as a replacement for their entire preferred stack, however.

[bridgman]

I've updated my post to account for your points, but probably not as much as you'd like.

It's good, thanks. The only additional changes would be things I forgot to mention - that HIP also has a CPU back end (so there's some Intel coverage while they finish working on dGPUs) and ongoing work with Xilinx:

https://www.phoronix.com/scan.php?pa...MD-ROCm-Xilinx

While HiP might've been the least-bad option for AMD, I think it's not the best for the GPU compute community. I prefer Intel's approach in how they opted to build oneAPI atop OpenCL and related standards, which pretty much means first class support for said standards. That's better for those of us who prefer non- vendor-specific APIs.

I have no more interest in ever writing HiP code than CUDA. I'll grant you that it's nice for HiP to be open source and to run on Nvidia hardware, but I'd still go for OpenCL whenever I had the choice.

I would argue that OpenCL is only coincidental to oneAPI, which focuses on Intel's customized variant of SYCL (and SYCL, in turn, reads like a wordy version of HIP).

You can argue that SYCL is part of OpenCL, of course, but going from that to expecting oneAPI to drive an increase in OpenCL programming and support is a bit of a stretch IMO, except to the extent that you say "oh DPC++ is OpenCL".

[coder]

he had a crazy anti-AMD conspirancy theory... and in the end all his points turned out to be wrong...

It's weird how you cast things in such absolute terms. Either you can't wrap your brain around how other people think, or maybe you don't actually know what a conspiracy theory is. Either way, I'll just say it plainly, for all to see: I don't believe AMD is involved in any conspiracy, other than following the usual profit motive that influences most of our lives and livelihoods, in some form and extent.

I always try to be tough, but fair. It's good that AMD has open source drivers and stuff, but I'm actually a lot more concerned about vendor lock-in and wasting time learning and using some proprietary technology that ends up being a dead end. So, I place a higher priority on open APIs than I do on open source implementations. That's why I'm critical of AMD for prioritizing HiP over OpenCL, even while I realize that it might've been a business necessity for them to do so.

he claims HIP is "vendor lock in" but in the end HIP runs on AMD and Nvidia also no "Vendor lock in"

Being locked into one of two vendors is still lock-in. And I don't trust that HiP will work on Nvidia hardware for the indefinite future. That isn't 100% in AMD's control, nor is it 100% in their interest.

he also claims WebGPU only run in the browser but gpu-rs runs outside of the browser.

No, I didn't actually say that. When you have to start misquoting me, it shows you've already lost.

he claims an opensource solution hurts your freedom but it is clearly freedom.

That's another mischaracterization. There's a practical reality that I'm one developer and even if I have the source to something and could theoretically port/extend/etc. it, such projects quickly become impractical, not to mention distracting me from my true priorities and interests. That's why I prize open standard APIs. Because, if I write standards-compliant code and have a number of standards-compliant implementations from which to choose, then that's a lot more practical freedom than the theoretical freedom of being able to port HiP to some other hardware.

Is open source good? yes. Would I prefer an open source implementation of the software I use? yes. It's simply not the only -- or even highest -- priority, for me,

he claims OpenCL is the future of Compute but it is clearly not the case and to unterstand someone only need to categorize all options:

I never said that, either. I only said what I would rather use.

Based on how many mischaracterizations I just corrected, you're either doing a very poor job of understanding my position, or you're actively trying to make a starwman case against me. If it's the first case, hopefully you might proceed with a bit more humility, after seeing how much you got wrong. If the second, I think you're not fooling anyone and instead just making yourself look bad, as well as wasting your time.

and there is very low level WebGPU/gpu-rs what is like Vulkan/Metal/DX12 compute but it is supported by apple,intel,amd,microsoft and all others.

What about it qualifies it as "very low level"?

this means CUDA/OpenCL IS NOT THE FUTURE OF GPU COMPUTE and it is clear WebGPU/gpu-rs is the future.

You're very quick to embrace a standard that doesn't even exist, yet.

[coder]

I would argue that OpenCL is only coincidental to oneAPI,

If/when Intel walks away from OpenCL, I'll re-evaluate my position on them.

SYCL, in turn, reads like a wordy version of HIP

Last I checked, SYCL is a Khronos standard and HiP is not. Do you really want to play this game?

expecting oneAPI to drive an increase in OpenCL programming and support is a bit of a stretch IMO,

That's quite apropos of nothing. Certainly nothing I said. I would not predict whether OpenCL will increase in popularity, but I know that if support for it dries up or at least ceases to advance, then its popularity is likely to decrease.

[coder]

thats interesting you say AMD is evil

Except I didn't say they're evil. I simply acknowledged that they're dealing with certain business realities that influence their behavior. So, if that makes them evil, I guess all commercial hardware and software companies are evil? Even ones like Redhat and Canonical? Maybe you think that, but I don't.

I think you're missing a lot of nuance and mixed-feelings, in my posts.

you ... just imagine a world AMD would not do "business necessity"

I can point to certain of their actions that I think don't help the community, even while understanding why they made those decisions and accepting their logical consistency.

I'm trying to be a realist, not a partisan. Only a partisan cannot criticize a party he supports. Which are you?

see this is how your conspirancy theory bust as a HOAX

I tried to explain this before: it's not a conspiracy theory. AMD is just acting according to its fairly obvious and straight-forward self-interest, as one would expect. That is not a conspiracy theory.

AMD is neither the most nor the least greedy company, but it is a publicly-traded corporation, and that forces them to behave according to certain rules, norms, and realities.

ok lets say Richard Stallmann is the good side and closed source nvidia/microsoft is the evil side

I don't accept that projection, partly because it's too simplistic. Stallman prioritizes the power of end-users above that of providers and intermediaries, while Nvidia prioritizes their own power. However, these motivations play out in different ways, according to circumstances.

Good and evil are in the eye of the beholder -- two people can view the same action and reach different conclusions on whether it's good or evil. So, I don't find it very constructive to utilize that terminology. It's more useful to talk about interests and benefits.

we can say for sure AMD is much less evil than nvidia.

We can say they're less powerful. And less powerful players tend to behave in less immediately self-interested ways.

Bridgman already told you ROCm has backend for Intel CPUs so you can choose amd or nvidia or intel.

Not really. If I'm using a GPU Compute API, it's probably because I need more power than I can get from a CPU. So, it's not a real choice. Mostly, I consider it useful for debugging, which is easier on CPUs than GPUs.

ok now you maybe claim CPU support don't count....

Yes, and I explained why. If you disagree with my rationale, then explain why, but don't try to dismiss my point simply because it makes me seem anti-AMD.

we are on the same side dude i also prize open APIs... but HIP/ROCm is an open API now you say it is not "standard"

This is not a small point: HiP and ROCm are not standards. And, partly because of that, you don't get alternate implementations from their competitors. That's very important to me. Maybe not to you, if you're already going to use AMD no matter what.

do you remember i already showed you the solution to all these problems... WebAssembly+WebGPU...
It will be "standard" be sure and it will be "open"

Those are not viable options for me, today or any time in the immediate future. OpenCL is. If you want to talk about the far future, that's not relevant to my points.

i see OpenCL as obsolete and i would go for Vulkan/metal based WebGPU...

OpenCL hasn't stopped evolving, so I think it's premature to declare it obsolete. Furthermore, compute-based SPIR-V is virtually nonexistent and WebGPU is actually nonexistent. So, you're arguing against something real with nothing but vaporware. That doesn't tend to work too well.

there is another explanation: you are a native english speaker i am a german,,, i do have dyslexia and you are not.
i am not some standard person who reads your writings the standard way ... i just can't perform this task it is that simpel.

You're putting my positions in very absolute terms, yet it seems like you understand my words. That's what I'm taking issue with.

I am trying to be patient and I understand you're putting in effort to understand me and get your points across.

However, there's something important I'm trying to say: when you try to tell me what I think and believe, then it only means we have to spent a lot more time where I explain what I really do think and believe. So, a suggestion would be to try asking what I think, instead of telling me.

Another point is that I care a lot about details. I need to. Getting a single detail wrong can casue bugs, and we all hate that. When I go to use an API, I am immersed in the details. They even go so far as dictating the architecture of my code! So, when you make sweeping claims, that doesn't work for me. I need to know the details supporting that position.

Low level= cpu assembler ISA or Vulkan/webGPU for GPUs...

So, here's a good example: I meant that I want to know what specific aspects of it qualify it as a low-level API, rather than a high-level one. And not just because someone talked about it as being influenced by Vulkan or Metal.

you do not need big imagination to come to this conclusion because everywhing what hit the web browsers become the """standard"""

like javascript it is only "standard" because it is in the web browser... WebAssembly a standard because it is in the web browser...

and WebAssembly is for cpus and webGPU is the same for GPUs...

• I cannot use technologies that don't exist, yet, and I'm not very interested in using ones without a reasonably mature implementation.
• Not every standard to hit a web browser has caught on. I'm not an expert on web technologies, but I'm sure there are dozens.
• There's interest in using WebAssembly outside web browsers, but it's hardly mainstream even in browsers and still experimental elsewhere. By the time it can grow, something else might come along -- we don't know.
• Reasoning by analogy is unreliable. Once WebGPU is out, we can look at the details and compare it to existing APIs. Until then, we can't say whether it can truly replace them, or in what circumstances.
• Each API tends to have different strengths and weaknesses, so it's a stretch to expect it to replace all others, in all cases.