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
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
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".)