Fixing Intel's Arc Drivers: Optimization & How GPU Drivers Actually Work Engineering Discussion
video description
Date: 2024-03-17
Related videos
Comments and reviews: 20
sniperganso
excellent interview and I am craving for more of this! However, I didn't find properly addressed in this interview what I was most curious to know: 1) Why are we seeing per-game (or per-engine) optimizations and not across the board Using the example at around 12:20 that he says that the optimization was to expose more registers of the vector engine so the engine can process things faster and not be under-utilized, why isn't this optimization for every game out there why would you hold back the registers of the vector engine I know registers are limited and you may be taking registers of something else the engine is not needing to use at that moment and therefore you may be making performance worse in many other scenario if that was done across the board, but I wanted to know more of this. Optimizing per game seems exhausting work that does not scale, so maybe smarter optimizations that identifies those scenarios at runtime and apply them across the board as needed could be a solution. I'd liked to see that discussed. 2) There was some talk about the optimizations needing to be at the game instead of driver near the end, but what about at DirectX/Vulkan level There is a layer between the game and UMD that could potentially be used to address some of that need for exhausting granular optimizations that is done at UMD layer, but maybe that need shouldn't exist. I understand that if this layer becomes overly complicated, game development becomes more complicated, but it shifts the pain point somewhere else. I find that the effort described by Tom somewhat translates to cleaning up garbage in certain points, as game devs code the game and observe the performance result as they code so they should be adjusting the code to achieve optimal performance. Or, the DirectX/Vulkan layers produce the unoptimized garbage, especially because the game dev facing APIs are meant to be more high level and abstract. This is more theoretical, as in reality if the games are already out there working fine for nvidia and amd then the only thing intel can do is optimize UMD, but I am thinking more about the future.
reply
excellent interview and I am craving for more of this! However, I didn't find properly addressed in this interview what I was most curious to know: 1) Why are we seeing per-game (or per-engine) optimizations and not across the board Using the example at around 12:20 that he says that the optimization was to expose more registers of the vector engine so the engine can process things faster and not be under-utilized, why isn't this optimization for every game out there why would you hold back the registers of the vector engine I know registers are limited and you may be taking registers of something else the engine is not needing to use at that moment and therefore you may be making performance worse in many other scenario if that was done across the board, but I wanted to know more of this. Optimizing per game seems exhausting work that does not scale, so maybe smarter optimizations that identifies those scenarios at runtime and apply them across the board as needed could be a solution. I'd liked to see that discussed. 2) There was some talk about the optimizations needing to be at the game instead of driver near the end, but what about at DirectX/Vulkan level There is a layer between the game and UMD that could potentially be used to address some of that need for exhausting granular optimizations that is done at UMD layer, but maybe that need shouldn't exist. I understand that if this layer becomes overly complicated, game development becomes more complicated, but it shifts the pain point somewhere else. I find that the effort described by Tom somewhat translates to cleaning up garbage in certain points, as game devs code the game and observe the performance result as they code so they should be adjusting the code to achieve optimal performance. Or, the DirectX/Vulkan layers produce the unoptimized garbage, especially because the game dev facing APIs are meant to be more high level and abstract. This is more theoretical, as in reality if the games are already out there working fine for nvidia and amd then the only thing intel can do is optimize UMD, but I am thinking more about the future.
reply
Kaguoro
You asked for more questions
Here they go:
1-Are there some automatic routines that try different optimizations to a game to enhance performance or the optimization is human dependant
2-It's possible to submit profiles and traces of a specific game/application to Intel (or other brands) that are analysed (automatically or by a human)
3-Can PIX be used by the regular Joe to analyse a specific situation
4-How different from Intel are the AMD and Nvidia approaches to driver optimization
5-What's the difference between a game that is originally optimized from it's birth to a specific brand and the same game that is optimized on the driver side by other brands Just because of day zero performance superiority
6-Percentage wise how much performance can be still be unlocked from the Intel hardware
6.1-What about performance unlock on the operating system side
Thanks to Steve, Tom and Hugo for the amazing content.
reply
You asked for more questions
Here they go:
1-Are there some automatic routines that try different optimizations to a game to enhance performance or the optimization is human dependant
2-It's possible to submit profiles and traces of a specific game/application to Intel (or other brands) that are analysed (automatically or by a human)
3-Can PIX be used by the regular Joe to analyse a specific situation
4-How different from Intel are the AMD and Nvidia approaches to driver optimization
5-What's the difference between a game that is originally optimized from it's birth to a specific brand and the same game that is optimized on the driver side by other brands Just because of day zero performance superiority
6-Percentage wise how much performance can be still be unlocked from the Intel hardware
6.1-What about performance unlock on the operating system side
Thanks to Steve, Tom and Hugo for the amazing content.
reply
Technocrat.
Maybe Intel needs to make their own Game engine made for Intel CPU and GPU systems. So a game developer can take that engine build their game based on that and the output would be 100% optimized for Intel from the start, then Intel would have access to the engine as it's theirs to tweak the games for maximum quality and performance.
Intel could incentivize Game developers by providing wanting developers at Cost Intel equipment. Of course take a deposit and if they actually make a good game, they get the deposit back. Intel will earn interest on those deposits while in their possession.
Everyone is happy. More Developers can afford to get in the gaming market and Intel has games ready for their products. And of course if you have a Intel game engine and use all Intel products CPU, GPU and if they make motherboards again, they would get a 50% boost in performance on system and Games vs competition
reply
Maybe Intel needs to make their own Game engine made for Intel CPU and GPU systems. So a game developer can take that engine build their game based on that and the output would be 100% optimized for Intel from the start, then Intel would have access to the engine as it's theirs to tweak the games for maximum quality and performance.
Intel could incentivize Game developers by providing wanting developers at Cost Intel equipment. Of course take a deposit and if they actually make a good game, they get the deposit back. Intel will earn interest on those deposits while in their possession.
Everyone is happy. More Developers can afford to get in the gaming market and Intel has games ready for their products. And of course if you have a Intel game engine and use all Intel products CPU, GPU and if they make motherboards again, they would get a 50% boost in performance on system and Games vs competition
reply
dkman123
I always wondered why you need to download a while new driver version. I think it would be great if you loaded the driver once then it reached out and pulled down a module per game. When you install a game it could tell the OS this application was installed, that would tell the driver, then the driver would download the corresponding module. Since that API doesn't exist today it might require a scan, it even a directed scan of go look at this folder.
After that the driver would check for updates by looking for driver level updates and updates to any installed modules. You wouldn't need to fully download a video driver again. And no more 400mb at a time garbage, just getting what you need.
Is that just a would be nice that will never happen
reply
I always wondered why you need to download a while new driver version. I think it would be great if you loaded the driver once then it reached out and pulled down a module per game. When you install a game it could tell the OS this application was installed, that would tell the driver, then the driver would download the corresponding module. Since that API doesn't exist today it might require a scan, it even a directed scan of go look at this folder.
After that the driver would check for updates by looking for driver level updates and updates to any installed modules. You wouldn't need to fully download a video driver again. And no more 400mb at a time garbage, just getting what you need.
Is that just a would be nice that will never happen
reply
EmanuelHoogeveen
2 questions:
1. How much of the compilation in Intel's GPU driver (if any) is dynamic JIT compilation, where you start out with a fast compile that produces somewhat slow code, then do a slower compile that produces faster code, etc. IIRC shaders are strongly typed unlike something like JavaScript, so I don't know how much opportunity there is for runtime optimization (maybe you just want to store the fastest version in the shader cache for next time).
2. Can the UMD driver look at sequences of DirectX API calls and restructure them to work more efficiently for the hardware Or does it first interpret them into something like bytecode and then optimize/restructure that The answer might be yes to both XD
reply
2 questions:
1. How much of the compilation in Intel's GPU driver (if any) is dynamic JIT compilation, where you start out with a fast compile that produces somewhat slow code, then do a slower compile that produces faster code, etc. IIRC shaders are strongly typed unlike something like JavaScript, so I don't know how much opportunity there is for runtime optimization (maybe you just want to store the fastest version in the shader cache for next time).
2. Can the UMD driver look at sequences of DirectX API calls and restructure them to work more efficiently for the hardware Or does it first interpret them into something like bytecode and then optimize/restructure that The answer might be yes to both XD
reply
seylaw
Thanks for the insights and presenting such crucial technical aspects in a way normies like me can follow. Some not often talked about subjects which might be worth to talk about in a future episode: 1) How does the process look like for getting specific features into an API and does it look like a bazzar when negotiating with Microsoft or other vendors in Khronos on how some API features are designed 2) What about Linux and cross-sharing ressources, e.g. the shader compiler Is it worth it or are there enough differences to keep the driver teams seperate 3) Why don't we see something like open source cross-vendor collaboration on GPU drivers (such as the Mesa project for Linux) on Windows
reply
Thanks for the insights and presenting such crucial technical aspects in a way normies like me can follow. Some not often talked about subjects which might be worth to talk about in a future episode: 1) How does the process look like for getting specific features into an API and does it look like a bazzar when negotiating with Microsoft or other vendors in Khronos on how some API features are designed 2) What about Linux and cross-sharing ressources, e.g. the shader compiler Is it worth it or are there enough differences to keep the driver teams seperate 3) Why don't we see something like open source cross-vendor collaboration on GPU drivers (such as the Mesa project for Linux) on Windows
reply
imischek
what i wonder is could driver work go open source in some sense i can see why they wouldnt want everybody look directly at their work but imagine how much work on game by game or engine by engine basis could improve their results. at first it may be a problem for the manufacturer but i could see the benefits really outway it in the long run. some people would optimise the living shit out of certain games or key features or certain hardware. this would maybe even be so competitive between optimisations groups. maybe i dont understand this enough but in my head this sounds awesome. the consumer could benefit from this dramaticly and in proxy by that the manufacturer
reply
what i wonder is could driver work go open source in some sense i can see why they wouldnt want everybody look directly at their work but imagine how much work on game by game or engine by engine basis could improve their results. at first it may be a problem for the manufacturer but i could see the benefits really outway it in the long run. some people would optimise the living shit out of certain games or key features or certain hardware. this would maybe even be so competitive between optimisations groups. maybe i dont understand this enough but in my head this sounds awesome. the consumer could benefit from this dramaticly and in proxy by that the manufacturer
reply
Technocrat.
Perhaps Arc GPU should automatically optimize a game after it's installed before it's played. Auto Optimize it and save settings to the game folder. That way the GPU has less work to do on the fly while processing a game in play.
Kind of like Android optimizes the phone after system update.
That could be accomplished via AI chip built on GPU to do in the background. On systems that have all Intel, CPU and GPU and also has an API, each unit could also have an AI engine to optimize on the fly and in background system and Games.
Like AMD of old video cards used to improve system performance and response times. It would lend a hand to system.
reply
Perhaps Arc GPU should automatically optimize a game after it's installed before it's played. Auto Optimize it and save settings to the game folder. That way the GPU has less work to do on the fly while processing a game in play.
Kind of like Android optimizes the phone after system update.
That could be accomplished via AI chip built on GPU to do in the background. On systems that have all Intel, CPU and GPU and also has an API, each unit could also have an AI engine to optimize on the fly and in background system and Games.
Like AMD of old video cards used to improve system performance and response times. It would lend a hand to system.
reply
datsnek
I have more of a technical question in regards to legacy api's i.e DirectX 9 and OpenGL. Why deos compatibility has to be manually tested, is it not enough to just have a compatible Programming Interface or does (for example DirectX 9) get optimized by game devs based specific drivers/hardware somehow. i.e how abstract are these Frameworks from hardware and drivers
The reason I ask this is because I think legacy software support is important for preservation reasons.
Otherwise thanks for the video! It is very interesting what happens under the hood when a game is ran.
reply
I have more of a technical question in regards to legacy api's i.e DirectX 9 and OpenGL. Why deos compatibility has to be manually tested, is it not enough to just have a compatible Programming Interface or does (for example DirectX 9) get optimized by game devs based specific drivers/hardware somehow. i.e how abstract are these Frameworks from hardware and drivers
The reason I ask this is because I think legacy software support is important for preservation reasons.
Otherwise thanks for the video! It is very interesting what happens under the hood when a game is ran.
reply
romanpollmeier2711
I was wondering if there is some kind of forum / website where we can send the Arc team feedback regarding driver bugs, feature requests etc. Because I found that the /r Arc subreddit is not really useful for that and I would love to give the driver team feedback. Also in case any Intel Software engineer is watching this, have you guys ever thought about creating a top 100 list of DX 9 / 10 games people want to play on Arc and therefore having something that can guide in regards to optimization priority
reply
I was wondering if there is some kind of forum / website where we can send the Arc team feedback regarding driver bugs, feature requests etc. Because I found that the /r Arc subreddit is not really useful for that and I would love to give the driver team feedback. Also in case any Intel Software engineer is watching this, have you guys ever thought about creating a top 100 list of DX 9 / 10 games people want to play on Arc and therefore having something that can guide in regards to optimization priority
reply
boam2943
Thank you GN for this series.
As an exclusively linux user/gamer, it would be interesting to know how the architecture and optimizations compare between windows and linux. Is it harder to implement/optimize things for linux Are there any differences in the software that they use for implementation/optimization of the drivers for linux Is it that done at all Is there any major difference between GPU APIs in the different OSs that may cause game developers to target just one OS (GPU wise)
Thanks again :)
reply
Thank you GN for this series.
As an exclusively linux user/gamer, it would be interesting to know how the architecture and optimizations compare between windows and linux. Is it harder to implement/optimize things for linux Are there any differences in the software that they use for implementation/optimization of the drivers for linux Is it that done at all Is there any major difference between GPU APIs in the different OSs that may cause game developers to target just one OS (GPU wise)
Thanks again :)
reply
-firefly7931
this could fix the buildings loading in and crash on a spacific game port royale 3 this game is no longer supported on steam so it falls to the community to fix the bugs in this game i wonder if going back to dx9 will fix the bugs i am seeing in game however i am unsure as i am playing the game in fullscreen on 100% zoom desktop native ress 7680x4320 on the up3218k monitor.
( any help is appreciated )
3070 ti
i5 12400f
z690a ddr4
2tb ssd
2x 32bit ram 3200hz
windows 11
reply
this could fix the buildings loading in and crash on a spacific game port royale 3 this game is no longer supported on steam so it falls to the community to fix the bugs in this game i wonder if going back to dx9 will fix the bugs i am seeing in game however i am unsure as i am playing the game in fullscreen on 100% zoom desktop native ress 7680x4320 on the up3218k monitor.
( any help is appreciated )
3070 ti
i5 12400f
z690a ddr4
2tb ssd
2x 32bit ram 3200hz
windows 11
reply
SlocusST
I may or may not currently work for the big blue silicon corp, but having someone like Tom on the GPU team is essential. When Raja Koduri left, ARC's future felt way less certain, but I think these types of improvements and attention in the gaming space translate to improvements in the AI compute space, so upper management sees the financial appeal of getting their hands dirty in the gaming space too. I'm actually stoked for the continued improvement to Alchemist and the release of Battlemage.
reply
I may or may not currently work for the big blue silicon corp, but having someone like Tom on the GPU team is essential. When Raja Koduri left, ARC's future felt way less certain, but I think these types of improvements and attention in the gaming space translate to improvements in the AI compute space, so upper management sees the financial appeal of getting their hands dirty in the gaming space too. I'm actually stoked for the continued improvement to Alchemist and the release of Battlemage.
reply
andrewjmarx
It'd be interesting to know how often this occurs:
1) Game dev creates shader
2) Intel does voodoo to specially optimize said shader
3) Game dev tweaks/replaces shader in such a way that the optimization is no longer relevant or needs to be redone
Seems like it'd be a never ending game of whack-a-mole, even at the engine level with engine devs changing things and different games being built for different versions of engines.
reply
It'd be interesting to know how often this occurs:
1) Game dev creates shader
2) Intel does voodoo to specially optimize said shader
3) Game dev tweaks/replaces shader in such a way that the optimization is no longer relevant or needs to be redone
Seems like it'd be a never ending game of whack-a-mole, even at the engine level with engine devs changing things and different games being built for different versions of engines.
reply
TheMissingxtension
Hey man how about an installer that isn't administor has blocked, MBR support for windows, an installer that doesn't crash, then after going through all the installation problems and converting to UEFI my ultrawide would only display in 1080.
I can read it in the installer logs/verbose installer. I will never buy starfield. So lets get rid of those pre render chache on my system..Your forums are not that useful
reply
Hey man how about an installer that isn't administor has blocked, MBR support for windows, an installer that doesn't crash, then after going through all the installation problems and converting to UEFI my ultrawide would only display in 1080.
I can read it in the installer logs/verbose installer. I will never buy starfield. So lets get rid of those pre render chache on my system..Your forums are not that useful
reply
monkev1199
Interestingly on Linux the layers are actually a little less.
Mesa drivers would look something like this for OpenGL:
1. OpenGL context
2. Gallium3D state tracking
3. Driver compiler and other code
4. Command submission via kernel
For vulkan the entire state tracking layer goes away because render passes do the tracking:
1. Vulkan API
2. Driver compiler and other code
3. Kernel command execution.
reply
Interestingly on Linux the layers are actually a little less.
Mesa drivers would look something like this for OpenGL:
1. OpenGL context
2. Gallium3D state tracking
3. Driver compiler and other code
4. Command submission via kernel
For vulkan the entire state tracking layer goes away because render passes do the tracking:
1. Vulkan API
2. Driver compiler and other code
3. Kernel command execution.
reply
ChristopherYeeMon
Suggestion for this series. Speak with a Linux driver engineer or a Valve Wine/Proton engineer to explain how this stack and these challenges are different for Linux. Like, big question, how does DXVK and Wine manage to work so well and be so performant on Linux. As complicated as that whole stack is, to throw two more layers that translate the windows and DirectX stuff to Linux and Vulcan is very impressive.
reply
Suggestion for this series. Speak with a Linux driver engineer or a Valve Wine/Proton engineer to explain how this stack and these challenges are different for Linux. Like, big question, how does DXVK and Wine manage to work so well and be so performant on Linux. As complicated as that whole stack is, to throw two more layers that translate the windows and DirectX stuff to Linux and Vulcan is very impressive.
reply
LordPlebulus
Really cool video! As a game developer it's amazing to get insights to to how Intel approaches their drivers. Tom mentioned that some optimizations can be applied to multiple games using the same engines. I'm curious does Intel work with engine developers Unreal/Unity to integrate these optimizations directly into the engine It seems counterintuitive to repeatedly apply the same driver tweaks on a per game basis.
reply
Really cool video! As a game developer it's amazing to get insights to to how Intel approaches their drivers. Tom mentioned that some optimizations can be applied to multiple games using the same engines. I'm curious does Intel work with engine developers Unreal/Unity to integrate these optimizations directly into the engine It seems counterintuitive to repeatedly apply the same driver tweaks on a per game basis.
reply
MindBlowerWTF
How is their driver built for different GPUs in their current range Is Graphics FW the only part that is GPU specific or the KMD is also coupled together with the GPU Do they have automated smoke tests, to see if fix in one place doesn't cause regression in other places
What about Vulkan optimisations It was mentioned and for Vulkan too few times, but they never expanded on this.
Thanks for these!
reply
How is their driver built for different GPUs in their current range Is Graphics FW the only part that is GPU specific or the KMD is also coupled together with the GPU Do they have automated smoke tests, to see if fix in one place doesn't cause regression in other places
What about Vulkan optimisations It was mentioned and for Vulkan too few times, but they never expanded on this.
Thanks for these!
reply
nielsbishere
5:50, just to add; not all shaders are text when they land in driver land. For DirectX12 and Vulkan, they have already compiled the text to an intermediary binary format (DXIL or SPIRV) which is easier for the driver to handle since there's less steps required to convert it to their instructions. But still it needs that compilation step. Probably text is easier to explain though (and relevant to opengl)
reply
5:50, just to add; not all shaders are text when they land in driver land. For DirectX12 and Vulkan, they have already compiled the text to an intermediary binary format (DXIL or SPIRV) which is easier for the driver to handle since there's less steps required to convert it to their instructions. But still it needs that compilation step. Probably text is easier to explain though (and relevant to opengl)
reply
Add a review, comment
Other channel videos
