Mir Support Not Merged For Mesa 9.2

[mrugiero]

You mention the closed source drivers should be equal to windows, this is not the case. I can atest to trying 3 flavours of AMD GPU from low end 4 series Southbridge, a 5 series high end and a new A10-5800k. I have used quite a few different distros and all DE's I know of (so thats KDE, XFCE, Unity, Cinnamon, MATE) and the performance is way behind Windows. All the installations were fresh and upto date and run for a number of months (often breaking with Mesa updates) the used from the 12 to the current 13.6 driver sets both beta and non beta.

The only thing that comes to mind is that maybe your desktop is not bypassing compositing. When I used the closed drivers, I achieved the same performance than in Windows with AMD. I don't use NVIDIA (my brother does, though), but I hear the same is supposed to happen with their driver.

my experience is that the frame rate and consisentcy of frame rate of MOST BUT NOT ALL games through Steam, Desura and standalone has varied and I dont mean per title aI literally mean per second (so 5,12,60,80,12,25,35,36,36,48, etc..) I have messed with Vsync on KDE , AMD's tear free options, AMD's Vsync options, Game Vsync options etc..

Now some of this is down to poor ports of games with bad opengl implementation (killing floor) but mostly it would seem there is some GPU clocking issue or Refresh issue as the frame rates can be very high at times ?

I'm not a hardcore gamer, so this kind of things are not my main strength, but the OpenGL argument makes sense. You should try the game on Windows with OpenGL to make sure if that is the cause.

My hope is that the problems will go away when Weyland and Mir is here due to better management of drawing video as I suspect the complexities of X are getting in the way of game rendering (again im a noob so this may not be the case)

As long as you are using compositing bypassing, I wouldn't expect big differences in fullscreen apps performance, and that includes most games.

a quick example = CS:source which can run at 120+ FPS on windows yet runs about 70-75fps on linux? all closed source drivers. So most people wont notice because their refresh is 60hz on the monitor. TF2 is only around 30fps-40fps but again this is upwards of 80fps on windows. Same drivers as windows as on linux (in version at least)

Again, I'm no hardcore gamer, it's pretty much out of my expertise area. However, might have something to do with game specific optimizations on the drivers? I'd look for a changelog. If that's the cause, it's likely to improve with time, now that this games are becoming more usual on Linux.

So i would say no, the performance is knowhere near to windows with closed source. Of course im excited for Mesa 9.2 and Kernal 3.11 to merge and then i shall try the opensource drivers..

which finally leads to my point.. opensource drivers are fantastic on the desktop! they beat out the closed source for stability and smoothness.

The open source drivers are not likely to have better performance than the closed source ones, it's usually the other way around (there are huge improvements on the releases you name, anyway).
I agree on stability, smoothness and don't messing your system, that's why I use them. But in performance, they're currently losing most of the time (there are cases, specially on older hardware, where the open source drivers have better performance than the closed ones).

[ForkedPython]

If you are using the closed drivers, you should get around the same performance, little bit better, little bit worse.

Will it? There's no way to know for sure. I think it might, but I heard they rely on SDL for all the window management related stuff (not sure if it's that way, though), and if it is that way, as long as it's supported on both Mir and Wayland (Wayland support is on the way, and Mir support will likely happen if not on upstream, with out of tree patches) it won't change anything for Valve. As for latency and such, I think both Mir and Wayland are supposed to be non intrusive, so it shouldn't affect as long as they do no hackish fixes to code for one and later make it run on the other.

Again, there's no way to know for sure. I doubt Valve will use Mir on their console, because that would imply they either need to code for a custom compositor or use Unity, and the first is unneeded work and the latter I think is not really what you want in a console. If I have to guess, for now they'll stick to X.org because they did the port recently and switching now could make porting to X.org seem like a wasted effort. But it's all speculation. Valve didn't make any claims on the subject, and supporting Ubuntu might just be a convenience, and if it starts implying more work, it stops being such a convenience.
/*EDIT: I'm not sure if I was clear as of why I mentioned the console, so I'll clarify it now; I mention it because I think that's their priority on porting to Linux, more than the desktop market share, so they will keep things the way it's easier for them to get the console out */

As for fitting, X.org fits almost everywhere, and has been used on phones even. It's not that.
The problems with X are a lot, I'll just list the ones that come to mind, but they're all related to being designed when computers were a completely different thing than what they are now.

One of the problems is that it should be backwards compatible with software written in another era.
Another is that, for some reason I don't quite remember, enabling a tear free desktop implies breaking support for such old software.
Other problem is everything related to input handling, event management, etc.
Basically, it gets too much in the way. Here is a very complete article from not too long ago on the differences between Wayland and X.org, I think you should read it.


No question is dumb, only answers can be dumb. And the previous one can contain silly errors, BTW, I don't quite remember most of the problems with X, aside of doing a lot of things it doesn't need to do by today.

Thanks for the replies mrugiero. I have to wonder if the problems with VSYNC that crop up between games are Due to X ?

You mention the closed source drivers should be equal to windows, this is not the case. I can atest to trying 3 flavours of AMD GPU from low end 4 series Southbridge, a 5 series high end and a new A10-5800k. I have used quite a few different distros and all DE's I know of (so thats KDE, XFCE, Unity, Cinnamon, MATE) and the performance is way behind Windows. All the installations were fresh and upto date and run for a number of months (often breaking with Mesa updates) the used from the 12 to the current 13.6 driver sets both beta and non beta.

my experience is that the frame rate and consisentcy of frame rate of MOST BUT NOT ALL games through Steam, Desura and standalone has varied and I dont mean per title aI literally mean per second (so 5,12,60,80,12,25,35,36,36,48, etc..) I have messed with Vsync on KDE , AMD's tear free options, AMD's Vsync options, Game Vsync options etc..

Now some of this is down to poor ports of games with bad opengl implementation (killing floor) but mostly it would seem there is some GPU clocking issue or Refresh issue as the frame rates can be very high at times ?

My hope is that the problems will go away when Weyland and Mir is here due to better management of drawing video as I suspect the complexities of X are getting in the way of game rendering (again im a noob so this may not be the case)

a quick example = CS:source which can run at 120+ FPS on windows yet runs about 70-75fps on linux? all closed source drivers. So most people wont notice because their refresh is 60hz on the monitor. TF2 is only around 30fps-40fps but again this is upwards of 80fps on windows. Same drivers as windows as on linux (in version at least)

So i would say no, the performance is knowhere near to windows with closed source. Of course im excited for Mesa 9.2 and Kernal 3.11 to merge and then i shall try the opensource drivers..

which finally leads to my point.. opensource drivers are fantastic on the desktop! they beat out the closed source for stability and smoothness.

[mrugiero]

I am a gamer who can now game quite well on Linux through desura and steam (also games that don’t require a DRM browser ) however i crave more performance, right now both my A10-5800k & my AMD 5850 should really be pulling double the frame rate (as within windows (and the rest)) but given the type of simple source games and the relative power of my hardware 30-40fps is OK and on some older source games 60fps is doable (where it would be 150 and more on windows). But as you have guessed i am an early adopter and have moved away from windows 7. The experience is not always smooth and im starting to wonder how games will fare that are a bit more hardcore (( DID ANYONE SEE THE JOB ADVERT FOR A CRYTEK, CRYSIS 3 LINUX DEV ?))

If you are using the closed drivers, you should get around the same performance, little bit better, little bit worse.

So the questions:

1. Will all of this Wayland / MIR stuff get in the way of gaming on Linux? Politically, will it hinder the confidence of Valve and other game devs to commit i.e will you install DOTA2 on Ubuntu get 100fps and then need some conversion that reduces FPS or increases frame latency to work on Weyland.

Will it? There's no way to know for sure. I think it might, but I heard they rely on SDL for all the window management related stuff (not sure if it's that way, though), and if it is that way, as long as it's supported on both Mir and Wayland (Wayland support is on the way, and Mir support will likely happen if not on upstream, with out of tree patches) it won't change anything for Valve. As for latency and such, I think both Mir and Wayland are supposed to be non intrusive, so it shouldn't affect as long as they do no hackish fixes to code for one and later make it run on the other.

2. Firstly, X is here for a while longer i guess as the dust needs to settle but if STEAM is officially supported on 13.04 Ubuntu then one would assume games will be ported and tested for MIR in future. Will Weyland games run as fast as MIR ? Will people who want to game on Linux be forced to use Ubuntu ?

Again, there's no way to know for sure. I doubt Valve will use Mir on their console, because that would imply they either need to code for a custom compositor or use Unity, and the first is unneeded work and the latter I think is not really what you want in a console. If I have to guess, for now they'll stick to X.org because they did the port recently and switching now could make porting to X.org seem like a wasted effort. But it's all speculation. Valve didn't make any claims on the subject, and supporting Ubuntu might just be a convenience, and if it starts implying more work, it stops being such a convenience.
/*EDIT: I'm not sure if I was clear as of why I mentioned the console, so I'll clarify it now; I mention it because I think that's their priority on porting to Linux, more than the desktop market share, so they will keep things the way it's easier for them to get the console out */

3. What is wrong with X ? it seems like only the actual open source drivers and mesa improvements hold performance back from reaching windows standards? If its because X doesn’t fit tablets, cars then why should I care I want a desktop environment?

As for fitting, X.org fits almost everywhere, and has been used on phones even. It's not that.
The problems with X are a lot, I'll just list the ones that come to mind, but they're all related to being designed when computers were a completely different thing than what they are now.

One of the problems is that it should be backwards compatible with software written in another era.
Another is that, for some reason I don't quite remember, enabling a tear free desktop implies breaking support for such old software.
Other problem is everything related to input handling, event management, etc.
Basically, it gets too much in the way. Here is a very complete article from not too long ago on the differences between Wayland and X.org, I think you should read it.

Sorry for my dumb questions

No question is dumb, only answers can be dumb. And the previous one can contain silly errors, BTW, I don't quite remember most of the problems with X, aside of doing a lot of things it doesn't need to do by today.

[ForkedPython]

sorry to derp into this thread, don?t understand this window manager stuff. I have questions though..

background:
I am a gamer who can now game quite well on Linux through desura and steam (also games that don?t require a DRM browser ) however i crave more performance, right now both my A10-5800k & my AMD 5850 should really be pulling double the frame rate (as within windows (and the rest)) but given the type of simple source games and the relative power of my hardware 30-40fps is OK and on some older source games 60fps is doable (where it would be 150 and more on windows). But as you have guessed i am an early adopter and have moved away from windows 7. The experience is not always smooth and im starting to wonder how games will fare that are a bit more hardcore (( DID ANYONE SEE THE JOB ADVERT FOR A CRYTEK, CRYSIS 3 LINUX DEV ?))

So the questions:

1. Will all of this Wayland / MIR stuff get in the way of gaming on Linux? Politically, will it hinder the confidence of Valve and other game devs to commit i.e will you install DOTA2 on Ubuntu get 100fps and then need some conversion that reduces FPS or increases frame latency to work on Weyland.

2. Firstly, X is here for a while longer i guess as the dust needs to settle but if STEAM is officially supported on 13.04 Ubuntu then one would assume games will be ported and tested for MIR in future. Will Weyland games run as fast as MIR ? Will people who want to game on Linux be forced to use Ubuntu ?

3. What is wrong with X ? it seems like only the actual open source drivers and mesa improvements hold performance back from reaching windows standards? If its because X doesn?t fit tablets, cars then why should I care I want a desktop environment?


Sorry for my dumb questions

[LinuxGamer]

Correct me if I'm wrong, but:
Kristian H?gsberg, one of the developers of Wayland, one of the developers/maintainers of X-server, employed by Intel, which is very active in the development of Mesa, Daniel Stone, developer/maintainer of input-systems in both X-server and Wayland, and most others that was wrapping/fixing/supporting X-server, seems to have a hand in Wayland.

It seems to me, that these people are infinitely more qualified to make a successer to X, not to mention making a functional X compatibility-layer, than any other group.
I'd say that Wayland is the safe bet.

yes alot of the Developer's of Wayland are or was Xorg Maintainer's, or Kernel Maintainer's, or Mesa Maintainer's, and, Wayland is being Developed by high Standard's as well,

[UraniumDeer]

Correct me if I'm wrong, but:
Kristian H?gsberg, one of the developers of Wayland, one of the developers/maintainers of X-server, employed by Intel, which is very active in the development of Mesa, Daniel Stone, developer/maintainer of input-systems in both X-server and Wayland, and most others that was wrapping/fixing/supporting X-server, seems to have a hand in Wayland.

It seems to me, that these people are infinitely more qualified to make a successer to X, not to mention making a functional X compatibility-layer, than any other group.
I'd say that Wayland is the safe bet.

[jrch2k8]

IIRC, for OpenCL there is work in progress for mesa to use it without a display system, if it isn't ready yet.

well as far as i know Opencl don't require display system to be loaded and the backend should be automatically choosed once the kernels try to execute but im not 100% sure

[mrugiero]

1.) Sure about servers your are right even though the work in Opencl will benefit them later but Redhat is the bigger desktop Distro, ok sure Ubuntu has a good number of users but most are regular users with cheap hardware and as canonical red numbers shows not too eager to spend money on it now Redhat certainly have less of this kind of users but is King in the enterprise grade users as Redhat massive[check TOP 500] incoming shows are very eager to spend money on it and they buy the kind of hardware that make nVidia/AMD/intel/etc happy in the pants[or did you think AMD is working for r600g because we the massive 1% market with 100$ cards were claiming it? nope, it were several big fat pockets RedHat clients that want better integration and stability for their open platforms] and Redhat understood many years ago that is smarter to support and contribute[money,devs,etc] the community from the sidelines than push your way alone and make them mad.

IIRC, for OpenCL there is work in progress for mesa to use it without a display system, if it isn't ready yet.

[jrch2k8]

1) Servers do not need that much in terms of X.org/Wayland/Mir. So servers do not impose much requirements on those. Phones are dominated by Android with its own stack. X.org wont be there. Wayland could go there. Mir come from there. But as for now, neither have any significant presence there. So we end up with desktop users. Here Ubuntu is the king.

2) Here is funny thing. Mesa delivers OpenGL (and other API's) to the LINUX. NOT LINUX BUT MIR. NOT LINUX WHEN XORG OR WAYLAND*. So here goes 1). Should Mesa dev team cut out large portion of Linux users, because they are not interested in supporting them?

3) Its responsibility of code "submitter" to care about submitted code. Why Wayland folks want their code in upstream Mesa? To forget about it the minute they submit it? Come one. Idea of upstream coop is to work TOGETHER. Frome where come this idea that it MUST be "abandon as soon as its upstreamed". And again. Do you sugest that Canonical WONT care about CRITICALLY IMPORTANT bugs for their MIR stack? (As in: "Wow, Mir wont work on new Mesa.. But that's ok. We do not care. Lets Mesa folks sort it out.... 3 months letter. Wow Mesa folks still didn't fixed it. .... 3y letter. Wow those bugs still there? ..." That is strange notion you have here. Mesa integration is MUST have for Mir. So canonical have all the reasons to care about that code).

4) Quantify "large code base". And quantify work needed to be done by Mesa contributors who will not work for Canonical nor for MIR. AFTER you have those two data points, lets talk about maintainance burden. (Yes. If burden is hight and Canonical shoulder it on their own upstream its OK. So You NEED to make the distinction of work that could be done by Canonical, and on which could not be..)

And Mesa already was modified for Wayland. Same will happen for Mir. Exactly paraler situations. Same reqirements for each code authrs from the stand point of Mesa core team. Only trash talking about Canonical, and assumption of best possible perf. on behalf of Wayland authors.

* At least Intel is working on Mesa + Android.

1.) Sure about servers your are right even though the work in Opencl will benefit them later but Redhat is the bigger desktop Distro, ok sure Ubuntu has a good number of users but most are regular users with cheap hardware and as canonical red numbers shows not too eager to spend money on it now Redhat certainly have less of this kind of users but is King in the enterprise grade users as Redhat massive[check TOP 500] incoming shows are very eager to spend money on it and they buy the kind of hardware that make nVidia/AMD/intel/etc happy in the pants[or did you think AMD is working for r600g because we the massive 1% market with 100$ cards were claiming it? nope, it were several big fat pockets RedHat clients that want better integration and stability for their open platforms] and Redhat understood many years ago that is smarter to support and contribute[money,devs,etc] the community from the sidelines than push your way alone and make them mad.

2.) that is the beauty of linux you can choose another distro if you are not happy with your current or the team handling it can keep up and this is 100% canonical fault[worst management i've ever seen btw] and Mesa devs are in all their right to, after all canonical for who knows what reason[beyond our own "server-compositor-thingy"] choosed completely on their free will to force a project that was not consulted[or supported] with/by anyone and mostly duplicate[or ripoff] the effort of years the community has put in the entire stack to make this actually possible without ever even try to talk to this developers to find a way to include their needs and posting FUD later because not 1 engineer in canonical was able to read wayland code and crosscheck the facts.

3.) Canonical has a LARRGGGE trail of dead unmaintained projects along the road and the ones that has survived is because they are forced into ubuntu[upstart/unity/bazaar] and even so unity has a different codebase every release, so why a mesa dev will believe Mir will be different? in the enterprise who you think will take the risk into adopt a technology supported by 1 company[they would go back windows for that] that never posted green numbers?. Technically speaking if tomorrow DRI3000 land in mesa and this force for example to rewrite entirely the EGL stack, do canonical have the know how to adapt it, when is public they can't even pass mesa QA for upstream patches? what if tomorrow canonical say "hey, lets keep Mir for mobile and make unity 9 run on wayland because we expect more money to come from mobile sector with less burden"?, a mesa dev have to take the job of remove all that code for no reason to keep the codebase clean, etc ,etc ,etc. This is why the 1 distro policy exists and normally distro maintainers are contributors to projects[especially debian, gentoo and arch] except canonical.

4.) you assume i upstream 1 line of code, it will work forever unless i make a boo boo and generate a bug myself and that i will or not fix it, that is utterly false, the issue here is not the code size Mir takes but the subsystems it touches and need but those are 3rd party to canonical, so if i upload[community dev not mesa official dev] a new required extension for EGL i will upload a wayland patch with it[or another dev that has been working with me along the life of the implementation or the code reviewers, etc] but i will break upstream compilation since the Mir module will cease to compile cleanly[i changed an internal struct to allow a feature in this extension of mine] and i don't use or care about Mir after all i don't use ubuntu, so mesa maintainer have 3 choices:

a.) remove from Makefiles the build of Mir modules and try to contact canonical to inform them it stop compiling and re enable once fixed[but since canonical don't interact with anybody could be fast or risk fail the merge window].
b.) remove my patch that implement a needed feature <-- this is less likely after all maintainers are made for this
c.) try to find someone willing and that uses ubuntu to backtrack the fix[normally is not as simple as just fix a type]

you are wrong mesa was not modified to accomodate wayland, wayland is the goal for which the entire linux graphic stack was/is been rewritten almost from scratch from kernel side all the way to mesa all over this years[where canonical put 0 LoC btw] and again no, even if Wayland and Mir use EGL their internals and concepts are different enough to make it non exactly trivial that again is canonical's fault as they did with wayland they never even tried to contact the EGL team or mesa team or anyone related to propose their ideas or possible features at all.

And no Valve don't have enough punch or features yet to make canonical even close to apple marketshare for at least 2 more years, certainly is a very good help and will help linux in general[steam runs fine in arch/gentoo/etc] but is not a miraculous divine event and their true target is bigpicture/steambox not be ubuntu exclusive

[mrugiero]

1) Ubuntu is single BIGGEST Linux distro. Lets talk about REAL Linux users affected. Shall we? (Or maybe for some unfanthomable reason will we start to exclude Linux users?)

Nobody has really reliable data to prove that or the opposite, so let's not make such claims.
As for the matter of Mir, Canonical should care about their users first, some of the ones who use Ubuntu-flavor are close to mine, and switched with my help to it, and I wouldn't like them suffering because of their stupid idea of running the desktop on XMir. They use it for academic purposes and for their works, they can't be bothered by that joke. I wouldn't be affected in 13.10, since I use Xubuntu, and I'm only testing on another box to avoid making unfunded claims and to ease that burden from my friends.

2) You suggest that no Mesa folk use Ubuntu as development environment? ITS NOT CANONICAL WHO ONLY USE UBUNTU. Its large distro. Perfectly capable to host development of kernel/mesa/xorg (for now). After Mir will be only thing maintained by Canonical, than devs will need to compile & install kernel/mesa/xorg/wayland on their own. But that IS WHAT THEY DO NOW. Since developing always involve working on bleeding edge.

No, he suggest that no mesa folk should use it just to test Canonical's things work. If they use it or not, should be because they like it or not. If you think any of mesa devs use Ubuntu, the charge of the proof is on you, I guess.

3) Are you suggesting that Canonical will push CRITICALLY IMPORTANT code for THEIR MIR EFFORT, and then will not care about bugs in that code? That they will then go and will stop maintining that code upstream, and will only provide downstream fixes? Right, because Canonicall devs all dream about wasting their time and effort on work that will be unneeded by anyone.

No, he's suggesting that Canonical will push critically important code for their Mir effort, and then expect upstream to maintain the code upstream, effectively releasing the burden from them, because that's one of the main reasons you'd have to expect code used only in your distro to go upstream. I don't think it would go that way, but they still have to make a compromise about that.

4) That only show problem within MESA development community. Is Mesa ONLY for specific distros? NO. (Go look at your 1) ) So why they refuse to work with people who have certain requirements for Mesa, and work with others who have very similar requirements? Technical reasons? (Beyound Your FUD)

If mesa has a politic on avoiding distro specific patches, it's enough to reject Mir patches at least until another distro states they will use Mir.
Technical reasons: see maintenance of code.
Also, your argument about being ONLY for specific distros? What? It's quite the opposite. In the other hand, they refusing to work on anything is their damn right. Accepting a patch is a whole different story, you really need a technical reason to not leverage the work of others on your code base, I agree, but to do the work themselves, they need a motivation, either Canonical paying or either them wanting because of reasons. Pretending they should 'because Canonical' is quite the attitude Canonical should start to avoid. They are working with people who has similar requirements because one is a distro specific, DE specific solution and the other is a common protocol everyone can use, and several distros already made plans to switch to that. Canonical did, even, and they didn't reject them when they were on the same boat.

[QUOTE=przemoli;342138]
2) Here is funny thing. Mesa delivers OpenGL (and other API's) to the LINUX. NOT LINUX BUT MIR. NOT LINUX WHEN XORG OR WAYLAND*. So here goes 1). Should Mesa dev team cut out large portion of Linux users, because they are not interested in supporting them?[QUOTE]
Actually, you are wrong. Mesa delivers OpenGL to X, and will do the same to Wayland. It uses kernel interfaces, yes, but is not Linux specific. As long as you have current DRI, you can use mesa, and FreeBSD does use it for some cards. And again, if people will argue that Canonical can do whatever best fit them, great for them. Mesa can do the same, and it's arguable that Mir fits them at all. Otherwise, Canonical supporters are having an ugly case of double standard.
The only one cutting out a large portion of Linux users anyway is Canonical, when they decided to go their own. If they are not able to support Mir by themselves, then they should have put more thought to it, because it was a predictable possibility.

3) Its responsibility of code "submitter" to care about submitted code. Why Wayland folks want their code in upstream Mesa? To forget about it the minute they submit it? Come one. Idea of upstream coop is to work TOGETHER. Frome where come this idea that it MUST be "abandon as soon as its upstreamed". And again. Do you sugest that Canonical WONT care about CRITICALLY IMPORTANT bugs for their MIR stack? (As in: "Wow, Mir wont work on new Mesa.. But that's ok. We do not care. Lets Mesa folks sort it out.... 3 months letter. Wow Mesa folks still didn't fixed it. .... 3y letter. Wow those bugs still there? ..." That is strange notion you have here. Mesa integration is MUST have for Mir. So canonical have all the reasons to care about that code).

Maybe you are right. But there will be no work together on something only them use, face it. Why would Red Hat people work on the Mir code base? They wouldn't. All of the other major distros sees Wayland as the next step, so they are likely to work together on it. See it this way. Since there are nobody else likely to work on the code for Mir, what will happen? Canonical will be the only one fixing its bugs. As they are on a schedule, they will probably merge their fixes downstream before it goes through the revisions on upstream. The only difference that makes for Canonical is a smaller patch to apply when they clone upstream in the next distro. As for mesa, they lose time on revisions that makes no difference to any user, and that have negligible benefit for Canonical. What's the point on being upstream, then?

4) Quantify "large code base". And quantify work needed to be done by Mesa contributors who will not work for Canonical nor for MIR. AFTER you have those two data points, lets talk about maintainance burden. (Yes. If burden is hight and Canonical shoulder it on their own upstream its OK. So You NEED to make the distinction of work that could be done by Canonical, and on which could not be..)

Canonical should weight those factors, I don't know how much manpower they have. But see above to see why is pointless to want upstream.

And Mesa already was modified for Wayland. Same will happen for Mir. Exactly paraler situations. Same reqirements for each code authrs from the stand point of Mesa core team. Only trash talking about Canonical, and assumption of best possible perf. on behalf of Wayland authors.

* At least Intel is working on Mesa + Android.

No, not exactly parallel situations, as explained. For Wayland, there are actually motivations to work together for different groups, so easing the maintenance burden on $COMPANY is not the only benefit, but actually there is a sharing of code. For Mir, Canonical is the only interested group so far.
And I wonder where you get from that mesa devs are talking trash about Canonical or assuming best possible performance from Wayland. I don't know of anyone asserting that Mir will have bad performance even in Phoronix, let alone mesa developers. Which will have almost surely a bad performance is a desktop under XMir, but obviously all of us who claim that are aware that the same would happen if someone tried to do the same with XWayland. The point is, nobody has been so stubbornly stupid to actually want this kind of solution aside from Canonical with XMir. Most concerns on Mir itself has nothing to do with performance.

Yep, Wayland is big. I wonder when the *BSD's will start looking into the Wayland protocol and start updating their kernel and graphics stacks to prepare for their Wayland implementations.

AFAIK, they are already on that task. They need to finish their DRI2 drivers (I believe Intel's was the only one complete). Is there any other requirement aside of DRI2 and KMS they don't meet?