[darkblu]

Originally Posted by DeanoC

Let I be a register with 3 16 bit tuples identified as 0,1,2
Let A be the address of the index stream
Let B be the address of the vertex stream
Let n be the current triangle number
Load I from n[A]
Load R0 from I.0[B]
Load R1 from I.1[B]
Load R2 from I.2[B]
VertexShade( R0 )
VertexShade( R1 )
VertexShade( R2 )

If we assume a memory latency of 200 cycles (thats very generous...) and that we can process 3+ memory requests at once we have 400 cycles to lose. Load I from n[A] is relatively easy, a predictor will notice the linear read and prefetch 200 cycles early, so when the load happens its hopefully already there. But the Load Rx from I.x[B] is much harder... I can't predict until the index register is filled, so I have to stall the shader for 200 cycles. The only serious option is a thread context switch.

i'm afraid a contex switch may not help either and you'd end up with things "just not working" even on a gpu if your indexing locality throughout the buffer is piss poor. so i'll second marco in this say that you don;t attacj brick walls head-on, you usually try to circumvent them : )

[DeanoC]

I don't deny it can be made to work, but my point is that ease of use just got thrown out the window.

The idea that a CPU is as good as a hardware vertex unit is false IMO. Its may do the job but to get VS3.0 functionality out of a CPU is hard, not because of FLOPs or functionality but memory latency.

As for Cell context switching I'm not convinced, we have to assume the 128K local RAM is shared among contexts (no way it could be saved/restored in time). We still have 2K of register to save/restore, assuming 128 bits per cycle read/write (to L1 cache I suppose) thats 32 cycles (16 per way) unless we have hardware contexts. Thats assuming hardware switching, if its actually software involving a PU interupt, then we have at least 10 cycles latency for the PU to react.

[DeanoC]

Originally Posted by darkblu

i'm afraid a contex switch may not help either and you'd end up with things "just not working" even on a gpu if your indexing locality throughout the buffer is piss poor. so i'll second marco in this say that you don;t attacj brick walls head-on, you usually try to circumvent them : )

At least one architecture has made the problem largely go away (of course there are pathologic cases but for most uses of index buffers and depedent texture reads its copes)

You just needs lots and lots of contexts (and a seriously good memory system). You have to stop thinking like a CPU where 8 contexts would be considered alot.

[Panajev2001a]

Originally Posted by DeanoC

I don't deny it can be made to work, but my point is that ease of use just got thrown out the window.

The idea that a CPU is as good as a hardware vertex unit is false IMO. Its may do the job but to get VS3.0 functionality out of a CPU is hard, not because of FLOPs or functionality but memory latency.

True, but I expect developers to do some pre-packaging work for data and to work-around problems like this while still using a high level graphics library and not going to a PlayStation 2 kind of approach.

[Vince]

Originally Posted by DeanoC

You just needs lots and lots of contexts (and a seriously good memory system). You have to stop thinking like a CPU where 8 contexts would be considered alot.

Like what? 32 or 64 or ... ?

[version]

Originally Posted by DeanoC

I don't deny it can be made to work, but my point is that ease of use just got thrown out the window.

The idea that a CPU is as good as a hardware vertex unit is false IMO. Its may do the job but to get VS3.0 functionality out of a CPU is hard, not because of FLOPs or functionality but memory latency.

TRUE, but APUs run on 4.6 GHZ in cell, while in gpu VS run 800MHZ
cell will faster, in gpu more pixelshader will faster than ati's gpu

sony save transistor count with this method

[V3]

Here's my prediction on what has happened thus far with PS3 development

1. Many people working on PS3 hardware didn't know or expect this to happen.

Companies always have Plan B, C, D, E....

2. The Nvidia's invovlement in PS3 did not start for one or two years before this annoucement. Nvidia's involvement was minimal, nothing more than NV execs talking on a high level to Sony execs, and sending out graphics cards for Sony to evaluate performance. Sony had been evaulating Nvidia tech for a while with zero cash exchanged between both parties. Nvidia didn't change what anything in thier roadmap to accomodate sony up until this annoucement.

That's the case too IMO. As we know, their concentration is on cell, the pixel engine was not something they make a big deal about. Even on the cell patent it was seems to be tacked on.

Anyway if they did something, you would already seen this annoucement earlier.

3. Toshiba was left out in the cold with this change and didn't know it was going to happen. The work on the GS for PS3 will continue, but that graphics hardware won't be used in the PS3.

Toshiba needs to develop their own pixel engine or license them from somewhere to be paired with their own Cell. I doubt they work specifically for PS3, and their exchange on this could be similar to what you said about NVIDIA. They would certainly make somekind of announcement earlier if they did otherwise.

4. One of sony's offices led the charge to make this change, as internally issues were raised with the expected performance of the new GS and/or expected feature set/delivery time frame.

That could be the case. Though it wasn't time frame or feature set, its most likely cost.

5. The nvidia licensing deal will cost Sony more money

Executives will not allow this. Executives will force the engineers to downgrade the spec either from NV part or Cell part to meet the budget. NV license deal was just a better value for money, that's why they chose it over their other options.

If I am speculating, for all we know, Sony owns solution could be superior to NV, but it broke the bank, and downgrading their solution, made NV solution a better performer. That could be why they go with NV.

But Sony would have a fixed range for PS3 budget, that they wouldn't break. That's not a speculation, that's just real world. Sony is building a PS3, not a bridge.

[Panajev2001a]

Look, sometimes budgets are increased if there is the need.

If you planned to spend $35,000 on a BMW 3 Series, but you see that for the model you want is either $1,000 more or a Yugo, you spend the extra $1,000.

According to your reasoning, V3, PSP would have never been launched in Japan this December, they would have delayed the launch as the budget they thought was good for it had to be majorly revised: PSP was pushed through the fabs in December because Son y wanted to hit the launch date even if it would cost them a lot of money (some hardware bugs had been recently fixed and to posh the amount of units through their manufacturing plants costed a premium in that period: the volume was quite low).

Sony will not lose an infinite amount o money on their hardware, but they still can adjust their decisions on how much they plan to lose per unit and how soon after launch these losses can be lowered.

Also, V3... neither Toshiba nor nVIDIA is providing ROPs/Pixel Engines to Sony: both of them were racing for a full GPU contract which includes Shaders, Texture Units, etc...

[V3]

Look, sometimes budgets are increased if there is the need.

If you planned to spend $35,000 on a BMW 3 Series, but you see that for the model you want is either $1,000 more or a Yugo, you spend the extra $1,000.

No, not in this case. Consumers aren't in it to make money , Sony is. Anyway, in business, luxury items are normally the first thing to get cut off. When you can't afford it, you can't afford it. Even the extra $1000.

According to your reasoning, V3, PSP would have never been launched in Japan this December, they would have delayed the launch as the budget they thought was good for it had to be majorly revised: PSP was pushed through the fabs in December because Son y wanted to hit the launch date even if it would cost them a lot of money (some hardware bugs had been recently fixed and to posh the amount of units through their manufacturing plants costed a premium in that period: the volume was quite low).

No, they already budgeted for that. Last minute hardware bugs are emergency, that sometimes happend. But those are bugs.

Sony will not lose an infinite amount o money on their hardware, but they still can adjust their decisions on how much they plan to lose per unit and how soon after launch these losses can be lowered.

No, those ranges are fix when they made the investment, and plans layed out. Options like abandoning Cell, going with Toshiba, NV, ATI, downgrading or upgrading spec, those are not fix though.

Also, V3... neither Toshiba nor nVIDIA is providing ROPs/Pixel Engines to Sony: both of them were racing for a full GPU contract which includes Shaders, Texture Units, etc...

That's what a GPU is isn't ? Pixel Engine is just Sony fancy name.

Look I am not saying PS3 is low budget or anything (its probably higher than the other two for all I know), but they wont increase the cost of it, just for the sake of increase in performance, that's futile in the eye of consumers. If it other features that may be visible, like Blu Ray, maybe they'll make allowance. But going to NV because their solution is expensive and will over budget the project but it gives better performance, thats just silly. They just won't go over budget. There are too much risk involved in doing that.

Like I said before going to NV is definitely the cheapest solution for Sony. Sony Plan A solution broke the bank so not feasible, Plan B look elsewhere for solutions that meet the cost. NV won the contract because it meets their cost, where others might not.

[Panajev2001a]

V3,

It is not going over budget, as you yourself said they already left wiggle room in the budget .

No, those ranges are fix when they made the investment, and plans layed out.

See ?

That's what a GPU is isn't ? Pixel Engine is just Sony fancy name.

If you think that nVIDIA is in to provide only Pixel Engines/ROPs then you are mistaken.

Look at NV40, there is a lot more stuff that makes a GPU than just Pixel Engines/ROPs.

Like I said before going to NV is definitely the cheapest solution for Sony. Sony Plan A solution broke the bank so not feasible, Plan B look elsewhere for solutions that meet the cost. NV won the contract because it meets their cost, where others might not.

That is a fancy way of looking at things: it is not that nVIDIA's solution is superior, it is the most affordable.

Plan A might have not passed budgeting (internal... Visualizer), but I am not aware that plan B (which jad been the official plan for quite a while) went overbudget as the contractors for plan B seemed to be a bit surprised at the coup that nVIDIA managed.

I think nVIDIA solution might have out-performed and out-featured plan B, but Toshiba had the lower cost (being Sony/SCE's partner, having already done work with XDR, Redwood and CELL they could afford to push the envelope without needing too much R&D money [less money than what Sony/SCE deemed as maximum R&D budget for the GPU]).

I also think that nVIDIA might have convinced Sony/SCE because of their change on the royaltes issues: it might have been what Sony/SCE needed (plus a nice big argument by nVIDIA about where the future of GPUs was headed and how the GPU they selected so far was nowhere near, according to nVIDIA of course, what Sony/SCE needed for PlayStation 3) to finally change their minds.

nVIDIA did not even seem a likely winner of the contract in the two weeks before the announcement was made, not at all.

[DeanoC]

Originally Posted by Vince

Like what? 32 or 64 or ... ?

Depends on the memory latency you want to hide...

But they sound reasonable figures for a GPU.

[MfA]

I assume Cell's DMA engines will support scatter/gather. Do the patents back this up?

[nAo]

Originally Posted by MfA

I assume Cell's DMA engines will support scatter/gather. Do the patents back this up?

It seems so:
Method for asynchronous DMA command completion notification

[0019] With the flexibility of this approach, software can group DMA commands in order to manage them. For instance all commands for a particular "task" can be grouped into a single tag group. Alternatively, all DMA "get" commands can be placed in a group separate from an output group comprising all DMA "put" commands. In addition, hardware can provide additional command parallelism or ordering rules with respect to groups. The APU software can verify that a single group has completed, all groups have completed, or a specified set of groups have completed operations. In the current embodiment, tag group status is supplied by the APU reading a data channel, where each bit in the channel represents a tag group status. Bit 0 represents tag group 0 status, bit 1 tag group 1 status, and so on up to bit 31 for tag group 31. A 0 indicates the tag group is complete, a 1 in the corresponding position indicates the tag group has one or more outstanding commands not yet completed.

[0020] There are several variations on the above and a number of advantages associated with the different variations. In one embodiment, the DMA queue 135 can store up to 32 DMA commands. All DMA commands in the DMA queue 135 could have the same tag group number, they could all have different tag group numbers, or anything in between.

Auto prefetch is also supported:
DMA prefetch

The load access pattern generally contains information on the data being transferred. The load access pattern can be used to predict future data transfers and prefetch data to the SL1 cache before the MFCactually requests the data. When the MFC actually requests the data, the MFC does not have to go all the way back to the system memory 212 to retrieve the data. Instead, the MFCaccesses the SL1 cache to retrieve the data and transfer the data to the local store

So a CELL CPU should support scatter and gather (with an authomatic prefetch mechanism) DMA operations, up to 32 operations at the same time. DMA ops can be grouped and prioritized and the SPU can check for single o groups completitions.

ciao,
Marco

[j^aws]

Originally Posted by Panajev2001a

Explain how.

Vertex Shading done by units like the SPUs/APUs or like the VUs in the EE can be done very effectively, while Pixel Shading might not (nVIDIA does not believe in using the same hardware for both and for now they might be right).

Splitting the VS and PS work between the CPU and the GPU is what some PS heavvy games on Xbox 2/Xenon will do: all the unified shading units would be dedicated to Pixel Shading work and Vertex Shading would then be done on the enhanced VMX units of the Xbox 2/Xenon's CPU.

I guess you've read the rest of my post for me not to explain it again!

On a side note, what you've posted above would've been a natural question to ask after reading 'point 3' of my explanation which would lead back to 'point 1' again and imply the GPU should be CELL based. :P

Originally Posted by Panajev2001a

Ideally that is what they would want, which is why I talked about the direction for CELL 2.0 for example. IBM, with CELL, sees a point in pushing towards the same direction ATI is pushing with unified shading hardware.

Unified graphics hardware != CELL.

By CELL 2.0, I presume you mean what CELL 1.0 should be from the patents? I.e. Run everything, all threads, scalar and vector, be it graphics or non-graphics threads in a distributed, broadband environment under a unified ISA?

IMHO, if they can't achieve that with CELL 1.0, then the architecture is just a glorified PS2 EE that uses distributed processing. The main addition would be for the VU equivalent S|APUs to work independantly. Don't get me wrong, this is still not bad, it's just a natural progression of tech. But it's not the vision laid out in the patents.

This is not the way nVIDIA sees things, not for theshort-to-medium term at least.

I disagree. I'm not sure what timescales you mean by short/medium term. But listening to that Huang interview/webcast with Morgan Stanley, he see's the graphics/media processor of the future as a programmable DSP. The CELL chip is basically a programmble DSP. The ATI R500 is basically a programmble DSP. I know on the VS/PS level ATI are looking at identical units but NV are differing on those being specialised. But this should not stop VS threads running on PS units and PS threads running on VS units.

In fact I see the NV approach capitalising on CELL and complemeting as mentioned in my other threads. If NV have two sets of shader units that are specilaised and optimised for their respective VS and PS parts, then for a future PCI-E PC's and PS3 IC's, we would see them employed ,

PC,

[CPU]<=>[VS<=>PS]

PS3,

[CELL]<=>[PS]


CELL Workstations perhaps,

[CELL<=>PS]

It will be interesting to see if they'll use Cg (very likely) and whether it will compile and run shaders on BOTH the CELL CPU and the NV GPU. It would make sense if they did. In my eyes, running Cg shaders would just become 'software renderring' executing on 'specilaised' SIMD hardware.

[one]

Originally Posted by Jaws

It will be interesting to see if they'll use Cg (very likely) and whether it will compile and run shaders on BOTH the CELL CPU and the NV GPU. It would make sense if they did. In my eyes, running Cg shaders would just become 'software renderring' executing on 'specilaised' SIMD hardware.

SCEA was hiring engineers for new shader compiler development... where does it fit in?

[darkblu]

Originally Posted by one

SCEA was hiring engineers for new shader compiler development... where does it fit in?

it fits in as in 'they just hired some' ; )

[Panajev2001a]

IMHO, if they can't achieve that with CELL 1.0, then the architecture is just a glorified PS2 EE that uses distributed processing. The main addition would be for the VU equivalent S|APUs to work independantly. Don't get me wrong, this is still not bad, it's just a natural progression of tech. But it's not the vision laid out in the patents.

Yes, CELL 2.0 being the full vision of the patents and more of course (the road does not stop there).

I am not saying that CELL 2.0 is a new ISA, a totally different road.

Think CELL 1.0 as being the implementation of CELL as you will see in the WorkStation and in PlayStation 3 and CELL 2.0 to be a later implementation.

Like Treebeard would say, don't be so hasty master Hobbit .

The vision laid out in the patents was natural progression of existing technologies and ideas that have been theorized 10-15 or even 20 years ago in laboratory environments.

I disagree with saying that Sony did not try to experiment how you could build an entire system made of CELL ICs and few sections of custom logic/small dedicated ICs, but Sony/SCE is in the business of making of PlayStation 3 and the CELL WorkStations the best possible products they can make, not proofs of concepts.

On this I agree with V3, Sony/SCE does not make money prooving the a concept lke "use CELL for everything" works in a high volume machine if this means monumental losses.

This does not mean the architecture is not good: wait to see CELL based products like hopefully some renderfarms.

Maybe some customer will ask IBM and Sony to deliver a new renderfarm and toolset chain or maybe Sony ImageWorks itself willl ask for a few million dollars worth of a system and with that kind of budget they might decide to push CELL far enough to allow for something like the full Broadband Engine and its Visualizer chip.

I believe we will see that once Sony/SCE starts PlayStation 4 R&D, just like we saw the GSCube-32 and GSCube-64 machines.

I know on the VS/PS level ATI are looking at identical units but NV are differing on those being specialised. But this should not stop VS threads running on PS units and PS threads running on VS units.

It does as it would be really inefficient: your example of PS threads running on VS units is exactly what nVIDIA says they do not want right now as the unit would not be used optimally at all.

PC,

[CPU]<=>[VS<=>PS]

PS3,

[CELL]<=>[PS]

In order to share data and wor together the CELL CPU and the nVIDIA GPU do not need to run the same code, run the same Apulets: they just need to agee on what kind of interfaces you use to communicate between the two. More like a "you know if I leave this quad-word here that it is a Vertex because blah+blah is written at memory location blah-blah-blah, etc...".

[Mythos]

Would'nt Cell 1.0 be 90NM and 2.0 Cell on 65NM?

Some quotes in regards to Nvidia and Sony rumors from CNN in 2003...

The reality is nVidia is not sitting in a vacuum," said Erach Desai, an analyst with American Technology Research. "They are in discussions with Sony for the PS3."

They realize, I think, that they cannot do it all," said Desai. "I have checked with a couple of very seasoned executives ... and the strong impression is that there is interest from Sony and interest from nVidia."

"We've always said we'd be happy to be in any game console," nVidia spokesperson Carrie Cowan told me recently.

"I would probably characterize it as a less than 50 percent chance that they win PS3," said Michael McConnell of Pacific Crest Securities. "However, we have talked with Sony and their take on it is they're considering an external vendor as well as an internal solution. So you can't rule it out, but you definitely can't say it's a sure thing."[/b]

[Vince]

Originally Posted by Mythos

Would'nt Cell 1.0 be 90NM and 2.0 Cell on 65NM?

Pana has been pre-gaming for tomorrow all week, don't pay attention to his rants on v1.0 and v2.0. :P

But yes, there are 90nm Cell processors and there will be 65nm fabricated ones as well. No, they don't coincide with his comments.

[Panajev2001a]

Originally Posted by Vince

Pana has been pre-gaming for tomorrow all week, don't pay attention to his rants on v1.0 and v2.0. :P

:lol

Vince, I did explain what I meant.

I do not think PlayStation 3 will fully go the way the first patent showed: namely a wholly CELL based system with a CELL based Visualizer.

One day we might see CELL based set-ups going the way ATI seems to be going: an extension of the Visualizer concept. A single IC doing both general purpose processing as well as graphics processing with a sea of computational blocks exchanging data with a seoarate sea of dedicated silicon blocks (TMUs, ROPs, etc...).

[Megadrive1988]

Panajev, well, I hope that Sony fully funds smaller companies like the one that makes the SAARC raytracing processors. for Playstation4. I'm hopeful since Sony was willing to go with Nvidia for the PS3 GPU or at least a very very significant portion of it.


PS2 CPU: Emotion Engine
PS3 CPU: Broadband Engine (?)

I hope PS4 CPU: RayTracing Engine 8)

[Panajev2001a]

I am sorry, but I want the REYES Engine and always will .

Renderman forever .

[Megadrive1988]

can't we somehow have REYES, Raytracing & GI together ?

[Dave Baumann]

Originally Posted by Panajev2001a

I do not think PlayStation 3 will fully go the way the first patent showed: namely a wholly CELL based system with a CELL based Visualizer.

Are we only just coming to this realisation?

[Panajev2001a]

Originally Posted by DaveBaumann

Are we only just coming to this realisation?

No, I am repeating what I have been saying for quite a bit actually.

The GPU was not going to be CELL based like the Visualizer even when the other contractor had the contract and I do not expect this to be different with nVIDIA.