[Mesa-dev] RFC about anv change that should be applicable to radv

[Mauro Rossi]

Hi,

Il giorno mer 27 giu 2018 alle ore 10:41 Tapani Pälli <
tapani.palli at intel.com> ha scritto:

> Hi;
>
> On 06/13/2018 09:32 AM, Mauro Rossi wrote:
> > +Samuel Pitoiset
> >
> >
> > 2018-06-11 22:31 GMT+02:00 Mauro Rossi <issor.oruam at gmail.com
> > <mailto:issor.oruam at gmail.com>>:
> >
> >     Hi Bas,
> >
> >     commit [1] removed a check on 'supported' attribute in
> >     src/intel/vulkan/anv_entrypoints_gen.py
> >
> >     Should the check on 'supported' attribute be removed also in
> >     src/amd/vulkan/radv_entrypoints_gen.py ?
>
> Yes
>

Infact with that change the vulkan.radv module works with amdgpu (dc=1) on
HD7790,
I'm going to submit the patch to mesa-dev.


>
> >     Thanks for your feedback
> >     Mauro
> >
> >     [1]
> >
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=63525ba730e3d8a466d7f6382a2b91f4c75dd171
> >     <
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=63525ba730e3d8a466d7f6382a2b91f4c75dd171
> >
> >
> >
> >
> > Hi Sam, Bas,
> >
> > there is an important matter regarding Android builds (android-x86)
> >
> > I have a series of patches for Android makefiles to build radv for that
> > platform,
> > they are building but they require the change in
> > src/amd/vulkan/radv_entrypoints_gen.py
> > to have the necessary entrypoints and vulkan apps starting to work.
> >
> > What I forgot to say is that I have the Android building rules ready to
> > submit to mesa-dev,
> > but they require to build libLLVM with a different name e.g libLLVM60 or
> > libLLVM_mesa and set the correct HAVE_LLVM properly
> >
> > The patches themselves would break the Android build for Intel, because
> > amd tree is built unconditionally,
> > but the libLLVM"for mesa" shared library is not in place in AOSP, Intel
> > builds and not even in android-x86 oreo,
>
> This *should* not be a problem for us since it's the dependencies set in
> product.mk that define what libraries will be built. Android-IA
> (nowadays "Celadon") should just not then list the library name built
> for radv.
>

If vulkan.radv is not added to PRODUCT_PACKAGES list then it should not be
a problem for Android-IA

The problem I'm referring to is the libLLVM shared dependency in itself

AOSP builds libLLVM from external/llvm for its own purposes, version 3.9 is
bundled with for Oreo branches,
recent mesa have ceased support for that version, so we cannot avoid
building the bundled libLLVM and for mesa we need to build libLLVM50
(different shared library module name)
because Android Build system does not allow for duplicated shared libraries
module names.

If this is not a problem I will submit the patches with Android building
rules assuming that llvm shared library can be the current i.e. libLLVM,
but in reality to build vulkan.radv for Android, libLLVM must be version
5.0 or later and requires "the trick" to side-build another external/llvm50
project.

This setup does not have many users, but upstream the Android radv patches
could make sense, if it's not disruptive for other users.
If someone know a different way or view please let me know.



>
> One issue is that anv currently builds as
> 'vulkan.$(TARGET_BOARD_PLATFORM)' which is very generic, we should
> probably have something like vulkan.anv.$(TARGET_BOARD_PLATFORM) instead
> and then use ro.hardware.vulkan=vulkan.anv.$(TARGET_BOARD_PLATFORM) in
> device.mk so that Android finds it (?)
>

vulkan.anv should be ok, as the vulkan HAL module name should not need to
depend on the $(TARGET_BOARD_PLATFORM) label

If I recall correctly for a 'vulkan.anv' named module the property is set
as:

setprop  ro.hardware.vulkan anv

if set as ro.hardware.vulkan vulkan.anv the module may not be found.

In android-x86 we plan to set  the property in init.sh, according to the
loaded drmfb module, for available vulkan hals:

for inteldrmfb         setprop ro.hardware.vulkan anv
for amdgpudrmfb   setprop ro.hardware.vulkan radv
[in the future as example] for  virtiodrmfb setprop ro.hardware.vulkan virgl

Mauro


>
>
> > so I wanted to start discussing about how to integrate ravd for Android
> > in a way that does not break other drivers builds,
> > if there are other interested users.
> >
> > Mauro
>
> // Tapani
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180627/0a04fc40/attachment-0001.html>