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.pa...@intel.com <mailto:tapani.pa...@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.or...@gmail.com
<mailto:issor.or...@gmail.com>
> <mailto:issor.or...@gmail.com <mailto:issor.or...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
