ATI Technologies Interview: The Power of the Xbox 360 GPU
- Thread starter Megadrive1988
- Start date
You just described linear tessellation not subdivision surfaces. Subdivision surfaces are tessellated surfaces, but it's not necessarily linear tessellation of a surface. For example, if you apply one type of subdivision surface to a box you'll end up with a sphere.Jawed said:
please be gentle
just wondering...
since, both the xbox and the x360 use UMA,
wouldn't it be safe to assume that the x360 has 22.4GB/s effective bandwidth since the xbox had an effective bandwidth of 6.4 GB/s?
Since that's the connection to its RAM is clocked at that?
And that the conection between the GPU and daughter die is used to save the bandwidth from main RAM by doing some things internally?
So would it mean that eventhough x360 has 22.4GB/s of bandwidth, it's highly efficient in using it and is not constrained?
just wondering...
since, both the xbox and the x360 use UMA,
wouldn't it be safe to assume that the x360 has 22.4GB/s effective bandwidth since the xbox had an effective bandwidth of 6.4 GB/s?
Since that's the connection to its RAM is clocked at that?
And that the conection between the GPU and daughter die is used to save the bandwidth from main RAM by doing some things internally?
So would it mean that eventhough x360 has 22.4GB/s of bandwidth, it's highly efficient in using it and is not constrained?
SDS explained
SDS uses a surface-generating mathematical function. It's kind of part way between polygonal meshes and CSGs. Given a bounding cage, which can be split and subdivided into more surfaces, a curved surface is calculated. From that mathematically defined surface you have to translate it to something that can be rendered
You can relate SDSs to a 2 Dimensional Beizer curve. A Beizer curve has several points that define a curve. From this mathematical curve, to draw the curve so that you can see it, you plot on the screen a point at every pixel the curve passes through. What you could do instead is divide that curve into a number of straight lines by taking points that lie on the curve at given intervals rather than every pixel, and then drawing lines to connect the points. That's tesselation. Heck, I'd better add a pic to illustrate. Hang on...
An SDS surface is the same thing but in 3D. You have a perfect mathematical curved surface and need to render it to the screen somehow. One way is to raytrace every point which gives a perfect curved surface (within the limits of a pixelated display screen
). That's not good for realtime though as realtime hardware is geared towards rendering polygons. Another way more suitable for realtime rendering is to tesselate the surface into polygons that approximate the curved surface. The higher degree of tesselation, the greater the number of polygons and higher the overhead.
If we consider the sphere example, which is defined by an SDS cube (near enough. You can vary how the vertices of the bounding box structure affect the shape of the curve underneath), you can tesselate it depending on distance from camera. When the sphere is a tiny dot in the distance, rendering the cube is enough. As it gets nearer to the camera you'd start tesselating to a finer degree, adding polygons to approximate the curved surface. Each tesselation multiples the number of surfaces by four (dividng faces into quads). Each quad face is made of 2 triangles. So a box rendered at 0 tesselation is 12 triangles in size. The first order of subdivision is 48 triangles in size. The next produces a mesh of 192 triangles. That's 192 triangles making a sphere described in only 8 vertices of the SDS bounding cage, compared with about 192 vertices to descirbe the 'sphere' as a poly mesh!
You can increase fidelity close up too. A sphere made of 1500 polys consumes that much memory, but if you stand close enough that only part is visible in the screen, you may only see three straight edges defning that part of the curved surface. Using an SDS surface (still only 8 vertices ) you could selectively render only the visible surface and use a poly budget of 1500 triangles to render a smooth curve. I'm not sure what options and methods can be used for this in realtime situations though.
Hence the benefits are a lower memory footprint, much much lower than high resolution models, and higher fidelity with better LOD. Also animation/mesh manipulation has a lower overhead. If you have a cylindrical tentacle that you want to bend, made of say 1500 vertices in a poly mesh, you have to process every one of the mesh vertices. You could define the same tentacle in a dozen or so points using an SDS cage and only need transform those dozen points, then the interpolation of the tesselation stage produces the curves. The downside is the processing requirement tesselating the SDS cage, and I thought until recently trouble with UV. Laa-Yosh seems to think that's not an issue now.
That's one reason. An SDS can model a sphere in 8 vertices. It also gives better curve definition depending on tesselation resolution.Hardknock said:
SDS uses a surface-generating mathematical function. It's kind of part way between polygonal meshes and CSGs. Given a bounding cage, which can be split and subdivided into more surfaces, a curved surface is calculated. From that mathematically defined surface you have to translate it to something that can be rendered
You can relate SDSs to a 2 Dimensional Beizer curve. A Beizer curve has several points that define a curve. From this mathematical curve, to draw the curve so that you can see it, you plot on the screen a point at every pixel the curve passes through. What you could do instead is divide that curve into a number of straight lines by taking points that lie on the curve at given intervals rather than every pixel, and then drawing lines to connect the points. That's tesselation. Heck, I'd better add a pic to illustrate. Hang on...
An SDS surface is the same thing but in 3D. You have a perfect mathematical curved surface and need to render it to the screen somehow. One way is to raytrace every point which gives a perfect curved surface (within the limits of a pixelated display screen
). That's not good for realtime though as realtime hardware is geared towards rendering polygons. Another way more suitable for realtime rendering is to tesselate the surface into polygons that approximate the curved surface. The higher degree of tesselation, the greater the number of polygons and higher the overhead.If we consider the sphere example, which is defined by an SDS cube (near enough. You can vary how the vertices of the bounding box structure affect the shape of the curve underneath), you can tesselate it depending on distance from camera. When the sphere is a tiny dot in the distance, rendering the cube is enough. As it gets nearer to the camera you'd start tesselating to a finer degree, adding polygons to approximate the curved surface. Each tesselation multiples the number of surfaces by four (dividng faces into quads). Each quad face is made of 2 triangles. So a box rendered at 0 tesselation is 12 triangles in size. The first order of subdivision is 48 triangles in size. The next produces a mesh of 192 triangles. That's 192 triangles making a sphere described in only 8 vertices of the SDS bounding cage, compared with about 192 vertices to descirbe the 'sphere' as a poly mesh!
You can increase fidelity close up too. A sphere made of 1500 polys consumes that much memory, but if you stand close enough that only part is visible in the screen, you may only see three straight edges defning that part of the curved surface. Using an SDS surface (still only 8 vertices
) you could selectively render only the visible surface and use a poly budget of 1500 triangles to render a smooth curve. I'm not sure what options and methods can be used for this in realtime situations though.Hence the benefits are a lower memory footprint, much much lower than high resolution models, and higher fidelity with better LOD. Also animation/mesh manipulation has a lower overhead. If you have a cylindrical tentacle that you want to bend, made of say 1500 vertices in a poly mesh, you have to process every one of the mesh vertices. You could define the same tentacle in a dozen or so points using an SDS cage and only need transform those dozen points, then the interpolation of the tesselation stage produces the curves. The downside is the processing requirement tesselating the SDS cage, and I thought until recently trouble with UV. Laa-Yosh seems to think that's not an issue now.
Last edited by a moderator:
ATI is talking about a simple vertex shader there that can fetch texels and move the vertices based on the greyscale values in the texture.
The real trick about displacement mapping is not the implementation, but the amount of geometry that you want to process. For detailed surfaces, you need polygons smaller then a pixel, and that means very, very dense models, that would eat up all your bandwith, RAM, and slow the transformation and lighting down as well. Unless you work with HOS and adaptive tesselation, in which case you can keep the amount of polygons relatively low.
The real trick about displacement mapping is not the implementation, but the amount of geometry that you want to process. For detailed surfaces, you need polygons smaller then a pixel, and that means very, very dense models, that would eat up all your bandwith, RAM, and slow the transformation and lighting down as well. Unless you work with HOS and adaptive tesselation, in which case you can keep the amount of polygons relatively low.
Similar threads
- Sticky
