More RADV Radeon Vulkan Optimizations Are In The Works

[starshipeleven]

I don't think it's that easy. Mesa is used by FreeBSD for example, but how are you going to use it in Windows?

I'm unsure of what you mean here. Mesa supports Windows https://www.mesa3d.org/systems.html

It provides OpenGL only afaik, as the DirectX "mesa equivalent" is done by Microsoft themselves in Windows.

[Masush5]

I'm unsure of what you mean here. Mesa supports Windows https://www.mesa3d.org/systems.html

It provides OpenGL only afaik, as the DirectX "mesa equivalent" is done by Microsoft themselves in Windows.

But only software renderers run on windows, you can't just run radeonsi, nouveau or i965 on windows. There is no kernel driver interface (winsys). Not to say it would be impossible to implement, but it's definitley not trivial.
Also, hardware specific parts of the DX drivers (which is a hugh chunck) are provided by the manufacturers, not MS.

[artivision]

But only software renderers run on windows, you can't just run radeonsi, nouveau or i965 on windows. There is no kernel driver interface (winsys). Not to say it would be impossible to implement, but it's definitley not trivial.
Also, hardware specific parts of the DX drivers (which is a hugh chunck) are provided by the manufacturers, not MS.

For the first problem the solution is for the kernel driver to have a unified front layer (to hook with Mesa) for all OSs. For the second problem the solution is to rework the Crimson D3D state trackers to support NIR (keeping them closed of course). If this is not allowed they can hook the entire Crimson intermediate system to RadeonSI (wile keeping it closed and clean only for/with the D3D state trackers).

[Masush5]

For the first problem the solution is for the kernel driver to have a unified front layer (to hook with Mesa) for all OSs. For the second problem the solution is to rework the Crimson D3D state trackers to support NIR (keeping them closed of course). If this is not allowed they can hook the entire Crimson intermediate system to RadeonSI (wile keeping it closed and clean only for/with the D3D state trackers).

Right, solveable, but would require quite invasive changes to their windows driver architecture, which is the most important one for AMD. I can understand why they are in no rush to do that.

[R41N3R]

I had a dream last night about multiplatform/os code sharing strategy...
In some parallel univers, the following approach was taken:
1) OpenGL Compatibility Profiles were implemented in mesa.
2) AMD dropped proprietary OpenGL implementation.
3) They started using mesa with RADV and OpenGL on multiple Operating Systems, and have achieved 'true' Open Source code sharing.
4) Radeon Software Crimson UI was adapted to work with the OSS stack on other Operating Systems than windows.
5) More customers started using AMD products because of this transparency and fast development model.

The performance that OpenGL has on Linux, was also available in windows and customers weren't complaining anymore.
They got tremendous support from the community for bugfixing, and managed to have a code continuously improved.
Mesa OSS started to benefit in return from implementation of Compatibility Profiles, better test coverage, ISV certification, even more people from AMD involved, etc.

I think unifying drivers could only become reality (from my point of view) if you limit the kernel driver interfaces to a Vulkan driver and if you run on top of Vulkan a OpenGL, OpenCL, OpenGL ES, WebGL and DirectX implementation. There are already several projects that try to run e.g. OpenGL ES or DirectX over Vulkan, so this sounds interesting for me.

[Masush5]

I think unifying drivers could only become reality (from my point of view) if you limit the kernel driver interfaces to a Vulkan driver and if you run on top of Vulkan a OpenGL, OpenCL, OpenGL ES, WebGL and DirectX implementation. There are already several projects that try to run e.g. OpenGL ES or DirectX over Vulkan, so this sounds interesting for me.

What makes you think that a vulkan driver requires less complex kernel interfaces compared to a OGL/DX driver?

[artivision]

I think unifying drivers could only become reality (from my point of view) if you limit the kernel driver interfaces to a Vulkan driver and if you run on top of Vulkan a OpenGL, OpenCL, OpenGL ES, WebGL and DirectX implementation. There are already several projects that try to run e.g. OpenGL ES or DirectX over Vulkan, so this sounds interesting for me.

That is also a good idea.

[bridgman]

I think unifying drivers could only become reality (from my point of view) if you limit the kernel driver interfaces to a Vulkan driver and if you run on top of Vulkan a OpenGL, OpenCL, OpenGL ES, WebGL and DirectX implementation. There are already several projects that try to run e.g. OpenGL ES or DirectX over Vulkan, so this sounds interesting for me.

We are already doing this to some extent - but as soon as you add DirectX into the mix it makes open sourcing much harder. That's one of the reasons it has taken so much work & time to open source the Vulkan driver.

[artivision]

We are already doing this to some extent - but as soon as you add DirectX into the mix it makes open sourcing much harder. That's one of the reasons it has taken so much work & time to open source the Vulkan driver.

??? Plan to replace Gallium?

[Masush5]

??? Plan to replace Gallium?

Where did you get that from?
I think he meant, that open sourcing their vulkan driver is harder because it shares code with, or uses the same interfaces as, their DX driver.