Bug 12054

I currently can't test on my rv250, but I'm pretty sure it worked for me some time ago. Is this a new issue for you and if so, could you figure out what commit broke it?

Unfortunately it's quite an old issue. Up until recently I have been assuming that it was Wine's fault, until I bought myself a shiny new laptop with an embedded ATI FireGL 5250.

Yes, I also remember the Cinematic once working in OpenGL mode. I don't think I've ever seen the indoor minimap work, though. (Of course, Blizzard has changed its code many times since. The cinematic handling might be quite different now.)

Are there any easy things that I can do to create some useful debugging information?

If the texture simply isn't there but otherwise nothing ill happens, it could be that the app failed to submit the texture (that is, the driver rejected it for some reason), if that's the case try a debug build (or use gdb to stick a breakpoint to _mesa_error) to see if that happens. Another reason could be that the texture fails the completeness test (which is not really an error but usually indicates an application bug), I've seen that happen (and IIRC some driver stacks chose to ignore this, though the spec is quite explicit in saying how to handle it) - see _mesa_test_texobj_completeness. This sometimes happens if the app sets the min filter to something requiring mipmaps but not actually supplying mipmaps. You could add some debug output saying if the completeness test succeeded or just hack _mesa_TexParameterfv so the min filter is always set to GL_LINEAR regardless the supplied value.

This is what Mesa tells me when I try to play the cinematic:

Mesa: User error: GL_INVALID_VALUE in glTexImage2D(level=0, width=512, height=250, depth=1)
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(level=0, width=256, height=250, depth=1)
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(level=0, width=32, height=250, depth=1)
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(level=0, width=512, height=123, depth=1)
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(level=0, width=256, height=123, depth=1)
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(level=0, width=32, height=123, depth=1)
Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D
Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D
...

Apparently, texObj->Image[0][level] is NULL, and so the texture fails subtexture_error_check2().

(In reply to comment #4)
> This is what Mesa tells me when I try to play the cinematic:
> 
> Mesa: User error: GL_INVALID_VALUE in glTexImage2D(level=0, width=512,
> height=250, depth=1)
I fail to see how this could work. The app is trying to submit npot textures to the 2d texture target, which cannot work if the driver doesn't support ARB_texture_npot (and r200 certainly doesn't). When you used the fglrx driver this was presumably on r300 or newer, since 8.40.4 certainly doesn't support r200, and these chip support ARB_texture_npot (well actually r300 doesn't really support it, the driver fakes it as good as it can or may even fall back to sw in some cases, but that's another story).
Subsequent subTexImage call will fail too of course.
I'm a bit baffled how WoW could make such a mistake, maybe their test for ARB_npot is wrong and they test for ARB_texture_rectangle instead or something. Unless something funky is going on and the height values there turning up are just random garbage... Just to be sure, try a full recompile I've seen strange things happen with partial recompiles...

(In reply to comment #5)
> When you used the fglrx driver this was presumably on r300 or newer, since
> 8.40.4 certainly doesn't support r200,

It was on a FireGL V5250, which I believe to be an R530. And the video didn't display entirely correctly there either because the entire left hand side was missing. (glxinfo doesn't show any GL_ARB_texture_non_power_of_two extension for that chip either!?! Is it called something else?)

But it works fine in D3D mode, where all the texture heights are powers of two.

The minimap is not appearing because its texture is incomplete:

Texture Obj 930 incomplete because: obj 0x6b52d010 (930) Image[baseLevel=0] == NULL

(In reply to comment #6)
> It was on a FireGL V5250, which I believe to be an R530. And the video didn't
> display entirely correctly there either because the entire left hand side was
> missing. (glxinfo doesn't show any GL_ARB_texture_non_power_of_two extension
> for that chip either!?! Is it called something else?)
It doesn't have to announce support for it, since it's in opengl 2.0 core.

> But it works fine in D3D mode, where all the texture heights are powers of two.
Hmm. Not sure how WoW displays the video, it could be a bug in wine too I guess but either way it doesn't look like a bug in wine/r200 driver.

> but either way it doesn't look like a bug in wine/r200 driver.
Meh. That should be mesa/r200.

(In reply to comment #7)
> The minimap is not appearing because its texture is incomplete:
> 
> Texture Obj 930 incomplete because: obj 0x6b52d010 (930) Image[baseLevel=0] ==
> NULL
Would be nice to know why the Image isn't there. Did the texImage2D fail just the same there too?

(In reply to comment #9)
>> Would be nice to know why the Image isn't there. Did the texImage2D fail just
> the same there too?

There is no other error message to explain this image's absence. I have created a MESA_DEBUG=tex,state log (heavily compressed!).

Created attachment 11172 [details]
MESA_DEBUG=tex,state for World of Warcraft

Show the context of the incomplete minimap texture.

(In reply to comment #11)
> Created an attachment (id=11172) [details]
> MESA_DEBUG=tex,state for World of Warcraft
> 
> Show the context of the incomplete minimap texture.

Mesa: FLUSH_VERTICES in _mesa_TexParameterfv
Mesa warning: GL User Error: called without context: CullFace
Mesa warning: GL User Error: called without context: LoadMatrixf
Mesa warning: GL User Error: called without context: ClearColor
Mesa warning: GL User Error: called without context: DepthMask
Mesa warning: GL User Error: called without context: DepthRange
Mesa warning: GL User Error: called without context: Clear
Mesa warning: GL User Error: called without context: DepthMask
Mesa warning: GL User Error: called without context: LoadMatrixf
Mesa warning: GL User Error: called without context: LoadMatrixf
Mesa warning: GL User Error: called without context: BindTexture
Mesa warning: GL User Error: called without context: CopyTexImage2D

This certainly is a reason why it's not there. Apparently the minimap texture should have been created by CopyTexImage2D, but no luck without a context...
It seems to me like WoW tried to use pbuffers (which aren't supported, you can see some wine errors in the beginning about that), and somehow didn't notice it never got a context handle for that...
It is possible that it simply needs pbuffers, or maybe it could alternatively use fbo's but those aren't supported (with r200 driver) neither. And btw even CopyTexImage2D alone would kill performance (currently not accelerated on r200), unless the area to copy is _really_ small...

(In reply to comment #12)
> It seems to me like WoW tried to use pbuffers (which aren't supported, you can
> see some wine errors in the beginning about that), and somehow didn't notice
> it never got a context handle for that...

Does r200 need to support WGL_ARB_pbuffer, then? fglrx doesn't support any kind of pbuffer extension at all (unless it's core 2.0 functionality?). And I have no idea what a "WGL" extension is - I just read it from a list generated by "strings WoW.exe" :-).

> It is possible that it simply needs pbuffers, or maybe it could alternatively
> use fbo's but those aren't supported (with r200 driver) neither. And btw even
> CopyTexImage2D alone would kill performance (currently not accelerated on
> r200), unless the area to copy is _really_ small...

It is a small area - but maybe not small enough. What would need adding to the r200 driver to accelerate CopyTexImage2D? (Please don't say "hardware" ;-) )

(In reply to comment #13)
> Does r200 need to support WGL_ARB_pbuffer, then? fglrx doesn't support any kind
> of pbuffer extension at all (unless it's core 2.0 functionality?). And I have
> no idea what a "WGL" extension is - I just read it from a list generated by
> "strings WoW.exe" :-).
wgl is only used for windows, but there is a corresponding glx extension. This is in glx 1.3, which fglrx supports. wine should translate wgl calls to the corresponding glx calls.

> > CopyTexImage2D alone would kill performance (currently not accelerated on
> > r200), unless the area to copy is _really_ small...
> 
> It is a small area - but maybe not small enough. What would need adding to the
> r200 driver to accelerate CopyTexImage2D? (Please don't say "hardware" ;-) )
A ttm-based r200 driver. (I've written a quick hack once to accelerate this, but there is no way to make that correct without some real buffer management for textures. It might work for WoW, though.)
But unfortunately pbuffers are a big obstacle. They are hard to get implemented correctly. Not exactly sure if someone is still working on it at the moment. Though presumably WoW might only need client-side support (I believe this is how it works with fglrx), which would be easier (at least with a ttm-based driver).

(In reply to comment #14)
> wgl is only used for windows, but there is a corresponding glx extension. This
> is in glx 1.3, which fglrx supports. wine should translate wgl calls to the
> corresponding glx calls.

The r200 supports GLX_SGIX_pbuffer (unlike fglrx). I don't know which other GLX extension might be needed. Here is fglrx's list:

server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, 
    GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, 
    GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
client glx vendor string: ATI
client glx version string: 1.3
client glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, 
    GLX_ARB_get_proc_address, GLX_SGI_video_sync, GLX_ARB_multisample, 
    GLX_ATI_pixel_format_float, GLX_ATI_render_texture
GLX version: 1.2
GLX extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, 
    GLX_ARB_multisample

Compare this to the r200's list:

server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
    GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_make_current_read, 
    GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group

> But unfortunately pbuffers are a big obstacle. 

So basically, Blizzard needs to use a pot texture for the cinematic in OpenGL mode, and wine needs to support WGL_ARB_pbuffer. And a ttm-based r200 driver will arrive in due course to speed everything up?

It sounds as if wine's pbuffer support is the next thing to pursue.

The comments in wine/dlls/winex11.drv/opengl.c are quite revealing as to how GLX extension detection works. Basically, ATI drivers are considered broken in that they only advertise important extensions in the client GLX string. The WGL_ARB_pbuffer support is not enabled because Mesa's common GLX extension section is only v1.2. (It is let down by the Xserver only supporting v1.2, despite the client supporting v1.4 and the precious GLX_SGIX_pbuffer.)

ATI advertises GLX_ATI_render_texture in the client extensions, and that's enough (apparently).

MESA is mentioned explicitly with "The mesa libGL client library seems to forward glXQueryDrawable to the Xserver, so only enable this function when the Xserver understand GLX 1.3 or newer".

(In reply to comment #16)
> The comments in wine/dlls/winex11.drv/opengl.c are quite revealing as to how
> GLX extension detection works. Basically, ATI drivers are considered broken in
> that they only advertise important extensions in the client GLX string. The
> WGL_ARB_pbuffer support is not enabled because Mesa's common GLX extension
> section is only v1.2. (It is let down by the Xserver only supporting v1.2,
> despite the client supporting v1.4 and the precious GLX_SGIX_pbuffer.)
> 
> ATI advertises GLX_ATI_render_texture in the client extensions, and that's
> enough (apparently).
> 
> MESA is mentioned explicitly with "The mesa libGL client library seems to
> forward glXQueryDrawable to the Xserver, so only enable this function when the
> Xserver understand GLX 1.3 or newer".
Yes, this is correct behaviour. fglrx cheats a bit there, from my understanding it just does all the pbuffer handling client-side (which won't have quite the right semantics, but it avoids all the complex issues).

(In reply to comment #15)
> So basically, Blizzard needs to use a pot texture for the cinematic in OpenGL
> mode,
Either that or use the TEXTURE_RECTANGLE_ARB/NV target instead - I doubt the cinematic uses mipmaps or unsupported texture wrap modes for that...

> and wine needs to support WGL_ARB_pbuffer. And a ttm-based r200 driver
> will arrive in due course to speed everything up?
> 
> It sounds as if wine's pbuffer support is the next thing to pursue.
wine should support pbuffer, but I'm not sure dri/xorg server will anytime soon - discussions about it are 3 years old now.
Dave Airlie has done some work for a ttm-based radeon driver, but so far ddx only.

(In reply to comment #17)
>> wine should support pbuffer, but I'm not sure dri/xorg server will anytime
> soon - discussions about it are 3 years old now.

Ummm... since Wine does support pbuffer, I'm thinking that server-side GLX 1.3 support with GLX_SGIX_pbuffer is the *only* thing that will get WoW running properly with Mesa. (Unless Blizzard suddenly decides to support Linux offically, anyway.) The comments in Wine were quite clear as to what its developers thought of the hacks needed for the ATI driver...

It's not just the missing mini-map. The text also goes crazy(*) unless GL_ARB_vertex_buffer_object is hidden/disabled in the Wine registry. I'm now thinking that having GL_ARB_vertex_buffer_object available opens another code-path that wants a pbuffer context.

> Dave Airlie has done some work for a ttm-based radeon driver, but so far ddx
> only.

Is the ttm work going "mainstream" any time soon? It sounds like it could really help with the ol' fps.

(*) "crazy" in this context means "As if the bottom-left corner of any text-box is being stretched to the bottom-left corner of the screen".
e.g. https://bugs.freedesktop.org/attachment.cgi?id=6904

Mass version move, cvs -> git