Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
Table Of Contents
|1.||(1 post)||News: Wine 0.9.3|
|2.||(18 posts)||Accelerating DirectDraw|
|3.||(3 posts)||Git Scripts|
|4.||(7 posts)||Finding Regressions|
|5.||Feedback on aRTs, ESounD, and JACK Drivers|
|6.||(3 posts)||Fedora 64-bit x86|
|7.||(10 posts)||Relay Segfaults|
This is the 301st issue of the Wine Weekly News publication. Its main goal is to break drill bits. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org
Mailing List Stats For This Week
We looked at 163 posts in 437K.
There were 61 different contributors. 35 posted more than once. 32 posted last week too.
The top posters of the week were:
1. News: Wine 0.9.3
(1 post) Archive Link: "News"
People: Alexandre Julliard, CodeWeavers, News
Wow, it seems like we've had a lot of CVS drops lately. Perhaps that's because we've had a lot of commits. The latest is Wine 0.9.3 which came out on Thursday. Alexandre highlighted the following in the announcement email:
What's new in this release:
It seems right now we're in that interesting period where CodeWeavers is doing infrastructure changes and laying the groundwork for even more. In particular, we're seeing RPC additions to support Outlook 2003, which requires wire compatible DCOM to talk to Exchange. As we've mentioned in the past, the directory objects support has been added to get us toward implementing an ntoskrnl.exe that will support loading copy protection drivers like Safedisc. Finally, other folks have been hard at work getting other parts of Wine working better.
If CodeWeavers sticks to the roadmap they outlined late last summer, then you can expect this kind of work to taper off in the coming months as they stabilize for a new release. (Of course, that means Wine also gets the same fixes!)
2. Accelerating DirectDraw
(18 posts) Archive Link: "DirectDraw over Direct3D"
People: Roderick Colenbrander, Jesse Allen, Lionel Ulmer, Stephan Dosinger, Stefan Dosinger
Roderick Colenbrander had an idea for speeding up Wine's DirectDraw implementation:
As you all might know 2d games tend to be slow on Wine. For a lot of games the main bottleneck is depth conversion which happens in cases when the depth requested by the game and the X desktop color are not the same.
As a way to speedup 2d Lionel assisted me with hacking wine's ddraw to let it use parts of the Direct3D backend. The final rendering is then done using OpenGL and the end result is that the videocard does the color conversion for us. The patch greatly improves the performance of 2d games which don't use GetDC/ReleaseDC a lot.
While the patch fixes the conversion bottleneck for various games it doesn't handle 8bit paletted which is used by games like StarCraft as OpenGL doesn't support this by default. The second patch which I attached as well adds support for this. On cards (at least all nvidia cards from geforce 1 to the fx) that support the opengl paletted texture extension this extension is used. It makes StarCraft very fast atleast on my Athlon XP2000 system with a GeforceFX where the game was slow before. As not all cards support paletted textures I emulated this using a simple fragment shader. (a 1D texture containing the palette is used as a lookup table)
The attached patches are still experimental and likely contain bugs so please test them. When the patches are applied set 'HKCU\Software\Wine\DirectDraw\UseDDrawOverD3D' to Y else it won't do anything :)
Further note that lots of games like to use multiple threads for graphics... using the patch games use 'd3d' (or actually opengl) which adds more multithreaded d3d games :) Games like Command & Conquer, Red Alert, Total Annihilation and lots of others became multithreaded. (they crash quite quickly due to some critical section in x11drv)
All have fun with the patches and please report any issues that appear so that I can fix the patches and submit them to wine-patches.
Jesse Allen asked some questions about it:
Is Starcraft really that slow? How does this compare with using DGA? I'm not too sure because its speed varies. I've been testing Starcraft this weekend and it has been plenty speedy. But I do remember when trying to play it multiplayer a few months ago and was burned when it ran slow. In fact it slowed *everyone* down. Not fun.
This patch seems similar to glSDL where it wraps SDL's 2d API to OpenGL. The good thing about this it can provide acceleration and not require root like DGA. The bad thing with this idea is that it can't be used on older video cards or even some newer ones that lack proper direct rendering. Am I correct that even when just doing depth conversions, without direct rendering it will still be slow?
Roderick explained in detail:
The code won't work for cards without hw accelerated opengl but note that most cards these days have opengl support. A simple Riva TNT is already quite old but is still supported on Linux and it should do a fine job only it can't handle the palette conversion. I haven't tested performance much using Mesa, I could try that soon using some games but it doesn't have to be slower than the current code as Mesa uses Xlib too in the indirect case. In general about all cards these days have some form of opengl support (intel, via, ati, nvidia, ..) perhaps only the latest S3 GPUs and perhaps some SIS ones (thought some have drivers) lack support. Note that cards don't need much functionality at all as OpenGL is only for the uploading of textures and the rendering of them.
I think the patch is a reasonable solution to work around various depth conversion problems. For sure it is the fastest way for the conversion as the videocard basically does it for free. On my system StarCraft and the Command & Conquer series (although they crash quite quickly due to threading issues) felt a lot faster, I think that the speed is close to that of DGA.
Perhaps I should clarify some misunderstandings that some people have. (I hope I explain it correctly) Basically DirectDraw provides a mechanism to directly access the framebuffer of the videocard. This is the fastest way to render 2D images on the screen. Games like StarCraft, Total Annihilation, C&C and lots of others use DirectDraw in this way. Second there's another class of games like Age Of Empires2, Heroes of Might and Magic IV and others which mix ddraw with GDI. They for instance render a image using ddraw and then use GetDC/ReleaseDC to get a device context so that they can draw in the surface. (directly into the video memory)
In case of X direct framebuffer access is only possible through DGA but it is insecure and has other issues. When DGA works correctly it can accelerate games like StarCraft. Further DGA doesn't have any depth conversion issues as it does depth switching. Without DGA the rendering operations need to go through X. Because of limitations of X, depth conversion problems appear when the depth of the desktop and X aren't the same.
For depth conversion purposes Wine's DirectDraw uses a DIB section. Basically all pixels of an image are translated to the depth of X. This is slow and especially for the case when the application requests 8bit paletted mode using a 24bit desktop. In this case a color lookup needs to happen in a palette for each pixel. The end result is then shown on the screen (if the game is of the StarCraft type)
Games that use GetDC/ReleaseDC can't work using DGA. The performance in general isn't great as lots of X calls happen. (things like conversions from XPixmap to XImages and the way around and also depth conversions happen a lot)
The patch I sent works for both classes of games though it won't help much for the second class as GetDC/ReleaseDC stuff is slow. As explained before the patch uploads the surface to a texture which is then rendered using OpenGL. This is quite fast and as a bonus the videocard can do all depth conversion for us as it isn't limited to rendering textures which are at the same depth as X.
For old videocards the GL renderer won't work and the old code should work fine (except for performance issues). You might have heard people talking about a 'dibengine' which would let Wine do all DIB related operations in software which would save a lot of XImage/XPixmap conversions. (conversion is only needed for the final rendering stage) This dibengine would mainly accelerate games that use GetDC/ReleaseDC. It won't help games like StarCraft (much) as for those DIBs were only used for depth conversion and the conversion algorithm stays the same (it can't be tweaked much if at all). So there's not really a way to speedup games like StarCraft for old videocards. Perhaps XShm might be of use but not sure how much it would help. (think it would only be useful for GetDC/ReleaseDC games)
Pretty much everyone was in favor of any patch that would improve performance. This method won't ever be as fast as using DGA, but it certainly seemed to be better than what we have. Then the question came up about how this related to Stephan Dösinger's work moving Direct3D 7 over to using the WineD3D library. Lionel Ulmer suggested:
I think that to merge Roderick's and your (ed note: Stephan's) patch, the best would be to directly hook WineD3D even at the 2D level and not have DDraw hook DDraw's D3D which then goes into WineD3D.
This way we would have a unified DDraw.
Of course, then the problem remains of what to do with older cards :-)
I thought of the same thing, as DDraw -> D3D7 -> WineD3D -> OpenGL is a quite long chain. I abandoned it as too much work at first, but it's surely worth considering.
How about moving the current 2D code to WineD3D, and making DDraw running over WineD3D in any case. Then WineD3D could decide whether to use plain X11, DGA or OpenGL for 2D rendering. :)
Maybe we should have a close look at the details of such a thing. I do not really recommend a ad-hoc attempt, as d3d7->WineD3D was nearly too much.
Lionel liked the idea:
That basically bows down to have WineD3D completely replace the 'HAL' architecture which was introduced by the TG merge.
Which is kinda an idea that I like :-)
Well, we can first stabilize D3D7 => WineD3D (which will already be quite a lot of work to first do and then polish) and then see if we move the 2D part too.
And then we will need to rename it to something else ... if not merge it integrally into the X11DRV so that other DLLs (like the new Vista ones :-) ) would be able to do 3D accelerations :-)
Then, as this issue was being wrapped up, Stefan sent an email with some ideas about how to proceed and asked for feedback about it:
In the past weeks, I've worked on a re-write of the Direct3D7 implementation with WineD3D. Well, I've managed to get some games running, but I have also encountered a few problems. Before I continue with this, I'd like to ask for your opinions.
I have uploaded a patch to http://doesi.gmxhome.de/d3d7.patch.bz2, it's a diff against Wine CVS from December, 11th 2005. It's not really meant to be used, but rather to have something to look at. I don't know how long I can keep the patch there, because I am limited in space. I've sent the patch to Oliver some days ago to upload it to his sourceforge website, it will be available there when he uploads it.
So what's the point of this mail? While a D3D7->WineD3D wrapping can be done by wrapping D3D7 only and leave DirectDraw in ddraw.dll, it has a few ugly drawbacks:
I think that everything would be much cleaner if the DirectDraw functionality was also moved to WineD3D. My suggestion is the following:
What's the drawback? First, it's much more work, and it's a really invasive change to WineD3D, which becomes more complex. Because of this I'd like to know your opinion before I spend a lot of time for this.
3. Git Scripts
(3 posts) Archive Link: "git patch to gmail draft script"
People: James Hawkins, Christian Lachner, cvs
James Hawkins put together a small script to hopefully help folks using Wine's new git repository make patches to send with Google's Gmail:
I've hacked up a little script that takes your committed git changes and puts a draft in your gmail draft folder for each commit that contains a changelog and the attached diff. To use the script, make sure you have python installed. You'll also need to change the variables at the top of the script to match your specifics. The script is pretty simple, so if you don't like the format of the email it wouldn't be hard to change. The process goes like so:
You'll also need libgmail for python installed as well:
If you have any comments or suggestions, I'd like to hear them (I think the script is rather ugly myself, but it gets the job done :))
Another script by Christian Lachner will download, compile, and install Wine from this git repository:
OK, more news. I updated my cvs-script a little bit (nothing really noticeable) but that's not all. Since everybody seems to have changed to GIT, I wrote a git-version of my wine-update-script. Features, functionality and so on are the same as in the cvs-version.
4. Finding Regressions
(7 posts) Archive Link: "WINE 0.9.3 and Photoshop 7 & CS"
People: Aleksey, Scott Ritchie, Dimitrie Paun, Dimi Paun
Ahhhh... regression testing. If you happen to notice something in Wine suddenly breaks, there's a fairly simple regression testing procedure you can do to figure it out. In fact, this method will work for pretty much any project, so it's a good thing to remember. It can also be the most time consuming part of fixing a bug. So figuring out exactly what broke something can get you really close to having a fix.
(There are also some exceptions to this, such as adding in stubbed functions that cause programs to suddenly break. The right fix is not to remove the stub, but to turn the stub into a complete function.. which may be a lot of work.)
Someone wrote in this week with a problem and the replies contained info about helping out:
Yesterday I upgraded to WINE 0.9.3, and then tried running Photoshop 7. Photoshop gave me a hardware error. I thought, no problem, I'll just reinstall it, same result. Then I reconfigured WINE using winetools and tried again, same thing. Here is what I got in the Terminal when running Photoshop 7:
Then I tried installing Photoshop CS, knowing that it worked fine with 0.9.2. Photoshop CS told me that certain required files was missing, but I forgot to get down the results from the Terminal. After that I downgraded to WINE 0.9.2 and both versions of Photoshop work great.
A little side note: ImageReady 7 works great under 0.9.3, I did not test ImageReady CS. ImageReady 7 works great under 0.9.2 also, but ImageReady CS crashes.
So there was actually some useful information in there. Scott Ritchie replied, " Well, the ideal way to fix bugs like this is to find the exact patch that caused the breakage. You've already done a whole lot for us by pointing the exact version that broke things. If you or someone else with Photoshop 7 is willing/able to do a lot more, however, we can attempt to isolate the exact patch that caused the breakage by doing several recompiles with/without various patches that have been applied since the last version. "
Dimi Paun followed up on that with instructions how to do it:
Yes. And here are some instructions on how to go about finding the troublesome patch:
5. Feedback on aRTs, ESounD, and JACK Drivers
Archive Link: "feedback wanted from arts, esound and jack sound driver users."
People: Robert Reifposts="1" >
Alexandre mentioned there were some new changes for better audio driver management in winecfg. That work has been done by Robert Reif and this week he asked if anyone could give him some feedback regarding the lesser used (and more broken) audio drivers:
Is anyone using the arts, esound or jack sound drivers for non trivial use? By non trivial, I mean more than one application or more than a single device. If so, I am interested in getting information on the software you are using and how it is using the drivers.
Would redesigning these drivers to show up as a single device per physical device which allowed being opened more than once be a problem?
6. Fedora 64-bit x86
(3 posts) Archive Link: "A better workaround for compiling on FC4/x86_64"
Topics: Build Process
People: Pavel Roskin, Marcus Meissner
Apparently Fedora's 64-bit version doesn't provide some of the 32-bit compatibility libraries necessary for Wine. (Which is somewhat surprising since Wine doesn't have as many dependencies as you'd expect.) Pavel Roskin came up with a script to work around it:
When trying to set up printing from Wine on Fedora Core 4 for x86_64, I have discovered that Wine fails to find many libraries, including libcups. It turns out that the development packages on Fedora Core 4 don't always provide *.so symlinks for 32-bit libraries. So I wrote this script.
The script creates all missing links in one directory (/usr/local/lib is the default). Not only was libcups found next time, but also the old workaround with imake has become unneeded. The configure script runs out-of-box and finds X11 libraries.
I'm posting the script here in hope that it will be useful for some Wine users. I'm not sure it it merits inclusion in Wine, but I would not object.
Marcus Meissner, who's heavily involved with SuSE's 64-bit x86, felt Fedora should really just provide that stuff out of the box. Pavel replied with more details:
They are provided for some basic libraries, such as zlib and ncurses. Other libraries, such as cups, as missing, but my script can remedy it, because the only missing file is the symlink to *.so for the linker.
Unfortunately, openssl support cannot be fixed by the script since /usr/include/openssl/opensslconf-i386.h is missing. That's where a development package would be very helpful.
I see it's not fixed in RawHide yet, so we'll have to deal with such issues for some time.
7. Relay Segfaults
(10 posts) Archive Link: "how do I find where wine itself is segfaulting?"
People: Bill Medland, Peter Berg Larsen, Mike McCormack
A thread popped up this week that seems to point to a problem lurking somewhere, but no one seems to have the answer to it. Bill Medland reported on it (and it's been brought up before):
Background. I am trying to figure out why a program that I thought ran OK on 25 October no longer runs and no longer runs when I recompile from that code too.
So the program accesses invalid memory down inside the WNDPROC stuff (winproc.c line 418, it says, so I guess it means line 416)
So I turn on WINDEBUG=+relay to see what is being passed.
And wine segfaults.
0009:Call kernel32.__wine_kernel_init() ret=77ed4e4d
I can't use gdb and I can't use winedbg.
Anyone know what is going on?
Peter Berg Larsen confirmed the issue, " Wine crashes the first time it enters/uses a entry/function using the debug setup from ntdll/relay.c:RELAY_SetupDLL. (Which happens to be a RtlInitUnicode in kernel/module:GetModuleHandleW) . If you exclude the ntdll in relaying, wine - without parameters - does not crash. BUT at soon as you try running a program it will crash when calling a kernel32/* function."
Mike McCormack knew of it as well and mentioned there was a hack in the CrossOver tree to work around it. Bill tried it but didn't have any success. He started looking at differences between his old machine it worked on and the new one. He narrowed it down to the kernel, " It's the kernel choice. It works on the non-smp kernel and fails on the smp kernel. (2.6.9-22.EL works; 2.6.9-22.ELsmp fails, both are RedHat kernels)"
Peter advised, " Try booting with noexec=off. I tried that when I asked wine-devel a month ago, but my mandrake crashed - for some obscure reasons - before reaching a prompt."
So that's where we stand: a problem with a possible workaround, but insufficient info to have a real fix. Is it a Wine problem? Kernel?
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.