
Blender 2.79: OpenCL on par with CUDA - nedsma
https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/OpenCL
======
aidos
There was an article on here a couple of months back that was an intro to
blender from a geek / vim perspective. I felt a bit inspired and downloaded it
to have a play. It's an absolutely brilliant application - I highly recommend
giving it a try.

Edit here's the post
[https://news.ycombinator.com/item?id=13379597](https://news.ycombinator.com/item?id=13379597)

~~~
thomastjeffery
Having learned blender first is likely why Vim was so appealing to me.

Blender's UI is so much better this way. The idea that the functionality of
any professional software tool should be immediately visible is just silly.
Photoshop, GIMP, Autocad, 3DS Max, Maya, etc. all follow that philosophy, and
just end up with way too many buttons and menus for anyone to want to sift
through. Blender shows functionality only where it is needed in the most
beautiful modular system I have ever used.

~~~
aidos
Agreed. It felt really streamlined and the mental model felt instantly
comfortable. If you want to rotate something you can select - rotate - fix
axis - choose degree, all in a very programmatic way.

One thing I ran into was it seemed there are some shortcuts that are essential
and basically wired to the number pad so I had to buy an external keyboard
(and non trackpad mouse).

I haven't had time to get back to it again but I'm looking forward to sitting
down and having another good play.

Edit I'm not super familiar with autocad but I make software for construction
companies so I've seen it used a bit. You can do everything in a vim like
command manner. I think it had a lisp prompt.

~~~
mikenew
If you toggle `File -> User Preferences -> Input -> Emulate Numpad` you can
have the usual number keys work like the numpad. I actually prefer it that way
to so I can change the camera without having to move my hand all the way to
the right of the keyboard.

------
zengid
Quoted from the article:

"OpenCL works fine on NVIDIA cards, but performance is reasonably slower (up
to 2x slowdown) compared to CUDA, so it doesn't really worth using OpenCL on
NVIDIA cards at this moment."

I wonder if that's intentional on NVIDIA's part.

Does it mention which version of OpenCL they're using? I'm looking forward to
hearing news about v2.x and SPIR-V.

~~~
pavanky
I don't think it has anything to do with the driver itself. At least in my
experience, the custom code you write performs more or less the same across
both CUDA and OpenCL. The issues arise when you are using the toolkit
libraries (like BLAS and FFT). cuBLAS and cuFFT are much much tuned for NVIDIA
hardware than any OpenCL versions available at the moment.

~~~
llukas
Are there any pain points for cuBLAS and cuFFT?

~~~
pavanky
Not really, but they are only supported in CUDA. For OpenCL you will have to
use clBLAs and clFFT (written and maintained by AMD). This means they are not
exactly tuned for other architectures.

~~~
dragandj
I prefer to use OpenCL, but I think the second key factor why Nvidia dominates
(the first is they integrated tooling) is that cuBLAS, cuFFT, cuDNN et.al work
out of the box when you install CUDA Toolkit. clBLAS and clFFT? Good luck
using them even on AMD hardware, yet alone on someone else's. And, of course,
there is no cuDNN equivalent (that is beyond experimental)...

------
valine
Blender's progress has been astounding. I remember a while back they anounced
the OpenCL implementation was being put on hold for a undetermined amount of
time due to limitations with AMD cards. This really is an exciting
announcement. It's great to see it on HN too.

~~~
thrillgore
Blender is probably one of the most successful OSS projects since Linux. In
the span of five years, you wouldn't be caught dead using it over Maya. Now,
its visa versa.

~~~
sametmax
It is espacially amazing given:

\- the problem blender is solving is super hard

\- the competition was way ahead

\- FOSS don't have great track record for this kind of challenge (gimp has
never replaced photoshop nor LibreOffice MSO)

\- they don't have that much resources

\- professionals are very demanding

\- the graphic space is not really foss friendly

\- the amount of work they poured into this is incredible

They are heroes really.

~~~
zaphar
One of the reasons for their success are the Open Movie and Open Game
projects[0]. It forces them to actually accommodate the needs of working
artists and designers in their tool. It also showcases the power of Blender
and gets the attention of potential users. The production values are actually
pretty good for the projects which get's peoples attention.

[0]:
[https://www.blender.org/features/projects/](https://www.blender.org/features/projects/)

~~~
pasta
I think the main reason is good software design.

It's so modular that it's very easy to extend.

A new fluid sim algorithm? A few months later Blender is shipping it.

That's also the reason it's fast. It starts in one or two seconds.

~~~
badosu
I can't talk about the specifics of the software design.

But if you take into account how the Blender project is handled with
consideration of how to sustain itself via the Blender Foundation, and all the
related projects, you can observe how an outlier it is compared to all similar
ambitious projects that are not doing so well.

This is a bad and a good sign: it makes evident how little FOSS projects take
in account it's sustainability over time, on the other hand it presents an
opportunity for huge improvements in this area.

------
tombert
The performance of OpenCL has generally been fine for me, particularly on AMD
GPUs, but I have to say I think CUDA is a lot simpler to work with.

OpenCL is one of those things that I never felt fully comfortable working
with, but I felt productive in CUDA after a week or two. Granted, I learned
them in that order, so it's possible that CUDA got an unfair head-start, but I
stand by my initial thesis.

~~~
shawn-butler
You might want to take a look at SYCL for higher-level abstractions if that
was your preference.

There is an open-source implementation to dig into:
[https://github.com/Xilinx/triSYCL](https://github.com/Xilinx/triSYCL)

~~~
tombert
Actually, nowadays since I mostly do esoteric functional stuff, I mostly use
the wonderful `accelerate` package for Haskell:
[https://www.stackage.org/package/accelerate](https://www.stackage.org/package/accelerate)

It abstracts away most of the difficult stuff.

~~~
Athas
Out of curiosity, what are you doing with Accelerate? I've been looking for
examples of people using it in anger.

~~~
tombert
I can't get into the weeds of it because of some NDA chicanery, but there are
a couple vector transformations that I have to do on a not-quite-big-data-but-
also-too-big-for-regular-CPU set of data. The initial version of the project
was doing some basic stuff in Python, but that proved to be slow so I rewrote
most of it in Haskell and Accelerate.

------
roel_v
I don't quite get this page; isn't it more accurate to say 'amd on par with
nvidia'? It seems for amd they use opencl, for nvidia cuda; but you can run
opencl on nvidia too (1.2 only, apart from experimental, partial 2.0 support
in the very latest drivers, but still).

I mean, there are numerical libraries that run 2x as fast on nvidia compared
to their most optimized opencl implementations, because they use 'gpu
assembly' specific for nvidia cards; how does that fit the 'opencl on par with
cuda' claim? It depends on what effort is spent on optimizing for a certain
platform, not what api is used...

I'm working in opencl myself but it's frustrating that I'll never get as much
performance as I would when using opencl, even when I'm using gtx gpus myself.

~~~
jacquesm
> as I would when using opencl

Didn't you mean CUDA?

~~~
roel_v
Yes I did, mixed that up, thanks.

------
dharma1
Cuda -> OpenCL transpiler:

[https://github.com/cuda-on-cl/cuda-on-cl](https://github.com/cuda-on-cl/cuda-
on-cl)

------
throwblender
Blender is a really fun program to use, Tons of tutorials and information on
youtube etc... I think more education could use 3d programs like this to help
with algorithm visualization.

I made this video about worker in tech with blender.

[https://vimeo.com/98728314](https://vimeo.com/98728314)

The worker is slaving away at his terminal, he is writing code that creates
the 'feed' of apps/entertainment/media/etc.. for the insatiable appetite of
society (Represented by the somewhat-similar-to-a-hungry-hippo character in
the depths). Who are these other two glowing beings? What do they represent?
My friends have tried to guess some explanations, but I'll let each audience
member decide for themselves.

------
radarsat1
Would it be a completely stupid idea to write a CUDA-based OpenCL back-end?
i.e., an OpenCL-to-CUDA translator, so you can program your kernels in one
single language but still get the benefit of the NVidia CUDA compiler?

Or are their machine models so different that that is an unreasonable thing to
even try..

~~~
jjn2009
It's likely better to just write/use libs which abstract the CUDA/OpenCL level
away for generic GPU type tasks. Unless you have really strict performance
requirements or are writing a very specific piece of GPU code, in which case I
cant image OpenCL-to-CUDA translator would handle that case well either.

They both have very similar ideas for the core of the APIs then CUDA adds a
bunch of stuff on top of it for ease of use and performance which is tightly
coupled with the hardware in some cases. It would be a lowest common
denominator situation with a lot of those features in CUDA.

------
k_sze
What part of that page says it has to do with version 2.79 of Blender though?

I think the actual page that talks about Cycles rendering performance
improvements in version 2.79 is this wiki page:
[https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.7...](https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.79/Cycles)

But that page doesn't seem to mention any comparison between OpenCL and CUDA.

I think something is still missing to make a concrete link between "OpenCL on
par with CUDA" and version 2.79 specifically.

------
anc84
It looks significantly faster in those benchmarks! Koro takes almost half as
long!

~~~
KaoruAoiShiho
That's nvidia on opencl not cuda.

~~~
floatboth
That's not clear, the chart just says "comparison of cards", the article does
not mention how it was made

~~~
KaoruAoiShiho
The entire page is talking about opencl, unless it's deliberately misleading
it's pretty clear it's opencl.

------
geertj
Anyone knows how to get OpenCL working on Linux using the open source AMDGPU
driver (not the AMDGPU-PRO driver which is their proprietary driver)?

~~~
vedranm
As the other poster said, you need Clover, and then you can use clinfo [1] to
check you have everything installed and working.

I can't say for sure what's the latest state of Blender; somebody on Freenode
#radeon mentioned a few months ago that Blender is failing to compile its
OpenCL kernel, while before that somebody mentioned it as working, but quite a
bit slower than with the proprietary driver. I suggest to try it yourself and
report any bugs you encounter as blocking [2].

[1] [https://github.com/Oblomov/clinfo](https://github.com/Oblomov/clinfo)

[2]
[https://bugs.freedesktop.org/show_bug.cgi?id=99553](https://bugs.freedesktop.org/show_bug.cgi?id=99553)

------
gt_
Either way, this has no effect.

The 3D artists using GPU production rendering require at least 4 of the top of
the line cards for their workstation. My workstation crams x5 980Tis in the
case (2 off the board with PCIe risers).

Joining the community using this approach not only requires the hardware and
ability to build it but also new rendering software and a lot of time to learn
a new approach/mindset/workflow. The best software available is crucial. It is
worth every penny to invest in the best rendering software when entering this
environment. Right now, there are 3 that matter and none of the GPU-specific
remdering softwares support OpenCL. There is a unique exception with V-Ray,
the last gen maverick of rendering engines. V-Ray's future in GPU rendering
could be bright if the new companies don't entirely outpace them in GPu
development. Either way, every part of the people actually using this solution
in the real world is investing all of their time, money, energy into Nvidia
right now.

The devs at Redshift, my chosen renderer, insist OpenCL is not even close to
having what they need.

Pseudo-realtime feedback could actually advance the craft to a new era and
Nvidia is carrying the entire ecosystem.

~~~
przemoc
Just out of curiosity (it's not my field), what are those 3 renderers that
matter right now?

Somehow I read your comment as V-Ray is not among them as being last-gen. I
remember that years ago there was a lot of buzz regarding Arnold (and it was
justified to some extent AFAIR, at least judging by opinions of pleased 3D
crowd), but maybe it's last-gen too now? Many years ago there was Brazil, but
quick googling shows it's only for Rhino now? I haven't heard about Redshift
till now, though.

~~~
gt_
The 3 GPU renderers that matter are: V-Ray RT, Octane, Redshift

CPU renderers are a different story but Arnold is right up there with V-Ray.
CPU renderers are tried and true, reliable and robust.

V-Ray is the only company making both CPU and GPU renderers. The GPU version
can render most of the same shaders but the backward compatibility
requirements slow it's progress. It's OpenCL support is always behind CUDA as
well.

