summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorKenneth Graunke <[email protected]>2016-05-25 14:38:32 -0700
committerKenneth Graunke <[email protected]>2016-05-26 15:56:41 -0700
commite7776fa9473af0fd1424f860323916077b991bf6 (patch)
treed3ebcac12be9363051482b1eacd996e1198af5e1
parente01a48218205adc280d3da00720dfb3d1ca5bde5 (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]>
-rw-r--r--src/mesa/drivers/dri/i965/brw_draw_upload.c3
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