[Libre-soc-dev] Loading Vulkan Driver

[vivek pandya]

On Mon, Aug 24, 2020 at 3:26 PM apinheiro <apinheiro at igalia.com> wrote:

>
> On 24/8/20 11:39, vivek pandya wrote:
>
>
>
> 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?
>
>
> 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.
>
Okay I will write a very simple test.
One last thing, for your change and with simple test, were you able to
reach upto v3dv_CreateShaderModule() in debugger?

Thanks,
Vivek

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