Bug 48742

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.