Can this SONY patent be the PixelEngine in the PS3's GPU?

Sony only cares about peak performance and raw numbers, it's absolutely true. To think that they will limit the fillrate to 8GP/S just because more would be 'pointless' is wishful thinking.

 

"wishful thinking" .... you make it sound as though people want the PlayStation 3 to be less powerful ............

 

There are people out there who do

But wishful might have been a wrong word I agree, but you get what I mean.

 

I'm not sure if I understood the patent correctly, but it seems to me that a SALP is meant to replace fixed function math units dedicated to things like texture filtering, LOD calculations, blending etc... and that their general purpose nature means that each one can service many different currently hardwired needs. My guess is that performance suffers for a given operation versus a dedicated hardware implementation, but that this is made up for by much better utilization (and flexibility).

 

The two fig. are from two different patent, the setup is different only because the figs have to accents the main purpose of the patent.
The schemas are specific to the patent, and it don't have to be "precise" on the details (the details are actually everything that it's not the subject of the patent).

You were talking about a car game, how much polys you think we can expect on a classical racer next-gen? Around 50Mpps, 100Mpps, 200Mpps or more?

 

IMHO, the GS is just a very early design ( its feature-set freeze apparently pre-dates the EE) made with three things in mind:

Very high polygon counts, resulting in smaller than usual ( for the times ) polygons.

Very high sustained fill-rate ( PSOne's biggest weakness according to some developers, together with the slow Triangle set-up performance ).

Unparalled partially-opaque/transparent polygon processing ( alpha-blending effects ).

I do not see evidence of major features that almost made it in, but were cut out, except maybe the mip-map LOD calculation Hardware.

In the document "Designing and Programming the Emotion Engine", the EE's architects state that thanks to their achievements with the GS ( parallel rendering engine and fast e-DRAM ) they even kind of over-achieved with the Rasterizer speed and that designing the EE the were trying to catch up with that kind of potetnial geometry processign monster.

Let's se what kind of trade-off they made with the PSP before we judge them to hastily .

 

Wouldn't want to put a number on it at this point. Besides I'm not working on a racing game at the moment.

But I will predict that the real limit will be memory, depending on what you think memory sizes will be it'll give you a solid ballpark number.

The real big incrases this time will be in pixel processing that's where you'll see the huge leaps in performance.

 

I have it on pretty good authority that there were a number of "features" cut from the original design at the last minute. The mipmap LOD calc is the most obvious one, but I still can't believe they omitted modulate from the blending modes.

To be honest I'm looking forwards to seeing real details on PS3, but a lot of what I've heard tends to imply that Sony are pretty happy with PS2's architecture and that does frighten me somewhat. It certainly has it's strengths, but in other ways it's totally crippled.

All IMO of course.

 

I'd say roughly around 140 Mpolys/s for every 256 MBs for a racing game like ERPs

 

I disagree - it's going to decrease. If nothing else, it will decrease relative to the number of math ops used, and probably further yet when you have math ops that are comparably fast to using a texture lookup table approximation instead.
Eg. when a vector normalize no longer costs an arm and a leg, using a bunch of cube-lookups for normalizing just stops making sense.

APUs won't work on one pixel/vertex at a time, it makes no sense to do that. Even with the short 4cycle instruction latency on VUs you need to write a pipelined loop with several vertices in flight to get optimal performance, and APU will only have a deeper pipeline, perhaps much deeper then that.
Actually on the subject of working on multiple primitives at a time, that kinda brings the question on how will pixel data to process be submitted to the APUs in the first place. Sounds a little less complex to handle then texture fetches, but still has its set issues I wouldn't be sure about off hand...

The problem is that some might just as well... overinflating fillrate at expense of everything else could very well be making the machine weaker...

 

You hit very good points Fafalada ( about the ability to avoid Cube-maps for things such as Vector Normalization, etc... ), but while I see the ratio of Texture Fetches vs Math Ops decreasing, I still do not see a decrease in use of Texture Ops from what we do now, instead I still see an increase ( which seems to be matched by a possible increase in Texture Fetch latency ) just one that is not as fast as the increase in Math Ops usage.

That increase unfortunately might held the pipeline back and force programmers to write pipelined loops with more and more vertices and primitives in flight which, pardon the pun, is not something primitive.

As food for thought, can you please expand on this point please ?

 

so Graphics Synthesizer design was frozen in 1997?

 

Feature-wise more or less as you need to lock the specs down a bit before you start manufacturing... in early 1999 the EE was already running ( in limited batches I am sure ) so it is not that impossible to think that the GS ( whose design seems to pre-date the EE ) was feature-locked during the year 1997.

 

it does make sense Panajev. as PS2 was possibly going to launch in late 1999 in Japan.

I suppose PS3's GPU is now locked down, if not it will be shortly, assuming a march/spring 06 launch in Japan.

 

This is mine ps3 gpu specs Ithis no way near the offical specs you can quote me when you see my specs.


Visualizer
2ghz(2000 MHz)
32Pixel Pipelines
64 Gigapixels per Second (no texture)
32 Gigatexels per Second
Point, Bilinear, Trilinear, Anisotropic Mip-Map Filtering
Perspective-Correct Texture Mapping
Bump MappingReal time ray tracing *selectively applied*, Global/local illumination, Metropolis light transport, particle flow physics, LOD via dynamic selective subdivision of polygons, Bézier patches, VS driven chroma-matching, inverse/converse kinematics, priori collision, 16x FSAA,shaders, detection, etc etc.
Environment Mapping
128bit HDR rendering for FMV and CG quality graphics.
32MB Quadported Embedded DRAM
256 Gigabytes per Second eDRAM Bandwidth
128 Gigabytes eDRAM Texture Bandwidth
16bpps without effects
1-3bpps with effects

 

Yea but how much RAM does it have?

 

32MB of embedded eDRAM