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.
Created attachment 144936 [details] Scene with broken lighting
Created attachment 144937 [details] Same scene with correct lights
Created attachment 144938 [details] X log
Created attachment 144939 [details] dmesg
Created attachment 144940 [details] glxinfo
An apitrace that demonstrates this would be the most expedient way to get this analyzed and ideally resolved.
(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
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.
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.
(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.
(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.
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.
I also tried NV50_PROG_USE_NIR=1 (with Mesa 19.2.0-devel (git-5254e53deb)) but it made no difference.
-- 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/1189.
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.