Agree that the technology has not been an issue for years but the (small) difference in cost is.
Telling our customers they need to pay more for a larger ROM does not result in the joy and happiness you might expect.
Announcement
Collapse
No announcement yet.
Almost A Decade Later, RadeonHD Stories Still Coming To Light
Collapse
X
-
Originally posted by rene View PostI was not jumping around. The one jumping around in this thread is apparently you. I was always talking about native OS drivers. I could care less what AMD is doing in their BIOS (as long as it at least boots, and get's out of my way, open source BIOS welcome though, too).
Btw. you are fighting to wrong guy here. I never wanted to use a totally closed Nvidia binary only blob, I even always promoted the "more" open AMD cards for use on Linux.
The use of a virtual machine for mode setting is just unnecessary nonsense.
Anyways, we can talk about this forever but I don't see things changing any time soon. To summarize:
1. We use an interpreter in VBIOS in order to (a) fit a lot of functionality into a small ROM, (b) give us a degree of CPU independence. My understanding is that this is pretty common practice; either way it's not likely to change unless OEMs buying AMD chips are willing to spend more $$ on the ROM for our hardware than for competitors hardware AND we are willing to go back to having different BIOS code for each of the different CPUs our chips are used with.
Originally posted by michaelb1 View Post... We just don't have the original source code of VBIOS, and the creation of open source VBIOS from scratch is like reinventing the wheel - a huge wheel, which is way too much for unpaid work. Just share the complete source code of VBIOS and let the open source community fix the bugs for you for free! ...
Relatively more of the changes are in data tables than in command tables but both get changed and so we need to use both in the driver if we want driver functionality to correctly match the HW config. There are literally thousands of different HW subsystems, each with their own VBIOS image and hence each with their own slightly different source code... and the associated HW differences DO generally need to be considered when the driver runs.
3. A couple of people have started projects to replace VBIOS with a fully open solution, but my impression is that they all run into the same issues:
- initial implementation is straightforward but ongoing maintenance is a big and boring effort nobody wants to own
- you lose CPU independence unless you are willing to maintain AND TEST a lot more different VBIOS builds
- without an interpreter the resulting implementation won't fit in the on-card ROM unless you cut back functionality
We make enough information for an open source BIOS replacement available as part of the open source driver effort (data table & command table headers, bytecode interpreter, open source drivers using the tables) although I don't think we support VBIOS re-flashing in general. It is easy to get the same result by over-riding tables in the driver code, however, and I believe there is an existing quirk mechanism.
4. Over time I think you will see a trend away from using AtomBIOS calls simply because ROM size limits the amount of complexity that can be supported in ROM-resident tables while HW complexity is continuing to grow as quickly as ever.
My understanding is that DAL/DC makes somewhat less use of AtomBIOS calls but it also replaces a relatively painless sharing model (drivers for all OSes/platforms make the same AtomBIOS calls for the fiddly HW-specific bits) with a much-harder-to-sell sharing model (drivers for all OSes/platforms share native driver code for the fiddly HW-specific bits).
I understand that this seems unnecessary (and maybe even counter-productive) if you believe that modesetting is trivial, but I don't know how to reconcile your views on modesetting with the views of developers working on the code at different vendors. Once we figure out how to close that gap the rest of the discussion should become easier.Last edited by bridgman; 22 February 2017, 01:05 AM.
- Likes 1
Leave a comment:
-
Originally posted by michaelb1 View Post
bridgman, why you don't just open source the complete source code of VBIOS, to let the open source community improve it and fix some bugs? With the help of flashrom open source project, anyone is able to reflash their VBIOS through In-System-Programming. We just don't have the original source code of VBIOS, and the creation of open source VBIOS from scratch is like reinventing the wheel - a huge wheel, which is way too much for unpaid work
Just share the complete source code of VBIOS and let the open source community fix the bugs for you for free! A win-win solution. Why not do it? For the bystanders like me, it gives an impression that either 1) VBIOS source code is a horrible quality, too ashamed to release it to public 2) VBIOS contains some hidden backdoors, hence the need for secrecy 3) AMD is not that friendly to open source community, if instead of sharing what you already got, you want the people to start reinventing the wheel and waste countless of unpaid work hours on it
Leave a comment:
-
Originally posted by starshipeleven View PostNo, overengineering is installing a full-blown android kernel in a modem device that has dozens of MB of ram (like most modern qualcomm modems, and also huawei ones) you then control by AT commands like any other dumb modem.
Using low-level VMs with a few dumb optcodes is not as bad as you think, and anyway that's stuff that would be turned in a blob, either flashed in a ROM or loaded at runtime anyway. Hardware is NOT open, so that's not "wrong" per-se.
That hardware is not open is not set in stone, and apparently also changing - see RiscV et al.
Also where should that stop? For me it is for example also not acceptable to have closed WiFi firmware. How should I know what backdoor is lurking inside there. And if this is not ok for WiFi chips, why should it be ok for some GPU? Mesa and LLVM have already all the real instruction secrets open source, and something as trivial and simple as mode setting needs a VM? Ridiculous.
Leave a comment:
-
Originally posted by bridgman View Post
Hold on, you seem to be jumping around a bit. Are you arguing about the use of the AtomBIOS interpreted bytecode in our VBIOS (which we need for CPU independence and to fit a lot of code into a small ROM) or just about the use of AtomBIOS calls in the modesetting driver ?
Your earlier posts seemed to be attacking AtomBIOS itself but your more recent posts seem to be more focused on its use in the driver. If so, that is easier to deal with since the DAL/DC effort replaces a lot of the AtomBIOS calls with native code, replacing the implicit sharing model with an explicit one.
Btw. you are fighting to wrong guy here. I never wanted to use a totally closed Nvidia binary only blob, I even always promoted the "more" open AMD cards for use on Linux.
The use of a virtual machine for mode setting is just unnecessary nonsense.
Leave a comment:
-
Originally posted by rene View PostAnd another point: Open source OS, drivers, libraries and everything has also to do with the freedom an ability to fix bugs. When there are bugs in ACPI, and AtomBIOS tables one can do nothing to fix them. Except putting workarounds and hack in the AtomBIOS interpreter glue.Originally posted by bridgman View PostI assume you are talking about moving all of the VBIOS code and table data to the driver, and maintaining thousands of different table sets in the driver ? Isn't that the same as treating *every* piece of hardware as needing a workaround and hack in the AtomBIOS interpreter glue ?
Originally posted by bridgman View PostIt's certainly do-able but AFAIK no vendor in the world actually does it because it makes new hardware launches somewhere between impractical and impossible. Every new card, every new laptop would potentially need a new driver revision to function.
Leave a comment:
-
Originally posted by rene View PostFine, your VM is smaller then Qemu. Does not change the point that this is a classic example of over engineering a trial problem. Does the open source Intel or Nouveau driver also include a Virtual Machine for their display port mode setting?
Using low-level VMs with a few dumb optcodes is not as bad as you think, and anyway that's stuff that would be turned in a blob, either flashed in a ROM or loaded at runtime anyway. Hardware is NOT open, so that's not "wrong" per-se.
Leave a comment:
Leave a comment: