Concerns Over Merging Drivers Back Into The X Server

[daniels]

when i said 'humour me', i didn't mean it literally ...

[libv]

Thats because I just picked random driver changelogs from google to show the fact that lots of stuff gets backported by us, are you actually going to argue you know more about the work I do that I do? Oh you are? your psychic powers would make you a lot of money on chatlines, I don't think your logic is as impeccable as you personally seem to think.

Like even someone with any reasonable ability to logically reason would be able to find,

http://rpm.pbone.net/index.php3/stat/22/idpl/12958163/com/changelog.html

Evergreen support isn't released in RHEL 5.5, as it wasn't there upstream on time, but is on the roadmap for future RHEL5.

So can you admit you have no clue what you are talking about? go on it'll be liberating for you to admit you were completely fucking wrong about something and maybe at some level you are just deluding yourself into believe you have an actual logical world view, and would seek help from some professionals. Otherwise I fear for your future with the tinfoil hats and the aliens probes.

Dave.

Aha, once you unpack this src-rpm, you notice that while the src.rpm is labelled 6.3.3 it actually contains, next to the actual 6.3.3 tarball, a 6.12.2 to support r500 and above. After a "Ah! look! Actual backporting!"-moment, one funny thought immediately crept into my mind: "Why was the separate radeonhd driver for r500 and above bad again?".

So yes, you did do backporting for your enterprise product in april 2009, together with some maintenance in the run-up to RHEL 5.4.

But the fact remains that you do only an extremely limited amount of backporting. You did not, for instance, update this driver for RHEL 5.5, which happened almost a year after your 6.12 backport.

The reality is, you do very little backporting, you do very little desktop maintenance. Redhat desktop developers do close to upstream work (with fedora), and little enterprise desktop work (as they mostly only have a server product to sell). This is why redhat manages to spend that much time on upstream code, even though the manpower they have is comparable to canonical and suse (well, easily outstripping suse thanks to some novell stupidity), and those two barely manage to do anything upstream.

Redhat has a different business model, and while that is ok for redhat, it does not give you the right to state that "We manage just fine with backporting drivers all the time" when companies with an actual enterprise desktop strategy whine about their inability to provide timely and solid driver updates due to upstream driver development strategies.

As for your last statements, keep it up.

[airlied]

Aha, once you unpack this src-rpm, you notice that while the src.rpm is labelled 6.3.3 it actually contains, next to the actual 6.3.3 tarball, a 6.12.2 to support r500 and above. After a "Ah! look! Actual backporting!"-moment, one funny thought immediately crept into my mind: "Why was the separate radeonhd driver for r500 and above bad again?".

So yes, you did do backporting for your enterprise product in april 2009, together with some maintenance in the run-up to RHEL 5.4.

But the fact remains that you do only an extremely limited amount of backporting. You did not, for instance, update this driver for RHEL 5.5, which happened almost a year after your 6.12 backport.

The reality is, you do very little backporting, you do very little desktop maintenance. Redhat desktop developers do close to upstream work (with fedora), and little enterprise desktop work (as they mostly only have a server product to sell). This is why redhat manages to spend that much time on upstream code, even though the manpower they have is comparable to canonical and suse (well, easily outstripping suse thanks to some novell stupidity), and those two barely manage to do anything upstream.

Redhat has a different business model, and while that is ok for redhat, it does not give you the right to state that "We manage just fine with backporting drivers all the time" when companies with an actual enterprise desktop strategy whine about their inability to provide timely and solid driver updates due to upstream driver development strategies.

As for your last statements, keep it up.

So RHEL is an enterprise distro, we make a point of only fixing bugs in it that are reported by users of it. This is what they pay us for, they don't want misc randomness, they want directed fixes. So for example for RHEL5.5 we had a limit on how many bugs we could fix and none of the -ati bugs necessitated a major backport. For RHEL5.6 there is a chance that 6.13.x will end up becoming the r500 driver.

When I originally backported "r500" it had acceleration support and used atombios to support more hardware, radeonhd had neither of these at the time, hence why I wrote a blogpost explaining it all.

I also wonder how you claim to know what my involvement with AMD/ATI was when this whole thing started, its wierd that 3 hour phone call with JB must have been my imagination, something that happened 2 months prior to my starting at Red Hat. Post my starting at Red Hat as I blog posted a long time ago, RH/AMD took their time sorting out my previous NDA issues. Also if I wasn't involved why was the XDC symbolic CD handover from Matthew Tippett to me and not you?

Luc, you need to start picking points and working on them, instead of as Daniels pointed out, going all conspiracy nuts. Generally we don't like you but not due to your technical ability, just because you come across like an arrogant prick without the backing of producing anything useful to users as opposed to Luc's play grounds.

Dave.

[airlied]

Though I can see why a conspiracy against you appeals to you so much.

Its a way to blame others for things failing. Its always easier to say the whole of X.org/Mesa is against me rather than saying maybe I was wrong and accepting it and learning from it.

Like here's the thing the response to your DRI SDK was quite broad, Ian, Nicolai and Keithw all responded to you, are they all part of the "usual suspects" or are they newer members that just joined up by disagreeing with you? Can you enumerate who exactly are "usual" and who are "unusual" suspects instead of muttering in the corner.

Dave.

[airlied]

Well, zoom back to september 2007, XDS cambridge, where egbert and i spent most of our time in the hotel churning out tons of code. We had presented a pre-release version of the radeonhd driver on the last day, and we explained how we wanted radeonhd to be a driver that was both suited to enterprise desktop and upstream users. Keith gave us a chuckle and a smear when he realised that we supported SLED 9 (xorg 6.8 or 6.9) and not the oldest supported RHEL, only to see this answered by me, honestly and directly, that we would be happy to support that too, as it mostly would be down to actually trying to build rhd on that rhel version. Dave also served us with a nice one, where he claimed loudly and trumpingly that he could support the same hardware with just 1.500lines of C instead of our 15.000 (at the time). Even ignoring body language and general behaviour of many people, let's just say that the atmosphere was not very supportive.

But, that same evening this picture was taken: http://www.flickr.com/photos/cysglyd...7606349243442/ Together with the behaviour of our technology partner ATI, Dave's blog entry where he (rather falsely) claimed to be heavily involved with the whole, and the creation of the #radeon irc channel and the revival of the [email protected] list to match radeonhd, one doesn't need to be a conspiracy theorist to see that something was afoot.

Ah the smoking gun, that was a good night, though kylem, jbarnes and sladen are the only ones with pimms in-photo. I don't think many people in that picture had ever met before XDC2007, it was definitely the first time I met JB/meep/Alex in real life. I actually can't remember how we all ended up in daf/mjg59s house that night. but it wasn't a planned meeting or anything, just a group of people with a lot of pimms. I do remember getting a lift to Heathrow from Meep/JB the next day with a hangover.

Dave.

[dfx.]

I doubt Gentoo users like me will care if they have to compile the whole of xorg-server if it means more frequent and hopefully stable releases

you doubt vainly - i Gentoo user and i mind, for example.

and i pretty sure they will be frequent (will be a necessity) but stable - no way (on contrary it means that frequent serious changes are inescapable)

[libv]

So RHEL is an enterprise distro, we make a point of only fixing bugs in it that are reported by users of it. This is what they pay us for, they don't want misc randomness, they want directed fixes. So for example for RHEL5.5 we had a limit on how many bugs we could fix and none of the -ati bugs necessitated a major backport. For RHEL5.6 there is a chance that 6.13.x will end up becoming the r500 driver.

But since your company is not really backing an enterprise desktop, the amount of bugs you are supposed to fix are that small. You do not have the same needs as real desktop vendors do, change your story accordingly, as your big claims are ridiculous, and, apart from the satisfaction you get from making another big claim for yourself, it only serves to silence those people who do need backwards compatible code.

When I originally backported "r500" it had acceleration support and used atombios to support more hardware, radeonhd had neither of these at the time, hence why I wrote a blogpost explaining it all.

Atombios was such a nice stick for Bridgman to bash us with, well, until the point where egbert went for more complete atombios dependance. We were already doing more than fglrx at the time, as we preferred ASICInit over int10, and fglrx on linux just ran the int10 bios. Once egbert increased the atombios dependance, another stick was quickly found.

Now, the whole political mix means that you, generalised redhat (this was shortly after the now mostly forgotten XGL/AIGLX mess), alex and bridgman found themselves immediately in creating a competing driver. Take into account the time spent on getting the modesetting going properly (even with all the knowledge you could readily take from radeonhd), and then it wasn't quicker or more adept solution than just porting dri init and 2d acceleration to radeonhd. It was preferred by you guys, yes.

I also wonder how you claim to know what my involvement with AMD/ATI was when this whole thing started, its wierd that 3 hour phone call with JB must have been my imagination, something that happened 2 months prior to my starting at Red Hat. Post my starting at Red Hat as I blog posted a long time ago, RH/AMD took their time sorting out my previous NDA issues. Also if I wasn't involved why was the XDC symbolic CD handover from Matthew Tippett to me and not you?

This puts it in june 2007. At which point you only talked to bridgman and no-one else. At around the same time we were given a nice budget from AMD to go and pick up whatever graphics cards we thought we needed for the bring-up in the next few months that were in the market at that time. Our proposal had traveled far and wide within SuSE, Novell, AMD and ATI by then, and AMD told us at the time they were still working out the last niggles before we were officially tasked with the work.

The CD, well... This was not the only thing that made a lot of people frown about ATI/AMD behaviour in this game, and not the worst either. Still many orders of magnitude less than what had been happening in what became or was "the other side".

None of this warranted your noisy "ME!!!!" post with http://airlied.livejournal.com/2007/09/07/

Luc, you need to start picking points and working on them, instead of as Daniels pointed out, going all conspiracy nuts. Generally we don't like you but not due to your technical ability, just because you come across like an arrogant prick without the backing of producing anything useful to users as opposed to Luc's play grounds.

Dave, where in our history have you not gone and peed against every tree you could spot, and barking loudly when someone had peed against it before? Whatever major change i have done, you've often had to first trash it, then reinvent it badly and then make a ton of noise.

If what i do can now be deemed playing grounds, then you've played a capital part in making that so, by reinventing things (shabbily) several times.

Also, some of the things i do are proving that the impossible is really very possible. If you're into producing solid code and solid drivers, then yes, you can only do so in a playing ground.

radeon is a playing ground to you and always has been. The bling features, the noise, the fact that you were not stuck with partner communication and synchronisation, the fact that you mostly get paid to do anything that makes noise anyway, the fact that it is also alex his playing ground and he has access to the necessary info, and that Bridgman apparently has been quite keen on you from the start (we raised many an eyebrow on what were supposed to be technical calls in july already), all made radeon more than just a playing ground. Definitely not something that is aimed at being long term supportable and maintainable.

As for the rest, well, no doubt you'll be trying to use that as an excuse for your NIHs of the future.

[libv]

Though I can see why a conspiracy against you appeals to you so much.

Its a way to blame others for things failing. Its always easier to say the whole of X.org/Mesa is against me rather than saying maybe I was wrong and accepting it and learning from it.

Have i ever stated so? No. That's just the image that you are working hard on creating.

What i have stated is that i noticed a group mechanism working against me. My insights get trashed because it doesn't suit people yet, for whatever personal or political reason, later my ideas get re-invented, without reparation or attribution, and people will only remember me being the whiny git who got trashed by, what in peoples minds becomes, everyone else. Next time round, trashing is easier because of people remembering just that.

Add to that that i work against people's games, and i often provide insights which are wholly unsuited to many personal and political directions, and prove what people blanket-bomb as "impossible" possible, and then the amount of trashing becomes rather sizable.

I never claimed anything beyond this. You do so though, but then you trashed and re-invented quite a few things already.

Like here's the thing the response to your DRI SDK was quite broad, Ian, Nicolai and Keithw all responded to you, are they all part of the "usual suspects" or are they newer members that just joined up by disagreeing with you? Can you enumerate who exactly are "usual" and who are "unusual" suspects instead of muttering in the corner.

Dave.

Now, about the DRI SDK, it proves that it is possible to have some form of an API for external drivers. Which then suggests that in future, there needs to be a more formal API, and developers need to spend some more time in doing decent API transitions instead of wanton changes.

This is the primary reason for people being against this. It might add work, and it definitely changes peoples mode of working, but the same people fail to accept that this mode of working has advantages which will more than make up for the slight bit of extra labour.

People still refuse to see that this is what the desktop needs.

And this includes you, and your loud claims that redhat manages just fine without it.

Intel Portland is a special case. They have been fighting off their own management, their Shanghai team, and quite a lot of their customers on backwards compatibility and maintainability over the past few years (this is of course also a generalization, the individual members of the team are of course differing). Suddenly what they always claimed as "impossible" is possible, and when so much political capital has been riding on that, it does pose a bit of a problem.