Omit stubs for unloaded functions

[Ralith]

In exchange, calling an unloaded function is now UB. This is more consistent with how Vulkan is used outside of rust, and saves about 6000 lines of generated code.

This is motivated by the desire to reduce buildtime. However, it empirically doesn't seem to significantly change build times, or even the size of the final stripped binary. Maybe monomorphizing Option and unwrap_unchecked sucks? Is there a better way to approach this?

[Ralith]

Manually inlining unwrap_unchecked helped size slightly, but again didn't noticeably impact buildtime.

[Ralith]

Even representing every pointer as usize and transmuting on call doesn't seem to change anything!

[MarijnS95]

In exchange, calling an unloaded function is now UB

That doesn't sound very promising unless we can make the user aware (ie. Result<Device, Device>) that not all functions loaded. Won't be the first time that I'm missing functions somewhere because of accidentally using 1.2 functions on a 1.1 device/driver, where the extension should be used. Sure, users should check for the supported extensions and Vulkan versions before doing this.

Hope you can find ways to nuke this code and win some compiletime, otherwise having an easier way to UB without any wins elsewhere is a tough pill to swallow.

[Ralith]

In practice I don't think this would be too bad, because 1. it's what you generally expect from Vulkan, and 2. in practice it'll tend to immediately segv, which is easily diagnosed. However, there doesn't appear to be any benefit, so I don't intend to pursue this further; it seems our problems are elsewhere. But maybe someone with more experience profiling rustc could prove me wrong.

unless we can make the user aware (ie. Result<Device, Device>) that not all functions loaded

I think this would require significant API changes, at least splitting Device into multiple objects.

[MarijnS95]

In practice I don't think this would be too bad, because 1. it's what you generally expect from Vulkan

If the driver crashes, sure I'd have to come up with a repro and contact vendors, but if it's a jump-to-null of my own making I'd rather prevent it.

, and 2. in practice it'll tend to immediately segv, which is easily diagnosed.

Fair enough.

However, there doesn't appear to be any benefit, so I don't intend to pursue this further; it seems our problems are elsewhere.

Yeah, agreed. We should probably continue on the builders and debugs which - together - contribute half of the buildtime. Perhaps after that the minor wins here may come to the forefront?

But maybe someone with more experience profiling rustc could prove me wrong.

I wish I knew more about this :sweat_smile: - IIRC there's debug perf output showing where in the compiler most time is spent, but I don't remember it being comprehensive enough nor easily mapping to the source code that is being translated.

unless we can make the user aware (ie. Result<Device, Device>) that not all functions loaded

I think this would require significant API changes, at least splitting Device into multiple objects.

Yeah fair enough, this would make sense for extensions but really tricky to read/use for the entire device (stabilized functions of all Vulkan versions). Perhaps something to think/worry about in the future.