update to 1.4

[SimonDanisch]

Vulkan 1.4 has lots of nice features e.g. to use hardware accelerated matmul.

[serenity4]

I remember attempting to update to even just a more recent 1.3 patch version about a year ago, and was faced with nontrivial issues in the generated code that required adjustments on the generator side (and possibly on VulkanSpec.jl to adapt to a changing representation of the contents of the specification). Support for 1.4 might require quite some thought to get it to a working state.

I have essentially moved on from Julia/Vulkan work but I'm happy to review changes in the generator parts (I will trust that you check tests pass in Vulkan.jl and most importantly in your downstream packages before we merge). If updating the generator proves to be too complex/requires to be too intimately familiar with how it works internally then feel free to let me know and I'll see if I can find some time to do it.

[serenity4]

Oh wait, I thought this was a PR to Vulkan.jl, not to VulkanCore.jl, my mistake. My previous comment applies to the former.

Seems like CI has issues fetching the SDK, would be nice to get that working for at least Linux CI.

[serenity4]

Updating to Clang 0.19.3 seems to have a fairly different representation for structs (they are generated with a single .data field that is an NTuple with getproperty/propertynames overloaded to represent the different "fields"), as in

struct VkRenderingAttachmentInfo
    sType::VkStructureType
    pNext::Ptr{Cvoid}
    imageView::VkImageView
    imageLayout::VkImageLayout
    resolveMode::VkResolveModeFlagBits
    resolveImageView::VkImageView
    resolveImageLayout::VkImageLayout
    loadOp::VkAttachmentLoadOp
    storeOp::VkAttachmentStoreOp
    clearValue::VkClearValue
end

previously and now this:

struct VkRenderingAttachmentInfo
    data::NTuple{72, UInt8}
end

function Base.getproperty(x::Ptr{VkRenderingAttachmentInfo}, f::Symbol)
    f === :sType && return Ptr{VkStructureType}(x + 0)
    f === :pNext && return Ptr{Ptr{Cvoid}}(x + 8)
    f === :imageView && return Ptr{VkImageView}(x + 16)
    f === :imageLayout && return Ptr{VkImageLayout}(x + 24)
    f === :resolveMode && return Ptr{VkResolveModeFlagBits}(x + 28)
    f === :resolveImageView && return Ptr{VkImageView}(x + 32)
    f === :resolveImageLayout && return Ptr{VkImageLayout}(x + 40)
    f === :loadOp && return Ptr{VkAttachmentLoadOp}(x + 44)
    f === :storeOp && return Ptr{VkAttachmentStoreOp}(x + 48)
    f === :clearValue && return Ptr{VkClearValue}(x + 52)
    return getfield(x, f)
end

function Base.getproperty(x::VkRenderingAttachmentInfo, f::Symbol)
    r = Ref{VkRenderingAttachmentInfo}(x)
    ptr = Base.unsafe_convert(Ptr{VkRenderingAttachmentInfo}, r)
    fptr = getproperty(ptr, f)
    GC.@preserve r unsafe_load(fptr)
end

function Base.setproperty!(x::Ptr{VkRenderingAttachmentInfo}, f::Symbol, v)
    unsafe_store!(getproperty(x, f), v)
end

function Base.propertynames(x::VkRenderingAttachmentInfo, private::Bool = false)
    (:sType, :pNext, :imageView, :imageLayout, :resolveMode, :resolveImageView, :resolveImageLayout, :loadOp, :storeOp, :clearValue, if private
            fieldnames(typeof(x))
        else
            ()
        end...)
end

function VkRenderingAttachmentInfo(sType::VkStructureType, pNext::Ptr{Cvoid}, imageView::VkImageView, imageLayout::VkImageLayout, resolveMode::VkResolveModeFlagBits, resolveImageView::VkImageView, resolveImageLayout::VkImageLayout, loadOp::VkAttachmentLoadOp, storeOp::VkAttachmentStoreOp, clearValue::VkClearValue)
    ref = Ref{VkRenderingAttachmentInfo}()
    ptr = Base.unsafe_convert(Ptr{VkRenderingAttachmentInfo}, ref)
    ptr.sType = sType
    ptr.pNext = pNext
    ptr.imageView = imageView
    ptr.imageLayout = imageLayout
    ptr.resolveMode = resolveMode
    ptr.resolveImageView = resolveImageView
    ptr.resolveImageLayout = resolveImageLayout
    ptr.loadOp = loadOp
    ptr.storeOp = storeOp
    ptr.clearValue = clearValue
    ref[]
end

It feels like it might be working fine but at the same time it could easily break code that used to introspect into e.g. fieldnames instead of the user-facing propertynames.

It might be just fine but I'd prefer to have confirmation downstream, outside the VulkanCore.jl test suite, that the changes from updating to latest Clang don't behave unexpectedly.

Otherwise it might be preferable to keep this PR limited to updating to 1.4 bindings and keep the same version for Clang.jl as we used before. We can always do a PR later that bumps Clang.jl to the latest version if needed.