diff options
author | Kenneth Graunke <[email protected]> | 2016-05-25 14:38:32 -0700 |
---|---|---|
committer | Kenneth Graunke <[email protected]> | 2016-05-26 15:56:41 -0700 |
commit | e7776fa9473af0fd1424f860323916077b991bf6 (patch) | |
tree | d3ebcac12be9363051482b1eacd996e1198af5e1 /src/mesa | |
parent | e01a48218205adc280d3da00720dfb3d1ca5bde5 (diff) |
i965: Use the buffer object size for VERTEX_BUFFER_STATE's size field.
commit 7c8dfa78b98a12c1c5 (i965/draw: Use the real size for vertex
buffers) changed how we programmed the VERTEX_BUFFER_STATE size field.
Previously, we programmed it to the size of the actual underlying BO,
which is page-aligned, and potentially much larger than the GL buffer
object. This violated the ARB_robust_buffer_access spec.
With that change, we started programming it based on the range of data
we expect the draw call to actually access - which is based on the
min_index and max_index information provided to glDrawRangeElements().
Unfortunately, applications often provide inaccurate range information
to glDrawRangeElements(). For example, all the Unreal demos appear to
draw using a range of [0, 3] when the index buffer's actual index range
is [0, 5]. Such results are undefined, and we are absolutely allowed
to restrict access to the range they specified. However, the failure
mode is usually that nothing draws, or misrendering with wild geometry,
which is kind of bad for a common mistake. And people tend to assume
the range information isn't that important when data is in VBOs.
There's no real advantage, either. ARB_robust_buffer_access only
requires us to restrict access to the GL buffer object size, not
the range of data we think they should access. Doing that allows
buggy applications to still function. (Note that we still use this
information for busy-tracking, so if they try to overwrite the data
with glBufferSubData, they'll still hit a bug.) This seems to be
safer.
We may want to provide the more strict range as a debug option,
or scan the VBO and warn against bogus glDrawRangeElements in
debug contexts. That can be done as a later patch, though.
Makes Unreal demos draw again.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Diffstat (limited to 'src/mesa')
-rw-r--r-- | src/mesa/drivers/dri/i965/brw_draw_upload.c | 3 |
1 files changed, 1 insertions, 2 deletions
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c b/src/mesa/drivers/dri/i965/brw_draw_upload.c index f4d1b2c6af1..bfe20c57324 100644 --- a/src/mesa/drivers/dri/i965/brw_draw_upload.c +++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c @@ -543,6 +543,7 @@ brw_prepare_vertices(struct brw_context *brw) buffer->offset = offset; buffer->stride = glarray->StrideB; buffer->step_rate = glarray->InstanceDivisor; + buffer->size = glarray->BufferObj->Size - offset; enabled_buffer[j] = intel_buffer; buffer_range_start[j] = start; @@ -610,8 +611,6 @@ brw_prepare_vertices(struct brw_context *brw) buffer->bo = intel_bufferobj_buffer(brw, enabled_buffer[i], start, range); drm_intel_bo_reference(buffer->bo); - - buffer->size = start + range; } /* If we need to upload all the arrays, then we can trim those arrays to |