Remove wrappers and modify proxies.

[mattatticus]

Hello. I looked at the generated file and the code was generated twice, once for the wrappers and once for the proxies.

I suggest removing the wrapper indirection and using the Dispatch field in the wrappers directly in the associated proxies.

Pros:

• Less generated code
• Faster compilation process
• Removing the need for allocation

For the command buffer proxy, queue proxy, etc, I suggest using just the function pointers which will be called by their associated proxies.

[Snektron]

The original idea was that the wrapper types handle the actual dispatching, while the proxies also add the device parameters. This way you could use the proxy as your "main" handle, and use the wrapper types for "optional" extension function pointers etc. I've been thinking about moving to a Volk-style setup where we just load everything into the struct though, which would also allow getting rid of one of the structs and make the library a lot less painful to use in general. Let me experiment with that a little bit...

[allemangD]

I've done a little experimenting with this (where I noticed #209).

It feels a bit "neater" to have both wrappers and proxies take a pointer to a dispatch; however it doesn't reduce generated code by much and it doesn't remove the need for allocation. The need for allocation is twofold, due to the LLVM issue regarding vtable optimizations and also because the dispatch tables are large and you don't want those sitting in the stack.

I have a documented prototype implementation in my fork master...allemangD:vulkan-zig:proxy-wrapper-dispatch

---

While I was fiddling with that, I had some thoughts about streamlining the typical use case. Typically, you only have one base, instance, and device, so it could make sense to put those dispatch tables in static storage to avoid the explicit heap allocation.

const static = struct{
    var instance_dispatch: vk.InstanceDispatch = .{};
};

const instance_handle = try base_wrapper.createInstance(...);
static.instance_dispatch = .load(instance_handle, static.base_dispatch.vkGetInstanceProcAddr.?);
const instance_proxy: vk.InstanceProxy = .init(instance_handle, &static.instance_dispatch);
defer instance_proxy.destroyInstance(...);

Making up arbitrary type names for discussion: in principle this could be automated with some concept like StaticInstanceProxy that implicitly uses a hidden static-duration dispatch table. Ideally it should be possible, somehow, to mix usage of static base, instance, and device proxies (for example you could use a single StaticInstanceProxy to create multiple DynamicDeviceProxy).

Edit: after some further reflection I don't think that should be the library's responsibility. If the application wants to use static or heap or stack memory for the dispatch table, fine, just pass it via pointer to the library in either case.

It might be nice instead to have some convenience methods on the proxies like

pub fn createDeviceProxy(
    self: Self,
    physical_device: PhysicalDevice,
    p_create_info: *const DeviceCreateInfo,
    p_allocator: ?*const AllocationCallbacks,
    p_dispatch: *DeviceDispatch,
) CreateDeviceError!DeviceProxy {
    const device = try self.createDevice(physical_device, p_create_info, p_allocator);
    p_dispatch.* = .load(self.p_dispatch.vkGetDeviceProcAddr.?, device);
    return .init(device, p_dispatch);
}

pub fn getDeviceQueueProxy(
    self: Self,
    queue_family_index: u32,
    queue_index: u32,
) QueueProxy {
    const queue = self.getDeviceQueue(queue_family_index, queue_index);
    return .init(queue, self.p_dispatch);
}

So the above snippet could become:

const static = struct{
    var instance_dispatch: vk.InstanceDispatch = .{};
};

const instance = try base_wrapper.createInstanceProxy(..., &static.instance_dispatch);
defer instance.destroyInstance(...);