Het volgende is geript van een post op rage3d.com ik hoop dat iedereen er wat aan heeft:
First thing I need to clear up is the comment scr0t made about HyperZ needing to be supported by the application to work. This is 100% false! All hyperZ functions work transparent to applications, with the limitation that some applications will benefit more from HyperZ than others depending on the order the polygons are sorted in and various other things.
Now, there are numerous terms here being thrown around that need to be clarified because most are being used at least somewhat incorrectly.
Deferred Rendering:
In a nutshell Deferred Rendering is a method of rendering that is centered around a uniqe way of doing Hidden Surface Removal (HSR). I'll explain why HSR term needs to be used carefully in a minute. Deferred Rendering works by checking every single pixel on the screen to determine what polygons are visible (you can check all polygons for visibility for every pixel). After all the pixels have been checked for the entire frame, only the visible polygons in the frame rendered (hence, Deferred Rendering: the entire frame is calculated first and then rendered, "traditional renderers" (such as 3dfx/nvidia) cards render every polygon as they recieve them, visible or not).
The advantage: Greatly reduces fill-rate necesary to render each frame.
The disadvantage: a lot of processing of each frame before the actual rendering.
To make this rendering method more practicle we get to Tile Based Rendering (as the term is generally used for).
--------------------------
Tile Based Rendering (TBR):
This term is misleading in many ways. What Most people are reffering to when they use this term is in relation to Videologic PowerVR (PVR1, Neon250 and Kyro) based cards and the different rendering technique (Deferred Rendering). Tile Based Rendering in this context is an optimization of Deferred Rendering to make it practical. Instead of doing all the calculations for every pixel for the Entire frame at once, TBR chips break each frame down into smaller chunks (say, 32x32) and calculates the visibility for all the pixels, then moves on to the next tile. When all the tiles are complete, the frame is rendered. This reduces the memory requirements for setting up the scene and can optimize cache hits and many other things.
One of the reasons this term can be confusing is that most cards "Tile" their memory to help get optimal cache hit rates for things like texture access... but I suppose I shouldn't confuse things any more than they already are.
---------------------
Hidden Surface Removal (HSR):
First, i'll strip a bit from a post by SimonF (an engineer at Videologic, post not related to Videologic stance or anything, just as a forum member) regarding the use of HSR as a term:
"Hidden Surface Removal, aka Hidden Surface Elimination, aka Visible Surface Determination, is simply making sure that in the final image you don't see portions of objects that are behind others."
Now, having said that, the Z-buffer is a form of HSR. It doesn't reduce the overdraw, instead it make sure you don't see polygons you shouldn't whether they are rendered or not.
Many people are using HSR to describe the process of actually not rendering some or all of those non-visible polygons which just confuses the matter.
-----------------
Keep in mind the following is speculation/theory based on available info.
Regarding 3dfx performance enhancement:
I'll steal from Kristof at Beyond3D this time (a "performance architect" now working for 3dfx, this is not an official 3dfx stance or anything like that, just a comment made as a forum member):
"3dfx is now using a software occlusion detection system to save fillrate"
What this refers to is a software method for "culling" pixels/polygons, that 3dfx is using to try and reject the rendering of some polygons before accessing the Z-buffer. This by no means means it is "removing all of the survaces that you don't see on the screen" as stated by scr0t. It can however help to save some fill-rate due to saving texture reads and not rendering polygons in the grossest of instances. This will only help in fill-rate limited instances (such as higher resolutions) and will likely require a strong CPU as it is entirely software based.
HyperZ (specifically the Heirarchical Z function) on the other hand is a little closer to what HSR means, though it is not HSR in the definition sense either. HyperZ covers a bunch of different ways to save bandwidth, but the "heirarchicalZ" function is a hardware implementation that I suppose could be could called "Early Z Rejection" or something like that and is another form of "culling" of pixels/polygons. The architecture of the Radeon chip uses an internal reduced resolution Z-buffer to try and reject polygons from being rendered/textured before it checks the full external Z-buffer stored in memory. This saves bandwidth and can help fill-rate depending on the order the polygons are sorted in.
------------------------
Hope this helps to clear up a bit of whats going on and what the various terms relate to. Pardon any misspellings etc, heh was meant as a fairly quick post but grew rather quickly
First thing I need to clear up is the comment scr0t made about HyperZ needing to be supported by the application to work. This is 100% false! All hyperZ functions work transparent to applications, with the limitation that some applications will benefit more from HyperZ than others depending on the order the polygons are sorted in and various other things.
Now, there are numerous terms here being thrown around that need to be clarified because most are being used at least somewhat incorrectly.
Deferred Rendering:
In a nutshell Deferred Rendering is a method of rendering that is centered around a uniqe way of doing Hidden Surface Removal (HSR). I'll explain why HSR term needs to be used carefully in a minute. Deferred Rendering works by checking every single pixel on the screen to determine what polygons are visible (you can check all polygons for visibility for every pixel). After all the pixels have been checked for the entire frame, only the visible polygons in the frame rendered (hence, Deferred Rendering: the entire frame is calculated first and then rendered, "traditional renderers" (such as 3dfx/nvidia) cards render every polygon as they recieve them, visible or not).
The advantage: Greatly reduces fill-rate necesary to render each frame.
The disadvantage: a lot of processing of each frame before the actual rendering.
To make this rendering method more practicle we get to Tile Based Rendering (as the term is generally used for).
--------------------------
Tile Based Rendering (TBR):
This term is misleading in many ways. What Most people are reffering to when they use this term is in relation to Videologic PowerVR (PVR1, Neon250 and Kyro) based cards and the different rendering technique (Deferred Rendering). Tile Based Rendering in this context is an optimization of Deferred Rendering to make it practical. Instead of doing all the calculations for every pixel for the Entire frame at once, TBR chips break each frame down into smaller chunks (say, 32x32) and calculates the visibility for all the pixels, then moves on to the next tile. When all the tiles are complete, the frame is rendered. This reduces the memory requirements for setting up the scene and can optimize cache hits and many other things.
One of the reasons this term can be confusing is that most cards "Tile" their memory to help get optimal cache hit rates for things like texture access... but I suppose I shouldn't confuse things any more than they already are.
---------------------
Hidden Surface Removal (HSR):
First, i'll strip a bit from a post by SimonF (an engineer at Videologic, post not related to Videologic stance or anything, just as a forum member) regarding the use of HSR as a term:
"Hidden Surface Removal, aka Hidden Surface Elimination, aka Visible Surface Determination, is simply making sure that in the final image you don't see portions of objects that are behind others."
Now, having said that, the Z-buffer is a form of HSR. It doesn't reduce the overdraw, instead it make sure you don't see polygons you shouldn't whether they are rendered or not.
Many people are using HSR to describe the process of actually not rendering some or all of those non-visible polygons which just confuses the matter.
-----------------
Keep in mind the following is speculation/theory based on available info.
Regarding 3dfx performance enhancement:
I'll steal from Kristof at Beyond3D this time (a "performance architect" now working for 3dfx, this is not an official 3dfx stance or anything like that, just a comment made as a forum member):
"3dfx is now using a software occlusion detection system to save fillrate"
What this refers to is a software method for "culling" pixels/polygons, that 3dfx is using to try and reject the rendering of some polygons before accessing the Z-buffer. This by no means means it is "removing all of the survaces that you don't see on the screen" as stated by scr0t. It can however help to save some fill-rate due to saving texture reads and not rendering polygons in the grossest of instances. This will only help in fill-rate limited instances (such as higher resolutions) and will likely require a strong CPU as it is entirely software based.
HyperZ (specifically the Heirarchical Z function) on the other hand is a little closer to what HSR means, though it is not HSR in the definition sense either. HyperZ covers a bunch of different ways to save bandwidth, but the "heirarchicalZ" function is a hardware implementation that I suppose could be could called "Early Z Rejection" or something like that and is another form of "culling" of pixels/polygons. The architecture of the Radeon chip uses an internal reduced resolution Z-buffer to try and reject polygons from being rendered/textured before it checks the full external Z-buffer stored in memory. This saves bandwidth and can help fill-rate depending on the order the polygons are sorted in.
------------------------
Hope this helps to clear up a bit of whats going on and what the various terms relate to. Pardon any misspellings etc, heh was meant as a fairly quick post but grew rather quickly
Breek je nek voorzichtig
:strip_exif()/u/3749/DukeNukemSmall.gif?f=community)
!