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

John Carmack's Comment on Hardware Ray Tracing

arstechnica.com

Post reply on HN
Print view View original

21–30 of 69 posts

Re: John Carmack's Comment on Hardware Ray Tracing

#21

Post by InclinedPlane »

chii wrote: post #5

Having no real knowledge of ray tracing (or rendering for that matter), can someone tell me why we can't be moving towards a massive cluster of gpu (in the order of 10,000) ray tracing a scene in parellel? I imagine each ray trace call is quite independent of any other. SOooner or later, cpu (and gpu) will have many cores available for such form of rendering. Is it because of the chicken/egg problem?

This is indeed ray tracing's huge advantage, of being highly amenable to parallelization. However, the same thing is more or less equivalently true for other rendering methods, such as rasterization. Modern GPUs have thousands of rendering sub-unit "cores". And with CUDA you can use those cores for almost anything, including ray tracing. But for a given scene and a given amount of finite computing power you're almost always going to be able to get superior results using a rasterization technique than ray tracing.

Re: John Carmack's Comment on Hardware Ray Tracing

#22

Post by InclinedPlane »

yk wrote: post #13
electrograv wrote: post #3

Excellent response by Carmack. "Ray Tracing" has always been an overhyped or misunderstood technology, at least in my experience. Because of the impressive lighting effects it's famous for producing, people view it as some "holy grail" of superior computer graphics technology that we just need to optimize a bit for use in games. As Carmack described, those highly realistic ray traced renders come at a price: billions…

I think people rather think of ray-tracing as much better motivated by physics ( and intuition) compared to all the complicated matrices in raster engines. Instead of thinking it is superior because of some demos.

An even more physics based rendering method is called radiosity, but it's also hugely computationally intensive.

Re: John Carmack's Comment on Hardware Ray Tracing

#23

Post by yk »

Osmium wrote: post #17
yk wrote: post #15

Earlier quoted context omitted.

Throwing more ( or finer etched) silicon at an algorithm will not help the algorithm, compared to a superior algorithm. For almost all scenes you get better results with rasterization, the two exceptions I can think of is scenes where the geometry of light rays is not flat, so for example involving lenses or black holes, or where there is a lot more optical complexity than you can reasonably use. ( A forest where eac…

e.g. mirrors?

Yes, but it perhaps more instructive to think of a curved mirror. In case of a raster engine, you need to calculate a texture for every triangle of the mirror. ( Which is essentially the same as rendering the scene in the first place.) On the other hand for a ray tracing engine you just need to reflect one ray on the mirror surface for every pixel the mirror occupies in the final rendering. So compared to the same scene with a window instead of the mirror, you just need to calculate one additional reflection instead of running the entire rendering pipeline again.

Re: John Carmack's Comment on Hardware Ray Tracing

#24

Post by damian2000 »

enneff wrote: post #6
damian2000 wrote: post #4

Earlier quoted context omitted.

He might be high up now, but he started off as a programmer. He co-founded id software and (along with others) developed Wolfenstein 3D, Doom, etc. http://en.wikipedia.org/wiki/Id_Software

He still is a programmer. He's the lead programmer at id and writes code for Armadillo Aerospace.

yeah, he can probably do whatever he wants, the fact he's still programming means he obviously enjoys it.

Re: John Carmack's Comment on Hardware Ray Tracing

#25

Post by willvarfar »

yk wrote: post #23
Osmium wrote: post #17

Earlier quoted context omitted.

e.g. mirrors?

Yes, but it perhaps more instructive to think of a curved mirror. In case of a raster engine, you need to calculate a texture for every triangle of the mirror. ( Which is essentially the same as rendering the scene in the first place.) On the other hand for a ray tracing engine you just need to reflect one ray on the mirror surface for every pixel the mirror occupies in the final rendering. So compared to the same sc…

I think John says not just one ray per pixel?

Re: John Carmack's Comment on Hardware Ray Tracing

#26

Post by damian2000 »

james4k wrote: post #16
hayksaakian wrote: post #2

Its so cool that someone as high up in the games industry as carmack actually knows his technical shit.

He's known for knowing his shit. :)

another example ...

"I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that?"

http://superuser.com/questions/419070/transatlantic-ping-fas...

Re: John Carmack's Comment on Hardware Ray Tracing

#27

Post by yk »

InclinedPlane wrote: post #21
chii wrote: post #5

Having no real knowledge of ray tracing (or rendering for that matter), can someone tell me why we can't be moving towards a massive cluster of gpu (in the order of 10,000) ray tracing a scene in parellel? I imagine each ray trace call is quite independent of any other. SOooner or later, cpu (and gpu) will have many cores available for such form of rendering. Is it because of the chicken/egg problem?

This is indeed ray tracing's huge advantage, of being highly amenable to parallelization. However, the same thing is more or less equivalently true for other rendering methods, such as rasterization. Modern GPUs have thousands of rendering sub-unit "cores". And with CUDA you can use those cores for almost anything, including ray tracing. But for a given scene and a given amount of finite computing power you're almost…

I think that rasterization is easier to parallelize than ray tracing, since raster engines essentially multiply each vertex with the same matrix, while for ray tracing you have to traverse an octtree for each step in each ray. ( Both are of course easy to parallelize, I just think that in general you will run into memory bandwidth problems faster with ray tracing algos.)

Re: John Carmack's Comment on Hardware Ray Tracing

#28

Post by ianb »

"For example, all surfaces that are shaded with interpolated normal will have an unnatural shadow discontinuity at the silhouette edges with single shadow ray traces."

For some reason I really want to understand what this sentence means. I don't know why it jumped out at me, maybe because it seems both accessible and arcane, I want some path to even just tour the arcane concerns of someone so deep into a (this) particular domain.

Re: John Carmack's Comment on Hardware Ray Tracing

#29

Post by gsg »

cmccabe wrote: post #14
zxcdw wrote: post #9

Earlier quoted context omitted.

AMD's vision of "heterogenous computing"(I think they came up with a new name for this?) would essentually be the "true" fusion of a CPU and a GPU in a sense that the chip consists of general purpose execution units(current CPU cores) and of special purpose parallel processing units (curent GPU SIMD/VLIW units) which operate concurrently in such sense that both sequential and parallel code can be executed efficiently…

Rasterization also requires "acceleration structures," kept in memory. I could be wrong here, but I think the point John was trying to make was that there was again a constant factor handicapping ray-tracing. But constant factors are, well, constant, and in 2050 we may well have ray-tracing done in hardware delivering scenes that are indistinguishable from reality. I wrote a ray tracer once, but it was primitive. So…

Rasterisation doesn't require any real acceleration structures. There are various caches, but nothing comparable to a kd-tree or BVH.

Re: John Carmack's Comment on Hardware Ray Tracing

#30

Post by dualogy »

cmccabe wrote: post #14
zxcdw wrote: post #9

Earlier quoted context omitted.

AMD's vision of "heterogenous computing"(I think they came up with a new name for this?) would essentually be the "true" fusion of a CPU and a GPU in a sense that the chip consists of general purpose execution units(current CPU cores) and of special purpose parallel processing units (curent GPU SIMD/VLIW units) which operate concurrently in such sense that both sequential and parallel code can be executed efficiently…

Rasterization also requires "acceleration structures," kept in memory. I could be wrong here, but I think the point John was trying to make was that there was again a constant factor handicapping ray-tracing. But constant factors are, well, constant, and in 2050 we may well have ray-tracing done in hardware delivering scenes that are indistinguishable from reality. I wrote a ray tracer once, but it was primitive. So…

> Rasterization also requires "acceleration structures," kept in memory

Yeah but surely not for the geometry itself. In rasterization, we may use simple low-overhead acc. structures to efficiently traverse a relevant sub-set of the whole (but coarsely described) scene for some fancy culling, collision detection (OK that's not really rendering) ... but geometry (vertices, polygons, vertex attributes) does not need to be traversed like that and thus does not have to be stored as individual triangles in an octree or bounding-volume hierarchy or what not. Quite a difference in overheads here. In GPU terms, with rasterization you have geometry neatly stored in vertex buffers and an awesome Z-aware traversal method with vertex shaders. In a simplistic current-gen fragment-shader-based raytracer, each pixel traces a ray traversing through your acceleration structure which may be stored in a volume texture (ouch, so many texel fetches...) since vertex buffers are not sensibly accessible in a frag shader.

> scenes that are indistinguishable from reality

This would also require a high dynamic range output device. Looking directly into perfectly raytraced sunlight still won't glare and blind me like the real world does, but indeed, by 2050...

Post reply on HN