#vkCmdBeginRendering() - Access Reading Violation

4 messages · Page 1 of 1 (latest)

echo iris
#

I'm currently attempting to implement deferred rendering in my toy engine. I've run into an issue with implementing my two render pass instances via dynamic rendering functions.

When my geometry pass targets two color attachments, the vkCmdBeginRendering() (which only takes a single color attachment) call in my lighting pass throws an access-reading violation. When my geometry pass targets a single color attachment, the vkCmdBeginRendering() call in my lighting pass does not throw and exception.

In pseudocode, it looks something like this:

  vkCmdBeginRendering(cmd, 2 color attachments, depth attachment)
  // draw to my g-buffers
  vkCmdEndRendering(cmd)

  // barriers converting g-buffers from color attachment layout to sampled image layout

  vkCmdBeginRendering(cmd, 1 color attachment, no depth attachment) // !! Access-reading violation here when first render pass instance has 2 color attachments
  // combine g-buffers into my draw image
  vkCmdEndRendering(cmd)

I am completely lost on why the color attachment cound from my first render pass instance would affect my second render pass instance. My instinct is that the 'cmd' object is in a bad state, as when I attempted the above with separate command buffers per render pass instance no exception was raised. I am not sure why 'cmd' would be in a bad state, however.

Any ideas or instincts would be extremely appreciated! Thanks!

stark oxide
#

what do you mean by render pass instances? you shouldn't have any when you use dynamic rendering

echo iris
#

Sorry, I'm definitely using confusing terminology. The vkCmdBeginRendering manual page says: "vkCmdBeginRendering - Begin a dynamic render pass instance", so I was just copying their language there.

stark oxide
#

hm... I'm not a fan of this terminology, but your question makes sense now

doing an api dump might help here, but I'm afraid my knowledge of memory corruption is limited