This was intended to be a confidential "get to know where you're going" Q&A with Intel's VCG. But, after initially agreeing to take a look, they've had the questions without answer to any (of the several) query of ours as to the status since 2/20. As such, we've had to reluctantly accept that they don't care to have a dialogue right now. That's their perogative, of course. However, since they have not bothered to explain any of that to us, and since we have received zero confidential information from them, we feel entitled to post for your edification what it was we asked them. Feel free to add some more questions to it if you think of something we missed and should include should a real opportunity to talk to them occur. Thanks to a couple of our members for their contributions (you know who are if you care to take a bow!)
To Wit:
1. To what degree is current API support (DX10, OGL 2.0) sufficient or insufficient for an optimal use of ray tracing in games development? Is ray tracing "transparent" to the API's in this regard, and only the driver needs to care about the hardware underneath? How far along with standards-owning entities are any additions to current APIs to support ray tracing optimally?
2. How much of an impact on ISVs does a switch to a ray tracing paradigm have? Is it completely transparent? Transparent for current functions, but new paradigms for new functions that weren't practical in a raster-world, or pretty much impacts how they write code for most/all functions in a game? To the degree the impact is significant, what strategies and tools do you foresee to ease this transition?
3. Obviously, the typical ISV is deeply interested in addressing as large a portion of the market as possible. As such, would you foresee a "ray tracing path" and a "rasterization path" thru game code during the transition period?
4. Is ray tracing suitable for discrete AIB solutions (vs CPU-centric multi-core solutions)? Is there any place for AIB solutions in a ray tracing world? If there are practical AIB solutions, does the optimal solution have the same relationship to the CPU (i.e. re resources and distribution of workload) as a rasterization solution’s relationship to the CPU, or is the paradigm different there too?
5. The movie industry has been using scan conversion/rasterization for many years, while ray tracing is mostly being used for particular difficult shots or for subset of a scene given its performance implications. Wouldn't we expect a wholesale conversion to ray tracing in the movie industry to presage a move at the consumer level?
6. Does Intel see ray tracing as an appropriate solution for the entire graphics food chain from IGP to high-end professional? Or is it better suited for some market segments than others?
7. What hardware resources impact the scalability of ray tracing performance? To what degree is this the same or different from the hardware resources to performance scale rasterization solutions? Do you believe ray tracing can be accelerated with fixed-function hardware, very much like rasterization is today? Or do you think full programmability is the way to go there?
8. Some critics seem to think that ray tracing is a fine "add on" to traditional graphics for specific niche problems. We hear things like "sure, for secondary rays (reflections, refraction, indirect illumination, etc.). . . but not for primary rays". Can you help us understand what those critics are missing by suggesting that ray tracing isn't an optimal solution (compared to traditional raster based hw) for primary rays?
9. Is a hybrid solution that optimally accelerates both rasterization (for primary rays) and ray tracing (for secondary rays) a practical and desirable use of silicon? Are the functional units that optimally accelerate each enough alike to make this practical, or so different as to require a significant duplication of silicon to support an efficient hybrid solution?
10. If you believe ray tracing makes sense for primary rays, is the reasoning that in future workloads, that will become a negligible part of the computation power needed, so it doesn't make sense to implement fixed-function rasterization? Obviously, ignore this question depending on your previous answers.
11. For shadows, do you believe ray tracing would "kill off" the use of shadow maps? Or do you think they're still useful because they can be filtered efficiently to give nice pseudo-soft shadows?
12. If you believe shadow maps still make sense in a ray tracing future, any idea what ray tracing would allow there that rasterization doesn't? Logarithmic shadow maps, perhaps?
13. On the subject of ray tracing vs rasterization scaling, one graphics researcher we consulted had this to say: "This is simply untrue... ray tracing scales terribly without an acceleration structure, and with a similar acceleration structure (for LOD and hierarchical occlusion culling), rasterization scales just as well." What would you say in response to such an argument?
14. Some documents we've seen seem to feel that increasing scene complexity, as defined by number of triangles on the screen, is where ray tracing really begins to shine. It is our experience that most people tend to think of "correct" shadowing/illumination as ray tracing's strong point. . . so why would a high number of triangles be the determiner for having a performance advantage vs rasterization?
15. Performant ray tracing implementations need to store geometry data into spatial subdivision structures (octrees, kd-tree, etc). This works well for static geometry, but games can have loads of dynamic geometry. Even something as trivial as skeletal animations can completely change relationships between triangles belonging to the same mesh. How will you efficiently update spatial subdivision structures for these kind of applications? Wouldn't the scaling advantage diminish if the acceleration structures had to be rebuilt?
16. Some GPU-based ray tracers have had pretty good results lately - in fact, some current implementations are already significantly faster than what current CPUs can do. The GPU architecture isn't perfectly suited (branching coherence etc...) but it's a good start. So, going forward and generally speaking, what hardware advantages will Intel products bring to the table for accelerating ray tracing? Larger caches (wouldn't a SPE-like local store help?) and no "branching coherence" problem? What else?
17. What happens to concepts like anisotropic filtering and anti-aliasing in a ray tracing world? Are they still relevant? How do they get addressed? For instance, how would anti-aliasing work with ray tracing? Assuming you're not using LODs, you're going to have micropolygons, for which the traditional answer has been supersampling. Are we missing something there? Will a ray tracing product be able to offer competitive amounts of anti-aliasing image quality with rasterization solutions in the near/mid-term?
18. This is more of a generic architectural question, but it's related to ray tracing. CPUs have traditionally been single-threaded, while GPUs have always had a very high number of threads running at the same time (100s, 1000s, or even more) to hide the latency. Recently, CPUs started going multi-core or multi-threads-per-core (HyperThreading). Do you believe workloads such as ray tracing will benefit from CPUs' more "MIMD-like" architecture, rather than the GPUs' SIMD-like architecture? Do you believe there are enough "semi-parallel" workloads out there, that could benefit from perhaps 16-32 threads but wouldn't be properly scalable to 1000+ threads? Basically, do you think MIMD has a significant and inherent advantage over pseudo-SIMD architectures?
19. Obviously you’re not about to announce any products as part of answering these questions. Even so, is there any high-level general visibility on the timelines you have in mind for productizing these technologies that you can provide us?
To Wit:
1. To what degree is current API support (DX10, OGL 2.0) sufficient or insufficient for an optimal use of ray tracing in games development? Is ray tracing "transparent" to the API's in this regard, and only the driver needs to care about the hardware underneath? How far along with standards-owning entities are any additions to current APIs to support ray tracing optimally?
2. How much of an impact on ISVs does a switch to a ray tracing paradigm have? Is it completely transparent? Transparent for current functions, but new paradigms for new functions that weren't practical in a raster-world, or pretty much impacts how they write code for most/all functions in a game? To the degree the impact is significant, what strategies and tools do you foresee to ease this transition?
3. Obviously, the typical ISV is deeply interested in addressing as large a portion of the market as possible. As such, would you foresee a "ray tracing path" and a "rasterization path" thru game code during the transition period?
4. Is ray tracing suitable for discrete AIB solutions (vs CPU-centric multi-core solutions)? Is there any place for AIB solutions in a ray tracing world? If there are practical AIB solutions, does the optimal solution have the same relationship to the CPU (i.e. re resources and distribution of workload) as a rasterization solution’s relationship to the CPU, or is the paradigm different there too?
5. The movie industry has been using scan conversion/rasterization for many years, while ray tracing is mostly being used for particular difficult shots or for subset of a scene given its performance implications. Wouldn't we expect a wholesale conversion to ray tracing in the movie industry to presage a move at the consumer level?
6. Does Intel see ray tracing as an appropriate solution for the entire graphics food chain from IGP to high-end professional? Or is it better suited for some market segments than others?
7. What hardware resources impact the scalability of ray tracing performance? To what degree is this the same or different from the hardware resources to performance scale rasterization solutions? Do you believe ray tracing can be accelerated with fixed-function hardware, very much like rasterization is today? Or do you think full programmability is the way to go there?
8. Some critics seem to think that ray tracing is a fine "add on" to traditional graphics for specific niche problems. We hear things like "sure, for secondary rays (reflections, refraction, indirect illumination, etc.). . . but not for primary rays". Can you help us understand what those critics are missing by suggesting that ray tracing isn't an optimal solution (compared to traditional raster based hw) for primary rays?
9. Is a hybrid solution that optimally accelerates both rasterization (for primary rays) and ray tracing (for secondary rays) a practical and desirable use of silicon? Are the functional units that optimally accelerate each enough alike to make this practical, or so different as to require a significant duplication of silicon to support an efficient hybrid solution?
10. If you believe ray tracing makes sense for primary rays, is the reasoning that in future workloads, that will become a negligible part of the computation power needed, so it doesn't make sense to implement fixed-function rasterization? Obviously, ignore this question depending on your previous answers.
11. For shadows, do you believe ray tracing would "kill off" the use of shadow maps? Or do you think they're still useful because they can be filtered efficiently to give nice pseudo-soft shadows?
12. If you believe shadow maps still make sense in a ray tracing future, any idea what ray tracing would allow there that rasterization doesn't? Logarithmic shadow maps, perhaps?
13. On the subject of ray tracing vs rasterization scaling, one graphics researcher we consulted had this to say: "This is simply untrue... ray tracing scales terribly without an acceleration structure, and with a similar acceleration structure (for LOD and hierarchical occlusion culling), rasterization scales just as well." What would you say in response to such an argument?
14. Some documents we've seen seem to feel that increasing scene complexity, as defined by number of triangles on the screen, is where ray tracing really begins to shine. It is our experience that most people tend to think of "correct" shadowing/illumination as ray tracing's strong point. . . so why would a high number of triangles be the determiner for having a performance advantage vs rasterization?
15. Performant ray tracing implementations need to store geometry data into spatial subdivision structures (octrees, kd-tree, etc). This works well for static geometry, but games can have loads of dynamic geometry. Even something as trivial as skeletal animations can completely change relationships between triangles belonging to the same mesh. How will you efficiently update spatial subdivision structures for these kind of applications? Wouldn't the scaling advantage diminish if the acceleration structures had to be rebuilt?
16. Some GPU-based ray tracers have had pretty good results lately - in fact, some current implementations are already significantly faster than what current CPUs can do. The GPU architecture isn't perfectly suited (branching coherence etc...) but it's a good start. So, going forward and generally speaking, what hardware advantages will Intel products bring to the table for accelerating ray tracing? Larger caches (wouldn't a SPE-like local store help?) and no "branching coherence" problem? What else?
17. What happens to concepts like anisotropic filtering and anti-aliasing in a ray tracing world? Are they still relevant? How do they get addressed? For instance, how would anti-aliasing work with ray tracing? Assuming you're not using LODs, you're going to have micropolygons, for which the traditional answer has been supersampling. Are we missing something there? Will a ray tracing product be able to offer competitive amounts of anti-aliasing image quality with rasterization solutions in the near/mid-term?
18. This is more of a generic architectural question, but it's related to ray tracing. CPUs have traditionally been single-threaded, while GPUs have always had a very high number of threads running at the same time (100s, 1000s, or even more) to hide the latency. Recently, CPUs started going multi-core or multi-threads-per-core (HyperThreading). Do you believe workloads such as ray tracing will benefit from CPUs' more "MIMD-like" architecture, rather than the GPUs' SIMD-like architecture? Do you believe there are enough "semi-parallel" workloads out there, that could benefit from perhaps 16-32 threads but wouldn't be properly scalable to 1000+ threads? Basically, do you think MIMD has a significant and inherent advantage over pseudo-SIMD architectures?
19. Obviously you’re not about to announce any products as part of answering these questions. Even so, is there any high-level general visibility on the timelines you have in mind for productizing these technologies that you can provide us?
