• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Mantle to Offer VRAM Stacking

I'm guessing this likely won't have much impact on traditionally rendered games, but will likely provide some efficiency improvements for non homogeneous display outputs (stereo output for HMD, 3 display eyefinity/surround on 3gpu's, etc).

I would think the limited bus speed of pci-e 3.0 would put a hamper on swapping data between gpu's on your standard AFR, especially when you realize pci-e 3.0 x16 only offers 16GB/s whereas the upcoming HBM GPU's are expected to have internal bandwidth of up to 640GB/s.

Regardless, this should bring about a few more options for developers.
 
295x2 would been seen as a true 8GB card instead of 4GB. That's pretty awesome right there.
 
difficult to do but doable at least for the gamedeveloper/engine.
 
A feature us multi-card users have been wanting for YEARS, now it looks like it is going to happen.
 
If true sounds amazing and it is new news to myself..but just like mantle from the get go, I'll believe it happening when i see it:D And i'm not holding my breath
 
I recall watching a presentation on mantle a while back where the speaker mentioned that in mantle each device is addressed separately and can be used for different tasks. The example give was that you do 99% of your heavy lifting rendering on a card and then some "extra" effects on an apu. I guess the model would extend to have 2, 3, ... n cards.
 
I highly doubt it will happen in games. Maybe several years from now from a rich studio pulling out all the stops to do it and multi-GPU setups are more common than the 5% they are at now (pulled that number out of thin air, but you get the idea),

Here's why:

To do pooled VRAM in gaming, you would have to split the assets. There is no bus that is fast enough to replace the direct VRAM-GPU connection. Physical distance alone prevents that from ever happening. Therefore, in order to utilize the VRAM, you have to split the assets. This means background goes to one GPU, character models go to the second, etc. The game would have to accurately decide how to split the assets based on the number of GPUs and how much work it takes to render those assets.

Basically, you end up with one GPU doing the background, second doing characters, third doing objects, etc, or some combination of that. And you would have to decide before the game loads what each GPU would get. Transferring additional assets to the GPUs in the middle of the game would result in stuttering and lag. And if one GPU suddenly has more work to do (like a lot of characters on screen), the other GPUs would have to wait for it to catch up before continuing.

So what you would end up is that the developer would have to predict the amount of work the assets take up, and distribute them among the cards. Games where the load changes a lot would lead to some cards idling while the other cards are working hard.

To be sure, it's doable. But it would be difficult to pull off with minimal gains on the vast minority of systems. I would rather see AFR (alternate frame rendering) dropped in favor of SFR (split frame rendering).
 
cageymaru said:
295x2 would been seen as a true 8GB card instead of 4GB. That's pretty awesome right there.
Click to expand...

If people have a bad reaction with the GTX970's memory performance dropping to 1/7th it's normal speed, how do you think they'd react to a 295's memory performance dropping to 1/20th (from 320GB/s to pci-e 3.0 x16's 16GB/s) any time vram usage went over 4GB??

Tsumi said:
To do pooled VRAM in gaming, you would have to split the assets. There is no bus that is fast enough to replace the direct VRAM-GPU connection. Physical distance alone prevents that from ever happening. Therefore, in order to utilize the VRAM, you have to split the assets. This means background goes to one GPU, character models go to the second, etc. The game would have to accurately decide how to split the assets based on the number of GPUs and how much work it takes to render those assets.
Click to expand...

I think this would be closer to the right idea, although significantly more complex, and would only work well in certain situations.
 
SFR is already working great in the new Civ game. Granted, its not as graphically intense as other games but the proof of concept is right there. From a few blog posts I've seen, apparently Mantle offers some rules for helping devs handle the balancing problem. If I had to guess, I'd say that AMD is referencing some of their experience with HPC and the load balancing necessary in supercomputers.

There is an ongoing discussion on Mantle's capabilities in another thread here on [H]: http://hardforum.com/showthread.php?t=1850874
 
CrazyRob said:
If people have a bad reaction with the GTX970's memory performance dropping to 1/7th it's normal speed, how do you think they'd react to a 295's memory performance dropping to 1/20th (from 320GB/s to pci-e 3.0 x16's 16GB/s) any time vram usage went over 4GB??
Click to expand...

It would only need to do that when it is quicker to fetch the stored data rather than just recreating it, which would be almost never.
 
haz_mat said:
SFR is already working great in the new Civ game. Granted, its not as graphically intense as other games but the proof of concept is right there. From a few blog posts I've seen, apparently Mantle offers some rules for helping devs handle the balancing problem. If I had to guess, I'd say that AMD is referencing some of their experience with HPC and the load balancing necessary in supercomputers.

There is an ongoing discussion on Mantle's capabilities in another thread here on [H]: http://hardforum.com/showthread.php?t=1850874
Click to expand...

SFR still requires full copying of assets across the GPUs though. VRAM pooling does not work with SFR.
 
Tsumi said:
SFR still requires full copying of assets across the GPUs though. VRAM pooling does not work with SFR.
Click to expand...

Not entirely. The deep-dive with the Civ:BE devs stated that they did not have 100% of the same resources in each VRAM. While a majority of the scenes have similar required resources, they did see times were they had independant allocation.
 
LordEC911 said:
Not entirely. The deep-dive with the Civ:BE devs stated that they did not have 100% of the same resources in each VRAM. While a majority of the scenes have similar required resources, they did see times were they had independant allocation.
Click to expand...

And what happens when moving the map rapidly causes one GPU to need the resources on a different GPU? You get stuttering due to the slow PCI-E bus. Let alone a FPS game.

Yes, you might be able to dynamically manage a limited number of resources. But for the large part, you need mirroring across all of the GPUs.
 
We already can Crossfire an APU with a GPU already. We can Crossfire mismatched GPUs from the same product chain. Remember AMD thinks differently than Intel and has HSA in it's back pocket for even more advanced stuff in the future.

So why do you think that there would be all sorts of latency issues when we can already do weird stuff with AMD products without degradation in performance? I'd give them the benefit of the doubt. Civ:BE runs so damn smoothly in Mantle it makes me want to purchase a second R9 290 just to check out the SFR feature already in it.

https://twitter.com/Thracks/status/561708827662245888
 
cageymaru said:
We already can Crossfire an APU with a GPU already. We can Crossfire mismatched GPUs from the same product chain. Remember AMD thinks differently than Intel and has HSA in it's back pocket for even more advanced stuff in the future.

So why do you think that there would be all sorts of latency issues when we can already do weird stuff with AMD products without degradation in performance? I'd give them the benefit of the doubt. Civ:BE runs so damn smoothly in Mantle it makes me want to purchase a second R9 290 just to check out the SFR feature already in it.

https://twitter.com/Thracks/status/561708827662245888
Click to expand...

Because asset splitting is a vastly different beast from both SFR and AFR. Read my post above.
 
Tsumi said:
And what happens when moving the map rapidly causes one GPU to need the resources on a different GPU? You get stuttering due to the slow PCI-E bus. Let alone a FPS game.

Yes, you might be able to dynamically manage a limited number of resources. But for the large part, you need mirroring across all of the GPUs.
Click to expand...

That typically wouldn't happen. The resources changing so fast, that neither GPU can re-use the previous resources, you are still in the same situation. You have to create/store new resources.

Again, the resources would be managed on the game engine or api side, that would make sure that fetching the needed resources is faster than recreating them, i.e. you wouldn't get stuttering like GTX970.
 
LordEC911 said:
That typically wouldn't happen. The resources changing so fast, that neither GPU can re-use the previous resources, you are still in the same situation. You have to create/store new resources.

Again, the resources would be managed on the game engine or api side, that would make sure that fetching the needed resources is faster than recreating them, i.e. you wouldn't get stuttering like GTX970.
Click to expand...

Which is why for those situations everything needs to be preloaded. Which is why while SFR might lower some VRAM usage, for the most part it will be mirrored.

The only real way to truly get VRAM pooling is to have each GPU render different things, as I said above. One does background/environment, one does moving models, etc. That is a completely different thing than telling one GPU to render half the screen and the other GPU to render the other half.
 
Tsumi said:
Which is why for those situations everything needs to be preloaded. Which is why while SFR might lower some VRAM usage, for the most part it will be mirrored.

The only real way to truly get VRAM pooling is to have each GPU render different things, as I said above. One does background/environment, one does moving models, etc. That is a completely different thing than telling one GPU to render half the screen and the other GPU to render the other half.
Click to expand...

Mantle can do that also. It's in the code and the Sniper Elite developers Rebellion were contemplating it last year and have been working on it to see what they can do with Mantle. In their example I believe they would have the APU's GPU render backgrounds and the main GPU handle the rest. Supposedly it will work fine, but of course that's AMD making that statement. I never saw what Rebellion's work led up to. They do have a new rehash of their franchises coming soon. Maybe they will debut something then?
 
cageymaru said:
Mantle can do that also. It's in the code and the Sniper Elite developers Rebellion were contemplating it last year and have been working on it to see what they can do with Mantle. In their example I believe they would have the APU's GPU render backgrounds and the main GPU handle the rest. Supposedly it will work fine, but of course that's AMD making that statement. I never saw what Rebellion's work led up to. They do have a new rehash of their franchises coming soon. Maybe they will debut something then?
Click to expand...

I never said it couldn't. All I said is that vram pooling would be far too difficult for too little gain for most developers. Especially when all they would have to do is raise hardware requirements and people will upgrade or just play at lower settings.

SFR, on the other hand, should do a lot to raise minimum frame rates, lower frame times, and minimize input lag, especially on tri and quad GPU systems. AFR requires guessing ahead what frame will be rendered by the number of cards (i.e. quad-crossfire requires guessing 3 frames in advance). With SFR, there is only one frame: the current one. VRAM will be slightly reduced due to a smaller frame being rendered, but the rendered frame only takes up a small portion of the VRAM. SFR is NOT vram pooling, and cannot work with vram pooling.
 
Tsumi said:
I never said it couldn't. All I said is that vram pooling would be far too difficult for too little gain for most developers. Especially when all they would have to do is raise hardware requirements and people will upgrade or just play at lower settings.
Click to expand...
If I may interject. This isn't saying that the memory map is going to be pooled. This is saying different jobs requiring different resources can be done one different chips. That is, You take 500 different textures and some geometry data render a scene without things like lighting, depth of field, and other effects. Take that semi complete object and pass it to the next gpu for the effects. This model would incur some latency in moving from one gpu to the next, but not the hit on every random access that you seem to imply. It's simply a one time cost in a pipeline model (which is the model of the gpu).
 
Darakian said:
If I may interject. This isn't saying that the memory map is going to be pooled. This is saying different jobs requiring different resources can be done one different chips. That is, You take 500 different textures and some geometry data render a scene without things like lighting, depth of field, and other effects. Take that semi complete object and pass it to the next gpu for the effects. This model would incur some latency in moving from one gpu to the next, but not the hit on every random access that you seem to imply. It's simply a one time cost in a pipeline model (which is the model of the gpu).
Click to expand...

Again, that still adds multiple levels of difficulty for developers. It won't happen, not for indie, not for smaller studios. A very rich studio making a game solely for the visuals with plot/gameplay taking a second seat might be able to pull this off, but not most. Unless a future DX or OpenGL version is able to dynamically detect and manage load, which will have an impact on CPU usage.
 
It's sounds really interesting. My biggest worry is if Game Developers need to code for it. If it is just a driver to go with the hardware, then that is fine. But with some very buggy messed up games being released these days, well...
 
they were talking about vram stacking seems like on there first dual gpu card.....hole things sounds great if true but im not counting on it happening anytime soon much less drivers for the thing:)
 
It's easy to split the image between the two gpu's and put them together, all you have to do is have an engine to do the stitching.

But what this stacking will do is effectively make on board crossfire actually more effective than split board.

Granted this has a bit more applicability towards the professional level than gaming but cool to see it making a come back.
 
Trimlock said:
It's easy to split the image between the two gpu's and put them together, all you have to do is have an engine to do the stitching.

But what this stacking will do is effectively make on board crossfire actually more effective than split board.

Granted this has a bit more applicability towards the professional level than gaming but cool to see it making a come back.
Click to expand...

The rendered frame isn't the only thing loaded into the VRAM. You need textures and models loaded into the VRAM.

What you described is SFR (split frame rendering). SFR still requires mirroring of 90+% of the VRAM.
 
I'm very anxious to see how stacked VRAM fares. If they can implement some kind of high-speed bridge, then it may take a significantly less transfer speed hit than using the PCIe bus.


cageymaru said:
And get it added to DX12? Ulikely because Nvidia is against tech that they didn't develop from the ground up so they can keep it proprietary.
Click to expand...

Oh please...
NVidia has largely contributed to the development of OpenGL and has been a permanent member of their ARB since around 2002-3, iirc. Providing work for Open Source = no money in it.

NVidia has also freely contributed to the development of Microsoft's proprietary Direct3D, which has been around longer than NVidia has been developing and manufacturing dedicated personal computer 3D accelerators that are compatible or compliant with said API. Providing work for someone else's proprietary technology = no money in it.

DirectX was released in late 1994, while the first DirectX compatible/compliant NVidia product was the Riva128 released in mid 1997.
 
If anyone thinks MS releases any DX version without working extremely close with Intel, Nvidia and AMD, you care smoking crack...
 
The Mac said:
If anyone thinks MS releases any DX version without working extremely close with Intel, Nvidia and AMD, you care smoking crack...
Click to expand...

Exactly. Microsoft's DirectX wouldn't be anywhere near what it is today without the contributions of many, many other companies. Not just graphics, processors, data interconnects, etc either...don't forget audio companies, software development companies (CAD/CAM), et al that have contributed.
 
I'm saying that for it to be added to DX12 it would have to be something that all parties want to be added to DX12. Since Nvidia hasn't shown that they are interested in this technology, then they would fight tooth and nail for it exclusion from the DX12 spec. You know... Just like certain companies didn't want Mantle.. Err low level API tech added to DirectX causing AMD to go it alone in conjunction with DICE and StarDock.

Imagine if MS had launched XBOX One with DX12 capabilities instead. AMD had to create and show them Mantle to open their eyes that there was a better way. I remember when AMD finally got them to patch the XBOX and Project Cars gained a huge boost that brought the game up to the PS4 levels of details. Simply Mad Studios wasted months of development time trying to get the game to match the PS4 before MS finally accepted AMD's technology for the XBOX One.

These companies are not only all out for only themselves, but will shoot themselves in the foot to keep from sharing technology. That's the way they are and will always be. To even think that they are in a love fest because of DX12 is shortsighted.
 
Yes, but it's Microsoft and game developers that steer the ship. The graphics hardware manufacturers tend to be followers with freshly released products touting highlights of being "DirectX xx compliant". They have no choice to conform to DirectX, otherwise they would become defunct rather quickly. Imagine what would happen to AMD or NVidia if one of them released their upcoming product families with OpenGL only support...

The best thing Microsoft ever did to keep a lock on the API preferential treatment that DirectX has and keep the tech relevant was gaining world-wide success with their original Xbox, continue it through to the XB360, and now on to the XB1. Lots of game devs develop for cross-platform releases, and now that XB1 and PS4 are x86 based with DirectX utlization, this makes it even easier for devs to code games. And which API do those devs have to choose? DirectX. AMD knows this, so they are going to continue supporting DirectX and not just Mantle. Especially with DX12's Direct3D becoming a Low-level API just like Mantle (and performing quite admirably, at that).

And because of that, any major player in the hardware graphics accelerator business (namely NVidia and AMD) will have to continue full support and compliancy for DirectX.
 
Last edited:
DejaWiz said:
Lots of game devs develop for cross-platform releases, and now that XB1 and PS4 are x86 based with DirectX utlization, this makes it even easier for devs to code games.
Click to expand...

Umm...I am pretty sure PS4 doesn't utilize DirectX. Wouldn't that be funny, Microsoft giving Sony the API's to power their more powerful console. If that was the case I could only imagine the DirectX implementation Microsoft would've given Sony HAHA!

I would believe Mantle being behind the wheel for PS4 rendering, but even that seems far fetched. I think the CPU's being based off x86 is where the comparison ends between the PS4 and how PC's render games. They almost certainly have their own special sauce to render games.
 
No they dont, the PS4 usues FreeBSD as its OS, and a custom version of OGL called GNM (low level) and GNMX (high-level) as their API.
 
Last edited:
That article is completely wrong. The author has no clue what hes talking about

In no way shape or form, does the PS4 use DX.
 
Last edited:
You must log in or register to reply here.
Back
Top