May 2014 - Wine-Devel - list.winehq.org

Re: wined3d: Recognize cards that expose ARB_shader_texture_lod as DX10 capable even if they don't support EXT_gpu_shader4 (try 3)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-29 01:33, schrieb Andrei Slăvoiu: > Drop the check for glsl_version. All wine shaders use #version 120 > so it doesn't matter. That's not quite right. Yes, it is true that we never use GLSL 130, so the version check isn't representative for what wined3d actually supports. For shader model 4 support we need much more than just GLSL 130, half of the d3d10 infrastructure is still missing. GL_ARB_shader_texture_lod doesn't imply shader model 4 support. My Radeon X1600 supports this extension on OSX, and this is a shader model 3 card. The X1600 doesn't support EXT_gpu_shader4 or GLSL 130. The point of this code is to check the capabilities of the card, not the capabilities of our d3d implementation. Thus to prevent SM 3 cards from being reported with PCI IDs that suggest SM 4 capabilities you need to check for all the other functionality that's supported by EXT_gpu_shader4 / GLSL 130. Even if we have a SM 4 capable card our d3d9 implementation does not expose SM 4 support. But neither does Microsoft's d3d9 implementation. There's also GLX_MESA_query_renderer. It gives us the PCI IDs and video memory size directly, without all the string parsing guesswork. We cannot use it wined3d directly. A possible approach would be to expose a similar WGL_WINE/MESA_query_renderer extension from winex11.drv and winemac.drv and use that in wined3d. The current wined3d guesswork code could be moved to winex11.drv and used in cases where GLX_MESA_query_renderer is not supported. (OSX has similar functionality that's always available) User32 also has a function (EnumDisplayDevices) to query the GPU identification string, and some applications (Company of Heroes demo) fail if the user32 GPU name differs from the d3d9 GPU name. So maybe a WGL extension isn't quite the right interface, and it should be something that does not require a GL context so user32.dll can use it as well. EnumDisplayDevices does not export all the information wined3d needs though - the PCI IDs and video memory size are missing I think. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThvZZAAoJEN0/YqbEcdMwsY8QAJG1NQVMSqjwaguVR0cwwNXq IMYCRWL+5cJPxK4Eodt4bF+zZDObqCz9r3hAJVlkA6bJIcflNHJwedT0ddeOAfpe 0Xc8g+NvspN715yNt51PpzcnlSqh2vS18qp1JLb4l00pZuPt8PMNqC0gaePkv+tY 1wY3B/kgbl0TfcIRpxWbwZBcIAM2h4g+FGCHFPFeznhMYWqFaJ67OKW1KAdfpBTT lPZsaNDXtU8hSaVQYVk7ITulUl0C8tW/MExnh4zclz6b/wQuG+/M0WRg5v/YDlNq 0ZAsVqT60+MbepR87ehYDnLB7RMjZMjZhEZ4/drafFbOQBmqL7YJjgbFsbBBXLTt COf/1mjiz7TptUvSUyDRc27o1K+YP1UoswsVdXT37sWkP9gtHtQFeLLNx8ZuR4pa 2yQ7xNIBi7KPNBjz9Q0RKYvc11oGVUvFSuD0gLgNuHZxdOmBWwZyHeSce9adHHGU 5t4Oz0FsTZuEiiuJXPTDatp06KQQpUZ/c7FgcO7bxIpn/NNUCZGKZdKT/ZYM1waf BEtBL2Ov+DzRnvRM3/lVPdaiMD1IY54bqTeU7NOiKCEFhBl0elCAblj155tVaKdR 5WekiCEsvB8S4FE6stDa+GewpBWUZiVLGSL49S0MViPqAbkbgcjcNlRVg6IEH2Zo tyQIl6/9DwdY1TCllA9W =Z1W8 -----END PGP SIGNATURE-----

May 29, 2014

Re: [2/2] ws2_32: Properly implement SO_CONNECT_TIME (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7316 Your paranoid android. === wvistau64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === w2008s64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000

May 29, 2014

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Andrei Slăvoiu

În ziua de Mar 27 Mai 2014, la 21:13:44, Stefan Dösinger a scris: > Am 2014-05-27 17:35, schrieb Stefan Dösinger: > > Am 2014-05-27 16:56, schrieb Andrei Slavoiu:> Yes, > > > >> GL_ARB_shader_texture_lod is exposed by mesa for all drivers in > >> both core and compatibility contexts. So should I check for > >> GL_ARB_shader_texture_lod instead of glsl version? > > > > No, I'd say use something like if (EXT_gpu_shader4 || ( > > ARB_shader_texture_lod && glsl_version >= 1.30). > > An even nicer solution would be to use the capabilities reported by > the shader backend. See select_shader_backend() and and > shader_backend->shader_get_caps. Unsupported vertex shaders would > match a dx 7 card, VS 1.x dx 8, VS 2/3 dx9 and 4 dx10. For separating > dx6 and and 7 the fixed function fragment pipeline info is needed > (number of supported texture units). > > Note that we currently do not support pixel shaders on dx8 cards, and > probably never will. That's because those cards use separate GL > extensions (ATI_fragment_shader and GL_NV_register_combiners + > GL_NV_texture_shader). Thus it's better to look only at vertex shaders > for now to prevent dx8 cards from being reported as dx7. Actually, d3d_level_from_gl_info is misleading (broken even), as it will check for SM3 capability and then return that the card is capable of directx 10 (which requires SM4). I'll look into a better way to report the capabilities to the callers (maybe use d3d feature levels?) and also for a way to share the code that identifies the capabilities with shader_glsl_get_caps. But that in a future patch, after the second version of this one gets submitted.

May 28, 2014

Re: [2/2] ws2_32: Properly implement SO_CONNECT_TIME

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7301 Your paranoid android. === w2000pro (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === wvistau64 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w2008s64 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w7u (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w8 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === wvistau64 (64 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w2008s64 (64 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0

May 28, 2014

Re: Fix for PlgBlt, the XFORM matrix was calculated incorrectly

by Alexander Almaleh

Ok. Btw, I have some other things on my head now, so it might be a week or two before I come back to this. On Fri, May 23, 2014 at 1:35 AM, Michael Mc Donnell <michael(a)mcdonnell.dk>wrote: > Hi Alexander > > On Thu, May 22, 2014 at 2:25 AM, Alexander Almaleh <sashoalm(a)gmail.com>wrote: >> >> OK, I'll try to write a unit test. I found this tutorial - >> https://www.winehq.org/docs/winedev-guide/testing, is it the correct >> thing to read? >> > > Yes that is the correct thing to read. > > >> You might be able to get your patch in without the automated test, but >>> I think you need to explain clearly what was wrong with the old code and >>> what you are doing instead. A few more simplified examples that test other >>> cases in your bug report might also help. >>> >> >> The trouble is I don't quite remember the exact steps I took 5 years ago >> to come up with the new formula. However, I do remember I came up to it by >> solving a system of linear equations. Since XFORM matrix is applied to each >> point, I took 3-4 measurements of how points are transformed by PlgBlt, and >> then used that to make equations of the type applyXFORM(xSrc) = xDest. By >> solving the equations for the XFORM matrix, I came up with the correct >> formula I need to get the XFORM matrix from the input variables. I used an >> online linear equation solver, so there's no human error. >> >> I'll try to recreate the steps, maybe it'll be easier to just explain >> them. I'll look into making automated tests, too. >> > > Sounds good. Like you are saying, figuring out the formulas again would be > a good idea. The current code does not explain where the formulas are > coming from. Adding that as comments in your patch would make it easier to > verify than the current code. > > Michael > >

May 27, 2014

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-27 17:35, schrieb Stefan Dösinger: > Am 2014-05-27 16:56, schrieb Andrei Slavoiu:> Yes, >> GL_ARB_shader_texture_lod is exposed by mesa for all drivers in >> both core and compatibility contexts. So should I check for >> GL_ARB_shader_texture_lod instead of glsl version? > No, I'd say use something like if (EXT_gpu_shader4 || ( > ARB_shader_texture_lod && glsl_version >= 1.30). An even nicer solution would be to use the capabilities reported by the shader backend. See select_shader_backend() and and shader_backend->shader_get_caps. Unsupported vertex shaders would match a dx 7 card, VS 1.x dx 8, VS 2/3 dx9 and 4 dx10. For separating dx6 and and 7 the fixed function fragment pipeline info is needed (number of supported texture units). Note that we currently do not support pixel shaders on dx8 cards, and probably never will. That's because those cards use separate GL extensions (ATI_fragment_shader and GL_NV_register_combiners + GL_NV_texture_shader). Thus it's better to look only at vertex shaders for now to prevent dx8 cards from being reported as dx7. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThOPoAAoJEN0/YqbEcdMwvvcP/jVwAxed6lqHNdMy9qrfwJ25 sfK2Npf0tiuvdWT5t/pGMhiAF/abWoS9w5qhD8OMEXo4TpYOS4IkLxWSJcJ/adAD w0cyduvRu0nONy5apHPaR4py6EIYrZB2n4WZmoj/QHJJjWzFSKGeQweuohcr8NvJ ddc/di9hjyquGuiTUNRU+hHiW3HPYVe4CJNZEH3jXyG6q0e6GgztxS6p10x2RcZY SlSKnOcSgEZAQvFPlZ50QWz6oElKFGzrkODcQZhuh8OHxfOntqzJyXg8PB5Ft2L0 6cHtVE5eTuXT6thcOds1759aQ1qLO7zOC59wP3N72Wp5L8TU/rN+Gg4ooHnV2ctw gkBZ0SkgsK7tR2aQ+gc9zU4CUEcX4HRuO3vMgSElUGl4Df6yuSKLteVy/eyKXlrX pHDcOdO899978tk+NibwQZOHyKo8l5jpzdVpkiOkd72lk3xLicIGlN3zKHZL0Cfw Esq3bI60boPbOVdYP+yI6X8a/UoBtpIvWxe5dfFQJqzm+gOnkvcEY5QEEx8P9IPd 895BrPcUOIxMCpPlZ26Op7eIGgtKPpRi2TJ7BwYgwWAdgeBNuQnlUcdkCn9FFvSQ jYvKze39X+q5vYxSAlKVAszhMOOXQM/NC9Vol1WfiL1T6+CFWhrR+cPd0x0So6uD 9u1plWqMoP7rf2QtxAPR =fZmC -----END PGP SIGNATURE-----

May 27, 2014

Re: About wineserver and winsock

by Erich E. Hoover

On Mon, May 26, 2014 at 3:23 PM, Chris Robinson <chris.kcat(a)gmail.com> wrote: > On 05/26/2014 09:31 AM, Damjan Jovanovic wrote: >> >> That wouldn't always work: in theory, DuplicateHandle() could transmit >> the socket to another process, which wouldn't have the same ws2_32 >> thread. > > > I don't know much about winsock and wineserver and such, but would it be > possible for a handle to track whether it's been duplicated from/to another > process and only involve wineserver when it has been? You actually need to use WSADuplicateSocket[A|W] on sockets, so it's conceivable that we could keep a record of which handles have been duplicated for other processes. Best, Erich

May 27, 2014

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-27 16:56, schrieb Andrei Slavoiu:> Yes, > GL_ARB_shader_texture_lod is exposed by mesa for all drivers in > both core and compatibility contexts. So should I check for > GL_ARB_shader_texture_lod instead of glsl version? No, I'd say use something like if (EXT_gpu_shader4 || ( ARB_shader_texture_lod && glsl_version >= 1.30). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThLDBAAoJEN0/YqbEcdMwkD4P/jSQ8W3qJ36kMNmuJ8XbA8nx zM3DH4KMOIY3Zgt1Mf/j8ycP/zhqy+GPkXDnWctaCAkrvrqeRoItMEbeIcgMI+yH vGBJLIBMuF7NyQ9K4jIxpdHnO81YOkklZPbLV62Fxv5zgrQCrIidm4kY/1EnvOr3 pXUbT1E596fxnZTvxD1/Y5MASrTrmfE5sDlsI49k0xzXQRBbc+gosJHVryUWSf3x 4vv29NiYW0CL0MVhbd0GUoY9HlMZnzeshhWO4689BFKYYTCi3BSBilfcr9qiAsx0 ud7EjehnD11NUnQmb1ail/XZRT+FpUEqSWkYO/GYw4wqthJcrnPVXa+AiSajEAjC b4ODtZUegjTZJ+bEEwEAW797tpo3KA9JIAl/c+zktE23PK3APSgmm3hD0Pr7PSNk rd9kKplvsXvvk/eqii6uJ8lx0ZnuoDkRgDkSbTzdy7eEfOGJTQ+1Mr78rPT2Lgpw AVzIUtqfbcT1fBOib0Cl6D38mI56hNb9oCMt4P2T8JxJXhnAAFK53e8SdVymE7zx 1vj4sEouFs0xw2CChhAPIkiWH4iFuSZWVGnudEy94cp/1iGO9m+zQk2unsqrzENs VmpAEvLcA63gtzchqZmyMibWbj+OhuM6NkicCObGuddZ1PXRkbbSV5hADSM8ZHnb b0Adkmlm5rdNfTS5p6Ys =ehtk -----END PGP SIGNATURE-----

May 27, 2014

Re: Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Andrei Slavoiu

On Tuesday 27 May 2014 15:56:57 Stefan DÃ¶singer wrote: > Am 23.05.2014 um 00:23 schrieb Andrei SlÄvoiu <andrei.slavoiu(a)gmail.com>: > > Mesa drivers do not expose EXT_GPU_SHADER4 as all functionality it offers > > is already part of OpenGL 3.0. This causes all cards that are not > > explicitly recognized by wine (for example all GCN cards) to be treated > > as DX9 cards and presented to Windows apps as Radeon 9500. > > The problem is that without GL_EXT_gpu_shader4 or GL_ARB_shader_texture_lod > we cannot handle the texldd instruction. Right now we cannot use core > contexts, so unless the driver exposes one of those extensions in > compatibility contexts we are stuck on a shader model 2 feature level :-( . > > The level detection your patch changes isn't directly related to this, as > the shader model version support is controlled differently. But a Radeon > 9500 matches a card with shader model 2 support much better than a Radeon > R9. > > Does this driver / gpu combination support GL_ARB_shader_texture_lod? Yes, GL_ARB_shader_texture_lod is exposed by mesa for all drivers in both core and compatibility contexts. So should I check for GL_ARB_shader_texture_lod instead of glsl version?

May 27, 2014

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Stefan Dösinger

Am 23.05.2014 um 00:23 schrieb Andrei Slăvoiu <andrei.slavoiu(a)gmail.com>: > Mesa drivers do not expose EXT_GPU_SHADER4 as all functionality it offers is > already part of OpenGL 3.0. This causes all cards that are not explicitly > recognized by wine (for example all GCN cards) to be treated as DX9 cards and > presented to Windows apps as Radeon 9500. The problem is that without GL_EXT_gpu_shader4 or GL_ARB_shader_texture_lod we cannot handle the texldd instruction. Right now we cannot use core contexts, so unless the driver exposes one of those extensions in compatibility contexts we are stuck on a shader model 2 feature level :-( . The level detection your patch changes isn't directly related to this, as the shader model version support is controlled differently. But a Radeon 9500 matches a card with shader model 2 support much better than a Radeon R9. Does this driver / gpu combination support GL_ARB_shader_texture_lod?

May 27, 2014