Almost A Decade Later, RadeonHD Stories Still Coming To Light

[bridgman]

Did you mean GPU instruction sets?

No, CPU - the VBIOS code is executed at power-up by CPU, and then called from the driver code (also running on CPU) at runtime.

The current driver/VBIOS combination is used on x86, ARM, MIPS and PowerPC today among others - CPU ISA portability was the primary reason for using an interpreter in the first place, since interpreting a purpose-built bytecode is considered to be a lot safer than interpreting x86 instructions.

[duby229]

No, CPU - the VBIOS code is executed at power-up by CPU, and then called from the driver code (also running on CPU) at runtime.

The current driver/VBIOS combination is used on x86, ARM, MIPS and PowerPC today among others - CPU ISA portability was the primary reason for using an interpreter in the first place, since interpreting a purpose-built bytecode is considered to be a lot safer than interpreting x86 instructions.

Yes, this exactly. The video bios actually runs on the cpu regardless of where it is stored. Hell even right up to the 9700pro and 9800pro the bios was entirely x86 assembly.

[rene]

I was answering Artivision's question about documentation to support making an open version of AtomBIOS - so all of the artifacts I mentioned would be required. Replacing the BIOS with native code is a separate issue, although (a) it would need most of the same information, (b) you would then be back with the original problem of handling all the different CPU instruction sets that we support today.

Note that AtomBIOS does a lot more than just modesetting.

my understanding is that the different GPU(!?!) instruction sets are handled in LLVM and mesa, and even as my outsider understanding should have nothing much to do with AtomBIOS mode setting, ....

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

It should not be rocket science to do mode setting, and if it is maybe the hardware is overcomplicated maze.

[bridgman]

my understanding is that the different GPU(!?!) instruction sets are handled in LLVM and mesa, and even as my outsider understanding should have nothing much to do with AtomBIOS mode setting, ....

Agreed, but I said CPU instruction sets - VBIOS runs on the CPU, not the GPU.

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

I 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 ?

It'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.

It should not be rocket science to do mode setting, and if it is maybe the hardware is overcomplicated maze.

Are you familiar with DisplayPort MST, where multiple displays are connected on a single shared link and the maximum resolutions for each of the displays depends on real-time link capability and the modes/colour depths of all the other displays sharing a link in addition to all of the usual constraints (GPU power state, memory bandwidth etc..) ? That is a fairly typical modesetting challenge these days.

[agd5f]

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

It should not be rocket science to do mode setting, and if it is maybe the hardware is overcomplicated maze.

Think of the command tables as more like scripts; register sequences required to setup the hw (both display and other things). They are shared and validated by both the vbios and driver teams (on multiple OSes) so they get a lot of testing. They are also the only way to really scale across lots of OEMs and AIB partners. Board specific configurations are encapsulated in the tables so the driver doesn't have to special case all the strange platforms out there just to make things work.

And modesetting is extremely complex nowadays. In addition to the complexities of DP, display has real-time requirements so things like fine grained bandwidth and clock management is incredibly important to avoid underflow or audio problems.

[rene]

Agreed, but I said CPU instruction sets - VBIOS runs on the CPU, not the GPU.



I 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 ?

It'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.



Are you familiar with DisplayPort MST, where multiple displays are connected on a single shared link and the maximum resolutions for each of the displays depends on real-time link capability and the modes/colour depths of all the other displays sharing a link in addition to all of the usual constraints (GPU power state, memory bandwidth etc..) ? That is a fairly typical modesetting challenge these days.

I assumed you your CPU was a typo, I do not see how CPU instructions are relevant when you mostly run on x86, beside especially on PowerPC, ARM or SPARC I would prefer native code, instead of VM like code interpretation.

Yes, I'm aware of DisplayPort and MST and HDMI audio etc. This is exactly not what I would want to be hidden away in an virtual, interpreted VM layer, ... :-/

[agd5f]

I assumed you your CPU was a typo, I do not see how CPU instructions are relevant when you mostly run on x86, beside especially on PowerPC, ARM or SPARC I would prefer native code, instead of VM like code interpretation.

It's a CPU independent interpreted language. The interpreter is open source and runs on all platforms. It needs to be compact to fit in the vbios and shareable so we can leverage the same sequences in the vbios as well as drivers for various OSes.

Yes, I'm aware of DisplayPort and MST and HDMI audio etc. This is exactly not what I would want to be hidden away in an virtual, interpreted VM layer, ... :-/

MST and audio are not handled by atombios directly. Atombios just handles asic init (initializing the chip so that sw can interact with it) and low level modesetting commands like setting plls, setting timing, setting up the digital encoder, setting up the phys. etc. The high level logic is in the driver, these are just the low level register programming sequences for specific low level operations. Modesetting is complex irrespective of how you go about it.

[rene]

It's a CPU independent interpreted language. The interpreter is open source and runs on all platforms. It needs to be compact to fit in the vbios and shareable so we can leverage the same sequences in the vbios as well as drivers for various OSes.



MST and audio are not handled by atombios directly. Atombios just handles asic init (initializing the chip so that sw can interact with it) and low level modesetting commands like setting plls, setting timing, setting up the digital encoder, setting up the phys. etc. The high level logic is in the driver, these are just the low level register programming sequences for specific low level operations. Modesetting is complex irrespective of how you go about it.

your bridgman brought that up, in fact he wrote "Note that AtomBIOS does a lot more than just mode setting." and "Are you familiar with DisplayPort MST, where multiple displays are connected on a single shared link…"

[bridgman]

your bridgman brought that up, in fact he wrote "Note that AtomBIOS does a lot more than just mode setting." and "Are you familiar with DisplayPort MST, where multiple displays are connected on a single shared link…"

Agreed, but my comment about DisplayPort & MST was in response to your comment about modesetting being trivial, not about AtomBIOS itself.

[rene]

Agreed, but my comment about DisplayPort & MST was in response to your comment about modesetting being trivial, not about AtomBIOS itself.

I still think modesettings is trivial (as opposed to rocket science), do you still want to provide an example of what "a lot more than just mode setting" AtomBIOS is providing?