July 2008 - Wine-devel - list.winehq.org

Re: CUDA wrapper
by Mind Matter 25 Jul '08

25 Jul '08

Sorry if I posted this wrong, I'm new to mailing lists. *You could use oprofile to find out where the CPU time is spent - this *behavior can be caused by a lot of issues. *Does the Cuda client work now? If so, it would be cool if we could include *the wrapper in Wine, or get it into a shape to make it easilly *redistributable and installable next to Wine. I have been testing this out with Seth. Yes the wrapper is up and running. I have been able to run the folding(a)home GPU client for about a week now with comparable performance to the same hardware running under Windows. The main problem as stated before is that both cores (dual core system) are running at 100% and the system is not usable until the client is killed. In Windows this client only uses about 20% or less of a single core to feed the GPU leaving the second core free. I ran oprofile (first time, never heard of it before) while the client was running. 213932 54.7876 wine-preloader CPU_CLK_UNHALT...| samples| %| ------------------ 1970113 88.9871 libcuda.so.177.13 160796 7.2629 FahCore_11.exe 30056 1.3576 libc-2.7.so 10169 0.4593 libpthread-2.7.so 9143 0.4130 libcudart.so.2.0 8473 0.3827 libfreetype.so.6.3.16 5065 0.2288 kernel32.dll.so 4726 0.2135 ntdll.dll.so 3578 0.1616 [vdso] (tgid:19882 range:0xffffe000-0xfffff000) 3458 0.1562 cudart.dll.so I have attached the full output. I assume this says that libcuda is using 88% of the CPU and FahCore_11.exe is using 7%. When I watch the processes in the KDE system monitor it shows FahCore_11.exe using ~50% (one full core) and Xorg using ~50% (second core). I don't see from oprofile how and why xorg is using a whole core.

2 1

re: EverQuest2.exe and context.c
by Dan Kegel 25 Jul '08

25 Jul '08

Chris Ahrendt wrote: > Again on the goto's I was following what the site > suggested was a good task to start with Where does it say that? I looked, but I couldn't find it. Please let me know so I can go make sure it's accurate. Wine code is a bit like kernel code, it has slightly different conventions than most people are used to. Chris, you should focus on one thing at a time, and code cleanup probably shouldn't be something you focus on until you are more in tune with Wine. - Dan p.s. Also, everybody, please trim your quotes...

2 1

question
by Adi mmx 25 Jul '08

25 Jul '08

Hallo, i have a question to wine developers, how do i get parallel port access tru dlportio.sys, and dlportio.dll , becose im getting an error while loading driver. Thanks.

3 2

Re: kernel32 [1/4]: Add tests for GetPrivateProfileString [RESEND]
by Paul Vriens 25 Jul '08

25 Jul '08

James Hawkins wrote: > Hi, > > Anything wrong with these patches? > > Changelog: > * Add tests for GetPrivateProfileString. > > dlls/kernel32/tests/profile.c | 272 +++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 272 insertions(+), 0 deletions(-) > There are lots of test crashes because of this patch (tested on W2K, XP-SP3, W2K3 and Vista). It looks like all tests with 'lpAppName is empty' and 'lpKeyName is empty' fail (haven't checked others). Marking them with an if(0) does seem overkill. Any idea? -- Cheers, Paul.

1 0

Re: crypt32/tests: check Vista error codes for the msg tests. [resend]
by Alexandre Julliard 25 Jul '08

25 Jul '08

"Reece Dunn" <msclrhd(a)googlemail.com> writes: > @@ -383,9 +383,10 @@ static void test_data_msg_update(void) > /* Can't update a message with no data */ > SetLastError(0xdeadbeef); > ret = CryptMsgUpdate(msg, NULL, 0, TRUE); > - /* NT: E_INVALIDARG, 9x: unchanged */ > - ok(!ret && (GetLastError() == E_INVALIDARG || GetLastError() == 0xdeadbeef), > - "Expected E_INVALIDARG or 0xdeadbeef, got 0x%x\n", GetLastError()); > + /* last error -- NT: E_INVALIDARG, 9x/Vista: unchanged */ > + /* ret is FALSE on XP and earlier but TRUE on Vista, therefore it cannot be tested for */ > + ok((GetLastError() == E_INVALIDARG || GetLastError() == 0xdeadbeef), > + "Expected E_INVALIDARG or 0xdeadbeef, 0x%x\n", GetLastError()); It doesn't make sense to test last error if the function succeeds. Also if it sometimes succeeds and sometimes fails the whole test is useless. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: EverQuest2.exe and context.c
by Vitaliy Margolen 25 Jul '08

25 Jul '08

Chris Ahrendt wrote: > Vitaliy Margolen wrote: >> Chris Ahrendt wrote: >>> Vitaliy Margolen wrote: >>>> Chris Ahrendt wrote: >>>>> Ok I ran make test and got the failure without running >>>>> Everquest2.exe let me attach the output of maketest. I guess thats >>>>> a start eh? >>>>> >>>> You getting off-topic too far here. Make test have nothing to do >>>> with your game. Especially that you attached complete output of >>>> everything. >>>> >>>> However this lines tell the whole story: >>>>> libGL error: drmMap of framebuffer failed (Cannot allocate memory) >>>>> libGL error: reverting to (slow) indirect rendering >>>> >>>> You have broken driver. And I'm afraid your configuration can not be >>>> supported. You could try and read the faq about how to try and fix >>>> it. But that still won't fix broken driver. >>>> >>>> Vitaliy >>>> >>>> PS: >>>> Please do not attach big files to mailing list. If you are asked for >>>> them - send to that person directly or attach to the bug report. >>>> >>>> PPS: >>>> Please take this discussion to the bug report. It's not a general >>>> case but a game specific. It belongs there not in the developer's >>>> mailing list. Since you are not a developer yourself and just add an >>>> extra noise to the mailing list. >>> Actually Vialiy it is a discussion that belongs here... not in bug fix.. >>> I have had that gl error and its not what we are working on... the >>> problem we are working on was first found in EverQuest2.exe but I was >>> able to reproduce it without everquest. so its not a game related issue. >>> Second point.. I was told to bring this sort of discussion over here to >>> discuss as the patch list is not for general discussion. >>> >> >> I'm talking about bugzilla. What's the bug number you are referring too? >> >> >> Vitaliy. > There are a couple 14072 is one of them... > Did you noticed that your patch has nothing to do with what you talking about here? The bug related to this topic is 14000. And please don't mix and match multiple things. Reading this thread you talking about: 1. Changing gotos with something 2. Not liking the code 3. PixelFormat. 4. make test failures (not even related to d3d at all) 5. dxdiag crash This is all on top of broken configuration (did you disable fast tls?) and known bad drivers and particular bad video card. Please stay on topic of pixelformat related problem or you won't get anywhere trying to fix everything at the same time. For the main topic - you will need to wait for Roderic to chime in on the reasons behind his code. This area is really fragile and should not be changed to fix a particular program. Vitaliy.

3 4

Re: d3dx9: Implement D3DXPlaneTransformArray.
by Vitaliy Margolen 24 Jul '08

24 Jul '08

Philip Nilsson wrote: > Thanks to joaopa for pointing out that I forgot this function. > > +D3DXPLANE* WINAPI D3DXPlaneTransformArray( > + D3DXPLANE* out, UINT outstride, CONST D3DXPLANE* in, UINT instride, > + CONST D3DXMATRIX* matrix, UINT elements) > +{ > + unsigned int i; > + TRACE("\n"); > + for (i = 0; i < elements; ++i) { Please don't mix and match win types and C types. If it says "UINT" in the function declaration then make the iterator "UINT i" as well. Vitaliy.

1 0

Re: [PATCH] cryptnet/tests: Make the tests usable on win9x
by Juan Lang 24 Jul '08

24 Jul '08

Hi Detlef, overall your patch looks good to me. One minor suggestion: + /* only newer versions of cryptnet do the cleanup */ + if(!ret && GetLastError() != CRYPT_E_ASN1_BADTAG && + GetLastError() != OSS_DATA_ERROR) { + ok(crl == NULL, "Expected CRL to be NULL\n"); + } Rather than only checking crl when a newer version of cryptnet is available, why not use the broken() macro? We really do expect crl to get cleaned up. --Juan

1 0

GL_INVALID_ENUM errors with FBO
by Vitaliy Margolen 24 Jul '08

24 Jul '08

I've been trying to track some of the errors that I get with different games. To do that I've added some extra traces and this is what I see: fixme:d3d_surface:read_from_framebuffer_texture glReadBuffer(0x405) was 0x8ce0 >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) @ ../../../wine.git/dlls/wined3d/surface.c / 918 0x405 is GL_BACK and 0x8ce0 is GL_COLOR_ATTACHMENT0_EXT. Also when this happens I have an inverted image of the entire screen in the left bottom corner. Is this an indication that we are reading from the wrong surface? Or writing into the wrong surface? Attached is the patch that produces the above output. BTW if it looks fine to you guys (that extra TRACE()/FIXME() call overhead) then I can send it to wine-patches as well. Vitaliy.

3 5

Re: [PATCH] wined3d: Fix the OpenGL driver version for Mac OS X NVIDIA driver.
by Michael Karcher 24 Jul '08

24 Jul '08

Am Donnerstag, den 24.07.2008, 00:55 +0800 schrieb Huang, Zhangrong: > Hi, > I tried run World of Warcraft on Mac OS X with X11 and NVIDIA card, > got the following error messages: > > err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string: > "1.5 NVIDIA-1.5.24" > err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string: > "1.5 NVIDIA-1.5.24" > > This patch fixed this problem. > + gl_string_cursor = gl_string; > + major = atoi(gl_string_cursor); > + while (*gl_string_cursor <= '9' && *gl_string_cursor >= '0') { > + ++gl_string_cursor; > + } What is the advantage of that compared to major = strtol(gl_string, &gl_string_cursor,10); ? Or even replace the whole scanning code by if(sscanf(gl_string, "%d.%d", &major, &minor) != 2) ERR_(d3d_caps)(...) Regards, Michael Karcher

2 1