[Bf-cycles] Boltzmann Initiative and Cycles?
martijn.berger at gmail.com
Wed Nov 18 09:14:57 CET 2015
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.
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.
I hope SPIR-V will take of separating the front- and back-ends of the
become very interesting also.
On Wed, Nov 18, 2015 at 1:34 AM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:
> Yes, my comment about OpenCL dying was overly dramatic, I'm just
> wondering what will happen long term. I'm still cautiously optimistic
> AMD and Intel will have a good implementation of OpenCL C++ at some
> point, but that will probably take another year or so.
> On Tue, Nov 17, 2015 at 8:14 AM, Sergey Sharybin <sergey.vfx at gmail.com>
> > While tis is an interesting concept, will it be same rock-solid as bare
> > itself or will have same weird issues as we've got with OpenCL kernels?
> > That's more a rithorical questions, but something we should keep in mind.
> > As for OpenCL -- to my knowledge Intel is currently very interested in
> > Also AMD improved OpenCL quite a lot in the past year, so don't think
> > really dying.
> > On Tue, Nov 17, 2015 at 2:24 AM, Brecht Van Lommel
> > <brechtvanlommel at pandora.be> wrote:
> >> This seems to be AMD's equivalent to the NVidia CUDA toolkit. The main
> >> interesting thing for Cycles is that this can compile to both AMD GPUs
> >> and NVidia GPUs (still using the CUDA toolkit underneath though).
> >> It remains to be seen if using this is actually a good idea for
> >> Cycles, there's a bunch of questions:
> >> * What are the advantages over OpenCL, why use this instead of an open
> >> standard?
> >> * What about Intel GPUs? Do we need OpenCL for those anyway, and if so
> >> why not use OpenCL for AMD too?
> >> * Or is this a sign that OpenCL is slowly dying, and eventually we'll
> >> have no choice but to use this?
> >> * Will all CUDA features that we use be available and will performance
> >> be equally good?
> >> * Will this work on OS X? NVidia has their own extra CUDA driver
> >> there, will AMD provide the same?
> >> * Does it allow dynamic loading, so that a single Blender executable
> >> works on all computers regardless of the GPU?
> >> IF this can replace CUDA and OpenCL backends in Cycles then that could
> >> simplify things, but it would be unfortunate to give up on OpenCL and
> >> go with something proprietary instead.
> >> I still hope the eventually there will be proper OpenCL support from
> >> all vendors, or even better, native support for GPUs in LLVM Clang.
> >> But so far the fragmentation isn't getting any better, with Apple
> >> choosing Metal over Vulkan, NVidia not supporting OpenCL properly, and
> >> OpenCL not providing enough control for optimal CPU performance.
> >> On Mon, Nov 16, 2015 at 5:52 PM, Zauber Paracelsus <zauber at gridmail.org
> >> wrote:
> >> > So, AMD has launched what they call the Boltzmann Initiative, with the
> >> > apparent aim to create a compiler that allows CUDA to work on AMD
> >> > graphics hardware.
> >> >
> >> > And I just have to wonder: what affect would this have on
> >> > Blender/Cycles, especially in light of the relatively recent addition
> >> > the OpenCL split-kernel work?
> >> >
> >> >
> >> > PS: Sorry for not providing a link, but doing so caused my original
> >> > message to be blocked by the spam filters.
> >> > _______________________________________________
> >> > Bf-cycles mailing list
> >> > Bf-cycles at blender.org
> >> > http://lists.blender.org/mailman/listinfo/bf-cycles
> >> _______________________________________________
> >> Bf-cycles mailing list
> >> Bf-cycles at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-cycles
> > --
> > With best regards, Sergey Sharybin
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-cycles
> Bf-cycles mailing list
> Bf-cycles at blender.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-cycles