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

Re: State of AMD 3d drivers?

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.03.2011 um 08:55 schrieb Dan Kegel: > How good are AMD's 3d drivers these days? > A few years ago, the word was, if you wanted to run the > wine test suite, you'd better have an nvidia graphics chip. > Is that still true? As far as the testsuite is concerned it is still true. An alternative is r600g, which almost runs the d3d tests successfully according to Henri. Wrt real games fglrx is in a pretty good shape. Performance isn't as good as the Nvidia drivers, and there are a few bugs here and there. However, if a game doesn't work I usually blame Wine first and then the driver. Bleeding edge games are probably still tricky. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNlDSJAAoJEN0/YqbEcdMwr0wP/RXt9MJUr3uePQubmPCP1jn1 VWlfwGevlPV2W7xkAxfp4Jtgd55hFnlyewuaCz58Lu2b6bDQlIzBh8wqWy6k4TRp 2/ixjF0G8Z6SH79gP8b4M4qf7WqeKmPpjpFoRdLbqmPyDA65JvDsvpKdJNLTmSYd l2i0r2MK4KobGZASRN4C2znuoJ8Z6YxXQwLQV6E13zb6dVUOgz6GYHNMfqccA+zU nc7lvgNigVTqdsXXzvYjJBHsMHiCphe5FPsONTH/dGMHQzGB9R8guKxzMj2SJlOv 4gUBYEYvRgCA8SVTfSc7w/G06hMag2mK1XVjjTgUnqhBsuB6yKX+r7kN+ZA0/r4V 3crxDa5NEAE4hJhItsJRuWSXxQs15+b6SqrLg3PotpiW28MJseFbYspGRlxVGGZw xFzVp5A80qBk7dtbi70BxrmzMJY6tRG6sW0EvFcf8R3HAmlyfMg3jX33zM30EMcE YGBZYaNOdGXcTYvFnD6Gkx1u/mISrsG3Xy/dYKO9RlaYNK5O91jtWrU7NmJGnQAH N2OoahTVKv/0qLGs7aJ9wcfX2g5Z7Ijub14Uj5G1yw5VjVCflWiNP2y2nwx2vp5q /I2E9Oc482bdg/yB1oAb2KDUpLLQIJJvJRURzDfOEWpns/Grz/PEPcAuaBma6D2U fAmnPkUaAEHhgWdG0ZEV =l/9v -----END PGP SIGNATURE-----

March 31, 2011

State of AMD 3d drivers?

by Dan Kegel

How good are AMD's 3d drivers these days? A few years ago, the word was, if you wanted to run the wine test suite, you'd better have an nvidia graphics chip. Is that still true?

March 31, 2011

Re: [1/2] winefile: Remove unimplemented menu entries.

by James McKenzie

On Wed, Mar 30, 2011 at 7:46 AM, Francois Gouget <fgouget(a)free.fr> wrote: > They unnecessarily clutter the GUI and are unlikely to ever be implemented. > --- > > As discussed on wine-devel. > I still left Rename and Create Directory because they are basic > functions that should really be there (but I won't implement them). Thank you Francois. These should only be brought back with a full implementation of the underlying code, if it is really needed. James McKenzie

March 30, 2011

Re: semi-obsolete audio drivers

by Andrew Eikum

On 03/30/2011 09:23 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Andrew, > > [good news, esp. the time-line] Let's hope I can stick to it :-P. It's looking good, though. >>OSSv4 (complete) > Do you specifically use OSS *v4* functions not available earlier? > (I'm not familiar with OSS4, even though I consult their docu online > and hope that what they write also applies to my machine with OSS v3 (Ubuntu)). I wrote it following the OSSv4 spec and using an OSSv4 implementation, so I suspect it won't work on OSSv3. I thought about supporting OSSv3, but I think it's not worth the effort -- that's a really old version that, when written, didn't support multiple clients simultaneously, had no mixer, etc. OSSv4 has a lot of features that make the driver much simpler. Further, I think only Linux is still stuck on OSSv3. I looked at a number of other operating systems, mostly BSDs and Solaris, and they all use OSSv4 by default. So I think Linux users should be covered by ALSA or PulseAudio (or perhaps JACK), and the much-more-pleasant OSSv4 is available for BSDs and Solaris. If a Linux user really wants OSS, I think they should probably upgrade to OSSv4 anyway. I could look at making it OSSv3 compatible, but I just think it's not worth the effort of supporting such an old and cantankerous API. Andrew

March 30, 2011

Re: semi-obsolete audio drivers

by Andrew Eikum

Hi Joerg, On 03/30/2011 06:11 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > What do you think? > - Why did people submit patches to one driver only when a short glance > shows that the same bug is in the other cloned drivers too? Well, those people might not know that there are multiple drivers, or might not care about drivers they don't use. Not everyone is as thorough as we'd like them to be :) > - Is WineJack "current" and worth some effort? > - Let the others continue to decay? > - Remove them from git? As for these questions, I can answer them all at once. I am currently re-implementing MMDevAPI to use a similar driver architecture to what WinMM uses. (Yes, this is Alexandre-approved ;-) ) I am at the point where a merge of my work into Wine is probably two or three weeks away. After we are satisfied with the MMDevAPI implementation, we will have to begin work on re-implementing WinMM and DSound on top of MMDevAPI, as Vista+ do. So the old, unmaintained WinMM drivers, as well as the current, maintained WinMM drivers, will be replaced by a single MMDevAPI-based implementation of WinMM. The maintenance burden will then be to keep the MMDevAPI drivers up-to-date, which is really the same problem you're asking about. But the hope is to make their first implementations _good_, and then keep them all correct and current, without letting any bitrot. For the record, I am planning on having ALSA (complete-ish, ALSA sucks), OSSv4 (complete), OSX CoreAudio (in progress), and PulseAudio (not yet started) implementations from the start. I would also like a JACK implementation for the pro-audio crowd (plus, I love JACK), but that's lower priority. In any case, the MMDevAPI drivers are much simpler and better organized than the WinMM drivers. I expect maintaining them and writing tests for them will be a much easier task than maintaining the WinMM drivers. Your continued work on the WinMM family is appreciated. That will help make the re-implementation on top of MMDevAPI higher quality from the start. Thanks, Andrew

March 30, 2011

Re: [PATCH 1/6] winmm: Check callback flags prior to opening a driver.

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=10217 Your paranoid android. === WXPPROSP3 (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W2K3R2SESP2 (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === WVISTAADM (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W2K8SE (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W7PRO (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W7PROX64 (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W7PROX64 (64 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR

March 30, 2011

semi-obsolete audio drivers

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, you may have noticed that I've always sent patches for the 3 audio drivers that I consider current and mostly up to date: + winealsa + wineoss + winecoreaudio and never for one of the other ones which I consider obsolete. - winejack - wineesd - winenas Sometimes I've been wondering whether I should include and take care of winejack too, although I've neither the jack development package nor do I know or use any software that uses Jack. As for the others, I really consider them obsolete and never look at them. This is not entirely satisfactory, as I've been blaming (in thoughts) the one or other developer who in the past fixed a bug in one of the drivers without fixing the same bug in the other ones... Code continues to diverge... What do you think? - Why did people submit patches to one driver only when a short glance shows that the same bug is in the other cloned drivers too? - Is WineJack "current" and worth some effort? - Let the others continue to decay? - Remove them from git? Please don't shout for maintenance by others too early: how much time do *you* invest in making Wine better? Regards, Jörg Höhle

March 30, 2011

Re: [06/10] msi: Accept whitespace-only property values on the command line.

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=10214 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5979: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

March 30, 2011

Re: [02/10] msi/tests: Get rid of workarounds for win9x test failures.

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=10212 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5979: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

March 30, 2011

Fwd: Re: [PATCH 2/5] d3dx9_36: Implemented ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetInt (Try 5)

by Rico Schüller

Forwarding to the list. Am 28.03.2011 20:47, schrieb David Laight: >> Ints and floats are represented differently and so, if we want to put >> an integer array into floating point registers, we need to have casts. >> If you were to simply call SetFloatArray, you would get nonsense >> values in the floating point registers. > Even using casts will fall foul of the C aliasing rules - which > mean that the compiler can assume that a read of type will not be > modified by a write to a different type so can be reorderd (unless > one of the types is 'char'). > > Not only that, but there are systems that will fault is an invalid > FP bit pattern is loaded into an FP register. > > David > My example wasn't very well chosen. So conversation (casts) between the different types is necessary. It was meant the way to reuse some of the code. Because I think ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetFloatArray could share a lot of code. This will probably be the same for ID3DXConstantTable_SetBoolArray. Cheers Rico

March 30, 2011