- 精华
- 0
- 帖子
- 3356
- 威望
- 0 点
- 积分
- 3407 点
- 种子
- 0 点
- 注册时间
- 2009-1-11
- 最后登录
- 2015-11-20
|
转载于B3D Forum
链接:http://forum.beyond3d.com/showthread.php?t=46241
List of Game Rendering Resolutions + some info on the hardware scaling
The other thread was getting to big for its own good, and as has been requested often enough, an easy-to-find compilation of discovered resolutions is needed.
I or other mods may update this thread as time goes.
Thanks go to Quaz for his efforts and most of the list. Thanks also go to grandmaster for providing direct screenshots from HDMI outputs.
Would you like to know more? Here is how the resolutions can be determined.
http://forum.beyond3d.com/showpo ... 4&postcount=273
http://forum.beyond3d.com/showpost.p...&postcount=282
http://forum.beyond3d.com/showpost.p...&postcount=284
http://forum.beyond3d.com/showpost.p...&postcount=292
http://forum.beyond3d.com/showpost.p...&postcount=225
http://forum.beyond3d.com/showpost.p...&postcount=222
http://forum.beyond3d.com/showpost.p...7&postcount=29
In order to reduce the number of people asking about hardware scaling, please read the following:
http://forum.beyond3d.com/showpost.p...3&postcount=77
http://forum.beyond3d.com/showpost.p...6&postcount=22
http://www.beyond3d.com/content/articles/16/
i.e.
360
Xenos is the hardware scaler, not HANA/ANA, which are just the video output chips dealing with digital/analog output to the various connections made with the display. Dave Baumann
AVIVO takes more samples for scaling so it is expected that the scaling is better (the algorithm also appears to be some form of bicubic, not a simple bilinear) Update: see below
Hardware scaling to the output resolution chosen in the dashboard is automagically performed .
In upscaling to 1080p, some games may first scale to 720p in software before the GPU scales to a 1080p output. e.g. RR6, SCIV, VF5, CoD4, H3, TR:L...
Some games let the GPU handle the scaling to 1080p directly from the arbitrary resolution. e.g. MotoGP 06, PGR3, ESIV:O...
"lanczos is just one of the selectable filters. Ultimately each game 'could' opt to use a different filter/sample count combination (though I suspect most don't bother)." -Fafalada
PS3
For whatever reason, the Pure Video scaler in the G7x derived GPU (RSX) is gimped to horizontal scaling of specific front buffer resolutions. See B3D Article
As of the January 2007 PS3 SDK, only the following front buffer resolutions are supported for hardware scaling to 1920x1080p: 960x1080 1280x1080, 1440x1080 and 1600x1080
Games whose back buffers are rendered at strange resolutions must upscale the front buffer (at a cost of extra memory) to either 1280x720 (720p output) or to one of the acceptable 1080p resolutions. (Note: native resolution = back buffer resolution, front buffer = image for displaying/hardware scaling)
ShootMyMonkey mentions scaling support for a pixel height of 576. There may be more new settings available.
Frame Buffer Calculations & Memory Consumption
Back-Buffer(s) = Pixels * FSAA Depth * Rendering Colour Depth (may include multiple render targets for deferred rendering techniques)
Z-Buffer = Pixels * FSAA Depth * Z Depth (usually 32-bit depth)
Front-Buffer(s) = Pixels * Output Colour Depth (this is what you see, almost always resolved to 8-bit per component rather than 10-bit or 16-bit)
Total = Back-Buffer(s) + Z-Buffer + Front-Buffer(s)
For Xenos, the back buffer and z-buffer must fit within the 10 MiB (10*1024*1024 bits, 8 bits/byte) to avoid tiling.
Update Dec. 3 2008: Grabbed from XNA MSDN:
"Render targets must be padded to certain dimensions based on the multisample mode. The padding required for 32-bits-per-pixel formats is 80×16 for 1× antialiasing, 80×8 for 2× antialiasing, and 40×8 for 4× antialiasing."
This may explain ShootMyMonkey's information on Tomb Raider Underworld's back buffer (1024x576) and depth-buffer (1040x576) dimensions, but may be tied to a particular rendering technique they are also using.
Frame buffer formats
RGBA8 = 8 bits for Red, 8 bits for Green, 8 bits for Blue, 8 bits for alpha = 32 bits per pixel
FP10 = 10 bits for RGB components, and 2 bits for alpha = 32 bits per pixel
FP16 = 16 bits for each component = 64 bits per pixel (no support for hardware alpha blending on Xenos)
NAO32 = LogLUV conversion, In-Depth explanation = 32 bits per pixel (no hardware alpha blending)
e.g. 1120x585, 2xMSAA, FP10, 32-bit Z-buffer
back buffer + Z = 1120*585*2*(32/8 + 32/8) = 10483200 bytes = 9.9975... MiB
Other formats do exist, such as R11G11B10 on Xbox 360 as Sebbbi explains:
Quote:
Originally Posted by sebbbi
It consumes same amount of memory and bandwidth as the standard RGBA8 and FP10 formats (4 bytes per pixel), and is as fast as FP10 (A2R10G10B10_FLOAT) to sample and to render to. R11G11B10_FLOAT also supports blending and filtering. It's a perfect choice for HDR rendering as the quality is pretty much comparable to FP16 and the bandwidth and memory usage are halved.
Regarding the notable absence of the alpha channel in this format:
Quote:
Originally Posted by sebbbi
The alpha channel of the back buffer (render target) is rarely used for blending. All the most common blending techniques can be implemented with only the source alpha (object's texture alpha channel). Destination alpha is only useful for some multipass rendering tricks (and most can be implemented more efficiently with the stencil buffer).
For custom color representations (logluv, RGBE8, etc), the alpha channel is used to store the color data component (exponent, color multiplier or fourth color channel needed for the color space). When writing custom color representations to the back buffer, the alpha channel is directly written to just like the RGB channels, and no alpha blending is used. This also means that source alpha cannot be used either (as the pixel shader alpha output is used for the alpha write and contains color data instead of alpha). When you are rendering with a custom color space, the only way to get alpha channel blending to work is to pinpoint between 2 buffers (sampling the pixel color from the other and rendering to the other). This slows down the performance considerably (game has to copy the whole backbuffer to a texture for every alpha blended object).
Aspect Ratio
Some of you might be wondering how games like Call of Duty 4 (1.71:1) , Halo 3(1.8:1) , Metal Gear Solid 4 (4:3) can have rendering resolutions that are not 16:9 aspect ratio. All you need to learn about is anamorphic widescreen. The image is squeezed into the rendered resolution but is then stretched to the proper 16:9 presentation.
An example of this squeezing can easily be seen in any Doom 3 engine games (Quake 4/Prey/Quake Wars). If you have one of them handy on your PC (latest version will do), try setting your resolution to 960x720 and in the console type r_aspectratio 1 for 16:9 or 2 for 16:10. All you'll see is the in-game view being squeezed/stretched horizontally. On the flip side, if you render the game at 1280x720 while still in 4:3 mode, the Mancubus just might be the fattest enemy you'll ever see. You can help it lose some weight by setting the game to 16:9. And of course, the isomorphic 1280x720 rendition will offer more image clarity than the anamorphic 960x720.
Multisample AA - multiple geometry/sub-sample (reddish squares in below images) points with a particular weighting (surrounding the texture sample point, green square in below images) are used to determine the colour of the pixel being rendered. Sample positions can differ between AMD/nVidia. As RSX is based on the G70 architecture, the following sample patterns should apply. In the case of Xenos, it would not be unreasonable to assume that it uses the same patterns as ATI has used in the past (R300+).
The result for 2xMSAA is that there may be one intermediary shade in between polygon edge steps; one sample is found to be within one polygon (e.g. colour A), and the second sample is found in another polygon (e.g. colour B). If both sample points have equal weightings, the resultant pixel would be 50% colour A, 50% colour B. Obvious results are obtained when a polygon edge bisects the shortest imaginary line connecting the two geometry sample points. Hence, 2xMSAA for G70 will look slightly different to 2xMSAA for R520 (see sample positions below).
For the case of 4xMSAA, there may be more shades in between polygon edge steps due to the higher number of geometry samples, resulting in a smoother transition between steps. With equal weightings to each sub-sample, there will be three intermediary shades.
The easiest way to see MSAA level is to have a straight-edged object overlapping another object/background with a high contrast in colours between the two e.g. black object against a white background. Beware of JPG compressed screenshots where pixels near high frequency components (edges) can be distorted.
G70 sample patterns
2xMSAA
http://www.beyond3d.com/images/reviews/g70/2x.png
4xMSAA
http://www.beyond3d.com/images/reviews/g70/4x.png
R520 - sample patterns
2xMSAA
4xMSAA
Quincunx AA on PS3 - two geometry sample points are used just like 2xMSAA (so the same storage cost), but it also uses 3 samples belonging to neighbouring pixels (regardless of a polygon edge) to the right and below of the original texture sampled point (see sample pattern image for clarity). The result is a blurring of the entire image, but higher perceived polygon AA. Consider a texture of higher frequency components, lots of different colour patterns. The current pixel's two geometry sample points indicate the pixel is entirely within one polygon. However, the three neighbouring sub-samples are still accounted for in the final pixel, hence the overall image blur.
Quincunx sample pattern
Comparison between 2xMSAA/QAA/ & blur filters
Temporal AA on PS3 (ala Quaz regarding DMC4, note that this is not the only implementation)- odd and even frames are rendered with a half-pixel shift. The current frame is blended with the previous frame to achieve a similar effect as super sample AA for static scenes. In a moving scene, the blending of the odd and even frames produces a persistent blurring of the image. However, this is also advantageous for the edges of alpha-to-coverage primitives, because traditional multisampling does not work*, only super sampling.
*see transparency AA or adaptive AA settings on appropriate PC hardware.
Update Dec 3 2008:
Sebbbi's take on TAA as seen so far:
Quote:
You can blend the new frame with last rendered frame (half pixel shifted offset), but this causes severe image ghosting with moving camera/objects limiting the technique usefullness. If the game can achieve solid 60 fps, it's usually better just to let the eyes do the blending themselves. 60 fps (half pixel shift every other frame) is enough to fool human eye and no distracting shimmering can be seen. Also all TV sets (and monitors) have some pixel lag, so the last frame pixels will slightly also blend together with the new pixels before being sent to the eye. Temporal AA looks good on static or slowly moving scenes, but the aliasing effect is no longer visible if the camera moves more than few pixels every frame (if blending is used you just see the ghosting and no AA at all, if no blending is used you just see the scene without AA).
There are many alternative temporal antialiasing methods that work perfectly on moving camera/objects. Reverse re-projection is one of them. For each rendered pixel, you calculate the position of the same surface pixel in last frame by utilising last frame model and view matrices (and sample the last frame back buffer texture at that position). This method is comparable to 2xSSAA, but affects only surfaces (not edges). The technique is most useful in hiding pixel shader based aliasing (caused by various parallax mapping techniques, shadow map sampling, negative lod bias shimmering, etc, etc). MSAA techniques do not anti alias polygon surfaces at all (leaving all aliasing caused by pixel shader and sampling). Like SSAA, all temporal aliasing techniques also antialias stencil buffer based effects (stencil shadows, etc).
----------------------
Black Levels & Output
Xbox 360
Standard = 16-235
Intermediate
Expanded = 0-255
PS3
Limited Range = 16-235
Full Range = 0-255
----------------------------
UE3.0 & MSAA - AA is apparent in certain cases, and it's possible the rendering pipeline or the use of post-processing effects, with respect to the MSAA resolve, messes with the end results. e.g. drawing effects after the msaa resolve.... tone-mapping can occur after the msaa resolve, leading to no AA'd edges... etc |
|
川公网安备 51019002005286号
楼主
发表于 2009-2-16 00:15 · 辽宁
