Using mesa up to commit 1ce9205f790471214b69c94f2ee07c4eabfa26f0 ("targets/xvmc-nouveau: fix accidental hardcoded include path") and hopefully latest libdrm/ddx, on kernel 965a47fb8ec0a72324aad8b9c0bd1c8b98cc7ca1 ("drm/nouveau/bios: fix regression on some nv4x board") gives me some more fun to report. See attached screenshot of mesa demo "fbotexture" with -arb command line key. (Image may change if you run demo few times) It draws OK with llvmpipe.
Created attachment 60034 [details] screenshot Incorrect rendering
It says: guest@slax:~/botva/src/demos/src/demos$ ./fbotexture -arb GL_RENDERER = Gallium 0.4 on NV43 Color/Texture size: 512 x 512 Depth buffer size: 422 x 422 Depth renderbuffer size = 24 bits Stencil renderbuffer size = 8 bits Render to texture name: 1 Color attachment[0] name: 1 Stencil attachment name: 3 Depth attachment name: 3 Usage: -ds Use combined depth/stencil renderbuffer -arb Try GL_ARB_framebuffer_object's mismatched buffer sizes -ds2 Try GL_ARB_framebuffer_object's GL_DEPTH_STENCIL_ATTACHMENT Keys: a Toggle animation s/s Step/rotate c Toggle back-face culling w Toggle wireframe mode (front-face only) Esc Exit
for correct image i get guest@slax:~/botva/src/demos/src/demos$ LIBGL_ALWAYS_SOFTWARE=1 ./fbotexture -arb GL_RENDERER = Gallium 0.4 on llvmpipe (LLVM 0x209) Color/Texture size: 512 x 512 Depth buffer size: 422 x 422 Depth renderbuffer size = 24 bits Stencil renderbuffer size = 8 bits Render to texture name: 1 Color attachment[0] name: 1 Stencil attachment name: 3 Depth attachment name: 3 Usage: -ds Use combined depth/stencil renderbuffer -arb Try GL_ARB_framebuffer_object's mismatched buffer sizes -ds2 Try GL_ARB_framebuffer_object's GL_DEPTH_STENCIL_ATTACHMENT Keys: a Toggle animation s/s Step/rotate c Toggle back-face culling w Toggle wireframe mode (front-face only) Esc Exit
Created attachment 60035 [details] screenshot - correct rendering on llvmpipe
Reproduced on a NV34 with both Mesa 9.1.6 and the semi-latest 9.3-git checkout (probably as of a few days ago, definitely no nv30 changes in there). The bad rendering is identical in all 3 of the fbotexture modes. (BTW, this took me a sec to figure out -- fbotexture is in the mesa/demos repo.)
So while on the NV34 the rendering was bad with -ds, -arb, and -ds2, on NV42, the rendering is only bad for -arb. Looking at what -arb does specially, it has a "sizeFudge" parameter in the demo. If I avoid setting that, it all works fine with -arb as well. sizeFudge is used to reduce the size of the texture. Normally the texture is 512x512, but if I reduce it to 511x511, then things look much better (the 90 pixels that ought to be blacked out aren't, but at least the main stuff updates seemingly correctly.) And I'm seeing [ 3360.231160] nouveau E[ PGRAPH][0000:02:00.0] ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT [ 3360.231173] nouveau E[ PGRAPH][0000:02:00.0] ch 3 [0x00118000 fbotexture[782]] subc 7 class 0x4097 mthd 0x0208 data 0x08080345 method 0x0208 = NV30_3D_RT_FORMAT. The problem is the type -- it's set to both linear *and* swizzle. A bit of investigation shows that this happens in nv30_clear. fb->cbufs[0]->texture is swizzled, but fb->zsbuf->texture is not. Not really sure how to handle this properly... I think fb->zsbuf->texture is not swizzled because it's a NPOT texture. (And if I make everything be 511x511, then everything becomes NPOT, and so the copy/etc succeeds.)
This should be "fixed" in mesa-git. The driver no longer reports ARB_framebuffer_object, so the -arb option shouldn't work. The hardware doesn't support differently-sized attachments. Since that extension is only part of OpenGL 3.0, and the HW is only OpenGL 2.1-capable, no reason to try to do a software fallback.
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.