anv: Clamp scissors to the framebuffer boundary
authorJason Ekstrand <jason.ekstrand@intel.com>
Wed, 22 Aug 2018 01:43:57 +0000 (20:43 -0500)
committerJason Ekstrand <jason.ekstrand@intel.com>
Fri, 7 Sep 2018 20:19:02 +0000 (15:19 -0500)
commit465e5a868cd58ca7c4ff7476e98231ffd4f3d2bf
tree23c07757a02c1a6c1fc285e3121da7c5991aa46b
parentb08b4b2b25b201df2d667cf70d7f99475e5c7aec
anv: Clamp scissors to the framebuffer boundary

The Vulkan 1.1.81 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."

Elsewhere, the Vulkan 1.1.81 spec says:

    "The application must ensure (using scissor if necessary) that all
    rendering is contained within the render area, otherwise the pixels
    outside of the render area become undefined and shader side effects
    may occur for fragments outside the render area. The render area
    must be contained within the framebuffer dimensions."

Unfortunately, there's some room for interpretation here as to what the
consequences are of having the render area set to exactly the
framebuffer dimensions and having a scissor that is larger than the
framebuffer.  Given that GL and other APIs provide automatic clipping to
the framebuffer, it makes sense that applications would assume that
Vulkan does this as well.  It costs us very little to play it safe and
just clamp client-provided scissors to the framebuffer dimensions.
Fortunately, the user is required to provide us with at least one
scissor so we don't need to handle the case where they don't.

Fixes: fb2a5ceb3264 "anv: Emit DRAWING_RECTANGLE once at driver..."
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
src/intel/vulkan/gen7_cmd_buffer.c
src/intel/vulkan/genX_cmd_buffer.c