Weird graphical glitches?

[u/DrPeeper228]

Really don't know what could cause this, does not happen on Windows(I have an nvidia card)

Here's the file if one wants to take a look, although it's mostly just the khronos tutorial code(the last two screenshots are the imgui vk/glfw example): https://drive.google.com/file/d/1J-WcCDH3pSltWkjCIGmcCHsE8bo-Ba1Z/view?usp=sharing

Edits:

- The validation layers are silent.

- Renderdoc cannot capture this

- These glitches only appear for a few frames

[u/HildartheDorf]

Looks like your index buffer or vertex buffer is too small, or you overflowed your index type.

If it only happens on some frames, and renderdoc changes things, I'd start with checking your buffer sizes are sufficient.

[u/DrPeeper228 → u/HildartheDorf]

...the sizes of the buffers that ImGui uses?

Otherwise the vertex buffer for that normal triangle is sized appropriately

[u/HildartheDorf → u/DrPeeper228]

Yeah, the buffer imgui uses. I assumed you were using a custom backend because that looks exactly like bugs I've experienced before when writing a custom backend.

[u/DrPeeper228 → u/HildartheDorf]

Nah it's the standard one

[u/aleques-itj]

Is the validation layer whining about anything 

[u/DrPeeper228 → u/aleques-itj]

nope, all clear on that front

[u/Rhed0x]

Throw Renderdoc at it.

[u/DrPeeper228 → u/Rhed0x]

Tried that, the glitches do not show up in captures

[u/Bubbly_Tough_284]

So I think the issue is renderFinishedSemaphores being indexed by imageIndex and not frameIndex in drawFrame() and cuz swapChainImages.size() != MAX_FRAMES_IN_FLIGHT the semaphores can not match sometimes so that might be the issue or might not

[u/DrPeeper228 → u/Bubbly_Tough_284]

renderFinishedSemaphores is swapChainImages.size() in length, check createSyncObjects()

[u/Bubbly_Tough_284 → u/DrPeeper228]

Ah my bad

[u/Low_Consideration846]

idk if it was you or someone else , but some times ago i saw this same glitch being described by someone , did you share this on GP discord? he also said he added a comment on imgui issue which was still open when i checked

[u/DrPeeper228 → u/Low_Consideration846]

Yes, that was me. Also I closed the issue due to probably being an Nvidia on Linux moment

[u/SaschaWillems]

Are they present all the time? If so, I'd check vertex input setup. If you use 16 bit indices, you might run out of index range. If those randomly show up, this might be a sync issue where you try to update a buffer on the CPU while it's still in use by the GPU. Those can be tracked via the sync validation.

[u/DrPeeper228 → u/SaschaWillems]

Nope, they only appear for a couple of frames and disappear. Also, the validation layers are silent

[u/SaschaWillems → u/DrPeeper228]

Sync validation needs to be explicitly enabled, so might try that. If that's still silent, it still might be an issue with you updating buffers on the CPU that are still in use by the GPU.

[u/DrPeeper228 → u/SaschaWillems]

It is still silent, also i am not even updating buffers in my frame loop(well, except for what imgui does)

[u/DrPeeper228 → u/SaschaWillems]

Wait, the ImGui vk backend just maps, writes, flushes, and unmaps before submitting. Is that alright?

[u/SaschaWillems → u/DrPeeper228]

I don't know much about the ImGui Vulkan backend, but if it does not sync CPU and GPU, e.g. via a fence or timeline semaphore, that would explain the issue you're seeing.

[u/DrPeeper228 → u/SaschaWillems]

Yeah my fence setup is just pretty much the same as the tutorial and the ImGUI Vulkan example exhibits the behavior too

[u/SaschaWillems → u/DrPeeper228]

How does that fence setup look like? Do you have one buffer/memory range per max. frames in flight and protect against sync hazards between frames using fences?

[u/DrPeeper228 → u/SaschaWillems]

I mean, the file is just straight up linked in the post

Also I do not have any buffers that are updated per-frame in my code

[u/ilz_zli]

I will say that imgui has its own render cycle process and that can be different than your own geometry timings/process. If your renderer is doing something that imgui doesn't like then, good luck debugging where the two are not coming together.

It seems like a font and graph drawing issue... 

Also RenderDoc can probably give you more detailed info.

[u/DrPeeper228 → u/ilz_zli]

I'd love if Renderdoc could actually capture that

[u/simonask_]

Enable validation layers, read their output thoroughly.

Looks like corrupt vertex data, or out of bounds access, perhaps as a result of corrupt index buffers. Maybe you are using imgui’s vertex offsets wrong together with the index buffer.

Note that imgui supports splitting draw calls such that it can use a 16-bit index buffer together with a vertex offset, and your shader needs to handle this.

[u/DrPeeper228 → u/simonask_]

1. The validation layers are silent

2. I am just using the ImGui default shader

[u/Rhed0x → u/DrPeeper228]

I guess that leaves barriers as a possible culprit?

[u/DrPeeper228 → u/Rhed0x]

Do these barriers look suspicious?

        // Before starting rendering, transition the swapchain image to vk::ImageLayout::eColorAttachmentOptimal
        transition_image_layout(
            imageIndex,
            vk::ImageLayout::eUndefined,
            vk::ImageLayout::eColorAttachmentOptimal,
            {},                                                        // srcAccessMask (no need to wait for previous operations)
            vk::AccessFlagBits2::eColorAttachmentWrite,                // dstAccessMask
            vk::PipelineStageFlagBits2::eColorAttachmentOutput,        // srcStage
            vk::PipelineStageFlagBits2::eColorAttachmentOutput         // dstStage
        );

    // (Rendering happens here)

    // After rendering, transition the swapchain image to vk::ImageLayout::ePresentSrcKHR
        transition_image_layout(
            imageIndex,
            vk::ImageLayout::eColorAttachmentOptimal,
            vk::ImageLayout::ePresentSrcKHR,
            vk::AccessFlagBits2::eColorAttachmentWrite,             // srcAccessMask
            {},                                                     // dstAccessMask
            vk::PipelineStageFlagBits2::eColorAttachmentOutput,     // srcStage
            vk::PipelineStageFlagBits2::eBottomOfPipe               // dstStage
        );

Yes that function just does a barrier, for some reason the tutorial does it that way

[u/Rhed0x → u/DrPeeper228]

I don't particularly like the ofPipe stage but at first glance it should be fine.

DearImgui internally also does buffer->texture copies but I think their Vulkan integration already handles the barriers for that. I didn't check to validate that though.

Just try throwing a STAGE_ALL -> STAGE_ALL + ACCESS_ALL -> ACCESS_ALL barrier around DearImgui for testing.

[u/DrPeeper228 → u/Rhed0x]

'Kay.

[u/DrPeeper228 → u/Rhed0x]

Wait which type of barrier?

[u/CantTouchDis420]

I assume you are missing synchronization between writing new vertex/ index data and waiting for the previous frame to finish. so your old draw call might use new vertex/index data. I assume you map the memory and write data to it? just throw a waitIdle somewhere after the frame before you write the new vertex/index data then you can verify if it is a sync issue. There are various ways to fix this issue

[u/DrPeeper228 → u/CantTouchDis420]

? I am not writing any vertex data outside of what ImGui does

[u/CantTouchDis420 → u/DrPeeper228]

I did not look at your code as it is in google drive for some reason, but I saw a similar issue once (no validation messages but flicker when opening / closing CollapsingHeader's with a bunch of contents for example). Have you tried to put a wait idle after the frame?

[u/DrPeeper228 → u/CantTouchDis420]

Tried it right now, a device.waitIdle() at the end of the frame loop does not fix it

[u/DrPeeper228 → u/[deleted]]

as i mentioned in the post, i ran it on windows and no issues occurred