[Libre-soc-dev] Loading Vulkan Driver
vivekvpandya at gmail.com
Mon Aug 24 10:58:14 BST 2020
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
>> 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
> 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?
>> 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
>>> As far as
>>> 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
>>> 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: [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.
>>> failed with ERROR_INCOMPATIBLE_DRIVER
>>> On Mon, Aug 24, 2020 at 7:18 AM Jacob Lifshay <programmerjake at gmail.com>
>>>> 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>
>>>>> > 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.
More information about the Libre-soc-dev