Wednesday, March 25th 2020

Intel iGPU+dGPU Multi-Adapter Tech Shows Promise Thanks to its Realistic Goals

Intel is revisiting the concept of asymmetric multi-GPU introduced with DirectX 12. The company posted an elaborate technical slide-deck it originally planned to present to game developers at the now-cancelled GDC 2020. The technology shows promise because the company isn't insulting developers' intelligence by proposing that the iGPU lying dormant be made to shoulder the game's entire rendering pipeline for a single-digit percentage performance boost. Rather, it has come up with innovating augments to the rendering path such that only certain lightweight compute aspects of the game's rendering be passed on to the iGPU's execution units, so it has a more meaningful contribution to overall performance. To that effect, Intel is on the path of coming up with SDK that can be integrated with existing game engines.

Microsoft DirectX 12 introduced the holy grail of multi-GPU technology, under its Explicit Multi-Adapter specification. This allows game engines to send rendering traffic to any combinations or makes of GPUs that support the API, to achieve a performance uplift over single GPU. This was met with lukewarm reception from AMD and NVIDIA, and far too few DirectX 12 games actually support it. Intel proposes a specialization of explicit multi-adapter approach, in which the iGPU's execution units are made to process various low-bandwidth elements both during the rendering and post-processing stages, such as Occlusion Culling, AI, game physics, etc. Intel's method leverages cross-adapter shared resources sitting in system memory (main memory), and D3D12 asynchronous compute, which creates separate processing queues for rendering and compute.
Intel developed easy code for game engine developers to integrate the new tech, with code for creating cross-adapter resources, shared heaps, and resources. The presentation also includes examples of how to how to leverage async compute and get the lightweight rendering- and compute paths to work with as little latency as possible. Intel also developed code for cross-adapter synchronization, called Intel Command Queue Throttle. This piece of code ensures performance and low frame-times when when the load is inconsistent between the iGPU and dGPU.
All current Intel Graphics drivers include support for the extension, and Intel has started giving out headers for the extension through its developer support. Intel notes that its method can be used for various kinds of async compute tasks such as shadows, AI, mesh deformation, and physics. Load on the system's PCIe and memory bandwidth is minimized because the iGPU isn't made to handle heavyweight resources such as texture filtering.
Intel iGPUs are approaching the 1 TFLOPs compute power barrier, with Gen11 and the upcoming Xe-based iGPU debuting with "Tiger Lake." That's a lot of compute power not to take advantage of. Intel's tech can prove particularly useful with notebooks that have entry- thru mid-range discrete GPUs, as all Intel mobile processors pack iGPUs and implement dynamic switching between iGPU and dGPU.
The complete Intel presentation follows.
Add your own comment

28 Comments on Intel iGPU+dGPU Multi-Adapter Tech Shows Promise Thanks to its Realistic Goals

#1
Midland Dog
i asked for this years ago, anisotropic filtering and post processing can be easily done on some PoS gigaflop level igp
Posted on Reply
#2
lexluthermiester
It should be noted that this is not exclusive to DX12 and can be done in OpenGL and Vulkan as well.
Posted on Reply
#3
john_
AMD could have pushed this years ago, but probably the advantages where not enough to cover up for lost sales of discrete GPUs. Nvidia could also push this, but they where winning in the GPU arena, so why give you the option to postpone an immediate upgrade? With Intel being the underdog in this market, it was probably the easiest bet to expect this kind of tech being utilized by them first. And in this case if they create an SDK that favors Intel CPUs and GPUs, it will be AMDs fault. Not Intel's marketing/bribe money or whatever we say (I say) from time to time(and probably in many case being correct).
Posted on Reply
#4
R0H1T
Oh cool another set of slides by Intel, I wonder if this won't die the death of their last dozen or so innovations :laugh:
Posted on Reply
#5
IceShroom
john_
AMD could have pushed this years ago, but probably the advantages where not enough to cover up for lost sales of discrete GPUs. Nvidia could also push this, but they where winning in the GPU arena, so why give you the option to postpone an immediate upgrade? With Intel being the underdog in this market, it was probably the easiest bet to expect this kind of tech being utilized by them first. And in this case if they create an SDK that favors Intel CPUs and GPUs, it will be AMDs fault. Not Intel's marketing/bribe money or whatever we say (I say) from time to time(and probably in many case being correct).
AMD could have pushed it, but the software developer would have implement it. How many application properly access AMD's encoder/decoder hardware on Windows??
Besides MS's Edge not a single browser use AMD's hardware decoder. But sadly it will repleased by inefficient Chrome's engine.
Posted on Reply
#6
ARF
john_
AMD could have pushed this years ago, but probably the advantages where not enough to cover up for lost sales of discrete GPUs. Nvidia could also push this, but they where winning in the GPU arena, so why give you the option to postpone an immediate upgrade? With Intel being the underdog in this market, it was probably the easiest bet to expect this kind of tech being utilized by them first. And in this case if they create an SDK that favors Intel CPUs and GPUs, it will be AMDs fault. Not Intel's marketing/bribe money or whatever we say (I say) from time to time(and probably in many case being correct).
AMD has for a decade Radeon Dual Graphics and Hybrid technologies.

www.amd.com/en/technologies/radeon-dual-graphics-faq

www.amd.com/en/support/kb/faq/dh-017
The ATI Hybrid Graphics technology was announced on January 23, 2008 with Radeon HD 2400 series and Radeon HD 3400 series video cards supporting hybrid graphics functionality. Originally, ATI announced this feature would only be supported in Vista, but in August 2008 they included support in their Windows XP drivers as well.[1] The architecture has been patented by ATI.[2]
en.wikipedia.org/wiki/AMD_Hybrid_Graphics
Posted on Reply
#7
Vya Domus
john_
AMD could have pushed this years ago, but probably the advantages where not enough to cover up for lost sales of discrete GPUs.
It's not that, this stuff simply doesn't work well in practice.

The biggest problem by far is the fact that under a lot of circumstances the distribution of compute is counterproductive, the gap caused by the different levels of performance makes it so that stalls are inevitable. So the closer the gap the better the performance, this basically makes the combination of iGPU+dGPU the worst contender for this sort of stuff.

The same problem existed with CPU+GPU hybrid compute, nothing really works in that way, most things are either fully GPU accelerated or run on just the CPU.
Posted on Reply
#9
TechLurker
I wonder if AMD's Infinity Architecture is capable of allowing this sort of hybrid crossing. The IA is already planned to allow sharing of memory resources to reduce bottlenecks, and some potential work-splitting (making multi-GPUs work more like one giant GPU), but I wonder if it could also leverage a Ryzen APU's iGPU too, in a similar manner.

The main concern I have about the concept of using the iGPU (whether it's on AMD or Intel) in a hybrid manner is how much of this will adversely affect performance of the CPU. Intel already throttles when it gets too toasty, and that's mostly just pure CPU work. AMD APUs also have bottleneck limitations, but assuming the next-gen APU is more like the PS5's via Infinity Arch, what about heat limitations for it?

And for that matter, will gaming companies really be interested in pursuing and optimizing games to work over such a niche distributed GPU method when they haven't done so for when the tech was first available? I mean sure, a few might just because Intel sponsored a game, but it seems like an overall waste of time if they have to build in the feature for it instead of letting the system distribute it intelligently (ie: it's up to the CPU/APU + GPU to intelligently distribute the resources necessary).
Posted on Reply
#10
john_
ARF
AMD has for a decade Radeon Dual Graphics and Hybrid technologies.
Can you please post the Dual Graphics compatibility table with Ryzen APUs? How many years to update/support it?
Also, this is something different compared to Hybrid CrossFire.
Vya Domus
It's not that, this stuff simply doesn't work well in practice.

The biggest problem by far is the fact that under a lot of circumstances the distribution of compute is counterproductive, the gap caused by the different levels of performance makes it so that stalls are inevitable. So the closer the gap the better the performance, this basically makes the combination of iGPU+dGPU the worst contender for this sort of stuff.

The same problem existed with CPU+GPU hybrid compute, nothing really works in that way, most things are either fully GPU accelerated or run on just the CPU.
Under DX12 we could see something much better compared to what Hybrid Graphics was giving us. If Intel's approach works and probably works in combination with AMD and Nvidia discrete cards, it will be proof that AMD and Nvidia just decided to ignore it.
Posted on Reply
#11
Razrback16
Ya, multi gpu is a very good thing. I'd like to see game developers take advantage of this tech for folks who have dGPU + iGPU and for folks using two heavyweight dGPUs.
Posted on Reply
#12
Assimilator
Essentially it's offloading tasks that would normally be run on the CPU... to the iGPU. Which... is part of the CPU.

So I guess you can either choose between your CPU boosting to max and iGPU doing nothing, or CPU and iGPU both running but at lower speeds? Not seeing the value proposition TBH.
Posted on Reply
#15
jmcslob
I remember this sounding fantastic 5 years ago...Still sounds fantastic.
Posted on Reply
#16
Flanker
From experience, just the management of dGPU and iGPU transferring data from one another, alone, wastes more time per frame than the time saved by offloading some work to the iGPU. Not to mention the extra work the CPU has to do to keep them in sync.
Posted on Reply
#17
ARF
Flanker
From experience, just the management of dGPU and iGPU transferring data from one another, alone, wastes more time per frame than the time saved by offloading some work to the iGPU. Not to mention the extra work the CPU has to do to keep them in sync.
Nowadays CPUs don't do a lot of work. At 1080p 40% load, at 4K 15-20% load.
They must do something and be kept busy up to 80-90%, rather than sitting lazy.
Posted on Reply
#18
Flanker
ARF
Nowadays CPUs don't do a lot of work. At 1080p 40% load, at 4K 15-20% load.
They must do something and be kept busy up to 80-90%, rather than sitting lazy.
You don't keep your CPU spinning for no performance gains, which is the case with adding iGPU along side your dGPU. Not to mention the amount of extra work for developers.
Posted on Reply
#19
Vayra86
john_
If Intel's approach works
That is the million dollar question and so far all evidence has historically pointed at 'no'

Besides, what are you winning here. Just buy a decent GPU. We all know that any realtime critical task needs to be done as close to the hardware as possible, yet here we are making a full round trip back to the CPU to win what, 5-10% fps?

This is already dead imo, but maybe Intel can pull out rabbits if they combine this with new Xe sauce. End result: you will need an Intel CPU (lol, in 2020-2021?!) and an Intel Xe GPU (which?) to make a dent.
ARF
Nowadays CPUs don't do a lot of work. At 1080p 40% load, at 4K 15-20% load.
They must do something and be kept busy up to 80-90%, rather than sitting lazy.
That's not how it works obviously. Its the IGP doing the work, not the CPU cycles you have sitting idle while gaming.
Posted on Reply
#20
john_
Vayra86
That is the million dollar question and so far all evidence has historically pointed at 'no'

Besides, what are you winning here. Just buy a decent GPU. We all know that any realtime critical task needs to be done as close to the hardware as possible, yet here we are making a full round trip back to the CPU to win what, 5-10% fps?

This is already dead imo, but maybe Intel can pull out rabbits if they combine this with new Xe sauce. End result: you will need an Intel CPU (lol, in 2020-2021?!) and an Intel Xe GPU (which?) to make a dent.



That's not how it works obviously. Its the IGP doing the work, not the CPU cycles you have sitting idle while gaming.
Well, in a scenario that is way too optimistic, if this works out, the possibilities for a much more meaningful usage than just combining an iGPU with a high end discrete GPU, are there. We just never had the chance to see what this technology could offer.
Posted on Reply
#21
Totally
IceShroom
But sadly it will repleased by inefficient Chrome's engine.
It already has and it's terrible. Whatever is driving audio cannot keep up whatsoever leading to DPC latency errors which causes playback to snap, crackle, and pop leaving the only options is to either lower sound quality, deal with it, or switch to another browser. I'm now using Firefox which isn't much better trading one set of issues for another. Not happy/disappointed that Edge is now hot garbage.
Posted on Reply
#22
StefanM
Can s.o. test the new sample with a feasible rig?

In my newer Pascal/G-Sync notebook the iGPU is hidden at BIOS level; and my old Maxwell/Broadwell/Optimus notebook refuses to run it.
So i'm out of the race...
Posted on Reply
#23
Vayra86
john_
Well, in a scenario that is way too optimistic, if this works out, the possibilities for a much more meaningful usage than just combining an iGPU with a high end discrete GPU, are there. We just never had the chance to see what this technology could offer.
Hmhm. But this is Intel and this is/was timed to coincide with GDC. This is marketing. And probably just some wild fantasy. On the link to the Intel page the thing has 0 collaborators and all we get is a few lines of text and some weird purple blurb that is supposed to be a demo. So yay they can run a furry with the IGP taking some of the load... 1999 called.
Posted on Reply
#24
john_
Vayra86
Hmhm. But this is Intel and this is/was timed to coincide with GDC. This is marketing. And probably just some wild fantasy. On the link to the Intel page the thing has 0 collaborators and all we get is a few lines of text and some weird purple blurb that is supposed to be a demo. So yay they can run a furry with the IGP taking some of the load... 1999 called.
I don't think it's just wild fantasy. Koduri does have experience and knowledge from Hybrid and typical CrossFire being in AMD. As shown above, in another post, DirectX 12 supports the tech from 2015, so people working with GPUs probably work with that idea for years. For reasons unknown to us, they didn't moved forward to make it available to us. But that's in my opinion decisions made from marketing and financial divisions, not technical problems. If we also consider that much of DirectX 12 is Mantle, maybe multi-adapter was part of Mantle, or it was suppose to be a feature for Mantle 2, 3 or something, if there where more versions of Mantle. Maybe a replacement for the original CrossFire back when CrossFire and SLi where still important. But then Nvidia decided to slowly kill SLi and AMD probably had no problem to follow Nvidia in that decision.
Intel now is a different story, it starts with zero market share, that will definitely jump thank's to the major OEMs getting nice deals on the GPUs, if they buy them as a nice little package with the CPUs. Intel's offerings will also have lower performance compared to AMD and Nvidia offerings. Not to mention probably shorter list of features. So, Intel is in a position where they will try every way possible to extent that feature list and probably close the gap in performance with their competitors. And multi adapter support can do both. Offer something that the competition doesn't and also improve performance when combining an Intel iGPU and a discrete Intel GPU compared to combining an Intel iGPU, that will be doing nothing in 3D gaming, with an AMD or Nvidia discrete GPU.

P.S. "Combining two Intel GPUs for the ultimate performance in games"
That's a nice marketing line on the box of a laptop, don't you think? And many consumers will never think to ask what kind of GPUs. 2 GPUs vs 1 GPU does sound better.
Posted on Reply
#25
Flanker
john_
I don't think it's just wild fantasy. Koduri does have experience and knowledge from Hybrid and typical CrossFire being in AMD. As shown above, in another post, DirectX 12 supports the tech from 2015, so people working with GPUs probably work with that idea for years. For reasons unknown to us, they didn't moved forward to make it available to us. But that's in my opinion decisions made from marketing and financial divitions, not technical problems. If we also consider that much of DirectX 12 is Mantle, maybe multi-adapter was part of Mantle, or it was suppose to be a feature for Mantle 2, 3 or something, if there where more versions of Mantle. Maybe a replacement for the original CrossFire back when CrossFire and SLi where still important. But then Nvidia decided to slowly kill SLi and AMD probably had no problem to follow Nvidia in that decision.
DirectX 12 allows developers more access to the underlying hardware aspects of GPUs, so it is possible to, for example, explicitly do task 1 on GPU1, after that's done, copy the result to GPU2 and use that result to do task 2. So yes, you could say all that was made possible since Mantle. A lot of that control wasn't there in DirectX 11 and before, SLI/CF just merged multiple GPUs into one logical GPU. The problem, to make it work, and especially to make it work well (significantly better than origical CF and SLI), it becomes a lot of work for developers. Just too much work for too little gain.
Posted on Reply
Add your own comment