I had my raytracing application running fine using SDK 1.3.240.0. Now I updated to 1.3.280.1 and I am getting this weird validation error triggered by vkCmdTraceRaysKHR:
VUID-vkCmdTraceRaysKHR-None-08608
The specs are clear about this:
If a pipeline is bound to the pipeline bind point used by this command, there must not have been any calls to dynamic state setting commands for any state not specified as dynamic in the VkPipeline object bound to the pipeline bind point used by this command, since that pipeline was bound
Now, the thing is that between the raytracing pipeline binding and the trace rays call there are only push constants. There is a pipeline which is bound and actually used viewport & scissor dynamic states right before the trace, but it is a graphics pipeline.
The specs say "pipeline bound to the pipeline bind point used by this command", but isn't it only VK_PIPELINE_BIND_POINT_RAY_TRACING_KHR? (I am guessing, I couldn't find any explicit confirmation in the specs)
And why validation layers were silent in 1.3.240.0?
I finally found what the issue was.
Viewport and scissor were set before the rasterization pipeline is bound. The raytracing happens after the rasterization, so the raytracing pipeline is bound after the rasterization has been completed. However, in case of an empty scene, the rasterization phase was skipped. This led to a viewport & scissor set directly before the binding of the raytracing pipeline.
Now, what I think is a bit misleading, is that it seems like the viewport and scissor dynamic state, in case no pipeline is currently bound, affect the first pipeline that is bound after such dynamic state call are made.
In my case, if the rasterization phase was skipped, the viewport & scissor dynamic states affected the next pipeline to be bound, that was the raytracing pipeline (which can't have viewport or scissor dynamic states), yet the validation error message clearly states since that pipeline was bound which really puzzled me, since as I originally wrote, there is no such state set between the binding of the pipeline and the trace rays call.
In any case, I can confirm this behavior does not trigger any validation errors on 1.3.240.0