Nouveau - Apr 2016 - [Bug 95095] New: NV46 (G72) Full screen artifacts in Freespace 2 SW OT mod

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

            Bug ID: 95095
           Summary: NV46 (G72) Full screen artifacts in Freespace 2 SW OT
                    mod
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: issor.oruam at gmail.com
        QA Contact: nouveau at lists.freedesktop.org

Hi,

I've seen this problem sometime ago on NV44
and now traced on NV46 (G72)

The GUI and the 3D models become completely corrupted with elements of the GUI
and parts of the model distorted and covering the whole screen.

Looking at the apitrace and errors highlighted by retracer,
I'm not able to judge if it is a mesa problem.

Here is the .trace:
https://drive.google.com/file/d/0B_OFHiIqgpSFampXVVRKYkVzaTQ/view?usp=sharing

Mauro

-- 
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/20160423/bde7c34a/attachment.html>

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

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
If you are involved with the development of this application, could you verify
that it never uses a 32-bit color buffer with a 16-bit depth buffer, or a
16-bit color buffer with a 24-bit depth buffer? (That's RGBA8 + Z16 or
RGB565 +
Z24.) Those combinations, while perfectly legal in GL, are not actually
supported by the hardware, and the driver "works around it" by just
disabling
depth, which results in broken rendering (but at least no hangs...).

Another random thing to try: set NV30_SWTNL=1 in the environment - that will
make the tnl go through a software path

Lastly, please ensure you're using a semi-recent mesa...

-- 
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/20160423/db259cc7/attachment.html>

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

--- Comment #2 from Ilia Mirkin <imirkin at alum.mit.edu> ---
By the way, it appears that the game makes use of GLSL 1.20 features but
doesn't set a #version 120 on its shaders. You can "fix" this by
running it
with

force_glsl_version=120

in the environment. I didn't see any visual changes in the trace replay
though.
(But I didn't necessarily know where to look.)

-- 
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/20160423/63f26f36/attachment.html>

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

--- Comment #3 from Mauro Rossi <issor.oruam at gmail.com> ---
Created attachment 123205
  --> https://bugs.freedesktop.org/attachment.cgi?id=123205&action=edit
dmesg log

-- 
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/20160424/bcc64a6c/attachment.html>

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

--- Comment #4 from Mauro Rossi <issor.oruam at gmail.com> ---

The attachment was related to a freeze-lockup, even if it's most probably a
different problem.
> If you are involved with the development of this application, could you
> verify that it never uses a 32-bit color buffer with a 16-bit depth buffer,
> or a 16-bit color buffer with a 24-bit depth buffer? (That's RGBA8 +
Z16 or
> RGB565 + Z24.) Those combinations, while perfectly legal in GL, are not
> actually supported by the hardware, and the driver "works around
it" by just
> disabling depth, which results in broken rendering (but at least no
> hangs...).
I'm not involved in fs2_open project, I'm contributing to Star Wars mod
testing
on Linux,

but I found something interesting, using the NV30_SWTNL=1 parameter, I could
cycle all models and get trace to qapitrate retrace all the sequence with hwtnl
and ...

...  just some specific 3D models produce z-culling artifacts, where parts of
the 3D model, like the X-Wind hull, are put extremely "in the front"
hiding
everything, while other 3D models are perfectly rendered.

I'm going to check with 3D model owners if there is a way to correct the
impacted 3D models.

Thanks a lot Ilia!

I'll report back when I found the exact cause of the problem.
> Lastly, please ensure you're using a semi-recent mesa...
I'm testing with mesa git (oibaf ppa)

-- 
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/20160424/4dba3b69/attachment.html>

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

--- Comment #5 from Mauro Rossi <issor.oruam at gmail.com> ---
Created attachment 124156
  --> https://bugs.freedesktop.org/attachment.cgi?id=124156&action=edit
Screenshots of qapitrace retracer error log

This is a merge of two screen snapshots of qapitrace error logs
It is provided to check about the following errors.

GL_INVALID_VALUE on glTexImage2D(InternalFormat=GL_RGBA16F)
Comment, this seems mixed formats, is it correct?

GL_INVALID_ENUM on glFramebufferTexture2D(invalid attachment
GL_COLOR_ATTACHMENT4)

GL_INVALID_FRAMEBUFFER_OPERATION

and the shader compilers errors, with one referring to mat3 requiring
GLSL1.20and HW TNL is GLSL1.10 on nouveau, while on Windows GLSL is 1.20
(looking at GPU capsviewer)

Does this mean that the root cause of "exploding in the face" X-Wing
shaders is
GLSL version and by using SW_TNL and exposing forces GLSL 1.20 is a workaround?
The problem is that with SW_TNL the fs2_open does not work with full assets of
a mission.

Is there a way to normalize by approximation in HW_TNL (just asking I don't
even fully know what I'm saying..) or by using less articulated models.
Ilia, I remember you were saying that this models are huge for a space combat
simulation.

What would be the requirement to be compatible with current nouveau nv30?
What formats?
GLSL 1.10 only shaders?

Thanks
Mauro

-- 
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/20160529/e5c1dd6f/attachment.html>

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

--- Comment #6 from Ilia Mirkin <imirkin at alum.mit.edu> ---
I think you went in the wrong direction with it.

The issue is that the shaders in the game are missing a "#version 120"
header,
yet use GLSL 1.20 features. When there is no #version specified, Mesa assumes
that it's GLSL 1.10. You need to change the game to stick an appropriate
#version header whenever it uses features that were introduced in later GLSL
versions.

-- 
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/20160529/7a90d502/attachment.html>

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

--- Comment #7 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Oh, and on the hwtnl vs swtnl thing - it's most likely a bug in the driver,
or
limitation of the hw (e.g. precision, etc) which is making the hwtnl path fail.

-- 
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/20160529/a5e4a1e0/attachment.html>

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

--- Comment #8 from Mauro Rossi <issor.oruam at gmail.com> ---
Hi Ilia,

I've seen there's an Issue on fs2open github about the need to set
#version 120
header,

now I've done that and rebuilt fs2_open and collected a new trace.

All the errors in qapitrace disappeared, however the X-Wing and other afftected
models are still causing the shaders  artifacts, so there is something else
inducing the artifacts.

Here is the apitrace file:
https://drive.google.com/open?id=0B_OFHiIqgpSFUUtnTXdWSEhoRnc

Is there a way I can get further logs to help?
Mauro

-- 
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/20160529/32678491/attachment.html>

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

GitLab Migration User <gitlab-migration at fdo.invalid> changed:

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

--- Comment #9 from GitLab Migration User <gitlab-migration at
fdo.invalid> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1100.

-- 
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/20190918/7f3e0f90/attachment.html>