Is HDR "Free" for the Xenos?

There will be no difference in the fill-rate limit between AA and non-AA.

The parent->daughter bandwidth, 32GB/s, is enough for 4GP/s including 4xAA sample data.
You're completely missing what I'm talking about. Unless you're trying to say that everything on chip magically quadruples in performance when enabling 4xAA. I'm saying that AA means more pixels to fill than not AA. Those extra pixels don't come for free, whether that's a purely fillrate problem or a problem of pixel shading power... doesn't really matter -- Pixels processed are pixels processed... rendering more pixels is something that cannot completely come for free if you're approaching some pixel or texel-related limit no matter how much bandwidth you have. Say I'm making 25 texture reads on every pixel shader, I'm going to hit texel fillrate limits with AA enabled sooner than I would without it simply because that shaders will be run that many more times. There's going to be a limit to how far you can say that the hit due to AA will be small. The more render passes you have, the more likely you are to see it.
 
whatever faud, you've already decided what you WANT to believe, and you're just looking for arguments, however weak they are, to support what you WANT to be true.

I think we're all through explaining it to you.
 
ShootMyMonkey: You're assuming SSAA. Xenos uses MSAA, which increases the number of samples, not pixels.The pixel shading workload does not increase by more than 1-2% approximatively (additional samples of the edge of a triangle being in a "pixel" they wouldn't have been "in" otherwise).
There are plenty on articles on the net about MSAA. So stop being so stubborn and try Google - it really works.

Uttar
 
Uttar said:
ShootMyMonkey: You're assuming SSAA. Xenos uses MSAA, which increases the number of samples, not pixels.The pixel shading workload does not increase by more than 1-2% approximatively (additional samples of the edge of a triangle being in a "pixel" they wouldn't have been "in" otherwise).
There are plenty on articles on the net about MSAA. So stop being so stubborn and try Google - it really works.
Exactly. MSAA is not SSAA. They have different performance characteristics.
 
ShootMyMonkey said:
There will be no difference in the fill-rate limit between AA and non-AA.

The parent->daughter bandwidth, 32GB/s, is enough for 4GP/s including 4xAA sample data.
You're completely missing what I'm talking about. Unless you're trying to say that everything on chip magically quadruples in performance when enabling 4xAA.

No, the ceiling on the GPU's fragments is set relatively low. There are 48 fragment pipes in Xenos, but it's designed to generate 8 fragments per clock (roughly half the speed of R420, for example).

The EDRAM's ROPs are running at 1/16th capacity, roughly (guess), with AA turned off.

It's only when you turn on AA that the ROPs are able to use all their bandwidth.

I'm saying that AA means more pixels to fill than not AA. Those extra pixels don't come for free, whether that's a purely fillrate problem or a problem of pixel shading power...

It appears to me that you are confusing fragments, AA samples and screen pixels...

Fill-rate is conventionally expressed in terms of screen pixels rendered - edit: scrub that, there are competing definitions of fill-rate.

The number of AA samples used in multi-sample anti-aliasing is not counted towards fill-rate.

In super-sampling, yes, you would count AA samples. But not in Xenos's AA.

doesn't really matter -- Pixels processed are pixels processed... rendering more pixels is something that cannot completely come for free if you're approaching some pixel or texel-related limit no matter how much bandwidth you have. Say I'm making 25 texture reads on every pixel shader, I'm going to hit texel fillrate limits with AA enabled sooner than I would without it simply because that shaders will be run that many more times. There's going to be a limit to how far you can say that the hit due to AA will be small. The more render passes you have, the more likely you are to see it.

An AA sample passes through the GPU without a single shader operation being performed on it. AA samples in multi-sampling AA are nothing more than sub-pixel geometry-present flags. Within a single pixel at the edge of a triangle, the edge will cover only, say, 30% of the pixel. Multi-sampling simply determines which of four pre-determined positions within the pixel are covered by the triangle. If one position is covered or 3 positions are covered, it makes no difference to the shader workload, because the GPU doesn't run the shader on the AA samples.

You can't count multi-sampling AA samples as part of the total "fill-rate".

Jawed
 
Shifty Geezer said:
How much bandwidth does writing 3 tiles to RAM take? At a guess, 10 MBs eDRAM is gonna consume...um...10 MB bandwidth per write. 10 MB write x 3 tiles = 30MB/s per frame x 60fps = 1,800 MB/s = 1.8 GB/s; well within the capabilities of the RAM bandwidth.

You don't have to write out all the EDRAM's content - you only need the color values, you can leave Z and Stencil in there. Also, a 720p frame tiled up into 3 parts won't fill the 10MB there, you'll probably have some spare space for render-to-texture operations and such.

Oh, I see others have already calculated the exact bandwith needs ;)
 
blakjedi said:
so is SSAA better or MSAA?

In terms of quality, yes - you also perform 4x shader and texture antialiasing, not just geometry AA (MSAA). But it cuts your fillrate by 75%, and it performs AA on pixels that don't need it.

Most offline renderers have adaptive SSAA that will only up the samples on pixels that require it; some renderers also have shader and geometry AA decoupled, and thus those will always perform a high level of geometry AA on every pixel. This should be the future for hardware rendering as well.
 
Laa-Yosh said:
blakjedi said:
so is SSAA better or MSAA?

In terms of quality, yes - you also perform 4x shader and texture antialiasing, not just geometry AA (MSAA). But it cuts your fillrate by 75%, and it performs AA on pixels that don't need it.

Most offline renderers have adaptive SSAA that will only up the samples on pixels that require it; some renderers also have shader and geometry AA decoupled, and thus those will always perform a high level of geometry AA on every pixel. This should be the future for hardware rendering as well.

So MS went with the low road MSAA
 
blakjedi said:
Laa-Yosh said:
blakjedi said:
so is SSAA better or MSAA?

In terms of quality, yes - you also perform 4x shader and texture antialiasing, not just geometry AA (MSAA). But it cuts your fillrate by 75%, and it performs AA on pixels that don't need it.

Most offline renderers have adaptive SSAA that will only up the samples on pixels that require it; some renderers also have shader and geometry AA decoupled, and thus those will always perform a high level of geometry AA on every pixel. This should be the future for hardware rendering as well.

So MS went with the low road MSAA

yeah xenos is a POS :rolleyes:
 
Question: Is there SSAA of the 720p framebuffer if I use a standard non HDTV TV for output?
I guess this would be something non HDTV users would really appriciate, and those are still the majority.
 
DotProduct said:
Question: Is there SSAA of the 720p framebuffer if I use a standard non HDTV TV for output?
I guess this would be something non HDTV users would really appriciate, and those are still the majority.

Probably developer decision.

My guess: In most situations, yes. The 360 has a powerful scaler unit and will probably take the 720p image and scale it.

That said, there is still the issue of widescreen, menus, etc... And the other is performance. If the game is choppy at 720p, they may decide to support 480p on standard sets to make the game smoother. Yeah, you would lose some of the SSAA IQ benefits (still would get 4xAA absolutely free as 4xMSAA fits into the 10MB framebuffer perfectly at 480p), but would get a smoother gameplay experience.

But as MS has told developers 720p is standard and the hardware appears more than capable to hit that target resolution, I think most games would just be scaled down.

But that opinion is based purely on the knowledge of MS's standard and what ATI has said about the video scaler.
 
Couldn´t such SSAA be handled by the DAC itself?
To me it would make alot of sense too force 720p and then let the DAC convert the signal accordingly.

Perhaps its just me, but SSAA seems to increase the "feeled" resolution at least by factor 1.5. A lot of the high frequencies that get completly lost during SSAA are compromised by alias anyway (With alias I mean more than the typical edge alias).
Of course this is a matter of "taste", but I prefer blured images to aliased images and there is alot of high frequency noise in realtime CG .
 
blakjedi said:
So MS went with the low road MSAA
:p

MSAA is the standard form of AA used in PCs. It helps with some forms of aliasing. Other forms are better handled with anisotropic filtering and shader antialiasing.
 
I wasnt trying to diss... by saying "the low road" like I said MS went for the sweet spot in all their capabilities so MSAA gives the best bang for the die buck...
 
DotProduct said:
Couldn´t such SSAA be handled by the DAC itself?
To me it would make alot of sense too force 720p and then let the DAC convert the signal accordingly.
Downsamplng the output buffer to SDTV? Yes, and XB360 does that. It only renders in one mode AFAIK (720p) and either ups or downs the output. In essence, XB260 has one resolution with 2x or 4x AA, so Devs have a fixed target which guarentees high IQ, and they don't need ot worry about supporting different outputs manually. The downside is less fidelity and flexibility for different displays
 
Shifty Geezer said:
DotProduct said:
Couldn´t such SSAA be handled by the DAC itself?
To me it would make alot of sense too force 720p and then let the DAC convert the signal accordingly.
Downsamplng the output buffer to SDTV? Yes, and XB360 does that. It only renders in one mode AFAIK (720p) and either ups or downs the output. In essence, XB260 has one resolution with 2x or 4x AA, so Devs have a fixed target which guarentees high IQ, and they don't need ot worry about supporting different outputs manually. The downside is less fidelity and flexibility for different displays

Even if everything is down/upsampled, this is only partially true in that 720p is a wide screen format, while most standard TVs (480i/p) are a 4:3 aspect.

The game HUD, and probably text, will need to be considered when scaling, so I am pretty sure developers, in the least, will need to develop both a

-16:9 aspect
-4:3 aspect

They could theoretically do 1280x720 (16:9; 720p) and 960x720 (4:3) and downsample both to STV 480i/p resolutions to work with standard AND widescreen STVs.

I think the hardest part (and slightly time consuming) is ensuring that the 4:3 and WideScreen gaming experiences are comprable and neither is "boinked".

Of course I could be wrong and developers could simply make the games letterboxed on 4:3 TVs :oops:
 
Back
Top