Mesa Starting To Use C11 Threads, Boost

[phoronix]

Phoronix: Mesa Starting To Use C11 Threads, Boost

The latest Mesa code in Git is now using C11 Threads via a Boost emulation library...

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

[Thaodan]

Do people really use Mesa drivers on MS Windows?

Something that I thought too.

[Rexilion]

Gallium is designed to run on any OS.

[devius]

Do people really use Mesa drivers on MS Windows?

I remember that back in the days of Win95/98 there was a file in the system32 directory called mesa.dll (or something like that) and I think it used to be the OpenGL software fallback driver for when the system didn't have hardware acceleration (which was the case for most systems back then). I don't know if that's still the case with more recent versions of Windows though.

[Veerappan]

Do people really use Mesa drivers on MS Windows?

Yes. The VMWare driver uses Gallium3D (many of the guys who wrote the initial Gallium3D implementation now work for VMWare). Pretty sure that includes their windows driver. There are quite a few commits on the mesa-dev list from VMWare devs that have to do with getting Direct3D's specifics handled correctly while also making OpenGL work.

[Raedwulf]

Boost-licensed...

Phoronix: Mesa Starting To Use C11 Threads, Boost

The latest Mesa code in Git is now using C11 Threads via a Boost emulation library...

I think you mean Boost-licensed rather than Boost? Boost is a C++ library.

[mrugiero]

Gallium is designed to run on any OS.

Yes, but you need to implement the backend, and none of the drivers I skimmed over has it.

Do people really use Mesa drivers on MS Windows?

I've been wondering a lot about that, seeing how I saw patches flowing to fix the build con MSVC. I know ReactOS uses or used its software renderer.

[Daktyl198]

Yes, but you need to implement the backend, and none of the drivers I skimmed over has it.



I've been wondering a lot about that, seeing how I saw patches flowing to fix the build con MSVC. I know ReactOS uses or used its software renderer.

So wait... Mesa used to use pthreads before right? So now it uses an abstraction library... in order to have Windows support? Doesn't that hurt performance on *nix/bsd (using the abstraction library)?

And since I am so unaware of how it works, how does Mesa/Gallium affect a Windows installation over VMware? Does it run actual Windows drivers connected to virtual hardware, or does it run virtual drivers connected to the real hardware (and just interfacing with Windows via their driver API/ABI)? AKA, what would Mesa having Win32 thread support matter if it's the first answer?

[Daktyl198]

Wong quote, ah well *shrug*

[mrugiero]

So wait... Mesa used to use pthreads before right? So now it uses an abstraction library... in order to have Windows support? Doesn't that hurt performance on *nix/bsd (using the abstraction library)?

I have no idea if it was using threads before, but yeah, if it is like you say, it will probably introduce some overhead. Still, it might be noticeable or it might be negligible, someone should test it before anyone jumps to conclusions.

And since I am so unaware of how it works, how does Mesa/Gallium affect a Windows installation over VMware? Does it run actual Windows drivers connected to virtual hardware, or does it run virtual drivers connected to the real hardware (and just interfacing with Windows via their driver API/ABI)? AKA, what would Mesa having Win32 thread support matter if it's the first answer?

My guess is that the winsys component needs to interface a WDDM kernel mode driver on modern Windows.
Now, on running Windows on a VM, the threads will have to spawn inside the VM, as the OS needs to know about them. For that, you will need them to be Win32 threads.