An interview with ATI - Dave Baumann

Graphics cards 1047 Page 4 of 5 Published by

teaser

Interview with ATI's Dave Baumann - Page 4

 

We all look very much forward to the new features DirectX 11 will bring along with it. Some of the features high on the top of my list to be interesting are of course the introduction of compute shaders and hardware tessellation (objects with better curved surfaces). The new graphics pipeline allows fairly flexible tessellation with the help of a dedicated hardware tessellation unit in the GPU. First thing that comes to my mind, and correct me if I am wrong here, is that R600 and 700 already have a HW tessellate unit inside the ASIC. I doubt it very much, but will there be some sort of backwards compatibility e.g. could that tessellate unit be used in DirectX 11 at all?

The tessellation unit featured in the ATI Radeon HD 2000, HD 3000 and HD 4000 series are all very much based on the same functionality found in the XBOX 360 "Xenos" graphics chip, although the unit in the ATI Radeon HD 4000 series does feature some additional tweaks. For DirectX 11 the tessellation portion of the pipeline has also been wrapped with two new shader types that can be used, the Hull Shader and the Domain Shader. Although these are new stages in DirectX 11, my understanding is that the actual tessellation portion of the pipeline is highly leveraged from the Xenos capabilities; hence any tessellation work that a developer carries out on our current GPUs will be very easily portable to DirectX 11.

Another DirectX 11 feature I'm quite excited about is the introduction of a new shader, the compute shader. Besides a capability to run cool stuff like physics effects somewhat more convenient through that shader, it could make post-processing faster and easier. Can you elaborate a little on compute shaders and what it will mean to ATI's upcoming DirectX 11 class graphics cards?

In talking to our ISV team I think you've hit the nail on the head with regards to where we may see DirectX Compute Shaders being used first - it seems like the optimization and enhancement of post processing routines may well be an area that sees an immediate benefit.

Compute Shaders is another area of functionality where DirectX 10 and DirectX 10.1 graphics processors will gain benefits under the DirectX 11 runtime.

The DirectX 11 API doesn't just have specifications for Compute Shaders 5.0, but also 4.1 and 4.0 and ATI Radeon HD 4000 Series graphics cards will actually fall into the Compute Shader 4.1 profile, bringing more functionality to developers and our DirectX 10.1 products.

We now touch the topic of GPU based Physics computation. Game Physics in the past where and still are handled by the CPU, yet now slowly is moving towards the GPU which can compute physics math much faster. It's however a very slow adaptation as the current problem of course is that only NVIDIA has a fully functional API for it. In the past week or so we noticed an announcement from ATI in regard to the HAVOK engine, which is going to support PhysX/Physics over ATI GPUs. Can you explain a little what is going to happen? Also, will the catalyst drivers have some sort of Physics functionality just like NVIDIA's approach, or will it remain HAVOK who will embed GPU Physics capabilities in their API? Also, when can we expect actual working HAVOK/ATI GPU Physics game titles?

First off, my personal take is that the story has warped a little, possibly due to the focus of the companies that have been making the biggest noise about GPU accelerated physics. The way I see things is that there will always be elements of game physics that will remain serial in nature and will probably continue to be processed best on CPU; then there are newer elements that benefit from data parallel compute processors (such as GPUs). These are relatively newer facets that are just becoming available to developers because the processors (and processor interfaces) weren't around previously. Finally there are likely to be tasks that may be relatively serial in nature, but will benefit to some extent from parallelization. It is this middle ground that represents a challenge for any company with only one type of processor as they will attempt to push all tasks to that processor type even though it may not represent the best choice for the end user.

This is where AMD's approach makes a lot more sense; by offering a full platform solution and producing both primary processor types (CPUs and GPUs) we can take a much more balanced approach to how we go about evangelizing things and how we set about putting them into practice. This is one of the reasons why we are playing the longer game with our approach to game physics and looking to utilize OpenCL, rather than trying to gain short term benefits with proprietary solutions that fall by the wayside when more universal standards become available. OpenCL is designed to be a true heterogeneous compute interface and will spread gracefully over data parallel compute processors and multicore CPUs.

Additionally, OpenCL has querying tools to test the compute capabilities of an individual platform, so that the processing requirements can be best tuned to the components within an individual computer - if a system has a middle-range CPU but a high-end GPU then the tasks can be biased towards the GPU. Alternatively if the system uses a performance CPU but a mainstream GPU then the tasks can be biased to the CPU so that the user can maintain the best graphics quality whilst still attaining good performance.

It should be noted that the demonstrations we have done to date have had zero impact on the Havok toolset itself. In other words, in this case the developer does not need to change anything from their point of view to enable GPU acceleration; it is entirely transparent.

As for what's going to happen next, we will disclose more as the time is right, we said that we would discuss what we are doing and how we are approaching this as we hit our milestones. Obviously the announcements at GDC concerning Havok and OpenCL were key milestones and give an indication of the path that we are taking. We are very happy with the relationship we've built with Havok and they seem to be fairly enthused about using OpenCL because it doesn't limit the processing of their middleware toolset on any one type of processor.

Share this content
Twitter Facebook Reddit WhatsApp Email Print