Almost A Decade Later, RadeonHD Stories Still Coming To Light

[duby229]

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?

Honestly man, just my opinion on this matter, programming modern computers is -much- more complicated than rocket science.

[agd5f]

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?

As I mentioned in my previous post is also provides support for initializing the asic to a state usable by software. This sequence is very board specific as it depends on a lot of board specific parameters (voltages, clocks, type and vendor of vram, display connector topology, i2c routing, etc.). There are also command tables for calculating certain clock dividers and voltage and leakage limits and data tables for all of the board specific parameters.

[rene]

As I mentioned in my previous post is also provides support for initializing the asic to a state usable by software. This sequence is very board specific as it depends on a lot of board specific parameters (voltages, clocks, type and vendor of vram, display connector topology, i2c routing, etc.). There are also command tables for calculating certain clock dividers and voltage and leakage limits and data tables for all of the board specific parameters.

ASIC init, oh well, like replaying a bunch of register values in a loop?

[rene]

Honestly man, just my opinion on this matter, programming modern computers is -much- more complicated than rocket science.

Honestly man, you do not happen to be a developer, are you?

[duby229]

Honestly man, you do not happen to be a developer, are you?

No I'm not, you're right. I'm not a rocket scientist either. I'm just saying programming GPU's at such a low level is a science which is much more complicated than rocket science.

I'm being sarcastic a bit, but really you comparing fuel burning in a reaction through a nozzle vs programming a GPU. Guess which one I think is more complex.

[StefanBruens]

ASIC init, oh well, like replaying a bunch of register values in a loop?

Honestly man, have you ever had to deal with hardware more complex then an Atmel uC?

Hardware initialization is more than just fixed values, often it is a state machine. Progress to the next state will require a) waiting for fixed times b) waiting until e.g. a PLL has locked. You may want to query voltage levels and set other values dependent on that. Of course you can do a completely table driven approach (which requires n * m * k * l * ... tables; n, m, k, l, ... being number of settings of independent variables like frequency, voltage, ...), and use fixed delays (which will slow down initial boot and every change of operating point), or go the sane way, use tables where required, do calculation where appropriate, and use control flow to combine everything.

If you claim pure register replay is enough, try to find any hardware driver in the kernel which is completely free of any control flow.

[rene]

Honestly man, have you ever had to deal with hardware more complex then an Atmel uC?

Hardware initialization is more than just fixed values, often it is a state machine. Progress to the next state will require a) waiting for fixed times b) waiting until e.g. a PLL has locked. You may want to query voltage levels and set other values dependent on that. Of course you can do a completely table driven approach (which requires n * m * k * l * ... tables; n, m, k, l, ... being number of settings of independent variables like frequency, voltage, ...), and use fixed delays (which will slow down initial boot and every change of operating point), or go the sane way, use tables where required, do calculation where appropriate, and use control flow to combine everything.

If you claim pure register replay is enough, try to find any hardware driver in the kernel which is completely free of any control flow.

Yes, I slightly simplified the HW init just to make normal users understand about what trivialities we are talking here that AMD things need a huge virtual machine language for abstraction. Instead of simply publishing proper register documents, and using native code like most other drivers.

Security and complexity wise this abstraction is a nightmare.

[bridgman]

Sorry, which "huge virtual machine language" are you talking about ? The bytecode ISA has ~8 opcodes and the interpreter is ~1500 lines of code:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdgpu/atom.c

The reason for using a compact interpreted bytecode is to fit all of the required initialization code & date into the available ROM space; the reason for using it in the driver is to ensure that driver and VBIOS use the same code & data despite the fact that both can be different from one board to the next even for the same GPU.

[smitty3268]

Sorry, which "huge virtual machine language" are you talking about ? The bytecode ISA has ~8 opcodes and the interpreter is ~1500 lines of code:

https://git.kernel.org/cgit/linux/ke.../amdgpu/atom.c

The reason for using a compact interpreted bytecode is to fit all of the required initialization code & date into the available ROM space; the reason for using it in the driver is to ensure that driver and VBIOS use the same code & data despite the fact that both can be different from one board to the next even for the same GPU.

We live in a post-fact society.

Nobody cares about your fancy facts and figures, if their gut says there is a huge virtual machine language full of bugs then there must be.

[rene]

Sorry, which "huge virtual machine language" are you talking about ? The bytecode ISA has ~8 opcodes and the interpreter is ~1500 lines of code:

https://git.kernel.org/cgit/linux/ke.../amdgpu/atom.c

The reason for using a compact interpreted bytecode is to fit all of the required initialization code & date into the available ROM space; the reason for using it in the driver is to ensure that driver and VBIOS use the same code & data despite the fact that both can be different from one board to the next even for the same GPU.

Fine, 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?