*Game Tech*

Status
Not open for further replies.
I see the PS3 version is much more prone to screen tearing.

Even with all the dedicated works on SPUs, it's sad to see PS3 version still lags behind :cry:
 
Can teh developer shed some light on the visual differences? We would appreciate that a lot :)
 
.....Or a problem of QA. It's always hard to tell from these comparison shots of whether you are seeing a fair representation of a systemic issue or isolated occurences of contrast.

Speaking of QA. As there's some differences between HLSL and Cg, it could just be that the tangent space is messed up and eat the normals. I've had that happen to me a few times. :)

But in general, except from the few MB of missing RAM, PS3 is much more texture happy. Can't imagine why someone would leave out the entire normal map. Sure, reduce the resolution, but remove it? Sounds like a bug to me. :)
 
Speaking of QA. As there's some differences between HLSL and Cg, it could just be that the tangent space is messed up and eat the normals. I've had that happen to me a few times. :)

But in general, except from the few MB of missing RAM, PS3 is much more texture happy. Can't imagine why someone would leave out the entire normal map. Sure, reduce the resolution, but remove it? Sounds like a bug to me. :)

What do you mean with Texture Happy?
 
24 texture filters compared to Xenos' 16.
It's great for peak texture throughput, but texture instructions cost math ops and trilinear/aniso cost even more. You can have shaders where adding more texture ops are free on Xenos, but they will always cost you on RSX, so I don't know if "texture-happy" is particularly apt.

It's not just the texture access, but the math ops, vertex shader ops, setup cycles (more iterators needed), and RAM. You add them all up and it might solve all their problems at once.

Interestingly, we saw the same with Oblivion, but at least they added aniso to compensate a bit.
 
Why are they free on xenos, but not rsx, mint?

Also, while I admit I never followed it very closely, I was under the impression the PS3 version of Oblivion was improved over the 360 version, but you seem to be suggesting the opposite. Could you enlighten me, please.
 
One has added AF and no AA (PS3), the other has 2x AA but no (or not as much) AF (360). Both have the same mid distance shader fixes and going from the scaling thread PS3 outputs at 720p where as 360 at 600 ish p or so.

/Can't recall exactly and can't be bothered looking........ :D

From my own experiences with both, they both have outdoor framerate hitches but oddly the PS3 version is really stuttery indoors sometimes as well for some reason, where as I only experienced said hitches outdoors on the 360. Thats from vanilla and GOTY versions on both consoles.

/Played to much Oblivion............
 
Why are they free on xenos, but not rsx, mint?

Also, while I admit I never followed it very closely, I was under the impression the PS3 version of Oblivion was improved over the 360 version, but you seem to be suggesting the opposite. Could you enlighten me, please.

No you are right, Oblivion got better textures, AF and a resolution increase (+better framerate) when it was ported to PS3.
 
Why are they free on xenos, but not rsx, mint?
Remember I said "some shaders". If a shader is heavy on math, you can add texture instructions and it will run at the same speed on Xenos. The texture units run in parallel to the math units.

On RSX, doing this will slow the shader down, because the texture units use part of the math units, and the way it's designed, the shader program can't proceed until the texture instruction is done. This inflexible but simple design is one of the reasons that RSX has such high peak rates for its size.

Also, while I admit I never followed it very closely, I was under the impression the PS3 version of Oblivion was improved over the 360 version, but you seem to be suggesting the opposite. Could you enlighten me, please.
The ground in the PS3 version got AF, which made a huge difference in texture quality, but it lost normal mapping, so it looks flat. Which is better is a matter of opinion (I'd probably choose the AF).

Bad Company doesn't have extra AF in the PS3 version, though.
 
Remember I said "some shaders". If a shader is heavy on math, you can add texture instructions and it will run at the same speed on Xenos. The texture units run in parallel to the math units.

On RSX, doing this will slow the shader down, because the texture units use part of the math units, and the way it's designed, the shader program can't proceed until the texture instruction is done. This inflexible but simple design is one of the reasons that RSX has such high peak rates for its size.

Thanks, interesting information.

Do the vertex units of the RSX share math units with the shader units as well?
 
Last edited by a moderator:
RSX isn't unified, so the vertex shaders are separate from the pixel shaders. As for other vertex operations like clipping/culling, I doubt there's any sharing.

With vertex texturing, I'm not sure if math units are used, but it doesn't really matter because the vertex texturing is so slow that you can do a ton of math instructions for every texture instruction. I think they can work in parallel in the VS, though.
 
Last edited by a moderator:
RSX isn't unified, so the vertex shaders are separate from the pixel shaders. As for other vertex operations like clipping/culling, I doubt there's any sharing.

With vertex texturing, I'm not sure if math units are used, but it doesn't really matter because the vertex texturing is so slow that you can do a ton of math instructions for every texture instruction. I think they can work in parallel in the VS, though.

Thanks, as the RSX lacks unified shaders, but the vertex shaders can work in parallel with pixel shaders, how hard is it to exploit that capability, i.e. distributing the vertex calculations more evenly over the rendering cycle? (not vertex texturing)
Is it achievable at all, if so is tiled graphics of help?

I know culling on the CPU is one way to reduce the amount of vertex calculations on the GPU and I´ve seen suggestions about caching invariant vertex results and such. Culling seems pretty straight forward, but how effective is caching, is it very dependant on the depth of field or can you expect good results in all situations?
 
Thanks, as the RSX lacks unified shaders, but the vertex shaders can work in parallel with pixel shaders, how hard is it to exploit that capability, i.e. distributing the vertex calculations more evenly over the rendering cycle? (not vertex texturing)
Is it achievable at all, if so is tiled graphics of help?
It's quite hard to do anything here. Pixel:vertex ratio for any set of polygons varies with distance to the screen and view direction, and you don't know those until after you've already run the vertex shader. It's more important to efficiently traverse the vertices to maximize vertex re-use than to re-order polygons in a way that tries to keep that ratio from fluctuating to any extreme. You can't really avoid large clumps of vertex-heavy load. You can set up your index buffer to break up long stretches of backfacing triangles (at the cost of a little re-use optimality), but that's about it.

I'm not sure how effective caching results would be beyond the short term caching already present in GPUs. I'd have to read more about the techniques.
 
Status
Not open for further replies.
Back
Top