Giter VIP home page Giter VIP logo

v-ez's Introduction

V-EZ

V-EZ is an open source, cross-platform (Windows and Linux) wrapper intended to alleviate the inherent complexity and application responsibility of using the Vulkan API. V-EZ attempts to bridge the gap between traditional graphics APIs and Vulkan by providing similar semantics to Vulkan while lowering the barrier to entry and providing an easier to use API.

Documentation

The documentation for V-EZ can be found here

Prerequisites

  • Windows 7, 8.1, 10 64-bit
  • Linux 64-bit (tested on Fedora, Ubuntu)
  • Visual Studio® 2015 and later
  • GCC 4.9 and later
  • CMake 3.8 and later
  • LunarG Vulkan SDK 1.1.70

Hardware Support

V-EZ is not hardware vendor specific and should work on non-AMD hardware.

Building V-EZ

  • Run cmake to generate Visual Studio solution files or Linux make files. No specific settings need to be set.

  • Pull down submodules

git submodule init

git submodule update

  • Build V-EZ project.

v-ez's People

Contributors

andmoos avatar ccoors avatar soconne avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

v-ez's Issues

Resizing the window crashes samples

Resizing the window of MSVC x64 Win10 compiled samples sometimes results in a properly resized framebuffer, but often crashes the program. Release builds handle resizing correctly more often, but eventually crash as well. In visual studio it triggers a breakpoint at SimpleQuad.cpp line 98: Unhandled exception at 0x00007FFF5A614008 in SimpleQuadD.exe: Microsoft C++ exception: std::bad_function_call at memory location 0x0000004E773AE810.

Some of the validation warnings presented in debug builds:

Name: GeForce GTX 1050
Type: DISCRETE_GPU
MEM(WARNING): Object: 0x12 | vkGetFenceStatus called for fence 0x12 which has not been submitted on a Queue or during acquire next image.
ObjectTracker(ERROR): Object: 0x177a5bcc288 | Invalid CommandBuffer Object 0x177a5bcc288. The spec valid usage text states 'pCommandBuffers must be a valid pointer to an array of commandBufferCount VkCommandBuffer handles, each element of which must either be a valid handle or NULL' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-vkFreeCommandBuffers-pCommandBuffers-00048)
ObjectTracker(ERROR): Object: 0x177a5bcc288 | Unable to remove CommandBuffer obj 0x177a5bcc288. Was it created? Has it already been destroyed?
ObjectTracker(ERROR): Object: 0x177c8f6f6d8 | Invalid CommandBuffer Object 0x177c8f6f6d8. The spec valid usage text states 'pCommandBuffers must be a valid pointer to an array of commandBufferCount VkCommandBuffer handles, each element of which must either be a valid handle or NULL' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-vkFreeCommandBuffers-pCommandBuffers-00048)
ObjectTracker(ERROR): Object: 0x177c8f6f6d8 | Unable to remove CommandBuffer obj 0x177c8f6f6d8. Was it created? Has it already been destroyed?
MEM(WARNING): Object: 0x8 | vkGetFenceStatus called for fence 0x8 which has not been submitted on a Queue or during acquire next image.
MEM(WARNING): Object: 0x8 | vkGetFenceStatus called for fence 0x8 which has not been submitted on a Queue or during acquire next image.

...

MEM(WARNING): Object: 0x8 | vkGetFenceStatus called for fence 0x8 which has not been submitted on a Queue or during acquire next image.
THREADING(ERROR): Object: 0x8 | THREADING ERROR : object of type VkFence is simultaneously used in thread 22072 and thread 6244
MEM(WARNING): Object: 0x8 | vkGetFenceStatus called for fence 0x8 which has not been submitted on a Queue or during acquire next image.
MEM(WARNING): Object: 0x8 | vkGetFenceStatus called for fence 0x8 which has not been submitted on a Queue or during acquire next image.

...

MEM(WARNING): Object: 0x8 | vkGetFenceStatus called for fence 0x8 which has not been submitted on a Queue or during acquire next image.
THREADING(ERROR): Object: 0x8 | THREADING ERROR : object of type VkFence is simultaneously used in thread 22072 and thread 6244
MEM(WARNING): Object: 0x8 | vkGetFenceStatus called for fence 0x8 which has not been submitted on a Queue or during acquire next image.
MEM(WARNING): Object: 0x8 | vkGetFenceStatus called for fence 0x8 which has not been submitted on a Queue or during acquire next image.
THREADING(ERROR): Object: 0x8 | THREADING ERROR : object of type VkFence is simultaneously used in thread 6244 and thread 22072
MEM(WARNING): Object: 0x8 | vkGetFenceStatus called for fence 0x8 which has not been submitted on a Queue or during acquire next image.

...

MEM(WARNING): Object: 0x8 | vkGetFenceStatus called for fence 0x8 which has not been submitted on a Queue or during acquire next image.
THREADING(ERROR): Object: 0x8 | THREADING ERROR : object of type VkFence is simultaneously used in thread 22072 and thread 6244
THREADING(ERROR): Object: 0x8 | THREADING ERROR : object of type VkFence is simultaneously used in thread 22072 and thread 6244
MEM(WARNING): Object: 0x8 | vkGetFenceStatus called for fence 0x8 which has not been submitted on a Queue or during acquire next image.
MEM(WARNING): Object: 0x8 | vkGetFenceStatus called for fence 0x8 which has not been submitted on a Queue or during acquire next image.
MEM(WARNING): Object: 0x8 | vkGetFenceStatus called for fence 0x8 which has not been submitted on a Queue or during acquire next image.
MEM(WARNING): Object: 0x22 | vkGetFenceStatus called for fence 0x22 which has not been submitted on a Queue or during acquire next image.

Validation layer complains about vkCreateDescriptorPool's size count

Error message:

ParameterValidation(ERROR / SPEC): object: 0x0 type: 0 msgNum: 75663387 - vkCreateDescriptorPool: parameter pCreateInfo->poolSizeCount must be greater than 0. The spec valid usage text states 'poolSizeCount must be greater than 0' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkDescriptorPoolCreateInfo-poolSizeCount-arraylength)
ParameterValidation(ERROR): object: 0x0 type: 0 location: 243 msg_code: 75663387: Object: 0x0 | vkCreateDescriptorPool: parameter pCreateInfo->poolSizeCount must be greater than 0. The spec valid usage text states 'poolSizeCount must be greater than 0' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkDescriptorPoolCreateInfo-poolSizeCount-arraylength)

Appears after inserting this code in a render pass:

  auto smgr = std::dynamic_pointer_cast<scene::CSceneManager>(Device.getSceneManager());
  uint32_t i = 0;
  VkDeviceSize offsets[1] = { 0 };
  for (const auto& node : smgr->getSceneNodeList(CurrentPass))
  {
    auto n = std::dynamic_pointer_cast<scene::IMeshSceneNode>(node);
    auto& mesh = n->getMesh();
    auto& meshBuffer = mesh->getMeshBuffer(0);

    // Allocate a buffer for the vertices and upload the host data.
    VezBufferCreateInfo bufferCreateInfo = {};
    VkBuffer vertexBuffer;
    bufferCreateInfo.usage = VK_BUFFER_USAGE_TRANSFER_DST_BIT | VK_BUFFER_USAGE_VERTEX_BUFFER_BIT;
    bufferCreateInfo.size = sizeof(float) * meshBuffer.getVertexCount();
    auto result = vezCreateBuffer(VKDevice, VEZ_MEMORY_GPU_ONLY, &bufferCreateInfo, &vertexBuffer);
    if (result != VK_SUCCESS) return;

    result = vezBufferSubData(VKDevice, vertexBuffer, 0, bufferCreateInfo.size, static_cast<const void*>(meshBuffer.getVertices()));

    vezCmdBindVertexBuffers(0, 1, &vertexBuffer, offsets);
    
    // Allocate a buffer for the indices and upload the host data.
    VkBuffer indexBuffer;
    bufferCreateInfo.usage = VK_BUFFER_USAGE_TRANSFER_DST_BIT | VK_BUFFER_USAGE_INDEX_BUFFER_BIT;
    bufferCreateInfo.size = sizeof(std::uint32_t) * meshBuffer.getIndexCount();
    result = vezCreateBuffer(VKDevice, VEZ_MEMORY_GPU_ONLY, &bufferCreateInfo, &indexBuffer);
    if (result != VK_SUCCESS) return;

    result = vezBufferSubData(VKDevice, indexBuffer, 0, bufferCreateInfo.size, static_cast<const void*>(meshBuffer.getIndices()));
    if (result != VK_SUCCESS) return;
    vezCmdBindIndexBuffer(indexBuffer, 0, VK_INDEX_TYPE_UINT32);

    VezVertexInputFormat vertexInputFormat;
    VkVertexInputBindingDescription bindingDesc = { 0, sizeof(float) * 6, VK_VERTEX_INPUT_RATE_VERTEX };
    std::array<VkVertexInputAttributeDescription, 2> attribDesc = {
      VkVertexInputAttributeDescription{ 0, 0, VK_FORMAT_R32G32B32_SFLOAT, 0 },
      VkVertexInputAttributeDescription{ 1, 0, VK_FORMAT_R32G32B32_SFLOAT, sizeof(float) * 3 }
    };
    VezVertexInputFormatCreateInfo vertexInputFormatCreateInfo = {};
    vertexInputFormatCreateInfo.vertexBindingDescriptionCount = 1;
    vertexInputFormatCreateInfo.pVertexBindingDescriptions = &bindingDesc;
    vertexInputFormatCreateInfo.vertexAttributeDescriptionCount = static_cast<uint32_t>(attribDesc.size());
    vertexInputFormatCreateInfo.pVertexAttributeDescriptions = attribDesc.data();
    result = vezCreateVertexInputFormat(VKDevice, &vertexInputFormatCreateInfo, &vertexInputFormat);

    vezCmdSetVertexInputFormat(vertexInputFormat);
    vezCmdDrawIndexed(meshBuffer.getIndexCount(), 1, 0, 0, 0);
  }

Image layout issues

I get a lot of layout issues reported from the validation layers:
layout_issue_0
layout_issue_1
layout_issue_2
My images have a lot of usage flags. Maybe this confuses V-EZ somehow?

Validation layer errors in samples

When I run the SimpleQuad sample I get these errors every frame.

DS (ERROR): object: 0x24026dd6b58 type: 6 location: 6721 msgCode: 461375810: vkCmdPipelineBarrier(): pImageMemBarriers[0].dstAccessMask (0x1000) is not supported by dstStageMask (0x1). The spec valid usage text states 'Each element of pMemoryBarriers, pBufferMemoryBarriers and pImageMemoryBarriers must not have any access flag included in its dstAccessMask member if that bit is not supported by any of the pipeline stages in dstStageMask, as specified in the table of supported access types.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-vkCmdPipelineBarrier-pMemoryBarriers-01185)
DS (ERROR): object: 0x24026dd6b58 type: 6 location: 6721 msgCode: 461375810: vkCmdPipelineBarrier(): pImageMemBarriers[1].dstAccessMask (0x800) is not supported by dstStageMask (0x1). The spec valid usage text states 'Each element of pMemoryBarriers, pBufferMemoryBarriers and pImageMemoryBarriers must not have any access flag included in its dstAccessMask member if that bit is not supported by any of the pipeline stages in dstStageMask, as specified in the table of supported access types.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-vkCmdPipelineBarrier-pMemoryBarriers-01185)

Layers from VulkanSDK 1.0.65.1.

Validation layer errors in samples

Hello!
I'm very interested in your work, so I took a look at the examples, and it seems they all generate errors on my pc.
The line 186 of simpleQuad.cpp generates these two errors:
VUID-VkMappedMemoryRange-size-01390(ERROR / SPEC): msgNum: 203426524 - vkFlushMappedMemoryRanges: Size in pMemRanges[0] is 0x18, which is not a multiple of VkPhysicalDeviceLimits::nonCoherentAtomSize (0x40). The spec valid usage text states 'If size is not equal to VK_WHOLE_SIZE, size must either be a multiple of VkPhysicalDeviceLimits::nonCoherentAtomSize, or offset plus size must equal the size of memory.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkMappedMemoryRange-size-01390)
and
Objects: 1 [0] 0x4, type: 8, name: (null) Validation(ERROR): msg_code: 203426524: [ VUID-VkMappedMemoryRange-size-01390 ] [ VUID-VkMappedMemoryRange-size-01390 ] Object: 0x4 (Type = 8) | vkFlushMappedMemoryRanges: Size in pMemRanges[0] is 0x18, which is not a multiple of VkPhysicalDeviceLimits::nonCoherentAtomSize (0x40). The spec valid usage text states 'If size is not equal to VK_WHOLE_SIZE, size must either be a multiple of VkPhysicalDeviceLimits::nonCoherentAtomSize, or offset plus size must equal the size of memory.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkMappedMemoryRange-size-01390)

After that, the line 339 generate these errors:
VUID-VkSubpassDependency-dstAccessMask-00869(ERROR / SPEC): msgNum: 333448906 - CreateRenderPass: pDependencies[0].dstAccessMask (0x100) is not supported by dstStageMask (0x2000). The spec valid usage text states 'Any access flag included in dstAccessMask must be supported by one of the pipeline stages in dstStageMask, as specified in the table of supported access types.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkSubpassDependency-dstAccessMask-00869)
,
Objects: 1 [0] 0x0, type: 0, name: (null) Validation(ERROR): msg_code: 333448906: [ VUID-VkSubpassDependency-dstAccessMask-00869 ] [ VUID-VkSubpassDependency-dstAccessMask-00869 ] Object: VK_NULL_HANDLE (Type = 0) | CreateRenderPass: pDependencies[0].dstAccessMask (0x100) is not supported by dstStageMask (0x2000). The spec valid usage text states 'Any access flag included in dstAccessMask must be supported by one of the pipeline stages in dstStageMask, as specified in the table of supported access types.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkSubpassDependency-dstAccessMask-00869)
,
VUID-VkSubpassDependency-srcAccessMask-00868(ERROR / SPEC): msgNum: 333448904 - CreateRenderPass: pDependencies[1].srcAccessMask (0x100) is not supported by srcStageMask (0x2000). The spec valid usage text states 'Any access flag included in srcAccessMask must be supported by one of the pipeline stages in srcStageMask, as specified in the table of supported access types.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkSubpassDependency-srcAccessMask-00868)
and
Objects: 1 [0] 0x0, type: 0, name: (null) Validation(ERROR): msg_code: 333448904: [ VUID-VkSubpassDependency-srcAccessMask-00868 ] [ VUID-VkSubpassDependency-srcAccessMask-00868 ] Object: VK_NULL_HANDLE (Type = 0) | CreateRenderPass: pDependencies[1].srcAccessMask (0x100) is not supported by srcStageMask (0x2000). The spec valid usage text states 'Any access flag included in srcAccessMask must be supported by one of the pipeline stages in srcStageMask, as specified in the table of supported access types.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkSubpassDependency-srcAccessMask-00868)

Note that at the end, the SimpleQuad window finally launches.

I hope it can help improve your library. Thx 😄

Setting dynamic states through pipeline states effectively does nothing

Yea i'm sure you know about it. Setting things like depthBias etc. which are also dynamic states does nothing, because all dynamic states are enabled by default:

VezRasterizationState rzState;
 rzState.depthBiasConstantFactor = 1.0f;
 rzState.depthBiasClamp = 1.0f;
 rzState.depthBiasSlopeFactor = 1.0f;

All fields above are ignored because the dynamic state with the default values is set. Either update the dynamic state with the values above if no command for setting it was recorded or remove these fields completely.

Port to macOS, too!

Given that the MoltenVK translation layer is now open source and handled by the Khronos group, please consider compiling for macOS in addition to Linux.

While MoltenVK's translation apparently isn't perfect, it will definitely improve over time, and supporting macOS in addition to Windows and Linux will make V-EZ a more attractive target for ISVs who may want to provide builds for this platform down the line.

vezImportVkImage

V-EZ needs a function to remove the object implementation manually, if an image was imported.
Problem is when i restart my engine V-EZ has still the old object implementation and crashes because it retrieves the old handle and not the new one.

Error when binding textures with descriptor sets

In StreamEncoder.cpp:952:

dsWrite.pImageInfo = reinterpret_cast<const VkDescriptorImageInfo*>(imageInfos.size());

This should probably be

dsWrite.pImageInfo = imageInfos.data();

Since neither size() nor the cast (especially the cast) make sense.

SPIR-V shaders support?

Hello. I want ask question about shaders: have V-EZ support of SPIR-V, only only GLSL directly? I planned to port our renderer host for V-EZ. Very interest...
Also, will have C++ (V-EZ-Hpp) version?

Problem while running the example SoftwareRasterization

Ubuntu 18.01

GeForce GTX 1080
Selected device: GeForce GTX 1080
IMAGE(ERROR / SPEC): object: 0x0 type: 0 msgNum: 165676966 - vkCreateImage: usage bit VK_IMAGE_USAGE_STORAGE_BIT is not supported for format VK_FORMAT_B8G8R8A8_UNORM with tiling VK_IMAGE_TILING_LINEAR. The spec valid usage text states 'If tiling is VK_IMAGE_TILING_LINEAR, and VkFormatProperties::linearTilingFeatures (as returned by vkGetPhysicalDeviceFormatProperties with the same value of format) does not include VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT, usage must not contain VK_IMAGE_USAGE_STORAGE_BIT' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkImageCreateInfo-tiling-00979)
IMAGE(ERROR): object: 0x0 type: 0 location: 663 msg_code: 165676966: Object: 0x0 | vkCreateImage: usage bit VK_IMAGE_USAGE_STORAGE_BIT is not supported for format VK_FORMAT_B8G8R8A8_UNORM with tiling VK_IMAGE_TILING_LINEAR. The spec valid usage text states 'If tiling is VK_IMAGE_TILING_LINEAR, and VkFormatProperties::linearTilingFeatures (as returned by vkGetPhysicalDeviceFormatProperties with the same value of format) does not include VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT, usage must not contain VK_IMAGE_USAGE_STORAGE_BIT' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkImageCreateInfo-tiling-00979)
IMAGE(ERROR / SPEC): object: 0x0 type: 0 msgNum: 165676888 - vkCreateImage: The combination of format, type, tiling, usage and flags supplied in the VkImageCreateInfo struct is reported by vkGetPhysicalDeviceImageFormatProperties() as unsupported. The spec valid usage text states 'The combination of format, imageType, tiling, usage, and flags must be supported, as indicated by a VK_SUCCESS return value from vkGetPhysicalDeviceImageFormatProperties invoked with the same values passed to the corresponding parameters.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkImageCreateInfo-format-00940)
IMAGE(ERROR): object: 0x0 type: 0 location: 708 msg_code: 165676888: Object: 0x0 | vkCreateImage: The combination of format, type, tiling, usage and flags supplied in the VkImageCreateInfo struct is reported by vkGetPhysicalDeviceImageFormatProperties() as unsupported. The spec valid usage text states 'The combination of format, imageType, tiling, usage, and flags must be supported, as indicated by a VK_SUCCESS return value from vkGetPhysicalDeviceImageFormatProperties invoked with the same values passed to the corresponding parameters.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkImageCreateInfo-format-00940)
ParameterValidation(ERROR / SPEC): object: 0x0 type: 0 msgNum: 4 - vkCmdPipelineBarrier: required parameter pImageMemoryBarriers[0].image specified as VK_NULL_HANDLE
ParameterValidation(ERROR): object: 0x0 type: 0 location: 436 msg_code: 4: Object: 0x0 | vkCmdPipelineBarrier: required parameter pImageMemoryBarriers[0].image specified as VK_NULL_HANDLE
ObjectTracker(ERROR / SPEC): object: 0x0 type: 10 msgNum: 167813121 - Invalid Image Object 0x0. The spec valid usage text states 'image must be a valid VkImage handle' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkImageMemoryBarrier-image-parameter)
ObjectTracker(ERROR): object: 0x0 type: 10 location: 198 msg_code: 167813121: Object: 0x0 | Invalid Image Object 0x0. The spec valid usage text states 'image must be a valid VkImage handle' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkImageMemoryBarrier-image-parameter)
[1] 24237 segmentation fault (core dumped) ./SoftwareRasterization

Give the EZ versions of things a proper prefix so Vulkan conflicts are removed

Currently this library does not allow linking alongside with the Vulkan static library because the functions are named the same. Why do things this way? Why not just prefix the functions with something like "Vez" so there is no conflict with the normal Vulkan functions?

Ditto with the header files - Why re-define all the stuff that's already defined in vulkan.h? Why not just use vulkan.h directly and add whatever stuff you need to, perhaps prefixed?

I think these two limitations (can't use vulkan.h in same source file, can't link vulkan.lib) would be a showstopper for many people who would be considering using this middleware. I would be curious to hear what the rationale is for such a design choice?

Wrong .vecsize for matrices

The .vecsize field for VezMemberInfo (i guess for VezPipelineResource aswell) is 4 for matrices which should be 16 in this case, because there is no other field which specifies the length for an vector.
This way a real vec4 in hlsl has also a vecsize of 4 and is indistinguishable from an matrix except for the size field. But to tell them apart by inspecting the size field seems rather hacky.

!!!! Binding subsequent buffers via "vezCmdBindBuffer" doesn't work

And found another bug :D
If you bind several buffers via "vezCmdBindBuffer" all descriptor-set bindings get the same "streamposition" which causes only the first buffer to be bound in StreamDecoder.cpp Line 172:

            // Check to see if there are any descriptor set bindings to be inserted.
            if (nextDescriptorSetBinding != encoder.GetDescriptorSetBindings().cend())
            {
                // The next descriptor set binding's stream position must be equal to the current read position.
                if (nextDescriptorSetBinding->streamPosition == streamPosition)
                {
                    // Bind the descriptor set.
                    vkCmdBindDescriptorSets(commandBuffer.GetHandle(), nextDescriptorSetBinding->bindPoint, nextDescriptorSetBinding->pipelineLayout,
                        nextDescriptorSetBinding->setIndex, 1, &nextDescriptorSetBinding->descriptorSet, 0, nullptr);

                    // Move to the next descriptor set binding in the list.
                    ++nextDescriptorSetBinding;
                }
            }

Every descriptor-set binding has the same stream-position:
descriptor_sets

This should be fixed ASAP, because it prevents to bind any subsequent descriptor-sets, because the "nextDescriptorSetBinding"-variable points to the next descriptor-set with the same stream-position. Because the decoder continues to read from the stream the "nextDescriptorSetBinding"-variable is stuck forever.

Instancing example?

I'm implementing muti-draw indirect with V-EZ and stuck at binding instance data.
Do you have any suggestions?

VR with Oculus SDK not possible with V-EZ

V-EZ does has a Wrapper for the standard vulkan swapchain to work with images/views created via vezCreateImage and vezCreateImageView.
Unfortunately the OculusSDK has its own Swapchain and gives only access to their VkImage's via

VkImage image;
ovr_GetTextureSwapChainBufferVk( session, m_swapChain, i, &image );

// Can't create an VkImageView with vezCreateImageView() because image was not created via vezCreateImage()

I need a way to use the VkImage returned from the oculus sdk in v-ez.

Macro produces non-portable functions

I'm trying to compile for Android and this error appears.

v-ez/Source/Utility/ObjectLookup.h:54:9: error: functions that differ only in their return type
      cannot be overloaded
        OBJECT_LOOKUP_DECLARATION(VkShaderModule, ShaderModule);

Here is the definition of it:

    #define OBJECT_LOOKUP_DECLARATION(Handle, Impl)\
    extern vez::Impl* GetObjectImpl(Handle handle);\
    extern void AddObjectImpl(Handle handle, vez::Impl* object);\
    extern void RemoveObjectImpl(Handle handle);

I think for Android all Vulkan Handles are the same type (uint?) so this won't work.
Check out my attempt to port here: https://github.com/manhnt9/V-EZ/tree/android

Fragment shader seems not executed

I'm trying to render a colored triangle.
Here is my shaders:

  shaderInfo.VSSource =
    "#version 450\n"
    "#extension GL_ARB_separate_shader_objects : enable\n"
    "layout (location = 0) in vec4 position;\n"
    "void main() {\n"
    "  gl_Position = position;\n"
    "}\n";

  shaderInfo.PSSource =
    "#version 450\n"
    "#extension GL_ARB_separate_shader_objects : enable\n"
    "layout (location = 0) out vec4 frag_color;\n"
    "void main() {\n"
    "  frag_color = vec4(0.0, 1.0, 0.0, 1.0);\n"
    "}\n";

Both shaders are created and included in pipeline creation.
Screen output is only a solid color (clear color).
Using RenderDoc, I found out that the vertices are rendered correctly.

screenshot_2018-10-05_09-45-19

screenshot_2018-10-05_09-40-59

And there's no Fragment Shader Output tab in RenderDoc for me to see.
So I think it's not executed.
Is there some step that I am missing?
My capture file: https://drive.google.com/open?id=1jh1YtqKVdm8P3NEYryRPaQqksky0Vyrq

Thank you!

Thank you for open sourcing it, guys! :) AMD is the best!

No support for VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT

So tried my engine on my laptop and the weird thing is validation layers are working there, but not on my desktop pc...
Anyway, had a couple validation complains. One of them is that it's not possible to create an ImageView with VK_IMAGE_VIEW_TYPE_CUBE or VK_IMAGE_VIEW_TYPE_CUBE_ARRAY because there is no way to create the image with the VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT flag (there is no flag field in VezImageCreateInfo).

Typo in documentation example

Section 1: Putting it all together, the final example:
line 81:
VkDeviceCreateInfo deviceCreateInfo = {};
should be
VezDeviceCreateInfo deviceCreateInfo = {};

Compile with -fPIC?

I was getting some LD errors on g++ 7.3 on Linux Mint 19, when linking. g++ suggested I add the -fPIC definition.

Adding the following to the root CMakeLists.txt file, it compiled.

add_definitions(-fPIC)

Installation instructions

It appears at the moment that the intended way to use V-EZ as a dependency for a CMake project is to have it as a subdirectory and use add_subdirectory in the CMakeLists.txt. It would be nice if this was documented somewhere.

For use with non-CMake projects, it would perhaps be better if an install step was included that put headers and binaries in the appropriate places. Then for ease of use with CMake projects using find_package, an appropriate "FindV-EZ.cmake" file could be placed in a directory in CMake's global module search path.

Add a license

As most other GPUOpen-LibrariesAndSDKs are MIT I guess it will be MIT, but having legal assurance would be nice.

Incompatible render passes

When using my stereo rendering pipeline i get the following error:
error
Trying to investigate and give some more information.

Open source?

Hello,

This is great for upgrading some old OpenGL codebases in the VFX world as well. Will this be an open source project? It's a bit strange having this binary-only, thought this was about being GPUOpen. ;)

Kind regards

How to draw indirect?

Hi, I'm very interested in a multi-draw indirect example.
Currently I can't find any vezCmdDrawIndirect or similar.
Could you give some suggestions on how this should be done with V-EZ?

Disabling vsync does not work on surfaces who doesn't support immediate mode

So as the title already states, a fix for this is using the MAILBOX mode if available.

I slightly modified the code in swapchain.cpp:
static VkPresentModeKHR ChooseSwapPresentMode(const std::vector<VkPresentModeKHR>& availablePresentModes, const std::vector<VkPresentModeKHR>& desiredModes) { for (auto& desiredMode : desiredModes) { for (const auto& availablePresentMode : availablePresentModes) { if (desiredMode == availablePresentMode) return desiredMode; } } if (availablePresentModes.size() > 0) return availablePresentModes[0]; else return VK_PRESENT_MODE_FIFO_KHR; }

And using it this way:
std::vector<VkPresentModeKHR> desiredModes; if (m_vsyncEnabled) desiredModes = { VK_PRESENT_MODE_FIFO_KHR }; else desiredModes = { VK_PRESENT_MODE_MAILBOX_KHR, VK_PRESENT_MODE_IMMEDIATE_KHR }; auto presentMode = ChooseSwapPresentMode(m_swapchainSupport.presentModes, desiredModes); // Determine the total number of images required. uint32_t imageCount = m_swapchainSupport.capabilities.minImageCount + 1; if (presentMode == VK_PRESENT_MODE_MAILBOX_KHR) // Try to use tripple buffering with mailbox mode imageCount = 3;

Unfortunately i have no idea how i can make a pull request, otherwise i would have done it. Sorry!

PipelineBarrier issue

In my render-to-texture scene the validation layer keeps printing the following error:
pipelinebarrier_issue

std::ceil is not a member std

On Linux Mint 19, gcc version "g++ (Ubuntu 7.3.0-16ubuntu3) 7.3.0"

There seems to be a missing #include<cmath> in Device.cpp

Please add support for disabling vsync, having access to the compiled spirv src and reflection on ubo members

Hello folks,
first things first: Awesome lib! I love it so far.

1.) VSync
I really need to disable vsync but i really don't want to mess with the vez code myself if i don't have to.
I recognized there is a function "vezDeviceSetVSync", which unfortunately just returns that the feature is not present yet. Could you please add support for it?

2.) Compiling glsl
Because compiling glsl is terrible slow in debug mode with vez (i did it before myself with shaderc, that was WAY faster in debug), i suggest a function like "vezCompileGLSL(device, info, spv)", which returns the compiled spirv-code, so its able to dump it on disk and read it later.

3.) Reflection on ubo members
This is probably a must have. The information for all the uniform buffer members is simply not parsed, only the whole ubo size is computed. It would be nice to have access to all the members names and types in a ubo. SPIRV-Cross supports it and i had it already implemented before i decided to switch using vez instead of doing everything from scratch

All these points shouldn't take to much time for somebody who's familiar with the code.
If you can't afford time for it i will do it myself after i have done everything else, but i'm also very short on time right now. (Writing my Master Thesis)

Thanks and have a great day!
SH

Wrong loop condition in Device.cpp Line 779

for (auto arrayLayer = pSubDataInfo->imageSubresource.baseArrayLayer; arrayLayer < pSubDataInfo->imageSubresource.layerCount; ++arrayLayer)

should be obviously:

for (auto arrayLayer = pSubDataInfo->imageSubresource.baseArrayLayer; arrayLayer < pSubDataInfo->imageSubresource.baseArrayLayer+pSubDataInfo->imageSubresource.layerCount ++arrayLayer)

Was trying to upload each face to a cubemap :-)

Don't force vertex data mapping.

Currently V-EZ is mapping vertex's position data and normal data into one buffer.
This is very inconvenient since users often have code like this:

std::vector<glm::vec3> PositionBuffer;
std::vector<glm::vec3> NormalBuffer;

V-EZ's mapping code:

vertices.push_back(pos.x);
vertices.push_back(pos.y);
vertices.push_back(pos.z);
vertices.push_back(normal.x);
vertices.push_back(normal.y);
vertices.push_back(normal.z);
...
 // Allocate a buffer for the vertices and upload the host data.
VezBufferCreateInfo bufferCreateInfo = {};
bufferCreateInfo.usage = VK_BUFFER_USAGE_TRANSFER_DST_BIT | VK_BUFFER_USAGE_VERTEX_BUFFER_BIT;
bufferCreateInfo.size = sizeof(float) * vertices.size();
auto result = vezCreateBuffer(device, VEZ_MEMORY_GPU_ONLY, &bufferCreateInfo, &m_vertexBuffer);
if (result != VK_SUCCESS)
    return false;

I suggest separating position and normal buffer to give more flexibility and basic usage.
Normal should not be required for every case.
This took me several hours trying to draw a triangle on the screen and eventually found out that my normal data is missing. Then I got to provide another PositionNormalBuffer for my data, which increased memory usage.

How to clear screen? Bugs spotted.

Hi, I'm using V-EZ for a simple example: clearing screen to a specific color.
Here is my command buffer generation.
I only create and bind 1 color attachment for the framebuffer.

void CVulkanDriver::createCommandBuffer()
{
  // Get the graphics queue handle.
  vezGetDeviceGraphicsQueue(VKDevice, 0, &GraphicsQueue);

  // Create a command buffer handle.
  VezCommandBufferAllocateInfo allocInfo = {};
  allocInfo.queue = GraphicsQueue;
  allocInfo.commandBufferCount = 1;
  if (vezAllocateCommandBuffers(VKDevice, &allocInfo, &CommandBuffer) != VK_SUCCESS)
  {
    SDL_LogError(SDL_LOG_CATEGORY_RENDER, "vezAllocateCommandBuffers failed");
    exit(1);
  }

  // Begin command buffer recording.
  if (vezBeginCommandBuffer(CommandBuffer, VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT) != VK_SUCCESS)
  {
    SDL_LogError(SDL_LOG_CATEGORY_RENDER, "vezBeginCommandBuffer failed");
    exit(1);
  }

  // Set the viewport state and dimensions.
  auto width = Device.getWidth();
  auto height = Device.getHeight();
  
  VkViewport viewport = { 0.0f, 0.0f, static_cast<float>(width), static_cast<float>(height), 0.0f, 1.0f };
  VkRect2D scissor = { { 0, 0 },{ static_cast<uint32_t>(width), static_cast<uint32_t>(height) } };
  vezCmdSetViewport(0, 1, &viewport);
  vezCmdSetScissor(0, 1, &scissor);
  vezCmdSetViewportState(1);

  VkClearColorValue clearColor = {
    { 0.4f, 0.6f, 0.9f, 1.0f } // R, G, B, A
  };

  // Define clear values for the swapchain's color and depth attachments.
  // std::array<VezAttachmentReference, 2> attachmentReferences = {};
  std::array<VezAttachmentReference, 1> attachmentReferences = {};
  attachmentReferences[0].clearValue.color = clearColor;
  attachmentReferences[0].loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR;
  attachmentReferences[0].storeOp = VK_ATTACHMENT_STORE_OP_STORE;
  // attachmentReferences[1].clearValue.depthStencil.depth = 1.0f;
  // attachmentReferences[1].loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR;
  // attachmentReferences[1].storeOp = VK_ATTACHMENT_STORE_OP_STORE;

  // Begin a render pass.
  VezRenderPassBeginInfo beginInfo = {};
  beginInfo.framebuffer = Framebuffer.handle;
  beginInfo.attachmentCount = static_cast<uint32_t>(attachmentReferences.size());
  beginInfo.pAttachments = attachmentReferences.data();
  vezCmdBeginRenderPass(&beginInfo);

  // Bind the pipeline and associated resources.
  vezCmdBindPipeline(BasicPipeline.pipeline);
  // vezCmdBindBuffer(m_uniformBuffer, 0, VK_WHOLE_SIZE, 0, 0, 0);
  // vezCmdBindImageView(ImageView, Sampler, 0, 1, 0);

  // Set depth stencil state.
  // VezPipelineDepthStencilState depthStencilState = {};
  // depthStencilState.depthTestEnable = VK_TRUE;
  // depthStencilState.depthWriteEnable = VK_TRUE;
  // depthStencilState.depthCompareOp = VK_COMPARE_OP_LESS_OR_EQUAL;
  // vezCmdSetDepthStencilState(&depthStencilState);

  // Bind the vertex buffer and index buffers.
  // VkDeviceSize offset = 0;
  // vezCmdBindVertexBuffers(0, 1, &m_vertexBuffer, &offset);
  // vezCmdBindIndexBuffer(m_indexBuffer, 0, VK_INDEX_TYPE_UINT32);

  // Draw the quad.
  // vezCmdDrawIndexed(6, 1, 0, 0, 0);

  // End the render pass.
  vezCmdEndRenderPass();

  // End command buffer recording.
  if (vezEndCommandBuffer() != VK_SUCCESS)
  {
    SDL_LogError(SDL_LOG_CATEGORY_RENDER, "vezEndCommandBuffer failed");
    exit(1);
  }
}

Example code from V-EZ docs Part 2

[Opened a new issue cause the previous #11 one was closed but not fixed.]

I made some adjustments...
#include <V-EZ.h> should be "#include <VEZ.h>"
"appinfo.engineVersion" should be "appInfo.engineVersion" (capital "I")
I included vector cause it was used.

But it still fails to compile.
Because "VezSurfaceCreateInfo" is undefined in VEZ.h

I think it might be more useful if I posted the output of g++ with those changes.

**** Incremental Build of configuration Debug for project V-EZ ****
make all 
Building file: ../src/V-EZ.cpp
Invoking: GCC C++ Compiler
g++ -I/home/User/Documents/Programming/Libaries/V-EZ/Source -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/V-EZ.d" -MT"src/V-EZ.o" -o "src/V-EZ.o" "../src/V-EZ.cpp"
../src/V-EZ.cpp: In function ‘bool InitVulkanEZ()’:
../src/V-EZ.cpp:45:5: error: ‘VezSurfaceCreateInfo’ was not declared in this scope
     VezSurfaceCreateInfo surfaceCreateInfo = {};
     ^~~~~~~~~~~~~~~~~~~~
../src/V-EZ.cpp:45:5: note: suggested alternative: ‘VezImageCreateInfo’
     VezSurfaceCreateInfo surfaceCreateInfo = {};
     ^~~~~~~~~~~~~~~~~~~~
     VezImageCreateInfo
../src/V-EZ.cpp:46:5: error: ‘surfaceCreateInfo’ was not declared in this scope
     surfaceCreateInfo.hinstance = GetModuleHandle(nullptr);
     ^~~~~~~~~~~~~~~~~
../src/V-EZ.cpp:46:5: note: suggested alternative: ‘instanceCreateInfo’
     surfaceCreateInfo.hinstance = GetModuleHandle(nullptr);
     ^~~~~~~~~~~~~~~~~
     instanceCreateInfo
../src/V-EZ.cpp:46:35: error: ‘GetModuleHandle’ was not declared in this scope
     surfaceCreateInfo.hinstance = GetModuleHandle(nullptr);
                                   ^~~~~~~~~~~~~~~
../src/V-EZ.cpp:47:30: error: ‘glfwGetWin32Window’ was not declared in this scope
     surfaceCreateInfo.hwnd = glfwGetWin32Window(window);
                              ^~~~~~~~~~~~~~~~~~
../src/V-EZ.cpp:47:30: note: suggested alternative: ‘glfwGetX11Window’
     surfaceCreateInfo.hwnd = glfwGetWin32Window(window);
                              ^~~~~~~~~~~~~~~~~~
                              glfwGetX11Window
../src/V-EZ.cpp:48:14: error: ‘vezCreateSurface’ was not declared in this scope
     result = vezCreateSurface(instance, &surfaceCreateInfo, &surface);
              ^~~~~~~~~~~~~~~~
../src/V-EZ.cpp:48:14: note: suggested alternative: ‘vezCreateImage’
     result = vezCreateSurface(instance, &surfaceCreateInfo, &surface);
              ^~~~~~~~~~~~~~~~
              vezCreateImage
../src/V-EZ.cpp:74:26: error: expected ‘;’ before ‘createInfo’
     VezSurfaceCreateInfo createInfo = {};
                          ^~~~~~~~~~
../src/V-EZ.cpp:75:5: error: ‘createInfo’ was not declared in this scope
     createInfo.hinstance = GetModuleHandle(nullptr);
     ^~~~~~~~~~
../src/V-EZ.cpp:75:5: note: suggested alternative: ‘appInfo’
     createInfo.hinstance = GetModuleHandle(nullptr);
     ^~~~~~~~~~
     appInfo
../src/V-EZ.cpp: In function ‘int main(int, char**)’:
../src/V-EZ.cpp:102:10: error: ‘InitGLFW’ was not declared in this scope
     if (!InitGLFW())
          ^~~~~~~~
src/subdir.mk:18: recipe for target 'src/V-EZ.o' failed
make: *** [src/V-EZ.o] Error 1

Validation complain in vezCreateSwapchain with 1.1.82.1

validation error

Upgraded the validation layers from 1.1.70 to the latest version 1.1.81.1. Validation finally works, yay! But they complain about invalid usage flags for the swapchain images. In vez the swapchain image is created with:

 swapchainCreateInfo.imageUsage = VK_IMAGE_USAGE_TRANSFER_DST_BIT;

The thing is that the validation layers are creating VkImageViews when "vkGetSwapchainImagesKHR" is called, don't ask me why and it's invalid to create an VkImageView from an image with just that usage flag.
The relevant piece in the spec (For VkImageViewCreateInfo):

image must have been created with a usage value containing at least one of VK_IMAGE_USAGE_SAMPLED_BIT, VK_IMAGE_USAGE_STORAGE_BIT, VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT, VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT, or VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT

Any idea how to fix that? Should we report that to the validation guys? Or just add VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT to the usage flag :D

EDIT: It seems like there are more validation layer complains. It might be a good idea to try out the latest LunarG-SDK and fix all complains. :-) Thank you!

Provide an easier way to name and tag objects

First off, thanks for open-sourcing this library!

I would like to point out that it is currently borderline impossible to name objects created with VEZ. Both vkSetDebugUtilsObjectNameEXT and vkDebugMarkerSetObjectNameEXT need to be provided handles to actual Vk... objects. However, VEZ takes all the abstraction away, forcing users to write what looks like horrible hacks in order to achieve this:

#if _DEBUG
#include "Core/CommandBuffer.h"

namespace debug
{
    template <typename T>
    struct object_type_traits {
        constexpr static const VkObjectType object_type = VK_OBJECT_TYPE_UNKNOWN;
        constexpr static const VkDebugReportObjectTypeEXT object_type_ext = VK_DEBUG_REPORT_OBJECT_TYPE_UNKNOWN_EXT;
    };

#define VULKAN_TYPE_TRAIT(TYPE, ENUM, ENUM_EXT)                                       \
    template<> struct object_type_traits<TYPE> {                                      \
        constexpr static const VkObjectType object_type = ENUM;                       \
        constexpr static const VkDebugReportObjectTypeEXT object_type_ext = ENUM_EXT; \
    }

VULKAN_TYPE_TRAIT(VkCommandBuffer, VK_OBJECT_TYPE_COMMAND_BUFFER, VK_DEBUG_REPORT_OBJECT_TYPE_COMMAND_BUFFER_EXT);
// etc, you get the idea of this

#undef VULKAN_TYPE_TRAIT

    template <typename T>
    struct vez_traits {
        using vulkan_type = std::nullptr_t;
        using vez_ptr_type = std::nullptr_t;
    };

#define VEZ_TO_VULKAN(VEZ, VULKAN, VEZTYPE)         \
    template <> struct vez_traits<VEZ> {            \
        using vulkan_type = VULKAN;                 \
        using vez_ptr_type = VEZTYPE;               \
    }

    VEZ_TO_VULKAN(VezSwapchain, VkSwapchainKHR, vez::Swapchain);
    VEZ_TO_VULKAN(VezCommandBuffer, VkCommandBuffer, vez::CommandBuffer);
    // Again, etc.

#undef VEZ_TO_VULKAN
    // ... State initializers and function ptr loaders later, unrelated to current "issue"
}
template <typename T>
void GameWindow::SetName(const char* name, T object)
{
#if _DEBUG
    debug::createDebugCallback(_instance); // Initialize function pointers

    if (debug::vkSetDebugUtilsObjectNameEXT != nullptr)
    {
        VkDebugUtilsObjectNameInfoEXT nameInfo{};
        nameInfo.sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_NAME_INFO_EXT;
        nameInfo.pObjectName = name;
        nameInfo.objectHandle = reinterpret_cast<std::uint64_t>(object);

        if constexpr (!std::is_same<typename debug::vez_traits<T>::vulkan_type, std::nullptr_t>::value)
        {
            using vulkan_type = typename debug::vez_traits<T>::vulkan_type;
            static_assert(debug::object_type_traits<vulkan_type>::object_type != VK_OBJECT_TYPE_UNKNOWN, "Unable to set a name for the provided object.");

            nameInfo.objectType = debug::object_type_traits<vulkan_type>::object_type;

            // HERE!!
            auto vezObject = reinterpret_cast<typename debug::vez_traits<T>::vez_ptr_type*>(object);
            nameInfo.objectHandle = reinterpret_cast<std::uint64_t>(vezObject->GetHandle());
        }
        else
        {
            static_assert(debug::object_type_traits<T>::object_type != VK_OBJECT_TYPE_UNKNOWN, "Unable to set a name for the provided object.");
            nameInfo.objectType = debug::object_type_traits<T>::object_type;
        }

        debug::vkSetDebugUtilsObjectNameEXT(_device, &nameInfo);
    }
    else if (debug::vkDebugMarkerSetObjectNameEXT != nullptr)
    {
        VkDebugMarkerObjectNameInfoEXT nameInfo{};
        nameInfo.sType = VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_NAME_INFO_EXT;
        nameInfo.object = reinterpret_cast<std::uint64_t>(object);
        nameInfo.pObjectName = name;

        if constexpr (!std::is_same<typename debug::vez_traits<T>::vulkan_type, std::nullptr_t>::value)
        {
            using vulkan_type = typename debug::vez_traits<T>::vulkan_type;
            static_assert(debug::object_type_traits<vulkan_type>::object_type_ext != VK_DEBUG_REPORT_OBJECT_TYPE_UNKNOWN_EXT, "Unable to set a name for the provided object.");
            nameInfo.objectType = debug::object_type_traits<vulkan_type>::object_type_ext;

            // HERE!!
            auto vezObject = reinterpret_cast<typename debug::vez_traits<T>::vez_ptr_type*>(object);
            nameInfo.object = reinterpret_cast<std::uint64_t>(vezObject->GetHandle());
        }
        else
        {
            static_assert(debug::object_type_traits<T>::object_type_ext != VK_DEBUG_REPORT_OBJECT_TYPE_UNKNOWN_EXT, "Unable to set a name for the provided object.");

            nameInfo.objectType = debug::object_type_traits<T>::object_type_ext;
        }

        debug::vkDebugMarkerSetObjectNameEXT(_device, &nameInfo);
    }
    else
        LOG_RENDERING << "Unable to set name \"" << name << "\". The required extensions (either VK_EXT_debug_utils or VK_EXT_debug_marker) are missing on this system.";
#endif
}

The idea here is to be able to pass VezCommandBuffer as well as VkCommandBuffer to the above function, and have exactly the same behavior.

This "solution" looks "fine", until you realize you also need to include part of V-EZ's core headers (namely Core/CommandBuffer.h here), which isn't exactly a pretty option - but does work. It's also dependant on GetHandle not being suddenly renamed across the board.

Are there plans to provide better naming support, or is this left as-is ?

Thank you!

Error in StreamDecoder.cpp Line 1017

So i tried to debug my engine with render-doc and i recognized that render-doc reports my main-pass as an "depth-only pass". The reason for this is that i had the same output-name in two different shaders (vertex + fragment). Because of that VEZ has internally a VezPipelineResource struct with the stage 17 (Vertex+Fragment). This causes inadvertently in StreamDecoder.cpp Line 1017 to fail the if-statement:

if (resource.stages == VK_SHADER_STAGE_FRAGMENT_BIT && resource.resourceType == VEZ_PIPELINE_RESOURCE_TYPE_OUTPUT)
// Add output attachment index and more...

I'm not exactly sure how the VezPipelineResource struct is build, so it recognizes same outputs with the same name as equal even if two shaders are clearly distinct. I guess an easy fix would be to test:
resource.stages & VK_SHADER_STAGE_FRAGMENT_BIT

Specifying the format of shader resources

Currently, given layout (location = 2) in vec4 inColor;, the library generates a binding that expects the user to pass a float[4]. However, I'm using ImGui, which sends text color using packed colors as u8[4], where each byte is a color component.

This can be seen in PipelineCache.cpp:206:

                case VEZ_PIPELINE_RESOURCE_BASE_TYPE_FLOAT:
                    typeSize = sizeof(float);
                    if (input.vecSize == 1) attributeDescription.format = VK_FORMAT_R32_SFLOAT;
                    else if (input.vecSize == 2) attributeDescription.format = VK_FORMAT_R32G32_SFLOAT;
                    else if (input.vecSize == 3) attributeDescription.format = VK_FORMAT_R32G32B32_SFLOAT;
                    else if (input.vecSize == 4) attributeDescription.format = VK_FORMAT_R32G32B32A32_SFLOAT;
                    break;

as well as in the spirv reflection loader.

I understand that this library is aimed to helping users kickstart their Vulkan experience, but some flexibility here would be nice.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.