AMD's information on DX12 and new rendering technique for multi-gpu

[PortentousLad]

aahhh @ahhming, I always appreciate the effort you put in your posts. Seems as if people on this forum have lost the drive to make their posts well structured in the past few month.

 

@ DX12 dual-graphics: I remember people saying that APU's are stupid and that having a dedicated GPU is is much smarter, well I got both and I did so for THIS very reason.

 

Only question remaining: "should we start a petition for a remastering of Skyrim with DX12 support?" I'll gladly re-buy the legendary edition at full price if that happened.

... oooooh TressFX in Skyrim... :wub:

[RagnarokDel]

Well it doesn't matter anyways, because I just realized cards that old won't run DirectX 12. Derp.

They're directx11 cards, so they're compatible with directx12.

[DuckDodgers]

The AFR rendering mode is actually a compromise multi-GPU method, introduced for the sole reason because of the positive geometry performance scaling. All the rest screen-splitting methods duplicate the geometry processing across the GPUs and that was a big deal back in the day, when the GPU architectures were limited to one triangle primitive per clock cycle (or every two, in case of the old Nvida GPUs). Now that modern GPUs can process many primitives at once and far more efficiently, it has become a moot point to solely rely on the wasteful and hard to support AFR with all of its drawbacks:

 

• near-zero scaling of the video memory pools -- all the data has to be explicitly duplicated across the GPUs, except for the frame-buffer;
• temporal incoherence -- every GPU renders different frame that requires strict application support in the driver to enable smooth sequencing for every possible game engine and its specific implementation;
•  inevitable input lag, due to the aforementioned AFR nature of multiple frames rendered at different time stamps -- another point for poor scaling with more GPUs;
• strict limitations of what hardware can be paired together -- usually the same model of the same generation;

[cluelessgenius]

"now possible to combine memory pools" - i dont know about you but i find this awesome if true. finally going dual gpu is even more tempting. oh the possibilities. good lord ill have some fun with this if true.

[Arreat]

snip

 

That could be the way they do it , it makes sense .

The question then is how much memory in multi GPU configurations will be gained , since if the tiles are smaller , then even more textures and resources will have to be duplicated on both gpu's . 

I was going very briefly over the documentation of dx12 , regarding resources , it often mentions "heaps" and "pages" , they will serve as containers for multiple resources . Maybe GPU's will be able to adress parts of that heap , reducing the amount of data it will need to store in vram ? I'm just speculating , I have just some surface understanding on graphical api's . 

[Humbug]

the problem with AMD's claim 4+4=8Gb is that for every video card powered by GCN above 1.0 GPU, AMD has renounced to use CFX bridges and the communications is done exclusively via PCIe

1. AMD's chipsets are not PCIe 3.0, but PCIe 2.xThey know that most people who buy high end Radeon GPUs run them with Intel CPUs. And I think they know they have zero chance to regain any of that market share until Zen which will have PCIE3.

[zMeul]

They know that most people who buy high end Radeon GPUs run them with Intel CPUs. And I think they know they have zero chance to regain any of that market share until Zen which will have PCIE3.

the irony of that .. eh  :rolleyes:

[Megahurt]

 

It makes perfect sense as traditionally in a multiple GPU configuration an entire frame gets piped to both cards for rendering. With DirectX 12 only half the frame needs to be sent to each card not only effectively reducing the dependency on VRAM density but also bandwidth requirements on the PCIe interface.

 

Split frame rendering makes sense, sharing vram between gpus does not, because even system ram would be as fast due to the limitations of the pci-e bus.

[Megahurt]

I don't think the frames will actually be "split" since there would be no way to actually determine which resources each card needs to have loaded to actually split the rendering. The frames would probably be done through work queues where each card has a set of resources and is given a job when a draw call uses one of those resources, after all jobs have been completed it would probably be sent to the master card for final image computation.

I don't see a problem at all, it's like if you had two screens and then reassemble them in the main gpu, don't see how it would be more challenging than having two screens for example. Instead of having each gpu process alternate frames of 1080p for example, each would process left or right part in 960x1080, and then both half combined in the main gpu.

[ahhming]

This has probably been asked an answered before, but will DX12 allow vram stacking for nvidia cards?

yes, it is a dx 12 feature and  Fermi, Kepler, and Maxwell GPUs will fully support the DX12 API.

do note that developer have to implement this feature.

[deviant88]

definately buying amd gpu next time if it works as advertised in most games

[trag1c]

I don't see a problem at all, it's like if you had two screens and then reassemble them in the main gpu, don't see how it would be more challenging than having two screens for example. Instead of having each gpu process alternate frames of 1080p for example, each would process left or right part in 960x1080, and then both half combined in the main gpu.

Having two different render targets isn't the issue (this is actually extremely easy). The issue is that you would need to determine which screen would need which assets, which is easy to do but when the requirements of the application are real time then it becomes impossible. Because the creation of resources takes lots of time which is something real time applications don't have. The sheer data requirements are massive for game assets. A single vertex is usually 32 Bytes ( assuming Position, Normals and  2 UV coordinates), an index for a that model could be about 4 Bytes, I don't even want to start on textures. A low poly model could be 500KB alone without textures.

 

EDIT: Forgot to mention this but if you want to run at 60FPS then you would only be able to transfer 268.8MB of data across PCI-E x16 3.0

 

My point is resources need to be created once and then left in GPU memory since transferring them around each frame would be impractical given current PCI-E speeds. Not only that I would imagine to transfer resources it would first need to be transferred to RAM which is crazy slow then it would need to be transferred into the other GPU. This is why the resources are mirrored in the GPU's so that they don't face this problem.

[Briggsy]

Can't wait to see tress FX 3.0 in action. Hair Effects that runs well on both AMD and Nvidia is so much more appealing than dealing with over-tessellated hairworks. Although, I'm curious if Adam Jensen's hair is even able to move, given the sheer amount of Hair Glue he uses.

[SIGSEGV]

This sounds cool... Looks like AMD will really be taking advantage of DX12

[bcredeur97]

SFR is great but I bet its going to open up a whole new world of problems. 

[Warren Pnigel]

yes, it is a dx 12 feature and  Fermi, Kepler, and Maxwell GPUs will fully support the DX12 API.

do note that developer have to implement this feature.

Hopefully that mean's I'll have more than 3.5gb of vram then lol

 

no h8 nvidia