[Libre-soc-dev] [Mesa-dev] Loading Vulkan Driver
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Sun Aug 23 12:30:50 BST 2020
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Aug 23, 2020 at 10:36 AM vivek pandya <vivekvpandya at gmail.com> wrote:
> Hello all,
> I just cleanup a bit and commited code at :
> However it is not working as per my expectation (or my expectations are
> I want to see that driver fail at
> however in debugger control never reach there.
hm does it reach here?
(can i recommend a #ifdef VERBOSE_DEBUG and some printfs: it's crude
but effective and when restarting or when others try to replicate this
they will not need to set large numbers of breakpoints. plus, the
debug print statements become a discussion anchor / reference-point,
and a form of documentation in themselves)
about that: is there an "official" MESA macro for use to do verbose
development-level debug output? i see the radv code checks an
> I see that in
> CreateShaderModule() is defined
hmm i don't see an equivalent createShaderModule in here:
also, enumerateInstanceDeviceProperties is empty:
whereas it is not, here:
i would recommend putting debug printfs at the top of
libresoc_GetInstanceProcAddr, to get a handle (ha ha) on what
functions are being looked for. ah: it *might* also be worthwhile
actually checking out that very early version of the broadcom driver,
liberally sprinkling it with debug printfs at least at the start of
every function, and see what is called, and in which order.
by doing the same thing in the libresoc driver that would give you an
idea of what is missing.
the other thought that occurred to me: it could just be that expecting
createGraphicsPipelines to be called is too early, and that to trigger
it, a little more of the infrastructure has to be in place, such as
responding to vkinfo:
just a thought.
More information about the Libre-soc-dev