Random GPU progress pic thread

[Zom-B]

Making sure instances work:

Seems they do work pretty fine ^^

[pixie]

Making sure instances work:

I think I spot one missing!

[Stinkie]

Looks like it works. Cool stuff.

Will Indigo 4 have some sort of out of core magic to circumvent gpu ram limitations?

[lycium]

OpenCL 2.0 supports virtual memory, which would make CPU/GPU memory seamless and in theory support out of core rendering.

Of course, it's not quite that simple, because in a path tracer like Indigo rays can bounce all over the place and touch potentially the whole scene's memory, meaning very slow rendering if it's constantly shuttling data to the GPU from CPU memory (like when you play a 3D game with the texture res set too high). However, we have plans to handle these situations too in Indigo, stuff like texture mipmapping and so on that other film / production renderers use.

[Stinkie]

Cool.

[vasco]

OpenCL 2.0 supports virtual memory, which would make CPU/GPU memory seamless and in theory support out of core rendering.

Of course, it's not quite that simple, because in a path tracer like Indigo rays can bounce all over the place and touch potentially the whole scene's memory, meaning very slow rendering if it's constantly shuttling data to the GPU from CPU memory (like when you play a 3D game with the texture res set too high). However, we have plans to handle these situations too in Indigo, stuff like texture mipmapping and so on that other film / production renderers use.

I think this is quite important, especially for HDRI lighting, because the .exr files are eating a lot vram. Would be great when HDRIs could be stored in the CPU memory.

[davide445]

Apart bad drivers and need to split kernels, there are other reasons why OpenCL 1.2 it's so hard to develop on something big such as Indigo?
We can expect easier development cycles and maybe a further speedup under 2.0 or 2.1?

[lycium]

Most of Indigo's GPU rendering code is now written using Winter (aka ISL), so actually a lot of this doesn't even affect us.

About storing HDRI in CPU memory, that simply won't be possible because the memory is used all the time, and crossing that bus between CPU and GPU is extremely, extremely slow: even a single access to local GPU can hide a ton of computation, and CPU memory is basically on the other side of the universe. We just have to focus on saving memory where possible on the GPU.

On the plus side, with HBM coming up it looks like 16-32GB on a GPU will become feasible, which should be enough to cache a huge amount of total scene data.

[davide445]

Never heard of Winter, any link for explanation?

[Headroom]

At the very end of this blog entry from April 2015 there is a little reference to Winter in respect to ISL ( Indigo Shader Language).

However, you'd have to go to the last couple of slides in the linked PDF to find that in the hiding the Glare Team is working on a general purpose, possibly open source programing language that would utilize the GPU.

http://www.indigorenderer.com/node/1988

[davide445]

So it's a Glare Tech proprietary high level language that can be compiled into OpenCL kernels, similar to Kronos SPIR-V?
Not a developer view, interested to understand future evolution.

[Headroom]

1. Your guess is as good a mine
2. proprietary != open source.

[davide445]

Interesting, even if I didn't understand how this can decouple from OpenCL intrinsic troubles, but will wait and see.

[lycium]

Yep it's Nick's badass programming language He posts about it now and then on his blog: http://www.forwardscattering.org/

I'm not sure how Nick wants to make it available, but I'm sure he will say more when the time comes!

PS. It's also what's powering the GPU rendering in the forthcoming Chaotica 2 release

[davide445]

From the slides appear to be possible to generate from Winter not only OpenCL but also CUDA code, a good way to keep open both opportunities. But maybe I'm misunderstanding badly.