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

[libv]

And that is exactly why I say openness isn't the issue, it's bout setting realistic goals that are achievable. One plan was achievable and the other was not even close. History has proven which was which.

Very limited atombios dependence was working out very well (ASICInit and data tables). It was purely for political reasons why it was demanded by bridgman.

In fact, when Egbert had already begun putting further AtomBIOS dependence in, he needed only a dozen or so lines to support the newer generation of rv635 (if memory serves) for our supported functionality in C code. This while bridgman harshly demanded full AtomBIOS dependence... Bridgman flipped his lid when egbert pushed his rather quick and non-invasive changes which made that new ASIC release work just fine...

[pal666]

Making some sort of artificial differentiation is stupid.

why do you differentiate hardware and firmware then? from user's pov they are the same thing

[libv]

Oh, and then there is the fact that if we had not been atomBIOS independent (when int10 had already run, and when we knew the connector layout), there never would've been any open source driver for r500/r600. Bridgman was blocking the coderelease by not resolving the proprietary license on the atomBIOS interpreter. When we then stated "that's fine, we do not really need it anyway, we can release and run without it", it was in the end resolved hastily. I am pretty sure that the plan was to stall us for many weeks still, just like Bridgman and the rest of ATI hoped that we would never manage to create a driver with the mass of extremely low level hw information we got.

[pal666]

It was almost down to ATI + Red Hat + noisemakers versus AMD + SuSE + big overnight community

looking at the outcome, that big community was not that big after all

[artivision]

Oh, and then there is the fact that if we had not been atomBIOS independent (when int10 had already run, and when we knew the connector layout), there never would've been any open source driver for r500/r600. Bridgman was blocking the coderelease by not resolving the proprietary license on the atomBIOS interpreter. When we then stated "that's fine, we do not really need it anyway, we can release and run without it", it was in the end resolved hastily. I am pretty sure that the plan was to stall us for many weeks still, just like Bridgman and the rest of ATI hoped that we would never manage to create a driver with the mass of extremely low level hw information we got.

First is the completion of the OGL, then the completion of the Gallium Fast Path and Ultra Fast Path, then add Vulkan support, then some extra D3D State Trackers (maybe), and then you can restart your project by simply porting over. Each thing on its time, its not a big deal today, it will be in a couple of years (lets say we can promise them that).

[W.Irrkopf]

That's when C code died, that's when register level documentation died. The only thing that continued were the ISA documentation releases, but that was done by a separate GPGPU team created before the r600 was even released and way before AMD decided that it had enough of the ATI shenanigans and would create an open source driver.

Ah, I was under the impression that nowadays there was register documentation as well, except for the DRM (in the restrictions meaning) stuff. Thanks for the clarification.

And now one of the nasty powerplayers is surprised that the organization that he helped shape to be far-less-than-free is not releasing code for a vulkan driver?

Is that "is surprised" your interpretation of "I was waiting for an open source driver to appear when I realised I should really just write one myself" in the mail/blogpost or based on other stuff as well?

[starshipeleven]

Why do you insist on quoting out of context?

It's not out of context.

Anyway I made my point. Firmware is definitely not hardware just as much as the schematics used to describe it also is not hardware.

I never claimed firmware was hardware, and WTF is that "schematics is not hardware" at all. Who the hell claimed schematics were hardware again? Stop drug abuse.

I only said "open hardware", it's not the same as just "hardware", just like "open source" is not the same as "source". If I go by your retarded logic I can call "opensource software" only the source form of it, not also the binary.

I said (and I repeat) that to have open firmwares you would need to have also true open hardware (i.e. full schematics, not just register info), which is not something most people expect.

Openness is the same and artificially complicating things is stupid.

Life is complicated.
How many people think that to have open firmwares they should need to advocate for open hardware schematics at all?

That was my point. People don't usually connect low-level firmware with hardware design. They are software like you keep repeating, but they are so linked to hardware that they cannot be opensourced without basically opensourcing hardware schematics too.

Which is why it's good to treat them differently than say Libreoffice that isn't anywhere close.

[duby229]

It's not out of context.

I never claimed firmware was hardware, and WTF is that "schematics is not hardware" at all. Who the hell claimed schematics were hardware again? Stop drug abuse.

I only said "open hardware", it's not the same as just "hardware", just like "open source" is not the same as "source". If I go by your retarded logic I can call "opensource software" only the source form of it, not also the binary.

I said (and I repeat) that to have open firmwares you would need to have also true open hardware (i.e. full schematics, not just register info), which is not something most people expect.

Life is complicated.
How many people think that to have open firmwares they should need to advocate for open hardware schematics at all?

That was my point. People don't usually connect low-level firmware with hardware design. They are software like you keep repeating, but they are so linked to hardware that they cannot be opensourced without basically opensourcing hardware schematics too.

Which is why it's good to treat them differently than say Libreoffice that isn't anywhere close.

You do realize that what you are saying is exactly the same difference right? I do understand what you are attempting to convey and it's exactly the same thing. You are trying to differentiate a liquid by placing it in different shaped jars essentially, but even though you can use jars to change its shape you can't change the fact that it's the same liquid.

Hardware is physical. Release as much documentation and code as you want, you won't be able to replicate it exactly without the exact fabrication and diffusion facilities it was designed for. Exactly the same way as how the code to operate a cnc machine is used to create the parts it makes, a fabrication plant is coded to create the products you think need some kind of special openness.

EDIT: If you want to see your dream of real physical hardware where the whole nine is OSS, then you better be prepared to front billions of dollars and your life to build a new foundry that doesn't infringe any patents at all.

[bridgman]

Ah, I was under the impression that nowadays there was register documentation as well, except for the DRM (in the restrictions meaning) stuff. Thanks for the clarification.

I'm not sure "clarification" is the right word. We have been continuously providing register documentation for the 3D/acceleration part; libv is talking about register documentation for the display block, which is at least partially handled by AtomBIOS:

• AMD R3xx 3D Register Reference
• AMD R5xx Acceleration
• AMD R6xx/R7xx 3D Register Reference
• AMD R6xx/R7xx Acceleration
• AMD Evergreen 3D Register Reference
• AMD Cayman/Trinity 3D Register Reference
• AMD Evergreen/Northern Islands Acceleration
• AMD Southern Islands 3D Register Reference
• AMD Sea Islands 3D Register Reference
• AMD Southern Islands/Sea Islands Acceleration

https://www.x.org/wiki/RadeonFeature/#index12h2

[Awesomeness]

and nothing useful. you can't trust it as future oss vulkan driver, so any comparison with amd is pointless

The announcement does not claim that it's either useful or a base for a fully working, future driver – neither did I.