summaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary/rbug
diff options
context:
space:
mode:
authorJason Ekstrand <[email protected]>2018-08-21 20:43:57 -0500
committerJason Ekstrand <[email protected]>2018-09-07 15:19:02 -0500
commit465e5a868cd58ca7c4ff7476e98231ffd4f3d2bf (patch)
tree23c07757a02c1a6c1fc285e3121da7c5991aa46b /src/gallium/auxiliary/rbug
parentb08b4b2b25b201df2d667cf70d7f99475e5c7aec (diff)
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 <[email protected]>
Diffstat (limited to 'src/gallium/auxiliary/rbug')
0 files changed, 0 insertions, 0 deletions