will graphics functionality be a part of the CPU instruction set?
- Thread starter Techno+
- Start date
Admittedly I haven't seen anything about this "Fusion Unfolding" you mention, but I really don't understand this repetitive thing about CPU's becoming GPU's :smile:
CPU's are general-purpose processors. They are good because, whilst good at some specific tasks, they are good all-round processing units. They handle the whole turing-complete and computable problems thing quite nicely. Ever heard the phrase "Jack of all trades, master of none"?
A CPU is therefore perfectly capable of doing graphics processing - look at all of the software rasterizers and ray-tracers that still keep graphics programmers entertained
GPU's are highly specialised pieces of hardware. Yes, they share much in common with CPU's but the reason they whup the CPU's ass when it comes to performance is because they are specifically designed to do one thing extremely well (yes, you can argue that they're becoming more mainstream, but I've discussed this in another thread recently...).
I remember having a lecturer at university openly laugh at people using Intel and AMD desktop computers to do decryption/encryption for secure communication. She went on to say that the security company she worked for had dedicated hardware specifically designed to handle encryption and related problems. It was rubbish at everything else but was an order of magnitude faster for encryption related tasks. In the same way as my previous point, sure a CPU can do encryption stuff but a dedicated chip can do it much better.
Okay, to get back to your point ....
Why would you want it to be part of the CPU's instruction set unless you actually wanted the CPU to execute it? I suppose if you had some sort of super-chip that was a CPU and GPU combined then maybe... but even then I'd be sceptical of whether you'd actually want them to share an instruction set.
Jack
CPU's are general-purpose processors. They are good because, whilst good at some specific tasks, they are good all-round processing units. They handle the whole turing-complete and computable problems thing quite nicely. Ever heard the phrase "Jack of all trades, master of none"?
A CPU is therefore perfectly capable of doing graphics processing - look at all of the software rasterizers and ray-tracers that still keep graphics programmers entertained
GPU's are highly specialised pieces of hardware. Yes, they share much in common with CPU's but the reason they whup the CPU's ass when it comes to performance is because they are specifically designed to do one thing extremely well (yes, you can argue that they're becoming more mainstream, but I've discussed this in another thread recently...).
I remember having a lecturer at university openly laugh at people using Intel and AMD desktop computers to do decryption/encryption for secure communication. She went on to say that the security company she worked for had dedicated hardware specifically designed to handle encryption and related problems. It was rubbish at everything else but was an order of magnitude faster for encryption related tasks. In the same way as my previous point, sure a CPU can do encryption stuff but a dedicated chip can do it much better.
Okay, to get back to your point ....
Why would you want it to be part of the CPU's instruction set unless you actually wanted the CPU to execute it? I suppose if you had some sort of super-chip that was a CPU and GPU combined then maybe... but even then I'd be sceptical of whether you'd actually want them to share an instruction set.
Jack
Anarchist4000
Veteran
I think you took 'unfolding' slightly out of context there. He meant details coming out, not some form of performance enhancing technology.
I think taking a CPU down to a simple 'single core' style chip with a stream processor(GPU) attached and adding instructions to it might not be a bad idea. Replace the SSE/MMX instructions with stream processing related instructions and it could be beneficial. Even if you end up with instructions that act more like shaders than simple math operations etc.
I think taking a CPU down to a simple 'single core' style chip with a stream processor(GPU) attached and adding instructions to it might not be a bad idea. Replace the SSE/MMX instructions with stream processing related instructions and it could be beneficial. Even if you end up with instructions that act more like shaders than simple math operations etc.
I could see this being the case for low end type stuff. Maybe even heterogeneous multiprocessiing where one of the cores has an ISA extension for triangle rasterization interpolation, and texture sampling. D3D driver almost written as a software rasterizer but exploiting the ISA extensions to access these 'accelerator units' for speed. Data parallelism would also need to be there as well. Perhaps more value could be extracted from a 3D processor that was built this way, being used as a second core when 3D is not running, or turned off completely. This is where I see a GPU/CPU merging into a single ISA. Where performance isn't critical, and adding value to the 3D hardware by having it used for more than one purpose (3D graphics). If its going to behave like a CPU, its giong to be treated like one (software-like rasterization driver, with some inline assembly calls to acceleration units).
maybe if stream processors are added to future CPUs, with the CPUs having 16 to 32 simple cores, Graphics processing will easily be done on the CPU, or we can have CPUs using vector units, something like hte alpha ev-9 proposal, and there are some plans by intel to actually implement this in Nehalem. In fact, I think it is better to have vectir units IMO, since it will be easier to program them.
G80 exposes itself to the programmer as having only scalar units, which makes it significantly easier to program efficiently. So I'm not sure what you're thinking of here...
Uttar
G80 exposes itself to the programmer as having only scalar units, which makes it significantly easier to program efficiently. So I'm not sure what you're thinking of here...
Uttar
then if this is the story then i apologise
i got this form arstechnica
'"Newell even talked about a trend he sees happening in the future that he calls the "Post-GPU Era." He predicts that as more and more cores appear on single chip dies, companies like Intel and AMD will add more CPU instructions that perform tasks normally handled by the GPU. This could lead to a point where coders and gamers no longer have to worry if a certain game is "CPU-bound" or "GPU-bound," only that the more cores they have available the better the game will perform. Newell says that if it does, his company is in an even better position to take advantage of it."'
so what i am saying does make sense.
'"Newell even talked about a trend he sees happening in the future that he calls the "Post-GPU Era." He predicts that as more and more cores appear on single chip dies, companies like Intel and AMD will add more CPU instructions that perform tasks normally handled by the GPU. This could lead to a point where coders and gamers no longer have to worry if a certain game is "CPU-bound" or "GPU-bound," only that the more cores they have available the better the game will perform. Newell says that if it does, his company is in an even better position to take advantage of it."'
so what i am saying does make sense.
Multi core will solve everything!? There's a thing called Amdahl's law (http://en.wikipedia.org/wiki/Amdahl's_law) which inherently limits the maximum performance gain buy adding N processors/cores. Graphics is inherently parallel, general applications are not. And as everyone has probably figured out it's not just about vector vs. scalar...
What is the general idea about implementation of this? You have 32 cores and each one of them also has say a G80 stream processor in it? Where is the gain in that? You could probably take a "Core 2 128" CPU and it would still loose against G80 doing rendering.
Or is it just that CPU guys are running out of ideas what to do with all those cores?
P.S.: Perhaps a better way to think... CPU-s always do something like: instruction fetch -> instruction decode -> data fetch -> execute -> write back... Now think about how do you fit a graphics pipeline into this (even a unified one).
What is the general idea about implementation of this? You have 32 cores and each one of them also has say a G80 stream processor in it? Where is the gain in that? You could probably take a "Core 2 128" CPU and it would still loose against G80 doing rendering.
Or is it just that CPU guys are running out of ideas what to do with all those cores?
P.S.: Perhaps a better way to think... CPU-s always do something like: instruction fetch -> instruction decode -> data fetch -> execute -> write back... Now think about how do you fit a graphics pipeline into this (even a unified one).
Last edited by a moderator:
What Newell says is technically possible, but it's not certain how much will actually change. Moving GPU functionality to the CPU would only be done if it makes sense with respect to performance (or possibly power, but that won't help Newell) to do so.
I'm not sure what functionality he thinks can be moved, or why it matters now as opposed to when the CPU and GPU were on separate chips.
Moving the GPU and CPU cores onto the same die is hardly a guarantee of good graphics performance, and the apparent target for chips like those for the Fusion line seems to indicate that top performance is not likely when they are.
Certainly the programming model needs to change, that's not in question. However there are many algorithms that can be formulated with increasingly small scalar parts (some even with no scalar parts) that can benefit hugely from more processors. I don't think it's too much of a generalization to state that there are very, very, few problems actually that seem to simply resist parallelization. Sure not everything is as simple as graphics or physics, but many things can be solved efficiently by parallel processors. For example, something as simple as sorting has several efficient parallel algorithms to solve it.
Thus I agree that multicore processors are not the solution by themselves... indeed task parallelism is only really useful in the short term, but data parallelism - and parallelism in general - is quite powerful, and certainly here to stay.
I think that's about right, but there are certain problems that do seem very resistant to parallelization.
Compression is one of them, or at least a lot of compression methods do not compress as well if they are parallelized.
MP3 encoding as it is done by LAME is one of those tasks that is only partially threadable, as the Huffman encoding used leads to a serial dependency between audio frames. There are ways to break the dependency, but they compromise quality relative to a serial version, all else being equal.
arjan de lumens
Veteran
Exactly. In the majority of cases I have seen, lack of parallellism arises as a property of a given solution to a problem and not at all as a fundamental property of the problem itself; this is probably the main reason why I usually tend to dismiss references to Amdahl's law as useless handwaving. (It's not the law per se that I see as wrong-headed, but rather people's expectations about what sub-problems one can and cannot move out of the "serial part".)
Many cases of apparently-serial algorithms can be parallellized by using e.g. the "Parallel Prefix" algorithm or replacing underlying data structures; other times, non-parallellizable solutions arise because of excessive antidependencies (in-place variable update), or other failures to do proper alias analysis (forcing the programmer to be excessively conservative wrt introducing parallellism).
Sure, that's true. We should spend alot more time thinking how to make algorithms more parallel.
I just don't see why people think we should jump straight to graphics. It's the simplest way sure, but is currently done by GPU which is way more parellel then CPU currenty is and will probably be for the next 10 years or more.
I just don't see why people think we should jump straight to graphics. It's the simplest way sure, but is currently done by GPU which is way more parellel then CPU currenty is and will probably be for the next 10 years or more.
Even for algorithms which on the face of it are emminently parallelisable the real-world scaling can be bounded by the requirements for inter-process(or) communication, eg. the requirement to synchronise between the sub-problems at the end of a timestep during numerical integration, or to exchange state or other information at the domain boundaries.
The synchronisation overhead may become a non-issue if the application programmer has very tight control over the scheduling of all of the work on the compute units, as might be the case on a GPU-like system, but may not be true on a multi-core CPU where work is scheduled by the operating system kernel.
The synchronisation overhead may become a non-issue if the application programmer has very tight control over the scheduling of all of the work on the compute units, as might be the case on a GPU-like system, but may not be true on a multi-core CPU where work is scheduled by the operating system kernel.
If you think Huffman is tough to parallelise, try arithmetic/range encoding!
you are completely wrong, since all experts say that in 6 years grafix card will be obselete.
That doesn't sound right at all. I can't rule out something revolutionary, but that really seems unlikely in such a short time frame.
