December 2009 - Wine-Devel - list.winehq.org

Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.

by Henri Verbeet

2009/12/29 Matteo Bruni <matteo.mystral(a)gmail.com>: > I added the fake parser for two reasons: because I have to initialize > an asm_parser structure anyway in the create_xxxx_parser functions > (and I prefer to use parser_fake for the unimplemented shader versions > instead of parser_vs_3) and I want to avoid having some tests for the > other shader versions pass "by chance" inside the todo_wine (this is > accomplished by the asmparser_end_fake function... probably this can > be seen as a hack). > Agreed on the structure fields. > Can't you just let the parser fail when it encounters an unsupported shader version? That's more or less what happens anyway, but I don't think you have to wait until after parsing all the instructions for that.

Dec. 29, 2009

Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.

by Matteo Bruni

2009/12/29 Alexandre Julliard <julliard(a)winehq.org>: > Matteo Bruni <matteo.mystral(a)gmail.com> writes: > >> + >> +%option reentrant bison-bridge > > These won't work on old flex versions, and will get you in trouble with > the flex police (aka Michael Stefaniuc ;-) > Alexandre, now you have another person on your side against RHEL 5 and old flex versions :) Joking aside, that's not a big issue as wpp is not reentrant anyway and I'm using the mutex to allow a single call at a time to D3DXAssembleShader. Just a question: as now I have to keep the parser context in a global structure defined in asmshader.y, how should I give access to it from asmshader.l? Do you prefer to give visibility to the global struct from asmshader.l or to create a getter (like a struct asm_parser *asm_get_context(void) function)?

Dec. 29, 2009

Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.

by Matteo Bruni

2009/12/29 Henri Verbeet <hverbeet(a)gmail.com>: > 2009/12/28 Matteo Bruni <matteo.mystral(a)gmail.com>: >> > Why do you need the fake parser? Can't you just not support those > shader versions yet? There's also (in general) not much of a point in > adding structure fields that aren't used yet. > I added the fake parser for two reasons: because I have to initialize an asm_parser structure anyway in the create_xxxx_parser functions (and I prefer to use parser_fake for the unimplemented shader versions instead of parser_vs_3) and I want to avoid having some tests for the other shader versions pass "by chance" inside the todo_wine (this is accomplished by the asmparser_end_fake function... probably this can be seen as a hack). Agreed on the structure fields. >> +/* This file needs the original d3d9 definitions. The bwriter ones >> + * aren't useable because they are wine-internal things. We're writing >> + * d3d8/9 shaders here, so we need the d3d9 definitions (which are >> + * equal to the d3d8 ones) >> + */ > This doesn't seem to match what the code actually does. That #include is only used from the next patch. I'll move the include and the comment in the right place (maybe rephrasing it somewhat). > >> +/* Debug utility routines. Some are not reentrant, check asmutils.c */ > Same as above. Yep, that's not true anymore, courtesy of wine_dbg_sprintf. > As for splitting things up, I think it's ok to e.g. add the > pre-processor first, and just return E_NOTIMPL from assemble_shader(). > You mean a patch which adds only the first half of the D3DXAssembleShader implementation (returning just after the preprocessing)? That seems reasonable. Btw, ok for your other points also.

Dec. 29, 2009

Re: Guide for creating new AppInstall tests

by Sam S.

Hi Austin, thank you for your reply. I'll give it another try. Btw, I do realise that some questions of the step-by-step list I gave at the end are already (at least partially) answered in various places - this was intended more as an outline of how a step-by-step guide useful to users with no prior experience could be added to the wiki page. Your answeres already made the process much clearer to me... One thing though: >> - on Windows: how to properly test-run/debug the new script > > By running it a few times and making sure nothing fails ;-). So you need to run ..\tools\autohotkey\autohotkey.exe testname.ahk and then check C:\appinstall\testname-result.txt correct? >> - on Windows: how to get all those checksums > > There's not an easy way on windows, without installing cygwin. This is > explained in the wiki. It explains it for Linux, I was hoping there would be a way to get the checksums of the files generated on Windows, without copying them to Linux first... Well, too bad... > If someone would volunteer to help with the documentation > (by proofing it, making sure I didn't leave steps out, etc.), it would > help greatly. If I manage to get it working now, maybe I can help with the documantation (by providing a user's perspective)... In any case, having a step-by-step howto of the actual process (as outlined in my first email) would already be a great improvement compared to having to collect the various bits of information from all over... One more thing: There should probably be a link to the AppInstall wiki page at http://www.winehq.org/contributing and maybe other places... (right now, it seems to be linked to only from the archived WWN article, which makes it not so easy to discover for users...)

Dec. 29, 2009

Re: Building and packaging Wine Gecko

by Jacek Caban

On 12/29/09 2:07 PM, André Hentschel wrote: > Jacek Caban schrieb: > >> On 12/28/09 8:34 AM, Ove Kaaven wrote: >> >>> OK, I've almost got a wine-gecko package built 100% from source, but >>> there's a problem: the gcc version in Debian's mingw32, namely gcc >>> 4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the >>> resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5 >>> something, compiles it correctly, but I can't reasonably build-depend on >>> it, as that version is not even in the current stable.) >>> >>> (Note that this 4.2.1-sjlj might not suffer from that gcc bug 9381 >>> mentioned on the wiki, as the testcases for it doesn't seem to crash. Or >>> aren't they supposed to crash?) >>> >>> >> It does suffer from this bug, these tests are probably not enough to >> show it. >> >> >>> I also seem to recall the gcc 4.4-based mingw32 compiler, available in >>> unstable, also refusing to compile those sources at all, due to numerous >>> problems with the headers, such as inconsistently declared calling >>> conventions for methods and stuff. >>> >>> I'm not sure what to do about this. Any ideas about something I can do >>> to make it build with gcc 4.2 or 4.4? >>> >>> >> The only compiler you can use for Wine Gecko 1.0.0 is GCC 3.4.5. Current >> Git version uses GCC 4.4 SVN version (waiting for the first official GCC >> release). All older compilers are not enough unless you'd patch them >> (but that doesn't sound reasonable). >> >> >> Jacek >> >> >> > Hi Jacek, > gcc 3.4.5 or 3.4.6(as mentioned in the wiki)? > It was a typo, it's 3.4.6 (although 3.4.5 would also work). Thanks, Jacek

Dec. 29, 2009

Re: Building and packaging Wine Gecko

by Jacek Caban

On 12/29/09 5:45 AM, Austin English wrote: > On Mon, Dec 28, 2009 at 6:53 PM, Jacek Caban<jacek(a)codeweavers.com> wrote: > >> On 12/29/09 1:44 AM, Ove Kaaven wrote: >> >>> gcc 4.4.2 is already released, and >>> Debian unstable is using it as the default compiler. And like I >>> mentioned, they even have a mingw32 cross compiler of it. Would it then >>> be a good idea to build wine-gecko git instead of wine-gecko 1.0.0? >>> Should that work? >>> >>> >> That won't work, but I think it's better to spend time on working on the >> next release. >> > When is the next 'release' of wine-gecko planned? E.g., when will > wine-gecko git become wine-gecko 1.1? > It's not yet planned. Jacek

Dec. 29, 2009

Re: dlls/user32/combo.c: Fix an issue where pressing 's' in a combobox shows the dropdown isntead of finding an entry starting with 's'.

by David Quintana (gigaherz)

I had already sent a second patch without the C++-style comment. But regardless, if you say other parts of the code are also wrong, then I will leave this to someone closer to the project, who knows better what is it that should be done here. 2009/12/29 Dmitry Timoshkov <dmitry(a)codeweavers.com> > "David Quintana (gigaherz)" <gigaherz(a)gmail.com> wrote: > > Issue was caused by VK_F4 having the same exact code as a lowercase 's'. >> So the code, which treated WM_CHAR and WM_KEYDOWN as the same, executed >> the wrong piece of code which was meant to be ONLY for WM_KEYDOWN. >> > > Thanks for spotting this bug. Anyway the fix is not correct. Virtual key > codes should be tested only in the WM_KEYDOWN handler, WM_CHAR handler > should test for character codes. Also, as Nikolay asked please don't use > C++ comments in Wine code. > > -- > Dmitry. >

Dec. 29, 2009

Re: Building and packaging Wine Gecko

by André Hentschel

Jacek Caban schrieb: > On 12/28/09 8:34 AM, Ove Kaaven wrote: >> OK, I've almost got a wine-gecko package built 100% from source, but >> there's a problem: the gcc version in Debian's mingw32, namely gcc >> 4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the >> resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5 >> something, compiles it correctly, but I can't reasonably build-depend on >> it, as that version is not even in the current stable.) >> >> (Note that this 4.2.1-sjlj might not suffer from that gcc bug 9381 >> mentioned on the wiki, as the testcases for it doesn't seem to crash. Or >> aren't they supposed to crash?) >> > > It does suffer from this bug, these tests are probably not enough to > show it. > >> I also seem to recall the gcc 4.4-based mingw32 compiler, available in >> unstable, also refusing to compile those sources at all, due to numerous >> problems with the headers, such as inconsistently declared calling >> conventions for methods and stuff. >> >> I'm not sure what to do about this. Any ideas about something I can do >> to make it build with gcc 4.2 or 4.4? >> > > The only compiler you can use for Wine Gecko 1.0.0 is GCC 3.4.5. Current > Git version uses GCC 4.4 SVN version (waiting for the first official GCC > release). All older compilers are not enough unless you'd patch them > (but that doesn't sound reasonable). > > > Jacek > > Hi Jacek, gcc 3.4.5 or 3.4.6(as mentioned in the wiki)? -- Best Regards, André Hentschel

Dec. 29, 2009

Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.

by Alexandre Julliard

Matteo Bruni <matteo.mystral(a)gmail.com> writes: > + > +%option reentrant bison-bridge These won't work on old flex versions, and will get you in trouble with the flex police (aka Michael Stefaniuc ;-) -- Alexandre Julliard julliard(a)winehq.org

Dec. 29, 2009

Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.

by Henri Verbeet

2009/12/28 Matteo Bruni <matteo.mystral(a)gmail.com>: > Why do you need the fake parser? Can't you just not support those shader versions yet? There's also (in general) not much of a point in adding structure fields that aren't used yet. > +/* This file needs the original d3d9 definitions. The bwriter ones > + * aren't useable because they are wine-internal things. We're writing > + * d3d8/9 shaders here, so we need the d3d9 definitions (which are > + * equal to the d3d8 ones) > + */ This doesn't seem to match what the code actually does. > +/* Debug utility routines. Some are not reentrant, check asmutils.c */ Same as above. > +const char *debug_print_dstreg(const struct shader_reg *reg, shader_type st) { > + return wine_dbg_sprintf("%s", get_regname(reg, st)); > +} > + > +const char *debug_print_srcreg(const struct shader_reg *reg, shader_type st) { > + switch(reg->srcmod) { > + case BWRITERSPSM_NONE: > + return wine_dbg_sprintf("%s", get_regname(reg, st)); > + } > + return "Unknown modifier"; > +} "return get_regname(reg, st);" should work at least as well. > +/* Mutex used to guarantee a single invocation > + of the D3DXAssembleShader function (or its variants) at a time. > + This is needed as wpp isn't thread-safe */ > +extern CRITICAL_SECTION wpp_mutex; It's probably easier to just statically initialize the critical section in shader.c. As for splitting things up, I think it's ok to e.g. add the pre-processor first, and just return E_NOTIMPL from assemble_shader().

Dec. 29, 2009