Linking failure #40
Assignees
Labels
Comments
|
in vkvg/CMakeList.txt, you may try to remove vkh_static from target_linked_library of tests_common: if (VKVG_BUILD_TESTS)
ADD_LIBRARY("tests_common" STATIC tests/common/vkengine.c tests/common/test.c)
TARGET_INCLUDE_DIRECTORIES(tests_common PRIVATE
${Vulkan_INCLUDE_DIRS}
${GLFW3_INCLUDE_DIR}
${CMAKE_CURRENT_SOURCE_DIR}/include
${CMAKE_CURRENT_SOURCE_DIR}/src
${CMAKE_CURRENT_SOURCE_DIR}/tests/common
${CMAKE_CURRENT_SOURCE_DIR}/vkh/include
${CMAKE_CURRENT_SOURCE_DIR}/vkh/src
)
TARGET_LINK_LIBRARIES(tests_common
${Vulkan_LIBRARIES}
${GLFW3_LIBRARY}
#vkh_static <===== HERE, vkh functions should be included in vkvg_static (put # to comment the line)
vkvg_static
)On my debian, It does not cause problem, maybe a default compiler option that remove some duplicates in static compilations. |
|
I've also remove those functions (old VK_EXT_debug_report extensions) from vkh_device.h, vkh now use the new VK_EXT_debug_utils. PFN_vkCreateDebugReportCallbackEXT CreateDebugReportCallback;
PFN_vkDestroyDebugReportCallbackEXT DestroyDebugReportCallback;
PFN_vkDebugReportMessageEXT dbgBreakCallback;I'll update the master branch with those two fixes. |
|
Thanks for looking into this! But unfortunatley still doesn't work: |
|
I've moved the implementation for those function pointers into the .c file, adding 'extern' keyword in header. (changes in master) |
|
Thanks it's compiling now! But unfortunately it crashes when I try to run any of the examples: vulkaninfo shows: |
|
I'm updating vulkan with the latest sdk. Meanwhile I've added an output log when the presentMode fallback value is fetched. presentMode is initialised with '-1', but it will choose the first available one as fallback, so I'm very surprise of a value of '-1' in the logs (on master). |
|
I see in your log that you are targeting your distribution vulkan install (Loading layer library libVkLayer_MESA_device_select.so). libVkLayer_MESA_device_select.so should not load if targeting lunarg sdk. |
|
When I say that I've add a log for present mode fallback, I was implicitly asking for you to check in your logs that you have: "Fallback present mode =>" returning a value greater than -1. (I'm not sure I've been clear enough) |
|
Hi and thanks for your continued help. I don't know why the MESA device is loading. As you saw I have an NVIDIA GTX 1070 card in my system. I just tested the Sascha Willems repo, and his demos do work. Another issue I don't understand is a simple triangle example (I think that it was modified from Sascha's repo) that I have that exit with the following error message: validation layers requested, but not available! Sigh... Getting Vulkan running certainly isn't easy. You said: | I was implicitly asking for you to check in your logs Which log? |
|
Because your validation layer points to a presentMode equal to '-1', on the master branch (update also vkh submodule), I've added a 'printf' when the requested presentMode is not available and the default one is selected (the first one returned by vulkan). So if you can run again with the latest commit from master and check the default Present mode ("Fallback present mode => X"), it would clear one of my doubt. The most important environment variable for getting the correct layers is : VK_LAYER_PATH. So check your running environment for a correct value. The more secure is to target the lunarg sdk. Mesa is loading when you use the vulkan driver from your fedora distribution. If you set LD_LIBRARY_PATH to the lunarg sdk, is should not load. Vulkan is on the road to maturity, depending on your hardware, (maybe several newer cards on linux are not fully supported) and depending on your distribution, your mesa version, your gpu drivers (open source/proprietary) there could be some difficulties. |
|
Ok, I got to the point. There was a bug. I'll update the master branch within 10 minuts. |
|
Done. |
|
Thanks!
…On Thu, Aug 13, 2020, 22:13 j-p ***@***.***> wrote:
Done.
Without entering into deep details, I was doing enum comparison with
negative value without converting it first to signed int.
Thank you for reporting, and feel free to ask for support, documentations
are on the planning.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#40 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACSSO46G7U72RR274624PLSAQ3NFANCNFSM4P5HX7GQ>
.
|
|
I guess I can close, thanks again. |
|
Thanks but unfortunately it still doesn't work for me. I guess something is wrong with my Vulkan installation, and I have no idea what it is. I still get the same behavior when running |
|
don't forget to update vkh submodule with: If Sasha W. samples are working with the MESA layer, vkvg should go with it too. |
|
It works!! Great! Now I have to figure out what to do with it. :-) Perhaps rewrite my image and vector viewer giv... http://github.com/dov/giv . |
|
Switching from cairo to vkvg should be straightforward, feel free to ask for any help. |
(I'm using this for thread for continued communication. Please let me know if you prefer somewhere else.) I'll have a closer look at vkvg now, but there are two "special" features that I need, that I wonder if you support:
(Actually I don't use cairo for the rendering but agg, but I'm certainly familiar with cairo, and it that part of the porting shouldn't be a problem.) Thanks! |
|
No problem to continue here. device = vkvg_device_create (inst, phy, vkdev, qFamIdx, qIndex);you may also use the multisampled device creation function but with sample count equal to one (VK_SAMPLE_COUNT_1_BIT). VkvgSurface is a normal vulkan image, drawing with context does not output anything on screen, it only write to that texture in gpu memory. In vkvg samples, I create a special vulkan blitting command buffer to blit the surface onto the swapchain images: So you may create a custom vulkan command buffer to copy image to a vkbuffer, or blit onto another image, or draw with a shader and use the image as a texture. |
|
Maybe I'll create in the future special surfaces which output directly to screen as cairo does (xcbSurface, win32Surf, ...) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After following the installations instructions precisely I get the following errors on my Fedora 32 system:
The text was updated successfully, but these errors were encountered: