The Libdrm & xf86-video-amdgpu Repositories To Follow For FreeSync

[gurv]

Great news!
Really excited to finally be able to test Freesync soon

[chithanh]

Wrong, the fact that it is running inside the peripheral itself pretty much eliminates any practical problem, as the only thing required is some code to load this blob in the peripheral itself at runtime.
There is no kind of documentation of how the hardware works at this level and it is unrealistic to expect it for closed hardware, so even with opensource firmwares you won't be able to have the community fix them in case of bugs.

What you write could not be further from the truth.

For one, the code size of the amdgpu microcode has grown to almost 2 MB for current generation GPUs. The code runs on F32 command processors which feed the various rings (graphics, compute, transfer, UVD, etc.). Significant decisions happen in this code, opaque to the user. At least two instances became publicly known where bugs were identified in the radeon/amdgpu microcode and fixed in a later update:

https://bugs.freedesktop.org/show_bug.cgi?id=75992

https://fail0verflow.com/media/33c3-slides/#/76 (need to press forward a couple times to see the whole slide)

On the topic of the second link, PS4 Linux, disassembling, studying/documenting and modifying the microcode was essential to getting the radeon driver run on PS4 hardware.

The ethical side is theoretically there, but in practice we are talking of very dumb and low-level stuff, It's not UEFI, it's not ME, it's not a CPU core running VxWorks while the other core runs your OS, so it's not a bigger threat than any other closed hardware you can choose (with or without firmwares).

Given how GPUs shift towards GPGPU, and how lots of applications now use OpenCL to do parts of your computer's work on the GPU, I strongly disagree here. If you delegate computation to the GPU then everything that happens is under full control of the GPU and the software that runs on it. And VxWorks runs on WiFi Routers with 2 MB flash memory, which isn't all that far from amdgpu microcode today.

[starshipeleven]

What you write could not be further from the truth.

What you post isn't contradicting what I said in the slightest. It's all tangential. Nice try, but my point still stands and yours is still bullshit.

For one, the code size of the amdgpu microcode has grown to almost 2 MB for current generation GPUs. The code runs on F32 command processors which feed the various rings (graphics, compute, transfer, UVD, etc.). Significant decisions happen in this code, opaque to the user.

Is this contradicting my statement that this microcode is running inside the peripheral itself? No. That's still microcontrollers inside the GPU SoC.

At least two instances became publicly known where bugs were identified in the radeon/amdgpu microcode and fixed in a later update:

Is this contradicting my point that there is no kind of documentation for this low-level hardware AT ALL and will never be because it's proprietary design, so even with an open firmware no community will ever be able to fix bugs in it? No.

So what are you asking open firmwares for? Opensource isn't magic. It isn't a religion.

On the topic of the second link, PS4 Linux, disassembling, studying/documenting and modifying the microcode was essential to getting the radeon driver run on PS4 hardware.

I'm not even sure of what is your point here.
It's custom proprietary hardware not intended for Linux (but for a proprietary OS), that has no driver, nor documentation, and is dodgy if not illegal to run Linux on it.
Are you perhaps asking all proprietary embedded devices to provide a linux-compatible driver?

Given how GPUs shift towards GPGPU, and how lots of applications now use OpenCL to do parts of your computer's work on the GPU, I strongly disagree here. If you delegate computation to the GPU then everything that happens is under full control of the GPU and the software that runs on it.

In what way this does contradict what I said?
It's still not an OS, it has no idea of what is the data it is processing or how to communicate to the outside world, it is just complex because the task is complex, and loaded on runtime because that way it can be updated easily.
It is microcode for microcontrollers, not a true OS with services and shit like UEFI, ME and VxWorks.

Your point is true but tangential. It's not a good idea to rely heavily on proprietary coprocessors in general, so you should campaign for open hardware.

I mean ok you can also waste your time shouting at proprietary hardware vendors, but you will only make a fool out of yourself as you are asking the impossible.

And VxWorks runs on WiFi Routers with 2 MB flash memory, which isn't all that far from amdgpu microcode today.

The firmware size only depends from the complexity of the task, does not say what the device can actually do.

[chithanh]

Note: the quotes are not in order, I grouped them by topic

What you post isn't contradicting what I said in the slightest. It's all tangential. Nice try, but my point still stands and yours is still bullshit.

On the contrary. Your point still stands only to those who are seriously out of touch with the changing realities of computers and firmware which is executed on auxiliary processors.

The practical problem that you consider "eliminated" isn't. It is that the software which runs on the F32 command processors does make decisions which are opaque to the user.

Is this contradicting my point that there is no kind of documentation for this low-level hardware AT ALL and will never be because it's proprietary design

There was an initial reverse engineering effort from Adreno folks (Adreno microcode is similar to R600 microcode) and there are now tools and reverse engineered specifications for CI F32 ISA from the PS4 Linux project.

In what way this does contradict what I said?

You wrote: "The ethical side is theoretically there, but in practice we are talking of very dumb and low-level stuff, It's not UEFI, it's not ME" and while it used to be very dumb and low-level in the early days, nowadays it is quite complex. Coupled with the fact that the GPU controls an ever increasing part of the computation that happens on a system (GPGPU) the practical problems of proprietary firmware running inside the GPU are all too obvious.

It's still not an OS, it has no idea of what is the data it is processing or how to communicate to the outside world

The firmware size only depends from the complexity of the task, does not say what the device can actually do.

The firmware inside the device device can decide whether or not to execute my code, whether or not to schedule it so that it runs efficiently, and whether or not to return faithful results. It can communicate via PCIe.

Your point is true but tangential. It's not a good idea to rely heavily on proprietary coprocessors in general, so you should campaign for open hardware.

Open hardware is nice but not required to benefit from FOSS. Many examples exist where firmware has been freed or a free replacement was written, and made to do things which the original hardware vendor did not envision or did not want to allow the user to do (first time I got into contact with this was the FreeMAC firmware for my p54u driven Wi-Fi adapter).

Open hardware was not in any way necessary for this, nor is it necessary now. Your continued insistence that open source firmware only makes sense in combination with open hardware is very strange.

So what are you asking open firmwares for? Opensource isn't magic. It isn't a religion.

and loaded on runtime because that way it can be updated easily.

Proprietary software is a tool for user subjugation. It gives the vendor an unfair advantage over the user, by being able to easily modify what the program does while the user faces difficulties or is even forbidden from understanding what it does (e.g. amdgpu/radeon firmware license forbids reverse engineering or disassembly).

[ernstp]

Let me fix that for you: "It's very much a hardware feature of the monitor and display interface afaik.

I see no reason why modern Nvidia and Intel GPU's wouldn't be able to make use of it with the right software.

Well your display interface could be a fixed function ASIC and not support Adaptive Sync? The thing that actually implements the DisplayPort PHY.
I mean if the hardware isn't specifically prepared for VESA Adaptive Sync, perhaps the programming interfaces are not flexible enough to support it well.
AMD can only do it on specific hardware generations, I assume that's because they need hardware support!

Naturally you need a FreeSync monitor also...

[Brisse]

AMD can only do it on specific hardware generations, I assume that's because they need hardware support!

Because they must have at least DP 1.2 or later. Adaptive sync is an optional part of the DP 1.2 specification called DP 1.2a. Nvidia does not claim to be DP 1.2a compliant but maybe they could be with the right software.

Naturally you need a FreeSync monitor also...

Obviously

[starshipeleven]

The practical problem that you consider "eliminated" isn't. It is that the software which runs on the F32 command processors does make decisions which are opaque to the user.

And this is different from a device that does opaque decisions due to other means, just like all proprietary hardware does, because?

There was an initial reverse engineering effort from Adreno folks (Adreno microcode is similar to R600 microcode) and there are now tools and reverse engineered specifications for CI F32 ISA from the PS4 Linux project.

Still not contradicting my point. To fix bugs you need to know how the hardware was actually designed.

The firmware inside the device device can decide whether or not to execute my code, whether or not to schedule it so that it runs efficiently, and whether or not to return faithful results. It can communicate via PCIe.

The same can do any proprietary hardare, firmwares or not. The hardware is a black box we hope does our bidding. Open firmwares don't protect you from this either, because proprietary hardware might do its bidding regadless using internal ROMs and whatever.

Open hardware is nice but not required to benefit from FOSS.

In the past maybe, but now it is. Things changed, just as now we don't have ROMs in the device itself with the blobs inside, so FOSS could be happy, hardware is more complex, making reverse-enginering so much ahrder.

Many examples exist where firmware has been freed or a free replacement was written, and made to do things which the original hardware vendor did not envision or did not want to allow the user to do (first time I got into contact with this was the FreeMAC firmware for my p54u driven Wi-Fi adapter).

Name something modern and relatively complex/important.

Open hardware was not in any way necessary for this, nor is it necessary now. Your continued insistence that open source firmware only makes sense in combination with open hardware is very strange.

Because hardware complexity has risen, like you said. And with it has risen reverse engineering complexity.

For example now in a 3G/4G dongle we have a dual core system running on one core some VxWorks thingy that runs the radio part, and on another core a crappy Android kernel to interface the modem to the PC and other systems.

We have 2 full OSes running in any x86 system (ME/PSP and UEFI) and the amount of info about them is barely enough to disable ME partially (or fully if using the US gov switch). And both are 10+ years old.

Also Coreboot is locked on older stuff and won't go anywhere, and reverse engineering is hitting high walls of complexity and lack of goddamn documentation. (yes I'm subscribed to that mailing list)

We need documentation, without it reverse engineering is a non-starter as the target is so complex that none can go there without company-grade backing. And proprietary hardware vendors won't provide it for obvious reasons.

Proprietary software is a tool for user subjugation. It gives the vendor an unfair advantage over the user, by being able to easily modify what the program does while the user faces difficulties or is even forbidden from understanding what it does (e.g. amdgpu/radeon firmware license forbids reverse engineering or disassembly).

Well, it is also a tool to actually get the money to do anything at all. It's not necessarily evil by default. It carries the risk of becoming a tool for user subjugation.

In the case of these firmwares, it's... not that much.

[chithanh]

I must say that you have very strange ideas about these things. Open hardware and free/open source software (including firmware) are two very different things, and one is not contingent on the other to be useful.

And this is different from a device that does opaque decisions due to other means, just like all proprietary hardware does, because?

It is different because the vendor has the ability to change what the software does, sell you hardware that is artificially gimped by software, etc. Also the vendor can react to users trying to circumvent these restrictions. Example from last year is a HP OfficeJet firmware update which installed a hidden countdown timer against 3rd party and rebuilt ink cartridges.

Still not contradicting my point. To fix bugs you need to know how the hardware was actually designed.

No. To fix bugs in the microcode it is only necessary to understand the microcode.

Name something modern and relatively complex/important.

Well you name one right there:

For example now in a 3G/4G dongle

Some USB Wi-Fi/Broadband adapters can run (partially, no baseband and no Wi-Fi firmware) free replacement for their built-in OS now.

We have 2 full OSes running in any x86 system (ME/PSP and UEFI) and the amount of info about them is barely enough to disable ME partially (or fully if using the US gov switch). And both are 10+ years old.

Also Coreboot is locked on older stuff and won't go anywhere, and reverse engineering is hitting high walls of complexity and lack of goddamn documentation. (yes I'm subscribed to that mailing list)

What does that have to do with anything? Of course things are becoming more complex, but that doesn't prevent people from replacing proprietary software with their own code even though the hardware is not fully understood.

We need documentation, without it reverse engineering is a non-starter as the target is so complex that none can go there without company-grade backing. And proprietary hardware vendors won't provide it for obvious reasons.

No. Look at the history of the Osmocom project and what they have achieved. The complexity of a cellular network and its components is enormous. Lots of it by reverse engineering, writing replacements for vendor firmware, using second-hand hardware discarded by telcos.

Well, it is also a tool to actually get the money to do anything at all. It's not necessarily evil by default. It carries the risk of becoming a tool for user subjugation.

In the case of these firmwares, it's... not that much.

In case of the radeon/amdgpu firmware, I think it was bridgman who said that there is a risk that DRM (ie. user subjugation) could be circumvented if the microcode and specifications were freed. So yes, it is already a tool.

[starshipeleven]

I must say that you have very strange ideas about these things. Open hardware and free/open source software (including firmware) are two very different things, and one is not contingent on the other to be useful.

I'm not saying it is contingent, but that it is the only way forward.
I'm saying that modern hardware is too complex to be reverse-engineered in a reasonable timescale (before it is obsolete), and so far this happens to be correct.

Open hardware would have none of these restrictions.

No. To fix bugs in the microcode it is only necessary to understand the microcode.

Yeah, syntax bugs maybe. You can't fix logic bugs unless you know wtf is the thing supposed to control.

Some USB Wi-Fi/Broadband adapters can run (partially, no baseband and no Wi-Fi firmware) free replacement for their built-in OS now.

I'm unsure of what this means.

You mean that they have no baseband nor wifi operational? What's the point?

What does that have to do with anything? Of course things are becoming more complex, but that doesn't prevent people from replacing proprietary software with their own code even though the hardware is not fully understood.

Both projects involve low-level hardware initialization and operation, same as microcodes in AMD. (Plus the OS thing that is the thing I have most beef with)

And the lack of documentation + hardware complexity has pretty much killed any non-NDA Coreboot development, last available are for Ivy bridge after the leak of information.

No. Look at the history of the Osmocom project and what they have achieved.

Firmware for modems running in GPRS and 3G networks, not supporting most features of 3G? In a world where LTE/4G is taking over, and they have some kind of company backing.

In case of the radeon/amdgpu firmware, I think it was bridgman who said that there is a risk that DRM (ie. user subjugation) could be circumvented if the microcode and specifications were freed. So yes, it is already a tool.

DRM isn't user subjugation because the user has agreed to a contract limiting his own freedom already, and the DRM is just enforcing this.

User subjugation is when there is no agreement, no contract. Like for example when hardware runs worse with time to force the user to upgrade (and of course none signed a contract where he agreed this would happen).

[chithanh]

Yeah, syntax bugs maybe.

Bugs like missing bounds checking on external input, which leads to buffer overrun, which leads to remote code execution.

You mean that they have no baseband nor wifi operational? What's the point?

I mean that the firmware replacement is free, but baseband or wifi requires blobs. But even without the blobs it is useful to repurpose to allow some general computing and communication via USB.

And the lack of documentation + hardware complexity has pretty much killed any non-NDA Coreboot development, last available are for Ivy bridge after the leak of information.

That still hasn't got to do anything with demanding free firmware, and free firmware being useful despite non-free hardware.

Firmware for modems running in GPRS and 3G networks, not supporting most features of 3G? In a world where LTE/4G is taking over, and they have some kind of company backing.

The companies backing Osmocom are small, some even founded by Osmocom people. And they wisely concentrated their efforts on goals that are within reach, but which are nonetheless impressive and required substituting the proprietary firmware with a free replacement in many cases.

DRM isn't user subjugation because the user has agreed to a contract limiting his own freedom already, and the DRM is just enforcing this.

User subjugation is when there is no agreement, no contract. Like for example when hardware runs worse with time to force the user to upgrade (and of course none signed a contract where he agreed this would happen).

Proprietary software is user subjugation, too, whether there is a contract/EULA, implied license, or whatever. And yes, the user limited their own freedom, that doesn't make it any less subjugation.