February 2015 - Wine-Devel - list.winehq.org

Compiling with GCC 5.0

by Michael Cronenworth

Has anyone given GCC 5.0 a shot? It breaks x86_64 for me and other Fedora 22+ users (22 and up use 5.0). Running wine as pure 32-bit does not exhibit issues. We're using 1.7.36 with wine-staging applied. In 64-bit mode it will not create a valid wine-prefix so I cannot run winedbg and nothing eventful happens with gdb attached to wine. Any ideas on how to debug this further? Here is the terminal output when a fresh prefix is attempted to be made: http://fpaste.org/187377/25868142/ Regards, Michael

Feb. 19, 2015

Re: [PATCH 4/5] wined3d: Reject unsupported pitches in wined3d_surface_update_desc().

by Henri Verbeet

On 18 February 2015 at 17:25, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Fwiw, I don't have strong feelings about this, so feel free to do what > you think fits best. My thinking is that the entire patch is based on > assumptions about the client libraries. The conceptual difference is that if we just reject the pitch in wined3d it becomes part of the API, so if e.g. ddraw tries to set an invalid pitch that's ddraw's problem. While if we don't, it's like we're pretending that pitches like that are supported, but we really hope nothing ever uses them, so if something sets an invalid pitch it's wined3d's problem to make it work somehow. The distinction is of course a bit artificial because everything is under our control, but the former seems more proper to me. > If this assumption breaks it's > worth making the resulting message more verbose than a WARN. Possibly, although at least ddraw_surface_create() will already print an ERR if wined3d_texture_update_desc() fails.

Feb. 18, 2015

Re: [PATCH 4/5] wined3d: Reject unsupported pitches in wined3d_surface_update_desc().

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-18 um 17:10 schrieb Matteo Bruni: > 2015-02-18 16:44 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: >> It's a bit debatable in this case, since that depends on >> assumptions about callers outside of wined3d. > > Yes, that was my reasoning for using WARN. I can change that > though. I'm certainly going to move the check to > wined3d_texture_update_desc() as you suggest. Fwiw, I don't have strong feelings about this, so feel free to do what you think fits best. My thinking is that the entire patch is based on assumptions about the client libraries. If this assumption breaks it's worth making the resulting message more verbose than a WARN. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5LziAAoJEN0/YqbEcdMwD3oP/1ebOCguJuQqAVCjnGmihlVZ 8+imGRXdiRl83qvz+7g/D0j++DIpMLQdAP0GwkYsVKzkGh3lubkB8dm+/pRCB4ug xBXE8rDDlLYhlBgBQ6pZ2RkfSdGgmEwv1kZB5HXVSkolSM4L5UyUrfXG9zUjW6ki e4WyhYvpoJlK5wpJlndcqtGFoCocDE/3kGrIc6HvXNciY6wlRIu262anjXzNmFey sFZyvRhLTD10wx1CipG6VUY5aAEnmOALKA8N0Jw6CBnBi2DCvKcwEtmoZAAHMo68 fUBwC+W/E8pqApfF1FNju/3ukh24S1pgWzrb7LX+iiLRBeCdhV+UswbV5iL5QPrf v3r/wE5aL7QreP05vcnRqiSw+6/2b33rZ2vM4pdz+TOkH25DyBhUtYC0SsE4r8c1 7Vr0ofcJi/nzaEpmVdVbNtEFi0lNaxN7qA7HG7enaKYWnRooDVq/IVPfFoVuhtFl yXdcAt2byCQbuy9rSHvqXdtLejXqdgw1My1XOpSrJ+LiVncDoZEvi0TPa5M7q3Fx FJuZ/8jptJIxCvITbRkSCFMAQe8Nb5Ebj4Jdj77ePJrzco9Rmvf6CzyJk66P7Sw0 xq4kZTN9sp6yjdpj/wzMxEVx3J0p5wwIq7cBVvHfFIhtSdOqXpZqYqxTCqekEW2x cOFtmivT1TluHiUYstKd =E7V4 -----END PGP SIGNATURE-----

Feb. 18, 2015

Re: [PATCH 4/5] wined3d: Reject unsupported pitches in wined3d_surface_update_desc().

by Matteo Bruni

2015-02-18 16:44 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 18 February 2015 at 16:07, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: >> Am 2015-02-18 um 14:20 schrieb Matteo Bruni: >>> + if (pitch & (texture_resource->format->byte_count - 1)) > I don't think this would do the right thing for formats where > byte_count isn't a power of two. I also think the check belongs in > wined3d_texture_update_desc(), since otherwise the texture would be in > an inconsistent state if it fails. (That actually also applies to > failing to create the DIB section, but that one seems much harder to > avoid.) In theory there are no non-power of two byte_count texture formats from ddraw and d3d9ex always passes 0 as pitch. Actually initially I wrote the check as: if (WARN_ON(d3d) && pitch % texture_resource->format->byte_count) I can go back to something like that, it's probably more consistent with the point below. >>> + { >>> + WARN("Pitch unsupported, not a multiple of the texture format byte width.\n"); >>> + return WINED3DERR_INVALIDCALL; >>> + } >> I'd prefer this to be an ERR instead, and the return statement removed. >> The idea is that since we don't ever expect this check to be true it >> shouldn't result in different behavior and can be compiled out in a >> build where debugging is disabled. >> > It's a bit debatable in this case, since that depends on assumptions > about callers outside of wined3d. Yes, that was my reasoning for using WARN. I can change that though. I'm certainly going to move the check to wined3d_texture_update_desc() as you suggest.

Feb. 18, 2015

Re: [PATCH 4/5] wined3d: Reject unsupported pitches in wined3d_surface_update_desc().

by Henri Verbeet

On 18 February 2015 at 16:07, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am 2015-02-18 um 14:20 schrieb Matteo Bruni: >> + if (pitch & (texture_resource->format->byte_count - 1)) I don't think this would do the right thing for formats where byte_count isn't a power of two. I also think the check belongs in wined3d_texture_update_desc(), since otherwise the texture would be in an inconsistent state if it fails. (That actually also applies to failing to create the DIB section, but that one seems much harder to avoid.) >> + { >> + WARN("Pitch unsupported, not a multiple of the texture format byte width.\n"); >> + return WINED3DERR_INVALIDCALL; >> + } > I'd prefer this to be an ERR instead, and the return statement removed. > The idea is that since we don't ever expect this check to be true it > shouldn't result in different behavior and can be compiled out in a > build where debugging is disabled. > It's a bit debatable in this case, since that depends on assumptions about callers outside of wined3d.

Feb. 18, 2015

Re: [PATCH 4/5] wined3d: Reject unsupported pitches in wined3d_surface_update_desc().

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-18 um 14:20 schrieb Matteo Bruni: > + if (pitch & (texture_resource->format->byte_count - 1)) > + { > + WARN("Pitch unsupported, not a multiple of the texture format byte width.\n"); > + return WINED3DERR_INVALIDCALL; > + } I'd prefer this to be an ERR instead, and the return statement removed. The idea is that since we don't ever expect this check to be true it shouldn't result in different behavior and can be compiled out in a build where debugging is disabled. The basic idea originated from Henri: https://www.winehq.org/pipermail/wine-devel/2013-August/100974.html . -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5KrDAAoJEN0/YqbEcdMwdj0P/0kphTArNNtcxtIbt5noekiX wTwi7X6YhxkjryHENqvYKKO8ckBftBoxJHo9o4I82Cc+IRvj9GvrvvuZ5FuiMsJO 6dGmo5JSHnGGNG3rl/oZt31v3P/1LAba3GoFAgRwBfXCULue6gNRyC8+57ahlbLy xVWc2m249URRP3ML/O9+bXlzA61oQdS+5q54T+jmYv3X8K8AgDHATu114mcpxaAq hkHIKmW2WCoigCBrNHQTzcxMG3lsavMbnuMxSvQ/01/mwrKvmYYkvvBtR/AVI6W+ I7HLF4KZlz5BLZnS71joW2LLL35/z/3qtmaHi8dq/kCMaajow9dBQmstcUFvwJ4p UknSxgcCOgKreAZH3yTOH5LNgf8qZvB21wQ5Cn0NGEBW7bZKdUxfRftFN8IQY1Ht NhGB9cmvo3Ozv0z+i7wMfcXjntT9wL/2H77RqC4Xb9Z/igo+E2LJN0XqQYvwvtj7 wG4Fw5rH7vrO4g/IcfFYvbT7CMUYrPWtFaTfiMn5IOQZ4mx2gacktHcpZJnCUjw5 /uTQo+089YosnM+xY/WvDnjjI13svZt5c3gUMlvha30RjsX7PDfih/vNrr0qR5Y/ C6TLk8ffbmPOX6TTobndfZrWdb2sP3d7x1T1tx9nMAKJG0HFy5wvFoygEDOzFRYU tG/x7wnrmr3fYfUSEPJY =LuAf -----END PGP SIGNATURE-----

Feb. 18, 2015

Re: [PATCH 4/5] wined3d: Set GL_UNPACK_ALIGNMENT to 1 when uploading surfaces from user memory.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-18 um 14:23 schrieb Matteo Bruni: > It looks like that's correct WRT the client APIs but not for > formats used internally by wined3d. I tried to set > GL_UNPACK_ALIGNMENT to 1 in context_create and that fails > volume_v16u16_test in d3d9:visual on Mesa. It fails because we're > using GL_RGB16 to emulate D3DFMT_V16U16 when NV_texture_shader > isn't supported (and the texture is 1x2x2 which luckily triggers > the bug). I'm aware of some problems with those conversions, and I am working on a test and some fixes right now. > I think conversions are the only cases where we can currently get > pitches non multiple of the pixel byte width and we can fix those > by either using a different pitch (we're free to choose it anyway) > or avoiding those 3-channels formats altogether. The attached patch > takes the former approach. The reason why I chose to use the same pitch alignment was because we set GL_UNPACK_ALIGNMENT globally. So once that setting is gone I don't think anything is stopping us from choosing a different pitch. The V8U8 and V16VU16 converts should be switched to RGBA types (but RGB internals) regardless of that. The drivers don't like non-padded formats either. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5Ja0AAoJEN0/YqbEcdMwr5wQAILo3M6FH39zKmW5RTASlQbG cx/KHC+P/dnIUtQCoGYQmMzDvHY4XYfY5CsEIF9Rc/1hELQxz4FqMRKk56j6K0AZ 7Vq4zdQFWMbdq+3rbj3YHZrMoWCTBbwc+4Pz08YcaGXRlldJVt5tHS5lisTyUN6Q NZnxQZkXcXX9SZaVgUeynez4XfvMwwHn8wBzd15qtMSyBMechUkAkTcVs9mJB41C B2BMuCuHuMm4MkdfnKIcG5IeyHRcpbrpFRH8Hh/vFFLJSqKYEP6XD2jhAuM3Nyqz ek+uTndNhrrv7ffPMe5YNQvlAjdODhNwZVNIR7EHaIf/3R2fRLG0P4I/zN15Kt0s rFQPlYvcL0/8oCKY3H0NReLh+uTrXmH8E+lallUKmba71OGJPxDLCDIfD0Tgfhlt 3SezJ9i0kBQeb1QAFnChpAzrtNMO1fNrYRQ1My1bJy/Z/WtdE/aF2dsSXU8lz04Y TQyVPuUEf9ZscAtmHjNll3Bnzd9IOs3sdor4xEqQtAgQ9NzhlmDzREgk0AnBD9CQ E3uf8bF5akVrE8STwHZlcWofRDO3ruq8pyOkJh+BBEUdrxaGoTSMlu6Kl/Ry63Ba Gy94/WegrSWx+IJfN1p3igfWFwOhhAP2GRjb8sKS7NKbv3cJJd1T8VMy6e40iMSO nZdH6xu1tmzphMnK1opl =EFgz -----END PGP SIGNATURE-----

Feb. 18, 2015

Re: [PATCH 4/5] wined3d: Set GL_UNPACK_ALIGNMENT to 1 when uploading surfaces from user memory.

by Matteo Bruni

2015-02-11 10:46 GMT+01:00 Stefan Dösinger <stefandoesinger(a)gmail.com>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2015-02-10 um 22:05 schrieb Henri Verbeet: >> What's a bit awkward about this is that if the pitch isn't a >> multiple of the pixel byte width it's still not going to work. But >> I guess this is the best we can do. > Does this ever happen? D3D9 doesn't allow specifying a manual pitch, > and ddraw has at most 4 byte pixels and enforces a pitch alignment of > 4 according to our tests. > > Technically 24-bit RGB8 can have a misaligned pitch, but that isn't > supported anywhere. It looks like that's correct WRT the client APIs but not for formats used internally by wined3d. I tried to set GL_UNPACK_ALIGNMENT to 1 in context_create and that fails volume_v16u16_test in d3d9:visual on Mesa. It fails because we're using GL_RGB16 to emulate D3DFMT_V16U16 when NV_texture_shader isn't supported (and the texture is 1x2x2 which luckily triggers the bug). I think conversions are the only cases where we can currently get pitches non multiple of the pixel byte width and we can fix those by either using a different pitch (we're free to choose it anyway) or avoiding those 3-channels formats altogether. The attached patch takes the former approach. Otherwise I can still go ahead with this patch but it would be a bit cumbersome to have to set UNPACK_ALIGNMENT every time when once per context should be enough (unless I'm missing something).

Feb. 18, 2015

RE: icinfo: Do not output an extra space at end of line

by Hugh McMaster

On Wed, 18 Feb 2015 13:32:20 +0100, Stefan Dösinger wrote: > Am 2015-02-18 um 11:53 schrieb Hugh McMaster: > > - if (ii.dwFlags & VIDCF_QUALITY) mywprintf(sspc_fmt, VIDCF_QUALITY_W); > > + if (ii.dwFlags & VIDCF_QUALITY) mywprintf(s_fmt, VIDCF_QUALITY_W); > > if (ii.dwFlags & VIDCF_CRUNCH) mywprintf(sspc_fmt, VIDCF_CRUNCH_W); > I don't think this works. If VIDCF_QUALITY is not set, but any other > flag is, it will now print a leading space. Good point. I'll rethink this and resend.

Feb. 18, 2015

Re: icinfo: Do not output an extra space at end of line

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-18 um 11:53 schrieb Hugh McMaster: > - if (ii.dwFlags & VIDCF_QUALITY) mywprintf(sspc_fmt, VIDCF_QUALITY_W); > + if (ii.dwFlags & VIDCF_QUALITY) mywprintf(s_fmt, VIDCF_QUALITY_W); > if (ii.dwFlags & VIDCF_CRUNCH) mywprintf(sspc_fmt, VIDCF_CRUNCH_W); I don't think this works. If VIDCF_QUALITY is not set, but any other flag is, it will now print a leading space. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5IZUAAoJEN0/YqbEcdMwTg8QAI0rVUkh9r19pCZbCEPnk+AQ z5Da4dia28IpRlUYYW1bvZgxUpbWZi67NQr7oAs12fbhVMzyvoNxRI+J4bUpB/Rl sFxcNNIxwiJ47iVXzOQ54d4jO0SlhjsRB07hm9Z6o/DcNCPLXpq8UvDEErkHRHMp dZMF0D5dRTaxkqxXGIcks8kLT7yODKeCsG/T4oZ4D7eYMYoKaODmw7lUbcaRsTk1 hKcqdz9BfgmmwLk1xcs+Ssy/7sgN+smJPwGDWEWT2W0kto2M3OLb6Aot6olKncQo ngn1KIhPOzauomfW7+XFr6ezQZaBq4mPVqDYpN7ZHUewPl/1TUDYYIzMxDaXwZrx xcgNPcrKR3HQEF2JycYoWgxb3zTfn5h9M4Q5vtz218ytgD7h8dQGgGBBDnjhTnr6 JyJnvrj4OezLZF2BR4kDYfIKCSPk9VVfFiRe/b+HfcKH56Dv9ALcI8Dq0tk/G35G VY/4YQEselJ9P7KL/D4gqvl6pJLOwSU9162qUQzKEAktfzIREZqmyQQya1hgtwP3 TyY9rMJ8uubLh2Tqn0cUiZxQO7XjhTP1r/BSEyxrJkl3lAx/TCnIsBwNgd849JJK MVFHBFqzsvXdCG+CYU393HviueMdWnJ1nxZmhAIK9i/FpHRHw1fZtxUGlQYYiB28 sqoZ3ohbVUpuGCNjDRHI =+LZ8 -----END PGP SIGNATURE-----

Feb. 18, 2015