Nouveau - Mar 2017 - [Bug 100177] New: [GM206] Misrendering in XCOM Ennemy Within

https://bugs.freedesktop.org/show_bug.cgi?id=100177

            Bug ID: 100177
           Summary: [GM206] Misrendering in XCOM Ennemy Within
           Product: Mesa
           Version: 17.0
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: pierre.morrow at free.fr
        QA Contact: nouveau at lists.freedesktop.org

Created attachment 130180
  --> https://bugs.freedesktop.org/attachment.cgi?id=130180&action=edit
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20170312/f1360d1a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=100177

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20170313/c71207ad/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=100177

--- Comment #2 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20170313/59adff7c/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=100177

--- Comment #3 from Ilia Mirkin <imirkin at alum.mit.edu> ---
MESA_DEBUG=flush "fixes" this. Oh goodie...

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20170313/aa107f9e/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=100177

--- Comment #4 from Samuel Pitoiset <samuel.pitoiset at gmail.com> ---
Similar issue to Heaven and Valley maybe?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20170313/184918ea/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=100177

--- Comment #5 from caguduzexi at sharklasers.com ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20180129/1e387e50/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=100177

Rhys Perry <pendingchaos02+fdobugzilla at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #6 from Rhys Perry <pendingchaos02+fdobugzilla at gmail.com>
---
Fixed by:

commit f310e86a4200d8ecc74f9ae682386b6ecd1d09d2
Author: Rhys Perry <pendingchaos02 at 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 at gmail.com>
    Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20180730/2144b65b/attachment.html>