I noticed this while looking for a cite for the similar requirement I was going to put on texture buffer objects.
We don't actually have a test for this, but the GL_ARB_texture_buffer_range alignment test we have makes me reasonably confident that this works, too. This causes a regression to be reported in gles3conform, but it's a testcase bug that I've reported upstream. --- src/mesa/drivers/dri/i965/brw_context.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c index 776d221..dee8032 100644 --- a/src/mesa/drivers/dri/i965/brw_context.c +++ b/src/mesa/drivers/dri/i965/brw_context.c @@ -240,7 +240,15 @@ brw_initialize_context_constants(struct brw_context *brw) ctx->Const.NativeIntegers = true; ctx->Const.UniformBooleanTrue = 1; - ctx->Const.UniformBufferOffsetAlignment = 16; + + /* From the gen4 PRM, volume 4 page 127: + * + * "For SURFTYPE_BUFFER non-rendertarget surfaces, this field specifies + * the base address of the first element of the surface, computed in + * software by adding the surface base address to the byte offset of + * the element in the buffer." + */ + ctx->Const.UniformBufferOffsetAlignment = 1; ctx->Const.ForceGLSLExtensionsWarn = driQueryOptionb(&brw->optionCache, "force_glsl_extensions_warn"); -- 1.8.4.rc3 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev