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...

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.)

Created attachment 123205 [details]
dmesg log

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)

Created attachment 124156 [details]
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

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.

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.

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

-- 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.