blog:2022:1104_vulkanapp_initial_triangle_display [NervTech's Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== NervLuna: Continuing with VulkanApp restoring ======

{{tag>dev cpp 3D nervland lua bindings nervbind nervluna}}

Still restoring stuff that was already "sort of" working at some point (a long time ago) lol: so I continue with this VulkanApp I built in Lua with my binding system. And it seems there is still a lot to do on that path...

====== ======


===== Fixing the enum bindings =====

  * AS mentioned at the end of the previous post, I currently have an issue with my enums: whic seem to be considered as non-defined classes: <code>2022-10-04 19:47:10.908671 [DEBUG] Creating enum ::VkPresentModeKHR

2022-10-04 19:47:10.909671 [DEBUG] Adding type with class target name: VkPresentModeKHR, (canonical type: VkPresentModeKHR)

2022-10-04 19:47:10.910393 [DEBUG] TypeManager: Registering type {

  "VkPresentModeKHR"

}

and then:

2022-10-04 19:47:16.318061 [DEBUG] Resolving target for type: VkPresentModeKHR

2022-10-04 19:47:16.318345 [DEBUG] Couldn't resolve type target, using target name instead: VkPresentModeKHR

2022-10-04 19:47:16.318518 [DEBUG] Creating class ::VkPresentModeKHR</code>

  * => In fact the "type" for VkPresentModeKHR should really be registerd as an integer I think, let's fix that...

  * **Fixed**! But this was a bit tricky in the end: I had to introduce a new "ENUM" basic type for my types as using only int32_t for all enums would not compile (where we need the enum itself and not just an int value!)

===== TypeAliasDecl handling =====

  * One nasty issue I just noticed is that with the latest changed I introduced replacing "typedefs" with the "using" syntax, I now have an unhandled curcor type case, for instance: <code>2022-10-06 15:09:27.010095 [DEBUG] Cursor 'VkDeviceQueueCreateInfoList' of kind 'TypeAliasDecl'</code>

  * So I need to deal with this **TypeAliasDecl** type now.

  * => turned out this fix was an easy one: all I needed was to handle this TypeAliasDecl just as regular typedefs: <sxh lua>    elseif ckind == clang.CursorKind.TypedefDecl or ckind == clang.CursorKind.TypeAliasDecl then
      -- logDEBUG("(Namespace) Registering typedef for '",cname, "'")
      self:registerTypedef(cur)
    else
        logDEBUG("Cursor '",cname, "' of kind '", kindName,"'")
    end
</sxh>

===== Proper handling of class declarations =====

  * Another issue I just noticed now is that if I add class declarations somewhere like: <sxh cpp; highlight: []>namespace nvk {

class VulkanPhysicalDevice;
class VulkanInstance;
class VulkanSurface;

class NVVULKAN_EXPORT VulkanDevice : public nv::RefObject {
    NV_DECLARE_NO_COPY(VulkanDevice)
    NV_DECLARE_NO_MOVE(VulkanDevice)

};
</sxh>

  * Then I actually just get a placeholder for the classes VulkanSurface, etc... not good 🤕
  * => arrff, and this was due to usage of **logDEBUG2()** in of of the curvor visitor function... grrrr... I should really make those visitor fail harder.

  * => Cool! Now that I got this fixed, the next step is the **createSwapChain** function.

===== Improvements on vectors handling =====

  * Before I move to the swapchain creation there is another nice feature I think I should investigate a bit: and that's the automatic creation of a Vector from an input lua table. How could we do that ?
  * Let's consider for instance the VulkanInstance::create_device() method: <sxh cpp; highlight: []>auto
    create_device(const nv::StringList& extensions,
                  const QueueInfoList& queueInfos,
                  const VkPhysicalDeviceFeatures* desired_features = nullptr,
                  uint32_t devId = 0) -> nv::RefPtr<VulkanDevice></sxh>
  * This should accept a StringList, and a QueueInfoList as arguments
  * => What this means is that for Vector classes that are passed as const references, we could also accept lua tables on the stack, something like this: <sxh cpp; highlight: []>static auto _check_create_device_sig1(lua_State* L) -> bool {
	int luatop = lua_gettop(L);
	if( luatop<3 || luatop>5 ) return false;

	if( !luna_isInstanceOf(L,1,LUNA_SID("nvk::VulkanInstance")) ) return false;

	if( !luna_isInstanceOf(L,2,LUNA_SID("nv::StringList"),false) && lua_istable(L,2)!=1) return false;
	if( !luna_isInstanceOf(L,3,LUNA_SID("nvk::QueueInfoList"),false) && lua_istable(L,2)!=1 ) return false;
	if( luatop>=4 && !luna_isInstanceOf(L,4,LUNA_SID("VkPhysicalDeviceFeatures"),true) ) return false;
	if( luatop>=5 && lua_isnumber(L,5)!=1 ) return false;
	return true;
}</sxh>

  * Then when we have to retrieve the argument from the stack we need a bit of work too on the following code: <sxh cpp; highlight: []>static auto _bind_create_device_sig1(lua_State* L) -> int {
	int luatop = lua_gettop(L);
	nvk::VulkanInstance* self = Luna< nvk::VulkanInstance >::get(L,1);
	LUNA_ASSERT(self!=nullptr);

	nv::StringList* extensions = Luna< nv::StringList >::get(L,2,false);
	nvk::QueueInfoList* queueInfos = Luna< nvk::QueueInfoList >::get(L,3,false);
	VkPhysicalDeviceFeatures* desired_features = luatop>=4? Luna< VkPhysicalDeviceFeatures >::get(L,4,true) : nullptr;
	uint32_t devId = luatop>=5? (uint32_t)lua_tointeger(L,5) : (uint32_t)0;

	nv::RefPtr<nvk::VulkanDevice> res = self->create_device(*extensions, *queueInfos, luatop>=4 ? desired_features : nullptr, devId);
	Luna< nvk::VulkanDevice >::push(L, res.get(), true);

	return 1;
}</sxh>

  * In fact we need so much refactoring here that I'm not sure it's worth it in the end 🤔... We need some storage for the StringList we may have to create for instance if we have a table ?... or maybe we could tweak the get() function directly ?? Nnnaaayy: that's sounds too tricky.
  * So let's say we put an object on the stack, then we could use something like this: <sxh cpp; highlight: []>
nv::StringList extensions_list;
nv::StringList* extensions = &extensions_list;
if(lua_istable(L, 2)==1) {
  // Populate the extensions_list object here:
    num = (int)lua_objlen(L, 2);
    for (int i = 0; i < num; ++i) {
        lua_rawgeti(L, 2, i + 1);
        nv::String str = // Read the data from stack here as a nv::String value.
        extensions_list.push_back(str);
        lua_pop(L, 1);
    }
}
else {
  // Otherwise we must already have a valid StringList object:
  extensions = Luna< nv::StringList >::get(L,2,false);
}

</sxh>

  * Either this, or I just extend the XXXList constructors in lua to accept an in put table... ? That would still require creating a Vector on the lua Stack, doesn't soon very good.
  * And in fact an "extension" of the code above could be to "require" the address of a given object when we need if from a shared memory pool, and then release it when we don't need it anymore at the end of the function call => this should avoid the bulk of dynamic allocations ? Or maybe just placing the list on the stack is really enough here in fact.

  * So let's see how we could implement something like that now 😇

  * **Oki doki!**: in the end this was not as tricky as I thought it would be, and here is a example of the code generated now: <sxh cpp; highlight: []>static auto _bind_create_device_sig1(lua_State* L) -> int {
	int luatop = lua_gettop(L);
	nvk::VulkanInstance* self = Luna< nvk::VulkanInstance >::get(L,1);
	LUNA_ASSERT(self!=nullptr);

	nv::StringList extensions_vec;
	nv::StringList* extensions = &extensions_vec;
	if(lua_istable(L, 2)==1) {
		int num = (int)lua_objlen(L, 2);
		for (int i = 0; i < num; ++i) {
			lua_rawgeti(L, 2, i + 1);
			size_t elem_len = 0;
			const char* elem_cstr = lua_tolstring(L,-1,&elem_len);
			nv::String elem(elem_cstr, elem_len);
			extensions_vec.push_back(std::move(elem)); 
			lua_pop(L, 1);
		}
	}
	else {
		extensions = Luna< nv::StringList >::get(L,2,false);
	}
	nvk::QueueInfoList queueInfos_vec;
	nvk::QueueInfoList* queueInfos = &queueInfos_vec;
	if(lua_istable(L, 3)==1) {
		int num = (int)lua_objlen(L, 3);
		for (int i = 0; i < num; ++i) {
			lua_rawgeti(L, 3, i + 1);
			nvk::QueueInfo* elem = Luna< nvk::QueueInfo >::get(L,-1,false);
			queueInfos_vec.push_back(*elem); 
			lua_pop(L, 1);
		}
	}
	else {
		queueInfos = Luna< nvk::QueueInfoList >::get(L,3,false);
	}
	VkPhysicalDeviceFeatures* desired_features = luatop>=4? Luna< VkPhysicalDeviceFeatures >::get(L,4,true) : nullptr;
	uint32_t devId = luatop>=5? (uint32_t)lua_tointeger(L,5) : (uint32_t)0;

	nv::RefPtr<nvk::VulkanDevice> res = self->create_device(*extensions, *queueInfos, luatop>=4 ? desired_features : nullptr, devId);
	Luna< nvk::VulkanDevice >::push(L, res.get(), true);

	return 1;
}</sxh>

  * This is a bit verbose, but it seems to be working just fine, and I could then update the lua code accordingly: <sxh lua>    -- Now we create a device with a simple queue:
    local qflags = VkQueueFlagBits
    -- local qinfos = nvk.QueueInfoList()
    -- qinfos:push_back()
    -- local extNames = nv.StringList()
    -- extNames:push_back()

    local dev = inst:create_device({exts.VK_KHR_SWAPCHAIN}, {nvk.QueueInfo(qflags.GRAPHICS_BIT, 0.3)}, nil, 0)
    logDEBUG("Done creating device.")</sxh>

  * Hmmm 🤔, and now, thinking about it, maybe we can also get the vector initialization from lua almost for free just defining an additional constructor. **Okay**: so I simply injected a new copy constructor for the vector types, and this seems to do the trick: <sxh cpp; highlight: []>  -- Inject the functions:
  create_func(cl:getName(), "void ()")
  create_func(cl:getName(), "void (const "..fname.."&)", nil, {{"rhs", cref_type}})</sxh>


===== Adding full custom lua functions on classes =====

  * In addition to the luna extension mechanism I already have which is handy to add specific extension functions, I now realize it would also be great to be able to provided some more generic lua functions, for instance in the case of the Vector containers:
  * I could certainly use for instance a "forEach()" or "to_table()" method, which I could bind as usual, but to bind these, the actual method should also exist...

  * So, implementing the for_each() lua function for Vectors went fine: this is done directly in the **ClassWriter** with the following code: <sxh lua>  -- Also write our custom functions here directly:
  self:writeSubLine([[
// Here I'm writing the custom functions that will be bound below for vector class ${1}  
// with elements of type ${2}

static void _lunaext_for_each(const ${1}& obj, lua_State* L, LuaFunction& func)
{
  for(auto i=0; i<obj.size(); ++i) {
    func((lua_Integer)i, obj[i]);
  }
};

]], fname, el_name)</sxh>

  * Yet in this process I was also restoring the **LuaFunction** helper class, and thus tried to improve a bit on how we call that function with variadic templates to pass the arguments... except that, this doesn't quite work 😅: I'mm not quite sure why but this version because will lead to a crash when running the app: <sxh cpp; highlight: []>    template <typename T> void pushArgs(const T& arg0) {
        logDEBUG("Pushing single arg.");
        pushArg(arg0);
    }

    template <typename T, typename... Args>
    auto pushArgs(T arg0, const Args&... args) -> bool {
        logDEBUG("Pushing 1 arg.");
        pushArg(arg0);
        logDEBUG("Pushing more args...");
        pushArgs(args...);
        logDEBUG("Done pushing args.");
    }
</sxh>

  * => But never mind: I lost enough time on this for now, so I'm using this version instead (which is working fine): <sxh cpp; highlight: []>    template <typename T> void pushArgs(const T& arg0) { pushArg(arg0); }

    template <typename T1, typename T2>
    void pushArgs(const T1& arg1, const T2& arg2) {
        pushArg(arg1);
        pushArg(arg2);
    }

    template <typename T1, typename T2, typename T3>
    void pushArgs(const T1& arg1, const T2& arg2, const T3& arg3) {
        pushArg(arg1);
        pushArg(arg2);
        pushArg(arg3);
    }

    template <typename T1, typename T2, typename T3, typename T4>
    void pushArgs(const T1& arg1, const T2& arg2, const T3& arg3,
                  const T4& arg4) {
        pushArg(arg1);
        pushArg(arg2);
        pushArg(arg3);
        pushArg(arg4);
    }
</sxh>
  

===== Adding support for custom constructors for lua =====

  * Our custom luna extensions wit **lunaext** and **lunarawext** already give us a lot of flexibility to add new functions on a given class, yet this is only really working with already existing objects as we concluded in our previous post. For constructors we will need something different, let's see...

  * **OK** => Just added support for custom lua constructors which can be implemented as follow: <sxh cpp; highlight: []>inline auto _lunactr_VkExtent2D(nv::U32 width = 0, nv::U32 height = 0)
    -> VkExtent2D* {
    // logDEBUG("Should create a new extent2D here with witdh={}, height={}",
    //          width, height);
    return new VkExtent2D{width, height};
}</sxh>


===== Restoring luna log function connections =====

  * Adding more Vulkan classes and more bindings, I eventually got my minimal test application to run 😃! Well, just displaying a white screen with no actual vulkan drawing on it, but that's a start anyway:

{{ blog:2022:1012:nervland_vulkanapp_first_view.png?800 }}

  * What I noticed next was that I was getting a crash when deleting my VkSurfaceFormatList object in lua during the application uninit process: this was because there was valid destructor available in those bindings at first, but this was producing a C++ exception while I really expeced a lua error in the **LUNA_THROW_MSG**: => So this required some fixing,
  * And at the same time, I noticed that the message handlers in luna (do display debug/error outputs) were not connected yet, so now also connecting them in **nerv_bindings.cpp**: <sxh cpp; highlight: []>    luna::setLogFunctions(luna_debug_log, luna_error_log);

    // Also prepare here the registration of the void type:
    luna::pushGlobalNamespace(L);

    luna::Luna<void>::Register(L);

    luna::popNamespace(L);</sxh>

  * Ohh, and also, as shown above, I get vulkan validation error messages which is great 👍! So, what's our next step now ? Let's think a little with a small coffee in hand ☕... (that's my favorite part 🙃)

  
===== What's next ? =====

  * Unfortunately, it seems this is where I stopped in my previous iteration on vulkan, and then I moved to DirectX12 where I pushed it a little further... So now I need to find some resources on performing simple display with vulkan and work from there.

  * I think I'm going to start with this playlist: https://www.youtube.com/watch?v=Y9U9IE0gVHA&list=PL8327DO66nu9qYVKLDmdLW_84-yE4auCR
  * Downloading the files with: <sxh bash; highlight: []>$ nv_ytdl -v PL8327DO66nu9qYVKLDmdLW_84-yE4auCR -p vulkan_tutorial_series</sxh>

  * => Okay, so  I think what I will need next is to build a graphics pipeline actually, let's get started on this!
  
  * Added even more vulkan classes to support creation of Pipelines: **OK**


===== Creating our first shader =====

  * Next let's create a first shader file: <sxh cpp; highlight: []>#version 450

#ifdef __VERTEX__

vec2 positions[3] = vec2[] {
    vec2(0.0, -0.5),
    vec2(0.5, 0.5),
    vec2(-0.5, 0.5)
};

void main() {
    gl_Position = vec4(positions[gl_VertexIndex], 0.0, 1.0);
}

#endif

#ifdef __FRAGMENT__

layout(location=0) out vec4 outColor;

void main() {
    outColor = vec4(1.0, 0.0, 0.0, 1.0);
}

#endif
</sxh>

  * Next we need to compile that with the vulkan glsl compiler... except that, I also want to support hot shader reloading, so I need to be able to compile programmatically.
  * => Found this article on the usage of glslang: https://lxjk.github.io/2020/03/10/Translate-GLSL-to-SPIRV-for-Vulkan-at-Runtime.html
  * Also found this page on the C API: https://github.com/KhronosGroup/glslang/pull/2038
  * Also reading this page as reference: https://github.com/KhronosGroup/glslang#readme

  * => Okay, so I think I really need to try and embed that glslang library now, so let's do this.
  * One problem there: ''glslang::DefaultTBuiltInResource'' is not available anymore. => replacement solution found at https://github.com/KhronosGroup/glslang/issues/2207

  * **OK**, now I have this method ready for usage in VulkanDevice: <sxh cpp; highlight: []>    /* Helper method used to compile GLSL code to SPIRV */
    auto compile_glsl_to_spirv(ShaderStage stage, const char* shader_code,
                               const char* code_name) -> nv::String;</sxh>

  * Now I'm trying to compile that GLSL code from Lua with the following snippet: <sxh lua>    logDEBUG("Loading Vulkan bindings...")
    bm:loadBindings("Vulkan", "luaVulkan")

    -- Create the Library:
    local lib = nvk.VulkanLibrary()
    local app = nv.NervApp.instance()
    app:register_component(lib)
    lib:init()
    
    -- Here we should be able to load a GLSL source file:
    local code = lib:get_glsl_source("tests/test_simple.glsl")
    logDEBUG("Loaded code is: ", code)

    -- Now we request the compilation:
    vert_code = "#define __VERTEX__\n"..code
    frag_code = "#define __FRAGMENT__\n"..code

    vert_spirv = lib:compile_glsl_to_spirv(nvk.ShaderStage.VERTEX, vert_code, "test_simple_vert")
    logDEBUG("Compiled vertex shader spirv code length: ", #vert_spirv)

    frag_spirv = lib:compile_glsl_to_spirv(nvk.ShaderStage.FRAGMENT, frag_code, "test_simple_frag")
    logDEBUG("Compiled fragment shader spirv code length: ", #frag_spirv)</sxh>

  * The compilation process will give me the following results: <code>2022-10-14 08:15:33.371281 [ERROR] GLSL preprocessing failed in test_simple_vert:
2022-10-14 08:15:33.371312 [ERROR] Info log: WARNING: 0:1: '#define' : names containing consecutive underscores are reserved: __VERTEX__
ERROR: 0:2: '#version' : must occur first in shader
ERROR: 0:2: '#version' : bad profile name; use es, core, or compatibility
ERROR: 0:2: '#version' : bad tokens following profile -- expected newline
ERROR: 3 compilation errors.  No code generated.


2022-10-14 08:15:33.371322 [ERROR] Debug log:
2022-10-14 08:15:33.371375 [DEBUG] Compiled vertex shader spirv code length: 0
2022-10-14 08:15:33.372532 [ERROR] GLSL preprocessing failed in test_simple_frag:
2022-10-14 08:15:33.372544 [ERROR] Info log: WARNING: 0:1: '#define' : names containing consecutive underscores are reserved: __FRAGMENT__
ERROR: 0:2: '#version' : must occur first in shader
ERROR: 0:2: '#version' : bad profile name; use es, core, or compatibility
ERROR: 0:2: '#version' : bad tokens following profile -- expected newline
ERROR: 3 compilation errors.  No code generated.


2022-10-14 08:15:33.372554 [ERROR] Debug log:
2022-10-14 08:15:33.372577 [DEBUG] Compiled fragment shader spirv code length: 0</code>

  * => So that's interesting: it just means that I should keep the #version out of the glsl code file themself and add that dynamically. and also, I should not use double underscores in my shader borders as reported above.

  * After some more tweaking I got the fragment shader to compile and for the vertex shader I get the error: <code>2022-10-14 08:27:22.758819 [ERROR] GLSL parsing failed in test_simple_vert:
2022-10-14 08:27:22.758845 [ERROR] Info log: ERROR: 0:13: 'limitations' : Non-constant-index-expression
ERROR: 1 compilation errors.  No code generated.</code>
  * Which seems to be related to the line: <sxh cpp; highlight: []>    gl_Position = vec4(positions[gl_VertexIndex], 0.0, 1.0);</sxh>

  * => So I'm wondering if this could be related to the "limits" I'm providing in the **TBuiltInResource** struct 🤔 ?
  * => Found this page: https://www.reddit.com/r/vulkan/comments/cm1t6c/nonconstantindexexpression_error_how_to_fix/: so seems we need ''limits.generalUniformIndexing = true;'' => But we have that already 😲

  * Also trying to replace**gl_Vertexindex** with **gl_VertexID** but this is not accepted (so "Vulkan GLSL" is not the same as "OpenGL GLSL" 🤔 ?)
  * So what do we have here ?

  * Hmmm, now I'm thinking maybe I have a mix here between the vulkan provided libraries for glslang and the standalone package I've been trying to use...
  * => And **indeed** this was it! If I comment the line ''# link_directories(${VULKAN_DIR}/lib)'' in my cmake configs, then everything is still compiling just fine (=> we are not linking to any vulkan library actually 😅) **and** I will link to the glslang library version 11.11.0 that I'm providing separately, **and** the vertex code will now compile!

<note>=> The TBuiltInResource structure is different between glslang 11.11.0 and the version provided with vulkan-sdk 1.3.224 so that would explain the shader compilation error.</note>

===== Creating Shader modules =====

  * With our newly compiled SPIRV code we should now be able to create Shader modules to be used for our pipeline constructions, so let's try that.

  * Hmmm, initial shader creation test give me an error as follow: <code>SPIR-V module not valid: Invalid SPIR-V binary version 1.6 for target environment SPIR-V 1.0 (under Vulkan 1.0 semantics)</code>
  * Found this page: https://stackoverflow.com/questions/54513830/vulkan-1-1-spir-v-1-3-libshaderc-validation-layers-error
  * So, where on earth would I set this API version ? 😅

  * **OK** Found it at the creation of the vulkan instance, and updated to apiVersion 1.3 and now the error is gone: <sxh cpp; highlight: []>    // We prepare the application info:
    VkApplicationInfo application_info = {VK_STRUCTURE_TYPE_APPLICATION_INFO,
                                          nullptr,
                                          lib->get_application_name().c_str(),
                                          VK_MAKE_VERSION(1, 0, 0),
                                          lib->get_engine_name().c_str(),
                                          VK_MAKE_VERSION(1, 0, 0),
                                          VK_MAKE_VERSION(1, 3, 0)};</sxh> /*//*/


===== Creating the command buffers =====

  * Next we will create the command buffers needed to produce the final images: we will provide one command buffer per image available in the swapchain: <sxh lua>function Class:createCommandBuffers()
    local queue = self.vkdev:get_queue(0)
    local famIdx = queue:get_queue_family_index()
    logDEBUG("Queue 0 family index: ", famIdx)

    -- Now we create a Command Pool on that family index:
    self.cmdpool = self.vkdev:create_command_pool(famIdx, VkCommandPoolCreateFlagBits.RESET_COMMAND_BUFFER_BIT);
    logDEBUG("Created command pool");

    -- Then we create a command buffer:
    -- We create as many buffers as we have images in our swapchain
    local num = self.swapchain:get_num_images()
    self.cmdbufs = self.cmdpool:create_command_buffers(num, VkCommandBufferLevel.PRIMARY);
    logDEBUG("Created command buffers");
end</sxh>

==== Using lua alias and default namespace ====

  * And before I go any further, I think I should really stop the implementation here and first move all those vulkan classes/enums/functions into a dedicated lua namespace/table instead of placing everything in the global table. Lets see how to do that...

  * To use a default namespace we can simply specify that in the nervbind.lua config: <sxh lua>cfg.defaultNamespaceName = "vk"</sxh>

  * To provide a custom "lua alias" for some classes and/or enums, we can set the alias while iterating on all the discovered classes: <sxh lua>local preprocessEnums = function(ent)

    local name = ent:getFullName()

    -- rename vulkan enums:
    if name:startsWith("Vk") then
        ent:setLuaAlias(name:sub(3))
    end

    for _,p in ipairs(allowedEnums) do 
        if name:find(p) then
            return
        end
    end
    
    -- Ignore this entity:
    ent:setIgnored(true)
    -- logDEBUG("=> Ignoring entity ", name)
    return

end</sxh>

===== Discovering and setting up the Lua-Language-Server for vscode =====

<note important>=> I just discovered https://github.com/sumneko/lua-language-server 🤣 My god, this will save me so much time and effort...</note>

  * My my... this **lua-language-server** thing is amasing: and now this makes me realize I could automatically generate "libraries" for it when I generate my bindings, which ultimately means I could get auto-completion and diagnostic supports for the C++ elements bound to lua 😳! Really ?! That would be so terrible good... 🥳 => Let's see if I could start with providing enum values for instance:

  * Currently using the following settings for lls in vscode: <sxh javascript; highlight: []>  "Lua.diagnostics.globals": [
    "vk",
    "nvk",
    "nv",
    "clang",
    "nerv",
    "lfs",
    "nvLogTRACE",
    "nvLogDEBUG",
    "nvLogINFO",
    "nvLogWARN",
    "nvLogERROR",
    "nvLogFATAL",
    "nvCHECK",
    "nvTHROW"
  ],
  "Lua.runtime.version": "LuaJIT",
  // "Lua.workspace.library": ["${workspaceFolder}/dist/assets/lua/external"],
  "Lua.workspace.library": ["dist/assets/lua_defs"],
  "Lua.workspace.ignoreDir": [
    ".cache",
    ".vscode",
    "cmake",
    "sources",
    "temp",
    "tests",
    "dist/modules",
    "dist/assets/lua_defs",
    "dist/assets/lua/external",
    "dist/assets/lua/pl"
  ],
  "Lua.workspace.checkThirdParty": false</sxh>

  * => I'm now trying to generate the enum metadata in **dist/assets/lua_defs/vulkan.lua**

  * Yeeahh! That's working pretty well so far: I added support to write the enum definitions as follow for instance: <sxh lua>---@enum vk.MemoryAllocateFlagBits
vk.MemoryAllocateFlagBits =
{
	DEVICE_MASK_BIT = 0,
	DEVICE_ADDRESS_BIT = 1,
	DEVICE_ADDRESS_CAPTURE_REPLAY_BIT = 2,
	DEVICE_MASK_BIT_KHR = 3,
	DEVICE_ADDRESS_BIT_KHR = 4,
	DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_KHR = 5,
	FLAG_BITS_MAX_ENUM = 6,
}</sxh>

  * And then also the support to write the class field definitions as follow: <sxh lua>---@class vk.SurfaceCapabilitiesKHR
---@field minImageCount integer
---@field maxImageCount integer
---@field currentExtent vk.Extent2D
---@field minImageExtent vk.Extent2D
---@field maxImageExtent vk.Extent2D
---@field maxImageArrayLayers integer
---@field supportedTransforms integer
---@field currentTransform vk.SurfaceTransformFlagBitsKHR
---@field supportedCompositeAlpha integer
---@field supportedUsageFlags integer
vk.SurfaceCapabilitiesKHR = {}</sxh>

<note important>The actual enum **values** that I'm providing as just dummy values to ensure the keys will be sorted in the same order as in the actual bindings: that's definitely something I need to keep in mind to avoid mixing those integer values at some point.</note>

  * Next stop: adding support for the functions in each class 👍!

  * Whaaoo, that was really a nice implementation experience: everything went really smooth for once, and now I'm able to automatically generate very large libraries definitions for the lua-language-server along with my NervLuna bindings! In the process I'm handling the various requirements to find the correct class names/namespaces in lua, taking care of RefPtr object, string convertions, function overloads, enum resolutions, etc and it seems that LLS is pretty happy with it 😊!

  * Here is a speaking example of the type of code generated: <sxh lua>---@class nvk.VulkanSubpassDescription
---@field objects nvk.VkSubpassDescriptionList
---@field pInputAttachments nv.Vector_nvk_VkAttachmentReferenceList
---@field pColorAttachments nv.Vector_nvk_VkAttachmentReferenceList
---@field pResolveAttachments nv.Vector_nvk_VkAttachmentReferenceList
---@field pDepthStencilAttachment nvk.VkAttachmentReferenceList
---@field pPreserveAttachments nv.Vector_nv_U32List
local class = {}
---@param rhs nvk.VulkanSubpassDescription
---@return nvk.VulkanSubpassDescription
function class:op_assign(rhs) end
---@return nvk.VkSubpassDescriptionList
function class:getVkList() end
---@return vk.SubpassDescription
function class:getVk() end
---@return boolean
function class:empty() end
---@return integer
function class:size() end
---@param item vk.SubpassDescription
---@return nvk.VulkanSubpassDescription
---@overload fun(bpoint: vk.PipelineBindPoint): nvk.VulkanSubpassDescription
function class:addItem(item) end
---@return vk.SubpassDescription
function class:getCurrent() end
---@param flags_ integer
---@return nvk.VulkanSubpassDescription
function class:setFlags(flags_) end
---@param pipelineBindPoint_ vk.PipelineBindPoint
---@return nvk.VulkanSubpassDescription
function class:setBindPoint(pipelineBindPoint_) end
---@return nvk.VkAttachmentReferenceList
function class:getCurrentInputAttachmentList() end
---@param list nvk.VkAttachmentReferenceList
---@return nvk.VulkanSubpassDescription
function class:setInputAttachments(list) end
---@param obj vk.AttachmentReference
---@return nvk.VulkanSubpassDescription
---@overload fun(attachment: integer, layout: vk.ImageLayout): nvk.VulkanSubpassDescription
function class:addInputAttachment(obj) end
---@return vk.AttachmentReference
function class:addNewInputAttachment() end
---@return nvk.VulkanSubpassDescription
function class:syncInputAttachments() end
---@return nvk.VkAttachmentReferenceList
function class:getCurrentColorAttachmentList() end
---@param list nvk.VkAttachmentReferenceList
---@return nvk.VulkanSubpassDescription
function class:setColorAttachments(list) end
---@param obj vk.AttachmentReference
---@return nvk.VulkanSubpassDescription
---@overload fun(attachment: integer, layout: vk.ImageLayout): nvk.VulkanSubpassDescription
function class:addColorAttachment(obj) end
---@return vk.AttachmentReference
function class:addNewColorAttachment() end
---@return nvk.VulkanSubpassDescription
function class:syncColorAttachments() end
---@return nvk.VkAttachmentReferenceList
function class:getCurrentResolveAttachmentList() end
---@param list nvk.VkAttachmentReferenceList
---@return nvk.VulkanSubpassDescription
function class:setResolveAttachments(list) end
---@param obj vk.AttachmentReference
---@return nvk.VulkanSubpassDescription
---@overload fun(attachment: integer, layout: vk.ImageLayout): nvk.VulkanSubpassDescription
function class:addResolveAttachment(obj) end
---@return vk.AttachmentReference
function class:addNewResolveAttachment() end
---@return nvk.VulkanSubpassDescription
function class:syncResolveAttachments() end
---@return vk.AttachmentReference
function class:getCurrentDepthStencilAttachment() end
---@return nvk.VulkanSubpassDescription
---@overload fun(obj: vk.AttachmentReference): nvk.VulkanSubpassDescription
---@overload fun(attachment: integer, layout: vk.ImageLayout): nvk.VulkanSubpassDescription
function class:setDepthStencilAttachment() end
---@return boolean
function class:hasDepthStencilAttachment() end
---@return vk.AttachmentReference
function class:getOrCreateDepthStencilAttachment() end
---@return nv.U32List
function class:getCurrentPreserveAttachmentList() end
---@param list nv.U32List
---@return nvk.VulkanSubpassDescription
function class:setPreserveAttachments(list) end
---@param obj integer
---@return nvk.VulkanSubpassDescription
function class:addPreserveAttachment(obj) end
</sxh>

  * Function descriptions are still missing, but anyway I'm fully satisfied with this first iteration already 👍! So let's get back to our command buffers now ;-)

===== Extending LLS support with constructor overloads =====

  * One thing that is still annoying in by library construction is that I don't have proper support for constructors yet: for instance when I call: <sxh lua>local lib = nvk.VulkanLibrary()</sxh>
  * => The ''lib'' object is not recognized as a VulkanLibrary instance: so I need to setup the constructor overloads when creating the library to provide this feature.
  * **OK**: now fixed with this additional code: <sxh lua>        -- Get the class constructor:
        local ctr = class:getConstructor()
        if ctr ~= nil then
            local sigs = ctr:getPublicSignatures(true)
            for _, sig in ipairs(sigs) do
                local args = sig:getArguments()
                local anames = {}

                for _, arg in ipairs(args) do
                    -- Ignore the canonical lua state:
                    if not arg:isCanonicalLuaState() then
                        local aname = arg:getName()
                        local atype = arg:getType():getLuaTypeName()
                        if atype == "luna.LuaFunction" then
                            atype = "function"
                        end

                        table.insert(anames, aname .. ": " .. atype)
                    end
                end

                -- Finish the list of arguments:
                local elems = {}
                table.insert(elems, "---@overload fun(")
                table.insert(elems, table.concat(anames, ", "))
                table.insert(elems, "): ")

                -- The return type should be the class itself:
                table.insert(elems, clname)

                -- Write that constructor:
                self:writeLine(table.concat(elems, ""))
            end
        end</sxh>
  
  *  Next thing we need is to support tables where we have vector arguments.... Ohh... actually, it seems this is available out of the box and I have nothing to do for it, cool 😆!


===== Adding support for specification of number of threads during build =====

  * Okay, so I'm getting tired of seeing my computer almost freeze to death when I try to build the C++ sources in this project: time to put the number of threads used under control!
  * So I'm adding this section in the cmake_manager.py component: <sxh python; highlight: []>        nthreads = self.get_param("num_threads", None)
        flags = None
        if nthreads is not None:
            logger.info("Building with %d threads.", nthreads)
            flags = ["-j", str(nthreads)]

        builder.run_ninja(build_dir, outfile=outfile, flags=flags)</sxh>
  * And next I need an optional entry to specify the number of threads: <sxh python; highlight: []>    psr = context.build_parser("build")
    psr.add_str("proj_names")("List of modules to build")
    psr.add_str("-d", "--dir", dest="mod_install_dir")("Install folder")
    psr.add_flag("-r", "--rebuild", dest="rebuild")("Force rebuilding completely")
    psr.add_str("-c", "--compiler", dest="compiler_type", default="clang")("Select the compiler")
    psr.add_int("-j", "--num-threads", dest="num_threads")("Specify the number of threads to use during build.")
</sxh>

  * => And now building with 4 threads on Saturn seems to still be acceptable, all good 👍!

===== Adding support for debug build mode =====

  * While I'm at it (trying to optimize the build time) I should also probably try to configure the project to support building in debug mode... Let's see if this is possible 🤔...

  * So I added another parameter in the cmake_manager to specify the build type: <sxh python; highlight: []>        build_type = self.get_param("build_type", "Release")
        logger.info("Cmake build type: %s", build_type)

        builder = self.get_builder()
        builder.run_cmake(build_dir, install_dir, src_dir, flags, outfile=outfile, build_type=build_type)
</sxh>

  * Then I can use a build command such as: <sxh bash; highlight: []>nvp nvl_build -j 4 -t Debug</sxh>

  * Yet, of course, I have a problem with linking the boost debug libraries (since I didn't build them I think): <code>lld-link: error: could not open 'libboost_filesystem-clang14-mt-gd-x64-1_79.lib': no such file or directory
lld-link: error: /failifmismatch: mismatch detected for '_ITERATOR_DEBUG_LEVEL':
>>> sources/nvCore/shared/CMakeFiles/nvCore.dir/_/src/view/WindowManager.cpp.obj has value 2</code>

  * => So now also rebuild boost with Debug version support: <sxh bash; highlight: []>cli.bat build libs boost --rebuild</sxh>
    * **Note**: I first disabled the **variant=release** setting in the builder for boost.
    * OK, then also fixing the variant of msvc runtime and this was then compiling fine in Debug: <code>set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreadedDLL")</code>

  * But the compile times are not significantly better... is there something else I could do ?? => Nothing I see for now, so never mind.


===== Filling the command buffers =====

  * Okay so... (a few days later...): I've actually been working pretty hard on this vulkan engine lately: basically adding a **VulkanRenderer** class which is currently the main element used to render frames. I used some of the design from the **LittleVulkanEngine** project as reference but then started to deviate from it.
  * But anyway, I could then fill the command buffers, and register them on the renderer as follow: <sxh lua>-- Method used to record command buffers:
---@param rpassIdx integer The render pass to use.
function Class:recordCommandBuffers(rpassIdx)
    -- Should create the framebuffers for each of the swapchain images here:
    -- Before we can create a framebuffer, we need to create the depth image that we will use as attachment:
    self.depthImg = self.vkeng:create_image_2d(self.width, self.height, vk.Format.D32_SFLOAT,
        vk.ImageUsageFlagBits.DEPTH_STENCIL_ATTACHMENT_BIT)
    -- logDEBUG("Depth image idx: ", self.depthImg)
    self:allocate_image_memory(self.depthImg)

    local depthView = self.vkeng:create_image_view(self.depthImg)
    local schain = self.vkeng:get_swap_chain(self.swapchain)

    -- Iterate on each command buffer object:
    local num = self.cmdbufs:size()
    self.framebuffers = nv.U64List()

    for i = 0, num - 1 do

        -- Create the framebuffer that will be used to render into the image (i):
        local imgIdx = schain:get_image(i)
        -- self:allocate_image_memory(imgIdx)
        local viewIdx = self.vkeng:create_image_view(imgIdx)
        local fbIdx = self.vkeng:create_framebuffer(rpassIdx, { viewIdx, depthView }, self.width, self.height)
        self.framebuffers:push_back(fbIdx)

        local cbuf = self.vkeng:get_command_buffer(self.cmdbufs:at(i))

        -- cbuf:begin(vk.CommandBufferUsageFlagBits.ONE_TIME_SUBMIT_BIT)
        cbuf:begin(0)

        -- Begin rendering into the swapchain framebuffer:
        cbuf:begin_inline_pass(rpassIdx, fbIdx)

        -- End the render pass:
        cbuf:end_render_pass()

        -- Finish the command buffer:
        cbuf:finish()

        self.renderer:add_swapchain_img_cmd_buffer(cbuf, i)
    end

    logDEBUG("Done recording ", num, " command buffers.")
end</sxh>

===== Our first vulkan display ever =====

  * Then extended my VulkanApp run loop to also render a frame with the renderer on each cycle, and here... ohhh miracle! It's working! And I get a black screen! 😁 which is the clear color I'm using so far:

{{ blog:2022:1103:first_vulkan_rendering.png?800 }}

  * I know this may sound like really not much, but for me this is a significant step anyway: it was pretty complex to get to this point in fact 😅 But I have good hopes things will become easier now (because I already have a lot of support classes, and some structure emerging in my engine).

  * Actually, let's continue with trying to check this default clear color... Oh my, that was super easy: I just need to set the clear color of the attachment 0 of each of the framebuffers I'm using (I areally only added those 3 lines in lua!): <sxh lua>        -- Set the clear color of the first attachment of the framebuffer:
        local fbuf = self.vkeng:get_framebuffer(fbIdx)
        fbuf:set_clear_color(0, 1.0, 0.0, 0.0, 1.0)</sxh>

  * And here we go!

{{ blog:2022:1103:vulkan_02_red_clear_color.png?800 }}


===== Drawing our first triangle =====

  * Let's continue with the rendering of a first triangle. In theory, all I need for that is a draw call in the command buffers.
  * (=> OOooops, no, I also need to bind the graphics pipeline of course, thank you dear validation layer 😂)
  * So the final updates to the command buffers are as follow: <sxh lua>        cbuf:begin(0)

        -- Begin rendering into the swapchain framebuffer:
        cbuf:begin_inline_pass(rpassIdx, fbIdx)

        -- Bind the graphics pipeline:
        cbuf:bind_graphics_pipeline(pipelineIdx)

        -- Draw our triangle:
        cbuf:draw(3)

        -- End the render pass:
        cbuf:end_render_pass()

        -- Finish the command buffer:
        cbuf:finish()</sxh>

  * => And again, it's working without too much trouble!

{{ blog:2022:1103:vulkan_03_first_triangle.png?800 }}

  * For once, this is getting a bit exciting!

===== Changing the color of the triangle =====

  * Arrff, this didn't remain exciting very long lol... now just trying to change the color of my triangle to something else than red, and that doesn't seem to work as expected: the triangle remains red, or becomes some kind of dark blue... What did I mess 🥴 ??

  * => First I have the fact that I'm sharing a single depth image between all framebuffers, lets fix that => now creating the depth image per framebuffer:: <sxh lua>    for i = 0, num - 1 do

        -- Before we can create a framebuffer, we need to create the depth image that we will use as attachment:
        local depthImg = self.vkeng:create_image_2d(self.width, self.height, vk.Format.D32_SFLOAT,
            vk.ImageUsageFlagBits.DEPTH_STENCIL_ATTACHMENT_BIT)
        -- logDEBUG("Depth image idx: ", depthImg)
        self:allocate_image_memory(depthImg)

        local depthView = self.vkeng:create_image_view(depthImg)

        -- Alos get the view for the swapchain image:
        local imgIdx = schain:get_image(i)

        -- self:allocate_image_memory(imgIdx)
        local viewIdx = self.vkeng:create_image_view(imgIdx)

        -- Create the framebuffer that will be used to render into the image (i):
        local fbIdx = self.vkeng:create_framebuffer(rpassIdx, { viewIdx, depthView }, self.width, self.height)
        self.framebuffers:push_back(fbIdx)
  end</sxh>

  * => But this doesn't fix our color issue of course. And in fact, looking more carefully, the triangle doesn't really look like it's full red... it rather seems to be mixed with the background color a bit ? It becomes full red if I set the background color to (0,0,0,1)

  * Also, I was not setting the VkSubpassDependency properly when creating the render pass, fixing that: <sxh lua>    local ddesc = nvk.VulkanSubpassDependency()
    ddesc:setSrcStageMask(vk.PipelineStageFlagBits.COLOR_ATTACHMENT_OUTPUT_BIT +
        vk.PipelineStageFlagBits.EARLY_FRAGMENT_TESTS_BIT)
    ddesc:setDstStageMask(vk.PipelineStageFlagBits.COLOR_ATTACHMENT_OUTPUT_BIT +
        vk.PipelineStageFlagBits.EARLY_FRAGMENT_TESTS_BIT)
    ddesc:setSrcAccessMask(0)
    ddesc:setDstAccessMask(vk.AccessFlagBits.COLOR_ATTACHMENT_WRITE_BIT +
        vk.AccessFlagBits.DEPTH_STENCIL_ATTACHMENT_WRITE_BIT)
</sxh>

  * But still, my triangle is just red 😭

  * => As I said above, this really looks like a blending issue, so let's check our settings at that level now.

  * Hmmm, actually, just noticed that the usrface format is set to B8G8R8A8_SRGB in lve, let's try that one. Nope, not helping.

  * But my idea above about blending was correct: if I completely comment the ColorBlendState config from the pipeline config creation, then the display colors are OK 😲! So let's see what I could be doing wrong there.

  * Note: actually there is a validation error if we do not specify the ColorBlendState info: <code>VUID-VkGraphicsPipelineCreateInfo-renderPass-06044(ERROR / SPEC): msgNum: -1526981024 - Validation Error: [ VUID-VkGraphicsPipelineCreateInfo-renderPass-06044 ] Object 0: handle = 0x27a7263ab50, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xa4fc1e60 | Invalid Pipeline CreateInfo[0] State: pColorBlendState is NULL when rasterization is enabled and subpass uses color attachments. The Vulkan spec states: If renderPass is not VK_NULL_HANDLE, the pipeline is being created with fragment output interface state, and subpass uses color attachments, pColorBlendState must be a valid pointer to a valid VkPipelineColorBlendStateCreateInfo structure (https://vulkan.lunarg.com/doc/view/1.3.224.1/windows/1.3-extensions/vkspec.html#VUID-VkGraphicsPipelineCreateInfo-renderPass-06044)</code>

  * Tried to write on ColorBlendState struct directly from C++ and this works: <sxh cpp; highlight: []>auto VulkanDevice::create_graphics_pipelines(
    const VkGraphicsPipelineCreateInfoList& infos, VkPipelineCache cache)
    -> VulkanPipelineList {
    VulkanPipelineList list;
    if (infos.empty())
        return list;

    // override the ColorBlendState config here:
    VkPipelineColorBlendAttachmentState attachment{};

    attachment.colorWriteMask =
        VK_COLOR_COMPONENT_R_BIT | VK_COLOR_COMPONENT_G_BIT |
        VK_COLOR_COMPONENT_B_BIT | VK_COLOR_COMPONENT_A_BIT;
    attachment.blendEnable = VK_FALSE;
    attachment.srcColorBlendFactor = VK_BLEND_FACTOR_ONE;  // Optional
    attachment.dstColorBlendFactor = VK_BLEND_FACTOR_ZERO; // Optional
    attachment.colorBlendOp = VK_BLEND_OP_ADD;             // Optional
    attachment.srcAlphaBlendFactor = VK_BLEND_FACTOR_ONE;  // Optional
    attachment.dstAlphaBlendFactor = VK_BLEND_FACTOR_ZERO; // Optional
    attachment.alphaBlendOp = VK_BLEND_OP_ADD;             // Optional

    VkPipelineColorBlendStateCreateInfo blendInfo{};

    blendInfo.sType = VK_STRUCTURE_TYPE_PIPELINE_COLOR_BLEND_STATE_CREATE_INFO;
    blendInfo.logicOpEnable = VK_FALSE;
    blendInfo.logicOp = VK_LOGIC_OP_COPY; // Optional
    blendInfo.attachmentCount = 1;
    blendInfo.pAttachments = &attachment;
    blendInfo.blendConstants[0] = 0.0F; // Optional
    blendInfo.blendConstants[1] = 0.0F; // Optional
    blendInfo.blendConstants[2] = 0.0F; // Optional
    blendInfo.blendConstants[3] = 0.0F; // Optional

    const_cast<VkGraphicsPipelineCreateInfoList&>(infos)[0].pColorBlendState =
        &blendInfo;

    VkPipelineList pipelines;
    pipelines.resize(infos.size());
    CHECK_VK_MSG(vkCreateGraphicsPipelines(_device, cache,
                                           (uint32_t)infos.size(), infos.data(),
                                           nullptr, pipelines.data()),
                 "Cannot create graphic pipelines");

    for (auto& p : pipelines) {
        list.push_back(new VulkanPipeline(this, p));
    }

    return list;
}</sxh>

  * Ohh crap... it was the color write mask in the blend attachment... because of the default value not being propagated in the lua bindings 😬! 
  * When specifying the writeMask value, everything seems OK: <sxh lua>    local blend = cfg:getCurrentColorBlendState()
    -- blend:setLogicOpEnabled(vk.FALSE)
    blend:setLogicOp(vk.LogicOp.COPY)
    -- blend:setBlendConstants(0.0, 0.0, 0.0, 0.0)
    blend:addAttachment(vk.FALSE, -- blendEnabled
        vk.BlendFactor.ONE, -- srcColor
        vk.BlendFactor.ZERO, -- dstColor
        vk.BlendOp.ADD, -- colorBlendOp,
        vk.BlendFactor.ONE, -- srcAlphaBlendFactor,
        vk.BlendFactor.ZERO, -- dstAlphaBlendFactor,
        vk.BlendOp.ADD, -- alphaBlendOp,
        vk.ColorComponentFlagBits.R_BIT + vk.ColorComponentFlagBits.G_BIT + vk.ColorComponentFlagBits.B_BIT +
        vk.ColorComponentFlagBits.A_BIT
    )</sxh>

  * => Stupid me... 😁 => I really need to pay attention to those default values more closely now.

  * Now I finally have my yellow triangle:

{{ blog:2022:1103:vulkan_04_yellow_triangle.png?800 }}

===== Checking default value retriaval in NervBind =====

  * Now checking the generated bindings, here is what I get for the addAttachment method: <sxh cpp; highlight: []>inline auto
addAttachment(VkBool32 blendEnable, VkBlendFactor srcColorBlendFactor,
              VkBlendFactor dstColorBlendFactor, VkBlendOp colorBlendOp,
              VkBlendFactor srcAlphaBlendFactor,
              VkBlendFactor dstAlphaBlendFactor, VkBlendOp alphaBlendOp,
              VkColorComponentFlags colorWriteMask = VK_COLOR_COMPONENT_R_BIT |
                                                     VK_COLOR_COMPONENT_G_BIT |
                                                     VK_COLOR_COMPONENT_B_BIT |
                                                     VK_COLOR_COMPONENT_A_BIT)
    -> class_type& {
    return addAttachment({blendEnable, srcColorBlendFactor, dstColorBlendFactor,
                          colorBlendOp, srcAlphaBlendFactor,
                          dstAlphaBlendFactor, alphaBlendOp, colorWriteMask});
}</sxh>

  * Generated bindings:
<sxh cpp; highlight: []>static auto _bind_addAttachment_sig2(lua_State* L) -> int {
	int luatop = lua_gettop(L);
	nvk::VulkanPipelineColorBlendStateCreateInfo* self = Luna< nvk::VulkanPipelineColorBlendStateCreateInfo >::get(L,1);
	LUNA_ASSERT(self!=nullptr);

	auto blendEnable = (uint32_t)lua_tointeger(L,2);
	auto srcColorBlendFactor = (VkBlendFactor)lua_tointeger(L,3);
	auto dstColorBlendFactor = (VkBlendFactor)lua_tointeger(L,4);
	auto colorBlendOp = (VkBlendOp)lua_tointeger(L,5);
	auto srcAlphaBlendFactor = (VkBlendFactor)lua_tointeger(L,6);
	auto dstAlphaBlendFactor = (VkBlendFactor)lua_tointeger(L,7);
	auto alphaBlendOp = (VkBlendOp)lua_tointeger(L,8);
	uint32_t colorWriteMask = luatop>=9? (uint32_t)lua_tointeger(L,9) : (uint32_t)VK_COLOR_COMPONENT_R_BIT;

	nvk::VulkanPipelineColorBlendStateCreateInfo& res = self->addAttachment(blendEnable, srcColorBlendFactor, dstColorBlendFactor, colorBlendOp, srcAlphaBlendFactor, dstAlphaBlendFactor, alphaBlendOp, colorWriteMask);
	Luna< nvk::VulkanPipelineColorBlendStateCreateInfo >::push(L, &res, false);

	return 1;
}
</sxh>

  * => I should really look into this default value of "VK_COLOR_COMPONENT_R_BIT" here... 😨
  
  * The corresponding AST at that location is pretty complex (but all our elements are in there): <code>2022-11-04 12:24:20.491163 [DEBUG] cursor AST:

2022-11-04 12:24:20.491199 [DEBUG] level 1: 'VkColorComponentFlags' of kind 'TypeRef', type: 'VkColorComponentFlags'

2022-11-04 12:24:20.491236 [DEBUG] level 1: '' of kind 'UnexposedExpr', type: 'VkColorComponentFlags'

2022-11-04 12:24:20.491273 [DEBUG] level 2: '' of kind 'BinaryOperator', type: 'int'

2022-11-04 12:24:20.491308 [DEBUG] level 3: '' of kind 'BinaryOperator', type: 'int'

2022-11-04 12:24:20.491345 [DEBUG] level 4: '' of kind 'BinaryOperator', type: 'int'

2022-11-04 12:24:20.491383 [DEBUG] level 5: 'VK_COLOR_COMPONENT_R_BIT' of kind 'UnexposedExpr', type: 'int'

2022-11-04 12:24:20.491444 [DEBUG] level 6: 'VK_COLOR_COMPONENT_R_BIT' of kind 'DeclRefExpr', type: 'VkColorComponentFlagBits'

2022-11-04 12:24:20.491488 [DEBUG] level 5: 'VK_COLOR_COMPONENT_G_BIT' of kind 'UnexposedExpr', type: 'int'

2022-11-04 12:24:20.491528 [DEBUG] level 6: 'VK_COLOR_COMPONENT_G_BIT' of kind 'DeclRefExpr', type: 'VkColorComponentFlagBits'

2022-11-04 12:24:20.491570 [DEBUG] level 4: 'VK_COLOR_COMPONENT_B_BIT' of kind 'UnexposedExpr', type: 'int'

2022-11-04 12:24:20.491610 [DEBUG] level 5: 'VK_COLOR_COMPONENT_B_BIT' of kind 'DeclRefExpr', type: 'VkColorComponentFlagBits'

2022-11-04 12:24:20.491696 [DEBUG] level 3: 'VK_COLOR_COMPONENT_A_BIT' of kind 'UnexposedExpr', type: 'int'

2022-11-04 12:24:20.491746 [DEBUG] level 4: 'VK_COLOR_COMPONENT_A_BIT' of kind 'DeclRefExpr', type: 'VkColorComponentFlagBits</code>

  * => I think I need to get access to the "UnexposedExpr" cursor at level 2 above and just try to collect all its tokens ? Let see if this coud work.

  * Okay, so, this was a little tricky, but I finally managed to update the default value parsing in NervBind, and now the default value I get for the colorWriteMask is  the correct one: <sxh cpp; highlight: []>static auto _bind_addAttachment_sig2(lua_State* L) -> int {
	int luatop = lua_gettop(L);
	nvk::VulkanPipelineColorBlendStateCreateInfo* self = Luna< nvk::VulkanPipelineColorBlendStateCreateInfo >::get(L,1);
	LUNA_ASSERT(self!=nullptr);

	auto blendEnable = (uint32_t)lua_tointeger(L,2);
	auto srcColorBlendFactor = (VkBlendFactor)lua_tointeger(L,3);
	auto dstColorBlendFactor = (VkBlendFactor)lua_tointeger(L,4);
	auto colorBlendOp = (VkBlendOp)lua_tointeger(L,5);
	auto srcAlphaBlendFactor = (VkBlendFactor)lua_tointeger(L,6);
	auto dstAlphaBlendFactor = (VkBlendFactor)lua_tointeger(L,7);
	auto alphaBlendOp = (VkBlendOp)lua_tointeger(L,8);
	uint32_t colorWriteMask = luatop>=9? (uint32_t)lua_tointeger(L,9) : (uint32_t)VK_COLOR_COMPONENT_R_BIT|VK_COLOR_COMPONENT_G_BIT|VK_COLOR_COMPONENT_B_BIT|VK_COLOR_COMPONENT_A_BIT;

	nvk::VulkanPipelineColorBlendStateCreateInfo& res = self->addAttachment(blendEnable, srcColorBlendFactor, dstColorBlendFactor, colorBlendOp, srcAlphaBlendFactor, dstAlphaBlendFactor, alphaBlendOp, colorWriteMask);
	Luna< nvk::VulkanPipelineColorBlendStateCreateInfo >::push(L, &res, false);

	return 1;
}</sxh>

<note>Actually this also fixed a lot of additional incorrectly specified default values, so this was definitely worth investigating and fixing!</note>