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

[Tapani Pälli]

On 06/27/2018 06:25 PM, Mauro Rossi wrote:
> Hi,
> 
> Il giorno mer 27 giu 2018 alle ore 10:41 Tapani Pälli 
> <tapani.palli at intel.com <mailto: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>
>      > <mailto: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 <http://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.

Hmm that sucks but I guess there is no other way around it :/

> 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 <http://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:
> 
> setpropro.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] forvirtiodrmfbsetpropro.hardware.vulkan virgl

I chose to include product platform there because "preferred paths" for 
Vulkan HAL module [1] are:

/vendor/lib/hw/vulkan.<ro.product.platform>.so
/vendor/lib64/hw/vulkan.<ro.product.platform>.so

Celadon sets name in device.mk like this:
PRODUCT_PROPERTY_OVERRIDES += ro.hardware.vulkan=project-celadon

I don't think product name is explicitly required but maybe it would be 
good to be there if it is "preferred".

[1] https://source.android.com/devices/graphics/implement-vulkan


> 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
>