http://bugs.winehq.org/show_bug.cgi?id=12736
Summary: d3d:sampler GL_INVALID_ENUM from glActiveTextureARB @ state.c Product: Wine Version: 0.9.59. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: hoehle@users.sourceforge.net
fixme:d3d:sampler >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glActiveTextureARB @ state.c / 2485
dlls/wined3d/state.c:sampler contains if (GL_SUPPORT(ARB_MULTITEXTURE)) { if (mapped_stage >= GL_LIMITS(combined_samplers)) { return; } GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB + mapped_stage)); checkGLcall("glActiveTextureARB");
The message is caused by an apparently incorrect use of GL_LIMITS(). GL_LIMITS(combined_samplers) seems not to be the correct test.
The spec for glActiveTexture says that the upper bound would be "the larger of (GL_MAX_TEXTURE_COORDS - 1) and (GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS - 1)". http://www.opengl.org/sdk/docs/man/xhtml/glActiveTexture.xml
I couldn't find the limits for glActiveTextureARB(), except for - a Darwin MacOS X manual page http://developer.apple.com/documentation/Darwin/Reference/Manpages/man3/glAc... - a Python page http://pyopengl.sourceforge.net/documentation/manual/glActiveTextureARB.3G.h... - and XFree86 http://www.xfree86.org/4.2.0/glActiveTextureARB.3.html which all say the upper bound is GL_MAX_TEXTURE_UNITS_ARB.
So it looks like the above wine code performs a check appropriate for glActiveTexture() but not for glActiveTextureARB(). It should have been GL_LIMITS(textures) for GL_MAX_TEXTURE_UNITS_ARB, cf. include/wine/wined3d_gl.h:WineD3D_GL_Info and dlls/wined3d/directx.c:FillGLCaps
As a result of the incorrect check, the sampler() continues processing, instead of returning early.
I'm using a laptop with the i810 Xorg driver.
http://bugs.winehq.org/show_bug.cgi?id=12736
--- Comment #1 from knan-wine@anduin.net 2008-09-11 12:32:44 --- So if you do that change to wine source and recompile, does the bug disappear? You seem to have diagnosed it...
http://bugs.winehq.org/show_bug.cgi?id=12736
--- Comment #2 from Austin English austinenglish@gmail.com 2009-03-30 12:47:56 --- Is this still an issue in current (1.1.18 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=12736
--- Comment #3 from Jörg Höhle hoehle@users.sourceforge.net 2009-04-08 04:17:27 ---
Is this still an issue in current (1.1.18 or newer) wine?
Bug #17253 prevents Luka from starting since 1.1.13, so I've not checked again. I didn't try git-revert -n.
Yet when you look at wined3d/sample.c, you'll notice a questionable use of 4 different GL_LIMITS (GL spec 2.1 section 2.11 mentions only 2 and 1 "for compatibility"):
state_texfactor: while idx < GL_LIMITS(texture_stages) GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB + idx));
tex_colorop, tex_alphaop, transform_texture: if mapped_stage >= GL_LIMITS(textures) return; GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB + mapped_stage));
tex_coordindex: if(mapped_stage >= GL_LIMITS(fragment_samplers)) { return; GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB + mapped_stage));
sampler: if (mapped_stage >= GL_LIMITS(combined_samplers)) { return; GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB + mapped_stage)); That's the one causing the original error, still present in 1.1.18.
So if you do that change to wine source and recompile, does the bug disappear? You seem to have diagnosed it...
It's not what I'd call diagnosis. I was just pointing at an error and showing snippets of manual pages, in the hope that somebody knowledgeable would pick it up.
My knowledge of OpenGL and especially OpenGL compatibility programming is near 0. E.g. How to write code that works with OpenGL 2.0, 2.1, 1.x, with or without ARB extension X? Does Wine expect OpenGL 2.1 and the XOrg Intel driver is only 2.0?
So I wouldn't dare to change a limit in sampler() to silence a warning without understanding what this limit affects and whether other portions of code (in wine) expect a particular behaviour. E.g. I don't even understand why it's safe to simply "return" from the functions without performing the job obviously requested by another entity in the program. Why were they called at all?
http://bugs.winehq.org/show_bug.cgi?id=12736
--- Comment #4 from H. Verbeet hverbeet@gmail.com 2009-04-08 04:58:17 --- You should probably check what the various limits are for your card, and what wined3d is actually using. Note that various extensions, like eg. ARB_vertex_shader modify the behaviour of glActiveTextureARB().
http://bugs.winehq.org/show_bug.cgi?id=12736
--- Comment #5 from Austin English austinenglish@gmail.com 2009-10-12 14:55:38 --- Is this still an issue in current (1.1.31 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=12736
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #6 from Jörg Höhle hoehle@users.sourceforge.net 2009-11-19 00:37:33 --- I scanned wined3d and the code looks better now, using mostly : i < context->gl_info->limits.texture_stages or :mapped_stage >= gl_info->limits.textures sometimes :mapped_stage >= gl_info->limits.combined_samplers
The affected app was Crazy Machines Inventors workshop. It shows no such warning any more (not yet tested on that other machine subject to bug #11810).
http://bugs.winehq.org/show_bug.cgi?id=12736
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org 2009-12-04 12:15:27 --- Closing bugs fixed in 1.1.34.
-
wine-bugs＠winehq.org