Re: (resubmit: need a hint) user32: when needed, recalculate menu size of menu bar before tracking starts.
On Thu, May 7, 2009 at 1:52 AM, Rein Klazes wrote: > Fixes bug 10845 > > Changes from previous patch: menu position calculations moved to > nonclient.c. Can you add a testcase? -- -Austin
Re: [4/5] WineD3D: Work around a bad crash in fglrx
Am Mittwoch, 6. Mai 2009 16:33:01 schrieb Roderick Colenbrander: > Actually ATI/AMD is quite interested in Wine. I have been in contact > with them for joining their developer program and helping them fix > issues. I didn't have time to fill out all the info yet. I could get > them look at it then. Note that the issue here is not getting the bug fixed(it is fixed in the 9.4 driver, as you've verified with my test apps), but that on older radeons we'll be stuck with a broken driver until one of the 3 existing Mesa radeon drivers becomes useable(I think the radeon-rewrite branch is the target, not the radeonhd one).
Re: Wine on Solaris 10 and SXCE
On Wed, May 6, 2009 at 9:55 AM, David Gerard wrote: > 2009/5/6 Vit Hrachovy : > >> *rumour* >> IMO one of technical barriers preventing Wine in /release repo could be >> that Wine doesn't compile with SunStudio compiler, only with gcc. >> *eof rumour* > > > Obviously that sort of thing consititutes a set of bugs that should be > reported and/or fixed by those it affects ;-) > > (Wine's cross-platform abilities are presently dismal. But there are > people working on fixing this.) Actually, wine works well on many platforms. Compiler wise, however, gcc is the compiler of choice (most variants, if not all). -- -Austin
Re: Wine on Solaris 10 and SXCE
2009/5/6 Vit Hrachovy : > *rumour* > IMO one of technical barriers preventing Wine in /release repo could be > that Wine doesn't compile with SunStudio compiler, only with gcc. > *eof rumour* Obviously that sort of thing consititutes a set of bugs that should be reported and/or fixed by those it affects ;-) (Wine's cross-platform abilities are presently dismal. But there are people working on fixing this.) - d.
Re: [4/5] WineD3D: Work around a bad crash in fglrx
On Wed, May 6, 2009 at 3:52 PM, Ben Klein wrote: > 2009/5/6 Francois Gouget : >> I have a feeling that Wine is the only 'application' that really tests >> the Unix OpenGL drivers, by virtue of being the only application to run >> the really complex vertex and pixel shaders that are found only in >> Windows games. Maybe I am wrong, but if I am right it means that the >> driver developpers would do well to take Wine seriously, and probably >> use it as a matter of course, if they want to produce quality code. > > I've been in contact with developers at Linux Game Publishing for a > while (and am now in fact a Junior Developer for them :D), and from > what I gather, regular OpenGL apps on Linux implement hacks to work > around bugs/shortcomings in ATI/AMD drivers. Wine is a special case > where it's been decided that hacks for specific drivers is a bad idea > except in extreme cases, and that there should be generalised > solutions for everything (which is, by the way, the whole point of > OpenGL :) ). > > As a result, the question of hacks in Wine comes up quite often > (ATI/AMD card owners want their games to work!) and it's (almost?) > always rejected. With any luck, we'll see some sensible, functional, > open-source radeonhd drivers coming soonish, so the issue of hacks at > the application level can be minimised. > > > Actually ATI/AMD is quite interested in Wine. I have been in contact with them for joining their developer program and helping them fix issues. I didn't have time to fill out all the info yet. I could get them look at it then. Roderick
Re: [4/5] WineD3D: Work around a bad crash in fglrx
2009/5/6 Francois Gouget : > I have a feeling that Wine is the only 'application' that really tests > the Unix OpenGL drivers, by virtue of being the only application to run > the really complex vertex and pixel shaders that are found only in > Windows games. Maybe I am wrong, but if I am right it means that the > driver developpers would do well to take Wine seriously, and probably > use it as a matter of course, if they want to produce quality code. I've been in contact with developers at Linux Game Publishing for a while (and am now in fact a Junior Developer for them :D), and from what I gather, regular OpenGL apps on Linux implement hacks to work around bugs/shortcomings in ATI/AMD drivers. Wine is a special case where it's been decided that hacks for specific drivers is a bad idea except in extreme cases, and that there should be generalised solutions for everything (which is, by the way, the whole point of OpenGL :) ). As a result, the question of hacks in Wine comes up quite often (ATI/AMD card owners want their games to work!) and it's (almost?) always rejected. With any luck, we'll see some sensible, functional, open-source radeonhd drivers coming soonish, so the issue of hacks at the application level can be minimised.
Re: Wine on Solaris 10 and SXCE
Austin English wrote: On Wed, May 6, 2009 at 5:15 AM, Vit Hrachovy wrote: Austin English wrote: OpenSolaris package wine in repository http://pkg.opensolaris.org/contrib Is the contrib repository enabled by default? I haven't noticed it when using OpenSolaris...or is it new for 2009.06? No, you have to add contrib repo manually. contrib repo exists since 2008.11 release. Ahh, thanks. Do you know if there's any plan on OpenSolaris's end to include Wine in its repository? There are no plans to add Wine to /release repository by now (no ARC case I'm aware of). However, anyone can use SourceJuicer [1] and SFE wine spec file [2] to contribute latest Wine release to /pending repo and ask /contrib repo maintainers to update the package here. *rumour* IMO one of technical barriers preventing Wine in /release repo could be that Wine doesn't compile with SunStudio compiler, only with gcc. *eof rumour* Regards Vit [1]http://opensolaris.org/os/project/sourcejuicer/ [2]https://pkgbuild.svn.sourceforge.net/svnroot/pkgbuild/spec-files-extra/trunk/SFEwine.spec
Re: [4/5] WineD3D: Work around a bad crash in fglrx
2009/5/6 Henri Verbeet : > Mesa (that includes e.g. the intel and radeon drivers) is generally > responsive to bug reports, as is NVIDIA. It's really just AMD and > Apple that are problematic wrt. getting bugs fixed. > Just for the record, I'm not trying to just make AMD look bad here, I think it's great that they released the GPU documentation, and that they're paying people to work on the Mesa driver. Also, going by what I hear from other people, fglrx improved a lot in the more recent versions (certainly compared to the kind of support my Radeon 9800 Pro had...), so it's not all bad. They just *really* need to fix their developer relations stuff.
Re: Wine on Solaris 10 and SXCE
On Wed, May 6, 2009 at 5:15 AM, Vit Hrachovy wrote: > Austin English wrote: >>> OpenSolaris >>> package wine in repository http://pkg.opensolaris.org/contrib >> >> Is the contrib repository enabled by default? I haven't noticed it >> when using OpenSolaris...or is it new for 2009.06? > > No, you have to add contrib repo manually. contrib repo exists since 2008.11 > release. Ahh, thanks. Do you know if there's any plan on OpenSolaris's end to include Wine in its repository? -- -Austin
Re: Wine on Solaris 10 and SXCE
Austin English wrote: On Wed, May 6, 2009 at 3:56 AM, Vit Hrachovy wrote: Hi people, Apostolos provided me links to download Sun packages of latest Wine (1.1.20) at sunfreepacks. Could someone responsible please update WineHQ page with the following info: The sources are available at http://source.winehq.org/git/ Ahh, thx. will send patch. OpenSolaris package wine in repository http://pkg.opensolaris.org/contrib Is the contrib repository enabled by default? I haven't noticed it when using OpenSolaris...or is it new for 2009.06? No, you have to add contrib repo manually. contrib repo exists since 2008.11 release. Cheers Vit
Re: [4/5] WineD3D: Work around a bad crash in fglrx
2009/5/6 Stefan Dösinger : > Am Mittwoch, 6. Mai 2009 10:10:07 schrieb Henri Verbeet: >> ...and on the other ones it will create hard to diagnose / explain >> bugs. Just disabling the extension if it's broken also avoids the >> crash, and will at least have predictable behaviour. > Not in this case. As I explain in a comment in the test, there's no d3d cap > flag for point sprites. So the games will just go ahead and try to do the > same kind of rendering and just fail in the same or worse way. > > The only advantage we get from disabling point sprites altogether is the WARN > we get if the game tries to use them. I'll add a similar WARN to the point > sprite function if the game uses them and this workaround is active. > Well, the point is that if you disable the extension it will just not work at all, instead of "sometimes, depending on which texture unit the texture is mapped on". >> Of course it would also help if AMD took these kind of >> things seriously, or at least replied to my posts >> (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107). > That specific issue is fixed in 9.4 I think. They confirmed the bug and > replied here: > http://ati.cchtml.com/show_bug.cgi?id=1462 > Sure, I read that too, but it's not my point of course.
Re: [4/5] WineD3D: Work around a bad crash in fglrx
2009/5/6 Francois Gouget : > On Wed, 6 May 2009, Henri Verbeet wrote: > [...] >> I also *still* think us working around AMD's bugs is the wrong >> approach. Of course it would also help if AMD took these kind of >> things seriously, or at least replied to my posts >> (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107). > > Do we have a more formal way of reporting bugs to AMD/ATI? Something > like a Bugzilla? Concerning this issue (the driver reporting a number of > vec4s instead of the number of uniforms), do we have a way of checking > independently of AMD? If so that would strengthen our bug report. > I think they're aware of that particular issue because Stefan talked privately to one of their developers, but unless things changed recently http://ati.cchtml.com/ is probably the closest to a bug tracker there is, and I'm not completely sure they read that regularly. > But hey, I got a quick answer to my bug report to the Intel developpers > so it's not always bad. Unfortunately now I'm the one that's slow to > answer as I have not had time to test their proposed fix. But I have not > forgotten... > Mesa (that includes e.g. the intel and radeon drivers) is generally responsive to bug reports, as is NVIDIA. It's really just AMD and Apple that are problematic wrt. getting bugs fixed.
Re: [4/5] WineD3D: Work around a bad crash in fglrx
Am Mittwoch, 6. Mai 2009 10:10:07 schrieb Henri Verbeet: > 2009/5/5 Stefan Dösinger : > > + * quirk only enables point sprites on the first texture unit. This > > keeps point sprites working in + * most games, but avoids the crash > > ...and on the other ones it will create hard to diagnose / explain > bugs. Just disabling the extension if it's broken also avoids the > crash, and will at least have predictable behaviour. Not in this case. As I explain in a comment in the test, there's no d3d cap flag for point sprites. So the games will just go ahead and try to do the same kind of rendering and just fail in the same or worse way. The only advantage we get from disabling point sprites altogether is the WARN we get if the game tries to use them. I'll add a similar WARN to the point sprite function if the game uses them and this workaround is active. > I also *still* think us working around AMD's bugs is the wrong > approach. I agree in general, if this was just a rendering bug I'd put the workaround as a hack into CrossOver and be happy. However, we're trying to prevent a kernel panic here, and on the last two Wineconfs we agreed that we should try to prevent kernel panics while running our d3d tests, even if it is ugly(we have similar workarounds for old Mesa glDrawPixels / glReadPixels issues). If the tests crash the systems people will refuse to run them, making them useless. > Of course it would also help if AMD took these kind of > things seriously, or at least replied to my posts > (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107). That specific issue is fixed in 9.4 I think. They confirmed the bug and replied here: http://ati.cchtml.com/show_bug.cgi?id=1462 (unfortunately no 9.4 for <= r500 cards, so we have to keep our workaround in directx.c)
Re: [4/5] WineD3D: Work around a bad crash in fglrx
On Wed, 6 May 2009, Henri Verbeet wrote: [...] > I also *still* think us working around AMD's bugs is the wrong > approach. Of course it would also help if AMD took these kind of > things seriously, or at least replied to my posts > (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107). Do we have a more formal way of reporting bugs to AMD/ATI? Something like a Bugzilla? Concerning this issue (the driver reporting a number of vec4s instead of the number of uniforms), do we have a way of checking independently of AMD? If so that would strengthen our bug report. I have a feeling that Wine is the only 'application' that really tests the Unix OpenGL drivers, by virtue of being the only application to run the really complex vertex and pixel shaders that are found only in Windows games. Maybe I am wrong, but if I am right it means that the driver developpers would do well to take Wine seriously, and probably use it as a matter of course, if they want to produce quality code. But hey, I got a quick answer to my bug report to the Intel developpers so it's not always bad. Unfortunately now I'm the one that's slow to answer as I have not had time to test their proposed fix. But I have not forgotten... -- Francois Gouget http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...
Re: Wine on Solaris 10 and SXCE
On Wed, May 6, 2009 at 5:02 AM, Austin English wrote: > On Wed, May 6, 2009 at 3:56 AM, Vit Hrachovy > wrote: > > Hi people, > > Apostolos provided me links to download Sun packages of latest Wine > (1.1.20) > > at sunfreepacks. Could someone responsible please update WineHQ page with > > the following info: > > The sources are available at http://source.winehq.org/git/ > > > OpenSolaris > > package wine in repository http://pkg.opensolaris.org/contrib > > Is the contrib repository enabled by default? I haven't noticed it > when using OpenSolaris...or is it new for 2009.06? Contrib still shows Wine 1.0.1 http://pkg.opensolaris.org/contrib/en/search.shtml?token=wine&action=Search > > -- > -Austin > > >
Re: Wine on Solaris 10 and SXCE
On Wed, May 6, 2009 at 3:56 AM, Vit Hrachovy wrote: > Hi people, > Apostolos provided me links to download Sun packages of latest Wine (1.1.20) > at sunfreepacks. Could someone responsible please update WineHQ page with > the following info: The sources are available at http://source.winehq.org/git/ > OpenSolaris > package wine in repository http://pkg.opensolaris.org/contrib Is the contrib repository enabled by default? I haven't noticed it when using OpenSolaris...or is it new for 2009.06? -- -Austin
Wine on Solaris 10 and SXCE
Hi people, Apostolos provided me links to download Sun packages of latest Wine (1.1.20) at sunfreepacks. Could someone responsible please update WineHQ page with the following info: http://winehq.org Run Windows applications on Linux, BSD, Solaris and Mac OS X. http://winehq.org/download/ Solaris http://www.sunfreepacks.com/listing/?limit=1000&offset=0 Solaris 10 http://www.sunfreepacks.com/pkgpool/ASwine-1.1.20.pkg.7z Solaris SXCE http://www.sunfreepacks.com/pkgpool/ASwine-SXCE-1.1.20.pkg.7z OpenSolaris package wine in repository http://pkg.opensolaris.org/contrib Thank you very much! Regards Vit Hrachovy Original Message Subject: Re: wine web pages update Date: Fri, 1 May 2009 11:31:53 -0700 (PDT) From: Apostolos Syropoulos To: Vít Hrachový Hello there, We have exchanged a couple of messages back in March about the inclusion of Solaris/OpenSolaris download link in the wine pages, but still there is no progress. If you visit the following URL http://www.sunfreepacks.com/listing/?limit=10&offset=20 you will be able to download binary packages for both platforms. Could you please update your web pages? Kind regards, Apostolos -- Apostolos Syropoulos Xanthi, Greece
Re: [4/5] WineD3D: Work around a bad crash in fglrx
2009/5/5 Stefan Dösinger : > + * quirk only enables point sprites on the first texture unit. This keeps > point sprites working in > + * most games, but avoids the crash ...and on the other ones it will create hard to diagnose / explain bugs. Just disabling the extension if it's broken also avoids the crash, and will at least have predictable behaviour. I also *still* think us working around AMD's bugs is the wrong approach. Of course it would also help if AMD took these kind of things seriously, or at least replied to my posts (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107).
Re: [2/5] WineD3D: Keep track of used float constants
> +reg_maps->constf = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + sizeof(*reg_maps->constf) * (constf_size / > (sizeof(*reg_maps->constf) * 8) + 1)); This is flawed, it will allocate too much memory. You essentially want "(bit_count + 31) / 32" to calculate the number of DWORDs. > static void shader_record_register_usage(IWineD3DBaseShaderImpl *This, > struct shader_reg_maps *reg_maps, > -DWORD register_type, UINT register_idx, BOOL has_rel_addr, BOOL > pshader) > +DWORD register_type, UINT register_idx, BOOL has_rel_addr, BOOL > pshader, unsigned char size) I don't think this is very nice, it's better to just call shader_record_register_usage() multiple times for the appropriate instructions. I.e., handle this the same way all the other opcodes are handled.
