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

Re: comctl32/tests: Remove practically unused parameters from test functions

by Vitaliy Margolen

On 04/27/2011 09:47 AM, Nikolay Sivov wrote: > On 4/27/2011 17:53, Vitaliy Margolen wrote: >> On 04/27/2011 01:14 AM, Nikolay Sivov wrote: >>> Remove practically unused parameters from test functions >>> >> >> So how is global variable any better then local variable passed as >> function parameter? > Because there's no need to have different parent windows for currently > present tests. I don't see a reason of > having window handle created exactly once and then passed in each test > function, it's tests after all with a straightforward structure. The reason - all global variables are bad, do not use them. Regardless why and how they are created and/or used. Vitaliy.

April 28, 2011

Re: infosoft/tests: COM cleanup in infosoft.c.

by Michael Stefaniuc

Alexandre, please ignore this patch as my script seems to have missed two places to change. bye michael On 04/28/2011 12:52 AM, Marvin wrote: > 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 > http://testbot.winehq.org/JobDetails.pl?Key=10605 > > Your paranoid android. > > > === WVISTAADM (32 bit infosoft) === > infosoft.c:185: Test failed: failed > infosoft.c:199: Test failed: failed > > === W2K8SE (32 bit infosoft) === > infosoft.c:185: Test failed: failed > infosoft.c:199: Test failed: failed > > === W7PRO (32 bit infosoft) === > infosoft.c:185: Test failed: failed > infosoft.c:199: Test failed: failed > > === W7PROX64 (32 bit infosoft) === > infosoft.c:185: Test failed: failed > infosoft.c:199: Test failed: failed > > === W7PROX64 (64 bit infosoft) === > infosoft.c:185: Test failed: failed > infosoft.c:199: Test failed: failed

April 27, 2011

Re: infosoft/tests: COM cleanup in infosoft.c.

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 http://testbot.winehq.org/JobDetails.pl?Key=10605 Your paranoid android. === WVISTAADM (32 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed === W2K8SE (32 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed === W7PRO (32 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed === W7PROX64 (32 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed === W7PROX64 (64 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed

April 27, 2011

Re: Question on Conformance Test

by Stefan Dösinger

On Wednesday 27 April 2011 18:05:59 Austin English wrote: > Normal practice is to try to match the XP+ behavior, and mark NT as > broken if it differs. In d3d we prefer results that some applications depend on. E.g. Windows XP has pretty relaxed or no error checking on IDirect3DVertexBuffer9::Lock, even though msdn says otherwise. Windows Vista added error checking as documented in the msdn. There are a few games out there that depend on the lack of error checking and crash on Windows Vista(or crashed at the time). We decided to replicate the behavior that kept the games working in Wine and mark the stricter check as broken() If we don't know of any app that depends on the behavior we replicate the one that is nicer from an API design point of view and mark the others with broken() If a result is clearly wrong(violates the docs, and doesn't make any sense) I mark it as broken if we don't know any "mainstream" app that depends on it(e.g. if the test was written to understand how something works). Alternatively we may just get rid of the test. If there's a mainstream app(ie, something you can buy in a shop, but not some random techdemo, tutorial or demoscene stuff) that depends on the behavior and this app doesn't work on this driver/Windows version I let the test fail. Sorry, your driver's broken, do not pass go, do not collect $200, do not pass the tests. This mostly applies to old hardware like my Radeon Mobility 9000, non-gaming hardware(Intel GPUs to a certain extend, rare stuff like Matrox cards) or outdated drivers.

April 27, 2011

Re: wined3d: Track when the FBO is dirty. (try 4)

by Adam Martinson

On Tuesday 26 April 18:16:27 Henri Verbeet wrote: > This is mostly the same as the previous version. Yes, it's just rebased. I'm happy to change it however you see fit, but I need to know what you'd like changed and how.

April 27, 2011

Re: winealsa.drv: Add mmdevapi driver.

by Reece Dunn

On 27 April 2011 15:48, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Andrew Eikum wrote: > >>>Does CoTaskMemFree match HeapAlloc? >>would anyone more familiar with CoTaskMem* want to comment? CoTaskMemFree should be used on memory allocated with CoTaskMalloc (just like malloc/free, HeapAlloc/HeapFree, etc.). It is typically used for non-string COM data. - Reece

April 27, 2011

D3D performance debugging report

by Stefan Dösinger

Hi, I spent a few hours debugging wined3d performance today. No, I found no magic fix for the slowness, just some semi-usable data. First I wrote a hacky patch to avoid redundant FBO applications. This gave a tiny, tiny performance increase, see http://www.winehq.org/pipermail/wine- devel/2011-April/089832.html. The main investigation concerned redundant shader applications. The aim was to find out how many of our glBindProgramARB calls are re-binding the same program, and how much this costs. Depending on the game between 20% to 90% of all BindProgram calls are redundant. I'll attach my debug hack so others can test their own apps. I used ARB shaders for testing because they can apply vertex and fragment programs separately. This brings up two questions: (a) How much does this cost (b) Why does this happen The costs: In my draw overhead tester hacking out the redundant apply calls improved performance a lot, from about 101 fps to 157 fps. The biggest part of that are the GL calls. Without them but the remaining shader logic I get 144 fps. Unfortunately this does not translate to any performance gains in real apps. I tried to filter out the redundant apply calls in the simplest way possible: Track the current value per wined3d_context and check before calling glBindProgramARB. This gave the 144 fps in the draw overhead tester, but no measurable increase in any other apps(I tested StarCraft 2, HL2, Team Fortress 2, World in Conflict and a few others) Given the amount of redundant apply calls and the cost of them in the draw overlay tester I have expected at least some improvement. Certainly not a 50% performance increase(the draw overlay tester performs no shader changes at all in the draw loop), but at least a 2-3% gain. So far I have no explanation why I didn't see that. But why do those redundant apply calls happen? It seems like the state dirtification comes all the way from the stream sources and/or vertex declaration. STREAMSRC is linked to VDECL, which is linked to VERTEXSHADER, which in turn reapplies the pixel shader. This means redundant vertex and pixel shader applications. Separating those states will be a major challenge. The vdecl<->vshader link shouldn't be needed any more, except in rare cases where GL_ARB_vertex_array_bgra is not supported and the application switches one attribute from D3DDECL_D3DCOLOR to a non-d3dcolor attribute. If the vertex shader changes we still have to reparse the vertex declaraion and reapply the stream sources because the vshader determines the stream numbers. Maybe we can reduce the number of times this happens by ordering stream usages and indices to make sure shaders with compatible input get the same stream ordering. vdecl and streamsrc are pretty related. If the vdecl is changed we have to reapply the stream sources. The other way around shouldn't cause problems though. There's no need to reapply every stream except the changed ones and there's no need to reapply the vertex shader. The vertex and pixel shader are linked for a few reasons: The shader backend API offers only a function to set both. Basic GLSL only offers a function to set both at once(GL_ARB_separate_shader_objects changes that). And even in ARB the pixel shader input may require some changes in the vertex shader output to get Shader Model 3.0 varyings right. The shader backend API can be changed, but it has to be done in a way that doesn't hurt GLSL without ARB_separate_shader_objects. If we have classic GLSL we have to keep the link. With ARB we can conditionally reapply the vertex shader if the ps_input_signature is changed. To complicate matters there are additional states that affect the shaders, like fog, textures, clipping. We don't keep track of those dependencies. So it's a lot of work to clean up these state dependencies and we don't know how much it'll gain us :-( Stefan

April 27, 2011

Re: wined3d: Track when the FBO is dirty. (try 4)

by Stefan Dösinger

On Wednesday 27 April 2011 18:26:08 Adam Martinson wrote: > Will do, but this is for http://source.winehq.org/patches/data/73534 not > http://source.winehq.org/patches/data/73533. Yep, I accidentally replied to the wrong mail(and wrote another mail to mention that)

April 27, 2011

Re: wined3d: Track when the FBO is dirty. (try 4)

by Adam Martinson

On Wednesday 27 Apr 2011 01:19:51 Stefan Dösinger wrote: > > > On Tuesday 26 April 2011 19:35:06 Adam Martinson wrote: > > - FIXME("Unrecognized D3DZBUFFERTYPE value %#x.\n", > > + WARN("treating unrecognized D3DZBUFFERTYPE value %#x as > WINED3DZB_TRUE.\n", > > stateblock->state.render_states[WINED3DRS_ZENABLE]); > > + /* falltrough */ > > + case WINED3DZB_TRUE: > Please provide a test for this. Will do, but this is for http://source.winehq.org/patches/data/73534 not http://source.winehq.org/patches/data/73533.

April 27, 2011

Re: Question on Conformance Test

by Austin English

On Tue, Apr 26, 2011 at 22:50, James McKenzie <jjmckenzie51(a)gmail.com> wrote: > All: > > I am writing a conformance test for the richedit function EM_FINDWORDBREAK. > I realize that WindowsNT 4.0 is our base configuration and most of the > values process the same. However, a couple of values process differently > for Windows NT 4.0/Windows2000, WindowsXP/Windows2003 and Windows Vista > onward. What would be the BEST method of annotating this: > > Per the development guide: > > ok ( GetLastError() == WINXP_ERROR || GetLastError() == WINNT40_ERROR, ...); > > or: > > ok ( GetLastError() == WINXP_ERROR || Broken (GetLastError() == > WINNT40_ERROR)); > > In other words, should I avoid the use of Broken() in this case, as the > returned value is correct? Normal practice is to try to match the XP+ behavior, and mark NT as broken if it differs. -- -Austin

April 27, 2011