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
On Sun, Jan 26, 2014 at 1:08 PM, Ruslan Kabatsayev b7.10110111@gmail.com wrote:
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
Quickest way is most likely to do a regression test in Wine wine Mesa 9.1, file a bug and if there is a mesa regression in the lot (this might all be normal behaviour), you will be asked to file a bug upstream on freedesktop.org.
J. Leclanche
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-01-26 14:08, schrieb Ruslan Kabatsayev:
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?
There are some corner cases in the d3d fixed function pipeline which we can't handle properly without shaders. Unfortunately, once we detect such a corner case it's too late to turn on shaders.
A possible workaround for the user is to set UseGLSL=disabled. It's not a good long-term fix though.
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?
Does the "slow" mean that Wine hits a software rendering fallback and Mesa emulates vertex shaders with the CPU? I hated it when OSX advertised features the card didn't have, and I think it's a very bad idea for Mesa to do the same thing.
The GL errors should be fixed though. Can you try to find the commits in Wine and Mesa that started those errors?
On Mon, Jan 27, 2014 at 5:53 PM, Stefan Dösinger stefandoesinger@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-01-26 14:08, schrieb Ruslan Kabatsayev:
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?
There are some corner cases in the d3d fixed function pipeline which we can't handle properly without shaders. Unfortunately, once we detect such a corner case it's too late to turn on shaders.
A possible workaround for the user is to set UseGLSL=disabled. It's not a good long-term fix though.
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?
Does the "slow" mean that Wine hits a software rendering fallback and Mesa emulates vertex shaders with the CPU? I hated it when OSX advertised features the card didn't have, and I think it's a very bad idea for Mesa to do the same thing.
Yes, a SW fallback. Vertex shaders are always on CPU on i915 by design. It's fragment shaders which suffer from SW fallback when something is used which is unsupported by the chip.
The GL errors should be fixed though. Can you try to find the commits in Wine and Mesa that started those errors?
Yeah, I've already bisected Mesa. Its commits (which appear next to each other in history) are:
1) The one making wine 1.5.17 slow: 97217a40f97cdeae0304798b607f704deb0c3558 is the first bad commit commit 97217a40f97cdeae0304798b607f704deb0c3558 Author: Eric Anholt eric@anholt.net Date: Wed Apr 17 13:55:08 2013 -0700
i915: Always enable GL 2.0 support.
There's no point in shipping a non-GL2 driver today.
:040000 040000 d039f68bbc5a5e610adbeb3d310350a844911fea efac289465401566fec6063b544c0a844e302559 M src
2) The one leading to GL_INVALID_FRAMEBUFFER_OPERATION: 4df1b986d3e44dc035227054000a1d0e1846ef07 is the first bad commit commit 4df1b986d3e44dc035227054000a1d0e1846ef07 Author: Eric Anholt eric@anholt.net Date: Wed Apr 17 19:10:29 2013 -0700
i915: Add support for GL_EXT_texture_sRGB and GL_EXT_texture_sRGB_decode.
This brings the driver up to GL 2.1.
:040000 040000 efac289465401566fec6063b544c0a844e302559 5bd49114ce64a359f4a0e3673ec27ca01590adbc M src
I'm bisecting wine now to find which commit starts GL_INVALID_FRAMEBUFFER_OPERATION error.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJS5mTVAAoJEN0/YqbEcdMwViwP/3iPmbKEtH/5BBcNLg/IqxGJ sie+Qn2Yibp+LBf2iYPqshjDKAHBNXiaiMKqTKG8GWzGC235K/Nqc0QoV2sFRRJW EiroXisQlG6AupmWKqzqldSVYC93tehCQdp982Rk3XYENQmmsuE+OSwMwXAg32ji 8gKSrZ7EYwT2b4NYy79o7p/KiR5+nO/Mwm7m8wNYLoYPPjQ3yk95pxPxlNlsuAZw eEeDRNU7lXtIGrYsO+xpA4saCW93vZp2rUqXLlQjAMdOi2HU3F5R7jmsLn/pqvJV rIawm53PMP7bauUcB926StXYwW8yLeEHAbGtER4t2nJKf9tHNrNNKD0Q8CwrpE1F fKwMJDHx5YVkeftADm2OiX4PNKflvwfeKTeib9ChCP7ApXbulbRi3Qx/n7Al+ZWv 6THEBaSS9PlxvPQQ1zwSduATfAMKsMulxDz6I0SPclVTnFTmMcfLxcNtFIHsjkCR US7Q6hKGHfqLO/OQEdpiJ/4KlQmXrkQkWj0VOwnsBmWjBFv02Q/8Xoj4i50f7Qev 7KadSvgpgAg5Yu468jBbiVwxibxaxNQZNuJgFUnDfMyMdwBYXD613Ngnm1GriOUO F+MWvaCKpMK4zsAYIZg366GTjH7XqANVZ1vaCruoAdmB6r39A3/mMiS5kmPoPLP5 /6tpS/N9eJfBOVyzv9Au =q+e8 -----END PGP SIGNATURE-----
On Mon, Jan 27, 2014 at 11:48 PM, Ruslan Kabatsayev b7.10110111@gmail.com wrote:
On Mon, Jan 27, 2014 at 5:53 PM, Stefan Dösinger stefandoesinger@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-01-26 14:08, schrieb Ruslan Kabatsayev:
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?
There are some corner cases in the d3d fixed function pipeline which we can't handle properly without shaders. Unfortunately, once we detect such a corner case it's too late to turn on shaders.
A possible workaround for the user is to set UseGLSL=disabled. It's not a good long-term fix though.
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?
Does the "slow" mean that Wine hits a software rendering fallback and Mesa emulates vertex shaders with the CPU? I hated it when OSX advertised features the card didn't have, and I think it's a very bad idea for Mesa to do the same thing.
Yes, a SW fallback. Vertex shaders are always on CPU on i915 by design. It's fragment shaders which suffer from SW fallback when something is used which is unsupported by the chip.
The GL errors should be fixed though. Can you try to find the commits in Wine and Mesa that started those errors?
Yeah, I've already bisected Mesa. Its commits (which appear next to each other in history) are:
- The one making wine 1.5.17 slow:
97217a40f97cdeae0304798b607f704deb0c3558 is the first bad commit commit 97217a40f97cdeae0304798b607f704deb0c3558 Author: Eric Anholt eric@anholt.net Date: Wed Apr 17 13:55:08 2013 -0700
i915: Always enable GL 2.0 support. There's no point in shipping a non-GL2 driver today.:040000 040000 d039f68bbc5a5e610adbeb3d310350a844911fea efac289465401566fec6063b544c0a844e302559 M src
- The one leading to GL_INVALID_FRAMEBUFFER_OPERATION:
4df1b986d3e44dc035227054000a1d0e1846ef07 is the first bad commit commit 4df1b986d3e44dc035227054000a1d0e1846ef07 Author: Eric Anholt eric@anholt.net Date: Wed Apr 17 19:10:29 2013 -0700
i915: Add support for GL_EXT_texture_sRGB and GL_EXT_texture_sRGB_decode. This brings the driver up to GL 2.1.:040000 040000 efac289465401566fec6063b544c0a844e302559 5bd49114ce64a359f4a0e3673ec27ca01590adbc M src
I'm bisecting wine now to find which commit starts GL_INVALID_FRAMEBUFFER_OPERATION error.
Bisection gives this (with Mesa $(git describe)=snb-magic-15798-g4df1b98): 09443f14e75e134328643b5d33aff61bdf4dca32 is the first bad commit commit 09443f14e75e134328643b5d33aff61bdf4dca32 Author: Henri Verbeet hverbeet@codeweavers.com Date: Wed Jul 18 21:32:34 2012 +0200
wined3d: Enable "AlwaysOffscreen" by default.
:040000 040000 c37d9d0fe4165e09a89c9e22066e3acc17537bbb 0dd4d64233f4441ab3613327e86d9fe8187ec4ed M dlls
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJS5mTVAAoJEN0/YqbEcdMwViwP/3iPmbKEtH/5BBcNLg/IqxGJ sie+Qn2Yibp+LBf2iYPqshjDKAHBNXiaiMKqTKG8GWzGC235K/Nqc0QoV2sFRRJW EiroXisQlG6AupmWKqzqldSVYC93tehCQdp982Rk3XYENQmmsuE+OSwMwXAg32ji 8gKSrZ7EYwT2b4NYy79o7p/KiR5+nO/Mwm7m8wNYLoYPPjQ3yk95pxPxlNlsuAZw eEeDRNU7lXtIGrYsO+xpA4saCW93vZp2rUqXLlQjAMdOi2HU3F5R7jmsLn/pqvJV rIawm53PMP7bauUcB926StXYwW8yLeEHAbGtER4t2nJKf9tHNrNNKD0Q8CwrpE1F fKwMJDHx5YVkeftADm2OiX4PNKflvwfeKTeib9ChCP7ApXbulbRi3Qx/n7Al+ZWv 6THEBaSS9PlxvPQQ1zwSduATfAMKsMulxDz6I0SPclVTnFTmMcfLxcNtFIHsjkCR US7Q6hKGHfqLO/OQEdpiJ/4KlQmXrkQkWj0VOwnsBmWjBFv02Q/8Xoj4i50f7Qev 7KadSvgpgAg5Yu468jBbiVwxibxaxNQZNuJgFUnDfMyMdwBYXD613Ngnm1GriOUO F+MWvaCKpMK4zsAYIZg366GTjH7XqANVZ1vaCruoAdmB6r39A3/mMiS5kmPoPLP5 /6tpS/N9eJfBOVyzv9Au =q+e8 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-01-27 21:14, schrieb Ruslan Kabatsayev:
Bisection gives this (with Mesa $(git describe)=snb-magic-15798-g4df1b98): 09443f14e75e134328643b5d33aff61bdf4dca32 is the first bad commit commit 09443f14e75e134328643b5d33aff61bdf4dca32 Author: Henri Verbeet hverbeet@codeweavers.com Date: Wed Jul 18 21:32:34 2012 +0200
wined3d: Enable "AlwaysOffscreen" by default.
:040000 040000 c37d9d0fe4165e09a89c9e22066e3acc17537bbb 0dd4d64233f4441ab3613327e86d9fe8187ec4ed M dlls
Does the GPU support GL_ARB_depth_texture? If not this is potentially a duplicate of bug 21708.
- The one making wine 1.5.17 slow:
97217a40f97cdeae0304798b607f704deb0c3558 is the first bad commit commit 97217a40f97cdeae0304798b607f704deb0c3558 Author: Eric Anholt eric@anholt.net Date: Wed Apr 17 13:55:08 2013 -0700
i915: Always enable GL 2.0 support.
There's no point in shipping a non-GL2 driver today.
I don't know about the extend this card support pixel shaders. There may be a way for the driver and/or wine to work without falling back to software. But overall I disagree with the premise of this patch. There's a point in shipping a < GL 2.0 driver for hardware that just doesn't support GL 2.0. But there is no point in requiring the application to magically know if the driver's GL 2.0 is really 2.0 or just something rigged with software fallback mines.
Can you file a Mesa bug about this issue? I think we should ask the Mesa devs about their opinion.
On 30 January 2014 22:22, Stefan Dösinger stefandoesinger@gmail.com wrote:
I don't know about the extend this card support pixel shaders. There may be a way for the driver and/or wine to work without falling back to software. But overall I disagree with the premise of this patch. There's a point in shipping a < GL 2.0 driver for hardware that just doesn't support GL 2.0. But there is no point in requiring the application to magically know if the driver's GL 2.0 is really 2.0 or just something rigged with software fallback mines.
Can you file a Mesa bug about this issue? I think we should ask the Mesa devs about their opinion.
I don't know if that's specifically the issue here, but GL 2.0 also introduced point sprite coordinate origin switching. We need that when rendering offscreen, and I seem to recall i915 hitting a software fallback for that. Without GL 2.0 we'd just render incorrectly instead. It should be easy enough to rule that out by commenting out the "glPointParameteriNV(GL_POINT_SPRITE_COORD_ORIGIN, origin);" call in psorigin(). It's also generally useful to set INTEL_DEBUG=perf when investigating these kinds of things.
On Fri, Jan 31, 2014 at 2:27 AM, Henri Verbeet hverbeet@gmail.com wrote:
On 30 January 2014 22:22, Stefan Dösinger stefandoesinger@gmail.com wrote:
I don't know about the extend this card support pixel shaders. There may be a way for the driver and/or wine to work without falling back to software. But overall I disagree with the premise of this patch. There's a point in shipping a < GL 2.0 driver for hardware that just doesn't support GL 2.0. But there is no point in requiring the application to magically know if the driver's GL 2.0 is really 2.0 or just something rigged with software fallback mines.
Can you file a Mesa bug about this issue? I think we should ask the Mesa devs about their opinion.
I don't know if that's specifically the issue here, but GL 2.0 also introduced point sprite coordinate origin switching. We need that when rendering offscreen, and I seem to recall i915 hitting a software fallback for that. Without GL 2.0 we'd just render incorrectly instead. It should be easy enough to rule that out by commenting out the "glPointParameteriNV(GL_POINT_SPRITE_COORD_ORIGIN, origin);" call in psorigin(). It's also generally useful to set INTEL_DEBUG=perf when investigating these kinds of things.
Indeed, you're right. If I return psorigin() before any GL calls are made (first one, not NV one is effective, btw), then it works fast enough.
On Fri, Jan 31, 2014 at 12:38 PM, Ruslan Kabatsayev b7.10110111@gmail.com wrote:
On Fri, Jan 31, 2014 at 2:27 AM, Henri Verbeet hverbeet@gmail.com wrote:
On 30 January 2014 22:22, Stefan Dösinger stefandoesinger@gmail.com wrote:
I don't know about the extend this card support pixel shaders. There may be a way for the driver and/or wine to work without falling back to software. But overall I disagree with the premise of this patch. There's a point in shipping a < GL 2.0 driver for hardware that just doesn't support GL 2.0. But there is no point in requiring the application to magically know if the driver's GL 2.0 is really 2.0 or just something rigged with software fallback mines.
Can you file a Mesa bug about this issue? I think we should ask the Mesa devs about their opinion.
I don't know if that's specifically the issue here, but GL 2.0 also introduced point sprite coordinate origin switching. We need that when rendering offscreen, and I seem to recall i915 hitting a software fallback for that. Without GL 2.0 we'd just render incorrectly instead. It should be easy enough to rule that out by commenting out the "glPointParameteriNV(GL_POINT_SPRITE_COORD_ORIGIN, origin);" call in psorigin(). It's also generally useful to set INTEL_DEBUG=perf when investigating these kinds of things.
Indeed, you're right. If I return psorigin() before any GL calls are made (first one, not NV one is effective, btw), then it works fast enough.
Now, as to INTEL_DEBUG. Here's the output:
intel_copy_texsubimage mismatched formats MESA_FORMAT_ARGB8888, MESA_FORMAT_RGB565 intelCopyTexSubImage - fallback to swrast intelReadPixels: fallback to swrast intel_copy_texsubimage mismatched formats MESA_FORMAT_ARGB8888, MESA_FORMAT_RGB565 intelCopyTexSubImage - fallback to swrast intelReadPixels: fallback to swrast intel_copy_texsubimage mismatched formats MESA_FORMAT_ARGB8888, MESA_FORMAT_ARGB1555 intelCopyTexSubImage - fallback to swrast intelReadPixels: fallback to swrast intel_copy_texsubimage mismatched formats MESA_FORMAT_ARGB8888, MESA_FORMAT_ARGB4444 intelCopyTexSubImage - fallback to swrast [snip repeating messages] ENTER FALLBACK 100000: point sprite coord origin Mapping a busy BO, causing a stall on the GPU. trace:fps:glxdrv_SwapBuffers @ approx 0.04fps, total 0.04fps trace:fps:swapchain_gl_present 0x1a7ff8 @ approx 0.04fps ENTER FALLBACK 100000: point sprite coord origin Mapping a busy BO, causing a stall on the GPU. trace:fps:glxdrv_SwapBuffers @ approx 0.22fps, total 0.44fps trace:fps:swapchain_gl_present 0x1a7ff8 @ approx 0.22fps Mapping a busy BO, causing a stall on the GPU.
Without glPointParameter() calls I don't have those errors after "[snip repeating messages]", but still do have CopyTexSubImage ones (although I didn't notice such a serious slowdown as was before; and these have also been before bisected wine commit).
On 31 January 2014 09:45, Ruslan Kabatsayev b7.10110111@gmail.com wrote:
Without glPointParameter() calls I don't have those errors after "[snip repeating messages]", but still do have CopyTexSubImage ones (although I didn't notice such a serious slowdown as was before; and these have also been before bisected wine commit).
If the CopyTexSubImage ones aren't repeating after initial loading, they may be from the wined3d GL quirk detection code or the FBO caps detection code, in which case they would be harmless.
On Fri, Jan 31, 2014 at 1:47 PM, Henri Verbeet hverbeet@gmail.com wrote:
On 31 January 2014 09:45, Ruslan Kabatsayev b7.10110111@gmail.com wrote:
Without glPointParameter() calls I don't have those errors after "[snip repeating messages]", but still do have CopyTexSubImage ones (although I didn't notice such a serious slowdown as was before; and these have also been before bisected wine commit).
If the CopyTexSubImage ones aren't repeating after initial loading, they may be from the wined3d GL quirk detection code or the FBO caps detection code, in which case they would be harmless.
They indeed don't repeat after loading. They appear after this commit:
7b0ba5153f3e42f31b922e5eb997d5e1d0cb44d4 is the first bad commit commit 7b0ba5153f3e42f31b922e5eb997d5e1d0cb44d4 Author: Matteo Bruni mbruni@codeweavers.com Date: Thu Nov 3 15:26:36 2011 +0100
wined3d: Test more thoroughly for post-pixelshader blending support, try on more texture formats.
:040000 040000 4ccfbad52a0797cdd96f4efccafeac45c6ce688a 026bd6e57c4cbbf8c906eddcb43527ffdbe233f7 M dlls
Hello all.
More than a month has passed since the bug report, and Mesa devs haven't said anything. What should my further actions be? I suppose some of the following:
1. Wait more 2. File a bug at winehq and hope that something could be done as a (automatic) workaround 3. Not rely on this being fixable and tell all users with i915 and similar chips to patch either wine or mesa, or maybe use some registry overrides in wine (UseGLSL and the like) 4. Something better?
Regards, Ruslan
On Sun, Feb 2, 2014 at 5:34 PM, Ruslan Kabatsayev b7.10110111@gmail.com wrote:
On Fri, Jan 31, 2014 at 1:47 PM, Henri Verbeet hverbeet@gmail.com wrote:
On 31 January 2014 09:45, Ruslan Kabatsayev b7.10110111@gmail.com wrote:
Without glPointParameter() calls I don't have those errors after "[snip repeating messages]", but still do have CopyTexSubImage ones (although I didn't notice such a serious slowdown as was before; and these have also been before bisected wine commit).
If the CopyTexSubImage ones aren't repeating after initial loading, they may be from the wined3d GL quirk detection code or the FBO caps detection code, in which case they would be harmless.
They indeed don't repeat after loading. They appear after this commit:
7b0ba5153f3e42f31b922e5eb997d5e1d0cb44d4 is the first bad commit commit 7b0ba5153f3e42f31b922e5eb997d5e1d0cb44d4 Author: Matteo Bruni mbruni@codeweavers.com Date: Thu Nov 3 15:26:36 2011 +0100
wined3d: Test more thoroughly for post-pixelshader blendingsupport, try on more texture formats.
:040000 040000 4ccfbad52a0797cdd96f4efccafeac45c6ce688a 026bd6e57c4cbbf8c906eddcb43527ffdbe233f7 M dlls
On 17 March 2014 12:53, Ruslan Kabatsayev b7.10110111@gmail.com wrote:
More than a month has passed since the bug report, and Mesa devs haven't said anything. What should my further actions be? I suppose some of the following:
The reality is probably that the Mesa (Intel) developers are pretty busy like everyone else, and i915 just isn't a very high priority. The correct approach to fixing these kinds of things is of course to fix the bug and send a patch, but that's often easier said than done. It may be possible to use MESA_EXTENSION_OVERRIDE="-GL_ARB_occlusion_query" as a workaround, but you'd have to test that.
On Fri, Jan 31, 2014 at 1:22 AM, Stefan Dösinger stefandoesinger@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-01-27 21:14, schrieb Ruslan Kabatsayev:
Bisection gives this (with Mesa $(git describe)=snb-magic-15798-g4df1b98): 09443f14e75e134328643b5d33aff61bdf4dca32 is the first bad commit commit 09443f14e75e134328643b5d33aff61bdf4dca32 Author: Henri Verbeet hverbeet@codeweavers.com Date: Wed Jul 18 21:32:34 2012 +0200
wined3d: Enable "AlwaysOffscreen" by default.
:040000 040000 c37d9d0fe4165e09a89c9e22066e3acc17537bbb 0dd4d64233f4441ab3613327e86d9fe8187ec4ed M dlls
Does the GPU support GL_ARB_depth_texture? If not this is potentially a duplicate of bug 21708.
According to glxinfo with Mesa before bad commits, it does support it. Also, there seem to have been some commits back in 2011 which worked with it, so I suppose it does.
- The one making wine 1.5.17 slow:
97217a40f97cdeae0304798b607f704deb0c3558 is the first bad commit commit 97217a40f97cdeae0304798b607f704deb0c3558 Author: Eric Anholt eric@anholt.net Date: Wed Apr 17 13:55:08 2013 -0700
i915: Always enable GL 2.0 support.
There's no point in shipping a non-GL2 driver today.
I don't know about the extend this card support pixel shaders. There may be a way for the driver and/or wine to work without falling back to software. But overall I disagree with the premise of this patch. There's a point in shipping a < GL 2.0 driver for hardware that just doesn't support GL 2.0. But there is no point in requiring the application to magically know if the driver's GL 2.0 is really 2.0 or just something rigged with software fallback mines.
Can you file a Mesa bug about this issue? I think we should ask the Mesa devs about their opinion.
Done: https://bugs.freedesktop.org/show_bug.cgi?id=74263
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJS6sKnAAoJEN0/YqbEcdMwTBsP/RpDjFuVxxv8+0LvkdT+LH62 9q/PfdsxBGQLCBpfJtuNjLP/2fsZ49SNs4cVY5tEj0FCU9lG8o14tPakBNfvxjXJ R4TE6ENzSZuv2pxilG5FS3ZGMks5bKQL6lcOjBmo3QPypHNZHtu0P9b6SotvWSrU VObpkayQGcY+hRgGvIABKvdtyJVXVeDGwbRbu+OKpFQZC27NhVx/V6lzkcBTHoAo K2OXuLLn7ESE9YtYNewaf4l7n5BHn/Dm2GDtSdsEFbpmyO0NtWLDqLHormz7W0Wz GPgFRgMs3/k9j+8MpT+UmbtFxgnT22afHE3f0TkS0yE145JdG5NHYuRQNUwjN5d+ dGZP05J5KiG8CDACDiNOhxDlx3sRDCCRvHSbjH6Ob3wz7ns2KK3kwHkvmMCwTjE3 AxB4bXxXzjr+LMUaeoRog0loF9mikDvLdDfejq9xGP68KIjisAzpH4rKkrMBESAc VSpn373igEcoGO19SyQwrmlRnvXzM1ewgrG4XetsmhYy7JwCZH5+x07o/FMw9mKV atV2CWqU4aTF5NKfzu1V0ys4GrtbGGvPsMuXyhq20G2q+t8xOKT/ARCGX9w6rQGX jhr0QnaCgziQxGeQ+WRTcL76uzc231QMH/EGZujfuiZKenutVqnnHrNrxLPxcDqO fxPnD37dUw4QnTZbLdzA =iPQ/ -----END PGP SIGNATURE-----
-
Henri Verbeet -
Jerome Leclanche -
Ruslan Kabatsayev -
Stefan Dösinger