CUDA reverse-engineered and ported to AMD, INTEL and ARM GPU.

“…Otoy has ported the CUDA language to run on AMD, Intel, and ARM GPUs for the first time ever. That means any application written in CUDA can run, without modification, on all major chipsets and platforms. While there is an independent GPGPU standard dubbed OpenCL, it isn’t necessarily as good as CUDA, Otoy believes…”

Finally maybe there is no need of opencl for Cycles either.

If that really works this easy and flawless then wow I am impressed!

That is intresting…

I wonder whether they built their own compiler for it, or whether they are implementing a system similar to cycles where you code once for multiple compilers.

RIP cycles lol

Octane (made by otoy) has its own place as does cycles… cycles wont die unless octane becomes opensource, which i doubt it will happen.

Will this tool be used for other software? How much will it be?

This is what they said.Wouldn’t that be cool.

Otoy will be building new backends to this framework to allow CUDA to target alternative applications programming interfaces (APIs) such as Vulkan, DirectX, and OpenGL – across Android, Playstation 4 and WebGL 3 (the latter with the help of JavaScript creator Brendan Eich).

Sounds like a compiler to me. If it generates hardware specific bytecode from cuda code.

:rolleyes:

It says so in paragraph four of the article that the OP linked to…I guess no one read the article then.

To me too.
Once done, IMO it’s all a matter of performances/hardware price range.
Really worthwile? I’m a bit skeptical.

Now I could buy another amd 390x :slight_smile:

This sound like black magic to me and I’m really curious to see some benchmarks… I have absolutely zero knowledge about CUDA or any other GPU computing stuff, but I guess something that is translated to another architecture will never run as fast as if it was specifically written for it? We’ll see…

well to make a cuda code to opencv converter i would have said yeaa thats fine. but to redo the cuda on a other platform is another thing and not to use opencl or any of these api’s for a simple transfer… well for me it sounds more like a big buzz for the investors to get more money.

btw. did the released there opencl implementation from the render? nearly 1 year ago they said they will have a render with that functionality in the second half of 2015 production ready!

Cycles is the only render engine I use and I love it xD but octane tries to include everyone while high end nvidia cards dont even work correctly with cycles ATM my butt hurt for cycles will stop when my card works again haha

You can’t do that with any of those graphics API they say they’ll target. With OpenCL2 or Vulkan you can target SPIR-V, which is still a rather high-level intermediate representation.

I can kinda see how they could translate some CUDA code into OpenGL(GLSL)/Direct3D(HLSL) or Metal compute shaders and then hope that the shader compiler makes the best of it. I doubt they’ll support a complete, compliant CUDA implementation. Similar things have already been done or are being worked on, so it’s not really big news.

That is not true, in CUDA everything is a compute kernel. “Compute Shaders” are part of graphics APIs like OpenGL or Direct3D.

Could you expand on that? I’m getting a high end Nvidia card in the coming weeks.

Check bug report here.

That’s bad news right there. I hope my 750 euro investment won’t go to waste. I’ll look into learning some other GPU based renderer in the meantime.

At least from the results in the spreadsheed, it seems that these huge slowdown issues only really appear on Win10, so the solution is pretty simple: Use Win7 (or Linux, of course).
Also, considering that the same code is used in Blender on Win7 and Win10, this is most likely a Driver/OS issue, nothing Blender could fix - indeed, googling around shows some posts about GM200 problems with Win10.

Regarding the topic of this post: Generally, NVCC outputs PTX code as an intermediate step (kind of like GPU assembly code). That can of course be translated to other architectures, no real need to even write an own compiler there.
However, I do have some doubts about that article: First of all, you can’t just simply write low-level code for e.g. AMD cards, you still have to go through their regular drivers (so I’d guess that they actually generate OpenCL code from the CUDA code).
Also, some of the CUDA features require hardware support, which other hardware just doesn’t have (like dynamic parallelism). So, you have to do some stuff in software, which means a huge slowdown.
Generally, judging from the amount of details in that post (pretty much zero), the mistakes (like “compute shaders” in CUDA, as BeerBaron pointed out), the general tone of the whole thing (“beautiful programs”, “beautiful games”, “big breakthrough”) and the page where it was posted, I’m pretty sure that it’s more like “Hey, we did something concerning games and new hardware that’s really fancy, give us your investment millions!” instead of a serious and reliable technical info.