4 ms·

I have said nothing of the sort anywhere in this thread. All I said is that AMD is viable for some large customers. You chose to continue to misinterpret that a

I have said nothing of the sort anywhere in this thread. All I said is that AMD is viable for some large customers. You chose to continue to misinterpret that after several clarifications. Then you throw out vague statements, and claim that you "don't want to say much more", to complain in the next sentence that it's all gossip. You have literally offered no argument, other than saying "trust me, I know, I am an insider"...

almostgotcaught 2y ago
> You have literally offered no argument I absolutely did but seemingly no one understands the force of it (because no one actually cares about details). My argument was very very simple: go look at the hip backend in pytorch and the cuda backend. To anyone that understands what's what, that alone speaks volumes. Not my fault if you don't understand though.
- Certhas 2y ago
  Again, your argument is ad hominem ("you don't understand") and not naming an actual problem but declaring that it's obvious to anyone who wants to look. The AMD and the CUDA backend in pytorch are actually derived from the same code base. AMD compiles the CUDA code to its HIP interface (which is essentially a reimplementation of CUDA), and that's that. It's all upstreamed and so changes to the CUDA backend are tested against the AMD build. If there is a problem with that strategy, then it's up to you to demonstrate it because the prima facie evidence is that it works: I can go to Azure and buy an AMD Instinct VM and run a Hugging Face model on that right now, with marginally more effort than it takes to run it on an nVidia VM.
  - almostgotcaught 2y ago
    > Again, your argument is ad hominem ("you don't understand") It's not ad hominem - it was my argument in literally my first response without a single word of shade. you then go and say "you have no argument" and I respond with "well if you can't understand the argument then sure I have no argument". pretty simple. I read this on reddit at some point: you're not the victim here, you're just starting a fight and then losing that fight. > If there is a problem with that strategy, then it's up to you to demonstrate it because the prima facie evidence is that it works you think that yolking yourself to your direct competitor's runtime API is a sound product strategy? really? i'm sure you'll come back with "intel x86_64 blah blah blah". the fact is it's not a sound strategy and maybe it would be wise for AMD to build out a real HIP backend (and maybe they already are).
    - Certhas 2y ago
      Nowhere did you say that you think trying to build an interface that is as close as possible to cuda is the problem. You still haven't said why it's a problem. You only said "look at the implementation" and said that if that's not obviously problematic to me, I just don't understand. If you had explained why you find it problematic we might have had a conversation on the viability of that strategy and the need for other complementary strategies. Seriously, the only reason I am still here is because I hope you can understand why your replies were really not appropriate for facilitating interesting conversation.

almostgotcaught 2y ago

> You have literally offered no argument I absolutely did but seemingly no one understands the force of it (because no one actually cares about details). My argument was very very simple: go look at the hip backend in pytorch and the cuda backend. To anyone that understands what's what, that alone speaks volumes. Not my fault if you don't understand though.

Certhas 2y ago
Again, your argument is ad hominem ("you don't understand") and not naming an actual problem but declaring that it's obvious to anyone who wants to look. The AMD and the CUDA backend in pytorch are actually derived from the same code base. AMD compiles the CUDA code to its HIP interface (which is essentially a reimplementation of CUDA), and that's that. It's all upstreamed and so changes to the CUDA backend are tested against the AMD build. If there is a problem with that strategy, then it's up to you to demonstrate it because the prima facie evidence is that it works: I can go to Azure and buy an AMD Instinct VM and run a Hugging Face model on that right now, with marginally more effort than it takes to run it on an nVidia VM.
- almostgotcaught 2y ago
  > Again, your argument is ad hominem ("you don't understand") It's not ad hominem - it was my argument in literally my first response without a single word of shade. you then go and say "you have no argument" and I respond with "well if you can't understand the argument then sure I have no argument". pretty simple. I read this on reddit at some point: you're not the victim here, you're just starting a fight and then losing that fight. > If there is a problem with that strategy, then it's up to you to demonstrate it because the prima facie evidence is that it works you think that yolking yourself to your direct competitor's runtime API is a sound product strategy? really? i'm sure you'll come back with "intel x86_64 blah blah blah". the fact is it's not a sound strategy and maybe it would be wise for AMD to build out a real HIP backend (and maybe they already are).
  - Certhas 2y ago
    Nowhere did you say that you think trying to build an interface that is as close as possible to cuda is the problem. You still haven't said why it's a problem. You only said "look at the implementation" and said that if that's not obviously problematic to me, I just don't understand. If you had explained why you find it problematic we might have had a conversation on the viability of that strategy and the need for other complementary strategies. Seriously, the only reason I am still here is because I hope you can understand why your replies were really not appropriate for facilitating interesting conversation.