1st International Symposium on CELL Computing

Jawed said:
This document:

http://download.nvidia.com/developer/presentations/2004/6800_Leagues/6800_Leagues_Deferred_Shading.pdf

came up recently in another discussion of deferred rendering.

It's fairly equivocal about deferred shading.

http://www.beyond3d.com/forum/showthread.php?t=12010 is an old thread about it.

Jawed

It does make me all the more intreagued in seeing how deferred shading would pan out with the Cell factored in successfully!

As a total beginner, I'm reading a lot of these things hoping something will stick and will be useful whenever I have time to play around with this myself (hard to do in your spare time). But encouragingly, while cycling yesterday the picture on page 12 is exactly what popped into my head, when I'd been mulling over the concept of shading textures to match their context of lighting and so on.

This is something completely new for me and which I've picked up from this discussion. I like to understand stuff, even if I don't always get an opportunity to do something useful with that knowledge. ;)
 
nAo said:
Do you output this mask to the stencil buffer?
I wonder if storing a per pixel material ID into the stencil buffer and completely avoid dynamic branching would make it faster..

Marco

I stencil masked if I was running a certain pixel through the deferred pipeline or the normal pipeline for things like subsurface scattering. I was trying to integrate the deferred rendering pipeline into BW2 at that time. But it was not a good idea. I also tried some tricks with using the zbuffer as a kind of stencil mask and it was better but again more involved.

Unfortunately the stencil reject happens at the end of the pipeline so you are only saving bandwidth to the framebuffer but still running the shader, that's why dynamic branching is needed here (in the pixel shader or using early z rejection).

The R500 supports special Hi-stencil mode that can reject fragments before the pixel shader is run with some (heavy) limitations.

Fran/Fable2
 
What a pity, I did not know this..I thought you could use the stencil buffer to early reject pixels..
 
You can on the 360 but using equal/not equal stencil op and with a granularity of 256 fragments (if i recall correctly). So not always very useful in general, i tend to prefer dynamic branching, it's simple to write the first time.

Fran/Fable2
 
nAo said:
What a pity, I did not know this..I thought you could use the stencil buffer to early reject pixels..
A by product of the per pixel stencil ops being on the daughter die. There is no per-pixel early Z rejection either although the Hi-Z works in fairly small chunks so that helps a bit.
 
Arwin said:
Well, I think that the challenge of using the 8-core Cell as a CPU to programmers was about as much as they could stomach at this stage.
The pre-NVidia GPU was not Cell related in any meaningfull way - so this wasn't an issue.
The rest of what you said is very true though - toolset, experience, developer support and so on that Sony brought in with NVidia are all very valuable assets that would have been much less available with any kind of custom solution.

Shifty Geezer said:
and otherwise, the original ideas would have worked.
I have a suspicion that marketting would have liked it more. But I guess in the end software quality sells the platform so marketting is not the only deciding factor.
 
Would Toshiba's cellphone GPU development have been indicative of their PS3 GPU development in any ways, such as production resources, development team, relative performance, or design approach?
 
Back
Top