DeathtoGnomeswould be interesting to see where the old 3dfx crew ended up and if they have anything to do with DX12 now

nVidia bought the entire 3DFX business, and kept most of those engineers on I believe. Where they are now I don't know.

As for DX12, are you making parallels to the 3DFX Glide wrapper?

No. its just the 3dfx folk seemed to have more creative future insight then most. So just cuz 3dfx couldnt deliver a profitable product doesnt mean then werent doing it right.

FordGT90ConceptI tried digging for more information on this and there's literally nothing beyond what is linked (which is barely more than nothing). It's all very "coming soon."


In before UWP only.

Yeah it's like waiting for MS to support gaming on PC's.

Mixing AMD and nVidia cards is probably holding them back as i bet nVidia have put up a load of red tape up.

This is very nice to know and a lot of people will make good use of it. Think of users with GTX 750, 750 Ti or GTX 1060 which cannot go SLI. Just an example, there are now limitless options.

AsRockYeah it's like waiting for MS to support gaming on PC's.

Mixing AMD and nVidia cards is probably holding them back as i bet nVidia have put up a load of red tape up.

nVidia really has no say in it, this circumvents the driver pretty much.

You'd think multi-GPU capabilities would make Nvidia and AMD happy, after all, it would mean a slight increase in sales. Making Nvidia and AMD play nice with each other is the trick. There has to be some benefit for Nvidia or AMD to want users to buy a card from each brand.

DeathtoGnomesYou'd think multi-GPU capabilities would make Nvidia and AMD happy, after all, it would mean a slight increase in sales. Making Nvidia and AMD play nice with each other is the trick. There has to be some benefit for Nvidia or AMD to want users to buy a card from each brand.

In a perfect world, i am sure either one would like to see the other die off so they could just bump their prices up lol.

AsRockIn a perfect world, i am sure either one would like to see the other die off so they could just bump their prices up lol.

LOL they never stopped bumping prices!

DeathtoGnomesLOL they never stopped bumping prices!

Without one or the other i bet they would be much worse.

AsRockWithout one or the other i bet they would be much worse.

Just like Intel? ;)

I believe Intel would have even higher prices if AMD were not around, like what company wouldn't.

People like their electronics, they probably get away with it until some one else decided there is a market for them.

RejZoRDoes this mean multicard GPU configurations will now become something ordinary as games will support it natively without the stupid profiles and also with better scaling? Because that would be nice and maybe the first time I'll have 2 cards in my system because of it...

No, it wouldn't change that much at all.

Since there is so much confusion about how multi-GPU works, I'm going to try to explain it.
The changes in Direct3D 12 and Vulkan regarding multi-GPU is the following:
1) Common API instead of native API to enumerate GPUs
2) Support for different queues on different GPUs

This does however not change the major effort in implementing multi-GPU support in games, which is the design of the queues themselves.

(1) is of course a good change, but it's only a minor front-end change. It only eliminates the need for the few vendor specific lines to set up multi-GPU. And like with any other common API, the underlying features can be implemented in a number of ways, every programmer knows this. That's how both Direct3D, OpenGL and Vulkan works, they are common interfaces across vastly different hardware, different drivers and operating systems. And since (1) is a minor front-end change, each vendor is free to implement it as they want. This means Nvidia will continue to use the SLI bridge when the user are using matching GPUs. And since AFR with matched GPUs will continue to be the primary use for multi-GPU, the SLI bridge wouldn't become obsolete anytime soon.

AFR works by creating the next queue while the previous one is still being processed by the previous GPU. Several factors determines the ability to scale with AFR:
- Queue dependencies(internal), sync fences etc. needs to be kept to a minimum or avoided.
- Dependencies across frames. Unfortunately many games utilizes shading techniques requiring data from the previous frame, which is problematic when this data resides on the other GPU.
etc.
So multi-GPU scaling comes down game engine design, and Direct3D 12 doesn't change that.

There is a lot of hype around (2), which will allow a game to offload some independent tasks to different GPUs. But it's actually not new at all, it's been a core feature for years and it's used by professional OpenGL applications. (2) does however have a challenge, since transfer of data is still very expensive, the GPUs can basically just transfer a few MB each frame or the performance will be dropping. An even greater challenge is that rendering of dynamic scenes is very hard to divide the rendering itself, so we are left with doing independent tasks on each GPU. In a game that could mean that one GPU is busy with the rendering, while any others are doing particle simulations, physics or anything else that's data independent, but somewhere in the pipeline the results are synchronized and used in the main rendering. This would mean that this kind of multi-GPU will never scale very well, it will actually be limited by the workload of the different queues. If for instance the main rendering is 80% of the workload, you can at maximum offload 20%, even if the second GPU is just as powerful. This is why (2) is never going to scale as well as AFR, it's harder to implement efficiently and we are going to see even fewer games prioritizing this.

It's a common misconception that Direct3D 12/Vulkan will be able to split any workload across n (matched or unmatched GPUs) and scale well. That will never happen. Splitting the workload has to be done manually.