WYP
News Guru
Yeah, older APIs do take ages to gain traction. When DirectX 12 was first announced DirectX 9 was still fairly common in new games.
DLSS Won't Be Available in EA's Anthem at Launch - Ray Tracing "Could be Added Later"
- Thread starter WYP
- Start date
Yeah, older APIs do take ages to gain traction. When DirectX 12 was first announced DirectX 9 was still fairly common in new games.
NeverBackDown
AMD Enthusiast
Yes it's a modified dx12 tool kit but most likely MS have tools available soit works seamlessly between PC and console
AlienALX
Well-known member
Sorry to jump in. IDK the answer to that but what I can say is that right now most of the features we yearn for on PC with DX12 are useless to consoles, hence the non existence. Things like mgpu and so on.
I know I said it briefly but consoles are still the primary platform for gaming. I doubt that will ever change either so people just need to accept that adoption of technologies like ray tracing will only happen once it can work on a console.
NeverBackDown
AMD Enthusiast
Dx12 is actually extremely well suited to consoles. Everything it addresses goes hand in hand with consoles. The focus on reducing CPU overhead, increase multi threading cabilities, better control over the API to allow for more optimizations to occur, asynchronous Compute to free up about 5-10% more performance on hardware that's outdated is significant, and then easy port access for Xbox and PC games because they are using similar pipelines. The limited hardware is what makes it useful
Dx12 is less suited to PC because most hardware in the past probably 7 years is fast enough to overcome these issues. The only thing holding back PC gaming is the GPU, which doesn't really matter for dx12 outside the exclusive features MS are bringing to it. That's another reason it's taking a long time as well for more games to ship with it. The need isn't so high and the development time to implement it is high. However with Ray Tracing and ML coming to it and there unique capabilities that brings graphics to a whole new level simply gives the one thing that matters for PC gaming, GPU, a reason to actually start more development time on dx12
Last edited:
SPS
Moderator
I think what he means is that PC-exclusive features such as multi-GPU aren't used by console so won't see them in games as console is the primary target, which is true. However, besides multi-gpu I don't think there are any other things that aren't shared.
NeverBackDown
AMD Enthusiast
Oh yes then I misread that.
Well they could do it if the consoles had it. But I doubt they would ever have it, makes little sense
Well they could do it if the consoles had it. But I doubt they would ever have it, makes little sense
Kaapstad
Active member
Whether people like it or not mGPU will be the future for gaming on any platform as it is easier and cheaper to produce several small chips than one huge one.
If hardware does not go down the mGPU route in the next few years gaming will stagnate and die on all platforms as the other ways of getting more performance are running out of options resulting in huge expensive chips like the TU102. How much are gamers prepared to pay for a single GPU card with a huge chip, I think with Turing we have just about reached the maximum people will pay for a graphics card.
And yes I do believe we will see mGPU in consoles.
Multi-die is not necessarily mGPU in a software sense, when we get to the point where we're using multiple dies on a single interposer for the GPU, which might not be more than a couple of years away, the bandwidth of the links would be high enough for the two portions to act as a nUMA cluster. Here's some recent research on the topic: https://hps.ece.utexas.edu/people/ebrahimi/pub/milic_micro17.pdf
This may require certain types of software that don't go through a driver stack to be nUMA aware to fully utilise the system properly but it would allow you to bypass the need for traditional mGPU software tricks like AFR or SFR, which have little place on consoles where consistency is strongly valued.
NeverBackDown
AMD Enthusiast
Hate to break it to you but it won't come back. Even if AMD for example brought multi die architecture, it won't work like the current standard mGPU. The schedular will take care of distribution, not the software developer.
The reason TU is large is due to adding on specific RT and AI dedicated transistors. As we move forward with architecture, just as history has taught us and logical thinking, the dedicated transistors will go away as the CUDA core itself (or AMD equal) will be able to process the RT or AI tasks on it's own. Effectively shrinking the overall package
Kaapstad
Active member
I did not say in what form mGPU will return but return it will.
NeverBackDown
AMD Enthusiast
I mean if that's what you want to believe. You'll have to convince consumers first and they've shown every indication of absolutely going as far away from mGPU as possible.
Multi-die GPUs won't be advertised as or considered or behave as mGPUs, they're not mGPUs, for all intents and purposes for software they're a large single GPU with non-uniform memory access, and will use no mGPU techniques, and this will not compare in any way or allow for multi-card systems, due to the bandwidth limit of the longer links.
For all intents and purposes, mGPU could and likely will work *alongside* multi-die GPUs, but I wouldn't bet on anything but a slow death for it, especially as multi-die GPUs take away many of the benefits.
For all intents and purposes, mGPU could and likely will work *alongside* multi-die GPUs, but I wouldn't bet on anything but a slow death for it, especially as multi-die GPUs take away many of the benefits.
Last edited:
Kaapstad
Active member
Multi-die = mGPU, it uses more than a single core.
Also with tech like NVLink and PCI-E 5.0 we could also see a combination of more than one card using multi die in the same PC.
looz
Active member
I don't see mGPU taking off in a big way in the foreseeable future due to added complexity in hardware, drivers and even game engines with current technology.
Alternating the rendering load between GPUs is anthithetical to responsiveness, and dividing the rendering on a per frame basis is hell to implement.
I mean it's possible that a console manufacturer decides to make a quirky setup utilising mGPU but that's going to be as universally liked by developers as PS3 was.
Alternating the rendering load between GPUs is anthithetical to responsiveness, and dividing the rendering on a per frame basis is hell to implement.
I mean it's possible that a console manufacturer decides to make a quirky setup utilising mGPU but that's going to be as universally liked by developers as PS3 was.
Nope, and that justification makes no sense anyway(A core can be anything you want it to be, for all intents and purposes there are thousands of distinct cores in a GPU, it's quite rare to refer to a die as a core unless the die only has a single core, but there isn't really such thing as a single core GPU beyond like tiny 2D mobile designs, they're inherently highly parallel devices).
If a multi-die GPU is configured to work across a single workload, without the need for a cluster-API or similar to act as an interface between distinct GPU interfaces, then it is acting & interfacing as a single processing unit, hence it is generally referred to as a single Graphics Processing Unit. This is in contrast to multi-GPU gaming configurations that almost always have two independent but identical workloads running in relative sync.
This is a really active area of research, and an area that will have a lot of consumer interest over the years, it's imperative we don't use confusing language like multi-GPU when referring to hardware that will not only not be multi-GPU in any way as far as any software is concerned, besides nUMA awareness, but for all intents and purposes will be a single external package too. The inner workings of a multi-die single-interposer nUMA aware GPU is nothing like that of anything referred to as multi-GPU.
PCIe5 & NVLink are useful for clustered GPGPU setups but at the moment they require a clustering API and other software for this interface and don't have nearly the bandwidth required to do graphics computations in a clustered fashion, the amount of data transfer for that is greater than even current Infinity Fabric bandwidth. It will be far longer after we have multi-die single interposer GPUs until we have external links capable of the same, likely won't be possible till we have consumer optronics.
But regardless, none of this is useful for the mGPU software stack(PC or otherwise), because the whole concept is built around not requiring a different software stack, as is the case with current mGPU setups, if anything multi-die GPUs have a higher chance of killing traditional mGPU software interfaces/approaches like CFX/SLI as the economics of dual card setups for larger arrays of stream cores becomes uneconomical compared to just single cards with large interposers.
Yeah, this. AFR based multi-GPU is fundamentally detrimental for input latency compared to single larger GPU setups.
Last edited:
Kaapstad
Active member
Now you are splitting hairs, more than one GPU is mGPU.
As to large interposers that is a rather expensive way of doing it, if any of it is faulty you have to reject the lot.
It's not splitting hairs because your proposition was that this technology would be beneficial to PC mGPU software/APIs, I'm explaining that it won't because it doesn't resemble a PC mGPU setup or software stack, it's not just me being pedantic over the terms, they mean two very different things that changes the nature of the discussion.
Large interposers are currently expensive, but they're widely regarded as the basis for more or less all future high performance microprocesssor designs amongst much more, they won't be in a few years as the technology matures & yields improve.
Integrating multiple dies into a single interposer similar to Threadripper is done with the intention of maintaining high enough bandwidth links for the device to appear as a single processor or a n/UMA processor cluster.
Large interposers are currently expensive, but they're widely regarded as the basis for more or less all future high performance microprocesssor designs amongst much more, they won't be in a few years as the technology matures & yields improve.
Integrating multiple dies into a single interposer similar to Threadripper is done with the intention of maintaining high enough bandwidth links for the device to appear as a single processor or a n/UMA processor cluster.
Last edited:
AlienALX
Well-known member
Yup DX was always suited to consoles, hence the name, Xbox. It was short for Direct X Box.
That hasn't changed too much, especially on the MS consoles.
Kaapstad
Active member
Of course you are splitting hairs as I can think of at least 5 different ways of doing mGPU at the moment that are already in use.
Using several dies on a single interposer is just another way of doing mGPU, yes the hardware and software will be different but it is still mGPU.
