No, AMD Will Not Be Opening Up Its Firmware/Microcode

[Amarildo]

Firmware files are pretty small. I wonder if it's too hard to do a "Clean Room" firmware based on de-compiled images.

[libv]

What can I say ? I told you the truth multiple times; you choose not to believe me so there's not much more I can do.

The problem is that you tended to be fairly single-minded in our discussions, to the extent that if I talked about something you disagreed with (like, say, KMS) it was like it never happened, so from your perspective you are probably telling the truth as well. I don't see that getting resolved without spending literally weeks trying to recreate every call and meeting, reminding each other of things they said that might trigger other recollections, and that doesn't seem like a good use of time or something that either of us would enjoy.

KMS is the worst possible example. KMS was a pretty bad heap of junk when Bornecrantzer created the header file (with some handholding help from the likes of airlied on how to style it). It was absolutely broken (we can only define the format/size of a cursor, since about 2 years), which is what one expects when the broken and badly tested randr1.2 headers gets poured into a kernel formatted header, at a time when even Randr1.2 was unable to tell anyone where modelines came from. Jesse did a first stab at a kms driver somewhere in the second half of 2008, and KMS really was not meant for general consumption. Crap like this was totally perpendicular to the primary goal of the RadeonHD driver, which was to get a solid display/2d driver with decent compositor support for enterprise linux. KMS never was not an option, until much, much later, and we clearly communicated that in the few cases that you actually brought it up.

I do have to say one thing though... given two possible ways to interpret what happened, one being subtle miscommunication in a large group of people followed by typical disagreements between strong-minded people with different priorities and technical opinions (both believing they are following the approved plan), and the other being a global conspiracy involving most of the open source graphics development community, I would lean towards the first interpretation simply because the latter seems highly unlikely.

And yes, I realize that everyone involved in running a global conspiracy probably says that

It was all but subtle. And it was not a global conspiracy, that's just a cheap shot from your side now. You were working towards a very different, surprisingly non-free goal, and this was clear from the start, and you kept it up, leaving in your wake a trail of what can only be described as lies and endless useless conference calls. Next to that there were a bunch of not overly technically clued loudmouths who happily let technical and open source goals slide for the ability to trump the SuSE competition and yours truly.

[libv]

I don't respond to most of what you post, because there's not much I can say other than "that's not true this is what happened" and the resulting "did not... did too... did not... did too..." could go on forever.

Just to be clear (and to restate for maybe the 20th time) my problem with you implementing native display support was simply based on budget and maintainability. We had a limited budget and timeline to get *everything* going including 2D and 3D acceleration, but what happened was a lot more days than planned going into writing "the ultimate modesetting driver" (despite your working around the clock on it) and fewer days than planned (essentially zero) going into acceleration. The work probably matched your plan but not the plan that was approved or funded.

Remember that you even wanted to bypass drm for acceleration and use the command fifos on 5xx and earlier, which would have left us unable to implement direct rendering or support 6xx and up. Not a problem from your perspective (your personal focus was on modesetting and limited 2D acceleration) but our focus was on 3D acceleration which was why we wanted a quick atombios-based display implementation at the start followed by drm-based acceleration. I was not particularly concerned about the initial modesetting implementation in X because I saw that code moving into drm fairly quickly anyways, and that would have required some rework no matter how perfect the DDX implementation might have been.

Yes, and it did work, especially if i had not overlooked a single register write (but by the time i was working on this i was too demotivated by the whole mess to actually be able to spot it still, and egbert spotted it afterwards). And we got code that was maintainable out of that too, unlike the imho deliberately crap port from Alex. And we needed that code to be independent of the turmoil happening on the drm driver level and to reduce the long term support overhead.

Again, we wanted a driver to live for 10 years, and which could be ported between changing interfaces and even changing subsystems easily. We did not want to go do a total rewrite every time, which always includes breaking everything that's older than 3 years, while of course not supporting everything that's younger than 1 year, which is the situation we now have, even in open source drivers. What happened with the -radeon drivers atombios code when they moved to the kernel? Almost complete rewrite. And now we have DAL, which is yet another abstraction on top of a firmware abstraction (atombios), which then required another complete rewrite. How high does ATI want this tower of abstractions to become? And how much hardware do we know is still fully stable today?

And no, you did not see this move to DRM. Jacobs KMS header file was from april 2007, and we were all still busy dealing with the RandR1.2 fallout (especially the ati driver had a big hit there).

You said earlier that it was supposed to be a partnership (which I agree with), but you totally ignored (and ridiculed) our priorities, and treated us like your gofers only there to provide you with documentation and funding.

This was indeed how i saw your involvement, especially since you were constantly sticking to technically inferior ATI style solutions. But guess what, you were very very bad at even this. As i stated earlier, we spent little time replacing AtomBIOS, we wasted all of our time figuring out those bits that both the docs and atomBIOS did not tell us or did not handle, and you were unbelievably little help here.

Great example; spread spectrum. It took us ages to have it reproduced in the office, then it took me several days to figure out which bit was responsible. When we explained what we had found, you said "ah, right, spread spectrum.", and i asked then whether you had suggested this at all beforehand (as i was surprised by the tone of your answer), and you confirmed that you didn't. It then took 2 seconds for the fix to be ported to the atombios based -radeon driver, and the radeonhd developers were of course not attributed. I am certain that you hailed this as a reason as to why full atomBIOS dependence was faster over proper C code. But guess what, it wasn't, we just wanted solid solutions over unstable ones, and that would've required just as much work with atomBIOS, and would've made it harder to debug.

Another nice example: introducing a stability limit for rv6xx dotclocks, over introducing a table where for a given board, a given mode, the PLL calculation was done from the other side, so that in this specific instance the result would be different... This was a 4-5d penalty at the start, but gave us reliable PLLs out of the box, whereas the other required several dozens of entries in a table over many years. The first was of course my solution, as an actual display driver developer. The second was suggested by you, as that was the ATI way, and this was then of course also implemeted by the forked driver. We had to wait for the r6xx userbase to die out before the "add another entry to the table" patches stopped rolling in.

Long term solutions, with modular and portable code, so that today the same AMD based desktop and/or server system would still solidly boot up a modern SLE/RHEL. That was the radeonhd goal all along, and this is what i knew AMD had bought into.

Now guess what some complaints from users in this thread are?

This is where the difference between proposals became important. The approved proposal (the one we took to Dirk for funding) had an acceleration focus and used atombios as a shortcut to let us get there more quickly. Your proposal had different priorities, and you interpreted every attempt I made to get the work back on track as "meddling" or "not understanding", despite the fact it was my job to get the project implemented as we had proposed.

Of course if I had known that you believed a *different* proposal had been approved things could have gone more smoothly on both sides, but I can't change that after the fact and neither can you.

As explained earlier, atomBIOS was not a shortcut. And, i was always very straight and true about what we were doing. The only time we went behind your back was to get access to real ATI/AMD close-to-the-hw people when we went and talked to the GPGPU team, but you managed to wriggle yourself into that one as well. Actively supporting a fork, and then lying about ones involvement, is a whole other ballpark.

[Kano]

But don't you think that KMS is a good idea now? I don't use Wayland but without KMS it would not be there. RadeonHD never supported the old R300 code - therefore I needed a new card to try it (still need Tonga+ for current AMDGPU) back then. It certainly worked but i could not say that the alternative solution provided by the combined radeon driver was much behind - from a user's POV.

Btw. I would not always mention SuSE as Enterprise quality distribution. Before i started Kanotix i tested around 100 others. I began with SuSE 11/94 (just Slackware with german translation) and even got the SuSE DVDs by some friends up to 7.3 (which was pretty good). My hardware was often not fully supported, like i had to use manually compiled GRUB for a 8 GB hd (lilo was shipped without lba48 support). Then i bought SuSE 8.0 but this release was the worst i had used before. I needed to compile a stock kernel just to get a simple mouse working. Sorry but SuSE did not always provide this kind of quality you would expect when you buy a product with manual in a bookstore. That was the last SuSE release i used. Today buying Linux in a bookstore sounds like an idea from the other Millenium.

I don't test other distribution than Debian or K(ubuntu) much now and i still know ppl who like OpenSuSE but just saying SuSE provided Enterprise class support just because of RadeonHD is overrated. I can not developed what you do and i highly respect your work but please don't overrate your former employer.

[Hi-Angel]

But don't you think that KMS is a good idea now? I don't use Wayland but without KMS it would not be there. RadeonHD never supported the old R300 code - therefore I needed a new card to try it (still need Tonga+ for current AMDGPU) back then. It certainly worked but i could not say that the alternative solution provided by the combined radeon driver was much behind - from a user's POV.

As I understood from his words, 1) KMS was overly bad and almost non-existent at the time, and 2) RadeonHD could be easily ported to KMS.

P.S.: I must thank both libv and bridgman, it was really cool and interesting story!

[bridgman]

KMS is the worst possible example. KMS was a pretty bad heap of junk when Bornecrantzer created the header file (with some handholding help from the likes of airlied on how to style it). It was absolutely broken (we can only define the format/size of a cursor, since about 2 years), which is what one expects when the broken and badly tested randr1.2 headers gets poured into a kernel formatted header, at a time when even Randr1.2 was unable to tell anyone where modelines came from. Jesse did a first stab at a kms driver somewhere in the second half of 2008, and KMS really was not meant for general consumption. Crap like this was totally perpendicular to the primary goal of the RadeonHD driver, which was to get a solid display/2d driver with decent compositor support for enterprise linux. KMS never was not an option, until much, much later, and we clearly communicated that in the few cases that you actually brought it up.

No, KMS was a perfect example. My point was not that we should be implementing KMS immediately but that we would be implementing it relatively soon. It seemed inevitable to me as early as ~May 2007, based on discussions I had had with Dave and Alex while putting together the plan.

I saw crafting your "perfect userspace modesetting driver" at that point as a poor use of time since it would need to be substantially changed in the process of moving into the kernel, while the acceleration code that we were prioritizing would survive the transition largely unchanged...

... so "atombios now, focus on acceleration, make your perfect modesetting driver later" was what I was calling for.

I do wish there had been video recordings of all this -- not for the reasons you might expect, but to capture the "uh-oh" looks that Egbert and Matthias probably exchanged the first time they thought about how our atombios-based plan was going to fit with your intent to completely eliminate use of bios from graphics drivers. Those would have been priceless, and would probably still be appearing in Phoronix articles to this day.

It was all but subtle. And it was not a global conspiracy, that's just a cheap shot from your side now. You were working towards a very different, surprisingly non-free goal, and this was clear from the start, and you kept it up, leaving in your wake a trail of what can only be described as lies and endless useless conference calls. Next to that there were a bunch of not overly technically clued loudmouths who happily let technical and open source goals slide for the ability to trump the SuSE competition and yours truly.

You named a broad cross-section of well-regarded Xorg developers, scattered around the world, and claimed they were working together to undercut your plans and goals. I think "global conspiracy" is a fair term for what you are describing - if not, what would you suggest ?

Other than use of atombios, I'm still trying to understand what your repeated claims about "surprisingly non-free" mean. If you are claiming that you would have waved a magic wand and opened up all the HW microcode as well that's a nice sound-bite but one with zero substance.

Great example; spread spectrum. It took us ages to have it reproduced in the office, then it took me several days to figure out which bit was responsible. When we explained what we had found, you said "ah, right, spread spectrum.", and i asked then whether you had suggested this at all beforehand (as i was surprised by the tone of your answer), and you confirmed that you didn't.

That's because we had been working in parallel on the issues, talking to the HW folks as well as the Catalyst SW devs, and spread spectrum was one of the things that they had just suggested we look at.

Actively supporting a fork, and then lying about ones involvement, is a whole other ballpark.

OK, so you imagine that I did something, just because it fits your bridgman-as-evil world view, and when I disagree then in your eyes I'm still guilty but I'm lying about it too, with no possibility that you could simply have imagined wrong ?

If you ever find yourself wondering why I don't respond to all your posts this is a good place to start.

Anyways, I think you are conflating two unrelated events. What you used to call "the fork" (radeon driver picking up support for newer HW using atombios plus some radeonhd code) happened in Oct/Nov 2007, while kernel modesetting with the new parser happened in mid-2008. Or have they both become "the fork" now ? If so, please be specific about which "fork" you are referencing.

If it helps, you used to claim that I was lying about my knowledge of the first "fork", not the second. You were doing that in late 2007 and early 2008, which makes it unlikely you were talking about kms+parser since that did not happen until ~6 months later.

[darkbasic]

P.S.: I must thank both libv and bridgman, it was really cool and interesting story!

Agree. I knew that story, mostly, but I still have to understand why the community turned against radeonhd, which in my opinion was techincally superior. Unfortunately I wans't involved enough to understand the community feeling at the time, but I don't believe in conspiracies. I will always regret holding over the switch from Nvidia to AMD, when I did it it was too late. I don't know libv personally so I can't speak about him, but sometimes I saw the community leaning torward a project instead of another simply because of the people involved.

[Hi-Angel]

Agree. I knew that story, mostly,

Is it written anywhere? I am, in turn, would be curious to hear other involved peoples' thoughts, e.g. Airlie.

[darkbasic]

Is it written anywhere? I am, in turn, would be curious to hear other involved peoples' thoughts, e.g. Airlie.

Phoronix, mailing lists, irc...

[airlied]

Is it written anywhere? I am, in turn, would be curious to hear other involved peoples' thoughts, e.g. Airlie.

As a great Irish man once said
"I learned long ago, never to wrestle with a pig. You get dirty, and besides, the pig likes it."

My memories are not something I dwell on, I didn't have many meetings with ATI/AMD. I remember talking to JB about April/May 2007 on the phone before I joined Red Hat, in my capacity as one of the -ati maintainers. I remember joining Red Hat, having written the skeleton of a previous driver for r500 hw under NDA, and waiting for a few months until NDA issues got resolved. Then ATI released the docs, radeonhd got atombios support. I didn't see much reason to not have atombios support in -ati, so I ported the ATI core code, and the radeonhd atom wrapper code (with copyrights intact) over to -ati. Alex agreed with me, so worked on it as well while he was employed at AMD. So myself and Alex worked together but it wasn't like anyone was paying RH to make me produce something and I was producing something they didn't want.

My motivations went something like:
-ati needed atombios to deal with r4xx cards properly, we need to take that code anyways.
R500 acceleration code isn't that different from R300/R400 acceleration code, so we should be able to leverage the work we've already done.
So by combining -ati and the atombios code, we got r4xx support, and an easier path to r5xx acceleration.

Since my goal was to get accelerated rendering going, and get to the more interesting 3D things, and knowing that KMS was going to happen (because it was my job to make it a thing) I didn't see the need to expend energy to make something we'd throw away in 2-3 years.

Luc went off on some divergent path where he decided that we should be able to have working 2D acceleration without a kernel driver, even though his enterprise distro shipped a kernel driver, and so did RHEL. This meant some tangent down a path that I personally didn't see the need for, again it was a fixing the wrong problem in the wrong place. If you can't accel without a kernel driver, ship a kernel driver. Again my goal was solid 3D accel, and doing that extra work just for 2D accel didn't seem to have any point, and was making the code a lot less maintainable.

So I know Luc likes to think we were all out to get him, as a group, but really Luc isn't good at making friends or interacting with communities, so I suspect self reflection is liable to me more productive in the long run. Personally since that time although Luc claims to have invented the Internet, I've somehow managed to produce a bunch of projects and ship them to lots of people. If you want to judge people look at their actions and results. Yes KMS wasn't perfect, possibly Luc could have done it better, but he didn't and over time we've fixed things, and with atomic, it's pretty much been rewritten, and hey look at where it is now, always remember, perfect is the enemy of good enough.