Larrabee's future in doubt as Nvidia looks to pull their cross-license IP

[BenSkywalker]

This one here says how ATI/NV infringed on real3D the IP that Intels owns .

Seriously, your flat out lies are too much, from the article you linked-

But Real3D also has legal suits out against 3Dfx Inc and ATI Technologies Inc, over claimed infringements of its texture mapping technologies.

Do some research, and stop with the flat out lies man, it isn't worth talking to you at all until you can manage that.

 

[Nemesis 1]

Oh I missed NV wast'n . But now that NV owns 3dfx your point is what. Point is intel has that which you deny

 

[Nemesis 1]

Originally posted by: chizow

Originally posted by: Nemesis 1
By intel doing it this way . Programmers can code native C++ for there programs or open CL Intel has every resonable avenue covered . While still mantaining X86 compatability with there Older tech. But as programs move away from those old instructions intel will not miss a step.

To add to Ben's point and approach it from a different angle. If Larrabee and x86 CPUs were "native C++" (they're not), then why would Nvidia need an x86 license? Why does Intel guard their x86 IP so tightly? Why does Intel charge so much for their x86 compiler? Answer: Intel CPUs aren't native C++.

I don't know what you 2 guys are about . But I got link from Intel Saying Larrabee native language is C++ compiler. Now this is a Offical Intel document . Same as other guy says intel has no patent on texture units when I have shown clearly they do . I have more patent links also.

 

[Nemesis 1]

http://www2.theregister.co.uk/...dismisses_ati_real_3d/

It appears to me Intels IP for Texture unit is very strong . Looks like its really strong. Fact is others are using Real 3D IP that Intel now owns . You really want to flex muscle . Intel seems to have plenty.

http://en.wikipedia.org/wiki/Real3D

 

[habbakuk87]

Originally posted by: Nemesis 1

Originally posted by: chizow

Originally posted by: Nemesis 1
By intel doing it this way . Programmers can code native C++ for there programs or open CL Intel has every resonable avenue covered . While still mantaining X86 compatability with there Older tech. But as programs move away from those old instructions intel will not miss a step.

To add to Ben's point and approach it from a different angle. If Larrabee and x86 CPUs were "native C++" (they're not), then why would Nvidia need an x86 license? Why does Intel guard their x86 IP so tightly? Why does Intel charge so much for their x86 compiler? Answer: Intel CPUs aren't native C++.

I don't know what you 2 guys are about . But I got link from Intel Saying Larrabee native language is C++ compiler. Now this is a Offical Intel document . Same as other guy says intel has no patent on texture units when I have shown clearly they do . I have more patent links also.

C++ is a high level language and a compiler is a software that translates high level language code to the native code of the processor on which the code is meant to run.The native language of Larrabee is going to be its instruction set.The C++ compiler that Intel refers to must be the compiler they are using to create software like drivers and software renderer etc because they are most probably going to have custom extensions to standard C++(like PS3 code is written on C++ with proprietary extensions).

 

[Nemesis 1]

I know all this . But it clearly stated That Larrabbee Native language is C++ compiler.


Heres what its says latter on I just copy . You you can read .


The Larrabee Native programming model resembles the well
known programming model for x86 multi-core architectures.
Central to Larrabee Native programming is a complete C/C++
compiler that statically compiles programs to the Larrabee x86
instruction set. Many C/C++ applications can be recompiled for
Larrabee and will execute correctly with no modification. Such
application portability alone can be an enormous productivity gain
for developers, especially for large legacy x86 code bases like
those found in high-performance computing and numericintensive
computing environments. Two current limitations are
that application system call porting is not supported and the
current driver architecture requires application recompilation.
We now discuss three important aspects of application
programming for Larrabee Native: software threading, SIMD
vectorization, and communication between the host and Larrabee.
Larrabee Native presents a flexible software threading capability.
The architecture level threading capability is exposed as the well
known POSIX Threads API (P-threads) [IEEE 2004]. We have
extended the API to also allow developers to specify thread
affinity with a particular HW thread or core.
Although P-threads is a powerful thread programming API, its
thread creation and thread switching costs may be too high for
some application threading. To amortize such costs, Larrabee
Native provides a task scheduling API based on a light weight
distributed task stealing scheduler [Blumofe et al. 1996]. A
production implementation of such a task programming API can
be found in Intel Thread Building Blocks [Reinders 2007].
Finally, Larrabee Native provides additional thread programming
support via OpenMP [Chandra et al. 2000] pragmas in Larrabee
Native?s C/C++ compiler.
All Larrabee SIMD vector units are fully programmable by
Larrabee Native application programmers. Larrabee Native?s
C/C++ compiler includes a Larrabee version of Intel?s autovectorization
compiler technology. Developers who need to
program Larrabee vector units directly may do so with C++ vector
intrinsics or inline Larrabee assembly code.
In a CPU based platform that includes a Larrabee based add-in
card, Larrabee will managed by an OS driver for that platform. In
such a platform, Larrabee Native binaries are tightly paired with a
host binary. Larrabee libraries provide fast message/data passing
protocol to manage all memory transfers and communications
between the binaries. The API supports both synchronous and
asynchronous data transfers. Additionally, execution of some
C/C++ standard library functions called from Larrabee application
binaries must be shared with the host operating system.
Specifically file I/O functions such as read/write/open/close, etc.,
are proxied from the Larrabee application binary back to a service
that executes such functions remotely on the host OS.
Besides high throughput application programming, we anticipate
that developers will also use Larrabee Native to implement higher
level programming models that may automate some aspects of
parallel programming or provide domain focus. Examples include
Ct style programming models [Ghuloum et al. 2007], high level
library APIs such as Intel® Math Kernel Library (Intel® MKL)
[Chuvelev et al. 2007], and physics APIs. Existing GPGPU
programming models can also be re-implemented via Larrabee
Native if so desired [Buck et al. 2004; Nickolls et al. 2008].
6.2 Irregular Data Structure Support
Larrabee provides excellent support for high throughput
applications that use irregular data structures such as complex
pointer trees, spatial data structures, or large sparse n-dimensional
matrices. They are supported by Larrabee?s programming model,
memory hierarchy, and VPU instructions.
For Larrabee applications, the multithreaded C++ code to
populate, transform, or traverse these data structures follows the
familiar programming methodology used on multi-core CPUs.
C++ pointers, inheritance, and classes may be used to implement
graph nodes. The individual nodes may have significantly
different operation execution costs or code branch behavior.
Because thread or task scheduling is under programmer control,
tasks that operate on these data structures can be dynamically rebundled
to maintain SIMD efficiency. For example, a ray tracer?s
secondary reflection rays may be re-bundled differently than the
primary camera rays that generated them. Finally, data structure
techniques such as pre-allocated memory pools can be used to
asymmetrically provide only the memory required for a given data
structure node. For example, an order-independent transparency
implementation may dynamically associate memory based on the
number of layers per pixel, rather than pre-allocating a wasteful
overestimation of the number of layers per pixel as K-buffer
techniques often do [Callahan et al. 2005; Bavoil et al. 2007].
18:10 ? L. Seiler et al.
ACM Transactions on Graphics, Vol. 27, No. 3, Article 18, Publication date: August 2008.


Pthreads defines a set of C programming language types, functions and constants. It is implemented with a pthread.h header and a thread library. Programmers can use Pthreads to create, manipulate and manage threads, as well as synchronize between threads using mutexes and signals.

 

[Cookie Monster]

Originally posted by: Nemesis 1
I know all this . But it clearly stated That Larrabbee Native language is C++ compiler.

-snip-

The Larrabee Native programming model resembles the well
known programming model for x86 multi-core architectures.
Central to Larrabee Native programming is a complete C/C++
compiler that statically compiles programs to the Larrabee x86
instruction set. Many C/C++ applications can be recompiled for
Larrabee and will execute correctly with no modification.

-snip-

What he is trying to say is that Larrabee's native language isnt C++ compiler literally (a compiler isnt even a language! but rather a translator), but in essence it is because due to the x86 nature of larrabee, compatibility with exisiting/future apps are all dependent on the compiler (for larrabee). Given intel's track record on compilers, I doubt we will see much compatibility problems.

At the end of the day, code written for Larrabee is based on C++ without/with proprietary extensions as habbakuk87 as pointed out where this is recompiled by this compiler which makes it run on Larrabee based technology. So basically, Larrabee is "native C++" in this sense. Sure some of these existing apps might require some code optimizations but they will run nonetheless without much compatibility issues.

This is what nemesis meant. When he talks about nVIDIA being in trouble he means that the since this is the first time an x86 based architecture is being developed as a dedicated GPU (or more appropriately GPGPU), intel will be the first and last one to hop into that new bandwagon. (Maybe AMD could do the same since they hold an x86 license). With releases of x86-GPUs (possibly with IGPs derived from larrabee tech also) nVIDIA might be in trouble. All this depends on how well Larabee performs in different areas such as 3D apps, GPGPU tasks, production cost and such. But if they manage to provide something equivalent to what the others provide, no one would be able to sustain a bloody meat grinder against the likes of Intel. Its a broad theory but we will have to see how this all pans out. Im also sure ive missed some of his other points but thats the homework I leave to you guys.

However my prediction atm is intel ending up in the intensive care unit in round 1!

 

[BenSkywalker]

But now that NV owns 3dfx your point is what.

That you flat out lie, frequently. Are you doing it out of complete ignorance or are you doing it to try and mislead people?

It appears to me Intels IP for Texture unit is very strong .

Again I have to ask, ignorance or intentional? I linked you the US Patent records on IP relating to texture management units. There are three of them, one is held by Toshiba, the other two are held by nVidia. What you are trying to point to is a way to execute texture mapping, that is the process that takes place after the texture management unit has done its' work.

As far as linking me information about Real3D, I was quite familiar with them back when they were a division of GE. You haven't been around very long, I have

I know all this . But it clearly stated That Larrabbee Native language is C++ compiler.

Again, a flat out lie.

Many C/C++ applications can be recompiled for
Larrabee and will execute correctly with no modification. Such
application portability alone can be an enormous productivity gain
for developers, especially for large legacy x86 code bases like
those found in high-performance computing and numericintensive
computing environments. Two current limitations are
that application system call porting is not supported and the
current driver architecture requires application recompilation.

You even quote the text yourself that proves you are lieing, what are you trying to do? Do you not understand what they are saying? Honestly I don't think talking to you is doing any good, but you post a lot of links and the way you try and present yourself as an insider may fool some people into thinking you know something, anything at all, about what you are talking about. You are not on the edge of raging Intel cheerleader, you have gone completely off the scales and are even telling lies beyond what the Intel documentation you quote states. Seriously, you are acting in a manner that goes beyond what any PR person I've ever met would try.

 

[Keysplayr]

Guys. Nemesis is F-ing with all of you. I mean isn't it obvious? He can't really be serious with all this. He is pulling your chains and you're all saying "May I please have some more?" Ignore him. He is beyond help.

 

[SickBeast]

To me it looks like AMD has the most to gain from Intel and NV going at each other like this.

I honestly think that Intel would come up with their own unique method of rasterization and ray tracing rather than infringing on numerous patents. It just goes against what they have traditionally done as a company.

It will definiately be interesting to see what happens with Larabee. When is its latest release date?

 

[habbakuk87]

http://arstechnica.com/hardwar...ce-the-pentium-pro.ars
So the Larrabee native C/C++ is the software renderer part.Judging and reconfiguring the renderer for each frame is an interesting method.I find it strange that they will want to push a model in which the performance benefits com from better driver(or renderer etc) support rather than buying a new model of the graphic card.

 

[Nemesis 1]

Originally posted by: BenSkywalker

But now that NV owns 3dfx your point is what.

That you flat out lie, frequently. Are you doing it out of complete ignorance or are you doing it to try and mislead people?

It appears to me Intels IP for Texture unit is very strong .

Again I have to ask, ignorance or intentional? I linked you the US Patent records on IP relating to texture management units. There are three of them, one is held by Toshiba, the other two are held by nVidia. What you are trying to point to is a way to execute texture mapping, that is the process that takes place after the texture management unit has done its' work.

As far as linking me information about Real3D, I was quite familiar with them back when they were a division of GE. You haven't been around very long, I have

I know all this . But it clearly stated That Larrabbee Native language is C++ compiler.

Again, a flat out lie.

Many C/C++ applications can be recompiled for
Larrabee and will execute correctly with no modification. Such
application portability alone can be an enormous productivity gain
for developers, especially for large legacy x86 code bases like
those found in high-performance computing and numericintensive
computing environments. Two current limitations are
that application system call porting is not supported and the
current driver architecture requires application recompilation.

You even quote the text yourself that proves you are lieing, what are you trying to do? Do you not understand what they are saying? Honestly I don't think talking to you is doing any good, but you post a lot of links and the way you try and present yourself as an insider may fool some people into thinking you know something, anything at all, about what you are talking about. You are not on the edge of raging Intel cheerleader, you have gone completely off the scales and are even telling lies beyond what the Intel documentation you quote states. Seriously, you are acting in a manner that goes beyond what any PR person I've ever met would try.

I know Compiler is and does on front end. I also Don't get Your problem here at all .

I highlighted interesting Part /
The architecture level threading capability is exposed as the well
known POSIX Threads API (P-threads) [IEEE 2004]. We have
extended the API to also allow developers to specify thread
affinity with a particular HW thread or core. P-Threads I wrote definintion at bottom


Your last part were Iam I lieing . I am using links. I may not put in to words corretly but I not Lieinging about anything . Zrro reasons to lie .


Read this tell; me what you get from it . Maybe than I can see how I am mis saying .


The Larrabee Native programming model resembles the well
known programming model for x86 multi-core architectures.
Central to Larrabee Native programming is a complete C/C++
compiler that statically compiles programs to the Larrabee x86
instruction set. Many C/C++ applications can be recompiled for
Larrabee and will execute correctly with no modification. Such
application portability alone can be an enormous productivity gain
for developers, especially for large legacy x86 code bases like
those found in high-performance computing and numericintensive
computing environments



Also Keys ya used the word now explain were you think I am pulling Chains . Show me were I am misleading . Its certainly not my intention. As I really haven't said anything without Links . Please tell me were I misread the info. At no time did I say Intel native was c/c++ I said Intel has it written Larrabee native C/C++ compiler. So pretty real fact that I know the Compiler isn't native . But than I hight light the P-threads(API) and its ignored.

If I got this wrong the way I reading . Show light. Instead of Attacking . Add to understanding than . If you understand whats going on inside larrabee. Say so . The APE type marketing warfare doesn't work on me .

Info is from Intel . Lets have your take on what its says . You do know this thread is coming back in future. Right!

 

[Nemesis 1]

That section I posted from intel . Lets talk about what it says . Seems to me thats what these forums are for . Not NV saying Intel using There IP. Lets look at larrabbee and see what it is that Intel would be using that is NV IP. On the GPU itself. Intel has only the Texture Unit. We Know Intel has patents and IP of tecture units . We also know that Many companies infringed on Real3D patents (NOw INtels) or all info on said facts is lie to somehow screw NV. LOL Intel has licensed other Ip . For some to say there are only 3 patents for Texturing units is just so not true.

So larrabbee is software render using a texture unit only from traditional GPU . You can target the texture unit if you desire but I think this is another Big Bang puff!

Its alright to get links and say this is whats out their because this is all I found . Really.

Ben its you who said Intel backed away from software render. Yet I have shown its otter BS. You said Intel backtracked . Which isn't true at all . The texture unit was always in the plan for Larrabee. Than I confuse ya by saying what intel writes Larrabee native language C/C++ compiler. Now if intel was saying Larrabee native was C/C++ that be differant. Intel goes on to say exactly that . Thats why I said read it for yourself.

We all know Compiler not language its software tool. But yjr P thread is C language thats the whole point. Intel can use higher languages like CL as native with compiler this is were Pthreads come into pic. or any high level language . Intels Vertex units are proving to be very interesting...

I a funny guy I know that. But when things start not to add up than I know I missed something. Intel saying on Sandy bridge at 22nm. That they will use FMA I have seen some reports saying intelwill use DMA . OK this is not working for me, Same with AMD saying Bulldozer gets FMA. I want to see this. If they can make that work on a cisc backend Its something I want to see very much. LOL. So intel / AMD not saying alot about the backends. For Me Sandy 32nm ties to larrabee for Max performance,

Sandy at 22nm has me completely baffled it doesn't make any sence. Surely intel doesn't see the future as being seperate GPU from CPU that just doesn't make sense. So sandy at 22nm is A strange creature . It be interesting how it relates to larrabee.

Back on topic . I am seirous Larrabees arch is laid out right here in a link . If NV has a case . Lets look at Intels Arch and see what it is NV could possiabily be referring to.

Is that not the proper way to have debate on OP . Heres the Tech Now whats NV talking about. Is this not the correct formate? Or again I am I not seeing clearly.

We really don't have long to wait. I not even talking Larrabee. We just have to wait and see how Nehalem runs on Snow Leapald and Grand central to find out INTELS C State.
My bet is Snow walks all over 7. In GAMING!! Now thats a Bold statement.

 

[Keysplayr]

Originally posted by: Nemesis 1

Originally posted by: BenSkywalker

But now that NV owns 3dfx your point is what.

That you flat out lie, frequently. Are you doing it out of complete ignorance or are you doing it to try and mislead people?

It appears to me Intels IP for Texture unit is very strong .

Again I have to ask, ignorance or intentional? I linked you the US Patent records on IP relating to texture management units. There are three of them, one is held by Toshiba, the other two are held by nVidia. What you are trying to point to is a way to execute texture mapping, that is the process that takes place after the texture management unit has done its' work.

As far as linking me information about Real3D, I was quite familiar with them back when they were a division of GE. You haven't been around very long, I have

I know all this . But it clearly stated That Larrabbee Native language is C++ compiler.

Again, a flat out lie.

Many C/C++ applications can be recompiled for
Larrabee and will execute correctly with no modification. Such
application portability alone can be an enormous productivity gain
for developers, especially for large legacy x86 code bases like
those found in high-performance computing and numericintensive
computing environments. Two current limitations are
that application system call porting is not supported and the
current driver architecture requires application recompilation.

You even quote the text yourself that proves you are lieing, what are you trying to do? Do you not understand what they are saying? Honestly I don't think talking to you is doing any good, but you post a lot of links and the way you try and present yourself as an insider may fool some people into thinking you know something, anything at all, about what you are talking about. You are not on the edge of raging Intel cheerleader, you have gone completely off the scales and are even telling lies beyond what the Intel documentation you quote states. Seriously, you are acting in a manner that goes beyond what any PR person I've ever met would try.

I know Compiler is and does on front end. I also Don't get Your problem here at all .

I highlighted interesting Part /
The architecture level threading capability is exposed as the well
known POSIX Threads API (P-threads) [IEEE 2004]. We have
extended the API to also allow developers to specify thread
affinity with a particular HW thread or core. P-Threads I wrote definintion at bottom


Your last part were Iam I lieing . I am using links. I may not put in to words corretly but I not Lieinging about anything . Zrro reasons to lie .


Read this tell; me what you get from it . Maybe than I can see how I am mis saying .


The Larrabee Native programming model resembles the well
known programming model for x86 multi-core architectures.
Central to Larrabee Native programming is a complete C/C++
compiler that statically compiles programs to the Larrabee x86
instruction set. Many C/C++ applications can be recompiled for
Larrabee and will execute correctly with no modification. Such
application portability alone can be an enormous productivity gain
for developers, especially for large legacy x86 code bases like
those found in high-performance computing and numericintensive
computing environments



Also Keys ya used the word now explain were you think I am pulling Chains . Show me were I am misleading . Its certainly not my intention. As I really haven't said anything without Links . Please tell me were I misread the info. At no time did I say Intel native was c/c++ I said Intel has it written Larrabee native C/C++ compiler. So pretty real fact that I know the Compiler isn't native . But than I hight light the P-threads(API) and its ignored.

If I got this wrong the way I reading . Show light. Instead of Attacking . Add to understanding than . If you understand whats going on inside larrabee. Say so . The APE type marketing warfare doesn't work on me .

Info is from Intel . Lets have your take on what its says . You do know this thread is coming back in future. Right!

No thanks bud. No attacks. Simply warned the level headed to steer clear for obvious reasons. After the material Ben presented, I think we can safely say he knows what he is talking about. You on the other hand, not so much. A for effort though. :beer:

 

[Nemesis 1]

Ok Keys. Young skywalker here seems to have fallen to the powers of Dark side.

He has seen that Intel Is really not using software render. Doesn't know what P threads are or how they relate to Intel APi or the c/C++ compiler. He knows that NV has 2/3 Texture Unit Patents. In which there are only 3 in world Ya I would say young skywalker has done well .


I like what mike says .


Quote:
Yay! Michael Abrash and I are finally going to do a talk each about the instruction set we helped develop: Rasterization on Larrabee: A First Look at the Larrabee New Instructions (LRBni) in Action and SIMD Programming with Larrabee: A Second Look at the Larrabee New Instructions (LRBni) in Action. They're pretty much a pair - going to mine without seeing Mike's first won't mean very much for example. Note that these aren't graphics talks, they're for anybody who wants to program these cores in assembly or C. We will be using parts of the graphics pipeline as examples, because that's what we've spent most of our time doing, but there's no graphics knowledge required at all. Just bring your assembly head - we're going all the way to the metal.

There's very few programmers that can say they got to invent their own ISA, and I'm really looking forward to finally being able to talk about it in public after about three years of secrecy. Creating an ISA is all about compromises between programmer flexibility and how difficult the hardware is to build, but I am always astonished how much we managed to pack in without too much screaming from the hardware folks. It will be interesting seeing how people react to it - it's got a lot of funky features not found in other ISA that I know of.

 

[Nemesis 1]

Originally posted by: Cookie Monster

Originally posted by: Nemesis 1
I know all this . But it clearly stated That Larrabbee Native language is C++ compiler.

-snip-

The Larrabee Native programming model resembles the well
known programming model for x86 multi-core architectures.
Central to Larrabee Native programming is a complete C/C++
compiler that statically compiles programs to the Larrabee x86
instruction set. Many C/C++ applications can be recompiled for
Larrabee and will execute correctly with no modification.

-snip-

What he is trying to say is that Larrabee's native language isnt C++ compiler literally (a compiler isnt even a language! but rather a translator), but in essence it is because due to the x86 nature of larrabee, compatibility with exisiting/future apps are all dependent on the compiler (for larrabee). Given intel's track record on compilers, I doubt we will see much compatibility problems.

At the end of the day, code written for Larrabee is based on C++ without/with proprietary extensions as habbakuk87 as pointed out where this is recompiled by this compiler which makes it run on Larrabee based technology. So basically, Larrabee is "native C++" in this sense. Sure some of these existing apps might require some code optimizations but they will run nonetheless without much compatibility issues.

This is what nemesis meant. When he talks about nVIDIA being in trouble he means that the since this is the first time an x86 based architecture is being developed as a dedicated GPU (or more appropriately GPGPU), intel will be the first and last one to hop into that new bandwagon. (Maybe AMD could do the same since they hold an x86 license). With releases of x86-GPUs (possibly with IGPs derived from larrabee tech also) nVIDIA might be in trouble. All this depends on how well Larabee performs in different areas such as 3D apps, GPGPU tasks, production cost and such. But if they manage to provide something equivalent to what the others provide, no one would be able to sustain a bloody meat grinder against the likes of Intel. Its a broad theory but we will have to see how this all pans out. Im also sure ive missed some of his other points but thats the homework I leave to you guys.

However my prediction atm is intel ending up in the intensive care unit in round 1!

You did really good. Thats almost perfect. I don't see why others can't see it The P threads is dead give away. I kinda agree to that we don't know how Larrabee will turn out. It could Flop. Thats no biggy to myself . The biggy to me is the Tech and having the shear power to do this in software gets me excited. If it works out it will change everthing . ATI tech Is way GOOD stuff. Now they got CL helps but CL was a thing Apple /Intel been working at long time. Befor Apple wanted to make it a standard. Look at larrabees API . Its GOT C/C++ languages written all over it , NATIVE! CL fitts like a glove it was made for Intel . Nothing like that stinky OJ glove Were it just didn't fit.


Besides high throughput application programming, we anticipate
that developers will also use Larrabee Native to implement higher
level programming models that may automate some aspects of
parallel programming or provide domain focus. Examples include
Ct style programming models [Ghuloum et al. 2007], high level
library APIs such as Intel® Math Kernel Library (Intel® MKL)
[Chuvelev et al. 2007], and physics APIs. Existing GPGPU
programming models can also be re-implemented via Larrabee
Native if so desired [Buck et al. 2004; Nickolls et al. 2008].

 

[Idontcare]

Originally posted by: Nemesis 1
You did really good. Thats almost perfect. I don't see why others can't see it The P threads is dead give away. I kinda agree to that we don't know how Larrabee will turn out. It could Flop. Thats no biggy to myself . The biggy to me is the Tech and having the shear power to do this in software gets me excited. If it works out it will change everthing . ATI tech Is way GOOD stuff. Now they got CL helps but CL was a thing Apple /Intel been working at long time. Befor Apple wanted to make it a standard. Look at larrabees API . Its GOT C/C++ languages written all over it , NATIVE! CL fitts like a glove it was made for Intel . Nothing like that stinky OJ glove Were it just didn't fit.


Besides high throughput application programming, we anticipate
that developers will also use Larrabee Native to implement higher
level programming models that may automate some aspects of
parallel programming or provide domain focus. Examples include
Ct style programming models [Ghuloum et al. 2007], high level
library APIs such as Intel® Math Kernel Library (Intel® MKL)
[Chuvelev et al. 2007], and physics APIs. Existing GPGPU
programming models can also be re-implemented via Larrabee
Native if so desired [Buck et al. 2004; Nickolls et al. 2008].

The part I bolded - this I like how Intel has approached Larrabee (or rather how they are using Larrabee to approach the graphics market) because of the generalized ISA they can deploy Larrabee-like architectures to accelerate many different applications from GPU-based to HPC-based.

From my perspective Larrabee's success in the discreet GPU market is simply a matter of time if it doesn't happen at time-zero. Intel has the wind of process technology cadence and superiority blowing on its back, if 45nm Larrabee doesn't have enough cores at the right clockspeed then 32nm shrink will take it up a notch, as will 22nm etc.

But regardless how it turns out in the discreet GPU market the prospects of dropping in a co-processing card connected by QPI to your Sandy Bridge CPU and suddenly your code is now processing on 64+ hardware cores certainly raises an eyebrow or two in the HPC and enterprise realms.

I'm not concerned with Larrabee's GPU prowess, I'm more interested to see where else Intel takes this thing in the coming 2-3 yrs.