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

141–150 of 154 posts

Re: DreamWorks releases OpenMoonRay source code

#141

Post by bluedino »

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…

Thoughts on HBM that Intel has been touting?

Re: DreamWorks releases OpenMoonRay source code

#142

Post by dahart »

Arelius wrote: post #121
dahart wrote: post #64

Earlier quoted context omitted.

Which Disney films use Unreal for final render? Disney has two separate path tracing renderers that are in active development and aren’t in danger of being replaced by Unreal. https://disneyanimation.com/technology/hyperion/ https://renderman.pixar.com/ These renderers are comparable in use case & audience to MoonRay, which is why I don’t think you’re correct that MoonRay needs external contribution to survive. “Used…

Star Wars Rogue One had used Unreal for final render of a couple of shots. However it was more a proof-of-concept then a better worflow or anything. Edit: I worked on this, Adding reference video from GDC https://youtu.be/pnigQTOig8k?t=510

Hey that’s pretty cool! Thanks for the link, it’s helpful to see the shots in question. Am I understanding correctly that the K droid was rendered from behind using Unreal in those shots, and the front shots were rendered with the in-house renderer? If true, I’d love to hear what the reasons were for not being able to use it on all the shots in the sequence. Are there more recent examples? Is Unreal still being tested like this at ILM, or is the focus on the in-house real time renderer?

BTW I’m hugely in favor of pushing real-time rendering for film (and I work on high performance rendering tech, aiming squarely at film + real-time!) I only was disputing the broad characterization by @Someone1234 that Unreal is widely used today for final, and that film studio path tracers are in imminent danger of death by game engine.

Re: DreamWorks releases OpenMoonRay source code

#143

Post by bri3d »

ace2358 wrote: post #65
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!

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

It seems like Dreamworks had to move acceleration to GPU using CUDA and OptiX instead of SIMD/AVX and Embree - the released OpenMoonRay code supports both.

It kind of feels like Dreamworks got burned a little by Intel here - they invested a ton of research effort (alongside Intel) in Embree, SIMD, and Knights' Landing, and then had to add another implementation for OptiX/GPU/SIMT anyway.

Re: DreamWorks releases OpenMoonRay source code

#145

Post by creativenolo »

gabereiser wrote: post #91
greenknight wrote: post #75

Earlier quoted context omitted.

Not just that, I am assuming that there are parts of that code, that will be analysed by the Cycles developers, to enhance Cycles to improve it.

This. Pixar’s Renderman has been an “option” for a while. It was out of band though. The cycles team will look at the theory behind what’s going on in renderers like this and will make the tech work inside cycles. Maybe someone will port this as another render option but really the sauce is their lighting models and parallel vectorization which could improve cycles already abysmally slow render times. Renderman for B…

Abysmally slow compared to? I have been impressed by it

Re: DreamWorks releases OpenMoonRay source code

#146

Post by a_e_k »

bobsomers wrote: post #116
mindcrime wrote: post #86

Is anybody else intrigued by the mention of multi-machine and cloud rendering via the Arras distributed computation framework. ? Is this something new? The code seems to be included as sub-modules of OMR itself, and all the repos[1][2][3] show recent "Initial Commit" messages, so I'm operating on the assumption that it is. If so, I wonder if this is something that might prove useful in other contexts... [1]: https://…

I can maybe add a bit of context to this. I worked on Moonray/Arras at DWA about 8-9 years ago. Arras was designed to let multiple machines work on a single frame in parallel. Film renderers still very much leverage the CPU for a lot of reasons, and letting a render run to completion on a single workstation could take hours. Normally this isn’t a problem for batch rendering, which typically happens overnight, for sho…

Neat! Parallelizing a single frame across multiple machines was something I'd wanted to try back when I was working on RenderMan. It used to be able to do it back in the REYES days via netrender, but was something we lost with the move to pathtracing on the RIS architecture.

Could you go into a bit more detail on how the work is distributed? Is it per tile (or some other screen-space division like macro-tiles or scan-lines)? Per sample pass? (Surely it's not scene distribution like the old Kilauea renderer from Square!) Dynamic or static scheduling? Sorry, so many questions. :-)

Re: DreamWorks releases OpenMoonRay source code

#147

Post by bobsomers »

a_e_k wrote: post #146
bobsomers wrote: post #116

Earlier quoted context omitted.

I can maybe add a bit of context to this. I worked on Moonray/Arras at DWA about 8-9 years ago. Arras was designed to let multiple machines work on a single frame in parallel. Film renderers still very much leverage the CPU for a lot of reasons, and letting a render run to completion on a single workstation could take hours. Normally this isn’t a problem for batch rendering, which typically happens overnight, for sho…

Neat! Parallelizing a single frame across multiple machines was something I'd wanted to try back when I was working on RenderMan. It used to be able to do it back in the REYES days via netrender, but was something we lost with the move to pathtracing on the RIS architecture. Could you go into a bit more detail on how the work is distributed? Is it per tile (or some other screen-space division like macro-tiles or scan…

My knowledge is probably outdated at this point (the now open source code is probably a better reference than my memory!) but at the time it was exactly as you described. Each workstation loaded the scene independently and work was distributed in screen space tiles and final assembly of the tiles was done on the client. I can’t remember if we implemented a work stealing queue to load balance the tile queue or not… my brain may be inventing details on that part. :)

I built a scene distribution renderer similar to Kilauea for my masters thesis in school, except with a feed forward shader design which exploited the linear color space to never send the results of computations back up the call stack… kind of neat but yeah, all sorts of reasons why that kind of design would not work well under production workloads. And RAM has gotten so stinking cheap!

Re: DreamWorks releases OpenMoonRay source code

#148

Post by naikrovek »

CyberDildonics wrote: post #114
naikrovek wrote: post #76

Earlier quoted context omitted.

yes, unreal is used in movies and TV shows, both. usually not entire movies or shows, but lots of individual scenes.

Why are you saying 'yes' then saying the exact opposite of what they said? Unreal is not used for final shots in film.

it has been, I just don't know of any films which have used it in the last year or so.

Re: DreamWorks releases OpenMoonRay source code

#149

Post by CyberDildonics »

naikrovek wrote: post #148
CyberDildonics wrote: post #114

Earlier quoted context omitted.

Why are you saying 'yes' then saying the exact opposite of what they said? Unreal is not used for final shots in film.

it has been, I just don't know of any films which have used it in the last year or so.

Who is talking about the last year? What films used direct unreal output for final frames at all?
Post reply on HN