Bug 48742

Summary: [NV30 gallium] fbotexture -arb misrenders on nv43
Product: Mesa Reporter: Andrew Randrianasulu <randrik>
Component: Drivers/DRI/nouveauAssignee: Nouveau Project <nouveau>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium    
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: screenshot
screenshot - correct rendering

Description Andrew Randrianasulu 2012-04-15 15:10:55 UTC
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.
Comment 1 Andrew Randrianasulu 2012-04-15 15:11:39 UTC
Created attachment 60034 [details]
screenshot

Incorrect rendering
Comment 2 Andrew Randrianasulu 2012-04-15 15:12:39 UTC
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
Comment 3 Andrew Randrianasulu 2012-04-15 15:14:09 UTC
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
Comment 4 Andrew Randrianasulu 2012-04-15 15:15:01 UTC
Created attachment 60035 [details]
screenshot - correct rendering

on llvmpipe
Comment 5 Ilia Mirkin 2013-08-20 06:10:37 UTC
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.)
Comment 6 Ilia Mirkin 2013-08-27 05:01:13 UTC
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.)
Comment 7 Ilia Mirkin 2013-11-26 03:20:47 UTC
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.