AMD Publishes Open-Source "GPUFORT" As Newest Effort To Help Transition Away From CUDA

[Mark625]

AMD is aiming their efforts at supporting supercomputers built with their FirePro and Instinct GPUs, not your typical desktop apps. As frustrating as it is for us plebes with a retail GPU, that is not the market they are trying to meet with ROCm.

Any crossover of ROCm functionality from data center / HPC / supercomputer to desktop is gravy.

[cb88]

Another thing to remember is that AMD has been pretty cash strapped for a long time, and running razor thin margins on everything in order to try to turn a profit... only just how have the windows drivers acutally gotten to the point where I would call it good... alot of small things have started being fixed in the recent months and basically that is what is missing from thier compute drivers... they "work" and if you are doing HPC they are perfectly fine but they are not polished at all the installation is not well integrated etc... for end users but that will come it just takes alot of time and effort. Also AMD needs to driver abstraction and defered runtime selection so having multiple compute drivers installed doesn't suck such as having RoCm coexist with Clover.

[FireBurn]

One day I hope to be able to run a real OpenCL benchmark successfully on any of my AMD GPUs using open software

That's what was promised when APUs were first announced and when I bought the X1250 / RS690 and I've stuck with them through the generations, maybe this time with the 6800M I'll be successful

Any idea when it's being added to ROCm?

[cesarcafe]

It's quite sad that we have fully working solutions for translating OpenGL to Vulkan, and Vulkan to Metal, but however there's still no 100% working solution for CUDA to OpenCL (or to Vulkan). It's very sad, because proprietary APIs are an 80s/90s thing that doesn't help long-term development, and that makes your code obsolete before it achieves beta stage.

[Mark625]

It's quite sad that we have fully working solutions for translating OpenGL to Vulkan, and Vulkan to Metal, but however there's still no 100% working solution for CUDA to OpenCL (or to Vulkan). It's very sad, because proprietary APIs are an 80s/90s thing that doesn't help long-term development, and that makes your code obsolete before it achieves beta stage.

What's sad is that Nvidia has been allowed to hobble the natural growth and improvement of OpenCL into something more competitive with CUDA. Why is Nvidia in the driver's seat at Khronos when they have a vested interest in their proprietary CUDA platform? It is a clear conflict of interest. If they want to keep their OpenCL users at 1.2 forever, that's their business, but they shouldn't be allowed to hold everyone else back.

AMD needs to push harder for continued evolution of OpenCL and forget chasing Nvidia. Remember, if you're always chasing, you're always behind. AMD needs to find a path to getting ahead in the GPU software ecosystem, not just seeking feature parity with CUDA. That may be pushing harder for CL C++, or other CL-enabled languages. Or it may be putting together a more direct competitor with CUDA that does not involve seven layers of translation and multiple processing passes. But their business is booming now and they need to be investing more, and investing more intelligently, in their software platform. The best processor / GPU is useless if programmers can't take advantage of it.

[nado]

What's sad is that Nvidia has been allowed to hobble the natural growth and improvement of OpenCL into something more competitive with CUDA. Why is Nvidia in the driver's seat at Khronos when they have a vested interest in their proprietary CUDA platform? It is a clear conflict of interest. If they want to keep their OpenCL users at 1.2 forever, that's their business, but they shouldn't be allowed to hold everyone else back.

AMD needs to push harder for continued evolution of OpenCL and forget chasing Nvidia. Remember, if you're always chasing, you're always behind. AMD needs to find a path to getting ahead in the GPU software ecosystem, not just seeking feature parity with CUDA. That may be pushing harder for CL C++, or other CL-enabled languages. Or it may be putting together a more direct competitor with CUDA that does not involve seven layers of translation and multiple processing passes. But their business is booming now and they need to be investing more, and investing more intelligently, in their software platform. The best processor / GPU is useless if programmers can't take advantage of it.

Sad or not... if you want things to change so badly, then DO SOMETHING about it Remember, these companies don't exist to cater to your whims.

[nado]

It's quite sad that we have fully working solutions for translating OpenGL to Vulkan, and Vulkan to Metal, but however there's still no 100% working solution for CUDA to OpenCL (or to Vulkan). It's very sad, because proprietary APIs are an 80s/90s thing that doesn't help long-term development, and that makes your code obsolete before it achieves beta stage.

Last I checked, there is a lot of software still doing the "80s/90s thing" and making money. Adobe, Microsoft, Google, Apple... those are just some big ones. So obviously it works for their business models, or they wouldn't be so succesful. Now if you're talking about YOUR wishes, then I would also mention that these companies don't exist to cater to your whims - unless you are a majority stake holder or possibly on the board etc.

[Mark625]

Sad or not... if you want things to change so badly, then DO SOMETHING about it Remember, these companies don't exist to cater to your whims.

Jeez, I'm not asking AMD to cater to my whims. I'm asking them to get a coherent platform strategy and for them to start leading instead of chasing. Right now their focus is divided between their proprietary Windows drivers and their open-source ROCm platform for Linux and HPC. They need a unified vision that leverages both platforms, instead of dividing their limited resources between the two.

I'm just a random user on the Internet. My only power is to share my opinion, that is the "something" that I can do.

[kiffmet]

Mark625
If Vulkan compute manages to establish as a well recieved and widely used standard, everything could run on AMDVLK.

[coder111]

Ugh, I'll go test it as soon as I have GPU compute working... I have a 5700XT. AMDGPU-pro drivers fail to run OpenCL successfully for me. I tried ROCm, that thing resulted in the whole machine crashing on some OpenCL tests. Come on AMD, your hardware is supposed to be working on Linux!

That being said, 3D and games work pretty much perfectly...