Search Issue Tracker
By Design
Votes
0
Found in
2020.3
2020.3.22f1
2021.2
2022.1
Issue ID
1380090
Regression
Yes
Unity process uses GPU Engine "GPU [n] - Copy" when two monitors are plugged in discrete GPU and two in integrated GPU
Reproduction steps:
1. Set up two monitors plugged into the discrete GPU and two monitors plugged into the integrated GPU
2. Set a horizontal monitor layout in the windows desktop settings. [][] [][] with the neighboring monitors being on the same GPU
3. Open the attached project "MultiScreenTest.zip"
4. Build the project through File > Build Settings > Build
5. Create the "Params.txt" file in the Build root folder
6. In "Params.txt" add the following (where a and b are the two integrated GPU monitors):
-stretched
-screen[a]
-screen[b]
7. Open the Command Prompt and navigate to the root folder of the Build
8. Enter "MultiScreenTest.exe -force-device-index [n]" line
9. Check the Task Manager to verify the GPU engine is listed as 'GPU n - 3D' and let it run for a few minutes
10. Launch a second time with the same command line and "Params.txt"
Expected result: GPU engine is listed as "GPU [n] - 3D"
Actual result: GPU engine listed as "GPU [n] - Copy"
Reproducible with: 2020.3.22f1, 2021.2.7f1, 2022.1.0b2
Not reproducible with: 2019.4.34f1
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Shader Graph Asset icon is not shown on creation unless you confirm the name
- APV Sky occlusion doesn't consider the terrain
- [iOS] "EXC_BAD_ACCESS" Player crash when Script Debugging is enabled
- Cursor skips input fields when tabbing between two sets of input fields
- "Shader error redefinition of 'Varyings'" error appears when selecting the shader
Resolution Note (2022.2.X):
The client accepted a workaround.
This feature could potentially do with a redesign to align the behavior with the client's expectations.
Right now, there are some inconsistencies with the feature that are due to how windows handles its monitor/adapter ids.
There doesn't seem to be a good way to fix this if we continue using IDs.
I tried with different APIs and as far as I know, there's no way to match IDs from code with what you see in the windows settings which is probably what the client is basing himself on to choose the ID.
We might want to consider coming up with a more robust API that takes in a monitor name (or some unique id that is available to the client and can be matched by code) and then targetting the gpu that is connected to that monitor.
(This is just brainstorming and might not address all possible cases and what we have right now might be "as good as it gets for windows".)