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

[starshipeleven]

I was wondering if it had something to do with programming registers etc., (the hardware level).
Which I felt AMD is quite open about.

So, then it's up to AMD (and other devs) to find other ways to do the same things as in the closed code ?

No, that low level is also pretty easy to reverse-engineer anyway. (for someone with resources, like say NVIDIA)

Closed source code also allows them to steal stuff and opening it may not be a good idea. (not accusing anyone, just saying what is common with closed source and one of the main reasons why companies are very sensitive about IPs)

Also, there is the old plain "avoiding to provide the competition with easy access to easily-usable code", as for example NVIDIA would be interested in seeing their windows driver source, but not so much at looking their linux driver source, since porting code over from a linux driver would be worse than writing stuff from scratch.

[ossuser]

If you ask bridgman he is under NDA and has no right to tell you what really is going one. he is not even in the position to tell you which company do have the copyright of the ineffectual property.

But if you know me on phoronix I was able to bust the truth out of secrecy many times ;-)

I hear you ;-)

But, back to topic, this start of development of a non-AMD Vulcan driver seems to be a very good thing then.

[Passso]

I can kinda bear Ubuntu, they take retarded counterproductive ways that doom them to failure, but at least it is still opensource (not that it matters that much in the end), but how in the hell is NVIDIA even "investing a lot in linux" if their driver is mostly the same as in windows and not even opensource?

They do invest a lot in their own multiplatform driver as they make also drivers for Solaris and BSD-like stuff, but "investing a lot in Linux"?

Providing day 1 support for their products with the same stability, functionalities and level of performance as Windows is an evidence that they invest a lot in Linux, yes.
(even if like you I would prefer an open-source driver)

[starshipeleven]

Providing day 1 support for their products with the same stability, functionalities and level of performance as Windows is an evidence that they invest a lot in linux, yes.

What part of "Unix systems get the same NVIDIA driver too" aren't you getting?

NVIDIA invests in its multiplatform driver that runs on Solaris and BSDs too with minor modifications, they don't invest in "linux" in any shape or form (for desktop/laptop anyway).

May I remind you that they DID NOT move a finger to make something like Bumblebee? Or that they don't usually give a fuck about a large amount of minor driver bugs that have to be worked around in the linux land (and probably on unix too).

[juno]

But I think it is very easy to get what company it will be: for OpenCL code it is "apple" for the Vulkan code it is sony because of the PS4 and for the LLVM compiler code it is microsoft because of xbox one and DX12 is sharing code with amd-mantle .

Sorry but do you have any evidence at all for that or are you just speculating around?
Apples OpenCL implementation is far behind. Also this has nothing to do with the Vulkan runtime or drivers.
Sony doesn't use Vulkan at all. The ps4 runs a BSD variant, so there are not even the same interfaces to hook into. Same with Apple BTW. The graphics API is called GNM and said to be even more low level than Vulkan.
The Xbox uses nt kernel and quite "normal" windows 10 alike os afaics. DX11 was altered to be more low level and fit xb1 requirements. DX12 came later, just like on PC. I don't see why ms would pull in mantle there, which is basically dead and dx12 is vendor independent and important for windows PCs as well. There is no insurance that the next iteration of Xbox hardware is from AMD as well. So why would they do this?

Also, if it were only for the consoles, it would be easy to cut off and release the rest, IMHO. But I don't see at all why they should have all that in this same project.

If we are just speculating, I'd say this is about code that has been written outside of AMD, ordered because of lack of devs.

Another possibility is with the functionality of specific hardware blocks. They also buy hardware IP from companies like synopsis or eSilicon, iirc, and integrate that in their chip designs. Would make sense if they also do some coding, wouldn't it?

[pal666]

Nothing dishonest or untrustworthy about that.

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

[ossuser]

...

If we are just speculating, I'd say this is about code that has been written outside of AMD, ordered because of lack of devs.

Another possibility is with the functionality of specific hardware blocks. They also buy hardware IP from companies like synopsis or eSilicon, iirc, and integrate that in their chip designs. Would make sense if they also do some coding, wouldn't it?

If it were indeed the hardware level, we would not ever get that code into opensource, isn't it ?
And in that case, maybe the nouveau guys would have some info for the radeon guys, that's interesting.

If it were the software level, it might be an interesting idea to have an AMD opensource (basic, not pro) driver on windows as well ?

[juno]

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.

What happened back then? What is atomBIIS and what does it have to do with this all?

[pal666]

If I recall correctly, someone (bridgman?) mentioned that the amdgpu kernel code shipped with amdgpu-pro isn't really the same amdgpu from latest drm tree. It contains pieces for vulkan and opencl, which can't be integrated upstream without userspace (policy?).

it contains one vulkan ioctl, but it is open source, just not upstreamed yet. nothing prevents you from using it with mesa opengl

[pal666]

If I recall correctly, someone (bridgman?) mentioned that the amdgpu kernel code shipped with amdgpu-pro isn't really the same amdgpu from latest drm tree. It contains pieces for vulkan and opencl, which can't be integrated upstream without userspace (policy?).

it is foss and can be used with mesa opengl and blob vulkan, just as i said