Are there any devs using tile rendering in 360 games?

BigGamer X said:
If 576P with a "whopping" 2Xaa becomes norm, I'm selling my X360. I can still see jaggies badly at that res. 1280-720 with "fake" AA would actually look better.

it's 1 launch game, out of 18, and was an exception to the rule. Far from the norm.
 
Tile based rendering in Kyro

What is tile based rendering?
To explain tile based rendering, one must first delve into the world of conventional graphics systems. In 3D graphics rendering, there are a few overlaying operations that must be performed before outputting the final image.
The basic 3-D coordinate system consists of the X, Y and Z planes. In the Z-buffer the graphical elements in the image are assigned a depth value. This depth value is used to determine where the polygons will be on the Z-axis. Depending upon the transparency of the objects, many polygons will never be drawn because they simply aren't in sight. An image might have a car in front of a duck. As a result the duck doesn't need to be drawn. After Z-buffering, the data is sent on to the frame buffer memory.

With tile based rendering, we have a totally different process at work. As its name implies, tile based rendering cuts up the scene into tiles. Instead of processing an entire image with a resolution of 640x480 at once like conventional rendering techniques, TBR takes small chunks at a time. As an arbitrary number, a tile size might be 20x20. An internal Z-buffer is then used to determine all the depth values before the objects are textured or manipulated in any way. This is where the KYRO shines. The pre-sorting is how the chip figures out only what it needs to draw. Smaller data sets reduce the amount of memory bandwidth needed. Once all the data sets have been tiled and sorted, the processor proceeds to texture and shade the tiles until the entire image is complete.

Conventional renderers do all the work and then filter out what polygons are actually needed (in view). The KYRO determines what it needs to draw first and then does only that, which saves memory bandwidth and processing power. The KYRO only needs regular SDRAM. The card simply does not need the extra bandwidth provided by DDR memory. This is where the effective fillrate term comes into play. With tile based rendering the KYRO doesn't need to generate 750 Mpixels to get the same image a GeForce2 would need 750 Mpixels to create.

http://www.firingsquad.com/hardware/kyropreview/default.asp

Tile-based rendering: The technology behind Kyro/Kyro II
Unlike traditional architectures that draw the entire contents of a scene regardless of whether or not they're actually visible on the screen, the tile-based approach determines which areas are visible and which ones aren't. We'll take Sarju's smiley face example from our original Kyro article:


To generate the previous image, a traditional immediate mode renderer would draw both smiley faces and then cut out the right portion of the blue smiley face (behind the yellow smiley face). This cut out portion is known as overdraw, as it isn't used in the final scene. On the other hand, the Kyro II never draws this unused portion; instead it only draws the visible portions of a scene:



By drawing only the visible portions of a scene, the Kyro II doesn't perform the redundant work of conventional graphics accelerators, and most importantly doesn't perform additional texture fetches from memory, an important aspect that allows the Kyro II to make more efficient use of its available memory bandwidth. Our smiley face example is an extremely simplified example of the challenges facing today's graphics accelerators. With scene complexity in games rising each year, overdraw continues to suck in more bandwidth. Graphics manufacturers have dealt with this problem by moving to faster DDR memory, but this can be an expensive solution. Both ATI and NVIDIA have implemented their own solutions for dealing with overdraw in their RADEON and GeForce3 products respectively, but neither implementation is as aggressive as tile-based rendering. Is tile-based rendering the way of the future? If you ask Imagination Technologies, the answer is a resounding yes. ATI and NVIDIA think differently however.

http://www.firingsquad.com/hardware/kyro2/default.asp

old article from b3d website
http://www.beyond3d.com/articles/tilebasedrendering/index1.php
 
Last edited by a moderator:
ShootMyMonkey said:
Texture copy of the back buffer (or a rendertarget that would otherwise have been the back buffer).
Without tiling you cannot fit a 720p backbuffer in eDRAM with multisampling period, it doesn't matter wether you use the hardware to downsample it for display at the end or DIY it. So again ... where are they storing those multiple samples exactly?
 
Lysander said:
Is xenos immediate mode rendering gpu or tile-based rendering gpu?
it's just an IMR with a big embedded frame buffer, it's much more similar to any other GPU out there than to a tile based deferred renderer
 
Last edited:
Without tiling you cannot fit a 720p backbuffer in eDRAM with multisampling period, it doesn't matter wether you use the hardware to downsample it for display at the end or DIY it. So again ... where are they storing those multiple samples exactly?
It's not a backbuffer w/ multisampling at all, and it's not downsampling anything. No multisampling is enabled, so you get a fully-aliased single backbuffer. It's relying on the interpolation while sampling the one single texture at slightly different spots plus possibly some mild jittering to get the effect of multisampling. The "multiple samples" are basically being stored in the registers, for lack of a better wording.
 
nAo said:
it's just an IMR with a big embedded frame buffer, it's much more similar to any other GPU out there than to a tile based deferred renderer
Uh, so you say that it renders an image at once and than it deconstruct that image down to tiles, simply to put it into edram.
Why not using edram as z buffer for depth calculation, then render 3 tiles on shaders and each tile goes to edram for aa sampling?
 
That's not what most people who matter will define as multisampling, shader-ized or otherwise. Supersampling a bilinearly upsized texture is also completely worthless, the staircases are already there and you aren't going to remove them like that ... which is not to say you couldn't do anti-aliasing with post processing, that's just not the way you would do it.

A minimum blur version of a post process anti-aliasing filter would find the subpixel edge location and blend the edge pixel with the pixel on the opposing side of the edge depending on that location and edge strength. Non trivial and very twiddly.
 
Lysander said:
Uh, so you say that it renders an image at once and than it deconstruct that image down to tiles, simply to put it into edram.
Why not using edram as z buffer for depth calculation, then render 3 tiles on shaders and each tile goes to edram for aa sampling?
I think you're misunderstanding nAo. The z buffer is in edram and AA sampling is done there. nAo didn't say otherwise.
 
I was searching for latest on powerVR engine developement, when I found this. PowerVR is now in use in mobile phones for graphics. Info on latest PowerVR SGX reads like info on 360gpu. It uses unified shaders :oops:

PowerVR SGX - Key features


* Unified Scalable Shader EngineT (USSE) - combines vertex and pixel
shading in a single processing unit maximizing performance for available
silicon area through automatic load balancing.
* Enables advanced geometry and pixel processing capabilities such as
procedural geometry (e.g. HS) and textures, advanced per pixel and vertex
lighting effects (e.g., shadows, parallax bump mapping, etc.). The
programmable architecture allows acceleration of other multimedia related
tasks (e.g. image processing). This unified approach to processing uses a
single unified-programming model with one compiler, reducing hardware and
software qualification time.
* Latency tolerant architecture - geometry and rasterisation processes
decoupled using tile-based rendering enabling on-chip processing of costly
hidden-surface removal and deferred pixel shading No pixel shading of
non-visible pixels, eliminating all unnecessary accesses to off-chip memory,
with on-chip processing of multiple render targets.
* Image Quality - Internal True ColourT operations to be performed
on-chip using high precision maths at arbitrary pixel precisions up to IEEE
32bit floating point combined with comprehensive programmable image
anti-aliasing for free.

It's an approach adopted by ATI for its R500 Xbox 360 graphics chip and
probably for the upcoming R520 desktop GPU. Nvidia is working on a unified
shader architecture for its next-generation G80 GPU family.

The SGX series builds on Imagination's existing PowerVR MBX line, itself
founded on PowerVR's low-bandwidth tile-based rendering architecture and
deferred pixel shading technique.

Like other PowerVR core designs, the SBX series will be made available to
semiconductor makers under licence. Imagination said key licensees will
receive their first core designs from Q4.
such licensee is Intel, which said in May it had bought the rights to
use the core design.

http://archives.devshed.com/forums/showthread.php?p=4015130#post4015130
 
Last edited by a moderator:
Lysander said:
I was searching for latest on powerVR engine developement, when I found this. PowerVR is now in use in mobile phones for graphics.
He's quick off the mark, this Lysander :p :rolleyes: :p :rolleyes:
 
Lysander said:
I was searching for latest on powerVR engine developement, when I found this. PowerVR is now in use in mobile phones for graphics. Info on latest PowerVR SGX reads like info on 360gpu. It uses unified shaders
There's quite a few threads about PVR's technology, on the other forums of this board, and thoses include the talks about their new SGX architecture. Also, there's actually a PVR employee* in this very thread.


*It's the guy who makes the tea, and only that, but he's useful nonetheless. When we need tea, for instance.
 
Vysez said:
Also, there's actually a PVR employee* in this very thread.


*It's the guy who makes the tea, and only that, but he's useful nonetheless. When we need tea, for instance.
You cheeky monkey.




I make damned fine tea.
 
Back
Top