RADV: A Community Open-Source Effort To Get Vulkan Working On Radeon

[ossuser]

AMD could still make the decision to opensource Mantle, or parts of it.
It contains the code examples that all parties need, including David Airlie.

[V10lator]

That would get VK support just like R100 got KMS, half baked FBO and left without HyperZ

As I said: You'll need software fallbacks (IIRC there's no memory management in hardware, which is needed for Vulkan but could in theory be done in software, too, and something other I don't remember right now). Also IIRC even some AMD guy (@bridgman maybe?) told some time ago a driver would be possible but AMD itself isn't interested in supporting that old hardware anymore. Anyway, there are poor guys (like me) which would love to see such a driver, just to make sure the cards will be future proof a little longer (also with OpenGL these cards are CPU limited in most situations (this is from my own measurings, YMMV), so Vulkan would be good, even if CPU usage would be higher than on GCN cards cause of the fallbacks).

[W.Irrkopf]

It is interesting though to see how Dave now is claiming victory over a situation that he himself helped create. If he hadn't been battling a proper open source driver for radeon back in 2007-2009, and siding with ATI on Atombios and whatnot (against SuSE, and against RadeonHD, and thus in the end against AMD itself), then we would've had much more open behaviour from AMD/ATI today. We would've had open register docs still, we wouldn't have had such dependence on AtomBIOS or DAL or whatever it is called now, and real open source developers would've started developing the open source AMD vulkan driver months ago, or at least actively supported it.

I have problems following what you are saying here. Are you talking about the Vulkan driver here or about DAL? On the one hand the current context seemed to be Vulkan and in that context I don't really understand what the Atombios stuff has to do with Dave "claiming victory over a situation that he himself helped create". If on the other hand the context was DAL, then I can follow most parts or what you wrote.

The part that I still have problems following is the part about "open register docs": I assumed that the register docs are released, but maybe I am no longer up to date or miss something about this. Btw, the purist in me says that there cannot be any "real open source developers" working on current AMD video hardware as the firmware is closed anyway.

[SpyroRyder]

AMD could still make the decision to opensource Mantle, or parts of it.
It contains the code examples that all parties need, including David Airlie.

...yes lets release a whole bunch of example code for a API that has been dead for 3 years so that people can write a driver for a current API the spec of which lives entirely in the public domain and additionally only bears a passing resemblence to the dead API. And that's assuming that the mantle code doesn't also have the same release problems that plague the release opf an open source Vulkan driver.

[starshipeleven]

Btw, the purist in me says that there cannot be any "real open source developers" working on current AMD video hardware as the firmware is closed anyway.

The purist in me wants to tell to the purist in you that open source means software-only stuff, so an opensource driver with microcode and low-level firmwares that is running non-open hardware is ok, because the closed parts are technically part of the hardware even if they aren't burned in a flash chip on that board.

If you want also open firmwares you want open hardware, which is another thing entirely.

[duby229]

The purist in me wants to tell to the purist in you that open source means software-only stuff, so an opensource driver with microcode and low-level firmwares that is running non-open hardware is ok, because the closed parts are technically part of the hardware even if they aren't burned in a flash chip on that board.

If you want also open firmwares you want open hardware, which is another thing entirely.

If it's a layout of 0's and 1's, then it's software. I don't care, what other people have been indoctrinated to think.Hardware is hard because it's physical and software is soft because it's virtual.

[Nille_kungen]

On the one hand the current context seemed to be Vulkan and in that context I don't really understand what the Atombios stuff has to do with Dave "claiming victory over a situation that he himself helped create".

I think he has forgotten that after some time radeonhd used atombios as well or that he blames Dave and Alex for the choice to use atombios in the radeon driver.

http://www.phoronix.com/scan.php?page=article&item=radeonhd_atombios&num=1

[starshipeleven]

If it's a layout of 0's and 1's, then it's software.

Cool, but I'm not talking about that. That is a simplistic definition that may be good for pre-schoolers and dumbfucks, but here we are all grown-ups and should be able to detect more fine differences.

I'm talking about the fact that for most people around the opensource world have weird views: if the firmware is embedded in the product then the driver is all fine and open, if the low-level firmwares are distributed separately and loaded by a driver then it is all wrong and closed.

The plain fact is that most modern hardware is simply too complex to be run without some sort of microcode, and keeping these microcode closed is just a consequence of the hardware itself not being open, as opensourcing microcode would give away like A LOT of such closed hardware.
And you cannot ask the manufacturers to opensource that in the name of FOSS, as it is as part of their hardware as the hardware itself and as sensitive information as the hardware design itself, and if their hardware is closed, so will remain the low-level firmware.

The definition of opensource software came BEFORE all this was the norm, and thus does not take it into account in the slightest, so you get the retarded situations as said above:
flashed in device (i.e. mimicks the old days when this wasn't present) = good,
loaded at runtime = bad.

So I was stating that what he is talking about should be called Open Hardware instead, a much more modern non-ambiguous definition, where the whole hardware design is freely available, and the low-level firmwares are opensourced.

Of course there are plenty of cases where the manufacturer hides non-low-level shit in the firmware, or makes various kinds of bullfuckery to sidestep GPL or opensource in general by keeping their IP safe and closedosurce while they can claim their driver is "opensource", and this is wrong and against opensource and worth fignting against.

But as I said not all firmwares are inherently bad or against opensource. The legit ones are just a consequence of increasing complexity of hardware + non-FOSS hardware, so if you don't want them you want open hardware, not open source.

[duby229]

So now you are expounding into a whole different dilemma. It's not about whether firmware is software or hardware. Firmware itself is in fact software, it doesn't matter where it was written or how or when. Whether it was lithographed or flashed or read from a disk does not matter at all. I'm not the guy making those stupid arguments. My personal opinion is they are freakin dumb.

In my mind I see it as how realistic a goal is. It's not realistic to code specifications for every single AMD GPU ever made or that ever will be mde. That's what the firmware provides. It's not an issue of duplication cause I don't think it can be realistically duplicated. An open source firmware obviously could be written, but the hardware specs themselves are unrealistic to expect. They've already been released and almost nobody did a thing with them. The guys that did were hired by AMD or already worked somewhere else.

[starshipeleven]

So now you are expounding into a whole different dilemma.

I was answering him, yes.

Firmware itself is in fact software, it doesn't matter where it was written or how or when.

In this specific case, a very special kind of low-level software that is so close to the hardware that making it opensource would make nearly open-hardware the hardware itself.

Which is why I'm saying that if he wants to get rid of it he should advocate for Open Hardware.

In my mind I see it as how realistic a goal is. It's not realistic to code specifications for every single AMD GPU ever made or that ever will be mde. That's what the firmware provides.

You are talking of firmwares responsible of GPU board initialization and configuration, that isn't the big offender as it is tiny and doing ONE thing (most SoCs have half-decent boot ROMs that do that too and it's fine), we are talking of the whole load of blobs that get loaded on runtime to initialize and run all stuff onboard once it is initialized.

"stuff onboard" in the sense of the GPU's features baked inside the SoC, that should work the same for all.