|Summary:||[GM206] Misrendering in XCOM Ennemy Within|
|Product:||Mesa||Reporter:||Pierre Moreau <pierre.morrow>|
|Component:||Drivers/DRI/nouveau||Assignee:||Nouveau Project <nouveau>|
|Status:||RESOLVED FIXED||QA Contact:||Nouveau Project <nouveau>|
|i915 platform:||i915 features:|
|Attachments:||IG Menu Screen in working state|
Description Pierre Moreau 2017-03-12 22:37:23 UTC
Created attachment 130180 [details] IG Menu Screen in working state On the menu screen of XCOM Ennemy Within, most of the background is not visible, and some orther parts are flickering (some z-fighting?). I tested with the same software stack on a Fermi card, and it worked there. Card: GeForce GTX 960 (GM206) Mesa: 17.0.1 Linux: 4.10 An apitrace of the bug is available here: https://phabricator.pmoreau.org/F111738
Comment 1 Ilia Mirkin 2017-03-13 02:27:55 UTC
I have an unproven theory that this is related to polygon-offset failing on GM20x. Can't figure out what we're missing. In the GM20x traces it seems like it's jumping through crazy hoops to set all the polygon offset stuff by using a macro to write out the values. It's effectively conditional on the value in some scratch register. I suspect it's to be able to apply a CSO without recomputing it, and adjusting its effect by adjusting scratch registers. However things are configured s.t. it does do the writes. One thought is that there's a register somewhere that sets the value of "r", i.e. the unit of polygon offset. This has traditionally been driven off the depth format as a function of rasterization details, but perhaps now it's set explicitly. It'd be 1/1<<24 for Z24, 1/1<<16 for Z16, and "variable" for Z32F. However no such setting has been found, and there's nothing obvious in the trace.
Comment 2 Ilia Mirkin 2017-03-13 04:08:31 UTC
Actually it looks broken on GM107, so forget about the polygon offset theory. Looks fine on fermi. Disabling optimizations or scheduling don't appear to have any effect.
Comment 3 Ilia Mirkin 2017-03-13 04:59:34 UTC
MESA_DEBUG=flush "fixes" this. Oh goodie...
Comment 4 Samuel Pitoiset 2017-03-13 09:57:24 UTC
Similar issue to Heaven and Valley maybe?
Comment 5 caguduzexi 2018-01-29 14:20:32 UTC
I wont recommend using/keeping the GM206 (GTX 960). It cant ever run with free software: https://www.theregister.co.uk/2015/04/15/nvidia_gtx_900_linux_driver_roadbloack/ https://www.phoronix.com/scan.php?page=news_item&px=Nouveau-XDC2017 https://www.phoronix.com/scan.php?page=news_item&px=Nouveau-XDC2016-NVIDIA Sell this crappy GM206 card away and go away from nvidia. Nvidia died with the 780ti card. Its the last end-user card that can be used normaly. Everything else is in some countries even a legal problem. Because the manufacturer (nvidia) blocks the users from beeing able to boot the software they want on THEIR hardware - happyly illegal in some countries. Hopefully some layer would sue the heck out of nvidia so that they would have to release the private signing key or close their doors. Blocking the freedom of the users on such way should not be accepted by anyone.
Comment 6 Rhys Perry 2018-07-30 16:23:10 UTC
Fixed by: commit f310e86a4200d8ecc74f9ae682386b6ecd1d09d2 Author: Rhys Perry <email@example.com> Date: Sun Jul 15 23:14:41 2018 +0100 nvc0: serialize before updating some constant buffer bindings on Maxwell+ To avoid serializing, this has the user constant buffer always be 65536 bytes and enabled unless it's required that something else is used for constant buffer 0. Fixes artifacts with at least XCOM: Enemy Within, 0 A.D. and Unigine Valley, Heaven and Superposition. v2: changed uniform_buffer_bound to be bool instead of a uint32_t v3: remove magic constants v3: remove pointless code in nvc0_validate_driverconst Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100177 Signed-off-by: Rhys Perry <firstname.lastname@example.org> Reviewed-by: Ilia Mirkin <email@example.com>