Created attachment 68876 [details] rendering corruption after the loading screen There are rendering corruption after the loading screen in this demo. You can download it here: http://www.pouet.net/prod.php?which=53647 apitrace: http://cme.taess.net/frameranger.trace.xz (66MB) Debian unstable with linux-next 20121019 wine-1.5.15-204-g673617e model name : Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz mesa: 3.0 Mesa 9.1-devel (git-d2b0338) ddx: 2.20.12-3-g9fa6e4a with sna drm: a4cb7233a8da171e53b48b376be5c1265c29a612 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09)
In replaying the trace on my ivb I see: 12937: glDebugOutputCallback: High severity API error 0, GL_INVALID_OPERATION in glCopyTexImage2D(srgb usage mismatch) 0 12937 glCopyTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RGBA8, x = 0, y = 0, width = 16, height = 16, border = 0) 12937: warning: glGetError(glCopyTexImage2D) = GL_INVALID_OPERATION So I'd expect there to be some uninitialized textures.
mh, that is possible, but this traces works fine on nvidia, fglrx and svga on nvidia. I think it worked on r600g, too, but i need to recheck that. Maybe those drivers just behave differently on uninitialized textures. What is also possible, that this is another bug in wine. That demo uses some circles to do some particles, which are missing in wine on any driver. Maybe the error comes from this.
FYI trace renders fine on current Mesa using IVB and HSW, maybe also fixed for SNB (?)
Now tested with SNB and Mesa 10.5.0-devel (git-bc6e57e), works fine also there! Don't want to bisect as would mean running glretrace for each bisect step, resolving as fixed. It is likely fixed by (massive) changes lately done to texture upload and conversion paths.
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.