Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vulkan: Shader debugging with input attachments #2247

Closed
luc4s opened this issue Apr 16, 2021 · 1 comment
Closed

Vulkan: Shader debugging with input attachments #2247

luc4s opened this issue Apr 16, 2021 · 1 comment
Labels
Bug A crash, misbehaviour, or other problem Unresolved Waiting for a fix or implementation

Comments

@luc4s
Copy link

luc4s commented Apr 16, 2021

Description

Hello,
I have a render pass which consists of 4 subpasses (implementation of order independent transparency), 2 of these subpasses reads from the other two subpass color attachments as input attachments.

Now, I want to debug the shader of one of these subpass that has two input attachments. The problem is that the displayed values in the shader do not reflect what the input attachment actually contains (texture viewer shows correct values though).

Steps to reproduce

  1. In provided capture, select any draw event in color pass UI is not high-DPI aware #2, preferably near end of pass, e.g. event 666
  2. In texture viewer, show output color attachment
  3. Select any pixel (right click) in drawing zone, e.g. 560;449
  4. Show history (first issue: history is showing input/output pixel values as 'Unavailable')
  5. Debug pixel of any event related to a draw command, e.g. EIG 616
  6. In shader debugging, press Run forwards
  7. In high level variables, b0 = (0, 0, 0, 0), but should be (4.52353, 0.71981, 0.41018, 0.16476) (can be checked in texture viewer)

Capture file:
DebugInputAttachment.zip

Environment

  • RenderDoc version: 1.13
  • Operating System: Windows 10
  • Graphics API: Vulkan 1.2.154.1
  • GPU: NVidia quadro P2000
  • Driver version: 451.48
@baldurk baldurk added Bug A crash, misbehaviour, or other problem Unresolved Waiting for a fix or implementation labels Apr 16, 2021
@baldurk
Copy link
Owner

baldurk commented Apr 16, 2021

This was caused by the pixel-relative co-ordinates not being properly transformed, so it was reading from 0,0 in the source texture. That commit should fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A crash, misbehaviour, or other problem Unresolved Waiting for a fix or implementation
Projects
None yet
Development

No branches or pull requests

2 participants