[Libre-soc-dev] Loading Vulkan Driver

[apinheiro]

On 24/8/20 11:23, vivek pandya wrote:
> Following output is generated due to my printfs.
>
> GetInstanceProcAddr called for: vkCreateInstance
> GetInstanceProcAddr called for: vkEnumerateInstanceExtensionProperties
> GetInstanceProcAddr called for: vkDestroyInstance
>
> Also I see the correct path from where ICD is being loaded.

Where those printfs are placed? As far as I see those are on the loader 
directly. My advice was about to put the printf on your vulkan method 
implementations, to confirm if they are being called.

>
> I don't have any other vulkan tests for now. I will build mesa-demos 
> and test.


Then it will be really likely that more methods that the bare minimum 
would be called. Taking into account that your plan is starting as small 
as possible, I think that you should start writing a small vulkan test 
calling as less as possible vulkan methods, even if it doesn't do 
anything at all. At least until you get your vulkan methods 
implementation being properly loaded and called.


>
> On Mon, Aug 24, 2020 at 2:44 PM apinheiro <apinheiro at igalia.com 
> <mailto:apinheiro at igalia.com>> wrote:
>
>
>     On 24/8/20 10:25, vivek pandya wrote:
>>     Removing a few people who may not be interested in low level
>>     testing details.
>>     As far as
>>     https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e
>>     this commit is concerned following output seems correct as there
>>     are no extensions enabled so loader will just destroy the
>>     instance am I correct?
>
>
>     I'm not sure why not having extension is related at all to what
>     the loader does. That commit includes a basic implementation for
>     that method. And as we are not supporting extensions, it is really
>     likely that the output would be mostly empty.
>
>     The loader would be just there to load the entrypoints. What your
>     program does with the info coming from calling those methods it is
>     independent of the loader. I really doubt the loader to do
>     something like destroy the instance just because
>     vkEnumerateInstanceExtensionProperties returns an empty set. It is
>     more likely that it is your program the one calling vkDestroyInstance.
>
>
>>
>>     DEBUG: Searching for ICD drivers named
>>     /home/vivek/install/lib/x86_64-linux-gnu/libvulkan_libresoc.so
>>     GetInstanceProcAddr called for: vkCreateInstance
>>     GetInstanceProcAddr called for:
>>     vkEnumerateInstanceExtensionProperties
>>     DEBUG: Build ICD instance extension list
>>     DEBUG: Build ICD instance extension list
>>     GetInstanceProcAddr called for: vkDestroyInstance
>>     WARNING:
>>     WARNING: [Loader Message] Code 0 : terminator_CreateInstance:
>>     Failed to CreateInstance and find entrypoints with ICD.  Skipping
>>     ICD.
>
>
>     Are you sure that you are using the correct ICD and that your
>     stubs are being called? you can use gdb or just silly printfs to
>     verify that.
>
>
>>     WARNING: terminator_CreateInstance: Failed to CreateInstance and
>>     find entrypoints with ICD. Skipping ICD.
>>     Cannot create Vulkan instance.
>>     This problem is often caused by a faulty installation of the
>>     Vulkan driver or attempting to use a GPU that does not support
>>     Vulkan.
>>     /build/vulkan-tools-KEbD_A/vulkan-tools-1.2.131.1+dfsg1/vulkaninfo/vulkaninfo.h:371:
>>     failed with ERROR_INCOMPATIBLE_DRIVER
>>
>>
>>     On Mon, Aug 24, 2020 at 7:18 AM Jacob Lifshay
>>     <programmerjake at gmail.com <mailto:programmerjake at gmail.com>> wrote:
>>
>>         On Sun, Aug 23, 2020, 18:38 Dave Airlie <airlied at gmail.com
>>         <mailto:airlied at gmail.com>> wrote:
>>
>>             On Mon, 24 Aug 2020 at 10:12, Jacob Lifshay
>>             <programmerjake at gmail.com
>>             <mailto:programmerjake at gmail.com>> wrote:
>>             > no, that is the existing LLVM backend from AMD's
>>             opengl/opencl drivers. amdvlk came later.
>>
>>             Those are the same codebase, amdvlk just uses a fork of
>>             llvm, but the
>>             differences are only minor changes for impedance mismatch
>>             and release
>>             timing, they never diverge more than necessary.
>>
>>
>>         yeah, what I had meant is that the llvm amdgpu backend was
>>         not originally created for amdvlk, since amdvlk didn't exist
>>         then.
>>
>>         Jacob
>>