Is the writing on the wall? ATI and NV doomed!

Thank, that was one of the most straight forward answer that I have read on the forum....

 

With the tremendous amount of software that's invested in x86 designs, I have a hard time believing that a major architectural change like that is in the works for CPUs. Such a change won't happen until it needs to.

 

Intel 2700G = PowerVR MBX (tell me that it lacks in bandwidth for what it's aimed for).

Question: what exactly would keep graphic IHVs from designing their future VPUs more in the stream processor direction, if it's really the superior sollution to look at?

This whole debate has been ongoing since the advent of 3D. For years now dedicated hardware has always proven itself to be more sufficient than general purpose HW and I don't expect it to change either. I won't deny that VPUs will move constantly closer to CPUs as time goes by, yet they'll still keep their well known so far advantages.

 

I voted PowerVR but i can't wait much longer

 

Straight-forward, maybe. We'll have to wait for more proofreaders before we can call it correct, though the fact that Brimstone didn't find any glaring errors is promising.

Considering what TR reported of IDF, the near future multi-core designs would appear to be cache-designed, as you say (the notion of cache- and stream-designed CPUs is new to me).

How's that for cache-designed?

TR also reports the P4 and P-M architectures will each get dual-core versions. Do you consider the P4's "NetBurst" architecture still cache-designed, or stream-designed, or a sort of crossover?

And will stream-designed CPUs require as much bandwidth as nV affords its GPUs (which is to say, more than twice what current CPUs get)?

 

A couple of points from me:

Firstly, software rendering is always going to be way more interesting than hardware rendering from a programmers perspective since it gives you total freedom to do whatever you want. With software rendering you aren't limited in what sort of texture filtering you can use, what size your textures have to be or the kind of antialiasing you want to apply, heck, you don't even need to use triangles or scanline rasterization at all; you could implement a REYES system or a raytracer or a combination thereof. Much more exciting than having to play by the rules of the graphics hardware.

On the issue if CPUs will ever be able to replace GPUs in the future I say its entirely possible but not the way CPUs are going at the moment. But remember that 10 years in computing technology is a very long time. Unlike some people here I can see a complete architectural shift happening and it would make a lot of sense. Honestly, what sort of problems actually require more computing power? Multimedia applications, image processing, rendering (offline and realtime), games, servers and scientific calculations. What do all of these have in common? They can very easily benefit from massive parallism. There are very few computing problems left that require a lot of power that cannot be run in parallel. Few applications right now would benefit and writing efficient programs on parallel architectures is more difficult but if CPUs do go that way then the programmers will follow.

When I'm talking about a parallel architecture for CPUs I'm not talking about multicore. Its a nice stop-gap solution for the short term but the approach is rubbish in the long term. Once you get to having more than four cores the power drain and heat dissipation are going to be a killer I would imagine and it just feels like a dirty hack. I think we need a completely new CPU architecture; perhaps something like CELL. x86 has to die sooner or later, I just hope that its sooner. You could always keep an emulation layer somewhere for legacy software support even if its not very fast (since most critical legacy apps don't need much speed and those that do are likely to be upgraded to the new architecture anyway; games probably will suffer the most but they evolve so quickly that it shouldn't be a problem for long).

I'm not saying any of this will happen (predictions about technology have a habit of being very inaccurate) but it certainly can happen and if it does it could make software rendering for games viable again. Maybe its just wishful thinking but I'm really hoping for the death of 3d hardware accelerators within the next ten years. When (if!) they go I'll be one of the first to say good riddance!

 

The reason multicore is the future is that it's actually pretty efficient in terms of die space, is fully exposed in software, and is backwards-compatible with previous architectures. In the PC space, we're not going to get anything different any time soon, in terms of parallelism, and neither am I sure that it would be desireable to do so.

Here's what multicore will allow CPU manufacturers to do:

1. Stop focusing so much on the efficiency of a single processing unit. Processors today are mostly serial, and most of their transistors are spent in making that one (well, okay, two: integer and floating point) unit operate at full efficiency. By moving towards a multicore system, once software starts to make use of the multiple processors adequately, it will start to make sense to back off a bit on some of the efficiency improvements that have been made over the last few years, and create instead smaller processing units that have more parallelism.

2. Less need for very high frequencies. Very high frequencies are one of the reasons why power consumption is so high in current designs. By making the CPUs more parallel than serial, CPU manufacturers will be better able to manage heat problems (CPUs will still be hot, of course, in the high-end...).

3. Backwards compatibility! This fact cannot be stressed enough. To put it simply, there is vastly too much money invested in x86 software. You just can't sell a product for the desktop market that doesn't run x86 software fast. But it's really not that big of a deal: multicore CPUs should be good enough.

 

I pretty much agree, at least in the next five years which is a long time in computing, after that I'm not sure. The transition to a true parallel architecture won't be radical if it does come at all, rather it will evolve out of going multicore. Once programmers are used to doing things in parallel on the PC it will be easier to continue to move in that direction.

That's true but how acceptable is it going to be to drop frequencies when introducing multiple cores? Older apps will run slower, which might make the processors look bad initialy. It may be a rough transition or maybe improved processes will cut the power/heat problem while giving similar frequencies with multiple cores? Oh well, I trust that Intel/AMD know what they are doing.

Any new architecture should be able to emulate x86 if some thought is put into making it reasonably efficient. Isn't this what IA64 aka Itanium does? New architecture with x86 emulation? Not exactly a popular chip that one but that's what I'm suggesting could be done.

Good enough for what? I won't be happy until software rendering is feasible again but heck, it might never be. Or maybe it will be that graphics chips become entirely general purpose processors with no fixed functionality that just happen to be suited for graphics (highly parallel, lots of high bandwidth memory on board). I'll be fine with that too. I just think that the most exciting stuff in graphics happens when the programmers have free reign.

 

But all the code between now and then will be compiled on x86 processors, unless there's some amazing move to Linux or some other OS by then....

Right, which is why the move to multicore will be modest at first. Once more and more apps make use of multiple processors, Intel and AMD will slowly scale up parallelism, while either not increasing or decreasing serial performance.

The Itanium is ridiculously slow at emulating x86. This can be done with any architecture, of course, but it won't be nearly as fast as a dedicated x86 processor.

Parallelism. Basically, I don't see why another parallel computing system would be any more efficient than going multicore. All of the other potential benefits of other instruction sets than x86 would just as well benefit as single CPU as a multicore CPU, but as far as parallelism goes, I don't think you can do significantly better than multicore.

There will always be some dedicated hardware in GPU's, for the simple reason that there are some operations that are integral to the 3D pipeline, and are also very amenable to acceleration (triangle setup and texture filtering, for example). Not only that but, apparently, the actual number of transistors dedicated to fixed function-type stuff these days is quite small. I believe I read a number around 10%. If this is the case, then there just wouldn't be much need to get rid of these units: they'll take proportionally less space as time goes on anyway, and so aren't a problem to keep in the chip.

 

Hmmm..... seems to me the whole universe would be better off with more Red Dwarf episodes.......

To smeg with all this PC talk.......

 

But as long as that stays it will pretty much rule out using more "exotic" rendering methods in realtime applications. You are stuck with the triangles, doing things the GPU way. I don't like it. I know it doesn't mean a damn thing, but I don't like it.

Thing is, what apps are there that wouldn't be ported to the new architecture very quickly that are really speed critical and that don't have dedicated systems that won't be upgraded anyway? I can't think of much. Most apps have new versions come out all the time anyway, I just take the move to OSX as an example. Old apps run but not as well as true native apps. Most speed sensitive programs have since been ported. Big deal.

Maybe, I don't know. I actually know very about the inner workings of the CPU and am in no way qualified to make such a judgement. I've just heard a lot about how evil and backwards x86 is over the years so I figure a change would be good. Maybe not. I don't know.

 

No, not necessarily. Just because the hardware is there doesn't mean you absolutely need to make use of it. In the future, it is likely that GPU's will move away from the "vertex processing then pixel processing" sort of nature of things, and work more along the lines of, "Okay, I've got some data to work on now, oh, and here it asks me to call this function that I have implemented in hardware."

1. Don't forget that Apple has a lot more control over their systems, and therefore has the option to break compatibility like this. PC companies don't.
2. Intel has already been trying to do this in the workstation space, but it's proven to be an uphill battle.

I expect it would be a lot more difficult than you would expect. First of all, you would need Windows to be ported to the new CPU architecture. Just look at how long it's been taking Microsoft to port to just the x86-64 architecture, for example. In the meantime, while Microsoft is working on this new architecture, you have to run all old software quickly on the new chip, or else risk not selling very many of them.

I think that the main problem here is drivers. Low-level programming tends to need to be rewritten for low-level programming, and drivers are all low-level. Windows ships with a hell of a lot of drivers.

Right, x86 certainly isn't the best. Current architectures use a ton of transistors to work around the shortcomings of the instruction set. But that doesn't mean parallelism would be any better in any other system.

 

I think it's worth noting as well that today's current "x86" cpus scarcely resemble the x86 cpus of a decade ago. The instruction set obviously isn't restricted to a specific hardware implementation and is separate from it, as x86 cpus today much more closely resemble RISC architectures than their CISC "x86" antecedents. Thus the term "x86" today is far more applicable to being backwards compatible with the instruction set than it is descriptive of general cpu architecture. A decade ago it was widely and erroneously believed that "x86" was inherently CISC, but such was not actually the case, as Intel first proved with the original Pentium. Since then, so-called "x86" cpu architecture has moved further and further away from the traditional CISC x86 cpu architectures with each succeeding generation (especially Athlon.)

With respect to x86-64 support, M$ has two tasks: to seamlessly support IA-32 applications at the same time with little performance loss resulting from the IA-32/x86-64 nature of the OS itself; and x86-64 driver support (which is critical to the success of WinXP64.) My opinion is that M$ has delayed formal introduction of XP64 chiefly for the sake of robust x86-64 driver development & hardware support.

 

The underlying architecture being different from the instruction set is the primary reason why x86 processors waste so many transistors (in the translation layer), and, all other things the same, they also can't be as fast as a more efficient architecture, as if the compiler has more information about the underlying architecture, it can obviously optimize for it more.

 

I think a more interesting question in the mobile space is whether programmable shaders will catch on (like the openGL es 2.0 work is hoping for), and if so, what will the implementation path be? Vertex shaders running on DSP's? Or following the GPU path?

Silicon valley is littered with bad mediaprocessor ideas...

 

I have three questions:
What is the difference between VLIW and Vector processors anyway? Don't both exploit parallelism by letting the software schedule SIMD instructions?

If a processor like Cell is sufficienly fast, why can't it emulate the x86 instruction set like Transmeta does and allow the industry to shift. If Cell can run Windows at half the speed of a 3GHz P4, then it's still pretty usable.

Why is it that computation is benefiting from parallel architectures (relatively lower frequency, more pipes) whereas bus technology is going the other way? Serial ATA and USB are all more serial but higher frequency. Why does parallel buses perform worse than serial ones (at the particular frequencies they can achieve?

 

waitaminute, aren't the first dual-core chips from Intel actually using Pentium-M type cores?

 

In a VLIW architecture, the instructions explicitly schedule the different execution units, a vector processor is just a processor that executes the same code on multiple pieces of data (vectors). The two are not mutually exclusive.

IMO what I've seen of the Cell patents, it will be very fast at a certain subset of problems, but it will not be a particularly fast or efficient for general purpose computing. There are a lot of problems that require fast random access to large datastructures and unless there is a lot more to it than were seeing in the patents Cell is just not built to run these efficiently.