[Libre-soc-dev] Loading Vulkan Driver

[vivek pandya]

On Mon, Aug 24, 2020 at 3:06 PM apinheiro <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?

>
>
> On Mon, Aug 24, 2020 at 2:44 PM apinheiro <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>
>> wrote:
>>
>>> On Sun, Aug 23, 2020, 18:38 Dave Airlie <airlied at gmail.com> wrote:
>>>
>>>> On Mon, 24 Aug 2020 at 10:12, Jacob Lifshay <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
>>>
>>