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

[bridgman]

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

I'm not talking about an individual's personal budget, I'm talking about a functional group's budget. You get that from listening to investor Q&A sessions and reading financial statements.

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.

The point I'm trying to make is that the videos you think of as "cool" tend to also be the expensive ones. There is a connection.

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.

The logo in the videos needs to match the brand the products sell under, and rebranding is *very* expensive. AFAIK that only changed once in the last 15 years, basically ATI Radeon to AMD Radeon.

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).

I don't get the connection. We could call the graphics group "Bruce" and the products would still be Radeon-branded cards from AMD. The org changes that resulted in formation of the RTG did not change product branding.

[libv]

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".

No, i am not part of that. I got my work extensively trashed, and if you believe some sources, i am "the corporate/microsoft drone who wrote a closed source driver to keep people from using a proper free driver, like -ati. Which is of course what redhat did, as part of the community, simply to make the world a better place.". Heck, just look at wikipedia, how often is SuSE credited there for freeing ATI? Even less than i have been credited for coming up with structured display driver development now known as modesetting.

(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)

I have a full and complete record at home, on DVD. It's not on my massive and seperately backed up storage yet, so i cannot access it remotely. But i will, and i will then provide everyone with very accurate dates, names, facts, quotes, whatever.

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.

Have you guys gone back and fixed the CRTC disable on all R5xx and all R6xx before the DP enabled RV6x5, when someone noticed the issue and finally fixed it, after more than 2 years? Of course you didn't.

Have you given people the ability to hack their own atombioses together themselves, with a clear "no warranty for you"? Of course you didn't.

The big issue I and many others have with your view of the world, and the big issue that was what this thread was supposed to be about (and which you tried to subvert) is the fact that very fundamental and surprisingly trivial functionality is being hidden. And hidden code always is faulty code. ATI should now also be known for abstracting poorly, and for piling on abstraction on abstraction (DAL).

Then there is the fact that, from where i sat, the difference between FireGL and standard cards was perhaps some small changes in board design, the pci-id fuse set differently, but mostly clocking things lower than the consumer part and then a much much better tested BIOS. FireGL board BIOSes had tons of fixes compared to the equivalent consumer board. I rather doubt that ATI spent the time to backport those fixes to consumer boards.

As i stated earlier, the crap hidden inside atombios was the trivial stuff. That what atombios did not tell us, and which then of course the register level documentation did not tell us, and which you never did help us with, that's what ate our time.

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.

You really have no register level documentation any more? At all? Do your field-application-engineers really use raw VHDL for doing their jobs? Perhaps they just use the FAE force? What water are they cooking with?

I think i remember you stating that these documents were automatically generated. If you had ticked differently, you could've worked to have individual hw blocks marked for release or not (by ATI management and legal), and automatically generate register level documentation that would per definition be releasable, without too much overhead, especially when such blocks were 99% the same between ASIC generations. But instead you spend the time stalling, complaining and subverting instead of providing sane solutions.

Then, there are several register level docs that you verbally stated would be freed, which still are not free today (perhaps i should just go and throw them online, to fulfill your promises). And this same register level documentation just happened to dry up at the exact same moment the RadeonHD project died. Your statements above really are not truthful.

If however you were trying to state that anything above register level was never available, then this is/was no different than what we had before, and we did not expect such nice documents to be available. We did expect your cooperation on providing some of the bits and pieces needed (which you barely ever did). Also, this level of information is/was also necessary to use atomBIOS correctly, so again, your statements hold no water whatsoever.

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.

So now it is a timing issue? The one time you claim that could've provided us with useful hints, was sadly ruined because you did not read your email before you talked to us? Such a sad sad coincidence, you missed your one chance to contribute to the open source driver.

But do feel free to dig out that email and prove this timing. I have a massive store of information myself, and am not against using it.

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.

Together with Airlieds statement, which i will also reply to when i find the time, your timing here does not make sense, once again.

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.

There probably were massive differences between the layout of the atombios tables between most different generations of chips (that's not how atombios was sold to ATI/amd management, but i have a long lists of such fallacies). I am pretty certain that r4xx atombios looked pretty different. While i am certain that the function tables could still be run by the same interpreter, the slightly higher level things will have changed massively between r4xx and r5xx as r5xx was such a complete redesign for everything that atombios was claimed to cover. (It should be relatively easy to prove this, but i have not done this yet here).

So again, this statement makes no sense. Yes, the interpreter would have to be duplicated or shared, but the way atombios functions and data tables were use was going to be massively different, and would've seriously influenced the implementation of a driver. So whether one uses atomBIOS extensively or not is, once again, irrelevant, the hard work would've been massively different again. Both using (some version of) atomBIOS is technically and logically far less significant than the massive differences in display engine design.

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

The sensible way to do this was to just ask "who can stick these things on an fd.o server, preferably during this talk", and to not make a point of underlining your future plans like you did.

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".

At very high level of course. If you go high enough, everything does look the same.

But as we can clearly see with what crap code you (ATI) are now pushing into the kernel this is not really a good solution. And this whole thread is about firmware and relations, and you are on a completely different and rather incompatible track. Yet you are still here trying to defend that stance, even though there is relentless proof as to how this model saves no effort and leads to problems on all levels.

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.

What?

You had a preliminary version of our proposal?

How?

And how dare you then claim that things like free documentation were not something new, and that you too came up with that, on your very own.

You even went as far as claiming that you had no idea of the separate SuSE proposal, at all, until you finally were told that valuable piece of secret information in May 2008? You had access to even a preliminary version of that proposal, and you had all the other datapoints, but you honestly had no clue about a separate SuSE proposal?

Is there no end to the lies you spew?

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.

Again... Our friendlies inside AMD tried to get us into contact with the GPGPU guys as it was very clear that you were not providing us with any worthwhile information. We got to talk to them in January 2008. You ended crashing that party as well, closing that door for us too.

They were of course not involved with the initial proposal(s), they were probably too busy sorting out the ATI mess from a GPGPU pov. (while we were supposed to sort out the ATI mess in the linux world).

I will get exact dates and names for you when i dig through my backups.

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.

This was the first time since 3DFX went bust that this happened, and it was quite a few years before the 3DFX release happened that graphics makers closed up. 3DFX was a a massive exception. Our proposal for the RadeonHD driver, was the first real publically available documentation in a decade.

_And_ you stopped the flow of documentation the second RadeonHD was dead. Luckily intel kept it up (at least for several more years).

And yes, i will get you the names and dates for the GPGPU people, they were indeed responsible for the ISA and other 3D engine things to continue to be available.

Again, your statements are not too credible.

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 ?

That's all very easy for you to say.

You did not pour your heart and soul into a beautiful and very easy to maintain driver. You did not have the rest of your career impeded by what essentially was nasty corporate politics (AMD+SuSE vs ATI+Redhat) badly carried into the open. You did not have baseless crap smeared on you, based on shaky facts and fabrications. You are still getting paid today for the little you did then (how long until you retire btw?). You do not have to listen to people like the FSF and libreboot whine about BIOSes and firmwares in graphics, and know that you had little no support when you were actually changing that (where were they then?). Instead, you can sit back and be content in the knowledge that you helped stop that "nonsense".

And finally, you do not have to watch people like John Bridgman constantly trying to subvert articles which are against firmwares and BIOSes. If you really had just buggered off after succeeding, then it would be much easier for me to let this go. Instead, you have spent the last 9 years subverting at least this forum here, which is why you have close to 10k posts now.

[pq1930562]

I have a full and complete record at home, on DVD. It's not on my massive and seperately backed up storage yet, so i cannot access it remotely. But i will, and i will then provide everyone with very accurate dates, names, facts, quotes, whatever.

PhoronixLeaks .

[pq1930562]

Anyway, heres the next point:

12. 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.

Ahahaha, bridgman MrCooper is this coincidence:

http://www.tomshardware.co.uk/freesync-tv-amd-radeon-rtg,news-53880.html

?