If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
That actually brings an interesting angle as to whether radv will in the end be less maintenance if it shares a lot of code with the existing Mesa GL drivers
There are no plans for AMD to officially support RADV to my knowledge. The openGL and Vulkan for AMDGPU-PRO, AFAIK, is based on the same source as the Windows driver, thus very easy to support due to the shared os development. I would doubt that AMD will ever officially support RADV, due to the plans to open source the Vulkan driver. Maintaining two drivers, such as what is happening with the openGL driver right now, is not likely desired. This is the motivation behind the ROCM openCL driver, rather than supporting the mesa openCL driver.
to making use of more shared/common code with RadeonSI Gallium3D.
Am I correct in understanding that:
- AMDGPU is the kernel driver
- RadeonSI is the user-space driver for AMDGPU and is part of Mesa
- Gallium3D is a Mesa framework in which RadeonSI is based
- AMDGPU is the kernel driver
- RadeonSI is the user-space driver for AMDGPU and is part of Mesa
- Gallium3D is a Mesa framework in which RadeonSI is based
Can anyone clarify this for me?
- RadeonSI is the user-space driver for both the radeon and AMDGPU kernel drivers and is part of Mesa
- radeon kernel driver is still the default for older cards gcn 1.0 and 1.1 although AMDGPU has experimental support for them
- AMDGPU is the path forward for all newer cards
- XOrg has separate drivers for AMDGPU and radeon kernel drivers
EDIT: Updated after kisak noted my mistakes.
Last edited by boombatower; 18 May 2017, 07:43 PM.
Maybe RADV turned out so well that they will just adopt it?
Fingers crossed.
fingers crossed for moving fixes from amd vulkan to radv via radeons lol?
i would like your self-punishing wish to be fulfilled, if it would be possible to do so without affecting me. unfortunately, it is not possible, so no, we will not see idiotic solutions just to please you
When/if AMD release their code, it may provide some "inspiration", but at this time I no longer believe it will ever get into Mesa. AMD blew the chance to have a single universal Vulkan driver for their chips.
you are delusional. amd has single universal vulkan driver for their chips. it works across operating systems and across all their cards. and its development is funded by other (non-linux)99% of amd customers. radv "works" only on linux and only on two cards
That actually brings an interesting angle as to whether radv will in the end be less maintenance if it shares a lot of code with the existing Mesa GL drivers
radv in the end will be infinitely more maintenance because it shares zero code with windows vulkan
you are delusional. amd has single universal vulkan driver for their chips. it works across operating systems and across all their cards. and its development is funded by other (non-linux)99% of amd customers. radv "works" only on linux and only on two cards
Pot calling kettle black. RADV is now the Linux driver going forward. The "Pro" AMD driver will be for "Pro" user only.
Uhm... Both RADV and Intels Vulkan drivers are part of Mesa. There is no other "Vulkanesa" for AMDs driver to be part of.
Pot calling kettle black. RADV is now the Linux driver going forward. The "Pro" AMD driver will be for "Pro" user only.
Did you smell the sarcasm?
Also the funny bit is that once kernel support for early gcn chips for amdgpu goes mainstream, having radv support them too will probably happen fast. AMD's own Vulkan driver needs that too so not much difference
Comment