Wine Traffic Brian Vincent

This is the 316th issue of the Wine Weekly News publication. Its main goal is to rip apart the washer. 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
DirectX Mike Hearn Microsoft Jason

Lots and lots and lots of work is going on in the DirectX world and we've got some new developers involved. Everything from minor bugfixes to complete rewrites of certain areas are in the works. A lot of the discussion is going on in #winehackers, but some of it trickles to the mailing list for review. This week we're going to take a look at shaders.

Shaders are a graphics concept that allow for extremely complex scenes to be rendered very quickly. They generally come in two flavors: pixel shaders and vertex shaders. At the heart of shaders are complex math operations generally involving things like matrices. Remember all that matrix math from calc III? Me either. On modern graphics cards these math calculations can be performed directly in the specially designed GPU's of the graphics cards rather than using the CPU of the computer. In the end, you get fancy 3D graphics. Shaders are responsible for creating fog effects, creating lighting and shadowing, etc.

Now, on Windows shaders are implemented by taking Direct3D calls and transforming the actions into Microsoft's "High Level Shader Language", or HLSL, that gets passed down to the graphics card. HLSL allows shader "programs" to be created that instruct the graphics processor what to do. On Windows, HLSL gets compiled to machine code by the DirectX libraries and pushed down to the graphics card for execution. That's a lot of overhead for Wine and fortunately it's not necessary.

On Linux, the mechanism to access the hardware of the graphics card is OpenGL. OpenGL 2.0 has more extensive shader support than previous versions and there's been an interest for Wine to be able to take advantage of that support. The OpenGL Shader Language (GLSL) approved by the OpenGL architectural review board and contained in the OpenGL 2.0 spec outlines an advanced shading language based on C. Using GLSL gives developers low-level control of the graphics pipeline similar to HLSL, except the compilation of the GLSL programs gets done within the OpenGL driver.

Wine has had shader support for quite a while, but it's relied on an older, less complete method. This week GLSL support was added by Jason Green in a series of large patches. Jason first posted an update a few weeks ago about the work and included some screenshots:

I'm working on the conversion from DirectX pixel and vertex shaders to GLSL function and have made a good bit of progress this weekend. At the moment, I'm able to run just about every simple vertex shader (version <= 1.4, and a few 2.0's) that I can find which already works on ARB_vertex_program (the current way that Wine handles this). I'm having a bit more trouble with pixel shaders, but I haven't really dug into it yet. Some of the really simple ones work, but I believe I'm missing a step in the texture binding code somewhere.

I've posted a patch to enable this shader generation here:

If you want to try this and help debug things, you'll have to apply the patch (it's against the current git tree as of 2:00 AM EST, May 30th). Plus, you'll need a video card and driver capable of using GLSL (type 'glxinfo' and look for "GL_ARB_shading_language_100") . You'll also have to set a new registry key in your Wine installation (it is case sensitve):

    HKEY_CURRENT_USER\Software\Wine\Direct3D\UseGLSL = "enabled"

Here are a few comparison screenshots (note, yes, they should be identical ;-):

In theory, once this all works, we'll be able to support shader model 2.0+, which a lot of newer games either require or strongly suggest (aka prettier graphics). Now, there are plenty of other bugs to be worked out in wined3d, so this isn't the holy grail of patches or anything, but it will take us that much closer to supporting new games. Please lend a hand if you're able to. Thanks!

(by the way, many thanks to the entire #winehackers crew for all the help along the way so far, it's been fun)

Then last week another update was given shortly before the patch was committed, Jason described a bit about it:

Well, I've fixed the speed issues with using GLSL (it's now just as fast as ARB shaders for the ones that actually work correctly) and gotten a few other things to work correctly. However, I'm still having issues with certain pixel/vertex shader combinations. Ohsix caught on that it may have to do with sampler limits on graphics cards and how sampling/textures are handled different in GLSL that with ARB. I'm not sure at the moment and could use some help.

is the diff against the most recent git tree. There are still some ugly hacks lying around in there. Note that I've separated out most of the GLSL functions into a new file "glsl_shader.c". Once again, to use GLSL instead of ARB shaders, you'll have to apply this patch, have a graphics card that's capable of GLSL, and add the following case senstive registry key:

    HKCU\Software\Wine\Direct3D\UseGLSL = "enabled"

(String value)

There was some discussion about the patch and Mike Hearn requested a bit of documentation be added to describe how it all works. Jason did so and you can find an in-depth description of Wine's DirectX shaders on the wiki.

Multimedia Robert Reif

Wine's audio has scrutinized lately. There's a lot of issues with getting sound to Just Work with Wine, not the least of which is communicating properly to the underlying hardware. There's also some fragmentation going on with Wine's audio. Rather than having one audio driver that works properly, we have five drivers subtly (and even not so subtly) broken. On top of that, other platforms require other implementations.

This week Nick Burns posted a patch for an OpenAL audio driver. In case you're not familiar with it, and I wasn't till the patch appeared, OpenAL is, a cross-platform 3D audio API appropriate for use with gaming applications and many other types of audio applications. As you can imagine, there was a bit of skepticism regarding the patch. On the one hand, it's great to see people jumping into Wine development and as such there was a fair amount of feedback and tips given regarding the patch. On the other hand, it adds one more driver to a framework badly needing attention in other areas. Nick seems to be aiming for support of MacOS X since another patch touched on that area. In that regard, it's nice to see even more work being done for that platform.

From Nick's original post:

I have started work on an openal driver for wine... So far I have playback and recording working (with minor issues) (for some reason the DSound HEL is unhappy with my driver)

OpenAL seems to have enough functionality to do the job.

Are there any problems with using OpenAL for such a purpose?

The reason for using OpenAL is for platforms that dont have alsa/oss/esd/... support For one it gives a chance to test audio on windows for example -- and on mac osx (although the winecoreaudio driver is making great progress).

Eric Pouech, who's done a lot of low-level work on audio, replied:

Planning to use OpenAL for portability reasons is a bad idea IMO:

  • it won't support the mapping required by dsound (unless we decide to drop the HW support)
  • OpenAL is overkill (in terms of API) for portability (PortAudio would be better IMO)
  • OpenAL doesn't support recording AFAICT

Nick addressed each of those issues:

OpenAL 1.1 supports recording... (1.0 does not have recording so that is a problem yes.) My driver handles this atm -- it checks for recording capabilities and supports accordingly.

The OpenAL api is rather simple: for playback you make buffers and queue them then poll them (to find out when they are done.) There are some extensions that cut out copies/support eax/. I have not looked at 'em yet. (support 2d and 3d audio) For recording (1.1 only): start capturing -- poll (get data -- if there) -- stop recording.

The dsound mapping stuff I want to understand better (are there any docs for this?) I am sure we can layer it on OpenAL (hopefully good.)

PortAudio looks like a good choice as well -- afaict -- but I dont have any experience with it (not that I had any openal exp when i started that driver)

Nick then posted a patch, got a lot of feedback, and reposted his work again. With the second round patch he announced some changes:

I finally figured out my dsound HEL problem (was making too many buffers) -- now I wait and only use a few buffers.

It seemed to work well for GTA3, Tribes2 and FlatOut (requires a binary patch to run) (dsound) -- and for SndRec32 (win/wout) Games and ...App... tested under Mac OSX x86 -- Mac Book Pro.

Remove the disable 'OPENAL_DISABLE_IN' to test wavein. (Forced off due to some issues of my OpenAL framework (I could only record at 44k -- could not figure out how to force 44k only for wavein) -- others may have better luck)

So here is my patch -- It adds it to winecfg, the makefile.in, configure.ac And it adds the new files (the actual driver why not)

I would like any feedback ppl out there may have.

With those changes it led Robert Reif to ask how well Wine's regression tests worked when run in interactive mode. Nick didn't know there was an interactive mode to the tests and after running them he reported, So I ran dsound_test and winmm_test (interactive mode?) on the command line There are some failures -- but no crashing Some games like Carmageddon2 are unhappy with openal atm.

Will another driver get added? The jury is out. Thus far the patch hasn't made it in.

Packaging Vitaliy Margolen cvs

Last week we mentioned updated Wine packages were appearing on Fedora Extras. This week Vitaliy Margolen warned everyone not use them since someone on irc appeared to have a broken package. That was news to Andreas Bierfert, who until now hasn't said anything about building the packages:

Be sure it is compiled with everything that FC/FE{3,4,5,devel} can support. The only thing is that some stuff is split out into subpackages and if users want that support they need to install it. Take a look at debian for example. Fedora Extras wine layout is basically the same. For the X driver... that should work out of the box so I suspect that the user has a different problem. In any way direct FE wine users to http://bugzilla.redhat.com to file bug against wine. This way I can easily track such bugs and decide if they should be filed against wine or if it really is a packaging but.

If you look in the package repository, you'll see there are 11 packages for Wine. A big chunk of that is to split out the various audio drivers, but there are packages that put TWAIN and LDAP support in separate packages. It led Mike Hearn to question why it was done:

We had this problem with Debian, where people didn't install the "utils" package and apps broke mysteriously. Unless you have a lot of experience of Wine debugging you cannot detect this easily ... please, there's no reason to split this stuff up as Wine will load everything in a failsafe fashion so there is no need to mark the package as depending on a million things.

Out of interest what are the 11 packages?

Andreas explained:

Well from a wine perspective I see that this makes sense, but if you take a look at all the dependencies it is another story... installing wine is one thing... ending up with zillion dependencies is a whole different story for lots of people where e.g. bandwidth is still a problem or which rather want to have a slim system. I as a packager sit between the chairs and in this case I see why splitting up wine made sense in debian and why it made sense for Fedora Extras as well. The question is what to split and what to leave in. The stuff that has been split from just having one 'wine' package is stuff that made sense and in ways interacts best with what Fedora Core ships with the distro. Sure there are improvements to be made and suggestions are always welcome :) but doing it the way it is done now made lots of people happy (and gave me positive feedback).

[the packages are:]

  • wine
  • wine-arts
  • wine-capi
  • wine-cms
  • wine-esd
  • wine-jack
  • wine-ldap
  • wine-nas
  • wine-tools
  • wine-twain

These are the 10 packages which are relevant for a 'normal' user where wine and wine-tools are the major ones. They are build from the wine sources (without winemp3). Then there is:

  • wine-debuginfo
  • wine-devel

These two are more or less only interesting for packagers/developers etc.

For more details take a look here:

And of course build from the wine-docs sources is the wine-docs rpm:

WineHQ Status Updates Chris Morgan Jonathan Ernst WineHQ Jeremy Newman

As part of a discussion about how well regressions are being tackled, Tony Lambregts gave his thoughts regarding, an update on how the AppDB is doing, and ideas for how people could help:

Since I have Administrated both the AppDB and Bugzilla for quite a while I would say that this is about even with regressions keeping pace with improvements. What seems to be improving is the rate at which the regressions are caught and fixed.

Catching regressions early is critical to fixing them and the faster release cycle helps but only if the user upgrades in a timely fashion.

Some programs have been Rock Solid for years (eg: SimCity 3000) while others are are not. Myst worked for years and then fell victim the Windows Management rewrite and I have just recently been able to run it again but it is still very unstable.

Overall I am seeing a lot more activity in bugzilla since we went to 0.9.0 as I am sure most of you are aware:

    501 in Apr 2005
    1492 in Apr 2006

    610 in May 2005
    1174 in May 2006

Some may call it a flood but over all I think this has been a good thing. The real downside to this is that it takes a lot more of my time to go through each email and see if I can assist and that the proper bug links are in place.

Going to winecfg has made the product more user friendly but we are still seem to be a long way away from "It Just Works" in a lot of cases.

In the interm I believe the AppDB has helped a lot. I think that the work that we have put into it has paid off fairly well to a point. So far we have added:

  • Applications Maintantainers that can modify application entries on an App by App basis.
  • Notification emails so that people (Administrators, Maintainers and Monitors) kept up to date on changes to applications.
  • Bug links to track bugs affecting an application.
  • Test results to track how well an application runs on a Wine version. and help spot regressions
  • Lots of small improvements.

Lots of thanks to Chris Morgan and Jonathan Ernst and everyone else that submited patches to get it to its current state.

However there are a number of things that are needed still.

  • We need a general search page.
  • It would be nice to have the ability for people to have classes of rights so that they can add/change/delete certain fields IE: "Application Description" without having to become a maintainer or administrator.
    There is a todo list here as well: http://wiki.winehq.org/AppdbInfo
    If anyone has experience with PHP or wants to gain some, there is a real need for your help.
  • A newsgroup set up that works the same as bugs so that anyone can see the notifications generated by the AppDB.
    I asked Jeremy Newman for this before but I don't think that I explained the need for it very well. (trying again)
  • More Maintainers: If you have an app that you run on a regular basis please consider becomeing a maintainer for that app.
  • More Administrators: The Application Queue is not being processed in a timely fashion.
    For myself I am busy with my day job, working on upgrading bugzilla, and burnt out/frustrated trying to keep up with Application submitions (I am too soft hearted to reject some submittions that probably should be rejected). Keeping up with the Application Queue is a tough job (for me at least, at this time) and at this point just reviewing some of the submittions makes my head hurt.
    Alexander Nicolaysen Sornes and KillerTux have picked up some of the slack but I think we could use some more help.
    This job is time consuming, tedious, thankless and does not come with a paycheck. It requires attention to detail and is a position of trust and responsability. On the plus side it does NOT require any programming skills. So... if this sounds like something you would like to do please send an email to appdb@winehq.org explaining why you you think you would be a good AppDB Administrator. (The guys in the white coats will be around ASAP)

Patches Codeweavers

This week a serious of patches appeared all at once from Anoni Moose. That's quite interesting because it shows someone took a lot of time to work on Wine and then wait to submit all the work at once... under an anonymous name. Andi Mohr was thankful for the patches but asked:

I can't help but say that your parents must have been giving you a rather "funny" name...

Or, IOW, do we have any guidelines about "Anoni Moose" submissions to our project? Are they ok, not ok, ok? Loves me, loves me not, ...

Anyway, thanks for a very nice collection of patches!

That led Christoph Frick to ask, What is the difference between anonymous submissions, that we can spot and which we don't? Maybe you are a fake ;)

Andi replied:

Darn, I knew fully well that exactly this objection would arise... ;)

Me, I've been created as an IRC bot happily typing away for about a decade without anyone noticing...

Oh, that's not true in fact, people do know that I'm real, since someone has been showing up at Codeweavers and various wineconfs pretending to be me ;)

So I guess it's fully a non-issue after all since the internet is a completely anonymous space anyway and patches can only be judged by their quality, not by their origin. Sorry for the noise!

Alexandre did weigh in on the situation:

Of course there's no real difference, but collaboration is based on trust, and it's hard to trust people who don't even want to give out their name. Obviously you can give me a false name, but I'll figure it out eventually, and then trust you even less than an anonymous submitter so there's really no point in trying to cheat.

If you have good reasons for wanting to remain anonymous, please discuss it with me in private and we can arrange something; but otherwise please use your real name.