Cannot sample image in compute pipeline

[x1244]

I want to implement image sampling and processing in a compute shader. Regardless of which image I read, sampling in the compute shader always returns a black image. Can you help me analyze where the problem might be?

Important notes:

The image being read is correct and without issues. I have verified its raw data in vsg::Data.

If I don't use a sampler and use storage instead, I can correctly access and read the image information.

Below is the application code: main.cpp

#include <vsg/all.h>
#ifdef vsgXchange_FOUND
#    include <vsgXchange/all.h>
#endif
#include <iostream>
#include <string>
using namespace std;

const int local_size_x = 1;
const int local_size_y = 1;

int main(int argc, char** argv)
{
    vsg::CommandLine arguments(&argc, argv);

    const int width = 256;
    const int height = 256;
    int workgroup_x = width/local_size_x;
    int workgroup_y = height/local_size_y;

    auto options = vsg::Options::create();
    options->sharedObjects = vsg::SharedObjects::create();
    options->fileCache = vsg::getEnv("VSG_FILE_CACHE");
    options->paths = vsg::getEnvPaths("VSG_FILE_PATH");
#ifdef vsgXchange_FOUND
    // add vsgXchange's support for reading and writing 3rd party file formats
    options->add(vsgXchange::all::create());
    auto glslreader = vsg::glsl::create();
    options->add(glslreader);
#endif

    vsg::Paths searchPaths = vsg::getEnvPaths("VSG_FILE_PATH");
    auto computeStage = read_cast<vsg::ShaderStage>("union.comp", options);

    computeStage->specializationConstants = vsg::ShaderStage::SpecializationConstants{
        {0, vsg::intValue::create(local_size_x)},    //local_size_x
        {1, vsg::intValue::create(local_size_y)}     //local_size_y
    };   

    // get the physical device that supports the required compute queue
    auto instance = vsg::Instance::create(vsg::Names{}, vsg::Names{});
    auto [physicalDevice, computeQueueFamily] = instance->getPhysicalDeviceAndQueueFamily(VK_QUEUE_COMPUTE_BIT);
    if (!physicalDevice || computeQueueFamily < 0)
    {
        std::cout << "No VkPhysicalDevice available that supports compute." << std::endl;
        return 1;
    }

    // create the logical device with specified queue, layers and extensions
    vsg::QueueSettings queueSettings{vsg::QueueSetting{computeQueueFamily, {1.0, 0.0}}};
    auto device = vsg::Device::create(physicalDevice, queueSettings, vsg::Names{}, vsg::Names{});

    // get the queue for the compute commands
    auto computeQueue = device->getQueue(computeQueueFamily);

    // allocate output storage buffer
    VkDeviceSize bufferSize = sizeof(vsg::vec4) * width * height;

    vsg::ref_ptr<vsg::Buffer> buffer = vsg::createBufferAndMemory(device, bufferSize, VK_BUFFER_USAGE_STORAGE_BUFFER_BIT, VK_SHARING_MODE_EXCLUSIVE, VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | VK_MEMORY_PROPERTY_HOST_COHERENT_BIT);
    // set up DescriptorSetLayout, DescriptorSet and BindDescriptorSets
    vsg::DescriptorSetLayoutBindings descriptorBindings{
        {0, VK_DESCRIPTOR_TYPE_STORAGE_BUFFER, 1, VK_SHADER_STAGE_COMPUTE_BIT, nullptr},
        {1, VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER, 1, VK_SHADER_STAGE_COMPUTE_BIT, nullptr}
    };

    auto descriptorSetLayout = vsg::DescriptorSetLayout::create(descriptorBindings);
    string layer("layer.jpg");
    auto imm = vsg::read_cast<vsg::Data>(layer, options);

    auto storge = vsg::DescriptorBuffer::create(
        vsg::BufferInfoList{vsg::BufferInfo::create(buffer, 0, bufferSize)}, 
        0, 0, VK_DESCRIPTOR_TYPE_STORAGE_BUFFER);
    auto texture = vsg::DescriptorImage::create(vsg::Sampler::create(), 
        imm, 1, 0, VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER);

    vsg::Descriptors descriptors{storge, texture};
    auto descriptorSet = vsg::DescriptorSet::create(descriptorSetLayout, descriptors);
    auto pipelineLayout = vsg::PipelineLayout::create(vsg::DescriptorSetLayouts{descriptorSetLayout}, vsg::PushConstantRanges{});
    auto bindDescriptorSet = vsg::BindDescriptorSet::create(VK_PIPELINE_BIND_POINT_COMPUTE, pipelineLayout, descriptorSet);

    // set up the compute pipeline
    auto pipeline = vsg::ComputePipeline::create(pipelineLayout, computeStage);
    auto bindPipeline = vsg::BindComputePipeline::create(pipeline);

    // assign to a CommandGraph that binds the Pipeline and DescriptorSets and calls Dispatch
    auto commandGraph = vsg::Commands::create();
    commandGraph->addChild(bindPipeline);
    commandGraph->addChild(bindDescriptorSet);
    commandGraph->addChild(vsg::Dispatch::create(workgroup_x, workgroup_y, 1));

    // compile the Vulkan objects
    auto compileTraversal = vsg::CompileTraversal::create();
    compileTraversal->queueFlags = VK_QUEUE_COMPUTE_BIT;
    compileTraversal->add(device);
    auto context = compileTraversal->contexts.front();

    commandGraph->accept(*compileTraversal);

    // setup fence
    auto fence = vsg::Fence::create(device);

    // submit commands
    vsg::submitCommandsToQueue(context->commandPool, fence, 100000000000, computeQueue, [&](vsg::CommandBuffer& commandBuffer) {
        commandGraph->record(commandBuffer);
    });

    auto bufferMemory = buffer->getDeviceMemory(device->deviceID);

    const string outputFilename("output.jpg");
    auto image = vsg::MappedData<vsg::vec4Array2D>::create(bufferMemory, 0, 0, vsg::Data::Properties{VK_FORMAT_R32G32B32A32_SFLOAT}, width, height); // deviceMemory, offset, flags an d dimensions

    // create an unsigned byte version of the image and then copy the texels across converting colours from float to unsigned byte.
    auto dest = vsg::ubvec4Array2D::create(width, height, vsg::Data::Properties{VK_FORMAT_R8G8B8A8_UNORM});

    using component_type = uint8_t;
    auto c_itr = dest->begin();
    for (auto& colour : *image)
    {
        (c_itr++)->set(static_cast<component_type>(colour.r * 255.0), static_cast<component_type>(colour.g * 255.0), static_cast<component_type>(colour.b * 255.0), static_cast<component_type>(colour.a * 255.0));
    }

    vsg::write(dest, outputFilename, options);
    cout <<"wirte to " <<outputFilename <<endl;

    // clean up done automatically thanks to ref_ptr<>
    return 0;
}

Below is the compute shader code: union.comp

#version 450
#extension GL_EXT_shader_8bit_storage : require
#extension GL_EXT_shader_explicit_arithmetic_types : require
#extension GL_ARB_separate_shader_objects : enable

layout (constant_id = 0) const uint size_x = 8;
layout (constant_id = 1) const uint size_y = 8;

struct Pixel
{
    vec4 value;
};

layout(local_size_x_id = 0, local_size_y_id = 1) in;

layout(binding = 0, std430) buffer Base
{
    Pixel imageData[];
} base;

layout(binding = 1) uniform sampler2D input_tex;

void main()
{
    const uint width = 256;
    const uint height = 256;
    vec2 coord = vec2(float(gl_GlobalInvocationID.x)/width, float(gl_GlobalInvocationID.y)/height);
    uint ix = (width * gl_GlobalInvocationID.y) + gl_GlobalInvocationID.x;
    vec4 backgroud = base.imageData[ix].value;
    vec4 color;
    if(coord.x < 0.5 && coord.y < 0.5) {
        color = vec4(1.0, 0.0, 0.0, 1.0);
    }
    else {
        color = texture(input_tex, coord);
    }
    base.imageData[ix].value = color;
}

I got the image

[AnyOldName3]

Have you tried running this with validation layers enabled and, if that doesn't reveal any problems, with RenderDoc? They should usually be the first things you try if a Vulkan-based app isn't doing what you expect.

[x1244]

When I add validation layers "VK_LAYER_KHRONOS_validation", I get this message

VUID-vkCmdDraw-None-09600(ERROR / SPEC): msgNum: 1180184443 - Validation Error: [ VUID-vkCmdDraw-None-09600 ] Object 0: handle = 0x2ae88a7c080, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xee647e0000000009, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x46582f7b | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x2ae88a7c080[] expects VkImage 0xee647e0000000009[] (subresource: aspectMask = VK_IMAGE_ASPECT_COLOR_BIT, mipLevel = 0, arrayLayer = 0) to be in layout VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
The Vulkan spec states: If a descriptor with type equal to any of VK_DESCRIPTOR_TYPE_SAMPLE_WEIGHT_IMAGE_QCOM, VK_DESCRIPTOR_TYPE_BLOCK_MATCH_IMAGE_QCOM, VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE, VK_DESCRIPTOR_TYPE_STORAGE_IMAGE, or VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT is accessed as a result of this command, the image subresource identified by that descriptor must be in the image layout identified when the descriptor was written (https://vulkan.lunarg.com/doc/view/1.4.304.0/windows/1.4-extensions/vkspec.html#VUID-vkCmdDraw-None-09600)
Objects: 2
[0] 0x2ae88a7c080, type: 6, name: NULL
[1] 0xee647e0000000009, type: 10, name: NULL

[x1244]

I tried replace

    auto texture = vsg::DescriptorImage::create(vsg::Sampler::create(), 
        imm, 1, 0, VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER);

to

    auto inputImage = vsg::Image::create(imm);
    auto imageView = vsg::ImageView::create(inputImage, VK_IMAGE_ASPECT_COLOR_BIT);
    auto sampler = vsg::Sampler::create();
    auto inputImageInfo = vsg::ImageInfo::create(sampler, imageView, VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL);
    auto texture = vsg::DescriptorImage::create(
        inputImageInfo, 1, 0, VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER);

still received the same validation error message.

[x1244]

I took a look at the code. In TransferTask::_transferImageInfo(), the method transferImageData() is called at the end. However, inside transferImageData(), when vkCmdPipelineBarrier() is called, the dstAccessMask is set to VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT. This causes the image to not have the correct VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL or VK_IMAGE_LAYOUT_GENERAL layout when accessed in the compute shader.

Is my understanding correct?

If so, how should I set up the image and sampler correctly so that I can sample from the image within the compute shader?

[x1244]

I applied a PipelineBarrier to change the image layout, and there are no more validation layer warnings, but I still cannot sample from the image in compute shader.

auto inputImage = vsg::Image::create(imm);
inputImage->usage = VK_IMAGE_USAGE_SAMPLED_BIT;
auto imageView = vsg::ImageView::create(inputImage, VK_IMAGE_ASPECT_COLOR_BIT);
auto sampler = vsg::Sampler::create();
auto inputImageInfo = vsg::ImageInfo::create(sampler, imageView, VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL);
auto texture = vsg::DescriptorImage::create(
    inputImageInfo, 1, 0, VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER);

...

auto imageMemoryBarrier = vsg::ImageMemoryBarrier::create(
    0, // srcAccessMask
    VK_ACCESS_SHADER_READ_BIT, // dstAccessMask
    VK_IMAGE_LAYOUT_UNDEFINED, // oldLayout
    VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL, // newLayout
    VK_QUEUE_FAMILY_IGNORED, // srcQueueFamilyIndex
    VK_QUEUE_FAMILY_IGNORED, // dstQueueFamilyIndex
    inputImage, // image
    VkImageSubresourceRange{
        VK_IMAGE_ASPECT_COLOR_BIT, // aspectMask
        0, // baseMipLevel
        1, // levelCount
        0, // baseArrayLayer
        1  // layerCount
    }
);

auto pipelineBarrier = vsg::PipelineBarrier::create(
    VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT,         // srcStageMask
    VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT,      // dstStageMask
    0,                                         // dependencyFlags
    imageMemoryBarrier                      // imageMemoryBarriers
);

...

commandGraph->addChild(pipelineBarrier);

I tried using RenderDoc to capture the compute pipeline, but I haven't yet figured out how to use this tool effectively for compute pipelines.

[robertosfield]

I have been away so coming to this discussion a bit late. The PipelineBarrier setting shouldn't affect the final state of the associate image but the timing of that assignment state, so I guess it's happening after the compute being run.

The compile traversal is usually treated as entirely dedicated step that is completed fully before the next operations happen. We may need to look at the implementation of vsg::transferImageData() so that it can take the stage that the transfer needs to be complete by and default it to the top of the pipe. Top of the pipe would reduce the parallelism but if you are reading the image earlier than VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT then this really should be respected.

I am catching up with a range of different tasks so I'll not be able to just focus on this item right away. It would be worth creating an Issue for it, ideally with an example program that illustrates how to recreate the problem. I see such an example embedded in the example above but this will require me to create source files, cmake files, build and hope that I've done it as intended so I'm reproducing the problem. If this was the only task I had to look into doing all of this would be fine, but I have dozens of items to look at so assistance would be appreciated.

[x1244]

Yes, you are absolutely right. It can now be almost confirmed that the transferImageData() method is called within TransferTask::_transferImageInfo(), and in this transferImageData() method, the final vkCmdPipelineBarrier() call transitions the image to the targetImageLayout, which is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL. In this transition, the dstStageMask is specified as VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT.

I created an example that combines VSG and Vulkan methods. When the layout transition is done with dstStageMask = VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT, I achieve the desired result.

However, I'm not very familiar with CMake and haven't managed to write the CMakeLists.txt file yet. I'll see if I can manage to create a CMake example later for project testing.

I have an idea: add a dstStageMask attribute to the ImageView or Image, and then use this value in transferImageData() to replace the fixed VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT. This way, we wouldn't need to change the transferImageData() interface contract, and it would still achieve the usage purpose.

[x1244]

To add to that, for images, we don't only use them in fragment shaders and compute shaders; they could also be used in vertex shaders or elsewhere.

[robertosfield]

@x1244 I have started looking into this topic, first step for me has been to recreate the test program, so I've created a CMakeLists.txt based on the one MyFirstVsgApplication/CMakeLists.txt and got your main.cpp compiling, added union.comp. I had to add a vsg before the read_cast<> to get it to compile. Did you compile the code before posting it? If so what compiler are you using?

When I run I get a crash in the submitCommandsToQueue(..) :

Thread 1 "computetest" received signal SIGSEGV, Segmentation fault.
0x000055555579e6ad in vsg::State::dirtyStateStacks (this=0x0) at /home/robert/dev/VulkanSceneGraph/include/vsg/vk/State.h:303
303                 dirty = true;
(gdb) where
#0  0x000055555579e6ad in vsg::State::dirtyStateStacks (this=0x0) at /home/robert/dev/VulkanSceneGraph/include/vsg/vk/State.h:303
#1  0x00005555557b75b9 in vsg::CommandBuffer::setCurrentPipelineLayout (this=0x7fffedd5d808, pipelineLayout=0x7fffedd5cf30) at /home/robert/dev/VulkanSceneGraph/src/vsg/vk/CommandBuffer.cpp:62
#2  0x00005555557397e6 in vsg::BindComputePipeline::record (this=0x55555738d4e0, commandBuffer=...) at /home/robert/dev/VulkanSceneGraph/src/vsg/state/ComputePipeline.cpp:161
#3  0x0000555555727176 in vsg::Commands::record (this=0x55555738d510, commandBuffer=...) at /home/robert/dev/VulkanSceneGraph/src/vsg/commands/Commands.cpp:64
#4  0x00005555556fb942 in operator() (__closure=0x7fffffffcc88, commandBuffer=...) at /home/robert/dev/temp/computetest/src/main.cpp:104
#5  0x00005555556fd78d in vsg::submitCommandsToQueue<main(int, char**)::<lambda(vsg::CommandBuffer&)> >(vsg::CommandPool *, vsg::Fence *, uint64_t, vsg::Queue *, struct {...}) (commandPool=0x7fffedd5d4f8, fence=0x7fffedd5d7a8, timeout=100000000000, 
    queue=0x7fffedd5c7d0, function=...) at /home/robert/install/include/vsg/vk/SubmitCommands.h:38
#6  0x00005555556fc980 in main (argc=1, argv=0x7fffffffd4d8) at /home/robert/dev/temp/computetest/src/main.cpp:103
(gdb) quit

Which version of the VSG are you compiling against?

You code also reads a "layer.jpg" file but you didn't supply this file. I can find a image to substitute, but would be helpful to use the same file so I can reproduce your results exactly rather than having to guess at what might be going on, on your system.

[robertosfield]

As an initial set in resolving this issue I have added a dstStageMask variable into the vsg::transferImageData(...) function with it's default still set to VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT for now: f0d1853

The stage that the image is used would typically be governed by the DescriptorSetLayoutBinding::stageFlags but this isn't passed in via the ImageInfo/ImageView. Perhaps we could cache all the stageFlags associated with an vkImage so when data is transferred to it it can handle all the possible variations.

A simpler approach might be just to set the default dstStageMask value to VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT as this should ensure that the copies are complete before any possible usage, however, this could reduce the level of parallelism that can be achieved.

[x1244]

The compiler I'm using is VS2022, and it compiles and runs successfully on my end. Below are some compilation parameters:

"C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.38.33130\\bin\\HostX64\\x64\\cl.exe" -c -nologo -MD -std:c++20 -Ic:\dev\vs2022\include -Ic:\VulkanSDK\1.4.304.0\Include -DvsgXchange_FOUND /EHsc /utf-8 -Fobuild\.objs\main\windows\x64\release\src\main.cpp.obj src\main.cpp

and

"C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.38.33130\\bin\\HostX64\\x64\\link.exe" -nologo -dynamicbase -nxcompat -machine:x64 -libpath:c:\dev\vs2022\lib -libpath:c:\VulkanSDK\1.4.304.0\Lib libcurl_imp.lib gdal.lib freetype.lib libpng16.lib libbz2.lib zlib.lib osg2vsg.lib osg.lib osgDB.lib OpenThreads.lib osgUtil.lib vsgXchange.lib assimp-vc143-mt.lib vulkan-1.lib glslang.lib vsg.lib OSDependent.lib GenericCodeGen.lib glslang-default-resource-limits.lib MachineIndependent.lib SPIRV.lib SPIRV-Tools.lib SPIRV-Tools-opt.lib SPVRemapper.lib user32.lib -out:build\windows\x64\release\main.exe build\.objs\main\windows\x64\release\src\main.cpp.obj

Additionally, below is the test image I used.

Also, in the main.cpp file, read_cast<vsg::ShaderStage> indeed does not have the vsg:: prefix, but it still compiles successfully on my end.

My current VSG commit is 35acf0e, which should correspond to version v1.1.9.

I'm currently trying out the commit f0d1853.

[x1244]

sorry the vsg version maybe v1.1.11.

[x1244]

Unfortunately, when I tried commit 6bee434, which is the next commit after f0d1853, I also encountered a crash. However, the vsgviewer from this commit runs normally.

[robertosfield]

Well I guess it's good we both see the same behavior...

The VSG usage in your testbed is unusual, as is the vsgcompute example for that matter, so likely which others have tripped up on a crash in this situation. Looking at the stack trace it looks like changes in VSG to help improve handling of inheritance of descriptor sets between pipeline layouts relied up a valid vsg::State being assigned but the usage case you have isn't providing this.

Both the crash and pipeline barrier stage mask used during transfer data will need fixing.

[x1244]

I've discovered that when comparing these two versions, not only was transferImageData() moved from state/ImageView.cpp to app/TransferTask.cpp, but the Data class also underwent significant changes. Specifically, Data::Properties::maxNumMipmaps was changed to Data::Properties::mipLevels, and the definition of MipmapOffsets was removed, along with many other modifications. These changes have made the transferImageData() function incompatible between the two versions. It's possible that these changes caused issues during image transfer from CPU to GPU in the compute pipeline, leading to the program crash.

The scope of changes is so extensive that I'm currently unsure where to begin investigating.

Additionally, due to the changes in the definition and interface of the Data class, both the osg2vsg and vsgXchange libraries now require updates to replace Data::Properties::maxNumMipmaps with Data::Properties::mipLevels.

Thank you for your work.

[robertosfield]

The change to use Data::Properties::mipLevels has been applied to vsgXchange, osg2vsg and vsgExample, but you'll need to pull master of each to get these changes.

I will try to figure out how to resolve the crash.

[robertosfield]

I have tracked down the cause of the crash in vsg::submitCommandsToQueue(..) usage, this regression will likely have happened when lazy state updating and tracking was introduced, adding a requirement for a vsg::State to be assigned to an active CommandBuffer.

I have checked to VSG master, with commit 34c36bd, the addition of set up of the now required vsg::State to vsg::submitCommandsToQueue(..) function and added a doxygen comment to specify that this function has been officially deprecated. This convenience function was written in the very early days of the VSG project in order to help implement features that weren't yet fully supported yet.

Fast forward 5 years and vsg::submitCommandsToQueue(..) function really isn't a good choice, far better to integrate compute etc. usage as part of the scene graph and the viewer. I need to rewrite the vsgcompute example to avoid others copying this old style usage.

With the above commit the test program now runs and creates output.jpg that looks like:

[robertosfield]

I have had a bash at resolve the issues with this test example, integrating support for -d and -a options for enabling Vulkan Validation Layer and the API Layers and but haven't got to the bottom of why the texture read isn't working yet.

$ bin/computetest -d
UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x623aa7d55620, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xee647e0000000009, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x623aa7d55620[] expects VkImage 0xee647e0000000009[] (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
    Objects: 2
        [0] 0x623aa7d55620, type: 6, name: NULL
        [1] 0xee647e0000000009, type: 10, name: NULL
wirte to output.jpg

The odd thing is the image handle that it has an issue with doesn't related to one that has been created earlier - you see the full output when using -a.

My changes to get things compiling and running on Linux are:

main.cpp
CMakeLists.txt

I need to get on with other tasks so I'll live it to others to investigate further.

[x1244]

YES. Updated to 34c36bd, and now the program runs normally without crashing. Using the -d parameter, I obtained the same results as you.

> ./main.exe -d
VUID-vkCmdDraw-None-09600(ERROR / SPEC): msgNum: 1180184443 - Validation Error: [ VUID-vkCmdDraw-None-09600 ] Object 0: handle = 0x2e598458b90, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xee647e0000000009, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x46582f7b | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x2e598458b90[] expects VkImage 0xee647e0000000009[] (subresource: aspectMask = VK_IMAGE_ASPECT_COLOR_BIT, mipLevel = 0, arrayLayer = 0) to be in layout VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
The Vulkan spec states: If a descriptor with type equal to any of VK_DESCRIPTOR_TYPE_SAMPLE_WEIGHT_IMAGE_QCOM, VK_DESCRIPTOR_TYPE_BLOCK_MATCH_IMAGE_QCOM, VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE, VK_DESCRIPTOR_TYPE_STORAGE_IMAGE, or VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT is accessed as a result of this command, the image subresource identified by that descriptor must be in the image layout identified when the descriptor was written (https://vulkan.lunarg.com/doc/view/1.4.304.0/windows/1.4-extensions/vkspec.html#VUID-vkCmdDraw-None-09600)
    Objects: 2
        [0] 0x2e598458b90, type: 6, name: NULL
        [1] 0xee647e0000000009, type: 10, name: NULL
wirte to output.jpg

Additionally, vsgXchange has been updated and is working properly. For osg2vsg, you need to use the mipmap_refinement branch, as it hasn't been merged into the main branch yet.

I have implemented image flipping - not using transferImageData(), but by writing a separate process. I'm including it now. Since I'm not yet very comfortable with CMake, you might need to make some minor adjustments to the CMakeLists.txt if it's not correct.

project.zip

[x1244]

Now, I get the picture with the new union.compu shader, where change color = texture(input_tex, coord); to color = texture(input_tex, 1.0 - coord);

union.zip

[robertosfield]

I am away from my dev system so can't check progress, but good to see you are now able to read and modify the image.

W.r.t osg2vsg updates, thanks for spotting this, I have merged the mipmap_refinements branch with master.

[x1244]

The reason why using vsg::submitCommandsToQueue() does not transfer images from CPU to GPU in the current pure compute pipeline is that, since no Viewer-related objects are created, there is no information related to RecordAndSubmitTasks, and thus the TransferTask is not started. As a result, no image transfer operations are observed. Setting the debug level to LOGGER_DEBUG reveals that there is absolutely no output related to TransferTask::_transferData.

debug: vsgXchange::init()
debug: ASSIMP_VERSION_MAJOR 5
debug: ASSIMP_VERSION_MINOR 4
debug: ASSIMP_VERSION_PATCH 1
debug: DeviceMemory::DeviceMemory() added to s_DeviceMemoryList, s_DeviceMemoryList.size() = 1
debug: Context::Context() 00000258AB91BBE0
debug: Context::Context() creating new deviceMemoryBufferPools = ref_ptr<vsg::MemoryBufferPools>(vsg::MemoryBufferPools 00000258AB91BE40)
debug: Context::Context() creating new stagingMemoryBufferPools = ref_ptr<vsg::MemoryBufferPools>(vsg::MemoryBufferPools 00000258AB91BF18)
debug: Context::Context() creating new descriptorPools = ref_ptr<vsg::DescriptorPools>(vsg::DescriptorPools 00000258AB91BFF0)
debug: ShaderCompiler::compile() combinedDefines = {}
debug: Successful compile
   1: #version 450
   2: #extension GL_EXT_shader_8bit_storage : require
   3: #extension GL_EXT_shader_explicit_arithmetic_types : require
   4: #extension GL_ARB_separate_shader_objects : enable
   5:
   6: layout (constant_id = 0) const uint size_x = 8;
   7: layout (constant_id = 1) const uint size_y = 8;
   8:
   9: struct Pixel
  10: {
  11:     vec4 value;
  12: };
  13:
  14: layout(local_size_x_id = 0, local_size_y_id = 1) in;
  15:
  16: layout(binding = 0, std430) buffer Base
  17: {
  18:     Pixel imageData[];
  19: } base;
  20:
  21: layout(binding = 1) uniform sampler2D input_tex;
  22:
  23: void main()
  24: {
  25:     const uint width = 256;
  26:     const uint height = 256;
  27:     vec2 coord = vec2(float(gl_GlobalInvocationID.x)/width, float(gl_GlobalInvocationID.y)/height);
  28:     uint ix = (width * gl_GlobalInvocationID.y) + gl_GlobalInvocationID.x;
  29:     vec4 backgroud = base.imageData[ix].value;
  30:     vec4 color;
  31:     if(coord.x < 0.5 && coord.y < 0.5) {
  32:         color = vec4(1.0, 0.0, 0.0, 1.0);
  33:     }
  34:     else {
  35:         color = texture(input_tex, 1.0 - coord);
  36:     }
  37:     base.imageData[ix].value = color;
  38: }


debug: DeviceMemory::DeviceMemory() added to s_DeviceMemoryList, s_DeviceMemoryList.size() = 2
debug: DeviceMemory::DeviceMemory() added to s_DeviceMemoryList, s_DeviceMemoryList.size() = 3
debug: DescriptorPool::DescriptorPool() 00000258AB91C558, maxSets = 1 {
debug:    { 7, 1 }
debug:    { 1, 1 }
debug: }
debug: DescriptorPool::allocateDescriptorSet(..) allocated new ref_ptr<vsg::DescriptorSet::Implementation>(vsg::DescriptorSet::Implementation 00000258AB91C628)
wirte to output.jpg
debug: start of Buffer::~Buffer() 00000258AB91C388
debug: end of Buffer::~Buffer() 00000258AB91C388
debug: DeviceMemory::~DeviceMemory() removed from s_DeviceMemoryList, s_DeviceMemoryList.size() = 2
debug: DeviceMemory::~DeviceMemory() removed from s_DeviceMemoryList, s_DeviceMemoryList.size() = 1
debug: start of Buffer::~Buffer() 00000258AB91B460
debug: end of Buffer::~Buffer() 00000258AB91B460
debug: DeviceMemory::~DeviceMemory() removed from s_DeviceMemoryList, s_DeviceMemoryList.size() = 0

Even if a TransferData object is forcibly created in the context, only the compilation of related resources is observed, with no recorded execution of the transfer operation.

    auto compileTraversal = vsg::CompileTraversal::create();
    compileTraversal->queueFlags = VK_QUEUE_COMPUTE_BIT;
    compileTraversal->add(device);
    auto context = compileTraversal->contexts.front();
    context->transferTask = vsg::TransferTask::create(device);

The corresponding output is as follows:

debug: vsgXchange::init()
debug: ASSIMP_VERSION_MAJOR 5
debug: ASSIMP_VERSION_MINOR 4
debug: ASSIMP_VERSION_PATCH 1
debug: DeviceMemory::DeviceMemory() added to s_DeviceMemoryList, s_DeviceMemoryList.size() = 1
debug: Context::Context() 00000258AB91BBE0
debug: Context::Context() creating new deviceMemoryBufferPools = ref_ptr<vsg::MemoryBufferPools>(vsg::MemoryBufferPools 00000258AB91BE40)
debug: Context::Context() creating new stagingMemoryBufferPools = ref_ptr<vsg::MemoryBufferPools>(vsg::MemoryBufferPools 00000258AB91BF18)
debug: Context::Context() creating new descriptorPools = ref_ptr<vsg::DescriptorPools>(vsg::DescriptorPools 00000258AB91BFF0)
debug: ShaderCompiler::compile() combinedDefines = {}
debug: Successful compile
   1: #version 450
   2: #extension GL_EXT_shader_8bit_storage : require
   3: #extension GL_EXT_shader_explicit_arithmetic_types : require
   4: #extension GL_ARB_separate_shader_objects : enable
   5:
   6: layout (constant_id = 0) const uint size_x = 8;
   7: layout (constant_id = 1) const uint size_y = 8;
   8:
   9: struct Pixel
  10: {
  11:     vec4 value;
  12: };
  13:
  14: layout(local_size_x_id = 0, local_size_y_id = 1) in;
  15:
  16: layout(binding = 0, std430) buffer Base
  17: {
  18:     Pixel imageData[];
  19: } base;
  20:
  21: layout(binding = 1) uniform sampler2D input_tex;
  22:
  23: void main()
  24: {
  25:     const uint width = 256;
  26:     const uint height = 256;
  27:     vec2 coord = vec2(float(gl_GlobalInvocationID.x)/width, float(gl_GlobalInvocationID.y)/height);
  28:     uint ix = (width * gl_GlobalInvocationID.y) + gl_GlobalInvocationID.x;
  29:     vec4 backgroud = base.imageData[ix].value;
  30:     vec4 color;
  31:     if(coord.x < 0.5 && coord.y < 0.5) {
  32:         color = vec4(1.0, 0.0, 0.0, 1.0);
  33:     }
  34:     else {
  35:         color = texture(input_tex, 1.0 - coord);
  36:     }
  37:     base.imageData[ix].value = color;
  38: }


debug: DeviceMemory::DeviceMemory() added to s_DeviceMemoryList, s_DeviceMemoryList.size() = 2
debug: DeviceMemory::DeviceMemory() added to s_DeviceMemoryList, s_DeviceMemoryList.size() = 3
debug: DescriptorPool::DescriptorPool() 00000258AB91C558, maxSets = 1 {
debug:    { 7, 1 }
debug:    { 1, 1 }
debug: }
debug: DescriptorPool::allocateDescriptorSet(..) allocated new ref_ptr<vsg::DescriptorSet::Implementation>(vsg::DescriptorSet::Implementation 00000258AB91C628)
wirte to output.jpg
debug: start of Buffer::~Buffer() 00000258AB91C388
debug: end of Buffer::~Buffer() 00000258AB91C388
debug: DeviceMemory::~DeviceMemory() removed from s_DeviceMemoryList, s_DeviceMemoryList.size() = 2
debug: DeviceMemory::~DeviceMemory() removed from s_DeviceMemoryList, s_DeviceMemoryList.size() = 1
debug: start of Buffer::~Buffer() 00000258AB91B460
debug: end of Buffer::~Buffer() 00000258AB91B460
debug: DeviceMemory::~DeviceMemory() removed from s_DeviceMemoryList, s_DeviceMemoryList.size() = 0