[Libre-soc-dev] Loading Vulkan Driver

[vivek pandya]

Thank you Apinherio, Jason, Jacob, Dave and all other mesa devs for being
patient with my questions. For now I am able to make progress with debug
build of vulkan loader.

There are still many things to learn.

-Vivek

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

>
> On 24/8/20 11:58, vivek pandya wrote:
>
>
>
> 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?
>
>
> As I already mentioned (twice) that simple program only did a clear, so we
> could test without needing to work on the compiler side of things yet. So
> that program didn't even call v3dv_CreateShaderModule.
>
> BR
>
>
>
> 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
>>>>>
>>>>