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

[pal666]

Operating systems do manage storage below filesystem level too.

and microcontrollers do manage storage below filesystem level. see, it is not an operating system's feature. operating system's feature is shared access

[libv]

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.

Wrong. KMS was not relevant in the lifetime of RadeonHD (and KMS was infantile and useless bullshit at the time, with no drivers and no users). By the time we had worked out the things you were unable or refused to tell us with modesetting, we were busy bringing up the 3D engine. When anyone would've been asked in 2008 what was more important, basic 2D/3D support for r600 or redoing all the work for KMS (as the case was with the new atombios parser) then the answer clearly was 2D/3D r600.

For you and your handful of friends, KMS was purely a political sidestep. Thanks to our executive oversight, and the decrease of even register level information (to bleed real code dry), Egbert went and added increased atomBIOS dependence. You lost your stick to beat us with, and then what i had predicted happened, you went and found a new stick.

Doing a proper modesetting driver later was never going to happen. Where are the register level docs today? Where are hacked/fixed atomBIOSes and flashing tools today? Gone, and nowhere. If you really wanted a degree of freedom and technical excellence, while clinging on to atomBIOS, then hacking/fixing atomBIOSes would've been the way. But that never was going to be accepted by ATI. Heck, DAL is just a further extension of ATI thinking.

This is one of the reasons why proper (not perfect) modesetting needed to be done early. It also was the reason why avivo was created. Basics first, bling later, and people were desperate for those basics in 2007, and unbelievably happy when they had working displays.

For all the flack, my proper modesetting had a major political advantage. When we were happy with our basic display driver, and we wanted to release it to our eager community, the release was blocked by ATI (as, after 2 months, you still hadn't bothered to fix the license). If i had not been able to state "that doesn't matter, with some connector layout information in our table, we can run without atomBIOS", then we never would've been able to release anything. After that statement of mine, to avoid the marketing fallout, you were quick to get this code cleared.

We have a somewhat free driver today, because we had a properly free driver then, simply because i put my foot down on the bios issues.

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 ?

It is and was not that broad. It was some people from redhat and their direct political allies. It is however a good cross section of those people who were attracted to the power vacume of the xfree86 fork. This fork shaped how my modesetting work (and i did pioneer modesetting and was very much alone there for a long time, spending ages convincing others) was at first not really accepted and later very badly and shallowly assimilated in RandR1.2.

I am still not entirely sure where Alex stood, my feeling is that he preferred better technical solutions than the -ati driver provided, but that he, as that is how his character is, was unwilling to step on any toes, let alone bite the ATI hand that was feeding him at the time.

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.

Where have the docs gone? Honestly Jon, why did the docs dry up the second RadeonHD was dead? I am pretty certain that free docs were not a part of _your_ proposal. But perhaps Agdf and airlied can do the right thing and show the world exactly what was written in that proposal.

As for the microcode... There are quite a few what-ifs here, and in 9 years a lot of things could've turned out very different. But my stance on atomBIOS however, my unwillingness to accept a black box for doing the standard/trivial things, would have influenced the other black-box situations for the better, as well. You do not need a crystal ball to know that.

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.

So here you admitted to either one of two things, one worse than the other. Your failure to pass on this information means that you were either grossly incompetent or that you were deliberately stalling. Regardless of how this happened, you wasted many many weeks of us being unable to reproduce this issue, and several days of me finding the relevant bit. If we had had this hint, we could've easily have had our users test something.

And then you have the audacity to state that we were unable to move fast because of proper modesetting version BIOS based modesetting. That's just seriously messed up.

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.

You are the one conflating. KMS was a political sidestep when increased atomBIOS was being added to RadeonHD, and when AMD management forced you to let SuSE handle r600 3d bringup, and the first stab at this KMS driver happened in June 2008. You were extremely aware of this action, as you ventured the new atombios parser out of the blue just hours before the announcement of the KMS driver. Politically/Ideologically though, it was a continuation of the same fork.

But you knew full well about the original fork as well. You admitted here that you had written a proposal, which supposedly involved agdf and airlied (did they actually see this proposal, did they help author it, or did you just have a phonecall with them). You also made a point of handing over the CD with the docs at XDC2007 in cambridge, to airlied first. You were driving this from the start.

What i still do not understand is that you continue to claim that you had no knowledge of the SuSE proposal. Even we knew that there was some proposal from the ATI side, but that it was rejected, and that the SuSE proposal was being worked on instead. And we were the external partner. Given how you crashed our valiant attempt, set up by AMD, to circumvent you with AMDs GPUGPU team, i cannot imagine that you had not heard anything about the SuSE proposal. Given how you have always enjoyed rumours and gossip (like the Dell thing), i am certain that you knew some of the contents of that proposal. Hell, the free docs was purely because of the SuSE proposal. I am myself actually pretty convinced that you had seen the SuSE proposal in June 2007 already.

On top of our public proposal, we were there to help reign in ATI, to provide an open source driver to counter the unwillingness of ATI to provide any linux driver for either r600 or r500 (i am not sure which one any more). This in turn meant that AMD servers were suffering, also due to the extremely bad bad press that fglrx was getting, and something needed to be done. So, some AMD people turned to SuSE, a trusted partner who helped make AMD64 happen when the likes of Microsoft and Redhat just couldn't be bothered, and asked us whether we had some ideas on what to do and how to do it.

We had a very clear mandate to create a driver which reminded people as little as possible of fglrx, and we had a very clear mandate to do things properly and not the ATI Way, we had a very clear mandate to create a proper, long term supported, fully open source driver for AMD and AMD alone. And we knew that ATI was going to fight us every step of the way, and that would've worked out ok. If AMD had been able to stay on top, and, to some extent, those handful of forkers had not played those underhand games (as well).

Oh, and Jon, i am not sure you know how the executive oversight ended. This executive oversight (which from the SuSE side was the then linux foundation CTO) made you have that supposed epiphany about the second proposal at the AMD-SuSE partner meeting in prague in may 2008. It also forced atomBIOS on us, and made you compromise a lot as well (like the r600 3d bringup), all of which you sidestepped with KMS. After that KMS gaffe, i was asked to explain what had played out in an email to this executive. This was one of the most excruciating weeks in my life, as i went through communication (email and phoronix and whatnot) and compiled a timeline of actions taken by you, us, and the people at redhat. It was so painful, simply because this quickly became a very coherent set of "accidents" and "misunderstandings" which revealed only one thing, one worse than the other, showing just how we had been played over the past year... I was taken out to lunch by this executive and my department lead 1 week later, and i got told to just give up, and to treat this as a life lesson on how such games are being played in and between corporations.

After that i only halfarsedly continued my r5xx acceleration code sharing idea (1-2kloc module with a nice clean interface, shared between -ati and -radeonhd), and instead shifted focus to the upcoming SLE11 release.

[bridgman]

OK, you're not reading what I write, and you're not going to believe anything that conflicts with your existing view of things, so this is going nowhere.

Here's a thought... along the lines of what "the executive" told you. We still have open source drivers today including things that I was told at the start we would never be able to open up, like video encode/decode. You were part of that... be happy, move on, and stop obsessing over "what might have been".

(BTW I went through the same timeline exercise as you; that was what prompted the call with your VP where we discovered the disconnect re: which proposal had been accepted - IIRC that was in early 2008, not May... email archives don't go back that far but I think it was ~Feb 08)

If you really wanted a degree of freedom and technical excellence, while clinging on to atomBIOS, then hacking/fixing atomBIOSes would've been the way.

Yes, but "doing it right" means testing the AtomBIOS info with driver code before the hardware ships, not asking end users to flash their own hardware. We added that in 2008 and are still doing it today. There are still problems where OEMs make last-minute changes to VBIOS tables without enough testing, but we are addressing that by pushing more testing out to the OEMs as well.

Where have the docs gone? Honestly Jon, why did the docs dry up the second RadeonHD was dead? I am pretty certain that free docs were not a part of _your_ proposal. But perhaps Agdf and airlied can do the right thing and show the world exactly what was written in that proposal.

Free docs were always part of the plan, but we weren't planning to do much in the display area because we had no "programmer level" display documentation, just the HW internal docs... that was one of the reasons AtomBIOS was attractive.

I was able to find some partially sanitized register spec docs covering display that another team had prepared for NDA delivery to a couple of OEMs for troubleshooting purposes, and get the NDA's removed from those after some more cleanup, but...

(a) I was told later that those docs still included info that we should not be releasing (I mentioned this earlier in the thread as you remember), and

(b) by the time we got that resolved the supply of original documents had dried up since we were now sending FAEs to OEM sites for bringup rather than writing documents for them to do their own debugging.

So here you admitted to either one of two things, one worse than the other. Your failure to pass on this information means that you were either grossly incompetent or that you were deliberately stalling. Regardless of how this happened, you wasted many many weeks of us being unable to reproduce this issue, and several days of me finding the relevant bit. If we had had this hint, we could've easily have had our users test something.

Oh good grief. Please turn down the drama.

We received an email overnight mentioning a few areas worth looking at, one of which was "spread spectrum", just those two words, and already had a call with you scheduled for the same day. If you are saying that I should have been watching email all night just in case something came in and my failure to do so wasted a couple of hours of your time that's fine, guilty as charged.

But you knew full well about the original fork as well. You admitted here that you had written a proposal, which supposedly involved agdf and airlied (did they actually see this proposal, did they help author it, or did you just have a phonecall with them). You also made a point of handing over the CD with the docs at XDC2007 in cambridge, to airlied first. You were driving this from the start.

Sigh... OK, let's be clear... by "original fork" you mean adding AtomBIOS support to radeon ? If so, no I did not know about it when it was starting but I did find out after the fact, around the time Alex joined AMD (remember that didn't happen until Dec 07). I wasn't particularly surprised since it was going to be needed for later 4xx HW anyways (maybe to you "being aware of the possibility" is the same as "knowing about it" ?) but that's as far as it goes.

Before writing the proposal I was browsing through various forums trying to get an understanding of the current state of open drivers and what customers were looking for. I ran across a comment along the lines of "if ATI was serious about open source drivers the first thing they would do is call Dave Airlie". So I did.

Dave suggested that I talk to Alex as well. Don't think either of them saw the proposal but it included some of their input along with input from the "AMD side" folks who were working with you. Dave and Alex knew about the plan to have Novell write the initial driver code; there were some open questions about how to manage acceleration code but we agreed we would work them out over time. Part of the challenge was that the big changes in display HW (all-new display HW in 5xx) happened at a different point from the big changes in acceleration HW (6xx). The move to AtomBIOS happened even earlier (midway through 4xx) because it was developed to help smooth the transition between different generations of display HW.

You already had the docs - who do you think should have received the first CD ?

What i still do not understand is that you continue to claim that you had no knowledge of the SuSE proposal. Even we knew that there was some proposal from the ATI side, but that it was rejected, and that the SuSE proposal was being worked on instead. And we were the external partner.

What you "knew" was wrong. I don't know how that happened, but you need to get over it somehow.

I suspect that the AMD folks you were working with felt that they had recommended enough changes for the two proposals to be effectively the same, and made their comments to you based on that understanding. The accepted proposal was the same as yours at a high level "blah blah open source blah blah Novell blah blah documentation blah blah community" level but different in the details that mattered to you - particularly "using AtomBIOS from the start" vs "stamping out the use of BIOS in drivers".

Given how you crashed our valiant attempt, set up by AMD, to circumvent you with AMDs GPUGPU team, i cannot imagine that you had not heard anything about the SuSE proposal. Given how you have always enjoyed rumours and gossip (like the Dell thing), i am certain that you knew some of the contents of that proposal.

My boss was asked to come up with a proposal for getting open source drivers happening (what you call "crashing your valiant attempt", I guess) and I was part of a small team tasked with putting together a plan. At some point early in the discussion we were sent a ~1.5 page "proposal" which I gather was either an early version or a top-sheet from your work, without all of the details.

I decided to get more involved after watching the avivo effort and seeing the developers struggle over lack of basic information that I knew we could provide without risk. Ben was looking for a volunteer to build the plan and run the project, and I volunteered.

The "AMD GPUGPU" team was never involved AFAIK, unless there was a "Plan C" that none of us knew about.

Hell, the free docs was purely because of the SuSE proposal. I am myself actually pretty convinced that you had seen the SuSE proposal in June 2007 already.

Sure, because HW vendors had never provided documentation before so we must have stolen the idea from you, right ? Reality check - I grew up writing drivers for reasonably well documented hardware (TI, NEC, Motorola in my case) and building processors from AMD bit-slice logic (also well documented). I knew how important documentation was (especially at the "getting started" stage) but I also saw that there was a point of diminishing returns where documentation size could grow exponentially and still not solve all the problems, so I thought that a mix of documentation and vendor support might be best.

-----------------------

Anyways, I'm sure it's fun to think of these events as good vs evil, hero vs villain, ATI vs AMD, SUSE vs RedHat, but the reality is much less exciting. Nine years after all this happened AMD is still strongly committed to open source... perhaps not in exactly the way you want but to a much greater extent than most companies in the industry.

Remember that ATI also actively supported open source driver development until ~2003, when the combination of acquiring FireGL (with a pre-existing binary Linux driver) and increased DRM robustness requirements resulted in an attempt to use the binary driver for all markets, not just workstation.

If anyone ever decides to make a movie about what happened you can write the screenplay, since your story would be much more interesting than mine. Until that happens, let's let it go and get on with life, OK ?

[Amarildo]

So much laundry being done in this thread. I love it

[pq1930562]

bridgman

Here's what AMD should really do:

1. Bring back the "ATI" brand. "ATI" sounds much cooler than "Radeon Technologies Group" or "AMD".
2. Stop giving your driver names like "Crimson Edition". "Crimson Edition" sounds horrible and is not cool at all.
3. Bring back cool advertisements like the following one (It was so cool, why did you stop doing such cool things?):

https://youtu.be/K0SIcFMLGeo

4. Bring back the proper Ruby, not this strange Ruby from the "Project Phoenix" CryENGINE 3 tech demo. This is the proper one:

https://youtu.be/HiszZlq3ST4

5. Make GPUs with red PCBs again
6. Fully commit to Linux / open source. Make Linux the number one priority.
7. Release everything as open source (drivers, firmware, everything, no compromises).
8. Maybe team up with Valve regarding Steam OS / Steam for Linux.
9. Stop supporting PlayStation and Xbox. Consoles and console exclusivity just ruin the PC gaming experience.
10. Remove DirectX 12 support from your drivers. Focus entirely on Vulkan instead. The world does not need yet another proprietary graphics API which only benefits Microsoft and forces consumers into buying/using Windows 10. Supporting DirectX 12 is only contributing to this. It is evil. AMD, please do good things instead.
11. Push harder on FreeSync. It's still not available on Linux. And it's still not available in TVs. Gaming is not just limited to small monitors. Gaming is also happening on TVs. About time FreeSync becomes also available for big TVs.Maybe you could even enable FreeSync for PlayStation and Xbox (they are using AMD Radeon technology after all) to push it even harder.
12. Release the Qt Radeon Settings for Linux ASAP. How a open-source dedicated GPU manufacturer can develop a Qt based graphics control panel and then only release it on Windows is beyond me. It should have been released on Linux first, not the other way around.
13. Rise

Any update?

[bridgman]

Any update?

I thought I replied to all the points already:

- some of them would result in us going out of business, so nothing happening there
- some of them are already happening as I said (but none are small enough for any kind of update after a week or two)
- the rest are related to areas of the company where I don't even know who to contact and don't have time right now to go and research

For #1-#4, telling a marketing team that "this person in a forum thinks what you are doing now sucks and you should go back to what you were doing before when you had a larger marketing budget" is not as likely to be well received as you might hope.

#5 is a possibility but the people who need convincing do not work for AMD, they work for the companies who build boards around our chips.

The rest fall into one of two buckets, the "that would mean us going out of business" bucket or the "we are already doing that" bucket.

[pq1930562]

- the rest are related to areas of the company where I don't even know who to contact and don't have time right now to go and research

It can not be that hard to figure that out?

For #1-#4, telling a marketing team that "this person in a forum thinks what you are doing now sucks and you should go back to what you were doing before when you had a larger marketing budget" is not as likely to be well received as you might hope.

Okay, you don't know who to contact at AMD, but you know that the unknown contact has a smaller budget than before, interesting.

Anyway:

Your argument of money is moot anyway, because: AMD is still doing such videos, here's a recent example:

https://youtu.be/K2Fs4hsnGI8

It's just that those videos are much less cool compared to the older videos.

And to bring back that neat ATI and AMD logo with those nice animations and nice sounds, would not cost you money at all, because you already have them.

Oh, and you had money to rename the graphics group to "Radeon Technologies Group" (A.K.A. "RTG"), so you probably also would have (had) the money to rename it to "ATI" again, which would have been much cooler (well, would have been even cooler if you would have kept "ATI" in the first place).

#5 is a possibility but the people who need convincing do not work for AMD, they work for the companies who build boards around our chips.

Then convince them.

The rest fall into one of two buckets, the "that would mean us going out of business" bucket or the "we are already doing that" bucket.

I don't see you doing what you could do.

For starters, you could rename all the repositories for "amdgpu" and "amdgpu-pro" to "atigpu" and "atigpu-pro".




Maybe that would also trigger the attention of the proper contact at AMD you claim is unknown to you .

You said you like #1 to #5. If you would put a bit more passion into it (instead of listing difficulties that could obviously be overcome), maybe #1 to #5 could actually happen.

Believe!

[bridgman]

Sure. Pick which new part whose Linux drivers we should stop working on so I can have time to play marketing. Vega ? The Zen APU ?

[pq1930562]

Sure. Pick which new part whose Linux drivers we should stop working on so I can have time to play marketing. Vega ? The Zen APU ?

Seriously, please don't tell me that figuring out an email address of the AMD marketing department would delay any driver development.

Obviously you have time to post on the Phoronix forums (which is a good thing). But then you also must have some time to figure out an email address within your own company and sending an email to that address.

Besides, all this driver development is in vain, if only a few people buy AMD hardware because the marketing is lackluster (or not as good as it used to be), so...

Anyway, it took me less than five minutes of googling to come up with the following website:

http://support.amd.com/en-us/dam

which even has a login for internal employees and even offers an email address when you click on "Contact MARS Support". Even though that "MARS Support" might not be the actual marketing team, maybe they can forward you to them.

Don't you have some kind of email list system or Active Directory at AMD that you could search for "marketing" to come up with the proper marketing team contacts?

Heck, maybe it's even as simple as:

marketing@

? (just a wild guess...)

[bridgman]

I'm not talking about "sending an email", I'm talking about doing something that will actually make a difference. That takes time.

Emails like the one you are suggesting generally just annoy people and make it harder to actually drive a change.