Created attachment 118688 [details] X log I was trying to see if GL Excess demo still works - it does, but only some scenes rendered correctly. Demo: http://www.glexcess.com/files.htm Hardware: 01:00.0 VGA compatible controller: NVIDIA Corporation NV43 [GeForce 6600 GT] (rev a2) Mesa: OpenGL version string: 2.1 Mesa 11.1.0-devel (git-93161be) drm: commit 8c4a1cbd98bd8d185d489395f33302a17db643a9 ("xf86drm: Fix error handling for drmGetDevices()") xf86-video-nouveau: commit 1ff13a922535924681b91452235b017e43a4c6f6 ("fix build after glamor removal") kernel from nouveau/4.3 branch: 4.2.0-rc8-40978-g778613e5 X server - standard 1.14.3 from Slackware 14.1 wine (yes, I know, old - but then same demo works with LIBGL_ALWAYS_SOFTWARE=1, so not only wine's fault. I can upgrade after some time): wine-1.5.25-1-gc2505fd
Created attachment 118689 [details] correct software rendering It shows some landscape, even if at 1 fps.
Created attachment 118690 [details] incorrect hw rendering with nouveau it only shows text and FPS bar - not landscape
Created attachment 118691 [details] dmesg I think you can ignore locking-related warnings. But I can retry with 4.3-rc4 mainline, if you prefer (again, will need some time to compile it)
Created attachment 118692 [details] Another type of image corruption Probably need its own bugreport. It always happen at same place in scene - so, not random. Nearly looks like some garbage instead of (guess) alpha channel of texture?
Hm, apparently this is regression - tried few mesa versions - 10.1.6 was OK, but 10.2.9 already broken. Attempt to disable few new (in 10.2) extensions not fixed this. "Mesa 10.2.9 implementation error: Trying to disable a permanently enabled extension: GL_ARB_multi_bind" - this one can't be disabled, it seems (commandline used MESA_EXTENSION_OVERRIDE="-GL_ARB_multi_bind" wine GLExcess.exe) MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage" wine GLExcess.exe - not resulted in anything. Apparently those two types of corruption related (no image and parts of scene filled with rainbow lines) - at least they both started to appear in 10.2.9
Updating wine (to version 1.7.51-staging, from http://www.slackware.com/~alien/slackbuilds/wine/pkg/14.1/) resulted in correctly disabled Vsync, but rendering still broken in the same way. Moreover, attempt to use latest apitrace (command line: ~/src/apitrace/apitrace trace /usr/bin/wine GLExcess.exe ) only resulted in illegal instruction (?!) ----quote---- apitrace: loaded into /usr/bin/wine apitrace: loaded into /usr/bin/wine-preloader apitrace: loaded into /usr/bin/wineserver apitrace: loaded into /usr/bin/wine-preloader fixme:winediag:start_process Wine Staging 1.7.51 is a testing version containing experimental patches. fixme:winediag:start_process Please report bugs at http://bugs.wine-staging.com (instead of winehq.org). apitrace: loaded into /usr/bin/wine-preloader apitrace: loaded into /usr/bin/wine-preloader apitrace: loaded into /usr/bin/wine-preloader apitrace: loaded into /usr/bin/wine-preloader Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. apitrace: loaded into /usr/bin/wine-preloader Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. apitrace: loaded into /usr/bin/wine-preloader bash-4.2$ Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. apitrace: loaded into /usr/bin/wine-preloader Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. apitrace: tracing to /home/guest/.wine/drive_c/Program Files/GL Excess/wine-preloader.trace apitrace: redirecting dlopen("libGL.so.1", 0x102) apitrace: redirecting dlopen("libGL.so.1", 0x102) apitrace: attempting to read configuration file: /home/guest/.config/apitrace/gltrace.conf wine: Unhandled illegal instruction at address 0xb75957f2 (thread 002a), starting debugger... apitrace: loaded into /usr/bin/wine-preloader Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. Unhandled exception: illegal instruction in 32-bit code (0xb75957f2). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:b75957f2 ESP:0033f978 EBP:0033f978 EFLAGS:00210282( R- -- I S - - - ) EAX:46240400 EBX:b777ab1c ECX:b777ab1c EDX:b6fdb89d ESI:7dffabc0 EDI:00002802 Stack dump: 0x0033f978: 0033f9b8 b74366ab 46240400 00000002 0x0033f988: 00002802 00000000 b778adcc 00001a4f 0x0033f998: 00000004 b777ab1c 7dffabc0 b777ab1c 0x0033f9a8: 0033f9d8 00001a50 b778ad60 7e8f77d0 0x0033f9b8: 0033fa08 7e883727 00000de1 00002802 0x0033f9c8: 46240400 00001a4f cccccccc 7e8f77d0 Backtrace: =>0 0xb75957f2 (0x0033f978) 1 0xb74366ab (0x0033f9b8) 2 0x7e883727 glTexParameterf+0x86() in opengl32 (0x0033fa08) 3 0x00441a5d in glxsv1.2 (+0x41a5c) (0x0033fa70) 4 0x00441d01 in glxsv1.2 (+0x41d00) (0x0033fb78) 5 0x004175f9 in glxsv1.2 (+0x175f8) (0x0033fbd8) 6 0x0044c0b7 in glxsv1.2 (+0x4c0b6) (0x0033fdd0) 7 0x004540a3 in glxsv1.2 (+0x540a2) (0x0033fe60) 8 0x7ed06acc call_process_entry+0xb() in kernel32 (0x0033fe78) 9 0x7ed07e31 in kernel32 (+0x47e30) (0x0033feb8) 10 0x7ef91b00 call_thread_func_wrapper+0xb() in ntdll (0x0033fed8) 11 0x7ef94d1d call_thread_func+0x7c() in ntdll (0x0033ffa8) 12 0x7ef91ade RtlRaiseException+0x21() in ntdll (0x0033ffc8) 13 0x7ef65faf in ntdll (+0x45fae) (0x0033ffe8) 14 0xb720c75d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 15 0xb720c81b wine_switch_to_stack+0x2a() in libwine.so.1 (0xbfc40d18) 16 0x7ef6a474 LdrInitializeThunk+0x263() in ntdll (0xbfc40d68) 17 0x7ed0ea43 __wine_kernel_init+0xa02() in kernel32 (0xbfc41c68) 18 0x7ef6b45b __wine_process_init+0x19a() in ntdll (0xbfc41cf8) 19 0xb7209ea8 wine_init+0x2c7() in libwine.so.1 (0xbfc41d58) 20 0x7bf00fcc main+0x7b() in <wine-loader> (0xbfc421a8) 21 0xb704c773 __libc_start_main+0xf2() in libc.so.6 (0x00000000) 0xb75957f2: repe (bad) Modules: Module Address Debug info Name (78 modules) PE 340000- 38f000 Deferred fmod PE 400000- 5a7000 Export glxsv1.2 PE 10000000-10035000 Deferred glut32 PE 60000000-6005d000 Deferred ijl15 ELF 7bf00000-7bf03000 Dwarf <wine-loader> ELF 7d3a1000-7dacc000 Deferred nouveau_dri.so ELF 7ddd0000-7ddd7000 Deferred libdrm_nouveau.so.2 ELF 7ddd7000-7dde5000 Deferred libudev.so.0 ELF 7dde5000-7ddef000 Deferred libxcursor.so.1 ELF 7de21000-7de5a000 Deferred libfontconfig.so.1 ELF 7de5a000-7de70000 Deferred libz.so.1 ELF 7de70000-7de9b000 Deferred libpng14.so.14 ELF 7de9b000-7deac000 Deferred libbz2.so.1 ELF 7deac000-7df3c000 Deferred libfreetype.so.6 ELF 7df3c000-7df4b000 Deferred libxi.so.6 ELF 7df4c000-7df51000 Deferred libtxc_dxtn.so ELF 7df6d000-7e002000 Deferred winex11<elf> \-PE 7df80000-7e002000 \ winex11 ELF 7e002000-7e026000 Deferred imm32<elf> \-PE 7e010000-7e026000 \ imm32 ELF 7e026000-7e0aa000 Deferred rpcrt4<elf> \-PE 7e030000-7e0aa000 \ rpcrt4 ELF 7e0aa000-7e1ec000 Deferred ole32<elf> \-PE 7e0c0000-7e1ec000 \ ole32 ELF 7e1ec000-7e29e000 Deferred msvcrt<elf> \-PE 7e200000-7e29e000 \ msvcrt ELF 7e29e000-7e2c8000 Deferred msacm32<elf> \-PE 7e2a0000-7e2c8000 \ msacm32 ELF 7e2c8000-7e381000 Deferred winmm<elf> \-PE 7e2d0000-7e381000 \ winmm ELF 7e3b0000-7e3c0000 Deferred libdrm.so.2 ELF 7e3c0000-7e3c6000 Deferred libxdmcp.so.6 ELF 7e3c6000-7e3c9000 Deferred libxau.so.6 ELF 7e3c9000-7e3e9000 Deferred libxcb.so.1 ELF 7e3e9000-7e3ee000 Deferred libxxf86vm.so.1 ELF 7e3ee000-7e3f3000 Deferred libxcb-dri2.so.0 ELF 7e3f3000-7e40a000 Deferred libxcb-glx.so.0 ELF 7e40a000-7e42f000 Deferred libglapi.so.0 ELF 7e42f000-7e456000 Deferred libexpat.so.1 ELF 7e456000-7e472000 Deferred libgcc_s.so.1 ELF 7e55a000-7e691000 Deferred libx11.so.6 ELF 7e691000-7e6a3000 Deferred libxext.so.6 ELF 7e6a3000-7e730000 Deferred libgl.so.1 ELF 7e730000-7e7a9000 Deferred libglu.so.1 ELF 7e7ad000-7e7b0000 Deferred libxcomposite.so.1 ELF 7e7b0000-7e7ba000 Deferred libxrandr.so.2 ELF 7e7ba000-7e7c4000 Deferred libxrender.so.1 ELF 7e7c4000-7e7c7000 Deferred libxinerama.so.1 ELF 7e7c7000-7e7cb000 Deferred cp1251.so ELF 7e7cb000-7e7e2000 Deferred glu32<elf> \-PE 7e7d0000-7e7e2000 \ glu32 ELF 7e7e2000-7e900000 Dwarf opengl32<elf> \-PE 7e800000-7e900000 \ opengl32 ELF 7e900000-7e97a000 Deferred advapi32<elf> \-PE 7e910000-7e97a000 \ advapi32 ELF 7e97a000-7ea98000 Deferred gdi32<elf> \-PE 7e990000-7ea98000 \ gdi32 ELF 7ea98000-7ec0d000 Deferred user32<elf> \-PE 7eab0000-7ec0d000 \ user32 ELF 7ec0d000-7ec1a000 Deferred libnss_files.so.2 ELF 7ec1a000-7ec26000 Deferred libnss_nis.so.2 ELF 7ec26000-7ec41000 Deferred libnsl.so.1 ELF 7ec41000-7ec4b000 Deferred libnss_compat.so.2 ELF 7ec4d000-7ec4f000 Deferred libx11-xcb.so.1 ELF 7ec4f000-7ec54000 Deferred libxfixes.so.3 ELF 7ec54000-7ec6d000 Deferred version<elf> \-PE 7ec60000-7ec6d000 \ version ELF 7eca4000-7ef0e000 Dwarf kernel32<elf> \-PE 7ecc0000-7ef0e000 \ kernel32 ELF 7ef0e000-7f000000 Dwarf ntdll<elf> \-PE 7ef20000-7f000000 \ ntdll ELF b6dc0000-b6dc3000 Deferred libxdamage.so.1 ELF b6ff1000-b7033000 Deferred libm.so.6 ELF b7033000-b71bf000 Dwarf libc.so.6 ELF b71bf000-b71c4000 Deferred libdl.so.2 ELF b71c4000-b71de000 Deferred libpthread.so.0 ELF b7200000-b73c6000 Dwarf libwine.so.1 ELF b7793000-b77b6000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000e services.exe 00000020 0 0000001f 0 00000016 0 00000012 0 0000000f 0 00000010 explorer.exe 00000026 0 00000025 0 00000024 0 00000023 0 00000011 0 00000014 winedevice.exe 0000001e 0 0000001b 0 0000001a 0 00000015 0 0000001c plugplay.exe 00000022 0 00000021 0 0000001d 0 00000027 XSconfig.exe 00000028 0 00000029 (D) C:\Program Files\GL Excess\glxsv1.2.exe 0000002a 0 <== System information: Wine build: wine-1.7.51 (Staging) Platform: i386 Host system: Linux Host version: 4.2.0-i486 apitrace: loaded into /usr/bin/wine-preloader Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. apitrace: loaded into /usr/bin/wine-preloader Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. apitrace: loaded into /usr/bin/konqueror Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. apitrace: loaded into /bin/bash apitrace: loaded into /usr/bin/kdeinit apitrace: unloaded from /usr/bin/kdeinit apitrace: loaded into /bin/bash apitrace: loaded into /usr/bin/iceauth apitrace: unloaded from /usr/bin/iceauth apitrace: unloaded from /usr/bin/kdeinit Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. kbuildsycoca running... apitrace: unloaded from /usr/bin/kdeinit apitrace: unloaded from /usr/bin/kdeinit apitrace: unloaded from /usr/bin/kdeinit apitrace: unloaded from /usr/bin/kdeinit apitrace: unloaded from /usr/bin/konqueror apitrace: unloaded from /usr/bin/kdeinit apitrace: unloaded from /usr/bin/kdeinit apitrace: unloaded from /usr/bin/kdeinit apitrace: unloaded from /usr/bin/kdeinit apitrace: unloaded from /usr/bin/kdeinit apitrace: unloaded from /usr/bin/kdeinit apitrace: unloaded from /usr/bin/kdeinit apitrace: unloaded from /usr/bin/kdeinit apitrace: loaded into /bin/bash apitrace: loaded into /usr/bin/dcopserver_shutdown apitrace: loaded into /bin/bash apitrace: loaded into /usr/bin/iceauth apitrace: unloaded from /usr/bin/iceauth apitrace: unloaded from /usr/bin/dcopserver_shutdown apitrace: unloaded from /usr/bin/kdeinit ----quote end----- Is there way to dump openGL commands via other method? Gallium-specific, even?
Older wine reacted the same (illegal instruction), so this is not something added with new wine version. This machine lacks SSE2, obviously ..may be apitrace silently compiles in some SSE2+ code? bash-4.2$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 11 model name : Intel(R) Celeron(TM) CPU 1000MHz stepping : 1 microcode : 0x1c cpu MHz : 1000.051 cache size : 256 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 mmx fxsr sse bugs : bogomips : 2000.10 clflush size : 32 cache_alignment : 32 address sizes : 36 bits physical, 32 bits virtual power management:
apitrace at commit f004530b30a63c08a16d82536858600446b2abf5 ("Date: Mon Sep 21 11:23:02 2015 +0100 d3d10state: Dump D3D10 texture formats.")
Created attachment 118742 [details] apitrace (bz2 compressed) ok, as workaround I run apitrace from another machine (with "Intel(R) Pentium(R) Dual CPU T2390 @ 1.86GHz" and infamous RS600 integrated graphics controller), where it worked.
Please use this file instead, attached one was truncated :/ http://s000.tinyupload.com/index.php?file_id=94706413066309920881 (xz compressed, uncompressed trace was ~17 mb)
After recompiling mesa mesa git commit 93161be9e7150ae5931000627833e714901cf195 - "i965: Fix intel_miptree_is_fast_clear_capable()" with this command line ./configure --prefix=/usr --disable-dri3 --with-gallium-drivers=nouveau --enable-texture-float --enable-debug --with-dri-drivers=swrast I got in terminal ---------- bash-4.2$ wine GLExcess.exe fixme:winediag:start_process Wine Staging 1.7.51 is a testing version containing experimental patches. fixme:winediag:start_process Please report bugs at http://bugs.wine-staging.com (instead of winehq.org). Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. reading configurations from ~/.fonts.conf is deprecated. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. bash-4.2$ Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. Mismatched color and zeta formats, ignoring zeta. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. kbuildsycoca running... -------- important part seems to be: "Mismatched color and zeta formats, ignoring zeta." I also tried to disable PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT , but this not fixed my bug.
(In reply to Andrew Randrianasulu from comment #11) > "Mismatched color and zeta formats, ignoring zeta." Yeah, as I suspected... unfortunately there's not a ton you can do besides fixing the issue. The problem is that you can't render to a 32-bit color format (e.g. RGBA8) while using a 16-bit zeta (Z16), and conversely you can't render to a 16-bit color format (e.g. RGB565) while using a 32-bit zeta (Z24S8). My current solution to this problem is to just not set the zeta buffer and move on with life. This leads to incorrect rendering, but at least no hangs. The proper solution is to have 2 depth textures that you copy to and fro and set the "right" one for the given color format. Ideally while minimizing the number of copies.
(In reply to Ilia Mirkin from comment #12) > (In reply to Andrew Randrianasulu from comment #11) > > "Mismatched color and zeta formats, ignoring zeta." > > Yeah, as I suspected... unfortunately there's not a ton you can do besides > fixing the issue. The problem is that you can't render to a 32-bit color > format (e.g. RGBA8) while using a 16-bit zeta (Z16), and conversely you > can't render to a 16-bit color format (e.g. RGB565) while using a 32-bit > zeta (Z24S8). > > My current solution to this problem is to just not set the zeta buffer and > move on with life. This leads to incorrect rendering, but at least no hangs. > > The proper solution is to have 2 depth textures that you copy to and fro and > set the "right" one for the given color format. Ideally while minimizing the > number of copies. Hm, but in my case it apparently worked fine... so, may be check is overrestrictive? I also tried to apply this path on top of mesa version indicated above ((git-93161be) ----patch--- diff --git a/src/gallium/drivers/nouveau/nv30/nv30_state.c b/src/gallium/drivers/nouveau/nv30/nv30_state.c index fd604c2..cceedfd 100644 --- a/src/gallium/drivers/nouveau/nv30/nv30_state.c +++ b/src/gallium/drivers/nouveau/nv30/nv30_state.c @@ -382,7 +382,7 @@ nv30_set_framebuffer_state(struct pipe_context *pipe, (util_format_get_blocksize(fb->zsbuf->format) > 2) != (util_format_get_blocksize(fb->cbufs[0]->format) > 2)) { nv30->framebuffer.zsbuf = NULL; - debug_printf("Mismatched color and zeta formats, ignoring zeta.\n"); + debug_printf("Mismatched color %d and zeta %d formats, ignoring zeta.\n", fb->cbufs[0]->format, fb->zsbuf->format); } } } --------end----- and got this in terminal: "Mismatched color 1 and zeta 16 formats, ignoring zeta." This is a bit strange, this demo from ~2002 era, and apparently was working fine on older nvidia hardware. And on nouveau, until this commit. I will retest just for making sure it doesn't flood my dmesg with errors ....
(In reply to Andrew Randrianasulu from comment #13) > (In reply to Ilia Mirkin from comment #12) > > (In reply to Andrew Randrianasulu from comment #11) > > > "Mismatched color and zeta formats, ignoring zeta." > > > > Yeah, as I suspected... unfortunately there's not a ton you can do besides > > fixing the issue. The problem is that you can't render to a 32-bit color > > format (e.g. RGBA8) while using a 16-bit zeta (Z16), and conversely you > > can't render to a 16-bit color format (e.g. RGB565) while using a 32-bit > > zeta (Z24S8). > > > > My current solution to this problem is to just not set the zeta buffer and > > move on with life. This leads to incorrect rendering, but at least no hangs. > > > > The proper solution is to have 2 depth textures that you copy to and fro and > > set the "right" one for the given color format. Ideally while minimizing the > > number of copies. > > Hm, but in my case it apparently worked fine... so, may be check is > overrestrictive? > > I also tried to apply this path on top of mesa version indicated above > ((git-93161be) > > ----patch--- > diff --git a/src/gallium/drivers/nouveau/nv30/nv30_state.c > b/src/gallium/drivers/nouveau/nv30/nv30_state.c > index fd604c2..cceedfd 100644 > --- a/src/gallium/drivers/nouveau/nv30/nv30_state.c > +++ b/src/gallium/drivers/nouveau/nv30/nv30_state.c > @@ -382,7 +382,7 @@ nv30_set_framebuffer_state(struct pipe_context *pipe, > (util_format_get_blocksize(fb->zsbuf->format) > 2) != > (util_format_get_blocksize(fb->cbufs[0]->format) > 2)) { > nv30->framebuffer.zsbuf = NULL; > - debug_printf("Mismatched color and zeta formats, ignoring > zeta.\n"); > + debug_printf("Mismatched color %d and zeta %d formats, ignoring > zeta.\n", fb->cbufs[0]->format, fb->zsbuf->format); > } > } > } > --------end----- > > and got this in terminal: > "Mismatched color 1 and zeta 16 formats, ignoring zeta." > > This is a bit strange, this demo from ~2002 era, and apparently was working > fine on older nvidia hardware. And on nouveau, until this commit. I will > retest just for making sure it doesn't flood my dmesg with errors .... You should be seeing errors about invalid values in dmesg for 0208 or some similar method. I'm guessing that the zeta buffer is used in such a way that things happen to work out, but the card doesn't really support it. src/gallium/include/pipe/p_format.h: PIPE_FORMAT_B8G8R8A8_UNORM = 1, src/gallium/include/pipe/p_format.h: PIPE_FORMAT_Z16_UNORM = 16, Not a valid combo, AFAIK.
(In reply to Ilia Mirkin from comment #14) > (In reply to Andrew Randrianasulu from comment #13) > > (In reply to Ilia Mirkin from comment #12) > > > (In reply to Andrew Randrianasulu from comment #11) > > > > "Mismatched color and zeta formats, ignoring zeta." > > > > > > Yeah, as I suspected... unfortunately there's not a ton you can do besides > > > fixing the issue. The problem is that you can't render to a 32-bit color > > > format (e.g. RGBA8) while using a 16-bit zeta (Z16), and conversely you > > > can't render to a 16-bit color format (e.g. RGB565) while using a 32-bit > > > zeta (Z24S8). > > > > > > My current solution to this problem is to just not set the zeta buffer and > > > move on with life. This leads to incorrect rendering, but at least no hangs. > > > > > > The proper solution is to have 2 depth textures that you copy to and fro and > > > set the "right" one for the given color format. Ideally while minimizing the > > > number of copies. > > > > Hm, but in my case it apparently worked fine... so, may be check is > > overrestrictive? > > > > I also tried to apply this path on top of mesa version indicated above > > ((git-93161be) > > > > ----patch--- > > diff --git a/src/gallium/drivers/nouveau/nv30/nv30_state.c > > b/src/gallium/drivers/nouveau/nv30/nv30_state.c > > index fd604c2..cceedfd 100644 > > --- a/src/gallium/drivers/nouveau/nv30/nv30_state.c > > +++ b/src/gallium/drivers/nouveau/nv30/nv30_state.c > > @@ -382,7 +382,7 @@ nv30_set_framebuffer_state(struct pipe_context *pipe, > > (util_format_get_blocksize(fb->zsbuf->format) > 2) != > > (util_format_get_blocksize(fb->cbufs[0]->format) > 2)) { > > nv30->framebuffer.zsbuf = NULL; > > - debug_printf("Mismatched color and zeta formats, ignoring > > zeta.\n"); > > + debug_printf("Mismatched color %d and zeta %d formats, ignoring > > zeta.\n", fb->cbufs[0]->format, fb->zsbuf->format); > > } > > } > > } > > --------end----- > > > > and got this in terminal: > > "Mismatched color 1 and zeta 16 formats, ignoring zeta." > > > > This is a bit strange, this demo from ~2002 era, and apparently was working > > fine on older nvidia hardware. And on nouveau, until this commit. I will > > retest just for making sure it doesn't flood my dmesg with errors .... > > You should be seeing errors about invalid values in dmesg for 0208 or some > similar method. I'm guessing that the zeta buffer is used in such a way that > things happen to work out, but the card doesn't really support it. > > src/gallium/include/pipe/p_format.h: PIPE_FORMAT_B8G8R8A8_UNORM = > 1, > src/gallium/include/pipe/p_format.h: PIPE_FORMAT_Z16_UNORM = > 16, > > Not a valid combo, AFAIK. just tried to comment out zbuf disabling, rendering is ok, no errors o.o May be because nv43 uses z-compression?
Created attachment 118847 [details] dmesg, from glean run, makeCurrent tests
(In reply to Ilia Mirkin from comment #14) > (In reply to Andrew Randrianasulu from comment #13) > > (In reply to Ilia Mirkin from comment #12) > > > (In reply to Andrew Randrianasulu from comment #11) > > > > "Mismatched color and zeta formats, ignoring zeta." > > > > > > Yeah, as I suspected... unfortunately there's not a ton you can do besides > > > fixing the issue. The problem is that you can't render to a 32-bit color > > > format (e.g. RGBA8) while using a 16-bit zeta (Z16), and conversely you > > > can't render to a 16-bit color format (e.g. RGB565) while using a 32-bit > > > zeta (Z24S8). > > > > > > My current solution to this problem is to just not set the zeta buffer and > > > move on with life. This leads to incorrect rendering, but at least no hangs. > > > > > > The proper solution is to have 2 depth textures that you copy to and fro and > > > set the "right" one for the given color format. Ideally while minimizing the > > > number of copies. > > > > Hm, but in my case it apparently worked fine... so, may be check is > > overrestrictive? > > > > I also tried to apply this path on top of mesa version indicated above > > ((git-93161be) > > > > ----patch--- > > diff --git a/src/gallium/drivers/nouveau/nv30/nv30_state.c > > b/src/gallium/drivers/nouveau/nv30/nv30_state.c > > index fd604c2..cceedfd 100644 > > --- a/src/gallium/drivers/nouveau/nv30/nv30_state.c > > +++ b/src/gallium/drivers/nouveau/nv30/nv30_state.c > > @@ -382,7 +382,7 @@ nv30_set_framebuffer_state(struct pipe_context *pipe, > > (util_format_get_blocksize(fb->zsbuf->format) > 2) != > > (util_format_get_blocksize(fb->cbufs[0]->format) > 2)) { > > nv30->framebuffer.zsbuf = NULL; > > - debug_printf("Mismatched color and zeta formats, ignoring > > zeta.\n"); > > + debug_printf("Mismatched color %d and zeta %d formats, ignoring > > zeta.\n", fb->cbufs[0]->format, fb->zsbuf->format); > > } > > } > > } > > --------end----- > > > > and got this in terminal: > > "Mismatched color 1 and zeta 16 formats, ignoring zeta." > > > > This is a bit strange, this demo from ~2002 era, and apparently was working > > fine on older nvidia hardware. And on nouveau, until this commit. I will > > retest just for making sure it doesn't flood my dmesg with errors .... > > You should be seeing errors about invalid values in dmesg for 0208 or some > similar method. I'm guessing that the zeta buffer is used in such a way that > things happen to work out, but the card doesn't really support it. > > src/gallium/include/pipe/p_format.h: PIPE_FORMAT_B8G8R8A8_UNORM = > 1, > src/gallium/include/pipe/p_format.h: PIPE_FORMAT_Z16_UNORM = > 16, > > Not a valid combo, AFAIK. I believe that restriction might only apply to swizzled surfaces.
Fixed with mesa git, thanks Ilia!
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.