diff options
author | Jason Ekstrand <[email protected]> | 2018-08-21 20:43:57 -0500 |
---|---|---|
committer | Jason Ekstrand <[email protected]> | 2018-09-07 15:19:02 -0500 |
commit | 465e5a868cd58ca7c4ff7476e98231ffd4f3d2bf (patch) | |
tree | 23c07757a02c1a6c1fc285e3121da7c5991aa46b /src/gallium/auxiliary/rbug | |
parent | b08b4b2b25b201df2d667cf70d7f99475e5c7aec (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