Athlon 64 3000+
11-03-2008, 20:14
http://forums.vr-zone.com/showthread.php?t=247624
Interview - In the second part of our interview Tim Sweeney, creator of the Unreal game engine and CEO of Epic Games, discusses the challenges and dramatic changes that are just ahead for game developers and gamers: Graphics rendering may change completely and Microsoft’s DirectX interface may become less important. The successors of the Xbox 360 and Playstation 3, due in 2012, could be running entirely on software pipelines.
The idea of extremely powerful graphics processors being used for general purpose applications is a much debated topic in the games industry as well - and Sweeney believes that the GPU and CPU will be heading into a battle for the dominant position in a computer – and either one could be pushed out of the market.
TG Daily: In the first part of our interview you implied that software rendering might be coming back. Daniel Pohl, who rewrote Quake 3 and Quake 4 using ray-tracing [and is now working as Intel's research scientist] recently showed ray-tracing on a Sony UMPC, an ultraportable device equipped with a single-core processor. True, the resolution was much lower than on PCs of today, but it looked impressive. What are your thoughts on ray-tracing? How will 3D develop in the next months and years?
Sweeney: Ray-tracing is a cool direction for future rendering techniques. Also, there is rendering and there is the ray scheme of dividing the scene into micro-polygons and voxels. There are around five to ten different techniques and they are all very interesting for the next-generation of rendering.
Rendering can be done on the CPU. As soon as we have enough CPU cores and better vector support, these schemes might get more practical for games. And: As GPUs become more general, you will have the possibility of writing a rendering engine that runs directly on the GPU and bypasses DirectX as well as the graphics pipeline. For example, you can write a render in CUDA and run it on Nvidia hardware, bypassing all of their rasterization and everything else.
All a software renderer really does is input some scene data, your position of objects, texture maps and things like that - while the output is just a rectangular grid of pixels. You can use different techniques to generate this grid. You don’t have to use the GPU rasterizer to achieve this goal.
TG Daily: What kind of advantage can be gained from avoiding the API? Most developers just utilize DirectX or OpenGL and that's about it. How does the Unreal Engine differ from the conventional approach?
Sweeney: There are significant advantages in doing it yourself, avoiding all the graphics API calling and overhead. With a direct approach, we can use techniques that require wider frame buffer, things that DirectX just doesn't support. At Epic, we're using the GPU for general computation with pixel shaders. There is a lot we can do there, just by bypassing the graphics pipeline completely.
TG Daily: What is the role of DirectX these days? DirectX 10 and the Vista-everything model promised things like more effects and direct hardware approach, claiming that lots of new built-in technologies would enable a console-like experience. DirectX 10.0 has been on the market for some time and the arrival of DirectX 10.1 is just ahead. What went right, what went wrong?
Sweeney: I don't think anything unusual happened there. DirectX 10 is a fine API. When Vista first shipped, DirectX 10 applications tended to be slower than DirectX 9, but that was to be expected. That was simply the case because the hardware guys were given many years and hundreds of man-years to optimize their DirectX 9 drivers. With DirectX 10, they had to start from scratch. In the past weeks and months, we have seen DX10 drivers catching up to DX9 in terms of performance and they're starting to surpass them.
I think that the roadmap was sound, but DirectX 10 was just a small incremental improvement over DX9. The big news items with DirectX 9 were pixel and vertex shaders: You could write arbitrary code and DX10 just takes that to a new level, offering geometry shaders and numerous features and modes. It doesn't change graphics in any way at all, unlike DX9. That was a giant step ahead of DirectX 7 and DirectX 8.
TG Daily: Since you are a member of Microsoft's advisory board for DirectX, you probably have a good idea what we will see next in DirectX. What can we expect and do you see a potential for a segmentation of APIs - all over again?
Sweeney: I think Microsoft is doing the right thing for the graphics API. There are many developers who always want to program through the API - either through DirectX these days or a software renderer in the past. That will always be the right solution for them. It makes things easier to get stuff being rendered on-screen. If you know your resource allocation, you'll be just fine. But realistically, I think that DirectX 10 is the last DirectX graphics API that is truly relevant to developers. In the future, developers will tend to write their own renderers that will use both the CPU and the GPU - using graphics processor programming language rather than DirectX. I think we're going to get there pretty quickly.
I expect that by the time of the release of the next generation of consoles, around 2012 when Microsoft comes out with the successor of the Xbox 360 and Sony comes out with the successor of the PlayStation 3, games will be running 100% on based software pipelines. Yes, some developers will still use DirectX, but at some point, DirectX just becomes a software library on top of ... you know.
TG Daily: If your vision comes true, it looks like graphics will take the best from the CPU and the GPU, with graphics hardware continuing its evolution from a fixed function pipeline into what are basically arrays of mini-processors that support almost the same data formats as floating point units on the CPU today.
Sweeney: It is hard to say at what point we are going to see graphics hardware being able to understand C++ code. But data will be processed right on the GPU. Then, you are going to get the GPU's computational functionality to a point where you can - not that this is useful, but it will be a very important experiment - recompile the kernel for a GPU and actually run the Linux kernel off the GPU - running entirely by itself. Then, the boundary between the CPU and the GPU will become just a matter of performance trade-offs.
TG Daily: General purpose GPUs competing with CPUs? Do you already have any idea who might win this battle?
Sweeney: Hard to say at this time. Both can run any kind of code, GPUs are just much better optimized for highly parallel vector computing. CPUs are better for authorized out-of-order, branching, and operating system type of things. Once they both have a complete feature-set, things will get very interesting there. We could see the CPU pushing GPUs out of the market entirely, if the integration of highly parallel computing influences future designs. Or, we could see GPU vendors start pushing actual CPUs out of the market: Windows or any other operating system could run directly on a GPU. There are lots of possibilities.
Interview - In the second part of our interview Tim Sweeney, creator of the Unreal game engine and CEO of Epic Games, discusses the challenges and dramatic changes that are just ahead for game developers and gamers: Graphics rendering may change completely and Microsoft’s DirectX interface may become less important. The successors of the Xbox 360 and Playstation 3, due in 2012, could be running entirely on software pipelines.
The idea of extremely powerful graphics processors being used for general purpose applications is a much debated topic in the games industry as well - and Sweeney believes that the GPU and CPU will be heading into a battle for the dominant position in a computer – and either one could be pushed out of the market.
TG Daily: In the first part of our interview you implied that software rendering might be coming back. Daniel Pohl, who rewrote Quake 3 and Quake 4 using ray-tracing [and is now working as Intel's research scientist] recently showed ray-tracing on a Sony UMPC, an ultraportable device equipped with a single-core processor. True, the resolution was much lower than on PCs of today, but it looked impressive. What are your thoughts on ray-tracing? How will 3D develop in the next months and years?
Sweeney: Ray-tracing is a cool direction for future rendering techniques. Also, there is rendering and there is the ray scheme of dividing the scene into micro-polygons and voxels. There are around five to ten different techniques and they are all very interesting for the next-generation of rendering.
Rendering can be done on the CPU. As soon as we have enough CPU cores and better vector support, these schemes might get more practical for games. And: As GPUs become more general, you will have the possibility of writing a rendering engine that runs directly on the GPU and bypasses DirectX as well as the graphics pipeline. For example, you can write a render in CUDA and run it on Nvidia hardware, bypassing all of their rasterization and everything else.
All a software renderer really does is input some scene data, your position of objects, texture maps and things like that - while the output is just a rectangular grid of pixels. You can use different techniques to generate this grid. You don’t have to use the GPU rasterizer to achieve this goal.
TG Daily: What kind of advantage can be gained from avoiding the API? Most developers just utilize DirectX or OpenGL and that's about it. How does the Unreal Engine differ from the conventional approach?
Sweeney: There are significant advantages in doing it yourself, avoiding all the graphics API calling and overhead. With a direct approach, we can use techniques that require wider frame buffer, things that DirectX just doesn't support. At Epic, we're using the GPU for general computation with pixel shaders. There is a lot we can do there, just by bypassing the graphics pipeline completely.
TG Daily: What is the role of DirectX these days? DirectX 10 and the Vista-everything model promised things like more effects and direct hardware approach, claiming that lots of new built-in technologies would enable a console-like experience. DirectX 10.0 has been on the market for some time and the arrival of DirectX 10.1 is just ahead. What went right, what went wrong?
Sweeney: I don't think anything unusual happened there. DirectX 10 is a fine API. When Vista first shipped, DirectX 10 applications tended to be slower than DirectX 9, but that was to be expected. That was simply the case because the hardware guys were given many years and hundreds of man-years to optimize their DirectX 9 drivers. With DirectX 10, they had to start from scratch. In the past weeks and months, we have seen DX10 drivers catching up to DX9 in terms of performance and they're starting to surpass them.
I think that the roadmap was sound, but DirectX 10 was just a small incremental improvement over DX9. The big news items with DirectX 9 were pixel and vertex shaders: You could write arbitrary code and DX10 just takes that to a new level, offering geometry shaders and numerous features and modes. It doesn't change graphics in any way at all, unlike DX9. That was a giant step ahead of DirectX 7 and DirectX 8.
TG Daily: Since you are a member of Microsoft's advisory board for DirectX, you probably have a good idea what we will see next in DirectX. What can we expect and do you see a potential for a segmentation of APIs - all over again?
Sweeney: I think Microsoft is doing the right thing for the graphics API. There are many developers who always want to program through the API - either through DirectX these days or a software renderer in the past. That will always be the right solution for them. It makes things easier to get stuff being rendered on-screen. If you know your resource allocation, you'll be just fine. But realistically, I think that DirectX 10 is the last DirectX graphics API that is truly relevant to developers. In the future, developers will tend to write their own renderers that will use both the CPU and the GPU - using graphics processor programming language rather than DirectX. I think we're going to get there pretty quickly.
I expect that by the time of the release of the next generation of consoles, around 2012 when Microsoft comes out with the successor of the Xbox 360 and Sony comes out with the successor of the PlayStation 3, games will be running 100% on based software pipelines. Yes, some developers will still use DirectX, but at some point, DirectX just becomes a software library on top of ... you know.
TG Daily: If your vision comes true, it looks like graphics will take the best from the CPU and the GPU, with graphics hardware continuing its evolution from a fixed function pipeline into what are basically arrays of mini-processors that support almost the same data formats as floating point units on the CPU today.
Sweeney: It is hard to say at what point we are going to see graphics hardware being able to understand C++ code. But data will be processed right on the GPU. Then, you are going to get the GPU's computational functionality to a point where you can - not that this is useful, but it will be a very important experiment - recompile the kernel for a GPU and actually run the Linux kernel off the GPU - running entirely by itself. Then, the boundary between the CPU and the GPU will become just a matter of performance trade-offs.
TG Daily: General purpose GPUs competing with CPUs? Do you already have any idea who might win this battle?
Sweeney: Hard to say at this time. Both can run any kind of code, GPUs are just much better optimized for highly parallel vector computing. CPUs are better for authorized out-of-order, branching, and operating system type of things. Once they both have a complete feature-set, things will get very interesting there. We could see the CPU pushing GPUs out of the market entirely, if the integration of highly parallel computing influences future designs. Or, we could see GPU vendors start pushing actual CPUs out of the market: Windows or any other operating system could run directly on a GPU. There are lots of possibilities.