Cross-regressions between wine and mesa: how to handle them?

Ruslan Kabatsayev b7.10110111 at gmail.com
Sun Jan 26 06:42:36 CST 2014


Hi all,

I've come across a problem, which may be simplest to see in the
following workability diagram, tested on GTAVC on a i915 machine:
_____________________________________________
Mesa_\_Wine_|__1.3.21__|__1.5.17__|__1.5.24+_|
____9.0_____|____OK____|____OK____|___slow___|
___~9.1-____|____OK____|___slow___|___slow___|
___~9.1+____|____OK____|_GL_error_|_GL_error_|

Here ~9.1- and ~9.1+ are bisected commits between 9.0 and 9.1, with
"-" earlier commit and "+" later one.
"slow" means slide show instead of normal animation.
"GL error" is a set of errors like
"err:d3d:device_clear_render_targets >>>>>>>>>>>>>>>>>
GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glClear @ device.c /
677".
Wine version 1.5.24+ means any wine newer than 1.5.24 up to 1.7.11.

All these things are related to wine trying to use GLSL as much as
possible, and Mesa trying to make it seem that it supports OpenGL 2+,
even on chips like i915, which don't support it.

For end user this looks like failing software, and moreover, it's not
easy to understand which software does have bug.
Wine perspective: On the one hand, wine seems to use what Mesa
exposes. On the other, why use shaders for games which don't need
them?
Mesa perspective: On the one hand, it wants to advertise more support
for latest OpenGL standards. On the other, why do it for very old HW
which doesn't support it?

So, I'm not sure where I should report these regressions - to
bugs.winehq.org or to bugs.freedesktop.org? I remember some similar
bugs reported to wine being closed as UPSTREAM (e.g. bug 33964), and
fixed (or worked around?) in Mesa. But on the other hand, wine 1.3
worked perfectly for all Mesa versions - is it really Mesa fault that
newer versions of wine don't work?

Could someone please explain how to handle such situations?

Regards,
Ruslan



More information about the wine-devel mailing list