Kaveri/Huma and Light Gaming

[NTMBK]

hUMA means nothing graphics wise. Its computational only.

Actually, would hUMA not make massive "Megatextures" (to use the Carmack word) much easier to deal with? (Note: this is just a guess, as I am not a games developer. 🙂 )

 

[zlatan]

Actually, would hUMA not make massive "Megatextures" (to use the Carmack word) much easier to deal with? (Note: this is just a guess, as I am not a games developer. 🙂 )

Yes, hUMA is great for virtual texturing.

 

[Gikaseixas]

hUMA means nothing graphics wise. Its computational only.

Same reason why graphics and hUMA is non related on all AMD slides.

Are you stating that it won't have any effect on 3D rendering?

 

[frozentundra123456]

Yes, hUMA is great for virtual texturing.

Is there any software written yet that shows this, or is it all theoretical?

 

[Gikaseixas]

Is there any software written yet that shows this, or is it all theoretical?

http://www.extremetech.com/gaming/1...u-memory-should-appear-in-kaveri-xbox-720-ps4

“Game developers and other 3D rendering programs have wanted to use extremely large textures for a number of years and they’ve had to go through a lot of tricks to pack pieces of textures into smaller textures, or split the textures into smaller textures, because of problems with the legacy memory model… Today, a whole texture has to be locked down in physical memory before the GPU is allowed to touch any part of it. If the GPU is only going to touch a small part of it, you’d like to only bring those pages into physical memory and therefore be able to accommodate other large textures.

With a hUMA approach to 3D rendering, applications will be able to code much more naturally with large textures and yet not run out of physical memory, because only the real working set will be brought into physical memory.”

 

[frozentundra123456]

http://www.extremetech.com/gaming/1...u-memory-should-appear-in-kaveri-xbox-720-ps4

“Game developers and other 3D rendering programs have wanted to use extremely large textures for a number of years and they’ve had to go through a lot of tricks to pack pieces of textures into smaller textures, or split the textures into smaller textures, because of problems with the legacy memory model… Today, a whole texture has to be locked down in physical memory before the GPU is allowed to touch any part of it. If the GPU is only going to touch a small part of it, you’d like to only bring those pages into physical memory and therefore be able to accommodate other large textures.

With a hUMA approach to 3D rendering, applications will be able to code much more naturally with large textures and yet not run out of physical memory, because only the real working set will be brought into physical memory.”

So the answer is "no".

 

[Gikaseixas]

No soft available but upcoming OS's will support and devs must be working hard at it

 

[LegSWAT]

So the answer is "no".

So yes, the answer is no. We'll see this stuff in next-gen console games in a not too distant future.

 

[ShintaiDK]

Actually, would hUMA not make massive "Megatextures" (to use the Carmack word) much easier to deal with? (Note: this is just a guess, as I am not a games developer. 🙂 )

It might be as useful as 3DNow! and SSE5 if you get my drift. Unless console ports somehow transfers this to the PC. But that leaves any dGPU out of it and any Intel product.

 

[Gikaseixas]

It might be as useful as 3DNow! and SSE5 if you get my drift. Unless console ports somehow transfers this to the PC. But that leaves any dGPU out of it and any Intel product.

The industry might have to follow AMD here, just like the 64bit deal

 

[ShintaiDK]

The industry might have to follow AMD here, just like the 64bit deal

Thats the question. Also hUMA is not exactly dGPU friendly.

And unlike 64bit, hUMA is far from as important. We can only wait and see how it turns out. It might also simply be replaced by something else.

 

[zlatan]

... But that leaves any dGPU out of it and any Intel product.

Why? A software solution for virtual texturing is already working on non-hUMA hardwares. Rage for example.

The tiled resources function in DirectX is also works with any hardware. There are three tier for it. One software and two hardware solutions (a limited tier1 option for Kepler, and a full feature set tier2 option for GCN, and also for the consoles). If you use a Granite middleware for it, than the compatibility won't be a problem.

 

[ShintaiDK]

Why? A software solution for virtual texturing is already working on non-hUMA hardwares. Rage for example.

The tiled resources function in DirectX is also works with any hardware. There are three tier for it. One software and two hardware solutions. If you use a Granite middleware for it, than the compatibility won't be a problem.

But performance could be. Its abit like the PhysX GPU vs CPU.

 

[NTMBK]

It might be as useful as 3DNow! and SSE5 if you get my drift. Unless console ports somehow transfers this to the PC. But that leaves any dGPU out of it and any Intel product.

Hah, yeah. Depends how it is exposed in a software API.

I am specifically thinking about DirectX 11.2's partially resident textures. On a dGPU that would mean streaming portions of texture across the PCIe bus, but I would presume that AMD's driver for their APU would use HUMA behind the scenes.

 

[zlatan]

But performance could be. Its abit like the PhysX GPU vs CPU.

There are performance differences, but not that dramatic. The main limitation for the software solution is the shader based anisotropic filtering, which is a very costly effect if the engine can't do it in hardware, but bilinear filtering is a cheap solution.
The tier1 and tier2 options are support hardware anisotropic filtering. The tier2 level also support shader feedback instructions and tile pool.

 

[SammichPG]

Thats the question. Also hUMA is not exactly dGPU friendly.

And unlike 64bit, hUMA is far from as important. We can only wait and see how it turns out. It might also simply be replaced by something else.

The vast majority of CPUs on the market have an igp, let's dream of a day when we'll care about a dGPU as much as we care for discrete sound cards (Only if you're a professional or audio enthusiast).

Even if that day won't come we should be able to use the igp as a computational coprocessor for latency sensitive stuff while leaving an external gpu to other tasks... sort of an hybrid sli/crossfire setup.

4k is very far ahead from mass market, igps are getting fast enough for 1080p (already are for many games and quality settings) and we haven't started playing with stacked chips and ddr4 yet.

The computer industry is on a one way trend to integrate everything because it's cheaper to manifacture, it's just a matter of time.

 

[Gikaseixas]

Thats the question. Also hUMA is not exactly dGPU friendly.

And unlike 64bit, hUMA is far from as important. We can only wait and see how it turns out. It might also simply be replaced by something else.

Every manufacturer wants to integrate, wants to simplify and HUMA is just a part of that process for AMD. Both Intel and AMD are in a tight race for IGP crown so i don't know how a person as knowledgeable as you could dismiss HUMA's importance.

 

[NTMBK]

Every manufacturer wants to integrate, wants to simplify and HUMA is just a part of that process for AMD. Both Intel and AMD are in a tight race for IGP crown so i don't know how a person as knowledgeable as you could dismiss HUMA's importance.

No, it's fair enough that it may not have much importance as exposed through any AMD proprietary API- the comparison to 3DNow! is apt, AMD just don't have enough penetration to make it universally adopted. But as wrapped in some commonly used API like DirectX, it will be a very useful tool.

 

[AtenRa]

No, it's fair enough that it may not have much importance as exposed through any AMD proprietary API- the comparison to 3DNow! is apt, AMD just don't have enough penetration to make it universally adopted. But as wrapped in some commonly used API like DirectX, it will be a very useful tool.

AMD is not alone this time, HuMA is not 3DNow. HSA/HuMA has ARM, SAMSUNG, Qualcomm, TI and more behind it. This time AMD made the right move.


ps: HuMA can make the cooperation of x86 and ARM cores working together in the same IC/SoC possible(Kaveri + ARM), also dGPUs can benefit from it as they could use/share System ram with the APUs.

 

[ShintaiDK]

AMD is not alone this time, HuMA is not 3DNow. HSA/HuMA has ARM, SAMSUNG, Qualcomm, TI and more behind it. This time AMD made the right move.

Being behind something is cheap PR. What products do they have in the pipeline?

ps: HuMA can make the cooperation of x86 and ARM cores working together in the same IC/SoC possible(Kaveri + ARM), also dGPUs can benefit from it as they could use/share System ram with the APUs.

No they cant. They use different memory archs. You cant replace the x86 core in kaveri for example with ARM and still have hUMA working. You also need a different CGN then.

 

[AtenRa]

Being behind something is cheap PR. What products do they have in the pipeline?

Being negative doesnt make it PR either. As for the products, when they will be ready they will announce them.

No they cant. They use different memory archs. You cant replace the x86 core in kaveri for example with ARM and still have hUMA working. You also need a different CGN then.

Yes they can, they both could use the same System memory. Also, If the ARM core can use HuMA it could work with any other arch.

You better read about HuMA again. Here is a nice little article,

http://arstechnica.com/information-...orm-memory-access-coming-this-year-in-kaveri/

 

[ShintaiDK]

Are you saying ARM and x86 accesses memory the same way? And you can reuse the GCN block for hUMA?

Maybe you should check how ARM maps memory vs x86.

 

[AtenRa]

Are you saying ARM and x86 accesses memory the same way? And you can reuse the GCN block for hUMA?

Maybe you should check how ARM maps memory vs x86.

I said they could use the same System memory without the need to copy each time from one to the other.

It is, however, a problem for traditional CPU/GPU designs. As mentioned before, in traditional systems, data has to be copied from the CPU's memory to the GPU's memory before the GPU can access it. This copying process is often performed in hardware independently of the CPU. This makes it efficient but limited in capability. In particular, it often cannot cope with memory that has been written out to disk. All the data being copied has to be resident in physical RAM, and pinned there, to make sure that it doesn't get moved out to disk during the copy operation.
hUMA addresses this, too. Not only can the GPU in a hUMA system use the CPU's addresses, it can also use the CPU's demand-paged virtual memory. If the GPU tries to access an address that's written out to disk, the CPU springs into life, calling on the operating system to find and load the relevant bit of data, and load it into memory.

HSA isn't just for CPUs with integrated GPUs. In principle, the other processors that share access to system memory could be anything, such as cryptographic accelerators, or programmable hardware such as FPGAs. They might also be other CPUs, with a combined x86/ARM chip often conjectured. Kaveri will in fact embed a small ARM core for creation of secure execution environments on the CPU. Discrete GPUs could similarly use HSA to access system memory.

 

[ShintaiDK]

hUMA doesnt allow ARM and x86 to work together. And ARM cores in x86 products is nothing new.

And that ARM core in Kaveri sounds like nothing else than integrated TPM. Something AMD havent produced itself yet. Previous they use an ARM chip via the LPC.

 

[zlatan]

Being behind something is cheap PR. What products do they have in the pipeline?

The Xbox One and PS4 support HSA. There will be complete developer tools for these in 2014.

HSA-compatible coprocessors from ...:
AMD - GCN IP with AMD64 ISA
ARM - Mali-T600 Series IP with ARMv8 ISA
Imagination - PowerVR G6000 Series IP with ARMv8 or MIPS64 ISA
Qualcomm - Adreno 400 Series IP with ARMv8 ISA
Vivante - GC"next" series IP with ARMv8 ISA

HSA-compatible HSA-MMUs from ...:
AMD - IOMMUv2.5
ARM - CoreLink MMU-500