AMD Working On CUDA Source Translation Support To Execute On FirePro GPUs

[jaxxed]

How long before we see a new CUDA version that offers minor improvements but breaks this?

[oldskool69]

such wow, this amd and nvidia, tell me more of your great marketing strategies.

[oleid]

Interesting that only FirePro is getting this. But, aside from drivers and ECC memory, there is otherwise no difference between Firepro and Radeon, so I guess AMD needs something else to give FP some edge. If AMD can get CUDA to work on Radeon though, that will give their IGPs some HUGE leverage. Using their IGP for physx could be really appealing to gamers.

I'd be surprised if it only works on firegl.

[oleid]

Well... the AMD OpenCL compiler is not capable of compiling and/or running the valid Blender Cycles OpenCL Mega-Kernel code and now they want to compile and run CUDA code?

You are taking about this?

http://developer.amd.com/community/blog/2015/07/10/collaboration-and-open-source-at-amd-blender-cycles/

[wodencafe]

No it's not. It's building the bridge that Nvidia doesn't have. Nvidia has no professional OpenCL tools to touch AMDs. This will increase AMD sales and once in the tiering with OpenCL will show vendors they have a much better future strategy.

How exactly is AMD's "working on" support for CUDA supposed to build a bridge to OpenCL?

Wouldn't it instead give developers the incentive to just stick with CUDA, rather than preparing for a rewrite for OpenCL?

Hypothetically speaking, that rewrite would buy NVidia enough time to catch up to AMD on OpenCL support anyway.

[bridgman]

We are not supporting CUDA. What we are providing is a standard C++ compiler for GPU/CPU plus tools that simplify porting CUDA apps to use it. See pic from Anandtech article...

[SystemCrasher]

and they're working to deliver proper headless Linux support for AMD GPU compute servers.

IIRC, OpenCL running on top of MESA can do it for a while... and split of devices to expose compute/render nodes independently of everything else has been completed few kernel versions ago and now it just happens to be default.

And on side note: dear AMD, unless you have excessive amount of resources, it seems to be kinda unwise to try to change approaches, compilers and so on all the time. First there was opencl. And it started to gain some steam. AMD has told there is HSA. Now they are up to something else. Some new compilers, etc. Uhm, well, slow down with introducing new cool stuff a bit and do at least something on a decent technical level comparable to cuda, dammit. And ideally, show nvidia how low blow looks in Linux - make it all-open, lol. Finally there're some programs using openCL. And uhm what? Catalyst is bugged bunch of horrors. Opensource driver is half baked and missing some essential features. So AMD haves good hardware and talented engineers. And their management still seems to be in SNAFU state. Just as usually. It makes little sense to release various vaporware-class apis and other cool stuff, unless you have resources to materialize them and can offer adequate quality. And its not like if I want to learn new compiler or runtime or something like this for each and every day. As simple as that. No, sure, PR is a good thing. But it going to be BAD PR when you throwing like 3 vaporware-class apis every year or two.

[bridgman]

No change in direction other than adding some porting tools to make it easier for existing HPC users to run on our HW. This is the latest version of the HSA stack, and HCC is the latest version of the C++-over-HSA compiler. It just gets more interesting when you run it on a box of dGPUs instead of a single APU.

HSA isn't a programming language on its own (other than the HSAIL IR), it's a compute stack that supports a variety of standard languages and tools.