Many foreign imports make sense to be unsafe imports about vulkan HOT 10 CLOSED

Unsafe calls are now enabled by default, they can be made safe with the safe-foreign-calls flag.

from vulkan.

Unfortunately the very first call one makes to Vulkan (vkCreateInstance) takes a bunch of callbacks and is entitled to remember them and call them at any time.

Any Create call is able to remember (and use) the allocation callbacks until the corresponding Destroy call.

See here: https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#memory-allocation

If an implementation intends to make calls through an VkAllocationCallbacks structure between the time a vkCreate* command returns and the time a corresponding vkDestroy* begins, that implementation must save a copy of the allocator before the vkCreate* command returns.

Because of this by default I think it's best to keep these as safe calls to avoid surprises.

Although: I imagine that lots of users are going to just stick with the default malloc/free pair and don't need to be bothered with the safe call overhead so the unsafe alternatives should probably be provided too.

How would be best to expose these unsafe variants?

• Duplicating every Vulkan command and adding a suffix along the lines of UnsafeNoCallbacks or NoCallbacks
• Duplicating every Vulkan command and adding a low profile suffix such as '
• Duplicating every module so one could import Graphics.Vulkan.Device or Graphics.Vulkan.Device.NoCallbacks
• Duplicating every module so one could import Graphics.Vulkan.NoCallbacks.Device instead.
• Something else altogether

from vulkan.

It might even make more sense to invert those alternatives and provide the unsafe functions by default, and require using alternative command or module names if one requires using Haskell callbacks.

from vulkan.

I like the duplicated modules. It gives users more control over scope and module qualification. I have no opinion on whether to put the NoCallbacks portion of the name near the beginning or the end, nor on which alternative should be the default.

from vulkan.

Sounds good to me.

I'll get down to closing this issue after the other issues with this package are fixed (Show instances etc...). I can't imagine that anyone's going to be requiring losing this safe call overhead for a little while yet.

from vulkan.

Hmm, I wonder if this could be done with a configuration flag. Along the same lines as vector's "don't do any bounds checking" flag.

from vulkan.

I would suggest having a special flag for this. Moreover, maybe it makes sense to generalize the flag idea for something like dev with safe calls and automatic error checking after each command?
I've seen nice a approach in some yesod's projects:

vulkan.cabal:

flag dev
    description: Turn on development settings.
    default: True

library
    if (flag(dev))
        cpp-options: -DDEVELOPMENT
        ghc-options: -Wall -fwarn-tabs -O0
...

*.hs:

{-# Language CPP #-}
...
#if DEVELOPMENT
foreign import ccall "vkFunc" vkFunc :: Param -> IO VkResult
#else
foreign import ccall unsafe "vkFunc" vkFunc :: Param -> IO VkResult
#endif

from vulkan.

Well, it's not exactly a development setting. It's an optimization which is only safe to do when one hasn't given Vulkan any callbacks which could come back into Haskell-land.

from vulkan.

After consulting with the #vulkan channel it seems as though idiomatic usage is for development to track allocations. Seems like custom allocators are not a widely used feature anyway.

from vulkan.

I just made two copies of each function to let user decide if they want to play risky or not :)
Also, I think it may be ok to call some vulkan functions unsafe even with callbacks attached, because the functions seem return immediately (callbacks are executed later, when the haskell runtime is resumed and there is no danger of blocking during FFI call). Though, I have not tested this yet.

from vulkan.