Re: Request for help/advice in investigation of one interesting "huge FPS regression" bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 16.04.2012 04:28, Vitaliy Margolen wrote: > Of course it won't - they are binary blobs from Nvidia. Not much to see > there. All you really looking for are time spent in that library. > Vitaliy, I don't expect oprofile to find hidden COFF or DWARF 2 debug infos inside nVIDIA binary blob, it's obvious that there are nothing like that there :-). What I was expecting to find in oprofile output is a libGL.so subdivision like may be seen in "objdump -T /usr/lib/libGL.so.295.40" output. Thinking a bit more about it makes it clear that my expectations were wrong as the export table doesn't have all the required info for oprofile to act as a poors man substitute for real symbols map file (for example, it can't be determined for sure from exports table what are the actual proc boundaries for any given exported symbol). What might be useful for profiling in this case is a "proxy" wrapper for libGL that sits between Wine and real libGL and collects call timing stats. A wrapper of such kind wouldn't be as devastating to FPS as apitrace, and it would provide a fine-grained picture on per-proc timing stats which are extremely helpful when one is trying to catch a GPU driver bug. I have no idea if there's such a wrapper already implemented out in a wild. - -- Best regards, Alexey Loukianov mailto:mooro...@mail.ru System Engineer,Mob.:+7(926)218-1320 *nix Specialist -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPi20tAAoJEPB9BOdTkBULPo4IAKFYIbPvg0Znv6AOiZt+C2yV +uiq1+FZcdeMedfGZrA8lelOvUEp9h8/wuDEmZ2YEW28+S/qkMA0EL0MaJY7hqZz ac3vdt/wVxxDpwAm1Jjl0YjmzhZP4dE8fyB42Clh5+McIG7MvsO7sHfGmQk9Jbye d+KvoOWbOFaB5fNrXr+lQMGqkNTSMas3TQS3KIVeiCFitDzXwDHoK7dGykeiJ340 q0MxqRRa7XvGSZNtw9Q043ZeywaNMFD/k6tSUkIXwP/FlZsTBPHhr7M37h+gjt84 2w26KE7cncoUKl1l3w7WfUMN9/MgEKmtX5O0nsP0S8EBCdehfVhOlUcUI48Kkgk= =Kkgh -END PGP SIGNATURE-
Re: Request for help/advice in investigation of one interesting "huge FPS regression" bug
On 04/15/2012 04:44 PM, Alexey Loukianov wrote: With oprofile I hit another trouble - it seems that this tool is unable to fetch symbols from libGL Of course it won't - they are binary blobs from Nvidia. Not much to see there. All you really looking for are time spent in that library. Vitaliy.
Re: Request for help/advice in investigation of one interesting "huge FPS regression" bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 15.04.2012 21:50, Stefan Dösinger wrote: > your best bet would be using something like oprofile to find out which GL > calls show performance changes. Well, I had compiled/installed APITrace 3.0 and oprofile 0.9.7 on my system, but it seems that it'd be by the very least "problematic" to get any useful info from these. APITrace 3.0 works fine with Wine, but the performance hit is huge and resulting trace size seems to be non-manageable. Trace file containing two frames displayed at the game login screen is ~2GB in size, and non-surprisingly game performance is more like "one frame per twenty seconds". With oprofile I hit another trouble - it seems that this tool is unable to fetch symbols from libGL, at least all I get in reports related to libGL are simple references to /usr/lib/libGL.so.295.40, /usr/lib/libnvidia-glcore.so.295.40 and /usr/lib/tls/libnvidia-tls.so.295.40 without any details available on symbols that are internal to this libs. It might be me misusing oprofile although, as currently it is the first time ever I'm trying to use it to do profiling tasks. - -- Best regards, Alexey Loukianov mailto:mooro...@mail.ru System Engineer,Mob.:+7(926)218-1320 *nix Specialist -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPi09CAAoJEPB9BOdTkBULLOQIAKEYcBV7xB3ii6BC8TNT7dzT YLnwGBtERPRpm+n3xfRzNmm2JCmDVMNQtZAZ8xxyMe2rksQW2Pu2v4R86QfdLZ2k NSGJm83lykH3VExz79dBkgHnBCNk129UIC7nfSLkDAWfZUvxuvQb1+flWtR/N224 98k2NNyxoZ09aiI3hwvJL7ckRtk1tOZaoObTteVxgfZBIZ7o5LXiILhwlgkbuJbZ hy9xIEQdCTXovpnQnqq3O4aPCI6ikIlUe0ySWtEo+5HtEKnA7u0/5OFEFKOEol/1 WnIzH0GVf4SnLOBy59NjIsX8ho3/q4/sz3TOHoiOs/ng/tjzAZMQmF/4Bk8k4+4= =Kyxl -END PGP SIGNATURE-
Re: ddraw/tests: Compare the correct surface pointers.
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=17873 Your paranoid android. === W2KPROSP4 (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs from the one returned by Lock(00A70028) === WXPPROSP3 (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs from the one returned by Lock(00BA0028) === W2K3R2SESP2 (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs from the one returned by Lock(00E40028) === WVISTAADM (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs from the one returned by Lock(02210028) === W2K8SE (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs from the one returned by Lock(02800028) === W7PRO (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs from the one returned by Lock(01BF0028) === W7PROX64 (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs from the one returned by Lock(02740028) === TEST64_W7SP1 (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs from the one returned by Lock(02690028) === W7PROX64 (64 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs from the one returned by Lock(02390040) === TEST64_W7SP1 (64 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs from the one returned by Lock(02360040)
Re: Request for help/advice in investigation of one interesting "huge FPS regression" bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 15.04.2012 21:50, Stefan Dösinger wrote: > It could also be because of some additional features added in newer > drivers. 16 byte alignment for vertex buffers is a possibility, I believe > it was added in the 280 drivers. You can check this by disabling > GL_ARB_map_buffer_range. This one isn't the case, as the problem affects ancient versions of Wine that don't use this extension, like 1.2.3 (under which the app in question actually performs much better comparing to fresher releases). Actually I've got a small patchset here against 1.5.2 which is required to bring the FPS levels for this game to a way it was with 1.2.3, and one of the patches from this patchset effectively disables GL_ARB_map_buffer_range usage. So, yeah, GL_ARB_map_buffer_range is causing trouble for this game, but it is not the one to blame for the issue I'm trying to resolve. Meanwhile I've been able to reproduce this bug on another PC I've got here at home. It was originally spotted on a box having 8GB DDR3 RAM, GeForce GTX 550 Ti with 1GB and AMD FX 8120 CPU running Fedora 14-based LFS-like system with 32bit PAE-enabled kernel. The system I've been able to reproduce the bug on is a box equipped with AMD Phenom II x4 955 CPU, 8GB DDR2 RAM, GeForce 8600 GT with 256MB VRAM running Linux Mint 9 with 32bit PAE-enabled kernel 3.0.0-16. Unfortunately I haven't got access to any system with ATI/AMD card a.t.m., but chances are I would be able to lay my hands on one with AMD A8 CPU with integraded Radeon card. It would be interesting to check if this bug affects ATI/AMD. Thanks for oprofile hint, but unfortunately I haven't got any experience with it. I also been thinking about trying to use APITrace, but I don't have any experience with it either and I don't know if it's compatible with non-OSS GPU drivers. - -- Best regards, Alexey Loukianov mailto:mooro...@mail.ru System Engineer,Mob.:+7(926)218-1320 *nix Specialist -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPizBJAAoJEPB9BOdTkBULm1IIAIP+YMp5XPuPeB/4E/fgcgoA S+HEb5Hdy48ezB/rpl862pT1zaQut1mKNptTBubt7fyIx1SoQ9e193lwJu0M7Ld0 Ia8HXl9XKn1pBAlS/f5xdNuoA3esB6chTTU1lVG2wnD9AOvpsbM/mVN1ymjyfdWp 1CSFeemJ014HoijG9OUC+FcbT+LqWgLpB1H4bAcHR6u/KSPQDizImmIAnve85mVg 264Bosj94g1pf9K32r2JZoiLQ41ufeo/7th+XKQOkG6nY7n849UmkZAUkRgVN7G8 MN74fZ/z0eaaNxJ9S+tuXERrJeOjxavFozCHOloxoEmt3GFEuxG6kga+sCF25v8= =kkSW -END PGP SIGNATURE-
Re: ddraw/tests: Compare the correct surface pointers.
On 04/15/2012 10:04 PM, Marvin wrote: > While running your changed tests on Windows, I think I found new failures. Yupp, test is incorrect. Stefan is looking at it. bye michael > 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=17873 > > Your paranoid android. > > > === W2KPROSP4 (32 bit dsurface) === > dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs > from the one returned by Lock(00A70028) > > === WXPPROSP3 (32 bit dsurface) === > dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs > from the one returned by Lock(00BA0028) > > === W2K3R2SESP2 (32 bit dsurface) === > dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs > from the one returned by Lock(00E40028) > > === WVISTAADM (32 bit dsurface) === > dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs > from the one returned by Lock(02210028) > > === W2K8SE (32 bit dsurface) === > dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs > from the one returned by Lock(02800028) > > === W7PRO (32 bit dsurface) === > dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs > from the one returned by Lock(01BF0028) > > === W7PROX64 (32 bit dsurface) === > dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs > from the one returned by Lock(02740028) > > === TEST64_W7SP1 (32 bit dsurface) === > dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() differs > from the one returned by Lock(02690028) > > === W7PROX64 (64 bit dsurface) === > dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() > differs from the one returned by Lock(02390040) > > === TEST64_W7SP1 (64 bit dsurface) === > dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc() > differs from the one returned by Lock(02360040)
Re: [PATCH 1/3] browseui: Add IOleWindow to IProgressDialog
Hello Detlef,
On 04/15/2012 10:08 PM, Detlef Riekenberg wrote:
> Used by apps to adjust the dialog position
> or remove the cancel button before vista
>
> --
> By by ... Detlef
> ---
> dlls/browseui/progressdlg.c | 69
> ++-
> 1 files changed, 68 insertions(+), 1 deletions(-)
>
> diff --git a/dlls/browseui/progressdlg.c b/dlls/browseui/progressdlg.c
> index 9b970e2..2807622 100644
> --- a/dlls/browseui/progressdlg.c
> +++ b/dlls/browseui/progressdlg.c
> @@ -270,9 +276,20 @@ static HRESULT WINAPI
> ProgressDialog_QueryInterface(IProgressDialog *iface, REFI
> ProgressDialog *This = impl_from_IProgressDialog(iface);
> *ppvOut = NULL;
>
> -if (IsEqualIID(iid, &IID_IUnknown) || IsEqualIID(iid,
> &IID_IProgressDialog))
> +if (IsEqualIID(iid, &IID_IUnknown))
> {
> *ppvOut = This;
> +TRACE("(%p, IID_IUnknown, %p) -> %p\n", This, ppvOut, This);
> +}
> +else if (IsEqualIID(iid, &IID_IProgressDialog))
> +{
> +*ppvOut = This;
this is not correct as ppvOut takes an interface and not an object.
While at it please fix the above one too.
thanks
bye
michael
Re: [PATCH 1/3] browseui: Add IOleWindow to IProgressDialog
On 4/15/2012 23:08, Detlef Riekenberg wrote:
Used by apps to adjust the dialog position
or remove the cancel button before vista
--
By by ... Detlef
---
dlls/browseui/progressdlg.c | 69 ++-
1 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/dlls/browseui/progressdlg.c b/dlls/browseui/progressdlg.c
index 9b970e2..2807622 100644
--- a/dlls/browseui/progressdlg.c
+++ b/dlls/browseui/progressdlg.c
@@ -60,6 +60,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(browseui);
typedef struct tagProgressDialog {
IProgressDialog IProgressDialog_iface;
+IOleWindow IOleWindow_iface;
LONG refCount;
CRITICAL_SECTION cs;
HWND hwnd;
@@ -79,6 +80,11 @@ static inline ProgressDialog
*impl_from_IProgressDialog(IProgressDialog *iface)
return CONTAINING_RECORD(iface, ProgressDialog, IProgressDialog_iface);
}
+static inline ProgressDialog *impl_from_IOleWindow(IOleWindow *iface)
+{
+return CONTAINING_RECORD(iface, ProgressDialog, IOleWindow_iface);
+}
+
static void set_buffer(LPWSTR *buffer, LPCWSTR string)
{
static const WCHAR empty_string[] = {0};
@@ -270,9 +276,20 @@ static HRESULT WINAPI
ProgressDialog_QueryInterface(IProgressDialog *iface, REFI
ProgressDialog *This = impl_from_IProgressDialog(iface);
*ppvOut = NULL;
-if (IsEqualIID(iid,&IID_IUnknown) || IsEqualIID(iid,&IID_IProgressDialog))
+if (IsEqualIID(iid,&IID_IUnknown))
{
*ppvOut = This;
+TRACE("(%p, IID_IUnknown, %p) -> %p\n", This, ppvOut, This);
+}
+else if (IsEqualIID(iid,&IID_IProgressDialog))
+{
+*ppvOut = This;
+TRACE("(%p, IID_IProgressDialog, %p) -> %p\n", This, ppvOut, This);
+}
+else if (IsEqualIID(iid,&IID_IOleWindow))
+{
+*ppvOut =&This->IOleWindow_iface;
+TRACE("(%p, IID_IOleWindow, %p) -> %p\n", This, ppvOut, *ppvOut);
}
What's a point in different traces? A single one is enough, with printed
riid of course.
Also please return iface instead of This, like *ppvOut = iface;, or if
you prefer instance pointer add a pointer to
interface like - &This->...
if (*ppvOut)
@@ -495,6 +512,55 @@ static const IProgressDialogVtbl ProgressDialogVtbl =
ProgressDialog_Timer
};
+static HRESULT WINAPI OleWindow_QueryInterface(IOleWindow *iface, REFIID iid,
LPVOID *ppvOut)
+{
+ProgressDialog *This = impl_from_IOleWindow(iface);
+
+TRACE("(%p, %s, %p)\n", iface, debugstr_guid(iid), ppvOut);
+return ProgressDialog_QueryInterface(&This->IProgressDialog_iface, iid,
ppvOut);
+}
+
This trace should go to ProgressDialog_QueryInterface(), no need to
place it in every interface.
Re: Request for help/advice in investigation of one interesting "huge FPS regression" bug
Am Sonntag, 15. April 2012, 07:22:34 schrieb Alexey Loukianov: > When I configure an app to run in a windowed mode I've got around 40 FPS on > game login screen with nVIDIA drivers 275.09.07, but switching into using > more recent versions causes FPS to drop to around ~10. It could be a driver bug as you suspect, which is difficult to track down - your best bet would be using something like oprofile to find out which GL calls show performance changes. It could also be because of some additional features added in newer drivers. 16 byte alignment for vertex buffers is a possibility, I believe it was added in the 280 drivers. You can check this by disabling GL_ARB_map_buffer_range. If this improves performance, you're probably running into a dynamic buffer related issue. It wouldn't explain the windowed vs fullscreen difference, but it's still worth checking.
Re: [GSoC] Reduce dependency on native dlls
On 14 April 2012 05:03, William Panlener wrote: > I have two concerns with this proposal: > 1) Is it unusual to work towards improving a specific application rather > than focusing on a specific component of wine? In general Wine development it's pretty common. For GSoC it's a bit more uncommon, but I don't think that necessarily makes it bad. > 2) The scope of the project is difficult to gauge in advance since the next > problematic stub cannot be identified until all the previous problematic > stubs are taken care of. Is this an issue for a GSoC proposal? Somewhat. We generally like GSoC projects to be fairly well defined tasks, so that it's clear up front how much work it's approximately going to be and when it's finished. You could probably make the proposal a bit more concrete by taking a look at the application's import table and checking which of those imports are unimplemented. However, while I'm not that closely involved with GSoC, I was under the impression that the deadline for submitting proposals has already passed.
Re: [1/2] comctl32/tests: Added tests for mouse events handling (try 3)
On Sun, Apr 15, 2012 at 07:38, Daniel Jelinski wrote: > Hello, > ... > Bug 19222 makes using MS SQL Server management studio a pain. The > application displays database structure in a tree view, and most > actions are executed from a context menu displayed by right-clicking > on a relevant position in the tree view. Unfortunately Wine suffers > from a bug - right click displays the menu, but selecting any option > from the menu causes another menu to be displayed at the current mouse > position. Selecting an option from this second menu works as expected. This problem is also seem in FlashFXP so your patch may fix it there as well. http://bugs.winehq.org/show_bug.cgi?id=19350#c4 > Thanks for your patience, > Daniel Bruno
Re: automate winedbg IDE integration
Le 14/04/2012 22:41, Ilya Basin a écrit : I've already written a wrapper (see my other mail winedbg-eclipse - winedbg wrapper for Eclipse IDE) There are some problems, however. EP> do you have a trace of the gdb commands ? gdb --version gdb --interpreter mi2 --nx 1-list-features 2-environment-cd /media/ARCHLINUXOLD/1/builds/wine/src/wine/programs/regedit 3-gdb-set breakpoint pending on 4-gdb-set detach-on-fork on 5-enable-pretty-printing 6source .gdbinit 7-gdb-set target-async off 8-gdb-set auto-solib-add on 9-file-exec-and-symbols --thread-group i1 /media/ARCHLINUXOLD/1/builds/wine/src/wine/programs/regedit/regedit.exe.so 10-gdb-set --thread-group i1 args testexport 11-list-thread-groups --available 12-break-insert --thread-group i1 -f /media/ARCHLINUXOLD/1/builds/wine/src/wine/programs/regedit/regproc.c:1092 13-break-insert --thread-group i1 -f /media/ARCHLINUXOLD/1/builds/wine/src/wine/programs/regedit/regproc.c: 14-break-insert --thread-group i1 -t -f main 15-inferior-tty-set --thread-group i1 /dev/pts/0 16-exec-run --thread-group i1 IMO you're debugging a 64 bit target, and remote protocol seems to suffer some bugs in this case I'll send a fix later on... A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Testbot certificate has expired
Hi testbot.winehq.com certificate expired on 13-04-2012. So now the wininet tests in dlls/wininet/tests/http.c are failing with an error for me. I can't determine if the fault are in the test or the function called should handle the error case. The error message is: err:wininet:NETCON_secure_connect SSL_connect failed: 12037 http.c:2873: Test failed: HttpSendRequest failed: 12037 wine: Unhandled page fault on read access to 0x0008 at address 0x68a876c5 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x0008 in 32-bit code (0x68a876c5). Best Regards Morten Rønne
Re: [1/2] comctl32/tests: Added tests for mouse events handling (try 3)
Hello, I see that my patch hasn't been accepted yet. Well if some explanation could help it through, here goes: Bug 19222 makes using MS SQL Server management studio a pain. The application displays database structure in a tree view, and most actions are executed from a context menu displayed by right-clicking on a relevant position in the tree view. Unfortunately Wine suffers from a bug - right click displays the menu, but selecting any option from the menu causes another menu to be displayed at the current mouse position. Selecting an option from this second menu works as expected. Also opening the popup menu by pressing context menu key on the keyboard works properly. The usual suspect in such cases is that incorrect messages are sent, or messages are sent in incorrect order. I tried to run the application with native comctl, but unfortunately it refused to work - probably comctl version 6.0 is required, while winetricks installs version 5.80. So I created my own application in Delphi. It dispayed the same problem with builtin comctl and worked correctly with native. Then I tested it with WINEDEBUG=+message. The outstanding differences were: - on native comctl treeview sent two messages to the main window - first WM_NOTIFY (NM_RCLICK) and then WM_CONTEXTMENU - on builtin comctl treeview sent first WM_CONTEXTMENU to self, which then got propagated to main window, and then WM_NOTIFY(NM_RCLICK). There was something peculiar - WM_RBUTTONUP never appeared in the logs. I checked to see why and found a function TREEVIEW_TrackMouse. This function is called by WM_RBUTTONDOWN handler and it captures all events from the message queue until it finds either WM_RBUTTONUP or WM_MOUSEMOVE with coordinates sufficiently far from the origin of the click. There was also a comment stating that "This is quite unusual piece of code, but that's how it's implemented in Windows.". Given the absence of WM_RBUTTONUP in message logs I consider this assertion to be true. With this knowledge I proceeded to write tests. I wanted to emulate right button down/up sequence. I couldn't send both messages by SendMessage, because SendMessage sends messages directly to the window procedure, and WM_RBUTTONUP has to be delivered by message queue. I also didn't want to push both messages to the queue - this would net me several more irrelevant messages like WM_PAINT and could cause failures if someone moved the (physical) mouse during the test. This is why I chose to post WM_RBUTTONUP and then send WM_RBUTTONDOWN. Later, thanks to our friendly bot Marvin, I found out that older versions of comctl sent WM_PAINT messages during the button down/button up sequence, bypassing the message queue. It took me several tries to find out which messages are sent, but now the patch works correctly on all tested comctl versions. Then I corrected Wine to pass the tests. I tested both applications (Microsoft's and mine) to see if they work correctly when the correct messages are sent. They do. If there is anything else I can do to help this patch get accepted, let me know. I'd like to have a clean git origin before I start fixing other treeview problems. Thanks for your patience, Daniel
