| 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> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 17.0 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | IG Menu Screen in working state | ||
|
Description
Pierre Moreau
2017-03-12 22:37:23 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. 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. MESA_DEBUG=flush "fixes" this. Oh goodie... Similar issue to Heaven and Valley maybe? 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. Fixed by: commit f310e86a4200d8ecc74f9ae682386b6ecd1d09d2 Author: Rhys Perry <pendingchaos02@gmail.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 <pendingchaos02@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.