Mesa on Windows?

[Daktyl198]

Before you laugh at me or throw tomatoes, hear me out?

This topic has been brought up before in a couple threads, but I wanted a thread specifically for it...
I've heard that Mesa is "portable to other OSes", and since it works on Haiku, I'm going to assume that's correct. We already have a semi-working D3D9 state tracker in one of the Radeon drivers (or was it Gallium3D as a whole?), so if we could throw in a half-baked D3D11 state tracker too, then port it to Windows, I feel we would get a lot more attention.

If it brought in enough of the right devs, we could advance Mesa and it's drivers much faster, and to a much better state. If it gets working really well on Windows as well as Linux, maybe Intel and AMD can ditch their proprietary drivers on at least these two platforms and finally commit 100% to FOSS drivers

The ultimate goal is adoption by users, of course, even if the companies don't exactly take on 100%... The day Gamers start choosing Mesa drivers no matter what OS they're on is a beautiful day indeed.

[droste]

I see a few flaws in the idea, the main one is: Why would any windows user switch to mesa? Where's the advantage for them?

And:
There is/was a D3D 10/11 gallium state tracker http://www.phoronix.com/scan.php?pag...3d_d3d11&num=1

[ChrisXY]

At first, nobody of course. But it's rapidly going near the performance of catalyst in opengl on linux, so it soon could actually be possible to use it for many games.

The point is that people do not only complain about catalyst on linux, they also complain about driver quality on windows. Apparently it has gotten better the last few years, but apparently there are still often problems with it.

Mesa would have the real advantage that people could actually get their bugs fixed instead of hoping amd will fix catalyst after the next 3 releases. It could become a "de facto" reference implementation for at least opengl on all mainstream operating systems.

[curaga]

Why exactly should linux devs care about Windows porting and Windows bugs?

By all means, if you want to do so, patches welcome, but you can't expect anyone to give Windows users the same attention their main platform gets.

[Daktyl198]

I see a few flaws in the idea, the main one is: Why would any windows user switch to mesa? Where's the advantage for them?

As ChrisXY said, the quality of some *cough*Intel/AMD*cough* drivers on Windows leaves much to be desired. If the Mesa drivers can reach near-proprietary speeds on Windows, but be stabler and easier to work with than the proprietary drivers, the obvious choice would be Mesa, no?

And:
There is/was a D3D 10/11 gallium state tracker http://www.phoronix.com/scan.php?pag...3d_d3d11&num=1

Oh... Awesome! Most of the work is done then!!

[tarceri]

maybe Intel and AMD can ditch their proprietary drivers on at least these two platforms and finally commit 100% to FOSS drivers

Intel would need to switch to Gallium first and there is no sign they want to do this. Actually it would be more interesting to see this happen than any windows driver effort as there are some easy cpu performance gains to be had by getting rid of classic driver support and switching Mesa to become just a state tracker for gallium. Currently there is wasted cpu converting back and forth between mesa and gallium formats I've seen around 2% of cpu time spent in switch statements alone. It likely there are many other places that could be improved by making Mesa a state tracker.

[droste]

If the Mesa drivers can reach near-proprietary speeds on Windows, but be stabler and easier to work with than the proprietary drivers, the obvious choice would be Mesa, no?

How would you do this? They are not even near proprietary speeds on linux and someone would have to "port" the kernel parts to the windows kernel (it would probably mean rewrite, as I highly doubt that the current linux kernel code is in any way compatible with the recent microsoft ones).
And _who_ would be doing this? The few people currently working on this? I don't like to see the low man power wasted on windows kernel stuff that wouldn't help the linux part.
The "easy" stuff of mesa is already working on windows (softpipe, llvmpipe, osmesa(?)) the hard part are the drivers where you have to interact with the kernel.

I wouldn't mind if someone who would otherwise not contribute to mesa brings some patches around to actually make this happen, but I don't think that will happen... ever

Lets just make mesa on linux stable and fast enough that nobody has to use windows

[Daktyl198]

How would you do this? They are not even near proprietary speeds on linux and someone would have to "port" the kernel parts to the windows kernel (it would probably mean rewrite, as I highly doubt that the current linux kernel code is in any way compatible with the recent microsoft ones).
And _who_ would be doing this? The few people currently working on this? I don't like to see the low man power wasted on windows kernel stuff that wouldn't help the linux part.
The "easy" stuff of mesa is already working on windows (softpipe, llvmpipe, osmesa(?)) the hard part are the drivers where you have to interact with the kernel.

I wouldn't mind if someone who would otherwise not contribute to mesa brings some patches around to actually make this happen, but I don't think that will happen... ever

Lets just make mesa on linux stable and fast enough that nobody has to use windows

1.) You are right, they aren't quite proprietary speeds, but saying "not even near" is disregarding all of the current work going into Gallium to make it faster. It's gotten some significant performance boosts in the last few releases, and it only looks to get faster. Within the next year or two, I expect there to be a minimal difference between the two in terms of performance on non-7xxx+ cards. Also, interested Devs coming from Windows can boost all-around performance (OS abstractions ftw).

2.) Porting of the code to the Windows kernel could be done by AMD/Intel themselves, if not a curious 3rd party developer. Btw, afaik Mesa is one of the biggest FOSS collaboration efforts beneath the Kernel itself. It has, at least, two major companies backing it along with plenty of solo developers. "Low man power" isn't exactly the words I would use ^.^

3.) Porting of the kernel-facing code probably isn't as hard as you're making it out to be. Mesa already runs on non-Linux systems, and even an OS with only partial POSIX complience (Haiku), so it's not like Mesa is targeted specifically for the Linux kernel and will break on anything else...

As stated above, "Mesa on Linux" is a pointless statement since ~90% of Mesa is abstracted away from the OS; performance/stability boosts from Windows/BSD/Haiku OSes will for the most part benefit Linux as well.

[droidhacker]

Interesting idea.
BUT, I would much prefer not to pollute/bloat the code with unnecessary interfaces to support a DYING platform. Android outsells MS by a fairly significant margin. Android runs on Mesa for hardware supported by Mesa. That means that realistically, Mesa will shortly be getting much greater exposure withOUT adding in the MS bloat. On top of that, MS users are ***SOOOOOO*** non-technical, that they need very special instructions just to figure out what button to click on their mouse -- after all, why do you think apple mouse only has 1 button? Don't expect Mesa to get anywhere with that crowd.

[Luke_Wolf]

Interesting idea.
BUT, I would much prefer not to pollute/bloat the code with unnecessary interfaces to support a DYING platform. Android outsells MS by a fairly significant margin. Android runs on Mesa for hardware supported by Mesa. That means that realistically, Mesa will shortly be getting much greater exposure withOUT adding in the MS bloat. On top of that, MS users are ***SOOOOOO*** non-technical, that they need very special instructions just to figure out what button to click on their mouse -- after all, why do you think apple mouse only has 1 button? Don't expect Mesa to get anywhere with that crowd.

I like how you talk about Microsoft users and then bring up the APPLE mouse as if APPLE has anything to do with people who use Microsoft products.