gamerk316 :
A GPU core is ALWAYS going to be slower then a CPU core, simply due to design. The ONLY reason a GPU is faster is because they have upwards of 1000 cores, and in highly parallel work where all those resources are used, ends up outperforming 4 core CPUs.
From a CPU's perspective, it is simply executing a stream of instructions. The CPU is more or less blind to how those instructions are organized, and thus can't make assumptions about if the instructions in question are better run on an iGPU or not. That type of data handling is ALWAYS going to be done user level, either by the developer or the compiler.
And in both cases, you have to consider the varying performance differences between the CPU/GPU when deciding whether to offload work or not. The Dolphin Emulator, for instance, has options to use both OpenMP and OpenCL for texture decoding, and typically, on my system (2600k and 770 GTX), both slow the emulator. With a weaker CPU though? Maybe those will result in a speedup. So even making hardcoded assumptions will cause problems. Just look at the idTech5 engine and listen to how people react when their performance options are automatically chosen for them in a sub-optimal manner.
Hence why HSA is a pipe dream: You need the devs to support it. And if Intel isn't on board, then its not going to be universally adopted. If AMD's strategy is built around HSA being widely adopted, then they've already failed. Devs do not go out of their way to support processing for the minority. In specialized software? Sure, since there's a market there. But in the real world? No.
Its this same reasoning why I called BD's design a failure two years ahead of time, because irrespective of anything else, low performance cores that mandated significant CPU threading of typically non-threadable tasks to make up its per-core performance deficit was NOT going to happen. Same concept here.
Bulldozer was a fiasco because it was a unbalanced (and even self-contradictory) design and its defects were amplified by Glofo underperforming SOI process. It has nothing to do with heterogeneous computing; in fact, Bulldozer is an homogeneous computing arch.
Traditional silicon scaling is dead. Those few dreaming with a single core @ 100GHz can continue dreaming. It is well-understood that the only way to improve performance significantly is towards parallelism: e.g. 100 cores @ 1GHz.
CPUs are terribly inefficient at parallel workloads. On the other hand, GPU cores are designed for optimal throughput per watt and throughput per area. A GPU core that was "slower" but occupies double space than a CPU core or consumes 50% more power would be completely useless.
When you claim that the developer has to select what computation is made on the CPU and what computation is "offloaded" to the GPU, you are referring to the traditional accelerator approach to GPGPU, where the GPU is a second class processor (a co-processor) slaved to the CPU (first class).
This is
not what HSA is about. In essence, HSA is about upgrading GPUs status to
first class processors, i.e. at same level than CPUs.
The claim that the decision to where run instructions in an heterogeneous system is "ALWAYS going to be done user level" is untrue. There are a strong heterogeneous compute research on how do this at kernel level. Different schedulers are being invented and researched which select where to run the instructions according to several parameters such as raw performance, power consumption... The final goal is that the operative system decides what part of an heterogeneous system is best suitable to run a given work.
Of course those automatic decisions can be overdrived by the developer (compiler directives) or by the user (OS tunning), if needed. The HSA spec. defines a HSA-kernel with a HSA-aware scheduler which:
The scheduler manages scheduling and context switching of TCU jobs. Scheduling in HSA can be
performed in software, in hardware, or in a combination of both. An HSA implementation can choose how
to split scheduling work between software and hardware to best match system requirements.
I don't know why you insist on mentioning that devs need to support new hardware. This is a general rule since computers were invented and it also applies to HSA. You are not saying anything new. In fact, the HSA manual says:
HSA is a system architecture encompassing both software and hardware concepts. Hardware that
supports HSA does not stand on its own, and similarly the HSA software stack requires HSA-compliant
hardware to deliver the system’s capabilities.
What do me suspicious is that you never use your developers-argument against Nvidia or Intel. When Nvidia develops a new graphics architecture with new features, these have to be supported by developers. DX12 will support new hardware features not supported by DX11 for instance. The same about Intel, if Intel introduces new AVX instructions on hardware, developers have to support them. E.g. you need software prepared for the new Haswell instructions if you want use them.
You are making the mistake of believing that HSA is a only-AMD thing, when HSa is being developed by the HSA Foundation, which includes members that are more bigger than Intel. What you call "minority" is in reality the majority in terms of market share. Intel is considered the underdog in mobile. The success of HSA is independent of if Intel decides to join the foundation or not; this is the same that happened with x86-64, which was a success even with Intel initially rejecting it. Latter, Intel had to reconsider its position and adopt x86-64 due to its increasing popularity.
Finally, I find amazing your comment that HSA is not for the "real world". Thus according to you LibreOffice, WinZip, Adobe Premiere and Photoshop, Linux, Java 8, OpenCL 2.0... all them must be products for some fictitious universe, right?
Ok, then you must also pretend that the next recent HSA demos
http://semiaccurate.com/2014/04/16/amd-demos-fedora-running-arm-hsa-chips/
http://arstechnica.com/information-technology/2014/04/amd-demos-hsa-for-the-server-room-with-java-on-top/
were run in another universe.
Facebook
Twitter
Instagram