AMD's answer to Larrabee: SSE5 vs. AVX? SPECULATION

[wingless]

If Larrabee is a success then companies like Nvidia and ATI may be up a creek. My purpose for this thread is to speculate on what type of CPU/GPU AMD will need to compete with Intel's Larrabee. AMD is also planning a new instruction set called SSE5 which seems to be geared toward the Bulldozer Fusion platform. Intel is coming out with AVX (a vector instruction set) for Larrabee as well. From what we have read and can find on the net, which seems more promising (useful)?

These questions came to me because Intel is serious about getting rid of the GPU and dependence on Direct X for 3D graphics. They want 100% x86 CPU rendering/ray tracing to happen ASAP. I'm asking here because I have witnessed the huge amount of technical backgrounds and knowledge of these forum members and wanted to get a discussion on these topics started.

Heres a link for you to feed on:
People “probably won’t” need discrete graphics cards anymore – Intel
http://www.tgdaily.com/content/view/36758/135/

 

[Arun]

I'm going to sleep just now so I'm not going to write a comprehensive answer to the overall topic which does hold merit, but AVX is for Sandy Bridge, not Larrabee; the latter will likely have a competing Vector ISA (ugh!)

 

[wingless]

I realize the link I posted is just of a Nehalem running 3D graphics. I just added that to illustrate the point that Intel wants to make 3D graphics on PCs all x86. I remember reading that Larrabee was to have it's own instruction set and I thought that was AVX, but I see I'm mistaken. It had something to do with pure x86 3D programming.

Just a thought: I wonder if a new version of SwiftShader would run on Larrabee. Sure, it would be pointless since Larrabee can run OpenGL and DirectX, but it would make benchmark for how fast Larrabee renders x86 3D graphics.

 

[Ilfirin]

I find the comments about having to learn new shader models a bit misleading at best. I mean, for the most part, the differences between all the shader models is just the instruction set and some other limitations. What he's saying is basically "you don't have to learn a new shader model every year, instead you just have to learn our new instruction set every year!" which I translate into meaning "You don't have to do what you currently do! Instead, you can do what you currently do.. but use our system!"

 

[Mobius1aic]

I find the comments about having to learn new shader models a bit misleading at best. I mean, for the most part, the differences between all the shader models is just the instruction set and some other limitations. What he's saying is basically "you don't have to learn a new shader model every year, instead you just have to learn our new instruction set every year!" which I translate into meaning "You don't have to do what you currently do! Instead, you can do what you currently do.. but use our system!"

It also sounds like a bid to force people into buying Intel chips if games possibly only support certain Intel processors. THAT WOULD BE COMPLETE BS. Also, GPUs are completely chambered for graphics, even an x86 processor with dozens of cores in 2012 isn't going to compete with a GPU that could possibly be armed to the teeth with potentially thousands of stream processor units, hundreds of TMUs, and dozens of ROPs. Add to that idea that physics could be done on it as well, leaving the CPU for AI and orchestration like usual. I think Larrabee is a pipe dream. A great idea, but ultimately doesn't work out too well considering it's using a type of architecture not made for graphics then trying to adapt it while still competing with true dedicated graphics solutions that will probably heavily outclass it anyways.

 

[Arun]

leaving the CPU for AI and [...]

I don't think it'll even have that left by then...

 

[Rys]

And all of this does nothing to change the fact that there needs to be a complete sea change in how graphics hardware is programmed before the status quo gets usurped. The status quo likely _can't_ be usurped without NV or AMD buying in to it either. The hardware is still largely incidental.

 

[kyetech]

I don't think it'll even have that left by then...

Do you think Larrabee is a pipe dream too then?

Personally I would prefer it to be a new era in rendering paradigm. But that in itself is probably a pipe dream?

The fact that Nvidia have set this 3 day hack party after the fall IDF suggests to me that Nvidia think Intel may have something worth showing and that they are going to need to make more noise about what they have.

I dont know much about the architectures but I cant imagine intel investing so heavily in something if they didnt think what they were going to do would work, or more specifically, be competitive. I mean surely if it really was going to be a poor performer against 2010 GPUs they would have already been able to work that out for themselves and realised it would be a poor investment. Or maybe they are in denial about what they think they can achieve?

Perhaps they will get in to higher cost higher profit markets first (HPC, offline renderfarms, Medical industry etc) And then leverage the tech towards gaming as it becomes more applicable and financially reasonable?

 

[3dilettante]

Do you think Larrabee is a pipe dream too then?

I think the quoted section was more of a comment on the likelihood that AI would remain a CPU duty.

A significant portion of an AI is often heavy-duty number crunching that produces the decision tree, tables, or other values used by the logic.
That much could potentially find its way to a GPU, though I wonder if it would be easier to do once the GPU is on-die.

The portion of the logic around that portion though, I am not so certain about pushing on the GPU just yet.

Personally I would prefer it to be a new era in rendering paradigm. But that in itself is probably a pipe dream?

That's probably basing too much hope on Larrabee, I think.

I dont know much about the architectures but I cant imagine intel investing so heavily in something if they didnt think what they were going to do would work, or more specifically, be competitive. I mean surely if it really was going to be a poor performer against 2010 GPUs they would have already been able to work that out for themselves and realised it would be a poor investment. Or maybe they are in denial about what they think they can achieve?

That means Intel would know what 2010 GPUs and 2010 workloads would look like, as well as knowing how Larrabee turns out at that time.
There's a lot that isn't known.
Intel does know it has the resources, x86 influence (maybe), and process technology to push the envelope on circuit performance and density.
That can be a significant advantage, but it is only part of the overall equation.

Perhaps they will get in to higher cost higher profit markets first (HPC, offline renderfarms, Medical industry etc) And then leverage the tech towards gaming as it becomes more applicable and financially reasonable?

I think that Larrabee would be much more strongly positioned outside of consumer graphics, but Intel seems intent on pushing pretty hard in that area as well.

 

[TimothyFarrar]

Anyone know what is cooking for DX11 (ie how the rendering API is going to change in Larrabee's time frame)?

I'm not sure if another x86 based arch would be competitive with Larrabee. I'm missing why NVidia and AMD/ATI cannot continue down their current path towards a more GP GPU and still be very competitive and continue dominance. Given the current slow adaption of DX10, and graphics based development still highly tied to the DX9 level of the consoles, I just don't see developers realistically being able to really take advantage of Larrabee's features for a long time. Most of us have core design tied to the lower end hardware requirements. For example, still using the x86 float stack instead of pure SSE or SSE2 because users still having pre-Core level CPU (ie missing ability to retire one SSE scaler op per cycle). Or in-ability to build or compile a 64-bit version of the program, because majority of users don't want to pay extra for 64-bit version of Windows. Larrabee could be suck in a DX9/10 world where price/performance for that API favors the dedicated hardware from NVidia and ATI.

 

[Entropy]

Or in-ability to build or compile a 64-bit version of the program, because majority of users don't want to pay extra for 64-bit version of Windows. Larrabee could be suck in a DX9/10 world where price/performance for that API favors the dedicated hardware from NVidia and ATI.

I just had reason to dive into old documents about Windows 7, and at the time they were written, the next client version of Windows would still be offered in a 32-bit and and a 64-bit version.
Unless something changes before launch, I think PC games will be stuck targeting a 32-bit environment for a very long time indeed.

Your other line of reasoning is sound, but dependent on the direction of nVidia and AMD. A graphics ASIC is going to yeild better performance per transistor the more dedicated it is to a limited task. That's the whole purpose of an application specific circuit in the first place. Going more general purpose (and incurring the corresponding hit in efficiency doing the old work load) opens them up to a more formidable opponent than S3... So is it really in nVidias best interest to keep pushing their graphics architecture to become more generally applicable? Good question.

 

[TimothyFarrar]

I should probably qualify my remark with what I mean by GP, which is more along the lines of adding programmable ROP (CUDA's compute 1.1 missing feature of surface cache, ie like texture cache except writeable), programmable vertex attribute fetch (which already exists as a vertex texture fetch), double precision support, rendering API R/W access to the features in CUDA (ie global memory access, atomic memory access, and local shared memory access), and last but extremely important is the ability to construct command buffers GPU side without CPU intervention. Nearly all of this is an API issue, with hardware features that mostly exist right now ... it doesn't take much to give the current rendering API enough flexibility to really perform at GP computations. The current fixed function hardware (triangle setup, texture units, etc) still plays a very important roll in what I am describing such that I still believe more GP GPUs will still have performance/transistor advantage over Larrabee.

 

[pjbliverpool]

So is AVX going to give Sandy Bridge more GPU like capabilities?

Should we expect Sandy Bridge software rendering to be on par or better than IGP's of the day?

 

[ShaidarHaran]

So is AVX going to give Sandy Bridge more GPU like capabilities?

Yes.

Should we expect Sandy Bridge software rendering to be on par or better than IGP's of the day?

I would say IGPs out next year will be able to top Sandy Bridge's software rendering performance, but I could be completely wrong.

 

[Rys]

Anyone know what is cooking for DX11 (ie how the rendering API is going to change in Larrabee's time frame)?

API wise, the biggest changes seem to be at the front of the pipe, before the GS, rather than at the tail end. Early peeks at things have the pipe extended by another couple of stages for the programmer there. You can guess why, and that bit maps reasonably well to Larrabee.

As for whether we get the oft asked for programmable OM, I'd say yes.

*P.S. Just to reiterate: DX11 isn't done, and what I've seen is not much past draft level, so things might change, but in those docs and discussions, the pre-GS stage is beefier and the OM gets new caps which hint at programmability*

 

[nAo]

Umh..AFAIK DX11 is pretty much done.

 

[Rys]

But not quite I didn't mean to imply that DX11 itself is still a draft, by the way.

 

[Nick]

...the pre-GS stage is beefier and the OM gets new caps which hint at programmability

Tell me more, tell me more! Grease jingle suddenly reverbs in my head...

I assume it's more like an evolution of DirectX 10 than something revolutionary like from DirectX 9 to DirectX 10? The overall architecture still needs more adoption from developers anyway. Anything else like general-purpose 'compute shaders' added?

 

[TimothyFarrar]

As for whether we get the oft asked for programmable OM, I'd say yes.

OM = what?

 

[Rys]

Output merger/ROP/blender.