Wine 1.5.11 Kills Big X11 Lock, Brings Multi-Channel ALSA

[phoronix]

Phoronix: Wine 1.5.11 Kills Big X11 Lock, Brings Multi-Channel ALSA

Wine 1.5.11 has been released today now that the project's back to their bi-weekly Friday releases. Wine 1.5.11 brings a few interesting changes...

http://www.phoronix.com/vr.php?view=MTE2MjU

[GreatEmerald]

Grumble grumble.

Anyway, what's the X11 lock?

[deanjo]

Wow, multichannel support. That's a feature that has been on the wishlist for a long long long time.

[mggrant]

Here's hoping the sound revamps finally include working Pulseaudio support soon - turning off PA isn't an option (or at least a very bad one) and PA support via ALSA emulation has never worked well. Mind you, no idea how difficult multichannel PA is!

[ShadowBane]

Here's hoping the sound revamps finally include working Pulseaudio support soon - turning off PA isn't an option (or at least a very bad one) and PA support via ALSA emulation has never worked well. Mind you, no idea how difficult multichannel PA is!

Looking at the PA API multi-channel looks pretty easy, you just tell it you want multiple channels.

[e8hffff]

I hope this multi channel ALSA driver doesn't mess up the recent Ubuntu PulseAudio version of Wine, as PulseAudio has been running fantastic.

[Thaodan]

I hope this multi channel ALSA driver doesn't mess up the recent Ubuntu PulseAudio version of Wine, as PulseAudio has been running fantastic.

The Pulseaudio is another drv modul than alsa.

[AJSB]

Grumble grumble.

Anyway, what's the X11 lock?

+1.....i also have no idea what they meant with that....

[Emanemxxx]

x11 lock is "simply" a big mutex which was mainly called every time there was frame drawing and/or other GL and X11 operations.
Aquiring and releasing locks are potentially expensive operations which may yield the control of the CPU from the process which performs locking operations to the OS, triggering a potential context switch and so decreasing overall performance, i.e. FPS, of an application using such locks.
As you already know, Direct3D calls are mapped to OpenGL, which through macros ENTER_GL and LEAVE_GL, was heavily using the lock.

Removing a potential cause of slowness in D3D applications is always a good thing. Nonetheless I'd like to point out that probably Michael's not completely accurate: in fact, a previous patch committed the 19th of July was actually performing the above enter/leave gl soft switch off, and was released indeed with wine 1.5.10.

Again, with this revision the lock has been "officially" removed from the code, but already one month ago majority of D3D codebase already stopped using it...

Not having the X11 lock anymore is great news, but again, this is probably the last part of an incremental change.

Hope this is clear!
Cheers!

Ps. here the enter/leave gl patch to exclude the lock http://source.winehq.org/git/wine.gi...928f0a959e9e14

[curaga]

I'm not at all familiar with Wine details, but here's how it usually is.

Big X11 lock:

Every time they call any X function, lock a mutex (or other scalable construct) so that only one thread can do those at a time.

Gone:

Replaced with a set of smaller locks, which scales better.

The same thing was done with the big kernel lock.