Ray Tracing is the Future and ever will be

Must read and other references.
toxie
Posts: 118
Joined: Mon Nov 28, 2011 12:30 pm
Location: germany
Contact:

Ray Tracing is the Future and ever will be

Postby toxie » Mon Jul 29, 2013 11:30 am

all stuff from siggraph is online by now:

https://sites.google.com/site/raytracingcourse/home
Better you leave here with your head still full of kitty cats and puppy dogs.

Lo1
Posts: 9
Joined: Fri Jul 26, 2013 12:24 pm

Re: Ray Tracing is the Future and ever will be

Postby Lo1 » Tue Jul 30, 2013 6:46 am

Thank you, just in time for me :-)

Dade
Posts: 206
Joined: Fri Dec 02, 2011 8:00 am

Re: Ray Tracing is the Future and ever will be

Postby Dade » Tue Jul 30, 2013 1:08 pm



Very interesting reading, it is just my impression or NVIDIA has done 180 turn: wasn't Optix kernel written has a single huge kernel before ? Not that I don't agree with the content of the presentation, I have written Path tracing kernels (mostly) in the same way for years.

Second question: doesn't the variable length of work queues they are using imply Dynamic Parallelism (as introduced by Kepler GPUs and recently in OpenCL 2.0) ? I use a fixed amount of work produced as workaround to this problem (i.e. I produce always only a single ray to trace at each step instead of a variable number).

spectral
Posts: 382
Joined: Wed Nov 30, 2011 2:27 pm
Contact:

Re: Ray Tracing is the Future and ever will be

Postby spectral » Tue Jul 30, 2013 2:50 pm

I don't see it as a real change...

OptiX is not written as a big kernel... as far as I remember it contains some kind of stack that allow to cut the whole logic in several parts... even if it is "hided" to the developer.

In my sense, this new paper is a logical continuation to previous works...

1) They request to minimize (not too much !!) the kernels to avoid spilling, too much instructions caching ...
2) they provide a generic mechanism for all kind of operations, and also provide a way to keep coalescent accesses
3) instead of using sorting/scan/... they use a queue (fixed size), they use a __ballot instruction... that looks easy to implement even in OpenCL

I really like their job, it is simple, efficient and looks promising !

With this, it seems to have a nice architecture to extend to out-of-core and other kind of algorithms...

I just would like to try it in practice by myself ;-) and also on other kind of architecture (Will CPU suffer of such processing, and on ATI ?)
Spectral
OMPF 2 global moderator

graphicsMan
Posts: 151
Joined: Mon Nov 28, 2011 7:28 pm

Re: Ray Tracing is the Future and ever will be

Postby graphicsMan » Tue Jul 30, 2013 5:46 pm

Dade wrote:


Very interesting reading, it is just my impression or NVIDIA has done 180 turn: wasn't Optix kernel written has a single huge kernel before ? Not that I don't agree with the content of the presentation, I have written Path tracing kernels (mostly) in the same way for years.

Second question: doesn't the variable length of work queues they are using imply Dynamic Parallelism (as introduced by Kepler GPUs and recently in OpenCL 2.0) ? I use a fixed amount of work produced as workaround to this problem (i.e. I produce always only a single ray to trace at each step instead of a variable number).


I think that Optix does compile into a huge kernel, but my info could be out of date.

Also, you would think Dynamic Parallelism would be useful here, but apparently it's quite expensive in the Kepler arch. These guys make their queue information available to the CPU and the CPU launches kernels. Apparently this is slightly faster than launching via Dynamic Parallelism.

papaboo
Posts: 36
Joined: Fri Jun 21, 2013 10:02 am
Contact:

Re: Ray Tracing is the Future and ever will be

Postby papaboo » Tue Aug 06, 2013 8:12 am

I was doing some quick profiling of Optix 3.0 last friday and it does indeed seem to compile into a mega kernel, since all I could find where calls to trace_1. However, I'm currently only compiling for devices of compute capability 1.0 and on such old devices it makes sense to generate a giant kernel, since the performance gains by sorting by ray or material would be completely lost in the overhead of doing the actual sorting, launching kernels and fetching/storing data between kernel launches.
On newer devices, 2.X and upwards, it makes sense to actually break it down into smaller kernels to achieve better thread coherence by sorting based on materials and to keep the register count low. I would assume/hope that NVidia does that when compiling for newer architectures, as that should be perfectly doable with the way they've structured Optix.

friedlinguini
Posts: 79
Joined: Thu Apr 11, 2013 5:15 pm

Re: Ray Tracing is the Future and ever will be

Postby friedlinguini » Wed Aug 07, 2013 1:12 am

papaboo wrote:I was doing some quick profiling of Optix 3.0 last friday and it does indeed seem to compile into a mega kernel, since all I could find where calls to trace_1. However, I'm currently only compiling for devices of compute capability 1.0 and on such old devices it makes sense to generate a giant kernel, since the performance gains by sorting by ray or material would be completely lost in the overhead of doing the actual sorting, launching kernels and fetching/storing data between kernel launches.
On newer devices, 2.X and upwards, it makes sense to actually break it down into smaller kernels to achieve better thread coherence by sorting based on materials and to keep the register count low. I would assume/hope that NVidia does that when compiling for newer architectures, as that should be perfectly doable with the way they've structured Optix.


In one presentation at SIGGRAPH (http://on-demand.gputechconf.com/siggra ... -OptiX.pdf), NVIDIA implies that there is an upcoming version that might address this. One slide for enhancements in a future version of Optix cites performance enhancements in "ray tracing kernels [Aila and Laine 2009; Aila et al. 2012]". 2009 presumably refers to "Understanding the Efficiency of Ray Traversal on GPUs", but 2012 is unclear, since Timo Aila's home page only cites one paper in 2012, "Reconstructing the Indirect Light Field for Global Illumination", which doesn't really have anything to do with kernels. Since he's also one of three authors of "Megakernels Considered Harmful", there is room for hope.

Disclaimer: I work for NVIDIA, but not on Optix, so I have no relevant inside knowledge here.

Dade
Posts: 206
Joined: Fri Dec 02, 2011 8:00 am

Re: Ray Tracing is the Future and ever will be

Postby Dade » Wed Aug 07, 2013 4:11 am

friedlinguini wrote:In one presentation at SIGGRAPH (http://on-demand.gputechconf.com/siggra ... -OptiX.pdf), NVIDIA implies that there is an upcoming version that might address this. One slide for enhancements in a future version of Optix cites performance enhancements in "ray tracing kernels [Aila and Laine 2009; Aila et al. 2012]".


I bet OptiX is going to use this kind of "micro-kernel" solution. May be, it is just not yet available in the released version.

I'm still a bit worried of the overhead of the CPU <=> GPU round trip and atomics but it is such an elegant and clean solution, it must work well.

McAce
Posts: 7
Joined: Fri Feb 22, 2013 6:28 am

Re: Ray Tracing is the Future and ever will be

Postby McAce » Wed Aug 07, 2013 8:55 am

friedlinguini wrote:2009 presumably refers to "Understanding the Efficiency of Ray Traversal on GPUs", but 2012 is unclear, since Timo Aila's home page only cites one paper in 2012 ...


Scroll down to Technical Reports; it refers to Understanding the Efficiency of Ray Traversal on GPUs -- Kepler and Fermi Addendum: https://mediatech.aalto.fi/~timo/publications/aila2012hpg_techrep.pdf

dbz
Posts: 46
Joined: Wed Jan 11, 2012 10:16 pm
Location: the Netherlands

Re: Ray Tracing is the Future and ever will be

Postby dbz » Wed Aug 07, 2013 12:18 pm

friedlinguini wrote:In one presentation at SIGGRAPH (http://on-demand.gputechconf.com/siggra ... -OptiX.pdf), NVIDIA implies that there is an upcoming version that might address this.

Slide 5 from that presentation called 'Real Time Path Tracing' is interesting. It mentions a 35x speedup over a GTX 680 is needed before path tracing can be done in real time. With gpu speed increasing by say 50% each generation of 1.5 years, it would take about 13 years before path tracing can be done in real time on a gpu. However, that ignores increases in screen resolution(4K screens in the near future, maybe 16K screens at that time) and in scene complexity.


Return to “Links & Papers”

Who is online

Users browsing this forum: No registered users and 2 guests