April 2016 - Wine-Devel - list.winehq.org

Re: [v9 4/6] d3dx9: Add basic opcodes to preshader.

by Matteo Bruni

2016-04-07 11:06 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > On 04/06/2016 04:43 PM, Matteo Bruni wrote: >> 2016-04-01 13:21 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: >> >>> + >>> >>> Also I get this on 32 bit: >>> >>> effect.c:3838: Test succeeded inside todo block: Operation rsq, >>> component 2, expected 0x3f2c985c, got 0x3f2c985c (0.6742). >>> effect.c:3838: Test succeeded inside todo block: Operation rsq, >>> component 3, expected 0x1f800001, got 0x1f800001 (5.42101e-20). >>> > That's interesting. I am getting 0x3f2c985d and 0x1f800000 (the > difference in the last bit of mantissa) on d3dx9_36 dll compiled with > various gcc optimization flags set, which effectively result in rsqrt > being computed using SSE opcode without glibc function call. Now when I > disabled all optimizations and any SSE arch targeting I get the same > result as you. The generated code has FP math been done through nasty > vintage x87 opcodes in this case, and sqrt glibc function is called in > pres_rsq(). > > Regarding the test, I could leave it as it, or remove todo, letting the > test to succed todo depending on compiler flags. Or compute a benchmark > rsqrt to guess which case we are having and use this for todo_wine_if. I > am not sure which way is preferred for the unit tests in such a case? The tests need to pass on Wine with default compiler settings. Comparing the obtained with the expected result allowing one (or more if necessary) ULP of tolerance is probably the nicest fix, at least WRT rsq. You could even specify the tolerance per-entry in the tests table if you want to stay bit-accurate when testing the other opcodes. I guess you could otherwise call sqrt() on some particular number and toggle todo_wine accordingly but that seems unnecessarily convoluted at the first glance. BTW, it might be interesting to try to add some sort of configure flag to enable SSE* without having to resort to manually set CFLAGS, maybe applying the additional compilation flags only on source files which "opt-in" somehow. Just thinking out loud, not sure how the others feel about it.

April 7, 2016

Re: [v9 3/6] d3dx9: Implement fxlc constants (expressions) in effect.

by Matteo Bruni

2016-04-07 10:37 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > On 04/06/2016 04:42 PM, Matteo Bruni wrote: >> >>> +static void regstore_set_double(struct d3dx_regstore *rs, unsigned int table, unsigned int offset, double v) >>> +{ >>> + BYTE *p; >>> + unsigned int reg_idx; >>> + >>> + p = (BYTE *)rs->tables[table] + table_info[table].component_size * offset; >>> + switch (table_info[table].type) >>> + { >>> + case PRES_VT_FLOAT : *(float *)p = v; break; >>> + case PRES_VT_DOUBLE: *(double *)p = v; break; >>> + case PRES_VT_INT : *(int *)p = roundf(v); break; >> Same here. Also it's not clear that rounding away from 0 is correct, >> this would need tests (although IIRC preshaders generated by the MS >> compiler explicitly compute integral values for integer constants, >> that would make this hard to test and mostly irrelevant in practice). >> So please try to test for rounding behavior with 0.5 / -0.5 / 1.5, if >> nothing else to confirm that my memory serves me right. BTW unless >> testing proves otherwise lrint() is probably the best option here >> since it generates much nicer code (at least when building with gcc >> for 32 bits). > In fact the main test now does not have integer constants. Preshader > code I've seen generated by MS compiler so far indeed does not use any > rounding functions, doing some math with fract, neg and min/max instead. > I already have some further patches involving tests of the newly added > operations which do not overwrite the blob but modify the opcode in > place. I used the same mini framework to test the other edge case which > is currently not in the main test: 0 * INF (BTW the results are funny, > preshaders exhibit IEEE FP behaviour, like in my implementation, while > d3d9 shaders have 0 * INF == 0). I suppose it will be easier to send and > less code changes to review if we consider the whole updated test blob > with all the planned changes at once afterwards, can we go this way? That sounds about what I expected and using lrint() here seems ideal. Yes, the additional tests can come after this set of patches.

April 7, 2016

wine-1.8.2-rc3 Available

by Michael Stefaniuc

Hello Alexandre, I have just pushed commit 74dbed07afbeda2e707424f1def138ec857da2b8 Author: Michael Stefaniuc <mstefani(a)winehq.org> Date: Thu Apr 7 14:25:40 2016 +0200 Release 1.8.2. as wine-1.8.2-rc3. It needs the configure change and your rubber stamp to call it 1.8.2. The only additions on top of 1.8.2-rc2 are your make_announce patch and the release commit. thanks bye michael

April 7, 2016

Re: Winegstreamer entry on Wine FAQ Wiki Page

by Rosanne DiMesio

On Thu, 7 Apr 2016 02:54:28 -0400 NP-Hardass <NP-Hardass(a)gentoo.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello, > > About a month ago, I created a Wine Wiki account and requested that it > be activated, explicitly so that I could add an entry to the FAQ page > [1]. After going to reference this new entry to someone today, I > noticed that my changes were reverted soon after my submission and the > page was subsequently locked [2]. This submission was made after > consulting wine developer, Sebastian Lackner. > > I think this information would be very useful to users starting to > adopt Winegstreamer, now that Andrew Eikum has updated it to gstreamer > 1.0 and it is functioning again. I'd like to inquire why the change > was reverted, if my content is deemed unnecessary, and if not, why it > was not moved elsewhere. > > - -- > NP-Hardass > Gentoo Wine maintainer > > [1] https://wiki.winehq.org/index.php?title=FAQ > [2] https://wiki.winehq.org/index.php?title=FAQ&action=history I reverted the item because: 1. It is not a frequently asked question. As written, it is not even a question. 2. The "answer" to this non-question served no purpose other than to advertise a third party project, giving the impression that it was officially recommended and supported here. The "information" in that item is not needed. If users are missing a gstreamer plugin needed by one of their apps, they will find it out as soon as they try to run the app. The console output will have a message from gstreamer complaining about the codec that was not found, and one from Wine suggesting a missing plugin. Users might need help figuring out exactly which package to install, but the "tool for developers to build and test DirectShow Graphs" project you were trying to drive traffic to won't help with that. The wiki is not a venue for free advertising. -- Rosanne DiMesio dimesio(a)earthlink.net

April 7, 2016

[GSoC] Re: Further work on the Visual C++ iostream library

by Iván Matellanes

On 06/04/16 09:40, Piotr Caban wrote: > Hi Iván, > > could you please provide us with timeline for your project? It doesn't have to be very specific. Hi, Based on my analysis of the unimplemented classes, the following could be a tentative timeline for the project: May 23 – Jun 5: Test ostream and figure out its methods. Jun 6 – Jun 12: Implement ostream methods. Jun 13 – Jun 26: Test istream and figure out its methods. Midterm evaluation. Jun 27 – Jul 3: Implement istream methods. Jul 4 – Jul 17: Implement ostream-derived classes (ofstream, ostream_withassign, ostrstream). Jul 18 – Jul 31: Implement istream-derived classes (ifstream, istream_withassign, istrstream). Aug 1 – Aug 21: Implement iostream and its derived classes (fstream, strstream, stdiostream). Final evaluation. If time permits I'd try to start sooner than May 23, but I can't guarantee it will be the case. Feel free to ask for any further clarification you may need. Best, Iván

April 7, 2016

Re: [PATCH] msvcp90: Add codecvt<wchar_t>::do_encoding that returns 0

by Piotr Caban

On 04/06/16 18:51, Daniel Lehman wrote: > seems to be only msvcp90 that returns 1 > > all others return 0 (which seems more correct anyway) Msvcp100 behaves the same as msvcp90. Please also update codecvt_short virtual functions table. Thanks, Piotr

April 7, 2016

Re: [v9 4/6] d3dx9: Add basic opcodes to preshader.

by Paul Gofman

On 04/06/2016 04:43 PM, Matteo Bruni wrote: > 2016-04-01 13:21 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > >> + >> >> Also I get this on 32 bit: >> >> effect.c:3838: Test succeeded inside todo block: Operation rsq, >> component 2, expected 0x3f2c985c, got 0x3f2c985c (0.6742). >> effect.c:3838: Test succeeded inside todo block: Operation rsq, >> component 3, expected 0x1f800001, got 0x1f800001 (5.42101e-20). >> That's interesting. I am getting 0x3f2c985d and 0x1f800000 (the difference in the last bit of mantissa) on d3dx9_36 dll compiled with various gcc optimization flags set, which effectively result in rsqrt being computed using SSE opcode without glibc function call. Now when I disabled all optimizations and any SSE arch targeting I get the same result as you. The generated code has FP math been done through nasty vintage x87 opcodes in this case, and sqrt glibc function is called in pres_rsq(). Regarding the test, I could leave it as it, or remove todo, letting the test to succed todo depending on compiler flags. Or compute a benchmark rsqrt to guess which case we are having and use this for todo_wine_if. I am not sure which way is preferred for the unit tests in such a case?

April 7, 2016

Re: [v9 3/6] d3dx9: Implement fxlc constants (expressions) in effect.

by Paul Gofman

On 04/06/2016 04:42 PM, Matteo Bruni wrote: > >> +static void regstore_set_double(struct d3dx_regstore *rs, unsigned int table, unsigned int offset, double v) >> +{ >> + BYTE *p; >> + unsigned int reg_idx; >> + >> + p = (BYTE *)rs->tables[table] + table_info[table].component_size * offset; >> + switch (table_info[table].type) >> + { >> + case PRES_VT_FLOAT : *(float *)p = v; break; >> + case PRES_VT_DOUBLE: *(double *)p = v; break; >> + case PRES_VT_INT : *(int *)p = roundf(v); break; > Same here. Also it's not clear that rounding away from 0 is correct, > this would need tests (although IIRC preshaders generated by the MS > compiler explicitly compute integral values for integer constants, > that would make this hard to test and mostly irrelevant in practice). > So please try to test for rounding behavior with 0.5 / -0.5 / 1.5, if > nothing else to confirm that my memory serves me right. BTW unless > testing proves otherwise lrint() is probably the best option here > since it generates much nicer code (at least when building with gcc > for 32 bits). In fact the main test now does not have integer constants. Preshader code I've seen generated by MS compiler so far indeed does not use any rounding functions, doing some math with fract, neg and min/max instead. I already have some further patches involving tests of the newly added operations which do not overwrite the blob but modify the opcode in place. I used the same mini framework to test the other edge case which is currently not in the main test: 0 * INF (BTW the results are funny, preshaders exhibit IEEE FP behaviour, like in my implementation, while d3d9 shaders have 0 * INF == 0). I suppose it will be easier to send and less code changes to review if we consider the whole updated test blob with all the planned changes at once afterwards, can we go this way?

April 7, 2016

Re: Sourceforge defaults to Wine 1.6.2 Re: Wine is "Community Choice" SourceForge Project of the Month

by Marcus Meissner

On Wed, Apr 06, 2016 at 10:30:53PM +0200, Jens Reyer wrote: > On 04/02/2016 12:42 PM, Marcus Meissner wrote: > > Hi, > > > > We are the "Community Choice" Project of the Month April 2016 at SourceForge. > > > > https://sourceforge.net/blog/april-2016-community-choice-project-of-the-mon… > > Just got the newsletter, clicked a link in it and was offered Wine > *1.6.2*. Someone needs to update the "default" download on Sourceforge. I changed it to 1.8.1 now. Thanks! Ciao, Marcus

April 7, 2016

Re: ntdll: Do not update iosb.Status after FSCTL_PIPE_LISTEN call. (v2)

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=21960 Your paranoid android. === build (build) === Patch failed to apply

April 7, 2016