Vector processing on nehelam?

Quote:

---

Originally Posted by Carfax

The Itanium uses something called software pipelining, which from what I hear, is superior to vectorization as it's more applicable.

But, real time ray tracing in games is many years off. If Intel decides to pursue this, it will most definitely be based on a specialized processor, and not a general purpose one like Nehalem.

---

YES CAN YOU TELL WE WHAT NEHALEM C IS ? were really speculating on geshner. But nehalem c is said to be a 16 core cpu. So it may be applicable to nehalem c. So with 16 cores on the cpu . I see no reason Intel can't include as you say a specialized processor. I would like to see a link that says Nehalem C is a general purpose processor

You seem to be saying you know what nehalem c is .It would be nice if you could elaborate on this and enlighten the rest of use. as for me I am just speculating. As thats whats this thread is.


This article touches abit on what were discussing here. Even tho its described as a x86 design . Witch really makes more since for Nehalem processor . But Geshner I believe is going into a whole new realm of processors.

The Otellini keynote stressed the proposition that processor performance is once again an important market factor. This is a return to a familiar message for Intel, and a departure from the "platformization" strategy that Intel has maintained through years of market share gains by AMD. Otellini's presentation also stressed the power-efficiency of the new processors. This move by Intel also highlights the continuing relevance of Moore's Law — which holds that the transistor density of integrated circuits will double every 18 months — and suggests that 16-core or even 32-core devices will likely be available by 2010.

http://www.theinquirer.org/default.aspx?article=35342

Even tho I may be getting ahead of myself on Geshner. What follows Geshner is extremely exciting also. Its hard to say were the industry is going but its a lot of fun tring to figure out or speculate on it. I really like the slides in this link . Eye poping stuff here.

http://www.tgdaily.com/picturegaller...0609264-1.html

can we please try to avoid mixing EPIC and x86 please turtle. They are not directly comparable

NN - it is applicable here. Thats what Elbrus compiler is VLIW(epic) . Do you think that Intel is going to announce to the world ya were ditching X86 in favor of VLIP(epic). I don't . I do believe Intel has a great desire to get away from the X86 processor. That could happen with Nehalem C but more likely Geshner.
This would give intel the ability to run any OS and not suffer a performance hit.

The logic of this is simplistic. As Intel spends billions on the x86 processor research. Everytime they come up with a design that will improve performance AMD is allowed to copy it. This bad for intel. By leaving the x86 processor they no longer have the monkey on their back.

Quote:

---

Originally Posted by Turtle 1

YES CAN YOU TELL WE WHAT NEHALEM C IS ? were really speculating on geshner. But nehalem c is said to be a 16 core cpu. So it may be applicable to nehalem c. So with 16 cores on the cpu . I see no reason Intel can't include as you say a specialized processor. I would like to see a link that says Nehalem C is a general purpose processor

You seem to be saying you know what nehalem c is .It would be nice if you could elaborate on this and enlighten the rest of use. as for me I am just speculating. As thats whats this thread is.

---

I have no idea what Nehalem C is and I am simply speculating.

I think it's safe to say that no general purpose processor would be capable of real time ray tracing at high resolution and acceptable frame rates.

But, after reading that article at the Inq, it's possible Intel has some plans to seriously beef up the vectorization in future cores.

As it stands right now, no x86 based processor uses a true vector engine. SSEn functions as both an FPU and a vector engine, but it's not a true vector engine.

In the future, Intel could put real vector units (similar to Cell) on their processors and this would dramatically increase floating point capability.

The biggest problem would be supplying these units with enough bandwidth, but who knows?

As the article states, there's XDR, and I'm sure Intel has some other tricks up it's sleeve to be able to feed the units..

This is probably the future of computing. Putting both specialized and general purpose cores together on the same piece of silicon..

Gesher is the 2010 model, so by then, desktop processors could be approaching 1 TFLOP in processing power, which should be enough to run a real time ray traced engine at high resolution.

be careful to differentiate between the x86 instuction set and the hardware that processes it, whilst intel and amd have an agreement to share significant updates to the core x86 instruction set, they have no obligations to share the hardware that processes those instructions. The internal pipelines of amd and intel cpus are already very different, and a certain degree of 'code morphing' already goes on, such as with micro and macro op fusion, but at this time this takes place in dedicated hardware that decodes the x86 instuctions and feeds the pipeline, not in software form that may be used in future products(and is used for running x86 on itaniums). The software solution is superior in that it may allow for universal compatability, with different recompilers used to convert between various instuction sets, not just external instructions>internal instruction

Quote:

---

Originally Posted by Carfax

I have no idea what Nehalem C is and I am simply speculating.

I think it's safe to say that no general purpose processor would be capable of real time ray tracing at high resolution and acceptable frame rates.

But, after reading that article at the Inq, it's possible Intel has some plans to seriously beef up the vectorization in future cores.

As it stands right now, no x86 based processor uses a true vector engine. SSEn functions as both an FPU and a vector engine, but it's not a true vector engine.

In the future, Intel could put real vector units (similar to Cell) on their processors and this would dramatically increase floating point capability.

The biggest problem would be supplying these units with enough bandwidth, but who knows?

As the article states, there's XDR, and I'm sure Intel has some other tricks up it's sleeve to be able to feed the units..

This is probably the future of computing. Putting both specialized and general purpose cores together on the same piece of silicon..

Gesher is the 2010 model, so by then, desktop processors could be approaching 1 TFLOP in processing power, which should be enough to run a real time ray traced engine at high resolution.

---

Now you see where I am coming from . It is extremely interesting and holds much promise. I believe in this thread I have the white paper link on Intels SSE4 its very interesting . But don't just read the top read the entire white paper its really good stuff.

Turtle you are talking about something that would take over a decade to unfold. And even if you have specialized logic for direct conversion, it is still going to suffer from the same problems as a common micro-decode engine

edit:
I advise you to read this article:
http://www.aceshardware.com/read.jsp?id=60000308
it is a little outdated but it'll help

Quote carfax

In the future, Intel could put real vector units (similar to Cell) on their processors and this would dramatically increase floating point capability.

The biggest problem would be supplying these units with enough bandwidth, but who knows?

As the article states, there's XDR, and I'm sure Intel has some other tricks up it's sleeve to be able to feed the units..
__________________________________________________ __________________________________________________ __________________
You may find this interesting as I do . As I believe Intel will introduce bits and pieces of the tech advance in each new generation. So its possiable we could find this tech on Geshner.

http://www.tgdaily.com/picturegaller...0609264-7.html

Quote:

---

Originally Posted by nn_step

Turtle you are talking about something that would take over a decade to unfold. And even if you have specialized logic for direct conversion, it is still going to suffer from the same problems as a common micro-decode engine

edit:
I advise you to read this article:
http://www.aceshardware.com/read.jsp?id=60000308
it is a little outdated but it'll help

---

Come on NN why do you think its 10 years away? As you know yourself Amd wants to add coprocessors as does intel on seperate sockets. Than we have Geneseo . This stuff isn't 10 years off only a 1 year.Ultimately making it on to the multi-core cpu sooner rather than latter.

That was a longtime ago and things have changed a lot.


However, there was one company which took a more radical approach and while its processor wasn’t exactly blazing fast it was faster than those using the stripped back approach, what’s more it didn’t include the x86 instruction decoder. That company was Transmeta and its line of processors weren’t x86 at all, they were VLIW (Very Long Instruction Word) processors which used "code morphing" software to translate the x86 instructions into their own VLIW instruction set.

Transmeta, however, made mistakes. During execution, its code morphing software would have to keep jumping in to translate the x86 instructions into their VLIW instruction set. The translation code had to be loaded into the CPU from memory and this took up considerable processor time lowering the CPU’s potential performance. It could have solved this with additional cache or even a second core but keeping costs down was evidently more important. The important thing is Transmeta proved it could be done, the technique just needs perfecting.

Intel on the other hand can and do build multicore processors and have no hesitation in throwing on huge dollops of cache. The Itanium line, also VLIW, includes processors with a whopping 9MB of cache. Intel can solve the performance problems Transmeta had because this new processor is designed to have multiple cores and while it may not have 9MB it certainly will have several megabytes of cache.

Most interestingly though is the E2K compiler technology which allows it to run X86 software. This is exactly the sort of technology Intel need and since last year they have had access to it and employ many of it’s designers.

You can of course expect all these cores to support 64 bit processing and SSE3, you can also expect there to be lots of them. Intel’s current Dothan cores are already tiny but VLIW cores without out of order execution or the large, complex, x86 decoders leave a very small, very low power core. Intel will be able to make processors stuffed to the gills with cores like this.

Intel will now be free to do as it pleases with X86 decoding done in software Intel can change the hardware at will. If the processor is weak in a specific area the next generation can be modified without worrying about backwards compatibility. Apart from the speedup nobody will notice the difference. It could even use different types of cores on the same chip for different types of problems.

The New Architecture
To reduce power you need to reduce the number of transistors, especially ones which don’t provide a large performance boost. Switching to VLIW means they can immediately cut out the hefty X86 decoders.

Out of order hardware will go with it as they are huge, consumes masses of power and in VLIW designs are completely unnecessary. The branch predictors may also go on a diet or even get removed completely as the Elbrus compiler can handle even complex branches.