RADV Is Now Considered A Vulkan Conformant Driver

[smitty3268]

Buying an ice cream cone would not cause the company to go out of business, but that was not the suggestion I was responding to either.
Q was saying that we should stop support for DirectX and MacOS, which would be a quick way to reach that "out of business" end state.

I stopped reading Q's posts a long time ago, but I believe in the past you've said that focusing on the internal vulkan driver was a business decision based around costs. I'd suggest that argument is hogwash now that we have a compliant radv working. It still needs work, obviously, but it's getting there fast and most of it is coming from independent contributors and consultants.

Nothing complicated - the Vulkan team decides our Vulkan strategy, and their preference was to focus on the AMD Vulkan driver rather than having AMD developers contribute to radv.

Hmm, so I've been wondering about how exactly this Vulkan driver is going to work. Can you answer a few questions? Or is it all still hush-hush or not figured out yet?

1. Will there be an open bugtracker somewhere that the general public can use to report bugs?
2. Will it be actively monitored and worked on, rather than a dumping ground that is never responded to (like the fglrx drivers had)?
3. Will the people doing that be Marek/Nicolai? If so, will they switch to Vulkan full time, or split time with Mesa/GL?
4. Or will it be windows proprietary driver people instead? Will there be more than a single person?
5. Will any of this be dedicated to the linux driver alone or will everything (bug tracker, devs, etc.) all be geared towards windows first and linux just gets to use it as well, or will there be people dedicated to the linux driver only?
6. Will it accept outside contributions, or is it just open source in that people can view the source and compile it themselves but not upstream anything?
7. Will contributions be quickly reviewed and upstreamed, or will there be a big approval process to go through? will it be like Addrlib where changes can potentially be made if urgent but otherwise the default is to stick to the cloned internal codebase as much as possible?

[bridgman]

then you get the point that rationality and logic shows that your point is not driven by science facts ....

It could even the complete Oppositie what could be the science truth....

You didn't exactly say I was wrong there, just "your point is not driven by scientific facts" (I never claimed it was) and "It could even be the complete opposite of ... truth" (but it could be right as well).

You need something stronger than that. Unless you are thinking about going into politics

[bridgman]

I stopped reading Q's posts a long time ago, but I believe in the past you've said that focusing on the internal vulkan driver was a business decision based around costs. I'd suggest that argument is hogwash now that we have a compliant radv working. It still needs work, obviously, but it's getting there fast and most of it is coming from independent contributors and consultants.

Surprisingly enough radv doesn't change the cost equation that much. The Linux team would still be expected to add radv support for each new HW generation (which would more or less come for free from a Linux perspective with AMD Vulkan) and there was some serious discussion about turning the code sharing model between OpenGL and Vulkan around, so that Mesa GL used code developed for the AMD Vulkan driver rather than requiring a separate implementation effort for each new GPU as it does today.

That said, the time and effort required to open up the AMD Vulkan driver suggests that the ongoing cost of getting new HW support out in a timely manner might be higher than originally expected, which gnaws away at the cost advantage. The question is how much.

Hmm, so I've been wondering about how exactly this Vulkan driver is going to work. Can you answer a few questions? Or is it all still hush-hush or not figured out yet?

It was mostly figured out a year or so ago, but there may have been discussions since that I missed. Take all this as "probably accurate a year ago":

1. Will there be an open bugtracker somewhere that the general public can use to report bugs?

IIRC the idea was another amdgpu category in the freedesktop.org bugzilla

2. Will it be actively monitored and worked on, rather than a dumping ground that is never responded to (like the fglrx drivers had)?

Depends on the average quality of the tickets. We were pretty active on the fglrx bug tracker for a while but eventually the combination of "my screen is black I wish you guys would all get cancer and die" and "I installed on a distro you don't support and it didn't work" messages dampened the enthusiasm.

Most of that user frustration came from a mismatch between fglrx priorities (pretty much 100% workstation 0% consumer) and user priorities (probably more like 50/50), so I expect there would be less ugliness in this case.

3. Will the people doing that be Marek/Nicolai? If so, will they switch to Vulkan full time, or split time with Mesa/GL?

Plan was for AMD Vulkan team people to do this, not Marek/Nicolai.

4. Or will it be windows proprietary driver people instead? Will there be more than a single person?

Not "Windows proprietary driver" but "cross-OS driver". Otherwise yes. Can you call it proprietary if it is open source ?

We didn't discuss number of people other than >0

5. Will any of this be dedicated to the linux driver alone or will everything (bug tracker, devs, etc.) all be geared towards windows first and linux just gets to use it as well, or will there be people dedicated to the linux driver only?

Bug tracker would probably be Linux only by virtue of being on FDO. Having Linux-oriented developers is unavoidable - even though the top of the driver presents the same API for Linux and other OSes the bottom of the driver talks to different interfaces on Linux than on Windows, and generally those developers would also be the ones looking at issues reported on Linux. One of the few things in life that usually works out on its own.

6. Will it accept outside contributions, or is it just open source in that people can view the source and compile it themselves but not upstream anything?

Intent was to accept outside contributions, with the exception of "strip XYZ out because we don't need it for Linux" changes. The open source Linux-only Vulkan-only source tree would just be a view into an internal multi-OS multi-API source tree and so some changes would have to be rejected or reworked (with explanation) because of that.

7. Will contributions be quickly reviewed and upstreamed, or will there be a big approval process to go through? will it be like Addrlib where changes can potentially be made if urgent but otherwise the default is to stick to the cloned internal codebase as much as possible?

The general rule (which I would expect to be the same for addrlib) is that if the contribution is a general improvement and suitable for going back into the "true upstream" tree (which is one step removed from the visible upstream tree) then it would be accepted and appreciated, but if it was something that would have to be maintained as a permanent offset in the public view of the tree it would be more difficult to deal with.

Again, please take this as "probably accurate a year ago".

[smitty3268]

Again, please take this as "probably accurate a year ago".

Thanks for the responses. I look forward to eventually seeing the driver in another 3 years.

[donkeykong]

Nice to see radv becoming conformant. Strangely, it doesn't seem to mean bug-free. https://bugs.freedesktop.org/buglist...list_id=626700
I hope that one of these days, the emulators will receive some love, as there are a few bugs (dolphin specially) ruining the experience is some cases. Those are probably corner cases, but that would probably benefit the driver's robustness and quality.

[bridgman]

Nice to see radv becoming conformant. Strangely, it doesn't seem to mean bug-free. https://bugs.freedesktop.org/buglist...list_id=626700

Conformant rarely means bug-free, just "bug-free within the time limits of the people writing the conformance tests", but usually a number of bugs do get fixed on the way to passing conformance tests.

That said, if you look at that bug list:

- some of the bugs are against the intel driver and just mention radv in passing
- some of the bugs are from before the radv driver was developed and are actually referring to radvd
- a couple of bugs appear to be resolved and are just waiting for confirmation that the fix or workaround is reasonable

Not much left after that, mostly the remaining dolphin issues AFAICS. I say "remaining" because it appears that some of the issues have already been resolved.

[airlied]

Nice to see radv becoming conformant. Strangely, it doesn't seem to mean bug-free. https://bugs.freedesktop.org/buglist...list_id=626700
I hope that one of these days, the emulators will receive some love, as there are a few bugs (dolphin specially) ruining the experience is some cases. Those are probably corner cases, but that would probably benefit the driver's robustness and quality.

So two dolphin bugs and one really old ss3 bug that is likely fixed.

Also Vulkan isnt like GL there is a pretty good chance the bugs are in dolphin, and just don't show up on other drivers, we've already have this with all other games and tried to solve them with game devs before they ship.