[Fixed] Corrupted picture with software renderers

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Corrupted picture with software renderers

Postby _mental_ » Fri May 03, 2019 4:51 am

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 8:15 am, edited 1 time in total.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Broken picture with 8-bit software renderers

Postby dpJudas » Fri May 03, 2019 5:34 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Broken picture with 8-bit software renderers

Postby _mental_ » Fri May 03, 2019 7:05 am

With validation layers enabled software renderer reports the following errors after entering a level. It's on macOS with integrated Intel graphics.
Code: Select allExpand view
[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 allExpand view
[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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Broken picture with 8-bit software renderers

Postby dpJudas » Fri May 03, 2019 9:24 am

I fixed the last error. The other ones went away on my computer once the SetActiveRenderTarget call was added.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Corrupted picture with software renderers

Postby _mental_ » Tue May 07, 2019 4:29 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Corrupted picture with software renderers

Postby dpJudas » Tue May 07, 2019 9:17 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Corrupted picture with software renderers

Postby _mental_ » Tue May 07, 2019 9:47 am

I calculated it from size of memory allocated for image.
Code: Select allExpand view
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_
 
 
 
Joined: 07 Aug 2011

Re: Corrupted picture with software renderers

Postby _mental_ » Wed May 08, 2019 4:26 am

Here is my attempt to fix it.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Corrupted picture with software renderers

Postby _mental_ » Wed May 08, 2019 2:53 pm

Fixed in 56557a1.
_mental_
 
 
 
Joined: 07 Aug 2011


Return to Closed Bugs

Who is online

Users browsing this forum: MSN [Bot] and 3 guests