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, <apinhe...@igalia.com> wrote: > > On 24/8/20 11:58, vivek pandya wrote: > > > > On Mon, Aug 24, 2020 at 3:26 PM apinheiro <apinhe...@igalia.com> wrote: > >> >> On 24/8/20 11:39, vivek pandya wrote: >> >> >> >> On Mon, Aug 24, 2020 at 3:06 PM apinheiro <apinhe...@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 <apinhe...@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 <programmerj...@gmail.com> >>>> wrote: >>>> >>>>> On Sun, Aug 23, 2020, 18:38 Dave Airlie <airl...@gmail.com> wrote: >>>>> >>>>>> On Mon, 24 Aug 2020 at 10:12, Jacob Lifshay <programmerj...@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 >>>>> >>>>
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
