I'm confused. The thing you quoted says it is legal to have scissors exceed the framebuffer dimensions.
I'm sorry. I've read that line dozens of times and aparently misread it dozens of times. :( Sorry for the noise.
Looks like DXVK only sets it to 32767 when the scissors are disabled from d3d11 state. However the spec says.
It is legal for offset.x + extent.width or offset.y + extent.height to exceed the dimensions of the framebuffer - the scissor test still applies as defined above. Rasterization does not produce fragments outside of the framebuffer, so such fragments never have the scissor test performed on them.
The scissor test is always performed. Applications can effectively disable the scissor test by specifying a scissor rectangle that encompasses the entire framebuffer.
I think we should set it to the framebuffer size for disabling the scissors as the spec says it still runs the scissor test when it exceeds the dimensions for the area inside the framebuffer.
I think effectively disable in this context just means that even if it is performed by the hardware, no fragments will be discarded because of the scissor test alone. I think RADV just clamps the scissor rectangle multiple times anyway before submitting it to the hardware, e.g. to discard fragments outside the viewport.
Setting it to the framebuffer size just means doing more work than necessary, since the framebuffer size is not known when the scissor is set on the d3d side, so we'd have to clamp it in the state tracker. There should really be no issue when setting a larger scissor rect than technically allowed, unless we exceed device limits.
Nothing extracted yet.
I just found this happening in Batman: Arkham City. I don't know that it's causing any problems but it is in violation of the spec. In section 25.3, the Vulkan spec says:
But DXVK likes to use 32767x32767 scissors on 1920x1024 framebuffers. It's possible this is the app doing something wrong and DXVK just passing it through but I don't really know.