Intels Larrabee Discreet Graphics croaked

[formulav8]

Looks like Intel is killing its Larrabee Add-in GFX plans. I'm sure many were expecting this.

http://www.anandtech.com/show/3738/...t-bring-a-discrete-graphics-product-to-market

Edit: I should probably put at least they won't have anything in the near future. But really that means not anytime soon, if ever, so don't hold your breath...

 

[Genx87]

I never understood how they planned to compete with Nvidia and ATI. The product cycles are just too short for an Intel business plan. Now it sounds like they are hoping to cash in on the HPC front. I am assuming this will officially kill off Itanic. But how do they plan to market this without killing their xeon line in that market?

Plus they will still have to contend with an nvidia product cycle where the processing power will increase by multiples every 18 months.

 

[theeedude]

 

[formulav8]

Yuk Yuk Yuk

 

[solofly]

Chicken shit Intel...

 

[AstroManLuca]

Never really understood Intel's position. Why wouldn't they be perfectly content selling their horrible integrated graphics to companies for use in cheap laptops and desktops?

Based on their track record I never expected them to be able to field anything of value, and it looks like that ended up being the case.

 

[Voo]

Who really thinks that Intel's big plan for larabee was ever the discreete GPU market? Why should they try to compete in a shrinking market where there are already two big players?

As long as their IGPs are good enough for HD video decoding why bother, there are much more interesting areas like HPC or servers in general where their competitors don't have years and years of experience and a large marketshare to build on. Also they should be more worried about AMD's fusion instead of Atis/Nvidias GPUs, it's not like a GPU can harm their business in many ways (well except tesla..)

 

[ZimZum]

Never made sense to begin with. Discreet graphics are a fairly niche market especially from company the size of Intel's prospective. One thats already dominated by 2 well established long standing brands. Who both have patents on pretty much everything pertaining to GPU's. Seems like more trouble than its worth.

 

[Keysplayr]

Intel taking notice to GPU parallel processing and how it poses a very real threat to Intels HPC business and the potential of losing server superiority is probably what spawned the Larrabee concept in the first place. Larrabee was just Intels "first try". Never count them out though. After all, they NEED to do something, and I'm sure they will. But they need a different approach apparently. Probably already has several parallel projects going at the same time. Larrabee seemed the most promising at first, hence all the press and limelight, but I'm sure there are other things on a couple of other burners that are not public.

 

[Keysplayr]

Never made sense to begin with. Discreet graphics are a fairly niche market especially from company the size of Intel's prospective. One thats already dominated by 2 well established long standing brands. Who both have patents on pretty much everything pertaining to GPU's. Seems like more trouble than its worth.

Between you and I, I don't think Larrabee was ever about graphics. It's the parallel processing. I mean, it would probably be sort of capable at a very low graphics level, but from the public showings and demos, it really looked abysmal.

 

[busydude]

Intel taking notice to GPU parallel processing and how it poses a very real threat to Intels HPC business and the potential of losing server superiority is probably what spawned the Larrabee concept in the first place. Larrabee was just Intels "first try". Never count them out though. After all, they NEED to do something, and I'm sure they will. But they need a different approach apparently. Probably already has several parallel projects going at the same time. Larrabee seemed the most promising at first, hence all the press and limelight, but I'm sure there are other things on a couple of other burners that are not public.

Intel need to move beyond x86. Whats interesting is that ATI/NVIDIA GPU's are able to execute x86 faster than Intel's CPU's and we are not talking 30%-40%, we are talking many magnitudes faster.

 

[Keysplayr]

Intel need to move beyond x86. Whats interesting is that ATI/NVIDIA GPU's are able to execute x86 faster than Intel's CPU's and we are not talking 30%-40%, we are talking many magnitudes faster.

GPU's can run x86 code? I don't think so. If it is possible, it has to be compiled with Stream or CUDA dev kits and libraries.

 

[v8envy]

Intel need to move beyond x86. Whats interesting is that ATI/NVIDIA GPU's are able to execute x86 faster than Intel's CPU's and we are not talking 30%-40%, we are talking many magnitudes faster.

How is that possible? Branchy code doesn't run very well on GPUs. Even *if* an x86 emulator ran on a GPU in the first place.

A GPU running x86 more efficiently than an x86 processor would violate the basic laws of thermodynamics. An emulated CPU will never be as efficient as the native one because when you do more work it takes more energy. To outperform an i7 by an order of magnitude (to say nothing of several orders of magnitude) we're talking a power budget of at least an order of magnitude more.

Now, for highly parallel, non-branching workloads you betcha -- GPUs all the way.

 

[busydude]

GPU's can run x86 code? I don't think so. If it is possible, it has to be compiled with Stream or CUDA dev kits and libraries.

Yeah, Thats what NVIDIA is trying to do right entering the server market?

 

[v8envy]

They're not entering the server market, those GPU compute cards (and previous generation's versions) are for very specific scientific computing needs. They've been selling into that market for quite a while now.

 

[busydude]

How is that possible? Branchy code doesn't run very well on GPUs. Even *if* an x86 emulator ran on a GPU in the first place. A GPU running x86 more efficiently than an x86 processor would violate the basic laws of thermodynamics. An emulated CPU will never be as efficient as the native one because when you do more work it takes more energy. To outperform an i7 by an order of magnitude (to say nothing of several orders of magnitude) we're talking a power budget of at least an order of magnitude more. Now, for highly parallel, non-branching workloads you betcha -- GPUs all the way. __________________

Ahh, I see. Back in 2008, I read that Nvidia was ready with an x86 CUDA compiler I didn't care to follow up but did it ever happen?

Link

Nvidia says CUDA code can run on any multi-core platform. To prove its point, the company is about to roll out an x86 CUDA compiler. Our sources indicate that the software will be available as a beta by the time the company’s tradeshow Nvision08 opens its doors. In that case, CUDA could be considered to be much more flexible than Larrabee, as it will support x86 as well as GPUs (and possibly even AMD/ATI GPUs.) Even if Intel often describes x86 programming as the root of all programming, the company will have to realize that CUDA may have an edge at this point. The question will be how well CUDA code will run on x86 processors.

Sorry for the confusion guys and derailing this thread with my lack of knowledge. But I learned at least something.

 

[taltamir]

Who really thinks that Intel's big plan for larabee was ever the discreete GPU market? Why should they try to compete in a shrinking market where there are already two big players?

As long as their IGPs are good enough for HD video decoding why bother, there are much more interesting areas like HPC or servers in general where their competitors don't have years and years of experience and a large marketshare to build on. Also they should be more worried about AMD's fusion instead of Atis/Nvidias GPUs, it's not like a GPU can harm their business in many ways (well except tesla..)

intels version of fusion is called sandy bridge, and it will arrive Q3 this year (was originally scheduled for later, but intel recently announced it was far ahead of schedule and will be ready Q3 this year).
AMD's has been pushed back to an arbitrary date in the far far future.

 

[lopri]

I used to say this but will repeat: Intel never really wanted Larrabee to take off. They wanted to generate just enough buzz of it to kill/slow the development of GPGPU such as CUDA and OpenCL. Only thing that's amusing to me is how it played out on gullible journalists.

 

[HurleyBird]

GPU's can run x86 code? I don't think so. If it is possible, it has to be compiled with Stream or CUDA dev kits and libraries.

No, current GPUs can't 'run' x86 code. Neither can modern CPUs from AMD or Intel, or any other modern processor for that matter. The internal language in AMD processors is very RISC/ALPHA-like. x86 code is not 'run', it is translated to something that the CPU *is* able to run. You can translate x86 code to basically any internal architecture, although some design philosophies will take a very heavy hit in translation. That's why Itanium has horrible performance in x86 mode, because VLIW designs rely on the compiler to run efficiently, and standard x86 code is not compiled specifically to run well on a unique VLIW architecture.

Funnily enough, Fermi and Cypress make a good comparison to x86 processors and Itanium. Fermi architecture should be able to 'run' x86 code relatively well, except that it's missing translation hardware due to Nvidia's lack of a license. If AMD were to modify Cypress to 'run' x86, it would perform abysmally much the same as Itanium. In terms of compute, it is easier to make fast running code on a Fermi-like architecture, but given a perfect or near-perfect compiler, a VLIW architecture like cypress could run much faster. Of course, this is unlikely to be the case given that AMD can't put as much resources into the software side of Cypress as Intel can with Itanium.

The way I see it, going with a VLIW shader core has allowed AMD to greatly surpass Nvidia in terms of theoretical shader performance, and has allowed them to extract more real world shading performance (in games at least)/mm2 -- even the most ardent Nvidia supporter should be able to agree on that much. What I don't get then, is why AMD is supposedly abandoning such a game winning strategy in Northern Islands. The way I see it, there are two distinct possibilities: One is that the rumors are false and NI will stay a VLIW design. The other possibility is that AMD is looking to pave the way for x86 compatible GPUs, basically their own version of Larrabee except instead of taking existing x86 solutions and turning them into GPUs, they are taking existing GPU tech and turning it into an x86 machine.

 

[GotNoRice]

Intel already has more market-share than ATI and Nvidia combined due to their integrated graphics processors. I'm sure the lessons they learned with larrabee won't be put to waste, they have a massive R & D department.

Also it might seem like they've failed with larrabee but I don't recall them actually ever announcing any kind of release date or even any of their formal plans in regards to larrabee. It seems like all of the expectations people had came from journalists with spotty information.

 

[BenSkywalker]

How is that possible? Branchy code doesn't run very well on GPUs.

Branchy code wouldn't have run well on Larrabee either, it's cores were P56- in order cores. x86 by default is no better at handling branching then GPUs, it is the current chip architectures that make it so they don't roll over and die.

A GPU running x86 more efficiently than an x86 processor would violate the basic laws of thermodynamics. An emulated CPU will never be as efficient as the native one because when you do more work it takes more energy.

Every current "x86 Processosr" don't execute x86 code natively. The difference is decode hardware- i7 has it- GPUs don't. Your theory about it violating the laws of thermodynamics is seriously misplaced as you are assuming that there is an equal workload "emulating" x86 versus executing it natively. The reality is that x86 was a travesty in terms of high performance execution and emulating its' functions using a more RISC like architecture was less overall work then executing the calls natively- this is why both Intel and AMD both emulate x86 today.

The way I see it, going with a VLIW shader core has allowed AMD to greatly surpass Nvidia in terms of theoretical shader performance, and has allowed them to extract more real world shading performance (in games at least)/mm2 -- even the most ardent Nvidia supporter should be able to agree on that much.

Using a Vec4+1 layout gives great theoretical peaks, not quite so great in real world useage. You can attribute that to a VLIW setup if you'd like, but it has more to do with how the functional units are laid out then the overal design philosophy of the chip. Changing how many ops you need for ideal ILP optimization can significantly adjust the level of real world benefit to be had using a VLIW setup.

 

[taltamir]

I used to say this but will repeat: Intel never really wanted Larrabee to take off. They wanted to generate just enough buzz of it to kill/slow the development of GPGPU such as CUDA and OpenCL. Only thing that's amusing to me is how it played out on gullible journalists.

that is a very good point. the mere mention of larabee hurt nvidia and AMD's implementation of GPGPU

 

[HurleyBird]

Using a Vec4+1 layout gives great theoretical peaks, not quite so great in real world useage. You can attribute that to a VLIW setup if you'd like, but it has more to do with how the functional units are laid out then the overal design philosophy of the chip. Changing how many ops you need for ideal ILP optimization can significantly adjust the level of real world benefit to be had using a VLIW setup.

No argument there, but I think that Cypress gets its huge theoretical throughput by a mix of Vec4+1 and VLIW. If AMD were to change Cypress to a fully superscaler Vec 4+1 implementation the shaders would be considerably larger. In essence you would be able to fit a smaller number of more efficient shaders in the same mm2. Theoretical performance would be lower, but efficiency would be increased. Poorly optimized code would run much faster, and highly optimized code not so much. Vs. Fermi you would have higer instruction level parallelism and lower thread level parallelism, which goes without saying when you have fewer superscaler cores vs. a greater number of scaler ones.

If AMD does abandon VLIW in NI but stays with a Vec 4+1 layout, it will be interesting how the new cores compare with the old ones on a per core basis. My guess would be a very small increase in theoretical computer power, a larger increase in most compute apps except for those that are already very well optimized, and for game performance I have no clue, although the trend seems to be going lower. (GT200 and R770 > Fermi and Cypress in that area). On the other hand, future games may be more vertex/tesselation bound and it may not matter as much.

 

[VirtualLarry]

Ahh, I see. Back in 2008, I read that Nvidia was ready with an x86 CUDA compiler I didn't care to follow up but did it ever happen?

Link

Sorry for the confusion guys and derailing this thread with my lack of knowledge. But I learned at least something.

That article appears to be saying that Nvidia was working on a compiler to translate CUDA code into x86 code, to be more flexible and allowing CUDA to run on multi-processor x86 systems. NOT that you could run x86 code on CUDA-compatible hardware.

(Which, if there is some way to solve the branching issues, could be possible, I suppose.)

 

[Scali]

Branchy code wouldn't have run well on Larrabee either, it's cores were P56- in order cores. x86 by default is no better at handling branching then GPUs, it is the current chip architectures that make it so they don't roll over and die.

x86 are very good at branching, like most other CPUs.
GPUs do NOT branch, that's the whole point.
When a branch occurs in code, the GPU will simply run both sides of the branch and disable the results of the branch that was not taken.
So it's implemented as a masking operation, rather than an actual branch.
The effect is that the paralellism goes down (it's still SIMD, so all threads have to execute the exact same instruction).
x86 is way different, as each core has its independent instruction pipeline and can branch completely independently from each other core.