Bug 111292 - Advanced Lighting option in Firestorm Viewer makes some objects black on nv92 card
Summary: Advanced Lighting option in Firestorm Viewer makes some objects black on nv92...
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/nouveau (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Nouveau Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-03 10:08 UTC by Andrew Randrianasulu
Modified: 2019-08-09 06:29 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Scene with broken lighting (177.32 KB, image/png)
2019-08-03 10:09 UTC, Andrew Randrianasulu
Details
Same scene with correct lights (677.49 KB, image/png)
2019-08-03 10:09 UTC, Andrew Randrianasulu
Details
X log (28.26 KB, text/plain)
2019-08-03 10:10 UTC, Andrew Randrianasulu
Details
dmesg (91.81 KB, text/plain)
2019-08-03 10:12 UTC, Andrew Randrianasulu
Details
glxinfo (88.25 KB, text/plain)
2019-08-03 10:12 UTC, Andrew Randrianasulu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Randrianasulu 2019-08-03 10:08:06 UTC
Hello!

While not everyone here likes to play Second Life - I was lured into it by following some interesting posts, and so far it works quite OK with nouveau/nv92 card. But when i tried to enable _everything_ in viewer's preferences - scene become broken: / Disabling 'Advanced Lighting' in preferences moves scene back to normal look.

Viewer: https://www.firestormviewer.org/ Phoenix_FirestormOS-Release_i686_6.0.2.56680 {but be aware viewer for Second Life only and not OpenSimulator can be blocked when 3 new releases come out .. see https://wiki.firestormviewer.org/fs_old_version_blocks}

src: http://www.phoenixviewer.com/phoenix-firestorm-lgpl/file/80296261f0ac/indra/newview/pipeline.cpp
[I think this is correct file in their VCS]


Mesa: OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.2.0-devel (git-de17922b8a)
kernel: 5.1.12-x64
Xserver: 1.19.7
xf86-video-nouveau - latest git [132955.893] (II) NOUVEAU driver Date:   Mon Jan 28 23:25:58 2019 -0500

will add two attachements - broken and correct rendering.

You can get Second Life account for free, no need for  credit card info or real name.
Comment 1 Andrew Randrianasulu 2019-08-03 10:09:03 UTC
Created attachment 144936 [details]
Scene with broken lighting
Comment 2 Andrew Randrianasulu 2019-08-03 10:09:51 UTC
Created attachment 144937 [details]
Same scene with correct lights
Comment 3 Andrew Randrianasulu 2019-08-03 10:10:57 UTC
Created attachment 144938 [details]
X log
Comment 4 Andrew Randrianasulu 2019-08-03 10:12:16 UTC
Created attachment 144939 [details]
dmesg
Comment 5 Andrew Randrianasulu 2019-08-03 10:12:49 UTC
Created attachment 144940 [details]
glxinfo
Comment 6 Ilia Mirkin 2019-08-03 16:10:08 UTC
An apitrace that demonstrates this would be the most expedient way to get this analyzed and ideally resolved.
Comment 7 Andrew Randrianasulu 2019-08-03 16:56:03 UTC
(In reply to Ilia Mirkin from comment #6)
> An apitrace that demonstrates this would be the most expedient way to get
> this analyzed and ideally resolved.

https://yadi.sk/d/2MMPqKPSiIHxLA - 41791K
Comment 8 Ilia Mirkin 2019-08-03 17:26:52 UTC
Note to anyone taking a look... due to either a bug in the shader or a bug in mesa (depending on one's view), you have to run the trace with

MESA_EXTENSION_ENABLE=-GL_ARB_gpu_shader5

on DX11+ GPUs. Clarifying the behavior now as to which is right (pretty sure mesa behavior is right), but either way it doesn't affect the OP's problem. The black floor does not reproduce on a GK208 though.
Comment 9 Ilia Mirkin 2019-08-03 17:56:21 UTC
Andrew - do you see a bunch of "nv50cal_space: -16" errors in dmesg when this happens? I get a lot of submit errors right when the black background appears, so I think it may be related. But I also have a much lower-end G84 plugged in right now.
Comment 10 Andrew Randrianasulu 2019-08-04 02:19:23 UTC
(In reply to Ilia Mirkin from comment #9)
> Andrew - do you see a bunch of "nv50cal_space: -16" errors in dmesg when
> this happens? I get a lot of submit errors right when the black background
> appears, so I think it may be related. But I also have a much lower-end G84
> plugged in right now.

No, or at least they not in dmesg:  dmesg | grep nv50cal_space returns nothing.
Comment 11 Ilia Mirkin 2019-08-04 02:36:38 UTC
(In reply to Andrew Randrianasulu from comment #10)
> (In reply to Ilia Mirkin from comment #9)
> > Andrew - do you see a bunch of "nv50cal_space: -16" errors in dmesg when
> > this happens? I get a lot of submit errors right when the black background
> > appears, so I think it may be related. But I also have a much lower-end G84
> > plugged in right now.
> 
> No, or at least they not in dmesg:  dmesg | grep nv50cal_space returns
> nothing.

OK, that seems like an artifact of glretrace. Running with MESA_DEBUG=flush and making _mesa_flush actually call Finish() as well makes the trace run ok. Now I can get to the actual figuring out of the misrender.
Comment 12 Ilia Mirkin 2019-08-04 07:21:05 UTC
The issue occurs in draw call 1306672 in the referenced trace. Not yet clear why... all the inputs are the same, and it's not a complex shader.
Comment 13 Andrew Randrianasulu 2019-08-09 06:29:27 UTC
I also tried NV50_PROG_USE_NIR=1 (with Mesa 19.2.0-devel (git-5254e53deb)) but it made no difference.


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.