Slashdot Mirror

← Back to Stories (view on slashdot.org)

Carmack On 'Infinite Detail,' Integrated GPUs, and Future Gaming Tech

Posted by Soulskill on from the building-a-better-virtual-rocket-launcher dept.

Vigile writes "John Carmack sat down for an interview during Quakecon 2011 to talk about the future of technology for gaming. He shared his thoughts on the GPU hardware race (hardware doesn't matter but drivers are really important), integrated graphics solutions on Sandy Bridge and Llano (with a future of shared address spaces they may outperform discrete GPUs) and of course some thoughts on 'infinite detail' engines (uninspired content viewed at the molecular level is still uninspired content). Carmack does mention a new-found interest in ray tracing, and how it will 'eventually win' the battle for rendering in the long run."

20 of 149 comments (clear)

  1. Does carmack still check slashdot? by walshy007 · · Score: 2

    Years ago he posted here on occasion and I even remember seeing small active discussions on rendering technique technical points etc.

    It has been ages since I've last seen this, which makes me ponder if he even reads slashdot these days when topics related to him are posted.

    1. Re:Does carmack still check slashdot? by Stradenko · · Score: 4, Funny

      Yeah, anyone still around here is obviously a real loser.

    2. Re:Does carmack still check slashdot? by drsquare · · Score: 2

      Doubt he'd bother coming, Slashdot barely has a games section anymore. Unless you want to read about Apple and Google over and over again, every day, there's not much point in visiting.

  2. Ray Tracing != Ray Casting by Suiggy · · Score: 5, Informative

    It should be noted that John Carmack believes that Ray Casting, not Ray Tracing, will win out in the long term.

    Unfortunately, many people outside of the graphics field confuse the two. Ray Casting is a subset of Ray Tracing in which only a single sample is taken per pixel, or in other words, in which a single ray is cast per pixel into the scene and a single intersection is taken with the geometry data set (or in the case of a translucent surface, the ray my be propagated in the same direction a finite number of times until an opaque surface is found). No recursive bouncing of rays is done. Lighting is handled through another means, such as with traditional forward shading against a dataset of light sources, or using a separate deferred shading pass to un-hinge the combinatorial explosion of overhead caused by scaling up the number of lights in a scene.

    John Carmack has been quoted on saying that full-blown ray-tracing just isn't feasible for real-time graphics due to the poor memory access patterns involved, as casting multiple rays per pixel, with multiple recursive steps ends up touching a lot of memory in your geometry data set, which just thrashes the cache on CPU and modern/future GPU hardware alike.

    When people talk about real-time ray-tracing, they almost always invariably are referring to real-time ray-casting.

    1. Re:Ray Tracing != Ray Casting by QuasiSteve · · Score: 2

      When people talk about real-time ray-tracing, they almost always invariably are referring to real-time ray-casting.

      Developers of dozens of realtime raytracers are lining up to disagree with you.
      e.g. VRay RT, Octane, etc.
      http://www.youtube.com/watch?v=6QNyI_ZMZjI

      Raytracing is extremely straight-forward and parallel. The only thing you have to do to make it feasible for use in games is either A. throw more power at it, B. cheat where you can, C. combination of A&B.

      Not to mention companies that make dedicated hardware, almost invariably treating raytracing less as a raycasting problem and more as data access problem.

    2. Re:Ray Tracing != Ray Casting by Suiggy · · Score: 2

      Yes, you do lose out on reflectivity, so you have to handle reflections through other means. If you use deferred shading, you can handle it in a separate reflective lighting pass in combination with something like cube-mapping. Even though you do a second pass to handle it, it'll still end up being faster than had you tried to implement fully recursive ray-tracing.

      Ray-casting would still have the benefit in providing better scalability than polygonal rasterization as there is a fixed cost per pixel, whereas with polygon rasterization, as you scale up the complexity of the geometry, you increase the computational cost. And that's why Carmack thinks it will eventually win out against rasterization: ray-casting becomes a better use of the available computational resources you have at your disposal once you get past a certain level of detail in your scenes.

    3. Re:Ray Tracing != Ray Casting by Suiggy · · Score: 3, Informative

      The video you posted is not real-time frame rates, it's interactive frame rates. It takes a few seconds to fully recompute the scene once you stop moving the camera. And note how there's only a single car model. imagine scaling up the amount of geometry to a full world. With ray-tracing, as you scale up the complexity of the geometry, you end up scaling up the required computational complexity as well due to radiosity computations. Full real-time ray-tracing on huge worlds in real-time is a pipe-dream. What you will be able to do with ray-casting or rasterization with deferred shading composition to simulate things like reflections or radiosity will always be more than what you can do with ray-tracing, and so games developers will always choose the former.

    4. Re:Ray Tracing != Ray Casting by Suiggy · · Score: 2

      I also forgot to mention that conventional rasterization and ray-casting is also just as parallel in nature as ray-tracing. In fact, more so because it has much better memory access patterns as I mentioned in a previous post. Memory-access is the biggest limiting factor in building scalable, parallel systems. If you don't have good memory-access patterns, you might as well being doing sequential work, because it's getting serialized by the hardware memory controller anyway.

      And this situation isn't improving, it's actually getting worse on each subsequent hardware generation... memory access is increasingly becoming a bigger and bigger bottleneck. I suggest you educate yourself on how memory works on modern cache-coherent hardware.

      https://lwn.net/Articles/250967/

    5. Re:Ray Tracing != Ray Casting by Sycraft-fu · · Score: 3, Insightful

      I think part of the problem is that you get a bunch of CS types who learned how to make a ray tracer in a class (because it is pretty easy and pretty cool) and also learn it is "O(log n)" but don't really understand what that means or what it applies to.

      Yes in theory, a ray tracing engine scales logarithmically with number of polygons. That means that past a point you can do more and more complex geometry without a lot of additional cost. However that forgets a big problem in the real world: Memory access. Memory access isn't free and it turns out to be a big issue for complex scenes in a ray tracer. You have to understand that algorithm speeds can't be taken out of context of a real system. You have to account for system overhead. Sometimes it can me a theoretically less optimal algorithm is better.

      Then there's the problem of shadowing/shading you pointed out. In a pure ray tracer, everything has that unnatural shiny/bright look. This is because you trace rays from the screen back to the light source. Works fine for direct illumination but the real world has lots of indirect illumination that gives the richness of shadows we see. For that you need something else like radiosity or photon mapping, and that has different costs.

      Finally there's the big issue of resolution that ray tracing types like to ignore. Ray tracing doesn't scale well with resolution. It scales O(n) in terms of pixels, and of course pixels grow in a power of two fashion since you increase horizontal and vertical resolution when you get higher PPI. Then if you want anti-aliasing, you have to do multiple rays per pixel. This is why when you see ray tracing demos they love to have all kinds of smooth spheres, but yet run at a low resolution. They can handle the polygons, but ask them to do 1920x1080 with 4xAA and they are fucked.

      Now none of this is to say that ray tracing will be something we never want to use. But it has some real issues that people seem to like to gloss over, issues that are the reason it isn't being used for realtime engines.

    6. Re:Ray Tracing != Ray Casting by Suiggy · · Score: 2

      I admit, I made my post before watching the video. Now that I've watched it, I think my position still holds. He talked a lot about using ray-tracing in content preproduction and preprocessing tools during development, and he talked about building ray-tracing engines in the past to experiment with the performance characteristics. This is the same research he did where he came to the conclusion that ray-casting will be better than ray-tracing. Where his position has changed is in that he used to think it would only be feasible using voxel as your input data set, but he's starting to come around on ray-casting against analytical surfaces... polygonal meshes, curved surfaces, etc. in real time.

    7. Re:Ray Tracing != Ray Casting by NoSig · · Score: 2

      Everything you wrote is mathematically accurate, yet the actually interesting thing is exactly how big N has to get. The mathematics of big-O notation tells you nothing about that, yet that is the crux of the matter. For example, if N has to be bigger than 10^123478234897298, the apparent better asymptotic complexity has no impact on the real world. The point is that if I tell you that one algorithm is O(1) and the other is O(2^n), you haven't actually learned anything useful about which algorithm you should use for your program - you also need to know the point at which one becomes better than the other. But if you know that, you don't have to know the complexity to choose which algorithm will work better for you! So you see, big-O notation can be useful for understanding how your program behaves. It is never by itself (!) useful for deciding between two algorithms at any size of input - it doesn't give you enough information. So don't just tell me the complexities, tell me that one method is better than another at X multiple of current performance.

    8. Re:Ray Tracing != Ray Casting by Suiggy · · Score: 2

      Yeah, not to mention that with full ray-tracing, as you add more lights to a scene, it increases the overall complexity per pixel per ray bounce linearly as well. That's why doing deferred shading is so nice because it unbuckles the lighting from the rasterization or ray-casting/tracing step and lets you scale up the number of lightings independently with a fixed amount of overhead and linear cost per light for the entire scene, instead of per pixel or per ray or per polygon.

      Going with pure ray-tracing doesn't let you take advantage of that.

    9. Re:Ray Tracing != Ray Casting by Creepy · · Score: 2

      I'd hope he is talking about ray tracing - I'm basically doing ray tracing inside of polygons in shaders today, and I'm sure he has, too. I really don't think ray casting has enough advantages over polygons that would make it worth it, and has significant disadvantages that would need to be worked around (no reflections, shadows, etc). Back in the 1980/1990s, programmers used the painter's algorithm instead of zbuffer because it was significantly slower to use zbuffer up to a certain number of polygons, and right as zbuffer was becoming practical consumer hardware became available that used it, killing the painter's algorithm. Ray tracing actually falls into a similar category - as the number of objects in a scene grows, it scales linearly, so at some point it will be cheaper or as cheap to use ray tracing as it is to use polygons. If monitors had stuck with 640x480, we'd easily be there today.

      Not that ray tracing doesn't have issues - it needs access to the entire scene in memory (GPU memory optimally - GPU parallel processing is ideal), creates hard shadows only (without photon mapping or similar - I'd say Radiosity, but I doubt we'll see that full scene in realtime anytime soon - O(n^5) I believe), requires a lot more processing power for larger monitors (640x480 is 307200 rays, 1920x1200 is 2304000 rays or 7.5x more expensive - in contrast, polygons don't increase in cost by monitor size), and displays reflective lighting far better than diffuse.

      All of the problems above are solvable by lots of GPU horsepower and memory - we're not there yet, but in 10 years, who knows?

    10. Re:Ray Tracing != Ray Casting by Daniel+Phillips · · Score: 2

      The thing is that when the critical N is reached, O(P log N) isnt just going to be slightly better, its going to be enormously better from then on out

      Obviously, but many commenters seem to gloss over the fact that polygon rendering can also be reduced to O(N log N) by multi-resolution rendering.techniques.

      --
      Have you got your LWN subscription yet?
    11. Re:Ray Tracing != Ray Casting by smallfries · · Score: 2

      Raytracing is extremely straight-forward and parallel.

      If only.... In the real world that would be an exclusive or, so pick one of the two. On small uncomplicated scenes it is straight-forward to make the tracing of each ray happen in parallel. As you add more geometry though it begins to behave differently. You will need a giant cache of rays to handle all of the bounces otherwise all of the recomputation will kill your performance. This was well known in the graphics community prior to GPUs and the same scaling issues were seen on clusters used in rendering. Working out how to implement that cache so that it scales nicely with the number of nodes is a really difficult data-structures problem.

      Say that you avoid this problem (for now) by only looking at a low number of bounces per ray, and you favour performance over fidelity by only casting a few (or just one) ray per pixel. You certainly don't want an O(n) intersection test with your geometry, and to hit some kind of O(log n) you will need a spatial subdivision tree of some kind. The problem that you will now face is that every ray traverses the tree in a slightly different order. This means that memory locality amongst your cores is a absolute bitch.

      Either replicate *all* of your geometry into huge local memories for each thread (not feasible). Or try and cover the latency with throughput. Of course high-throughput on a GPU depends entirely on memory coalescing (not possible because the access patterns diverge in each thread) and a high arithmetic to access ratio (not really going to happen during tree traversal). Then you have the smaller issues like the SIMD restrictions that mean every thread in a workgroup must execute the same trace, so both sides of branches are run and recursive traversal functions are pig-slow.

      There is some really, really nice work out there. But it is hideously inefficient because the problem does not map onto the architecture. The Sparse Efficient Volumetric work from (siggraph 2 years ago?) shoots about 140Mray/s on a GTX-580. It looks pretty gorgeous, but it expands out all of the geometry into 2.7GB on the card to make the approach a little bit closer to brute-force and spend less time on processing acceleration structures. But that card can hit 800Gflop/s so each ray is still costing 6000 arithmetic instructions (or more likely their equivalent as they are memory bound). They are not computing hundreds of bounces per ray on average, that huge cost is because their arithmetic to access ratio is so bad, and that is a direct result of it being so difficult to parallelise the ray processing.

      Of course dynamic scenes are much, much harder than these minor problems that you get for static scenes...

      --
      Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
  3. You can have both rasterization and ray-casting. by Suiggy · · Score: 2

    The Euclideon infinite detail technology was exposed in a recent interview to be efficient sparse voxel octree ray-casting with contours (instead of axis-aligned cubes), which was previously investigated by nVidia researchers and others.

    http://www.tml.tkk.fi/~samuli/publications/laine2010tr1_paper.pdf

    It's still not quite competitive enough with conventional rasterization techniques if you also try to do decent lighting with it along with all of the other stuff that goes into developing a game. Maybe in couple of more GPU generations. And in the Euclideon demos, you can see they're only getting 15-25 frames per second, and yet they're using a simplistic lighting model with a single global light.

    Also, you can merge polygon rasterization and voxel ray-casting under the same rendering architecture if you employ deferred shading and composition. That way you can have your static models as a voxel-octree that you ray-cast into your geometry-buffer, rasterize your dynamic polygonal models in a second pass into the same geometry-buffer, and then perform your lighting passes with the geometry-buffer as input, and then your final scene composition and post-processing passes. In fact, I bet you that in 5-6 years time, this will become a standard practice among PC game developers. Unfortunately, I think the upcoming next console generation, with hardware from Sony and MS due out next year, will miss out on being able to handle this.

  4. Hey! by toby · · Score: 4, Funny

    Speak for yourself! ;-)

    --
    you had me at #!
  5. Re:Does anyone actually listen to him by ddt · · Score: 2

    There are a lot of reasons people still follow him closely.

    He's really smart, hard-working, and open with his opinions. If something blows, he doesn't sugar coat it out of fear for his relationship with the company whose product he's bagging on.

    He's also fiercely empirical. Moreso than a lot of his competitors, he doesn't buy into his own bullshit. If he has an idea, he makes an experiment to test it, and if it doesn't cut the mustard, he adjusts his view on the subject. He reverses his opinions over time and points out when he's been wrong. You'd think that trait would be common amoungst coders, what being lovers of science and engineering in general, and you'd be wrong.

    He's also open with his source code, and a lot of coders have actually learned how to write games by reading his source for Doom & Quake. In addition to being a fast coder, he writes very clean code with a very crisp style, and that code has been a really positive influence on the next generation of game programmers.

    But if you're looking for Jesus, you need look no further. I was one of the first coders John hired, and if you recall, Jesus is the *son* of God, and like Jesus, I was cast out from Heaven to muck about with mortals and spread the good word. Also, unlike John but more like Jesus, I believe my own bullshit without the need to test it. Crucially, if you look up "gamer" under Google images, I'm on the first page, and you'll see conclusively that I can rock the long Jesus hair. I am also skinny, emaciated, and have been repeatedly crucified. If you choose to become a disciple, I will welcome you with open arms. I just won't respect you.

  6. Re:Does anyone actually listen to him by XanC · · Score: 2

    So how many games will the 'Horns win this year?

  7. Re:Too much dependence on drivers by loufoque · · Score: 2

    Let me make a guess. You don't program do you?

    I write software tools for high-performance computing that work on a variety of hardware, including all variations of x86, POWER, PowerPC and Cell, ARM, GPUs, multi-core, clusters... and other more confidential architectures (many-core, VLIW, FPGA, ASICs...)
    Supporting a lot of different hardware is not an insurmountable problem if you have a good design (and a good test farm).

    Now you may be confusing drivers with game engines but even then you would be wrong just not insane.

    What we call graphics drivers nowadays is not just the code that allows to interact with the hardware. It's an OpenGL and DirectX implementation.
    With the advent of programmable GPUs, this abstraction has become much too high-level. A C compiler is quite a better one.