Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DreamWorks releases OpenMoonRay source code

github.com

Post reply on HN
Print view View original

131–140 of 154 posts

Re: DreamWorks releases OpenMoonRay source code

#131

Post by jb1991 »

jsheard wrote: post #58
bhouston wrote: post #56

Earlier quoted context omitted.

So we just need GPUs with 128GB of ram then? Or move towards the Apple M-series design where CPU+GPU both have insanely fast access to all ram...

It's easier said than done, there's consistently a huge gulf between CPU and GPU memory limits. Even run-of-the-mill consumer desktops can run 128GB of RAM, which exceeds even the highest end professional GPUs VRAM, and the sky is the limit with workstation and server platforms. AMD EPYC can support 2TB of memory!

It’s not just about memory. The path tracing algorithm is a natural fit for CPU threads but very difficult to design for efficient use of GPU threads. It’s very easy to leave many of your GPUs threads idle due to the divergence, or overflowing the registers, and any number of other things that are very natural to path tracing.

Re: DreamWorks releases OpenMoonRay source code

#133

Post by jocaal »

aprdm wrote: post #67
bri3d wrote: post #12

Earlier quoted context omitted.

This paper is the first place I've found a production use of Knights' Landing / Xeon Phi, the Intel massively-multicore Atom-with-AVX512 accelerator system, outside of HPC / science use cases. And for this use case, it makes perfect sense!

AVX512 is used in VFX for rendering, as well as in tensorflow ?

Yes, the instruction set is quite commonly supported, but knights landing was a hole different beast. The main focus of KL was to maximize AVX512 throughput for use in scientific workloads, but the processor ended up being a business failure.

Re: DreamWorks releases OpenMoonRay source code

#134

Post by Pet_Ant »

mhh__ wrote: post #99
ace2358 wrote: post #65

Earlier quoted context omitted.

Is that sort of code able to ‘just run’ on their arc series of GPUs? It feels like intel kinda hates AVX512 on the cpu side (or wants to upsell you for it) so I’m wondering if they turned those cards into their GPUs

Probably not. Even if the code was entirely reliant on the compiler performing vectorization (i.e. GPU & CPU instruction sets are at very the least nominally very different), GPU programming is quite different even to "lots of little CPUs"-style.

> “lots of little CPUS”-style

Known as “manycore”: https://en.m.wikipedia.org/wiki/Manycore_processor

Re: DreamWorks releases OpenMoonRay source code

#135

Post by _flux »

ur-whale wrote: post #106
boppo1 wrote: post #98

Earlier quoted context omitted.

Can you elaborate on what's not good about eevee/cycles shaders? By proper integration do you imagine it will use Blender's node shader system or a different system? I'm not being combative, I'm in the process of learning enough of Blender's code to be able to contribute.

I could write a book about this, but to make it short, what most users of a 3D system like Blender want when they get to the shading/rendering part of their work is to simply: - pick an object in the scene - pick a pre-made rich and complicated shader (wood, glass, tar, etc...) from a huge library of shaders expressed in a standard form (as in: that will work with whichever render, be it cycles, luxrender, moonray, e…

I've used Blender only a little, but surely you're aware of the Asset Browser introduced in the 3.0? They seem easy enough to use, but of course they'd need to be high-quality to work similarly with all renderers.

Granted I don't actually know where to find such libraries except for the small free asset bundles at https://www.blender.org/download/demo-files/#assets or perhaps by paying Blender organization for them, so maybe this doesn't really address your core point :).

Re: DreamWorks releases OpenMoonRay source code

#136

Post by Tunabrain »

ykl wrote: post #105
daniel-thompson wrote: post #72

Surprised nobody has mentioned this, but it looks like it implements the render kernels in ISPC^, which is a tool that exposes a CUDA-like SPMD model that runs over the vector lanes in the CPU. ISPC is also used by Disney's Hyperion renderer, see https://www.researchgate.net/publication/326662420_The_Desig... Neat! ^ https://ispc.github.io/

Hyperion does not use ISPC. Source: I am one of the Hyperion developers.

Oh wow, I bump into you everywhere!

Re: DreamWorks releases OpenMoonRay source code

#137

Post by prox »

NateEag wrote: post #88
satvikpendem wrote: post #83

Earlier quoted context omitted.

Did you watch in IMAX 3D? I watched in both 3D and 2D and the 2D simply cannot compare to the 3D. The way most 3D movies work is the 3D effects are done after the fact in post-production. 3D in Avatar movies are done entirely in the shooting phase, through 3D cameras. Hence, the 3D in Avatar films is much more immersive to me than in something like Dr Strange 2, which simply could not compare.

I remember watching Avatar in 3D and being blown away (both by the dreadful screenwriting and by the amazing 3D effect). It taught me that the key you immersive 3D is to treat the screen as a window. Things have depth beyond it, but never protrude out of it. I noticed only two shots in the movie where anything protruded from the screen towards me, and they really caught my attention.

I try to find 3d movies but so few are of them are made. And like you say, most of them are automated billboard extractions rather than actual 2 cameras.

Re: DreamWorks releases OpenMoonRay source code

#138

Post by xmcqdpt2 »

daniel-thompson wrote: post #101
xmcqdpt2 wrote: post #81

Earlier quoted context omitted.

Neat! Vectorization is the best part of writing Fortran. This looks like it makes it possible to write fortran-like code in C. I wonder how it compares to ifort / openMP?

OpenMP starts with a serial model, the programmer tags the loop they want to run in parallel with a directive, and the compiler tries to vectorize the loop. This can always fail, since it relies on a computer program reasoning about an arbitrary block of code. So you have to really dig into the SIMD directives and understand their limitations in order to write performant code that actually does get vectorized. ISPC s…

Specifically I meant OMP workshare which parallelizes vector operations in Fortran,

https://www.openmp.org/spec-html/5.0/openmpsu39.html

sorry should have been more specific.

Re: DreamWorks releases OpenMoonRay source code

#139

Post by kranke155 »

polishdude20 wrote: post #112
kranke155 wrote: post #96

Earlier quoted context omitted.

Fundamentally yes. Big Studios are CPU Farms. Small Studios and Indie Artists like myself a Lot of us have moved to GPU.

Is that because work is usually divided by frame? And usually a frame for these big movies uses more than typical GPU VRAM?

The work is always divided per frame yes. Everything is baked so that happens easily even with water simulations, they’ve been reduced down to some form of geometry or something similar that can be rendered frame by frame.

The VRAM is indeed one of the main issues. But as someone else I believe cost per final pixel is still lower in CPU. That was particularly true during the GPU shortage.

Re: DreamWorks releases OpenMoonRay source code

#140

Post by brookst »

aseipp wrote: post #84
bhouston wrote: post #56

Earlier quoted context omitted.

So we just need GPUs with 128GB of ram then? Or move towards the Apple M-series design where CPU+GPU both have insanely fast access to all ram...

GPUs need RAM that can handle a lot of bandwidth, so that all of the execution units can remain constantly fed. For bandwidth, there is both a width and a rate of transfer (often bounded by the clock speed) which combined yield the overall bandwidth, i.e. a 384-bit bus at XXXX million transfers/second. It will never matter how much compute or RAM they have if these don't align and you can't feed the cores. Modern des…

Fantastic comment, thanks k you!

Do you think there’s any hope for UMA on PC / x86 systems? Seems like Intel would have an incentive to offer parts, but would it be possible to remain Windows/legacy OS compatible with a UMA implementation?

Post reply on HN