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

WyldBOT 1 & 2 updated

by wylda＠volny.cz

Hi, 6 months passed so i updated images for these two machines (Description + Windows update + nvidia drivers in case of WyldBOT1). And this new nVidia v275.33 driver brings new failures in dlls/ddraw/tests/visual.c: visual.c:1503: Test failed: Got color 000000d8, expected 00000080 or near visual.c:1625: Test failed: Got color 00b000cf, expected 008000ff or near visual.c:1745: Test failed: Got color 00d80000, expected 00800000 or near The above is diff of the following links: Old nVidia driver v260.99: http://test.winehq.org/data/5758d748971d300f77b05ab245d870696c44132c/xp_Wyl… New nVidia driver v275.33: http://test.winehq.org/data/5758d748971d300f77b05ab245d870696c44132c/xp_Wyl… Regards, W.

July 3, 2011

Re: [6/6] wined3d: Don't apply and invalidate the framebuffer when clearing the device's fb

by Henri Verbeet

On 2 July 2011 11:59, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (isStateDirty(context, STATE_FRAMEBUFFER) || fb != &device->fb) This is probably never an issue in practice, but you're ignoring rt_count here.

July 3, 2011

Re: Traces with threading

by Erich Hoover

On Sun, Jul 3, 2011 at 10:58 AM, Alex Bradbury <asb(a)asbradbury.org> wrote: > On 3 July 2011 17:51, Erich Hoover <ehoover(a)mines.edu> wrote: > > Rather than rooting around for a while I figured I should ask first, is > > there a quick and easy way to get all TRACE/FIXME commands to output the > > thread id? I'm trying to track down an issue where one of a pair of > threads > > locks up and it'd be really nice to quickly identify which one is doing > > what. > > Unless I've totally misunderstood your question: > > http://wiki.winehq.org/DebugChannels > > WINEDEBUG=+tid > Thank you so much! I was aware of the list of "functionality" channels but did not notice the "special" channels, I'll be more careful to read down the page further next time. Erich Hoover ehoover(a)mines.edu

July 3, 2011

Re: Traces with threading

by Alex Bradbury

On 3 July 2011 17:51, Erich Hoover <ehoover(a)mines.edu> wrote: > Rather than rooting around for a while I figured I should ask first, is > there a quick and easy way to get all TRACE/FIXME commands to output the > thread id? I'm trying to track down an issue where one of a pair of threads > locks up and it'd be really nice to quickly identify which one is doing > what. Unless I've totally misunderstood your question: http://wiki.winehq.org/DebugChannels WINEDEBUG=+tid Alex

July 3, 2011

Traces with threading

by Erich Hoover

Rather than rooting around for a while I figured I should ask first, is there a quick and easy way to get all TRACE/FIXME commands to output the thread id? I'm trying to track down an issue where one of a pair of threads locks up and it'd be really nice to quickly identify which one is doing what. Erich Hoover ehoover(a)mines.edu

July 3, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Dylan Smith

The latest ConvertPointRepsToAdjacency patches look good.

July 3, 2011

Re: Updated Clang static analysis results / Valgrind update

by Vincas Miliūnas

On 07/03/2011 04:33 PM, Frédéric Delanoy wrote: > 2011/7/3 Vincas Miliūnas <vincas.miliunas(a)gmail.com>: >>> On Sun, Jul 3, 2011 at 04:15, Austin English <austinenglish at gmail.com <http://www.winehq.org/mailman/listinfo/wine-devel>> wrote: >>>> / Web space usage was getting a bit high, so I've uploaded a tarball to >>> />/ a file download service: >>> />/ http://www.sendspace.com/file/5hot36 >>> />/ >>> />/ austin at aw21 <http://www.winehq.org/mailman/listinfo/wine-devel> ~ $ sha1sum scan-build-2011-07-02.tar.bz2 >>> />/ ac3cb3920ef97641fff1f5376f8136cef01f15bf scan-build-2011-07-02.tar.bz2 >>> / >>> FWIW, you could use xz instead of bzip2 to further reduce the download >>> size (54 MiB) >>> I got the size down to 46 MiB using default settings, and 25 MiB using >>> max compression (xz -9) >>> >>> Frédéric >> I have heard about he xz compressor, so I was interested on how 7zip and xz perform maxed-out: >> >> 7z a -t7z -m0=lzma -mx=9 -mfb=255 -md=256m -ms=on scan-build-2011-07-02-1.7z scan-build-2011-07-02-1 >> 11.87MiB - 12445530 scan-build-2011-07-02-1.7z >> >> xz -zkc -Fxz -9e -M5GB --lzma2='dict=256Mi,nice=273,mf=bt4' scan-build-2011-07-02-1.tar > scan-build-2011-07-02-1.xz >> 12.14MiB - 12726004 scan-build-2011-07-02-1.xz >> >> I didn't measure time, but it wasn't very long; xz took longer, because it doesn't support multithreading. Both required 3.5GB of memory at the peek. > Well I didn't use all the xz options TBH... I only have 4 GiB of RAM, so... > With "xz -9" it used like 600 MiB memory. > > Don't know about 7z, but xz manpage says it requires 5-20% RAM for > decompression compared to compression, so it maybe a bit (too) high > with your options for certain people. > > I once did a (quick) comparison between rzip/lrzip (which I think is > in the same family as 7z) and xz, and had comparable results (give ot > take 1% or 2), but xz was WAY quicker (something like 7-8x). > xz was about a quick (or quicker) than bzip2 with better compression > ratios/less memory usage, so it seemed a good compromise > > You probably have a monster machine if it didn't take very long for > you though ;) > > Frédéric > No, I have an old E8400 w/ 8GiB of RAM. I reran the 7z compression with time measurement. Decompression of the previous 7z archive took ~3 seconds to a ram drive. Looking at the exact numbers, I guess I overestimated :), it did take a considerable amount of time and multithreading isn't very impressive: real 10m39.469s user 12m14.888s sys 0m3.839s But I agree, from what I have seen, xz is certainly superior to bzip2.

July 3, 2011

Re: kernel32/tests: remove a few CloseHandle calls on a HMODULE that don't make any sense

by Louis Lenders

Marvin <testbot <at> testbot.winehq.org> writes: > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=12163 > > Your paranoid android. > > === WNT4WSSP6 (32 bit module) === > module.c:356: Test failed: Expected ERROR_FILE_NOT_FOUND, got 1006 > Hi, is there anyone who can tell me why the test now fails in WinNT? Maybe I'm completely off and not understanding the tests for LoadLibraryEx, and the CloseHandle calls _are_ needed? If someone could explain me why they are there that would be great. regards louis

July 3, 2011

Re: Updated Clang static analysis results / Valgrind update

by Frédéric Delanoy

2011/7/3 Vincas Miliūnas <vincas.miliunas(a)gmail.com>: >> On Sun, Jul 3, 2011 at 04:15, Austin English <austinenglish at gmail.com <http://www.winehq.org/mailman/listinfo/wine-devel>> wrote: >> >/ Web space usage was getting a bit high, so I've uploaded a tarball to >> />/ a file download service: >> />/ http://www.sendspace.com/file/5hot36 >> />/ >> />/ austin at aw21 <http://www.winehq.org/mailman/listinfo/wine-devel> ~ $ sha1sum scan-build-2011-07-02.tar.bz2 >> />/ ac3cb3920ef97641fff1f5376f8136cef01f15bf scan-build-2011-07-02.tar.bz2 >> / >> FWIW, you could use xz instead of bzip2 to further reduce the download >> size (54 MiB) >> I got the size down to 46 MiB using default settings, and 25 MiB using >> max compression (xz -9) >> >> Frédéric > I have heard about he xz compressor, so I was interested on how 7zip and xz perform maxed-out: > > 7z a -t7z -m0=lzma -mx=9 -mfb=255 -md=256m -ms=on scan-build-2011-07-02-1.7z scan-build-2011-07-02-1 > 11.87MiB - 12445530 scan-build-2011-07-02-1.7z > > xz -zkc -Fxz -9e -M5GB --lzma2='dict=256Mi,nice=273,mf=bt4' scan-build-2011-07-02-1.tar > scan-build-2011-07-02-1.xz > 12.14MiB - 12726004 scan-build-2011-07-02-1.xz > > I didn't measure time, but it wasn't very long; xz took longer, because it doesn't support multithreading. Both required 3.5GB of memory at the peek. Well I didn't use all the xz options TBH... I only have 4 GiB of RAM, so... With "xz -9" it used like 600 MiB memory. Don't know about 7z, but xz manpage says it requires 5-20% RAM for decompression compared to compression, so it maybe a bit (too) high with your options for certain people. I once did a (quick) comparison between rzip/lrzip (which I think is in the same family as 7z) and xz, and had comparable results (give ot take 1% or 2), but xz was WAY quicker (something like 7-8x). xz was about a quick (or quicker) than bzip2 with better compression ratios/less memory usage, so it seemed a good compromise You probably have a monster machine if it didn't take very long for you though ;) Frédéric

July 3, 2011

Re: Updated Clang static analysis results / Valgrind update

by Vincas Miliūnas

> On Sun, Jul 3, 2011 at 04:15, Austin English <austinenglish at gmail.com <http://www.winehq.org/mailman/listinfo/wine-devel>> wrote: > >/ Web space usage was getting a bit high, so I've uploaded a tarball to > />/ a file download service: > />/ http://www.sendspace.com/file/5hot36 > />/ > />/ austin at aw21 <http://www.winehq.org/mailman/listinfo/wine-devel> ~ $ sha1sum scan-build-2011-07-02.tar.bz2 > />/ ac3cb3920ef97641fff1f5376f8136cef01f15bf scan-build-2011-07-02.tar.bz2 > / > FWIW, you could use xz instead of bzip2 to further reduce the download > size (54 MiB) > I got the size down to 46 MiB using default settings, and 25 MiB using > max compression (xz -9) > > Frédéric I have heard about he xz compressor, so I was interested on how 7zip and xz perform maxed-out: 7z a -t7z -m0=lzma -mx=9 -mfb=255 -md=256m -ms=on scan-build-2011-07-02-1.7z scan-build-2011-07-02-1 11.87MiB - 12445530 scan-build-2011-07-02-1.7z xz -zkc -Fxz -9e -M5GB --lzma2='dict=256Mi,nice=273,mf=bt4' scan-build-2011-07-02-1.tar > scan-build-2011-07-02-1.xz 12.14MiB - 12726004 scan-build-2011-07-02-1.xz I didn't measure time, but it wasn't very long; xz took longer, because it doesn't support multithreading. Both required 3.5GB of memory at the peek.

July 3, 2011