Application
Intel Arc Driver
Processor / Processor Number [Required]
4600G
Graphic Card
B580
Rendering API
Windows Build
Windows 10 22H2
Other Windows build
No response
Describe the feature
As a layman with no graphics programming experience, I have been trying to understand driver overhead on Arc. Some tech journalists have tested the B580 with different CPUs, finding that it slips as the CPU gets slower, something masked by faster CPUs such as the 9800X3D. In contrast, the GeForce and Radeon tend to have similar results on different CPUs, leading many to the conclusion that Arc has more driver overhead than usual. Intel being new to the discrete GPU market, it’s understandable, and we applaud the excellent work the engineers have done over the past few years, putting forth massive gains as they perfected the drivers. Quite a feat, considering that AMD and Nvidia have a decades-long lead. Well done!
Nonetheless, there seems to be room for improvement in the drivers. One of the best analyses I came across was Chips and Cheese’s “Digging into Driver Overhead on Intel's B580.” Using 3DMark’s now-deprecated-but-still-insightful-for-Arc API Overhead Test and GPUView, they found a few things.
-
An RDNA2 Radeon executed drastically more draw calls per second than the B580. What’s more, Arc’s DX11 MT performance is slightly behind ST, suggesting that DX11 multithreading is not fully tapped or is being bogged down by threading synchronisation. I saw, in DirectX Caps Viewer, that Arc does not support Driver Command Lists. Could that be a cause, holding back DX11 MT performance? This old Intel paper digs deeper into DX11/2 MT.
-
The B580’s Vulkan draw calls per second are about half that of DX12, suggesting a bottleneck. The Radeon’s Vulkan draw calls are on par with DX12. This old Anandtech article shows DX12 and Vulkan on a similar footing on Pascal and Polaris.
-
In Intel’s kernel mode driver, Interrupt Service Routines took disproportionately more execution time than Deferred Procedure Calls in DX11 and Vulkan. In DX12, Arc beat the Radeon on this measure.
-
In GPUView and DX11, the Arc has a lot of work stacking up on the CPU-side queue. The Radeon was completely different, showing CPU-side work of one submission per frame. (Wider and slower vs. narrower and faster?) AMD has also got smaller DMA packets, 64 bytes vs. Intel’s 64 KB, and each points to allocated memory; Intel’s DMA packets do not. Additionally, on AMD, work goes to the GPU queue straight away; Intel has a few-milliseconds delay. (Synchronisation holding up the line?)
-
Interestingly, Arc has paging packets coming up on its copy queue; AMD, none. Could this paging, for transferring data between CPU and GPU, be the cause of micro-stutter and Intel’s sensitivity to Resizeable BAR? Could bypassing the CPU, when possible, and letting the GPU access host memory directly lead to a massive improvement?
The author concludes the DX11 study, saying that Intel does not batch draw calls as aggressively as AMD, incurring extra overhead (perhaps from amplified synchronisation, I imagine); and that there may be overhead when copying data to the GPU.
-
DX12 is similar between AMD and Intel. AMD, however, sends off far more DMA packets, over 100 vs. about 8; and from what I understand, there is a lot of work being done on the Radeon—seemingly, a higher work-to-synchronisation ratio—whereas the Arc has a lot of synchronisation for less work. AMD seems to have more parallelisation on the CPU-side queue for the device context.
-
In Vulkan, flip commands are being done by the DWM, unlike the Radeon, perhaps slowing the Arc further. See resource below.
The author concludes by noting that driver development is a hard task, and that Intel engineers could look at how work is being submitted to the GPU, and whether tackling batching and DMA packets differently might help. Significantly, Intel’s driver seems to be wasting time waiting for locks.
Lastly, though a legacy API, OpenGL is still widely used in applications and older but important games, and some of these findings may, no doubt, apply there. Not too long ago, AMD reworked their OpenGL driver, showing massive gains. I understand that Intel, having limited resources, is prioritising the newest APIs and games, as they should; but one of the things preventing people from buying an Arc is legacy support and performance. As AMD did with Ryzen, it’s not enough to match the competition; one has to surpass them, and it can be done.
Additional notes
DWM, flipping, present latency, and waitable swapchains.
Application
Intel Arc Driver
Processor / Processor Number [Required]
4600G
Graphic Card
B580
Rendering API
Windows Build
Windows 10 22H2
Other Windows build
No response
Describe the feature
As a layman with no graphics programming experience, I have been trying to understand driver overhead on Arc. Some tech journalists have tested the B580 with different CPUs, finding that it slips as the CPU gets slower, something masked by faster CPUs such as the 9800X3D. In contrast, the GeForce and Radeon tend to have similar results on different CPUs, leading many to the conclusion that Arc has more driver overhead than usual. Intel being new to the discrete GPU market, it’s understandable, and we applaud the excellent work the engineers have done over the past few years, putting forth massive gains as they perfected the drivers. Quite a feat, considering that AMD and Nvidia have a decades-long lead. Well done!
Nonetheless, there seems to be room for improvement in the drivers. One of the best analyses I came across was Chips and Cheese’s “Digging into Driver Overhead on Intel's B580.” Using 3DMark’s now-deprecated-but-still-insightful-for-Arc API Overhead Test and GPUView, they found a few things.
An RDNA2 Radeon executed drastically more draw calls per second than the B580. What’s more, Arc’s DX11 MT performance is slightly behind ST, suggesting that DX11 multithreading is not fully tapped or is being bogged down by threading synchronisation. I saw, in DirectX Caps Viewer, that Arc does not support Driver Command Lists. Could that be a cause, holding back DX11 MT performance? This old Intel paper digs deeper into DX11/2 MT.
The B580’s Vulkan draw calls per second are about half that of DX12, suggesting a bottleneck. The Radeon’s Vulkan draw calls are on par with DX12. This old Anandtech article shows DX12 and Vulkan on a similar footing on Pascal and Polaris.
In Intel’s kernel mode driver, Interrupt Service Routines took disproportionately more execution time than Deferred Procedure Calls in DX11 and Vulkan. In DX12, Arc beat the Radeon on this measure.
In GPUView and DX11, the Arc has a lot of work stacking up on the CPU-side queue. The Radeon was completely different, showing CPU-side work of one submission per frame. (Wider and slower vs. narrower and faster?) AMD has also got smaller DMA packets, 64 bytes vs. Intel’s 64 KB, and each points to allocated memory; Intel’s DMA packets do not. Additionally, on AMD, work goes to the GPU queue straight away; Intel has a few-milliseconds delay. (Synchronisation holding up the line?)
Interestingly, Arc has paging packets coming up on its copy queue; AMD, none. Could this paging, for transferring data between CPU and GPU, be the cause of micro-stutter and Intel’s sensitivity to Resizeable BAR? Could bypassing the CPU, when possible, and letting the GPU access host memory directly lead to a massive improvement?
The author concludes the DX11 study, saying that Intel does not batch draw calls as aggressively as AMD, incurring extra overhead (perhaps from amplified synchronisation, I imagine); and that there may be overhead when copying data to the GPU.
DX12 is similar between AMD and Intel. AMD, however, sends off far more DMA packets, over 100 vs. about 8; and from what I understand, there is a lot of work being done on the Radeon—seemingly, a higher work-to-synchronisation ratio—whereas the Arc has a lot of synchronisation for less work. AMD seems to have more parallelisation on the CPU-side queue for the device context.
In Vulkan, flip commands are being done by the DWM, unlike the Radeon, perhaps slowing the Arc further. See resource below.
The author concludes by noting that driver development is a hard task, and that Intel engineers could look at how work is being submitted to the GPU, and whether tackling batching and DMA packets differently might help. Significantly, Intel’s driver seems to be wasting time waiting for locks.
Lastly, though a legacy API, OpenGL is still widely used in applications and older but important games, and some of these findings may, no doubt, apply there. Not too long ago, AMD reworked their OpenGL driver, showing massive gains. I understand that Intel, having limited resources, is prioritising the newest APIs and games, as they should; but one of the things preventing people from buying an Arc is legacy support and performance. As AMD did with Ryzen, it’s not enough to match the competition; one has to surpass them, and it can be done.
Additional notes
DWM, flipping, present latency, and waitable swapchains.