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
- Mono Windows Builds don't produce full log callstacks when generating logs
- AssetBundles fail to load when running in Built Players for Mobile Devices
- UI elements with text gets bigger and grey when Player window is moved to another screen with different resolution
- System name accepts multiline text but crops it on confirmation, duplicates input, and shrinks the field when empty
- UI element scale and position are wrong in project build when DRS is changed with HDR and Software Dynamic Resolution enabled
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".)