Thoughts about REYES approach, PlayStation 3 and Visualizer

If you guys remember the famous Cell patent the Visualizer showed 4 Pixel Engines as it had 4 PEs with 4 APUs each and the part of the PE used by the other 4 APUs was used for the Pixel Engines, the Image Cache and the CRTC...

People pointed out that those would be 4 separate pixel pipelines each working on a different polygon... others noted that having 4 Pixel Pipelines filling 1 pixel each would not be good enough ( I still expect between 2 and 4 GPixels/s with such a configuration ).

Recently in a discussion between V3 and I, someone noticed how wasteful most of today's consoles would be with micro-polygons as each could fill more than a single pixel ( in the polygon all the pipes are working on, they are not independent pipes ) each cycle.

I agree on the idea that the 4 PEs would work on a different polygon/micro-polygon each as it makes sense that they could work independently... with the triangle size getting very low, with the increase in complexity of Shader programs ( which will be the limiting factor in next-generation graphics ) and with the fact that with the increase in clock rate even 4 pipelines can bring you a combined fill-rate of over 2-4 GPixels/s, this is the idea you should push towards...

It will not make sense filling 4x4 patterns each cycle, even 2x2 will begin to be a bit wasteful...

With each pixel pipeline being independent you gain on flexibility without loosing much in speed, if you even loose anything at all...


Summary: Visualizer working on 4 micro-polygons each cycle or 4 triangle/cycle ( depending on what the programmer chooses for his/her engine ).

This kind of set-up would be another thing n the PlayStation 3 architecture which IMHO would ecnourage following a REYES-like approach...

Coming back to a REYES-like architecture, the Visualizer ser-up would fit the bill really nicely... each PE would ultimately ( using the Pixel Engine ) work on a separate micro-polygon and drawing 1 pixel per cycle.
 
Panajev -

Since you seem to be one of the PS3/Cell experts here what do you feel the difference is between a REYES approach and the approach taken by future Radeons/Geforces? From what little I understand of the REYES Rendering modality the determining characteristics of such on approach consist of stochastic (quasi-random) sampling of microtris from the higher level subdivision surface along with other characteristics which are now part and parcel of the "SGI approach" now ubiquitous in the PC world.

However with the rumored primitive shaders in DX10 (and R500/NV50) aren't the GFFX/Radeon also moving to a "REYES" system? I fail to see how piggybacking a powerful primitive shader on a modern 3D card would be appreciably different to the Pixar/Reyes system.

And a final note. One reason for 2x2 pixel configs on GPUs (NV3x has 1 and R3xx has 2 independent blocks) is to do high quality mip-mapping. One could do mip-mapping through a distance function, true. One caveat - if you do dependent texturing where you access texels indirectly calculating "distance" might be meaningless. What you do to do mipmapping is to estimate first derivative along the u and v texcord axis with respect to pixel position by subtracting the texcords from those of a different pixel. (dsx and dsy do this in DX9) While far from absolutely "correct," it's often the best that can be done. ;)
 
The single main feature of Reyes style rendering over a standard approach is the ease with with per-pixel (or sub-pixel) displacement mapping can be integrated.

Per-pixel displacement mapping breaks the coherance that triangle renderers rely on for there speed. The only real way to do per-pixel displacement mapping in a standard renderer IS to slice and dice primitives down to the pixel level.

Reyes rendering simplifys the triangle rasterisor by making all polygons by sliced and diced until they are a solid colour. Rendering a flat (or gouraud) shaded polygon you know is going to be tiny can be done very fast (software or hardware). But doing that loses efficency for when you could have used coherance.

The questions becomes how important is per-pixel displacement maps? If the majority of your rendering will be using them, then Reyes will be more efficient than the existing methods, if on the other hand, you could have used coherance the existing methods would beat the Reyes renderer.

The main issue with just adding a primitive slicer and dicer to a existing architecture is the waste of pixel processing power. Why use 2x2 blocks with texture units if all your rendering is a 1 pixel solid colour?

If existing architectures gain advanced tesselation units that can slice and dice only when required and can render small flat shaded polygons very fast you could easily get the best of both worlds. And thats why unification of the arithemetic units is a good thing, if the per-primitive, per-vertex and per-pixel shaders share units, then you can change from massive per-pixel work (current approach) to a Reyes renderer on the fly (just reallocate the units from the pixel shaders to the primitive and vertex shaders).
 
Thanks ever so much for your reply Dean. You cleared many issues up, particularly regarding the neccessity of making per-surface, per-vertex, and per-fragment calculations run on the same "shader" hardware in order to do any meaningful per-pixel displacement mapping, as otherwise you hit horrible balancing issues. So a current GPU with a strong surface shader would basically choke - well there's always DX10 and its rumored unifed shading model, gotta wait till 2006. :(
 
No megadrive - far from it. It's mostly just an interesting theoretical discussion to see if such a rasterization method would work on an distributed processing architecture such as "CELL." The real answer I suppose relies upon details concerning the main core, rasterizer core, and general system layout we have no way of knowing at this point.
 
So is this the approach of PS3 for certain? a simple rasterizer, for Reyes style rendering?

Who knows ? All we got is that patent, I think next year, we will probably know alot more.

[0137] Other dedicated structures can be established among a group of APUs and their associated sandboxes for processing other types of data. For example, as shown in FIG. 27, a dedicated group of APUs, e.g., APUs 2702, 2708 and 2714, can be established for performing geometric transformations upon three dimensional objects to generate two dimensional display lists. These two dimensional display lists can be further processed (rendered) by other APUs to generate pixel data. To perform this processing, sandboxes are dedicated to APUs 2702, 2708 and 2414 for storing the three dimensional objects and the display lists resulting from the processing of these objects. For example, source sandboxes 2704, 2710 and 2716 are dedicated to storing the three dimensional objects processed by, respectively, APU 2702, APU 2708 and APU 2714. In a similar manner, destination sandboxes 2706, 2712 and 2718 are dedicated to storing the display lists resulting from the processing of these three dimensional objects by, respectively, APU 2702, APU 2708 and APU 2714.

[0138] Coordinating APU 2720 is dedicated to receiving in its local storage the display lists from destination sandboxes 2706, 2712 and 2718. APU 2720 arbitrates among these display lists and sends them to other APUs for the rendering of pixel data.

Does that sound like it to you ?
 
As I read that part of the patent, it could apply equally to either method.

What it seems to imply is that you build a chain of APUs that take as input your 3D mesh data and processes them. It even talks of using APU's to generate pixel data.

So config A might be
Primtive APU
Surface Shader APU
Surface Shader APU
Rasterisor and Pixel APU

Config B might be
Primitive and Vertex APU
Rasterisor APU
Pixel APU
Pixel APU

As each APU is meant to be fairly 'standard' (though I expect some to be connect to texture units etc more than others) you can mix and match as you see fit. Giving you a fairly general unified system (where the APU is the unit of sharing).

The real problem with this model is how to remove pipeline bubbles, if you need to chain APU's together how do you stop massive waste of resources due to working at the speed of the slowest unit in the chain. Its talks about display lists (i.e. each link in the chain creating a DMA buffer) but that might not solve the problems and could eat alot of RAM up.
 
I feel that all this reyes talk will be like the voxel talk with the ps2.

I don't think the ps3 will be able to do this fast enough . Basicly my feelings on the output of the ps3 would be what the top of the line pc would be able to do in 2006 with code writen specificly for that computer. Mabye a little bit better than that . I don't think sony will take a radical new way of rendering things. The curve on the ps2 was bad enough and the curve on the ps3 will be just as bad with out programers haveing to wrestle with learning how to program reyes. Mabye at the end of its life cycle but i still feel it wont have enough power to do this .
 
notAFanB said:
considering what your paying for a top of the line PC in 2006, you make the PS3 seem like a bargain! :)

It is . The ps2 in 2000 was a bargain . Remember its alot cheaper to make a car that just drives instead of a car that drives and floats through water like a boat.
 
jvd said:
notAFanB said:
considering what your paying for a top of the line PC in 2006, you make the PS3 seem like a bargain! :)

It is . The ps2 in 2000 was a bargain . Remember its alot cheaper to make a car that just drives instead of a car that drives and floats through water like a boat.

I'm sure you meant break down on the highway, sinks in the middle of the atlantic and blows up in your face every 5 mins. :LOL:
 
Although I think PS2 can do voxels just fine (386 PCs did them just fine, but there's just no need for them right now :) I pretty much cautiously share JVD's opinions on PS3. I don't see any 2005/6 hardware being capable to render REYES approach fast enough while having really complex game scenes to process. It just seems like reinventing the wheel too much when we have other approach that is proven to work fast, and looks just fine. I mean, just look at those Radeon 9800 or GFFX5900 demos, or the nature scene from latest 3D mark. That almost looks like high quality pre-rendered graphics, and that's being done today
 
I mean, just look at those Radeon 9800 or GFFX5900 demos, or the nature scene from latest 3D mark.

don't want ot appear argumentative but those demos aren't quite high end CG quality (they are too enclosed for a start). can't comment on the nature demo haven't seen/run it yet.

edit:

ah actually some of the 'living toy' demo are quite nice.
 
I don't see any 2005/6 hardware being capable to render REYES approach fast enough while having really complex game scenes to process.

Add me to that list too. Go JVD Go Marc! :D

don't want ot appear argumentative but those demos aren't quite high end CG quality (they are too enclosed for a start).

IMHO, i expect next gen games, to look like those latest DX9 demos(maybe a tad better here and there). Only that we ALSO get more of those hipowered demo models, larger free 3D space to manouver around and well a full functional game.

True 100% FFX FMV is nayyy IMHO.
 
IMHO, i expect next gen games, to look like those latest DX9 demos(maybe a tad better here and there). Only that we ALSO get more of those hipowered demo models, larger free 3D space to manouver around and well a full functional game.

pretty much, I'd love it if the geometry load increased by several orders of magnitude though.
 
Missed this out,

It just seems like reinventing the wheel too much when we have other approach that is proven to work fast, and looks just fine.
And thats what is bothering me about PS3...the rumored CELL unconventional approach just seems so prone to hiccups...


I'd love it if the geometry load increased by several orders of magnitude though
I am not sure how far that several orders will go.

If you look at 3dmark03 games demo, they look pretty normal(D3/HL2 level). And that is already DX9...has there even been any game that look as good as 3dmark01 Nature scene?

DX10/PS3 is expected around 2005/6, will the leap be that humogously huge within the short frame of time?

Only those specialized DX9 demos(and 3Dmark Nature scene), do the graphics look hot. Of course the stuffs onscreen and interactions are very limited. That, and some good more(not toooooo more though), is what to expect of XB2/PS3 base graphics.

All those talk about FF10 FMV is nay yay mayay for me.
 
And thats what is bothering me about PS3...the rumored CELL unconventional approach just seems so prone to hiccups...

the REYES wheel if you will has been around for awhile. CELL has little or nothing to do with that.

the question isn't if the unconventional design is good or not (I counldn't care less) for REYES but whether it is fast enough for comparable REYEs rendering versus the traditional GFX pipeline.

who know maybe Xbox next will be more suited to REYES in the end.
 
chaphack said:
IMHO, i expect next gen games, to look like those latest DX9 demos(maybe a tad better here and there). Only that we ALSO get more of those hipowered demo models, larger free 3D space to manouver around and well a full functional game.

You expect 2005 hardware based on a 65nm proces to look like tech demos running on 2002/2003 hardware on a 130nm process?

I, myself, attempt not to over imagine things and have backed off the REYES bangwagon for the past while. But I can't believe this. From what I've heard of the 3D part Microsoft is looking for, it's going to be quite ahead of what you see in the current round of DX9 accelerators. And that's based on the linear as hell PC-paradigm, as opposed to PS3 which is the unknown wildcard.

If the future consoles are going to be outputting 2003/4 level graphics (eg. STALKER, Max2, 2nd generation Source and Doom Engine) then why even care?
 
Vince said:
If the future consoles are going to be outputting 2003/4 level graphics (eg. STALKER, Max2, 2nd generation Source and Doom Engine) then why even care?



THATS the thing. i expect the overall "look" of console games to get even more distant from the look of PC games. the trend started with PS2, and i expect things to keep progressing that way.
at the end of the day PC's will always have much more RAM than consoles, with poor bandwidth. Consoles have been going the other way. (the old "small buckets and big pipes VS big buckets with small pipes" thing) of course the look of the games will be different.
PS3 and Xnext will have quite a lot of RAM, but it will still be less than what can be put into a PC. at the same time those consoles will have a whole lot more bandwidth and sheer calculation power available to them.

games specifically designed for such different architectures will OF COURSE look different.

so, NO, i do not expect PS3 games to look like hi-end PC games outnow and in the near future, or even PC game sout at the same time.

i dont know why, but when i think about PS3 and Xnext i think about dynamic graphics, not necesseraly DETAILED graphics. they will be detailed, but i think the focus here will be on animation, lighting and physics IMO. at the end of the day all those Flops will not only go into polygons if u know what i mean...
 
Back
Top