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

Re: Profiling CS:GO

by Stefan Dösinger

Am 05.02.2014 um 17:22 schrieb Brock York <twunknown(a)gmail.com>: > >Quick reply from my phone: wglShareLists on Windows had to be called with neither context being current. I once hacked a workaround >together that created 20 extra contexts in advance with the primary one before making the first context current in one thread > Is this why WineD3D can't be used multithreaded under wine in CS:GO? I don't know much about how OpenGL and DirectX let alone their windows counterparts but I'm trying. It should work in current Wine (on Linux), but you may have to enable StrictDrawOrdering. Without that you may get some texture corruption, e.g. HUD parts are broken in CS:S if the game’s multithreading is enabled but StrictDrawOrdering isn’t. StrictDrawOrdering kills performance though. CSMT supersedes StrictDrawOrdering. > >One more thing: there are a few issues with the nvidia driver on the command stream. For testing, try to remove vertex buffer objects and >pixel buffer objects from the extension table in directx.c, disable glsl and enable the game's multithreading. That got me pretty decent >performance in cs:s. > This is for running and testing WineD3D under windows for testing that I should remove the VBO's and PBO's? Or is this for getting better performance when under wine in linux? This is for getting better performance on Wine in Linux.

Feb. 6, 2014

Re: Wine at LinuxTag in Berlin

by Stefan Dösinger

Am 05.02.2014 um 21:26 schrieb Michael Stefaniuc <mstefani(a)redhat.com>: > <_Marcus_> and a Playing Windows games with Wine could be seperate if > necessary /& wanted... would surely also be interesting I think I could come up with something here, but not by tomorrow evening. I might need some advice in tailoring the message to the LinuxTag audience, whatever it may be.

Feb. 6, 2014

Re: kernel32/tests: Add test for FindFirstFileA()

by Dmitry Timoshkov

Zhenbo Li <litimetal(a)gmail.com> wrote: > >> + strcpy(buffer2, nonexistent); > >> + handle = CreateFileA(buffer2, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0 ); > > > > There is no need for a strcpy(). > Well, I'll add more tests later(like trailing \\). strcpy() could be added later when new tests get added. > >> + ok(handle != INVALID_HANDLE_VALUE, "failed to create a file\n"); > >> + handle = FindFirstFileA(buffer2, &data); > >> + ok(handle != FindFirstFileA, "failed to find an existent file\n"); > > > > It would be useful to actually test what FindFirstFileA() returns. > > Also not leaking the handle *twice* would be a bonus point. > Thank you for mentioning that. > Most of the previous testcases leak the handle. > After this patch, is it necessary to fix them? Every handle leak is bad on its own, and may lead to unwanted side effects like inability to destroy an object or delete a file. Another thing that could be improved in this test is printing last error code in the failure message. Also you may find that making failure messages shorter and simpler makes your life a bit easier. For axample: "CreateFile(%s) error %d\n", name, GetLastError() and "FindFirstFile(%s) error %d\n", name, GetLastError() -- Dmitry.

Feb. 6, 2014

Re: kernel32/tests: Add test for FindFirstFileA()

by Zhenbo Li

Thank you. 2014-02-06 15:56 GMT+08:00 Dmitry Timoshkov <dmitry(a)baikal.ru>: > Zhenbo Li <litimetal(a)gmail.com> wrote: > >> + strcpy(buffer2, nonexistent); >> + handle = CreateFileA(buffer2, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0 ); > > There is no need for a strcpy(). Well, I'll add more tests later(like trailing \\). > >> + ok(handle != INVALID_HANDLE_VALUE, "failed to create a file\n"); >> + handle = FindFirstFileA(buffer2, &data); >> + ok(handle != FindFirstFileA, "failed to find an existent file\n"); > > It would be useful to actually test what FindFirstFileA() returns. > Also not leaking the handle *twice* would be a bonus point. Thank you for mentioning that. Most of the previous testcases leak the handle. After this patch, is it necessary to fix them? -- Have a nice day! Zhenbo Li

Feb. 6, 2014

Re: Wine at LinuxTag in Berlin

by Henri Verbeet

On 6 February 2014 10:29, Francois Gouget <fgouget(a)free.fr> wrote: > That would be true if Wine was universally viewed as important. However > there is a sentiment among free software radicals that because Wine > makes it possible to run Windows applications (which are viewed as 100% > non open-source), it's bad for Linux, open-source software, etc. So this > title just confirms that sentiment and is thus not necessarily > provocative (except on a Wine mailing list). > That was perhaps true at some point, but I have the impression that these days the sentiment is more that "Valve and Icculus are going to fix Linux gaming, nobody uses Wine for anything else anyway, and Free Software is just this thing that makes it harder for them to do so."

Feb. 6, 2014

Re: Fixing conflicts between WineD3D and WGL

by Henri Verbeet

On 5 February 2014 20:20, Ken Thomases <ken(a)codeweavers.com> wrote: >> Right. I was under the impression it would be used by >> wined3d_caps_gl_ctx_create() to avoid changing the current WGL DC. If >> it's only for restoring the application's GL context, I'm not sure how >> that's effectively much different from just making the application's >> GL context current on wined3d's DC? (I'd have to look into the details >> again, but IIRC that wasn't enough for bug 28869, even as a hack.) > > Well, it would be different because it wouldn't change the app's GL context to point at a potentially-different drawable. Which, by the way, is actually happening in bug 28869. The app does GL against a top-level window but uses ddraw/wined3d on a child window of that window. So, your hack wouldn't work because it would make the app's GL context current on a window that's destroyed soon after. > Actually, what confused me there was thinking of the current DC as thread state as opposed to context state. So yeah, wglMakeContextCurrentWINE() should work. It does have me wondering slightly if wglMakeCurrent() shouldn't behave like that anyway if the DC it gets passes is the same as the one the context was last current with, but perhaps not enough to go find out. > In experimenting with implementing the extension and making wined3d use it, I discovered a complication. At the same point where wined3d attempts to restore the app's GL context, it also tries to restore the pixel format on the app's DC. On the one hand, my extension doesn't help with that which undermines its rationale since the DC is still required. On the other hand, that's the wrong thing for wined3d to try to do there! Wined3d has set the pixel format on its target window (through a DC it obtained itself). In many cases, the app will be targeting the same window with its GL context, but not always (as we've seen). So, wined3d should be trying to restore the pixel format of the window it modified, not the window the app's GL context may be targeting. > It may not be enough in some cases, and redundant in others, but I don't think it's wrong as such. I.e., if the wined3d GL DC and the application's GL DC aren't the same, restoring the pixel format on the application's GL DC is redundant because we didn't touch it, but it should never restore the wrong pixel format. There are two cases where it wouldn't be enough: - The application has set a pixel format on the wined3d DC before, is not currently using GL on that DC, but will do so (again) in the future. I think this case can be fixed, although it's not entirely trivial because of e.g. context_update_window(), and IMO a bit of a rare case. - The application has never set a pixel format on the wined3d DC, but will try to do so in the future. I don't think we can fix this with the current WGL_WINE_pixel_format_passthrough implementation. As soon as wined3d sets a pixel format, it becomes impossible for the application to do so in the future. This is essentially bug 29934. In theory this entire issue should go away with wglGetSurfaceDCWINE() though, because in that case we'd never have to restore the pixel format at all, provided there's no way the application can get at the same DC wined3d is using.

Feb. 6, 2014

Re: Wine at LinuxTag in Berlin

by Francois Gouget

On Wed, 5 Feb 2014, Rosanne DiMesio wrote: > On Wed, 5 Feb 2014 18:11:18 -0600 > Ken Thomases <ken(a)codeweavers.com> wrote: > > > On Feb 5, 2014, at 2:26 PM, Michael Stefaniuc wrote: > > > > > - I will submit a talk proposal: "Is Wine Still Relevant?" … > > > > To me, this invites the reader to think "no" (even with a subtitle). > > How about something like "Uses of Wine Today and in the Future"? > > IMO, "Is Wine Still Relevant?" sounds like a much more interesting, provocative talk. That would be true if Wine was universally viewed as important. However there is a sentiment among free software radicals that because Wine makes it possible to run Windows applications (which are viewed as 100% non open-source), it's bad for Linux, open-source software, etc. So this title just confirms that sentiment and is thus not necessarily provocative (except on a Wine mailing list). So I think the opposite tack would be more provocative: What makes Wine THE most important open-source project or Wine: Still the most important open-source project or for a different talk: Status and future of the most important open-source project: Wine -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

Feb. 6, 2014

Re: kernel32/tests: Add test for FindFirstFileA()

by Dmitry Timoshkov

Zhenbo Li <litimetal(a)gmail.com> wrote: > + strcpy(buffer2, nonexistent); > + handle = CreateFileA(buffer2, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0 ); There is no need for a strcpy(). > + ok(handle != INVALID_HANDLE_VALUE, "failed to create a file\n"); > + handle = FindFirstFileA(buffer2, &data); > + ok(handle != FindFirstFileA, "failed to find an existent file\n"); It would be useful to actually test what FindFirstFileA() returns. Also not leaking the handle *twice* would be a bonus point. -- Dmitry.

Feb. 6, 2014

Re: Wine at LinuxTag in Berlin

by Rosanne DiMesio

On Wed, 5 Feb 2014 20:38:18 -0600 Ken Thomases <ken(a)codeweavers.com> wrote: > On Feb 5, 2014, at 7:52 PM, Rosanne DiMesio wrote: > > > On Wed, 5 Feb 2014 18:11:18 -0600 > > Ken Thomases <ken(a)codeweavers.com> wrote: > > > >> On Feb 5, 2014, at 2:26 PM, Michael Stefaniuc wrote: > >> > >>> - I will submit a talk proposal: "Is Wine Still Relevant?" … > >> > >> To me, this invites the reader to think "no" (even with a subtitle). How about something like "Uses of Wine Today and in the Future"? > >> > > > > IMO, "Is Wine Still Relevant?" sounds like a much more interesting, provocative talk. > > Well, you're right that my alternative suggestion is dull as dirt. Terrible. Don't use that. > > But I stand by my first sentence. > Oh, I agree with your first sentence, too. But that's what makes the title so intriguing: it tells me the speaker knows I might say "no" and is going to challenge my thinking. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 5, 2014

Re: Wine at LinuxTag in Berlin

by Erich E. Hoover

On Wed, Feb 5, 2014 at 7:38 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Feb 5, 2014, at 7:52 PM, Rosanne DiMesio wrote: > >> On Wed, 5 Feb 2014 18:11:18 -0600 >> Ken Thomases <ken(a)codeweavers.com> wrote: >> >>> On Feb 5, 2014, at 2:26 PM, Michael Stefaniuc wrote: >>> >>>> - I will submit a talk proposal: "Is Wine Still Relevant?" ... >>> >>> To me, this invites the reader to think "no" (even with a subtitle). How about something like "Uses of Wine Today and in the Future"? >>> >> >> IMO, "Is Wine Still Relevant?" sounds like a much more interesting, provocative talk. > > Well, you're right that my alternative suggestion is dull as dirt. Terrible. Don't use that. > > But I stand by my first sentence. > > -Ken "How Wine Remains Relevant" ? Best, Erich

Feb. 5, 2014