OCN via Twitter: AMD Mantle First Graphics API To Allow Multi GPU VRAM Combinations

[artivix]

Poster on OCN has Twitter from AMD's Rob Hallock stating that Mantle API will provide for utilizing all VRAM in multi-GPU setup! Current Xfire/SLI setups wasting half VRAM now, will be able to utilize all memory in upcoming Mantle software.


http://www.overclock.net/t/1539218/...antle-allows-adding-vram-on-multi-gpu-configs

 

[SlowSpyder]

That'd be great if true. Something like two R9 290's will have a longer future for those who keep their cards if the ram can stack vs. having to mirror data.

 

[ShintaiDK]

How would people imagine it to work anyway? Because the PCIe bus isnt going to cut the requirements.

Both cards still need the textures loaded, scene setup, lightning etc.

It way use a little less with SFR as Civ BE uses. He only says AFR cant use more than 4GB in his tweets.

Depends entirely on how the dev does the game. If it's AFR rendering, it's mirrored 4GB. If it's not AFR, it COULD be full 8.

No numbers, no slides, no examples. Honestly sounds like a BS statement again.

 

[SPBHM]

vram can be over 200GB/s, accessing the other card (PCIE) is what? less than 15GB/s, how would that work?

 

[NTMBK]

Thing is, most things will need to be mirrored anyway for high performance. Most objects in the scene will need to be present on both GPUs (both geometry and textures), unless you aggressively cull based on which half of the screen the object will be present in- and then be willing to swap the memory back in when the viewer shifts his view right by 1 degree. That sounds like a performance consistency nightmare.

Sure, you can have half-sized framebuffers on the GPUs, but don't expect them to magically double the amount of available VRAM. And don't forget that they will still need one fullsized RGB framebuffer on one card to stitch the two final rendered images together to display onscreen.

 

[96Firebird]

Anything is possible, let's see it in use!

 

[Creig]

I was intrigued by the very last sentence in the very last paragraph:

Ultimately, the point is that gamers believe that two 4GB cards can't possibly give you 8GB of useful memory. That may have been true for the last 25 years of PC gaming, but that's not true with Mantle, and it's not true with the low-overhead APIs that follow in Mantle's footsteps.

The only "low-overhead API that follows in Mantle's footsteps" that I can think of would be DX12.

 

[night.fox]

Oh come on people. If this is true and they could deliver it, it will benefit alot on people who has multi-gpu configuration.

Which means alot will be attracted to opt for multi-gpu. More sales for AMD.

 

[Paul98]

He isn't saying that each card has access to the other card's vram quickly actually he says that's a problem right in the first paragraph. Rather that the developer now can control the vram of multiple cards. Which I thought was already known given that you can control multiple cards to do different things at once.

 

[2is]

My initial reaction was "awesome!" but after reading some of the more technical details/issues surrounding this, my excitement has been nerfed. Would have been nice if DX12 stretched the useful life of my 2GB 680's but I doubt that's going to happen given the technical hurdles.

 

[Dribble]

It doesn't "double you memory", I think all this means is a dev if they really wanted can specify which gpu's memory to send something too.

I don't see any problem with them enabling this over Mantle, highly unlikely anyone will ever use it however. If mantle is only available to a small % of the user base, and an even smaller % of them use Xfire exactly how many people would a dev be developing for if he wrote a custom multi gpu mantle memory routine? How much benefit would it give anyway, can't be that much as most rendering requires all the same stuff on both cards?

So what dev is going to spend time and money developing something that gives a small performance boost to a tiny group of people?

 

[njdevilsfan87]

I'm actually kind of disappointed that AMD is trying to hype it like this - as if anyone is going to bother trying to render in parallel beyond basic split frame imaging (which is going to be negligible in VRAM savings).

SFR is a good push, but saying CF is going to effectively be able to use all the of VRAM is even more misleading than a GTX 970 being advertised as a 4GB card.

 

[Gikaseixas]

saying CF is going to effectively be able to use all the of VRAM is even more misleading than a GTX 970 being advertised as a 4GB card

Really? They haven't even been caught lying like NV did, so aren't you jumping the gun? Give them the benefit of the doubt

 

[mindbomb]

It's possible, but it's a lot of work, and it only helps a small subset of those who are capable of using mantle, which in turn is relatively small. I really doubt people are gonna put the effort into doing it. Also, performance scaling is something that can also be better than current AFR, that's probably the more exciting aspect of the new multi gpu methods.

 

[Gikaseixas]

yeah i still need to see it to believe it, keeping my mind open about this.
This is certainly a boost for multi GPU users if true

 

[Paul98]

How it would get into games is by AMD and it's partners implementing it's use it into a branch of the game engines that use mantle.

Then those using the engine could decide if they want to add that feature.

 

[Paul98]

I'm actually kind of disappointed that AMD is trying to hype it like this - as if anyone is going to bother trying to render in parallel beyond basic split frame imaging (which is going to be negligible in VRAM savings).

SFR is a good push, but saying CF is going to effectively be able to use all the of VRAM is even more misleading than a GTX 970 being advertised as a 4GB card.

Please read what was actually written

 

[njdevilsfan87]

Really? They haven't even been caught lying like NV did, so aren't you jumping the gun? Give them the benefit of the doubt

The problem is, AMD is advertising this unified pool of memory that has a major constraint - PCIe bandwidth. So that means the work load has to be assigned beforehand (as they did mention). GPU code developers can already do this. It's difficult enough as it is for a heterogeneous workload. But lets say a developer takes the "easy route" and goes with split frame imaging - the VRAM savings will be negligible.

I am sure AMD will fund some titles to get some mileage out of this. But its going to be too difficult for a developer to ever bother with it. That's why I'm disappointed they are announcing it like this. I think the biggest benefit that will come out of this is SFR for Mantle users. SFR will be much better with frame time deviations and latency. But that's still not entirely the level of control AMD is advertising.

 

[artivix]

I'm actually kind of disappointed that AMD is trying to hype it like this - as if anyone is going to bother trying to render in parallel beyond basic split frame imaging (which is going to be negligible in VRAM savings).

SFR is a good push, but saying CF is going to effectively be able to use all the of VRAM is even more misleading than a GTX 970 being advertised as a 4GB card.

Extremetech took a look at one of the first games utilizing Mantle with SFR technique and had some interesting findings and conclusions!

"Holy Hannah. In the chart above, the dark red line is Mantle, while the pale line — the one bounces erratically — is D3D and AFR. This makes a notable difference in game, where frame delivery is much smoother and the game engine just feels better. This graph highlights how frame times and frame rates aren’t the same — according to our first graph, D3D is faster than Mantle. Actually play the game, however, and Mantle is easily the superior solution.

Can Nvidia match Mantle using D3D?

The most obvious question is whether AMD’s Mantle really offers this much of a benefit, or if the company didn’t bother optimizing its AFR solution in any fashion to make sure Mantle would look as good as possible. It’s impossible to answer that question, for obvious reasons, but plenty of people will be watching to see if Nvidia’s GTX 980 is stuck in stutterville, or if it can deliver Mantle’s silky smoothness with the conventional DX11 API. According to AMD, there are specific reasons why Nvidia can’t — we’ll see if it holds up. If AMD is telling the truth, then this is a solid example of how Mantle can enable multi-GPU performance modes that traditional AFR can’t match — and, yes, a preview of the sorts of features DirectX 12 might offer in the next 15-18 months or so.

One thing to keep in mind when looking at these results is that we’re already testing with top-end cards. It’s absolutely true that a high-end R9 290X or GTX 980 doesn’t really need a second GPU to deliver a decent frame rate, but according to AMD these benefits should also show up in lower-end hardware as well. If you’ve got a pair of R9 270X cards, Mantle should still give you a solid fps uplift without microstutter."

http://www.extremetech.com/gaming/1...ti-gpu-scaling-in-civilization-beyond-earth/2

 

[ShintaiDK]

We all know SFR is better. However it comes with a large performance penalty. It only scales around 50% at best.

 

[Headfoot]

There is no doubt, and there should be no doubt in anyone with any technical skills at all, that such a thing is theoretically possible under a sufficiently low level programming API. It's fundamentally no different from multisocket CPU programming at a sufficiently low level (e.g. HPC/supercomputer programming).

The real problem is that writing a split-frame rendering technique is almost never going to be worth the time, effort, investment and support troubles unless AMD is literally paying you to do it. If anyone recalls, Lucid Logix tried a method of intercepting DX calls at the driver layer and splitting a single frame across multiple GPUs, including mixed nVidia - AMD configurations. It's just not economical to do it when hardly anyone (% wise) runs multiple cards

It would be really cool to see someone do it though. If designing a renderer from the ground up, you could theoretically write it with the assumption of N rendering co-processors and assign tasks to them heterogeneously -- perhaps even mixed graphics cards or with the integrated GPU in an APU. It would certainly be a colossal pain to try and backport into an existing engine.

To what degree Mantle will support this is yet to be seen. The link in the OP seems to support it at least with cards that are normally close enough to be Crossfired

 

[el etro]

My expectation is that this will mean more work for the developer. But it will work.

 

[Jodell88]

My guess is utilizing HSA/HSA like technology for graphics instead of compute. The reason only Mantle will support it is because other IHVs may never support HSA.

 

[bystander36]

I wonder how it would be received by most gamers. Sure it may run smoother, but you will also see significantly less FPS than AFR. This means the cost of that extra GPU may seem less impactful to them, and cause them to complain about the cost to performance they get. Psychologically, that FPS meter is really difficult for some people to overcome.

 

[RussianSensation]

We all know SFR is better. However it comes with a large performance penalty. It only scales around 50% at best.

Did you not read the post above you?

"This graph highlights how frame times and frame rates aren’t the same — according to our first graph, D3D is faster than Mantle. Actually play the game, however, and Mantle is easily the superior solution."

If you split the frame into 50%/50%, 1st GPU has 4GB of VRAM and needs to render ~50% of the workload, the 2nd GPU has 4GB of VRAM and needs to render ~50% of the workload. That's why you can theoretically load much more than 4GB of VRAM into 1 frame because you are splitting the frame's resources. With AFR this isn't possible since GPU 1 renders frame 1 and GPU renders frame 2, GPU 1 renders frame 3, GPU 2 renders frame 4, and so on. This means that at any given frame, GPU 1's 4GB of VRAM is the limit for frame 1, while GPU 2's 4GB of VRAM is the limit for frame 2, etc.

For SRF, it's unlikely that each single frame can be perfectly split into 50% VRAM and 50% GPU load evenly for each GPU, and that's why the scaling is not going to be similar to AFR's. However, it means you can theoretically use both of the GPU's VRAM pools simultaneously. If your frame 1 is using 6GB of VRAM, GPU 1 could perform 33% of the workload with 2GB of VRAM used, while GPU 2 could perform the remaining 66% with 4GB of VRAM used. Suddenly you are using 6GB of VRAM on 290 4GB CF in SFR.

For anyone who remembers the early days of SLI/CF, SFR was always an option but developers hardly utilized it.

I wonder how it would be received by most gamers. Sure it may run smoother, but you will also see significantly less FPS than AFR. This means the cost of that extra GPU may seem less impactful to them, and cause them to complain about the cost to performance they get. Psychologically, that FPS meter is really difficult for some people to overcome.

That's true if the market is uninformed/refused to believe that frame times matter just as much as FPS, if not more sometimes. There has been a serious push for frame times over FPS for the last 3 years and if reviewers and gamers experience smoother gameplay at lower FPS due to superior frame times, then the metric of price/performance will need an adjustment of what "performance" means.

We know already from early days of HD7970 CF and recent reviews of 960 that FPS does not equal good frame times. It's just ironic seeing how almost all of the major websites that pushed frame times over FPS for years and years are not completely quiet on this point.