[3dilettante]

Originally Posted by rpg.314

>4 years to make a new uarch? WTH are they trying to do with BD? re-implement x86 from scratch?

CPUs, particularly new designs that have the complexity of a multicore high-performance OoO x86, do take that long.
It's not clear just how long elements of Bulldozer have been in development, as various x86 projects to succeed K8 have been cancelled, and the internal project code-named Bulldozer may have been restarted or had its codename transfered at some point.

However, it's not exactly like GPUs are as fleet of foot as some may think. The upper bounds of GPU gestation periods overlap pretty well with the lower bounds of CPU design periods as of late.

[Jawed]

Originally Posted by rpg.314

>4 years to make a new uarch? WTH are they trying to do with BD? re-implement x86 from scratch?

I really don't care much about x86, it's boring (except Larrabee, but that's only because it hasn't arrived, once it's here it'll be even more boring). But hasn't AMD junked at least two designs since K8?

What troubles do you foresee with this kind of coupling?

The GPU would munch through L2, starving the core, which has other things to do. Better to stream through L2 into L3 for the GPU-SIMD to use, I suspect.

Also, with module-local, you can only maximise GPU-SIMD usage by pushing work through all the modules, enforcing fine-grained tasks when only a coarse-grained (single host thread) task is required.

The idea is that by putting a simd engine next to a full blown x86 core, the gpu kernels can be programmed to call back x86 code when it is finished, and have it's return data siting right there. Or vice versa, with the x86 setting up launch parameters in the L2 and then issuing kernel calls. IOW, reduce data latency between cpu and gpu.

Going through L3 seems better to me. The difference in latency won't break your balls. These are still OpenCL kernels, they're not a few in-thread SSE instructions you're trying to speed-up.

Personally, I am looking out for kernel launch granularity to reduce from a bunch of work groups to just one work group.

Going to be hard to avoid having at least 1 workgroup per SIMD.

With recursive block calls, ie work groups calling work groups (same size of course) and with ability to launch x86 functions at the end of workgroups, it will lead to better synergy between cpu and gpu code.

Do things need to be more tangled than the fairly clean OpenCL event model?

Power management is another plus. With increasingly finer granularity of core level power gating, the same infrastructure can be reused for gpu power gating.

I don't see how that's affected by the tightness of coupling.

Jawed

[entity279]

Originally Posted by rpg.314

>4 years to make a new uarch? WTH are they trying to do with BD? re-implement x86 from scratch?

Any way, with >4 years in the oven, and a new gpu being built along side, it seems reasonable to assume that there has been a lot of influence both ways.
.

If i recall correctly, I can remember Bulldozer being talked about even at the beginnings of Intel Core era. It has been pushed back ever since.

Back in the days, AMD had also delayed the Hammer architecture for quite a while.

Edit: oups, 3dilettante already "produced" a better alternative to my post; yeah BD may have been just a name

[Jawed]

http://www.semiaccurate.com/forums/s...5&postcount=20

[nutball]

Who's doing 28nm? and when?

*whistles*

[Squilliam]

Originally Posted by nutball

Who's doing 28nm? and when?

*whistles*

Global Foundries 28nm??? He does say that in his lil snippet.

Now if we go by the piece in the Industry forums, whose party are the going to try and show up for on time? Could this be the first ever time they release the parts for laptops before they get the mainline desktop parts out the door? Noone sneezes at a 140mm^2 Juniper replacement with better power/performance in the laptop space and thats a pretty good pipe cleaner as well.

Does anyone see any reason why they shouldn't release from the middle and work up/downwards? Say 66xx part first followed by 64xx then 67xx and finally 68xx/69xx and bringing up the rear the IGP and Fusion solutions? Laptops are bigger now than the desktop markets and time to market for this segement is paramount given the lead time for manufacturing? A 66xx would be an excellent first OEM part, IMO!

[digitalwanderer]

Originally Posted by nutball

Who's doing 28nm? and when?

*whistles*

[rpg.314]

Originally Posted by Jawed

http://www.semiaccurate.com/forums/s...5&postcount=20

• A new architecture
• 28 nm
• 2H10

My head is spinning.

PS: All of it assumes, of course, that GF's 28 nm has an easier time (with sensible yields and reasonable volume) taking birth than TSMC's 40nm, which compared favorably with a greek tragedy.

[rpg.314]

Originally Posted by Jawed

I really don't care much about x86, it's boring (except Larrabee, but that's only because it hasn't arrived, once it's here it'll be even more boring). But hasn't AMD junked at least two designs since K8?

I don't care about x86 either. I have no idea about the mess AMD has made internally. I always thought BD began after Barcelona was finished.

The GPU would munch through L2, starving the core, which has other things to do. Better to stream through L2 into L3 for the GPU-SIMD to use, I suspect.

Yeah, the gpu will eat up the L2. But if you share via L3, it'll eat up L3 too. The only way out seems to be to put an upper limit on the amount of cache the gpu can hog. And if you are gonna cap L3 usage, might as well put it together with a module and cap L2 uage as well.

Also, with module-local, you can only maximise GPU-SIMD usage by pushing work through all the modules, enforcing fine-grained tasks when only a coarse-grained (single host thread) task is required.

Good point, this approach will need some kind of across module load balancer to throw work groups at other, free simd's. Probably better off implmented in sw with some hw support.

Going through L3 seems better to me. The difference in latency won't break your balls. These are still OpenCL kernels, they're not a few in-thread SSE instructions you're trying to speed-up.


Going to be hard to avoid having at least 1 workgroup per SIMD.


Do things need to be more tangled than the fairly clean OpenCL event model?


I don't see how that's affected by the tightness of coupling.

Jawed

Sharing via L3 means it is no better (architecturally at least) compared to Llano though they may very well g down that road. The overall direction is to make it system level programmable, instead of using the gpu as a device visible to apps. I feel they'll take their cues (both regarding what to do and what not do) from Cell's execution model (definitely not it's programming model though ) which is amenable to providing a JIT level interface and allows flexible communication/signal patterns between the cpu and gpu cores.

[tannat]

"Lurkermode off"

What if Ati has been quite happy with being first to the table with HD5xxx and 40 nm in spite of the problems of TSCM. They are not that afraid of (and quite good at) being early adopters to a smaller process node.

It has several advantages:

1) They can be agressive while playing safe by double up with GF and TSCM making two layouts for the chip. Minimizing risks of a repeat of the problematic 40 nm adoption.

2)Whatever first fab ready with 28 nm out makes launch date. If glofo is delayed TSCM may come through and vv

3) If TSCM and glofo are ready quite simultaneously there will be less constraints of cards at launch since two 28 nm lines are used to satisfy demand. Even if early cypress yields wer low, say in 30-40% Ati may have realized that one line operating att 90% yield would not have been enough for early demand.

This could have been clear while still in negotiation with TSCM and glofo about NI. They just went for both.

[Shtal]

Hi!

This might be true that ATI R9xx GPU possibly be released second half of 2010 on 28nm or 32nm, right here press release from http://www.globalfoundries.com/newsr...90930_GSA.aspx dated back September 30th, 2009 - it talks about that volume production of 32-nm super high performance process (SOI+HKMG) will begin in 2H 2010, while volume production of 28-nm high performance process (HKMG) will as well start in 2H 2010. Here is another http://www.globalfoundries.com/newsr.../20100215.aspx it says how high-end ARM designs will be out in 2H 2010 using both Global foundries' 28-nm high performance HKMG and 28-nm super low power HKMG process nodes. So, it looks like it is defiantly is entirely feasible for ATI to launch the "Northern Islands" generation on Global foundries 28-nm process this year; no doubt supplies will be constrained for first few months, but it wouldn't be any worse than what ATI went through last year with TSMC's 40-nm process.

[Tahir2]

I thought GloFlo and TSMC are going straight to 28nm?

[dizietsma]

I wonder if moving to GF is a result of the problems with the problems with 40nm from Taiwan fab? Mind you AMD when it owned the foundry didn't have massive success going to new process nodes, 65nm for instance....

[rpg.314]

http://www.semiaccurate.com/forums/s...5&postcount=33


So sometime October, November then? I wonder how many chips are coming in 2010.

[Shtal]

ATI's next gen DX11 chip is 40nm http://www.fudzilla.com/content/view/17782/1/

I don't believe Northern Islands will be on 40nm since it will increase die size and it is against their "sweet spot" policy.

[rpg.314]

If fudo is right, then may be NI is Evergreen+2.

But then it flies in the face of what Charlie is claiming and what Anand said.

All in all, the only known is that some new chips are coming later this year.

[Mindfury]

Maybe ATI will try new architecture on 40nm,make a chip slightly bigger than Cypress.When 28nm is ready,double everything to make a monster chip.

[Silent_Buddha]

Originally Posted by tannat

"Lurkermode off"

What if Ati has been quite happy with being first to the table with HD5xxx and 40 nm in spite of the problems of TSCM. They are not that afraid of (and quite good at) being early adopters to a smaller process node.

It has several advantages:

1) They can be agressive while playing safe by double up with GF and TSCM making two layouts for the chip. Minimizing risks of a repeat of the problematic 40 nm adoption.

2)Whatever first fab ready with 28 nm out makes launch date. If glofo is delayed TSCM may come through and vv

3) If TSCM and glofo are ready quite simultaneously there will be less constraints of cards at launch since two 28 nm lines are used to satisfy demand. Even if early cypress yields wer low, say in 30-40% Ati may have realized that one line operating att 90% yield would not have been enough for early demand.

This could have been clear while still in negotiation with TSCM and glofo about NI. They just went for both.

Well HD 58xx (Cypress) benefitted from the experience they had on 40 nm with Rv740. That allowed them to avoid many of the problems that Rv740 ran into (going by Anandtech's article), thus allowing Cypress to have less problems than they might otherwise have had.

I'd believe the 28 nm for N.I. more if ATI releases something before then to "test" the process first to see if there's any unexpected problems they might run into, and thus allow them to better adjust N.I. for those potential problems.

Regards,
SB

[Squilliam]

Originally Posted by Silent_Buddha

Well HD 58xx (Cypress) benefitted from the experience they had on 40 nm with Rv740. That allowed them to avoid many of the problems that Rv740 ran into (going by Anandtech's article), thus allowing Cypress to have less problems than they might otherwise have had.

I'd believe the 28 nm for N.I. more if ATI releases something before then to "test" the process first to see if there's any unexpected problems they might run into, and thus allow them to better adjust N.I. for those potential problems.

Regards,
SB

Wouldn't it be more practical to switch foundries with a new chip than it would be productive to simply port a chip from one to the other? Also theres the thing that they don't want to telegraph their intentions to Nvidia/TSMC whom both have a lot to lose in an effective transition. If they have a lot of leeway in terms of time it seems to make sense for them to jump in with both feet and work it out later if they know they have plenty of time before TSMC makes the switch (as they should as a client of both). Thats the flip side to what you wrote. Im a chronic contradictor, whats a GPU?

[eastmen]

Originally Posted by Silent_Buddha

Well HD 58xx (Cypress) benefitted from the experience they had on 40 nm with Rv740. That allowed them to avoid many of the problems that Rv740 ran into (going by Anandtech's article), thus allowing Cypress to have less problems than they might otherwise have had.

I'd believe the 28 nm for N.I. more if ATI releases something before then to "test" the process first to see if there's any unexpected problems they might run into, and thus allow them to better adjust N.I. for those potential problems.

Regards,
SB

For all we know N.I may have already tapped out and they may be testing it already. I'm going to think they know alot more about GF's processes than TMSC's.

Mabye the first chip we will see is early summer cypress on 28nm to test the waters. They'd be able to up the clocks while lowing power , most likely be able to refresh the 5970 also. 1.2ghz on a 5890 and 1ghz on a 5990 would be a good refresh product .

[Silent_Buddha]

Originally Posted by Squilliam

Wouldn't it be more practical to switch foundries with a new chip than it would be productive to simply port a chip from one to the other? Also theres the thing that they don't want to telegraph their intentions to Nvidia/TSMC whom both have a lot to lose in an effective transition. If they have a lot of leeway in terms of time it seems to make sense for them to jump in with both feet and work it out later if they know they have plenty of time before TSMC makes the switch (as they should as a client of both). Thats the flip side to what you wrote. Im a chronic contradictor, whats a GPU?

Switching your entire new line would be extremely risky if you have nothing prior to indicate whether the transition will go well or go horribly or anything in between.

Add to that if 28 nm is delayed for some reason, you've basically blown an entire product cycle. The potential to have a longer delay than Fermi would be great.

Then again, with high risk there's also high reward. If it does go smoothly, 28 nm would be a huge advantage (in theory). Just like if 40nm had gone well with Fermi, it would have been a huge counter to Cypress.

But really, it's like an all or nothing bet without something to show its viability or expose any problems. Not to mention crossing your fingers and hoping the process node doesn't get delayed.

Regards,
SB

[tannat]

Originally Posted by Silent_Buddha

Well HD 58xx (Cypress) benefitted from the experience they had on 40 nm with Rv740. That allowed them to avoid many of the problems that Rv740 ran into (going by Anandtech's article), thus allowing Cypress to have less problems than they might otherwise have had.

I'd believe the 28 nm for N.I. more if ATI releases something before then to "test" the process first to see if there's any unexpected problems they might run into, and thus allow them to better adjust N.I. for those potential problems.

Regards,
SB

Yes, a Rv8xx chip on 28 nm would be a strong indication of 28 nm.

Going GloFo and TSMC in parallel may be additionally rewarding if they want to continue launch several die size versions within a short time frame as with Rv8xx.

It would also be an incentive for TSMC to be on the toes and not be sloppy with tool calibrations. Also, if Ati go through the effort of making separate layouts and prework on both companies 28 nm processes, then SoI on GloFo and bulk Si on TSMC may not be a huge additional step.

Rv8xx has been quite successful, this double approach may possibly mitigate most problems seen with Rv8xx launch with while enabling Ati to jump on the new node for next architecture safely.

[neliz]

the next RV8xx will still be on 40nm and the chances that RV9xx will go to GloFo seem to be slim.

[Psycho]

"The next RV8xx"?

[neliz]

Originally Posted by Psycho

"The next RV8xx"?

Hecatoncheires, the RV8xx refresh. i.e the part nv doesn't compare GF100 to when they claim "worlds fastest graphics solution."