palladin9479 :
hcl123 :
palladin9479 :
You do realize that 99%+ of PC games are released on Windows and the primary function for GPU's is gaming. Consoles are consoles, they'll be coded for hardware and I expect them to make the most out of it. Consoles also have extremely low hardware performance due to cost limitations, they rely on coding to hardware to maximize their performance.
HUMA does absolutely nothing for abstracted graphics languages like DirectX / OpenGL. There could be some "magic" happening at the driver layer with memory mapping to speed things up, I expect AMD to do this with their APU drivers.
Please people, learn some ASM and how things actually get done on a system. You can't magically throw acronyms at something and expect results. We don't live in an ideal world where each generation gets to start fresh. In Microsoft made their money by offering this thing called "Backwards Compatibility" which pretty much dominates the industry.
I think that is not entirely correct. There is no silver bullet, but many effects and "physics" can benefit greatly if codded with HUMA in mind, specially if using either the CPU as well the GPU, and even if the majority of the game code is as usaully JITed and only the driver does its thing. Also there are "task" queues visible from user-space. Now this could be very interesting, only is not about hUMA is about HSA... HSA games !
And none of that applies to abstracted graphics API's like DirectX and OpenGL. Specifically the parts that are shipping data off to the GPU to be drawn / shaded / ect. Things like HSA / HUMA are applied at a very low level, damn near bare metal level. In HLL's and abstracted layers you don't work directly with hardware addressing or even opcodes. This is really gamer's territory but I do know that both graphics API's must work under the assumption that the GPU is a separate entity to maintain compatibility with dGPU's. This makes many of the aforementioned assumptions impossible, at least at the application level. You won't be using HUMA on a PC to make rendering graphics faster. Consoles are a different story, but definitely not PC's.
From the systems point of view a bolted on non-X86 vector processor is just a coprocesor similar to the SIMD units. If their using a bolt on scheduler then it'll just act like a 16x or 32x shared 128-bit FPU unit, if their addressing it as a separate unit entirely then you'll need compiled binary code to make use of it. 99% of the consumer software is not JAVA or any other JIT language, it's compiled for binary before it ships from the manufacturer. The closest you get is the DirectX / OpenGL API's, but those are done by the graphics drivers made from AMD / Nvidia, not even developers get to see inside them.
This is entirely true...
@juanrga:
I think what you're missing, and what palladin9479 is trying to explain, is simply this (as best I can describe it):
The "scalar" cores or integer cores, can do physics calculations, but it would be like using an abacus to do math. Can you get there? Sure, eventually...however, it's not efficient.
The "vector" instruction units, or FPUs, do physics, etc. extremely well...like supercomputer capability in a smaller scale sense. However, the FPU is not capable of basic scalar operations. It's like trying to get an x86 OS to run on a POWER architecture machine. It's not going to happen. They don't speak the same language. In a sense, it's simply not made to do those things, and hypothetically, even if you could get it to do serial/scalar operations, if you managed it. The FPU would be so horrible at it, it wouldn't even be worth the effort to get there.
HSA is going to bridge a gap in many ways, however, only vector instructions are going to be shared. GPUs/FPUs do not do integer calculations for s#!%, for lack of a better layman term.
So, it's like you're talking past each other. You're not grasping what he is saying, and he is hearing the same thing back from you as you said before.
Basically, HSA will only be effective in situations where the software/code is compiled for it, and it will only show massive performance gains in situations where there are a massive numbers of array calculations/vector instructions.
Additionally...DX and OpenGL, etc. are not going to see massive benefits from HSA initially. In fact, I would doubt either one would see much benefit for a while, here's why:
M$ isn't going to give a rat about putting HSA enabling improvements into DX API, primarily because they're never in a hurry to do anything, and are typically too lazy to optimize for something that doesn't show them a direct cash benefit.
On the other hand, OpenGL is run by the Khronos Group...and while they have their heart in the right place (most of the time), they're too discombobulated and lackadaisical to actually get anything done in a time frame that would even remotely be relevant at all. In other words, when DX12 hits with full HSA enabled optimization in the DX dev tools, then OpenGL will likely "be looked at" to keep up with DX12. They don't care much for innovating anymore, they just want to avoid falling too far behind DX and M$.
As much as I wish OpenGL was a better API, unfortunately, it has just been left languishing in the hands of inactive or incompetent people who have had no motivation to innovate, and cannot agree on how to fix it. So they keep bolting on new crap on top of the old stuff and nothing is ever streamlined or made to work coherently. Additionally, it's hard to even get a consensus among people who develop with OGL regularly as to what is the best way to do anything, because you can typically do the same thing 5 different ways, and none of them are the fastest or the easiest.
HSA will be a benefit in gaming at some point in the future, and may streamline some things in the way games work now, by removing some "minor" bottlenecks on a very low level, however, many games will not be optimized to use it to it's full potential until it has the full backing and optimization from the APIs used to develop AAA titles in the modern gaming world.
Hence my argument that I still need an 8 core CPU, because most of the crap I run, will likely see less benefit of HSA than even some of the things your typical PC user will. Specialized tools are often neglected in favor of mainstream applications and software in this regard unless the demand is extremely high. In this case, the demand won't be that high for a while likely as most development houses have top notch machines in place that can currently do nothing with hUMA or HSA.