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

this means the denoising would be very ‘animated’ right? (the textures would seem to wave and heave?)
(like the camera is on LSD?)

Denoisers usually put a proper texture on the image after its denoised… Well thats what the render man guy said at siggraph anyway lol

Maybe not quite as intense as you might be imagining, but close. Think flickering, pixel popping, high frequency texture swimming, etc.

Well, I tweeted at Ton that I would send my GTX 980 Ti to wherever it needs to go to, because it seems they closed the bug due to not having a GTX 980 Ti.

Ton himself said in the bugreport comments that he plans to get a 980Ti in march. I hope it actually happens because my 980ti just came in.

When will CUDA on amd cards be avaiable in Cycles?

Only if AMD makes it so.

:confused:
CUDA is Nvidia property. And it requires specific nvidia hardware architecture and stuff.

This thread talks about a software written for CUDA in a classic “CUDA” way that should work in all cards through some kind of magic mysterious hack.

I hope you send it to them soon because at the moment they don’t have a GM200 card and they can’t fix the issue.

For Cycles to benefit from OTOY port of CUDA to AMD gpus, OTOY would have to Open-source it, but we don’t know when/if it will happen.

https://twitter.com/OTOY/status/709773347077251077

AMD testing shows that in many cases 90 percent or more of CUDA code can be automatically converted into C++ by HIP with the final 10 percent converted manually in the widely popular C++ language

http://www.amd.com/en-us/press-releases/Pages/boltzmann-initiative-2015nov16.aspx

Was fun looking back & I wonder now… What bulls are we getting next year?
:smiley:

This was something old i looked at a while back, Either Otoy were full of it, Or the article was nonsense, Or were just not seeing the fruits of Otoys so called miracle code.

But OpenCL 2.1 was built the way it was for a reason. Nvidia not supporting opencl 2.1 (or even 2.0) is also for a reason.

Which is that Opencl 2.1 was basically designed to get rid of the C code to OpenCL platform, OpenCL 2.1 is all about basically allowing OpenCL devices to run C++ code on the GPU in an open platform (something only Cuda even if badly has been able to do so far)

This page explains some helphull things about what really should be possible with Spir-V:

http://www.alphanew.net/index.php?site=overview&newsID=111

This is old stuff but gets to the point, AMD has a cuda converter that NEARLY works already if you check their OpenGPU page

The release of SPIRV-LLVM and all the talk about Vulkan at GDC made me curious as to how far we actually are from compiling other languages, particularly full-featured C++, to the GPU. So far, using somewhat current versions of C++ on the GPU has been a privilege reserved to CUDA programmers specifically targeting NVIDIA GPUs. TLDR: As it turns out, it is already possible today. See command lines in the center, experimental compiler binaries at the bottom.

Sources
Interestingly, clang implements OpenCL with very few additions to the C99 front end, which in turn shares most of its logic with the C++ front end. As it turns out, a miniscule set of changes allows the use of any C++ standard in combination with the OpenCL extensions. Merging in the OpenCL headers and SPIR-V code emission from Khronos’ OpenCL C Compiler, we can in fact already obtain an end-to-end solution compiling C++17 to SPIR-V. New commits can easily be merged in as clang continues to evolve. You can find my experimentally patched version of the current clang master branch here: https://github.com/tszirr/clang

Compilation of this patched version of clang will also require an up-to-date port of LLVM-SPIRV to the LLVM master branch, which I did here: https://github.com/tszirr/SPIRV-LLVM

Usage
Now, we can simply compile C++ kernels to SPIR-V bit code using the following command line:

clang -cc1 -std=c++1y -triple spir-unknown-unknown -emit-spirv -x cl -o mykernels.cpp.sv mykernels.cpp
We can investigate the generated SPIR-V bit code using the LLVM-SPIRV tool:

llvm-spirv -to-text -o mykernels.cpp.sv.txt mykernels.cpp.sv
Disclaimer
I successfully compiled a few templates, classes with constructors and destructors, and group-shared/global/generic/image memory accesses. Note that so far, however, this combination of languages is officially unsupported and will only partly follow the OpenCL C language specification, particularly not the provisional OpenCL 2.1 C++ specification. I have been in contact with the clang/LLVM codebase for merely a day, therefore I am certainly no clang/LLVM expert and cannot assess the full extent of code paths where C++ and C99 front ends diverge. I fixed one minor issue for C++ declarations involving memory spaces, but more might turn up elsewhere.

Binaries
Since building clang and LLVM takes quite some time, I compiled a minimal set of experimental x64 Windows binaries that can get you started: http://alphanew.net/releases/experimental/clang-oclxx-spirv.zip

Backwards Compatibility
(Note on legacy OpenCL/SPIR compatibility: For OpenCL implementations only supporting the old LLVM 3.x-derived SPIR format, you can use SPIR-V as a stable intermediate format that can then be fed to the official LLVM 3.x-based SPIRV-LLVM tool for reverse conversion from SPIR-V to SPIR. Be aware that you will have to obtain that official binary elsewhere, since the llvm-spirv binary provided in the above zip file is based on the current LLVM master branch and therefore unsuitable for that purpose, it merely serves for debugging/disassembling purposes.)

Their are projects in progress to convert Cuda to spir_v through the Kronos compiler. I just say sod it, Cuda’s old, why even give it the time of day. Most opencl 2.1-2.2 coders would say the same.

What you say here is also reverse engineering. And by the way it’s one of the best examples.

Regards,
Albert

Well, I decided to look into if this was true or not and Otoy DOES have a working cuda multi platform compiler. But better still Octane 4 will include Brigade realtime path tracer with plugins for unity and UE4 (UE4 is their main effort in this area though). In this video they show realtime path tracing with brigade noise free on one GPU, when last year they released the same video but needed 30 GPU’s to get the same general performance.

Ive been waiting for Brigade for years, Now im finally going to be able to get my hands on it. Awesome.

I am presently fooling around with Blender for Android with what appears to be Vulkan Graphics. I do have problems of getting render to video textures for a minmap to work