Octane Render 2.0

[krautsourced]

So, I feel some of the calculations made here are a bit off. I'm speaking from my experience here of course, but:

 

- there's no significant advantage in using Tesla/Quadro cards over GTX cards for rendering, except potentially more VRAM and potentially longer life of components/less power use. All GPU renderers use single precision floating point calculations, and the Tesla/Quadro cards are only faster with double precision.

- comparing the cost of a single-CPU machine with a single-GPU machine is unfair, since a) you can and should fit multiple GPUs in a single machine, multiple CPU are almost exponentially more expensive c) multiple CPU are not nearly as fast as multiple GPU

 

I beta tested Redshift and while it was nice, I never got the feeling it worked as smoothly as Octane. One of the big advantages of octane, imho, is that it is very easy to get a good looking result without much tweaking of parameters (much like Maxwell in that respect). Also, octane is integrated in a whole lot more applications (Houdini noticeably missing, unfortunately). Redshift iirc was Maya only.

[krautsourced]

A) Every Tessla needs server with CPU.

The price of two modern Xeons: 3000$ + 1500$ for a node.

C) Tessla: 5000$ + 1500$ for a node.

Speedy rendering, still pricy, limited, and doesn't scale at all.

 

What do you mean by "doesn't scale at all"? Multiple cards scale in an almost linear fashion in Octane. Also, as said before, Tesla is pointless imho, GTX780 Ti 6GB is the best bang for the buck.

[krautsourced]

I hope not.

As many others have said before, I can't see GPU rendering as something that fits wel in the CGI pipeline for animation/vfx.

 

Blur Studio seems to disagree: 

 /  

[symek]

Most here can't rely on GTX, because 16GB of RAM at rendernode is a minimum these days for post purposes we use Houdini for.

 

What do you mean by "doesn't scale at all"? Multiple cards scale in an almost linear fashion in Octane. Also, as said before, Tesla is pointless imho, GTX780 Ti 6GB is the best bang for the buck.

 

Making Tesla monster computer:  5XTesla + big station with places for it gives me ~30.000 for a server. At that price I got 6 double Xeons render nodes with 16GB of RAM each - easy to upgrade for, say, simulation purposes up to 64GB, easy to put Tesla or Phi inside too. Good hardware investment. It's flexible, versatile and has comparable performance with monster machine for all but interactive rendering.

 

So unless you have a demand for interactivity or you work alone and doesn't need anything above Octane/Redshift functionality, you're OK. But if you want to apply your interactive workstation across studio, you end up with pricy yet limited, well, the end. Unlike CPUs which, despite brute GFLOP per chip limitation, simple add their performance one to another pretty endlessly.

[symek]

Blur Studio seems to disagree

 

 

Not Blur, but one of its sups private initiative. You take any CPU brute force path tracer (Mistuba, embree), connect it to 3 PC with decent Xeons and you got the same thing, albeit little less sexy, because it's a CPU, not GPU after all. Again, this is specific interactive application. No one claims GPU doesn't have a future or its advantages. Just says Nvidia hips doesn't make sky any bluer.

Edited April 4, 2014 by symek

[symek]

Interesting fact about Pixar's Katana plugin for close-to-realtime previs of PRman scenes based on Nvidia Optix. They showed case it on last Siggraph at the occasion of Monster University premier, and again recently at current GTC.

 

They usually don't reveal any details, just saying how their awesome technology Optix previz PRman scenes during work on Monster University. Then you hear people who actually developed it, and a) prman shaders have to be baked into textures first and then used by basic path tracer tech wasn't really used in production,  it wasn't ready, after all baking whole scene into a textures isn't always that easy... Again as a custom technology tailored to specific needs, awesome. Other than that, hip.

 

As as side note, I've watched most of this year presentations of Nvidia conference. Interestingly most of the benchmarks presented there are between single or at most multi-threaded CPU code against custom GPU code. They hardly use SIMD at CPU because unlike CUDA, it isn't used automatically except for a most obvious scenarios. Once someone dare to optimize CPU code with intrinsic, the gap falls down x4 and becomes pretty irrelevant.

 

This tells something about current stage of technology and explains why INTEL puts some much efforts in compile time optimizations (ispc, cilkplus, llvm, vtune). The power is there, yet not as apparent as in CUDA, specially from the outside, because if you have a choice between programming CPU with compile-time optimization versus CUDA, I hardly believe the latter one comes without pain.

Edited April 4, 2014 by symek

[Guest tar]

Yup - the formulae for conferences and product announcements is usually.  Reality = Presentation * 0.15 

[Guest mantragora]

EDIT: Nevermind. It was posted on previous page. Sorry!

Edited April 11, 2014 by mantragora

[lisux]

This tells something about current stage of technology and explains why INTEL puts some much efforts in compile time optimizations (ispc, cilkplus, llvm, vtune). The power is there, yet not as apparent as in CUDA, specially from the outside, because if you have a choice between programming CPU with compile-time optimization versus CUDA, I hardly believe the latter one comes without pain.

I agree with Symek.

LLVM is for me the technology for the future.

Working on GPUs requires a lot of custom code and create big constraints in the pipeline. Hardware is far from being standardised, there is a lot of fragmentation.

I think that before GPUs become a standard and cheap framework things like LLVM will make regular CPUs a cheaper solution with a very similar performance to GPUs.

Edited April 11, 2014 by lisux

[Mandrake0]

i hope that sesi will leave the openCL implementation and invest more time in vex => llvm optimization. 

 

thanks to intel you get speed up in the cpu side and thanks to nvidia you also can create gpu bytecode because they have also a llvm implementation.

for the amd side there are also some development going on for creating a llvm backend.

 

if it's possible it would be interesting if mantra could be 100% in vex like that you can create a optimized render core for just that task which you configured.

or compile code for a fpga would be pretty sick. but that is more a dream but a cool one :-) 

[lisux]

i hope that sesi will leave the openCL implementation and invest more time in vex => llvm optimization. 

 

thanks to intel you get speed up in the cpu side and thanks to nvidia you also can create gpu bytecode because they have also a llvm implementation.

for the amd side there are also some development going on for creating a llvm backend.

 

if it's possible it would be interesting if mantra could be 100% in vex like that you can create a optimized render core for just that task which you configured.

or compile code for a fpga would be pretty sick. but that is more a dream but a cool one :-)

As far as I remember VEX is starting to use LLVM:

http://www.sidefx.com/docs/houdini13.0/news/12_5/vex

About usin LLVM To output code for GPUs, I agree this should be the way to go, and make OpenCL/Cuda obsolete.

Mantra being implemented using VEX is impossible. In some parts of mantra Vex makes sense in others note at all.

VEX is powerful but has it's limitations.

[eetu]

About usin LLVM To output code for GPUs, I agree this should be the way to go, and make OpenCL/Cuda obsolete.

 

As far as I can see that's what SPIR is about; see page 10 and onwards; https://www.khronos.org/assets/uploads/developers/library/2014-gdc/Khronos-OpenCL-DevU-GDC-Mar14.pdf