RV770 has 10 clusters. I interpret this to mean it has 10 sequencers (all independent), each of which is running user-defined programs. The ALUs and TUs take control of those instructions in these programs that are targeted at them - the rest of the instructions run on the sequencer (control flow, register manipulation, cache control, etc.)
Dunno. On the MIPS1 & maybe 2, when there was only a 3 or 4 stage pipeline then it's a significant contribution to keeping your pipelines full, and the whole raison d'etre of the MIPS project was to avoid spending money on silicon when you can spend it on software instead.
Why? Instead of building a pile of large register files like in RV770 (2.5MB in total, it seems), the memory will be organised as a cache (2MB).
Depends on whether you program Larrabee close to the metal or using a JIT of some sort. For D3D graphics a JIT is planned. Ct is JIT based too.
Certainly. But that's not my point. For all I care it could be PowerPC, IA64, SPARC, ARM, MIPS or XYZ that dominates the market. I seriously doubt it would be significantly faster than x86 though. Other factors determine performance nowadays, and even performance / area.
Such as? Beyond the decoders x86 is really just a RISC architecture as far as I know. And the decoders are only marginally larger than those for other ISAs and are still dwarfed in comparison to other units.
Ever since the advent of shaders there has been talk about GPUs becoming more like CPUs. And with multi-core CPUs things even started to converge from the other end as well. So it's not a giant leap to try to see where the convergence will end. Using its expertise, NVIDIA can pretty much ensure that any new architecture is going to perform as expected while still offering many new features at minimal cost. It's a far greater gamble for Intel, who has no point of comparison and no alternatives to evaluate.
Having a general purpose cache, transparent to the user is a very nice feat. However as the paper Intel published at SIGGRAPH clearly shows it just doesn't work for graphics. Larrabee has cache-control instructions because you want cache blocks to be pinned, or you want stores to go to memory without polluting the caches, or recently loaded lines to be evicted immediately, the rasterizer must choose an appropriate tile size depending on the render target to fit the L2, back-end threads are pinned to a specific core so that non-atomic instructions can be used for synchronization between them, etc...
Sure, but back in the 1980s people didn't realise the days of making heavy revisions to the ISA were coming quickly to an end.
Why is that better if both designs are going to be using that storage predominantly to house a lot of thread context?
The counterargument is that a handful of generally slower and one size fits all cache ports under contention isn't particularly nice either.
Contemporaneous RISC designs to i386 and Pentium could do the same with a 30-40% economy in transistor count and often lead signficantly in performance.
If Larrabee used the Pentium Pro, your point would be valid. P54 is all CISC,, and the decoders are massively larger than an equivalent RISC decoder.
You're bound to a certain cache size and have to adapt the software to it, that's true, but it's still much more flexible and adaptive than what GPUs offer today. For any algorithm you have in mind, the entire cache is available for your temporary storage needs. The sizes of buffers and queues can be adjusted by changing a line of code, changing an application setting, or even adjusted dynamically.
Yes, and this would be an advantage as a GPU cannot magically re-allocate its post-transform cache for frame buffer data for example. But a cache also has two significant drawbacks:
Nvidia has a few CPU products, so it has at least licensed and implemented a few.
The qualifier is that one of the two problems is harder and is less established than the other.
I think we can make a distinction between having to design a general-purpose core and following the model Intel is using.
I'm not saying it's better, merely another way of doing something similar. I don't like the way Larrabee loses cycles to context switching, for what it's worth.
With a fixed SIMD width and well-defined data types the cache is hardly a match made in hell. Plus high performance graphics programming forces developers to pack their data into "cache line friendly" organisations, whether it's vertex attributes or texture resources or render targets.
Licensing is not exactly designing from the ground-up. On a completely different note they can barely design a working chipset..and they got at least one graphics product completely wrong. They can make mistakes too, even what they are very good at.
Yep, it's harder and less established, and I'd put my money on Intel getting it (more) right the first time than NVIDIA, because it's a major departure from how graphics hardware has been done in the last 5 years, while software graphics pipeline are well understood. We shall see in a couple of years, but again, I expect next NVIDIA architecture to be way similar to LRB than G8x is now, that's the only way forward, there is no coming back (in the short term).
Unless you know what NVIDIA is cooking I don't see how we can much such a distinction, ISA aside.
