Corrupted picture with software renderers

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Post Reply
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Corrupted picture with software renderers

Post by _mental_ »

When Vulkan is enabled the final picture with classic and poly software renderers is rather broken.
When Vulkan is enabled software renderers may produce a corrupted picture depending on the current resolution and requirement for buffer alignment.
Screenshot_Doom_20190503_124513.png
I suspect it's just one spot where handling of 8-bit image format is missing. Although, I was unable to find it yet.
Last edited by _mental_ on Tue May 07, 2019 7:15 am, edited 1 time in total.
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: Broken picture with 8-bit software renderers

Post by dpJudas »

Hmm, I am not seeing this on my computer.

However I noticed that vk_debug 1 gives some errors when using software rendering. Those errors indicate that maybe it could create corrupted output on different hardware than my own.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Broken picture with 8-bit software renderers

Post by _mental_ »

With validation layers enabled software renderer reports the following errors after entering a level. It's on macOS with integrated Intel graphics.

Code: Select all

[vulkan error] You cannot start a render pass using attachment 0 where the render pass initial layout is VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL and the previous known layout of the attachment is VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL. The layouts must match, or the render pass initial layout for the attachment must be VK_IMAGE_LAYOUT_UNDEFINED

[vulkan error] vkCmdPipelineBarrier(): Barriers cannot be set during subpass 0 of renderPass VkRenderPassSetup.RenderPass[VkRenderPassSetup.RenderPass] with no self-dependency specified. The Vulkan spec states: If vkCmdPipelineBarrier is called within a render pass instance, the render pass must have been created with at least one VkSubpassDependency instance in VkRenderPassCreateInfo::pDependencies that expresses a dependency from the current subpass to itself, and for which srcStageMask contains a subset of the bit values in VkSubpassDependency::srcStageMask, dstStageMask contains a subset of the bit values in VkSubpassDependency::dstStageMask, dependencyFlags is equal to VkSubpassDependency::dependencyFlags, srcAccessMask member of each element of pMemoryBarriers and pImageMemoryBarriers contains a subset of the bit values in VkSubpassDependency::srcAccessMask, and dstAccessMask member of each element of pMemoryBarriers and pImageMemoryBarriers contains a subset of the bit values in VkSubpassDependency::dstAccessMask (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkCmdPipelineBarrier-pDependencies-02285)

[vulkan error] For image 0xa7[VkRenderBuffers.PipelineImage] you cannot transition the layout of aspect=1 level=0 layer=0 from VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL. The Vulkan spec states: oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of the image subresources affected by the barrier (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01197)

[vulkan error] For image 0xa7[VkRenderBuffers.PipelineImage] you cannot transition the layout of aspect=1 level=0 layer=0 from VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL. The Vulkan spec states: oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of the image subresources affected by the barrier (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01197)

[vulkan error] Submitted command buffer expects image 0xa7[VkRenderBuffers.PipelineImage]  (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL.
Also, this is reported regardless of renderer selection before entering a level.

Code: Select all

[vulkan error] vkGetQueryPoolResults: parameter dataSize must be greater than 0. The Vulkan spec states: dataSize must be greater than 0 (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkGetQueryPoolResults-dataSize-arraylength)
Also, I'm seeing the same broken picture on Linux with much newer Intel graphics.
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: Broken picture with 8-bit software renderers

Post by dpJudas »

I fixed the last error. The other ones went away on my computer once the SetActiveRenderTarget call was added.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Corrupted picture with software renderers

Post by _mental_ »

I moved this back to opened bugs subforum because a corrupted picture is still present.
Also, I updated the first post as this appeared to affect all software renderers.

My initial assumption was wrong, this has nothing to do with one channel image format.
This issue is caused by a buffer alignment only. In other words, everything works fine when horizontal resolution is divisible by some magic number.
For example, Intel graphics driver on Linux expects 64 bytes alignment while MoltenVK aligns memory by 128 bytes.
So, resolution like 1024x768 doesn't exhibit this problem on all hardware and OS combinations I tried.
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: Corrupted picture with software renderers

Post by dpJudas »

Seems the padding is mentioned in the spec: "VK_IMAGE_TILING_LINEAR specifies linear tiling (texels are laid out in memory in row-major order, possibly with some padding on each row)."

Unfortunately I'm not able to spot in the spec exactly how to read what that padding may be.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Corrupted picture with software renderers

Post by _mental_ »

I calculated it from size of memory allocated for image.

Code: Select all

image_width_padded = allocated_size / image_height
padding = image_width_padded - image_width
Alignment will be the next power of two of padding.
Hard to say about correctness of this approach according to the spec.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Corrupted picture with software renderers

Post by _mental_ »

Here is my attempt to fix it.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Corrupted picture with software renderers

Post by _mental_ »

Fixed in 56557a1.
Post Reply

Return to “Closed Bugs [GZDoom]”