Created attachment 55523 [details] screenshot with artefacts See screenshot in attachment, mesa is from git: OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x300) OpenGL version string: 2.1 Mesa 8.0-devel (git-36ede89) llvm is 3.0 configure flags: ./autogen.sh --prefix=/usr \ --with-dri-driverdir=/usr/lib/xorg/modules/dri \ --with-gallium-drivers=r300,r600,nouveau,swrast,i915 \ --enable-gallium-egl --enable-shared-glapi --enable-gallium-llvm \ --enable-glx-tls \ --with-driver=dri \ --enable-xcb \ --disable-glut \ --enable-gles1 \ --enable-gles2 \ --enable-egl \ --enable-shared-dricore \ --enable-texture-float
What application is this? http://foobillardplus.sourceforge.net/download.html ? Could you try to obtain a apitrace w/ https://github.com/apitrace/apitrace ?
Seems to be a bug in draw, it reproduces with i915g also, so probably affects all drivers which use draw.
Also I can't repro locally (i915g or llvmpipe with llvm 2.8) and Vasily can (i915g or llvmpipe with llvm 3.0).
I've uploaded a trace to http://people.freedesktop.org/~jrfonseca/traces/foobillardplus.trace.xz
I couldn't reproduce the issue with LLVM 3.0 on x64 bits debian. Which distro and architecture are you seeing this?
ArchLinux, x86 (32 bits)
Does this still happen? If so please provide /proc/cpuinfo, as it is possible that it is tied to your particular processor settings.
Still happens with llvmpipe, but system has changed, now it's Core i5-3320M and 64-bit OS (still Archlinux), earlier it was Core 2 Duo T5500 with 32-bit OS
Created attachment 74194 [details] cpuinfo
(In reply to comment #9) > Created attachment 74194 [details] > cpuinfo Thanks. Your processor has SSE4.1, which is what we test the most, so it can't be for lack of processor features. Could you please take make an apitrace ( https://github.com/apitrace/apitrace ) of the corruption, to see if we can reproduce with that? Also, please confirm that with the upgrade you're still using LLVM 3.0. If you have access to other LLVM versions, I'd recommend trying LLVM 3.1 to see if that makes any difference.
(In reply to comment #10) > (In reply to comment #9) > > Created attachment 74194 [details] > > cpuinfo > > Thanks. Your processor has SSE4.1, which is what we test the most, so it > can't be for lack of processor features. > > > Could you please take make an apitrace ( > https://github.com/apitrace/apitrace ) of the corruption, to see if we can > reproduce with that? > > > Also, please confirm that with the upgrade you're still using LLVM 3.0. If > you have access to other LLVM versions, I'd recommend trying LLVM 3.1 to see > if that makes any difference. I'm using Mesa 9.0.2 with LLVM 3.2
Here's apitrace: https://www.dropbox.com/s/bfljhocswxfqtxc/foobillardplus.1.trace.bz2
I tried the trace here w/ NVIDIA GL driver and the rendering here looks just like your screenshot. I though by artefacts you meant the countours in the balls, but I'm not sure anymore. Could you describe exactly what you believe to be artifacts? Also, glretrace here shows many errors, both with NVIDIA or Mesa: Mesa: Mesa: User error: GL_INVALID_VALUE in glMaterial(invalid shininess: 1000.000000 out range [0, 128.000000]) 38030: glDebugOutputCallback: High severity API error 0, GL_INVALID_VALUE in glMaterial(invalid shininess: 1000.000000 out range [0, 128.000000]) 0 38030 glCallList(list = 1) NVIDIA: 38030: glDebugOutputCallback: High severity API error 1281, GL_INVALID_VALUE error generated. 0 38030 glCallList(list = 1) 38030: warning: glGetError(glCallList) = GL_INVALID_VALUE I suspect this may be an application bug... Maybe induced by something in Mesa drivers, but it looks like the drivers are rendering what they are being told..
(In reply to comment #13) > I tried the trace here w/ NVIDIA GL driver and the rendering here looks just > like your screenshot. > > I though by artefacts you meant the countours in the balls, but I'm not sure > anymore. Could you describe exactly what you believe to be artifacts? All balls are colored in wrong colors. > Also, glretrace here shows many errors, both with NVIDIA or Mesa: > > Mesa: > > Mesa: User error: GL_INVALID_VALUE in glMaterial(invalid shininess: > 1000.000000 out range [0, 128.000000]) > 38030: glDebugOutputCallback: High severity API error 0, GL_INVALID_VALUE in > glMaterial(invalid shininess: 1000.000000 out range [0, 128.000000]) > 0 38030 glCallList(list = 1) > > NVIDIA: > > 38030: glDebugOutputCallback: High severity API error 1281, GL_INVALID_VALUE > error generated. > 0 38030 glCallList(list = 1) > 38030: warning: glGetError(glCallList) = GL_INVALID_VALUE > > > I suspect this may be an application bug... Maybe induced by something in > Mesa drivers, but it looks like the drivers are rendering what they are > being told.. I'm pretty sure that I had no such issue with i915 driver (on same machine with same Mesa version), but I have no machine with i915 hw anymore, so can't check. Anyway, foobillard++ on i965 Mesa driver (with Ivy Bridge hardware) has same issue, so probably it's an application bug.
This is not a mesa bug and was resolved a long time ago by the developer of Foobillard++. You can choose different rendering options in the game menu. Hit on ESC / Graphic / Reflections / Rendering and there on default (Version >= 3.42) or spheremap. See also http://sourceforge.net/p/foobillardplus/bugs/10/
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.