[Libre-soc-dev] Loading Vulkan Driver
apinheiro
apinheiro at igalia.com
Mon Aug 24 11:04:13 BST 2020
On 24/8/20 11:58, vivek pandya wrote:
>
>
> On Mon, Aug 24, 2020 at 3:26 PM apinheiro <apinheiro at igalia.com
> <mailto: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
>> <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.
>
> 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 <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
>>>>
More information about the Libre-soc-dev
mailing list