Hi, Il giorno mer 27 giu 2018 alle ore 10:41 Tapani Pälli < 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>>: > > > > 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 >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
