[Libre-soc-dev] Loading Vulkan Driver

[apinheiro]

On 24/8/20 11:39, vivek pandya wrote:
>
>
> On Mon, Aug 24, 2020 at 3:06 PM apinheiro <apinheiro at igalia.com 
> <mailto:apinheiro at igalia.com>> wrote:
>
>
>     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.
>
> With Debugger I have checked that it reaches upto CreateInstance() 
> implementation in my device.c
>
>>
>>     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.
>
> Could you please recall how you have tested initial commits?


Those commits were not enough to get any test working. As mentioned it 
was just the basic skeleton. Most of those methods are just empty stubs 
that doesn't do anything. So getting those methods called was the first 
starting point.

After that, our objective was trying to get a really basic Vulkan tests 
working. As mentioned, we started with a real basic test that just did a 
clear, as in that way, we didn't need to bother with the compiler yet. 
We didn't save that test though. In any case, it was really simple, so 
it should be easy to recreate.

BR


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