<div dir="ltr"><div>I think llvm/clang and SPIR-V will at some point lead to a situation where one could just use some restricted C++ 14/17 across devices.<br>A lot of parties seem to be going in this direction. Transcompiling OpenCL to CUDA should not be to hard to do but seems almost impossible to do perfect and even more so given that CUDA is defined only through what nvidia decides it needs.<br><br></div><div>I hope SPIR-V will take of separating the front- and back-ends of the toolchain.<br><br><a href="http://llvm.org/devmtg/2015-10/slides/Wu-OptimizingLLVMforGPGPU.pdf">http://llvm.org/devmtg/2015-10/slides/Wu-OptimizingLLVMforGPGPU.pdf</a> could become very interesting also.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 18, 2015 at 1:34 AM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, my comment about OpenCL dying was overly dramatic, I'm just<br>
wondering what will happen long term. I'm still cautiously optimistic<br>
AMD and Intel will have a good implementation of OpenCL C++ at some<br>
point, but that will probably take another year or so.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Nov 17, 2015 at 8:14 AM, Sergey Sharybin <<a href="mailto:sergey.vfx@gmail.com">sergey.vfx@gmail.com</a>> wrote:<br>
> While tis is an interesting concept, will it be same rock-solid as bare CUDA<br>
> itself or will have same weird issues as we've got with OpenCL kernels?<br>
> That's more a rithorical questions, but something we should keep in mind.<br>
><br>
> As for OpenCL -- to my knowledge Intel is currently very interested in it.<br>
> Also AMD improved OpenCL quite a lot in the past year, so don't think OpenCL<br>
> really dying.<br>
><br>
> On Tue, Nov 17, 2015 at 2:24 AM, Brecht Van Lommel<br>
> <<a href="mailto:brechtvanlommel@pandora.be">brechtvanlommel@pandora.be</a>> wrote:<br>
>><br>
>> This seems to be AMD's equivalent to the NVidia CUDA toolkit. The main<br>
>> interesting thing for Cycles is that this can compile to both AMD GPUs<br>
>> and NVidia GPUs (still using the CUDA toolkit underneath though).<br>
>><br>
>> It remains to be seen if using this is actually a good idea for<br>
>> Cycles, there's a bunch of questions:<br>
>><br>
>> * What are the advantages over OpenCL, why use this instead of an open<br>
>> standard?<br>
>> * What about Intel GPUs? Do we need OpenCL for those anyway, and if so<br>
>> why not use OpenCL for AMD too?<br>
>> * Or is this a sign that OpenCL is slowly dying, and eventually we'll<br>
>> have no choice but to use this?<br>
>> * Will all CUDA features that we use be available and will performance<br>
>> be equally good?<br>
>> * Will this work on OS X? NVidia has their own extra CUDA driver<br>
>> there, will AMD provide the same?<br>
>> * Does it allow dynamic loading, so that a single Blender executable<br>
>> works on all computers regardless of the GPU?<br>
>><br>
>> IF this can replace CUDA and OpenCL backends in Cycles then that could<br>
>> simplify things, but it would be unfortunate to give up on OpenCL and<br>
>> go with something proprietary instead.<br>
>><br>
>> I still hope the eventually there will be proper OpenCL support from<br>
>> all vendors, or even better, native support for GPUs in LLVM Clang.<br>
>> But so far the fragmentation isn't getting any better, with Apple<br>
>> choosing Metal over Vulkan, NVidia not supporting OpenCL properly, and<br>
>> OpenCL not providing enough control for optimal CPU performance.<br>
>><br>
>> On Mon, Nov 16, 2015 at 5:52 PM, Zauber Paracelsus <<a href="mailto:zauber@gridmail.org">zauber@gridmail.org</a>><br>
>> wrote:<br>
>> > So, AMD has launched what they call the Boltzmann Initiative, with the<br>
>> > apparent aim to create a compiler that allows CUDA to work on AMD<br>
>> > graphics hardware.<br>
>> ><br>
>> > And I just have to wonder: what affect would this have on<br>
>> > Blender/Cycles, especially in light of the relatively recent addition of<br>
>> > the OpenCL split-kernel work?<br>
>> ><br>
>> ><br>
>> > PS: Sorry for not providing a link, but doing so caused my original<br>
>> > message to be blocked by the spam filters.<br>
>> > _______________________________________________<br>
>> > Bf-cycles mailing list<br>
>> > <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
>> > <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
>> _______________________________________________<br>
>> Bf-cycles mailing list<br>
>> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
>> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
><br>
><br>
><br>
><br>
> --<br>
> With best regards, Sergey Sharybin<br>
><br>
> _______________________________________________<br>
> Bf-cycles mailing list<br>
> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
><br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</div></div></blockquote></div><br></div>