Seems they do work pretty fine ^^OnoSendai wrote:Making sure instances work:
Random GPU progress pic thread
Re: Random GPU progress pic thread
polygonmanufaktur.de
- pixie
- Posts: 2332
- Joined: Sat Dec 29, 2007 4:54 am
- Location: Away from paradise
- 3D Software: Cinema 4D
- Contact:
Re: Random GPU progress pic thread
I think I spot one missing!OnoSendai wrote:Making sure instances work:
Re: Random GPU progress pic thread
Looks like it works. Cool stuff.
Will Indigo 4 have some sort of out of core magic to circumvent gpu ram limitations?
Will Indigo 4 have some sort of out of core magic to circumvent gpu ram limitations?
Re: Random GPU progress pic thread
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.
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.
Re: Random GPU progress pic thread
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.lycium wrote: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.
Intel Pentium 4, 512MB Ram, Nvidia Riva TNT2 Ultra
Instagram: gorilla_studio_coco
Instagram: gorilla_studio_coco
Re: Random GPU progress pic thread
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?
We can expect easier development cycles and maybe a further speedup under 2.0 or 2.1?
Re: Random GPU progress pic thread
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.
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.
Re: Random GPU progress pic thread
Never heard of Winter, any link for explanation?
Re: Random GPU progress pic thread
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
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
Re: Random GPU progress pic thread
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.
Not a developer view, interested to understand future evolution.
Re: Random GPU progress pic thread
1. Your guess is as good a mine
2. proprietary != open source.
2. proprietary != open source.
Re: Random GPU progress pic thread
Interesting, even if I didn't understand how this can decouple from OpenCL intrinsic troubles, but will wait and see.
Re: Random GPU progress pic thread
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
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
Re: Random GPU progress pic thread
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.
Who is online
Users browsing this forum: No registered users and 31 guests