vulkan port merge about kons-9 HOT 47 OPEN

from kons-9.

from kons-9.

from kons-9.

from kons-9.

oh yeah, and people who are committing to main during this process...please stop! commit your changes to the krma branch after the git maintenance is completed. the main branch should be considered read only until vulkan becomes main. otherwise we'll have to repeat the maintenance procedures over and over again.

from kons-9.

Thanks for doing this @awolven . As a reminder, I hope to keep the OpenGL version working as an option even after the Vulkan merge.

I plan to add some features to main in the coming days, but will refrain from doing so once someone starts working on this task.

from kons-9.

@awolven On running the kons-9 krma branch, some errors occurr. Please can you suggest how to remedy them.

System: Linux, x11 (XFCE desktop on kubuntu 23.04)
GPU: AMD Radeon graphics (512 MB)

KONS-9> vk::(physical-device (default-logical-device *app*))
#<GPU AMD Radeon Graphics (RADV RENOIR)>
KONS-9> (princ vk::*present-mode*)
1
1

Following are the steps which were done:

• clone awolven/kons-9
• checkout krma branch in local
• git submodule update --init --recursive
• (kons-9:run)

Evaluating the last step (kons-9:run) within SLIME, caused the kons-9 window to open but it seems to be non-responsive and usual interactions of mouse, keyboard (for menu) do not respond. Closing the window too, doesn't work normally.

The following error gets printed many (13) times in the slime repl:

[vulkan] ObjectType: 3
Message: Validation Error: [ VUID-VkGraphicsPipelineCreateInfo-pDynamicStates-00749 ] Object 0: handle = 0x557015349df0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x1b1ca73 | The line width state is static (pCreateInfos[0].pDynamicState->pDynamicStates does not contain VK_DYNAMIC_STATE_LINE_WIDTH) and VkPhysicalDeviceFeatures::wideLines is disabled, but pCreateInfos[0].pRasterizationState->lineWidth (=2.000000) is not 1.0. The Vulkan spec states: If the pipeline is being created with pre-rasterization shader state, and the wideLines feature is not enabled, and no element of the pDynamicStates member of pDynamicState is VK_DYNAMIC_STATE_LINE_WIDTH, the lineWidth member of pRasterizationState must be 1.0 (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkGraphicsPipelineCreateInfo-pDynamicStates-00749)

This error gets printed twice:

[vulkan] ObjectType: 6
Message: Validation Error: [ VUID-vkCmdDrawIndexed-None-02859 ] Object 0: handle = 0x5570154f0660, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x780000000078, type = VK_OBJECT_TYPE_PIPELINE; | MessageID = 0x93e69b0a | vkCmdDrawIndexed: VkPipeline 0x780000000078[] doesn't set up VK_DYNAMIC_STATE_LINE_WIDTH, but it calls the related dynamic state setting commands The Vulkan spec states: There must not have been any calls to dynamic state setting commands for any state not specified as dynamic in the VkPipeline object bound to the pipeline bind point used by this command, since that pipeline was bound (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdDrawIndexed-None-02859)

This error gets printed twice:

[vulkan] ObjectType: 6
Message: Validation Error: [ VUID-vkCmdSetLineWidth-lineWidth-00788 ] Object 0: handle = 0x5570154f0660, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x3d555d77 | VkPhysicalDeviceFeatures::wideLines is disabled, but lineWidth (=3.000000) is not 1.0. The Vulkan spec states: If the wideLines feature is not enabled, lineWidth must be 1.0 (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdSetLineWidth-lineWidth-00788)

from kons-9.

@awolven Here's the result with krma standalone:

System: Linux, x11 (XFCE desktop on kubuntu 23.04)

KONS-9> vk::(physical-device (default-logical-device *app*))
#<GPU AMD Radeon Graphics (RADV RENOIR)>
KONS-9> (princ vk::*present-mode*)
1
1

Following steps were done:
git clone [email protected]:awolven/krma.git
cd krma/
git submodule update --init --recursive
Downloaded VulkanSDK
edited GLSL_COMPILER in krma/compile.sh
./compile.sh
edited version in krma/submodules/cl-vulkan/ifc/load-libraries.lisp

CL-USER> (pushnew "path/to/krma/" asdf:*central-registry* :test #'equalp)
CL-USER> (ql:quickload :krma)
CL-USER> (krma:run)
#<SIMPLE-TASKS:CALL-TASK :FUNC #<FUNCTION (LAMBDA () :IN KRMA:RUN) {1003E3851B}> :STATUS :SCHEDULED {1004381CE3}>

Following error printed 13 times:

[vulkan] ObjectType: 3
Message: Validation Error: [ VUID-VkGraphicsPipelineCreateInfo-pDynamicStates-00749 ] Object 0: handle = 0x5618562716f0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x1b1ca73 | The line width state is static (pCreateInfos[0].pDynamicState->pDynamicStates does not contain VK_DYNAMIC_STATE_LINE_WIDTH) and VkPhysicalDeviceFeatures::wideLines is disabled, but pCreateInfos[0].pRasterizationState->lineWidth (=2.000000) is not 1.0. The Vulkan spec states: If the pipeline is being created with pre-rasterization shader state, and the wideLines feature is not enabled, and no element of the pDynamicStates member of pDynamicState is VK_DYNAMIC_STATE_LINE_WIDTH, the lineWidth member of pRasterizationState must be 1.0 (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkGraphicsPipelineCreateInfo-pDynamicStates-00749)

CL-USER> (krma:add-text "The quick brown fox jumped over the lazy dog." 100 200)
; No value

No error when printing the above text

CL-USER> (krma:add-2d-line 0 0 100 100 :color #x0000ffff)
; No value

Line gets drawn but the repl logs a continuous stream of the below errors which never stop:

[vulkan] ObjectType: 6
Message: Validation Error: [ VUID-vkCmdSetLineWidth-lineWidth-00788 ] Object 0: handle = 0x5618567bdc00, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x3d555d77 | VkPhysicalDeviceFeatures::wideLines is disabled, but lineWidth (=2.000000) is not 1.0. The Vulkan spec states: If the wideLines feature is not enabled, lineWidth must be 1.0 (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdSetLineWidth-lineWidth-00788)

[vulkan] ObjectType: 6
Message: Validation Error: [ VUID-vkCmdDrawIndexed-None-02859 ] Object 0: handle = 0x5618567bdc00, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x420000000042, type = VK_OBJECT_TYPE_PIPELINE; | MessageID = 0x93e69b0a | vkCmdDrawIndexed: VkPipeline 0x420000000042[] doesn't set up VK_DYNAMIC_STATE_LINE_WIDTH, but it calls the related dynamic state setting commands The Vulkan spec states: There must not have been any calls to dynamic state setting commands for any state not specified as dynamic in the VkPipeline object bound to the pipeline bind point used by this command, since that pipeline was bound (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdDrawIndexed-None-02859)

[vulkan] ObjectType: 6
Message: Validation Error: [ VUID-vkCmdSetLineWidth-lineWidth-00788 ] Object 0: handle = 0x561856584e70, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x3d555d77 | VkPhysicalDeviceFeatures::wideLines is disabled, but lineWidth (=2.000000) is not 1.0. The Vulkan spec states: If the wideLines feature is not enabled, lineWidth must be 1.0 (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdSetLineWidth-lineWidth-00788)

[vulkan] ObjectType: 6
Message: Validation Error: [ VUID-vkCmdDrawIndexed-None-02859 ] Object 0: handle = 0x561856584e70, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x420000000042, type = VK_OBJECT_TYPE_PIPELINE; | MessageID = 0x93e69b0a | vkCmdDrawIndexed: VkPipeline 0x420000000042[] doesn't set up VK_DYNAMIC_STATE_LINE_WIDTH, but it calls the related dynamic state setting commands The Vulkan spec states: There must not have been any calls to dynamic state setting commands for any state not specified as dynamic in the VkPipeline object bound to the pipeline bind point used by this command, since that pipeline was bound (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdDrawIndexed-None-02859)

[vulkan] ObjectType: 6
Message: Validation Error: [ VUID-vkCmdSetLineWidth-lineWidth-00788 ] Object 0: handle = 0x561856588ca0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x3d555d77 | VkPhysicalDeviceFeatures::wideLines is disabled, but lineWidth (=2.000000) is not 1.0. The Vulkan spec states: If the wideLines feature is not enabled, lineWidth must be 1.0 (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdSetLineWidth-lineWidth-00788)

[vulkan] ObjectType: 6
Message: Validation Error: [ VUID-vkCmdDrawIndexed-None-02859 ] Object 0: handle = 0x561856588ca0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x420000000042, type = VK_OBJECT_TYPE_PIPELINE; | MessageID = 0x93e69b0a | vkCmdDrawIndexed: VkPipeline 0x420000000042[] doesn't set up VK_DYNAMIC_STATE_LINE_WIDTH, but it calls the related dynamic state setting commands The Vulkan spec states: There must not have been any calls to dynamic state setting commands for any state not specified as dynamic in the VkPipeline object bound to the pipeline bind point used by this command, since that pipeline was bound (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdDrawIndexed-None-02859)

[vulkan] ObjectType: 6
Message: Validation Error: [ VUID-vkCmdSetLineWidth-lineWidth-00788 ] Object 0: handle = 0x5618565b8eb0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x3d555d77 | VkPhysicalDeviceFeatures::wideLines is disabled, but lineWidth (=2.000000) is not 1.0. The Vulkan spec states: If the wideLines feature is not enabled, lineWidth must be 1.0 (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdSetLineWidth-lineWidth-00788)

[vulkan] ObjectType: 6
Message: Validation Error: [ VUID-vkCmdDrawIndexed-None-02859 ] Object 0: handle = 0x5618565b8eb0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x420000000042, type = VK_OBJECT_TYPE_PIPELINE; | MessageID = 0x93e69b0a | vkCmdDrawIndexed: VkPipeline 0x420000000042[] doesn't set up VK_DYNAMIC_STATE_LINE_WIDTH, but it calls the related dynamic state setting commands The Vulkan spec states: There must not have been any calls to dynamic state setting commands for any state not specified as dynamic in the VkPipeline object bound to the pipeline bind point used by this command, since that pipeline was bound (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdDrawIndexed-None-02859)

[vulkan] ObjectType: 6
Message: Validation Error: [ VUID-vkCmdSetLineWidth-lineWidth-00788 ] Object 0: handle = 0x5618565ff130, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x3d555d77 | VkPhysicalDeviceFeatures::wideLines is disabled, but lineWidth (=2.000000) is not 1.0. The Vulkan spec states: If the wideLines feature is not enabled, lineWidth must be 1.0 (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdSetLineWidth-lineWidth-00788)

[vulkan] ObjectType: 6
Message: Validation Error: [ VUID-vkCmdDrawIndexed-None-02859 ] Object 0: handle = 0x5618565ff130, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x420000000042, type = VK_OBJECT_TYPE_PIPELINE; | MessageID = 0x93e69b0a | vkCmdDrawIndexed: VkPipeline 0x420000000042[] doesn't set up VK_DYNAMIC_STATE_LINE_WIDTH, but it calls the related dynamic state setting commands The Vulkan spec states: There must not have been any calls to dynamic state setting commands for any state not specified as dynamic in the VkPipeline object bound to the pipeline bind point used by this command, since that pipeline was bound (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdDrawIndexed-None-02859)

from kons-9.

from kons-9.

Thanks for your reply. I will start working on this once the above changes and instructions for building the new karma are ready.

from kons-9.

This is awesome. Will try to compile and run it shortly. Curious how it will work on my Linux environment. Will try a few other environments as well.

from kons-9.

just tried cloning and running. I cannot replicate the following submodules:

• 3d-math
• clui

As I am not part of the conversation, there is no need to give me perms to replicate those submodules. Just mentioning this if this is not related to perms necessary for those submodules for anyone that wants to test.

Thanks.

from kons-9.

from kons-9.

Results:

1. git clone @.***/awolven/clui.git <-- reply: repository does not exist (makes sense)

2. git clone @.***:awolven/d-math.git <-- Reply:

Cloning into '3d-math'...
[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists

3. git clone @.***:awolven/clui.git <-- Reply:

Cloning into 'clui'...
[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I am not entirely sure what to make of that. I can git clone all of the other submodules just fine. When I go to the following url I cannot browse those two repos: https://github.com/awolven/krma/tree/main/submodules

from kons-9.

from kons-9.

from kons-9.

Aha! That worked! Thank you kindly.

from kons-9.

from kons-9.

from kons-9.

from kons-9.

Thanks for the updates... sorry it took me a while to respond.
While trying to run krma, I came across a couple of errors.

1. One error seems related to an unqualified reference to defcfun here: ifc/glfw/glfw.lisp#L866
2. Another error - Unknown CFFI type VKINSTANCE - which occurs near the above quoted line. I couldn't figure how to fix this. This full error is:

; in: CFFI:DEFCFUN ("glfwCreateWindowSurface" GLFWCREATEWINDOWSURFACE)
; (CFFI:DEFCFUN ("glfwCreateWindowSurface" $GLFW::GLFWCREATEWINDOWSURFACE)
; $GLFW::VKRESULT
; ($GLFW::INSTANCE $GLFW::VKINSTANCE)
; ($GLFW::WINDOW :POINTER)
; ($GLFW::ALLOCATOR (:POINTER (:STRUCT $GLFW::VKALLOCATIONCALLBACKS)))
; ($GLFW::SURFACE (:POINTER $GLFW::VKSURFACEKHR)))
;
; caught COMMON-LISP:ERROR:
; (during macroexpansion of (CFFI:DEFCFUN ("glfwCreateWindowSurface" GLFWCREATEWINDOWSURFACE)
; ...))
; Unknown CFFI type VKINSTANCE

As you had mentioned you had written a CL alternative to GLFW and since the code has conditionals +noglfw, I did a (pushnew :noglfw *features*) which bypassed both the above glfw related errors.

I again tried running krma and ran into one more error which I couldn't figure out:

; file: /home/kayo/projects/kons-9-prj/krma/submodules/cl-vulkan/src/x11.lisp
; in: DEFUN CREATE-X11-WINDOW-SURFACE
; (NOFFI-C::|XGetXCBConnection| (CLUI:H VK::DISPLAY))
;
; caught ERROR:
; during macroexpansion of (#_XGetXCBConnection (H DISPLAY)). Use
; BREAK-ON-SIGNALS to intercept.
;
; Undeclared identifier #_XGetXCBConnection

does the #_ prefix have any significance or is it a typo? did a brief search about this to no avail.

btw, what should be the correct way to add :noglfw to *features*?
Thanks.

from kons-9.

from kons-9.

make sure you have /usr/include/X11/Xlib-xcb.h

It was missing. To install it I installed (on linux) libx11-xcb-dev

For some reason, (ql:quickload :krma) still results in the error:

; file: /home/kayo/projects/kons-9-prj/krma/submodules/cl-vulkan/src/x11.lisp
; in: DEFUN CREATE-X11-WINDOW-SURFACE
; (NOFFI-C::|XGetXCBConnection| (CLUI:H VK::DISPLAY))
;
; caught ERROR:
; during macroexpansion of (#_XGetXCBConnection (H DISPLAY)). Use
; BREAK-ON-SIGNALS to intercept.
;
; Undeclared identifier #_XGetXCBConnection

I checked to make sure I have the full list of include files in krma/submodules/clui/x11/x11.lisp

btw, is the #_ prefix related to clui?

from kons-9.

from kons-9.

I evaluated your above suggestions and krma is working now! Thanks:)

Evaluated (ql:quickload :krma) followed by your earlier steps:

(trivial-main-thread:call-in-main-thread #'(lambda () (krma:main
(make-instance 'krma::krma-test-application))))
(krma:add-2d-line 100 100 200 200 :color #xffff00ff)
(krma:add-text "Sample Text" 250 200)

The line and sample text are successfully rendered.

quickload is really of limited utility: it fetches dependencies for you but it
will not recompile sources, you have to force these dependencies to recompile

It did occur me that recompiling might be needed after installing the missing
header /usr/include/X11/Xlib-xcb.h but I didn't know how to do that. So, I did
a rm -rf ~/quicklisp and then reinstalled quicklisp but obviously that must
not have worked. I now guess that is because the compiled output resides in the
respective submodules, correct?

I guess what you suggested above (asdf:oos 'asdf:load-op ... :force t)
does the recompiling. I will need to dig into it to understand things better.

Will go ahead with the next steps, thanks for your patience.

from kons-9.

from kons-9.

Okay, I now understand. Thanks.

from kons-9.

from kons-9.

I have 2 home office setups.

Both are laptops with 15.6" display (1920x1080),
integrated graphics, no video cards.

1. Laptop with Intel Iris Xe Graphics, vram shared with 62G sys ram.
   2 external monitors:
   Benq EW3270U 31.5" 4K (VA panel)
   Dell Ultrasharp U2412M 24" (1920x1200) (TFT LCD) (Mfg in 2013)

2. Laptop with AMD Radeon Vega 7 graphics , vram 512MB dedicated, 32GB total
   1 external monitor:
   Benq EW3270U 31.5" 4K (VA panel) (same as above)

I haven't done graphics intesive work since years.

What kind of video card / GPU / monitor specs do you use?

from kons-9.

from kons-9.

I get the best video performance using the display port cable, totally smooth
animation with no artifacts. (144 fps)

That's nice to have. My laptops don't have a display port, else i would have
given it a try.

One of my laptops provides just 1 video out which is HDMI (the laptop also has a
usb-c port but one which doesn't support video) and so I have only 1 external
Benq display. I can't connect another external display which I would personally
liked to have (I have another Dell 24" display lying around). The laptop
graphics might be able support another external display and at one point I did a
bit of research if I might be able to daisy chain two external displays but
there are too many unknowns as I would have to convert the only HDMI out of the
laptop to Display port because the Dell displays do not have HDMI. iirc the Dell
displays being relatively old (2013) have some limit on the daisy chaining, so I
gave up in order to be able to get work done:)

Another downside I have is that despite having a Benq 4K monitor I ashamedly run
my linux (xfce) desktop at 2K, else fonts and icons appear too small for me and
I think in order to increase font and icon sizes they would need to be setup
differently for different apps. I also remember setting a larger default font on
some web browser but it caused some sites not to display as expected. Running at
2K gets rid of these issues. Now that I'm mentioning it, I think I'll give
another go running at 4K having since I've just moved to a newer linux
distribution.

CLUI can detect your monitors and get the pixel width/height and mm
width/height, so you can compute pixels/millimeters for each monitor. I
haven't found a way to ask a window what monitor it is on yet, but I'm sure
it is doable. So for multi-monitor setups you would want to ask the window
what monitor it is on and get the pixels/millimeters of the monitor to draw
UI elements such as fonts and buttons. I also need to set up an event
where if the window changes monitors it will signal so the scaling can
change. Just need to do a little more research, it has to work for all
three platforms. Also I have noticed KDE multi monitor support is jenky.

Let me know if I can help in any way by testing or try things out on a multi
monitor setup.

from kons-9.

from kons-9.

I have not yet got a chance to work on it but I plan to do so this weekend.

from kons-9.

have started working on this and am a bit stuck: when loading both systems -
krma as well as kons-9, the application window does not pop up.

Steps:

1. To central-registry push paths ...krma/ and ...kons-9/
2. (asdf:load-system :krma)
3. (asdf:load-system :kons-9)
4. (trivial-main-thread:call-in-main-thread #'(lambda () (krma:main (make-instance 'krma::krma-test-application))))

Nothing happens - below is the repl output:

CL-USER> (trivial-main-thread:call-in-main-thread #'(lambda () (krma:main
(make-instance 'krma::krma-test-application))))
#<SIMPLE-TASKS:CALL-TASK :FUNC #<FUNCTION (LAMBDA ()) {547FCB1B}> :STATUS :SCHEDULED {10073A2A03}>

On skipping step 3 [which loads kons-9], the krma app window successfully
appears - below is the repl output:

CL-USER> (trivial-main-thread:call-in-main-thread #'(lambda () (krma:main
(make-instance 'krma::krma-test-application))))
#<SIMPLE-TASKS:CALL-TASK :FUNC #<FUNCTION (LAMBDA ()) {5430217B}> :STATUS :SCHEDULED {10018A2023}>
WARNING:
Physical device #<GPU AMD Radeon Graphics (RADV RENOIR)> may not have feature lineRasterization.
[vulkan] ObjectType: 9
Message: Validation Error: [ VUID-vkBindBufferMemory-bufferDeviceAddress-03339 ] Object 0: handle = 0x50000000005, type = VK_OBJECT_TYPE_BUFFER; | MessageID = 0x44a78781 | vkBindBufferMemory(): If buffer was created with the VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT bit set, memory must have been allocated with the VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT bit set. The Vulkan spec states: If the VkPhysicalDeviceBufferDeviceAddressFeatures::bufferDeviceAddress feature is enabled and buffer was created with the VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT bit set, memory must have been allocated with the VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT bit set (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkBindBufferMemory-bufferDeviceAddress-03339)

Interestingly, on closing the app and re-running the below, nothing happens:

CL-USER> (trivial-main-thread:call-in-main-thread #'(lambda () (krma:main
(make-instance 'krma::krma-test-application))))
#<SIMPLE-TASKS:CALL-TASK :FUNC #<FUNCTION (LAMBDA ()) {543150AB}> :STATUS :RUNNING {1006BAFE03}>

My first step was to add :krma to the :depends-on list in kons-9.asd so that
(ql:quickload :kons-9) automatically loads :krma which is when I noticed the
above. So I went a step back, removed :krma from the :depends-on list and tried
loading each of them as done above.

from kons-9.

btw on closing the krma standalone app window, a spew of messages occurs in the repl:

[vulkan] ObjectType: 1
Message: Validation Error: [ VUID-vkDestroyCommandPool-commandPool-parameter ] Object 0: handle = 0x56486bd09ac0, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x106044c7 | Invalid VkCommandPool Object 0x20000000002. The Vulkan spec states: If commandPool is not VK_NULL_HANDLE, commandPool must be a valid VkCommandPool handle (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkDestroyCommandPool-commandPool-parameter)

[vulkan] ObjectType: 25
Message: Validation Error: [ UNASSIGNED-Threading-Info ] Object 0: handle = 0x20000000002, type = VK_OBJECT_TYPE_COMMAND_POOL; | MessageID = 0x5d6b67e2 | Couldn't find VkCommandPool Object 0x20000000002. This should not happen and may indicate a bug in the application.

[vulkan] ObjectType: 25
Message: Validation Error: [ UNASSIGNED-Threading-Info ] Object 0: handle = 0x20000000002, type = VK_OBJECT_TYPE_COMMAND_POOL; | MessageID = 0x5d6b67e2 | Couldn't find VkCommandPool Object 0x20000000002. This should not happen and may indicate a bug in the application.

[vulkan] ObjectType: 25
Message: Validation Error: [ UNASSIGNED-Threading-Info ] Object 0: handle = 0x20000000002, type = VK_OBJECT_TYPE_COMMAND_POOL; | MessageID = 0x5d6b67e2 | Couldn't find VkCommandPool Object 0x20000000002. This should not happen and may indicate a bug in the application.

[vulkan] ObjectType: 25
Message: Validation Error: [ UNASSIGNED-Threading-Info ] Object 0: handle = 0x20000000002, type = VK_OBJECT_TYPE_COMMAND_POOL; | MessageID = 0x5d6b67e2 | Couldn't find VkCommandPool Object 0x20000000002. This should not happen and may indicate a bug in the application.

Then, a message similar to the following is printed over 120 times:

[vulkan] ObjectType: 3
Message: Validation Error: [ VUID-vkDestroyDevice-device-00378 ] Object 0: handle = 0x56486c651c90, type = VK_OBJECT_TYPE_DEVICE; Object 1: handle = 0x6b000000006b, type = VK_OBJECT_TYPE_BUFFER; | MessageID = 0x71500fba | OBJ ERROR : For VkDevice 0x56486c651c90[], VkBuffer 0x6b000000006b[] has not been destroyed. The Vulkan spec states: All child objects created on device must have been destroyed prior to destroying device (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkDestroyDevice-device-00378)

from kons-9.

from kons-9.

Thanks for the tip. In the inferior-lisp buffer, I evaluated
(trivial-main-thread:call-in-main-thread #'(lambda () (krma:main (make-instance 'krma::krma-test-application))))

In the bad case (both :krma and :kons-9 loaded), the error is:

There is no applicable method for the generic function
#<STANDARD-GENERIC-FUNCTION CLUI::COMPUTE-MAKE-DISPLAY-INSTANCE-ARGUMENTS (2)>
when called with arguments
(#<CLUI:DISPLAY {1006A03B73}> NIL NIL T T NIL NIL T :X11 T
:VULKAN T :OPENGL T).
[Condition of type SB-PCL::NO-APPLICABLE-METHOD-ERROR]

To compare the arguments in the good case, I did a trace:

(trace CLUI::compute-make-display-instance-arguments)

Trace in the good case (only :krma loaded) prints:

0: (CLUI::COMPUTE-MAKE-DISPLAY-INSTANCE-ARGUMENTS #<CLUI:DISPLAY {1003884303}> NIL NIL NIL T NIL NIL T :X11 T :VULKAN T)
0: CLUI::COMPUTE-MAKE-DISPLAY-INSTANCE-ARGUMENTS returned
(# :X11 T :VULKAN T)

While in bad case (:krma and :kons-9 loaded) it is called with args:

0: (CLUI::COMPUTE-MAKE-DISPLAY-INSTANCE-ARGUMENTS #<CLUI:DISPLAY {1006A03B73}> NIL NIL T T NIL NIL T :X11 T :VULKAN T :OPENGL T)

btw after looking at the appropriate method definition (which is below) it looks like the arguments in the bad case correspond to the below method, right? so it should not have resulted in There is no applicable method for the generic function right> does this mean that for some reason the method for the generic function is no longer available when :kons-9 is also loaded?

file: clui/compute-concrete-class.lisp

(defmethod compute-make-instance-arguments ((protocol display)
				    &rest initargs &key
						     (cocoa nil)
						     (metal nil)
						     (opengl nil)
						     (vulkan nil)
						     (wayland nil)
						     (win32 nil)
						     (x11 nil)
				    &allow-other-keys)

(apply #'compute-make-display-instance-arguments protocol
 cocoa
 metal
 opengl
 vulkan
 wayland
 win32
 x11
 initargs))

from kons-9.

from kons-9.

hmm... if it's related to bashing of definitions, there must be warnings to look
out for... I will continue to debug this further tomorrow.

from kons-9.

from kons-9.

understood - I will get started using #+opengl

from kons-9.

btw other than conditional reader macros like #+opengl are there any other
techniques to conditionally compile code?

from kons-9.

btw I have a trivial question.

A few comments above you had suggested:

(asdf:oos 'asdf:load-op :clui :force t)
if that succeeds:
(push "~/krma/submodules/cl-vulkan/" asdf:central-registry)
(asdf:oos 'asdf:load-op :cl-vulkan :force t)
quit and restart lisp
(asdf:oos 'asdf:load-op :krma :force t)

I was wondering what was the reason to restart lisp. Was it just to clear out
any inconsistent state after forcing compilation or any other reason?

from kons-9.

understood, thanks

from kons-9.

Andrew, thanks for your help in getting started. I've gone through
krma/documentation and your work in github.com/awolven/kons-9.git krma
branch. I've started integrating it but it might take me a while to work through
this - for the next few weeks I might only get weekends to work on it but I will
see it through.

from kons-9.

@kaveh808 @awolven apologies for no updates on this task. My daugther was unwell
with high grade fever and we had a tough time for ten days. She's absolutely
fine now but I have a pile of backlog which I am unable to catch up with and
hence not been able to work on this task. If anyone else reading this wants to
give it a shot please go ahead, else I will try to get back at it after a couple
of months.

from kons-9.

No worries at all @kayomarz I'm glad your daughter is well now.

from kons-9.