[Mesa-dev] [PATCH] scons: Add glsl/glcpp to the include path.
Fixes this build failure on Solaris.
Compiling build/sunos-debug/glsl/glcpp/glcpp-lex.c ...
"src/glsl/glcpp/glcpp-lex.l", line 30: cannot find include file: "glcpp-parse.h"
Signed-off-by: Vinson Lee
---
src/glsl/SConscript |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/SConscript b/src/glsl/SConscript
index f8e8723..2fc57c6 100644
--- a/src/glsl/SConscript
+++ b/src/glsl/SConscript
@@ -14,8 +14,8 @@ env.Prepend(CPPPATH = [
'#src/glsl/glcpp',
])
-# Make glcpp/glcpp-parse.h and glsl_parser.h reacheable from the include path
-env.Append(CPPPATH = [Dir('.').abspath])
+# Make glcpp-parse.h and glsl_parser.h reachable from the include path.
+env.Append(CPPPATH = [Dir('.').abspath, Dir('glcpp').abspath])
env.Append(YACCFLAGS = '-d')
--
1.7.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] scons: Do not build glx on Solaris.
The GLX headers on Solaris are not recent enough.
Signed-off-by: Vinson Lee
---
src/SConscript |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/SConscript b/src/SConscript
index 75c4446..f55a20e 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -23,7 +23,7 @@ SConscript('mesa/SConscript')
SConscript('mapi/vgapi/SConscript')
if not env['embedded']:
-if env['platform'] not in ('cygwin', 'darwin', 'freebsd', 'haiku',
'windows'):
+if env['platform'] not in ('cygwin', 'darwin', 'freebsd', 'haiku',
'sunos', 'windows'):
SConscript('glx/SConscript')
if env['platform'] not in ['darwin', 'haiku', 'sunos']:
SConscript('egl/main/SConscript')
--
1.7.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Do not build glx on Solaris.
On 06/19/2012 11:34 PM, Vinson Lee wrote:
> The GLX headers on Solaris are not recent enough.
>
> Signed-off-by: Vinson Lee
> ---
> src/SConscript |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/SConscript b/src/SConscript
> index 75c4446..f55a20e 100644
> --- a/src/SConscript
> +++ b/src/SConscript
> @@ -23,7 +23,7 @@ SConscript('mesa/SConscript')
> SConscript('mapi/vgapi/SConscript')
>
> if not env['embedded']:
> -if env['platform'] not in ('cygwin', 'darwin', 'freebsd', 'haiku',
> 'windows'):
> +if env['platform'] not in ('cygwin', 'darwin', 'freebsd', 'haiku',
> 'sunos', 'windows'):
> SConscript('glx/SConscript')
> if env['platform'] not in ['darwin', 'haiku', 'sunos']:
> SConscript('egl/main/SConscript')
It doesn't sound very useful to build Mesa on Solaris without GLX
support. I guess you could use EGL, but...most existing apps use GLX,
so I imagine not much would run...
That said, I don't use Solaris nor SCons, so it's not really my place to
say...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: remove obsolete confdiff.sh
On 06/19/2012 10:49 AM, Andreas Boll wrote: > this script is obsolete since > 0cc216676c96efacb0e1eb82457e6a83920ae704 > --- > bin/confdiff.sh | 48 > 1 files changed, 0 insertions(+), 48 deletions(-) > delete mode 100755 bin/confdiff.sh Heh! :D It sure is... Applied, thanks. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] glsl: glcpp: Move handling of #line directives from lexer to parser.
On 06/09/2012 04:41 PM, Carl Worth wrote:
> The GLSL specification requires that #line directives be interpreted
> after macro expansion. Our existing implementation of #line macros in
> the lexer prevents conformance on this point.
>
> Moving the handling of #line from the lexer to the parser gives us the
> macro expansion we need. An additional benefit is that the
> preprocessor also now supports comments on the same line as #line
> directives.
>
> Finally, the preprocessor now emits the (fully-macro-expanded) #line
> directives into the output. This allows the full GLSL compiler to also
> see and interpret these directives so it can also generate correct
> line numbers in error messages.
> ---
> src/glsl/glcpp/glcpp-lex.l| 49
> +++--
> src/glsl/glcpp/glcpp-parse.y | 33 -
> src/glsl/glcpp/glcpp.h|4 ++
> src/glsl/glcpp/tests/091-hash-line.c.expected |8 ++--
> 4 files changed, 54 insertions(+), 40 deletions(-)
Hi Carl,
Sorry for the extremely late review. (Lost this one in the inbox.)
Comments below...
> diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
> index b34f2c0..7ab58cb 100644
> --- a/src/glsl/glcpp/glcpp-lex.l
> +++ b/src/glsl/glcpp/glcpp-lex.l
> @@ -40,12 +40,18 @@ void glcpp_set_column (int column_no , yyscan_t
> yyscanner);
>
> #define YY_NO_INPUT
>
> -#define YY_USER_ACTION \
> - do { \
> - yylloc->first_column = yycolumn + 1; \
> - yylloc->first_line = yylineno;\
> - yycolumn += yyleng; \
> - } while(0);
> +#define YY_USER_ACTION
> \
> + do {\
> + if (parser->has_new_line_number)\
> + yylineno = parser->new_line_number; \
> + if (parser->has_new_source_number) \
> + yylloc->source = parser->new_source_number; \
Could yylineno and yylloc->source be set directly from the rules, rather
than using flags and setting them here? It seems like they could, but I
imagine you tried that and it doesn't work.
> + yylloc->first_column = yycolumn + 1;\
> + yylloc->first_line = yylineno; \
> + yycolumn += yyleng; \
> + parser->has_new_line_number = 0;\
> + parser->has_new_source_number = 0; \
> + } while(0);
>
> #define YY_USER_INIT \
> do {\
> @@ -129,35 +135,8 @@ HEXADECIMAL_INTEGER 0[xX][0-9a-fA-F]+[uU]?
> return OTHER;
> }
>
> -{HASH}line{HSPACE}+{DIGITS}{HSPACE}+{DIGITS}{HSPACE}*$ {
> - /* Eat characters until the first digit is
> - * encountered
> - */
> - char *ptr = yytext;
> - while (!isdigit(*ptr))
> - ptr++;
> -
> - /* Subtract one from the line number because
> - * yylineno is zero-based instead of
> - * one-based.
> - */
> - yylineno = strtol(ptr, &ptr, 0) - 1;
> - yylloc->source = strtol(ptr, NULL, 0);
> -}
> -
> -{HASH}line{HSPACE}+{DIGITS}{HSPACE}*$ {
> - /* Eat characters until the first digit is
> - * encountered
> - */
> - char *ptr = yytext;
> - while (!isdigit(*ptr))
> - ptr++;
> -
> - /* Subtract one from the line number because
> - * yylineno is zero-based instead of
> - * one-based.
> - */
> - yylineno = strtol(ptr, &ptr, 0) - 1;
> +{HASH}line {
> + return HASH_LINE;
> }
>
> {
> diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
> index ee00180..cc4af16 100644
> --- a/src/glsl/glcpp/glcpp-parse.y
> +++ b/src/glsl/glcpp/glcpp-parse.y
> @@ -162,7 +162,7 @@ add_builtin_define(glcpp_parser_t *parser, const char
> *name, int value);
> %lex-param {glcpp_parser_t *parser}
>
> %expect 0
> -%token COMMA_FINAL DEFINED ELIF_EXPANDED HASH HASH_DEFINE_FUNC
> HASH_DEFINE_OBJ HASH_ELIF HASH_ELSE HASH_ENDIF HASH_IF HASH_IFDEF HASH_IFNDEF
> HASH_UNDEF HASH_VERSION IDENTIFIER IF_EXPANDED INTEGER INTEGER_STRING NEWLINE
> OTHER PLACEHOLDER SPACE
> +%token COMMA_FINAL DEFINED ELIF_EXPANDED HASH HASH_DEFINE_FUNC
> HASH_DEFINE_OBJ HASH_ELIF HASH_ELSE HASH_ENDIF HASH_IF HASH_IFDEF HASH_IFNDEF
> HASH_LINE HASH_UNDEF HASH_VERSION IDENTIFIER IF_EXPANDED INTEGER
> INTEGER_STRING LINE_EXPANDED NEWLINE OTHER PLACEHOLDER SPACE
> %token PASTE
> %type expression INTEGER operator SPACE integer_constant
> %type IDENTIFIER INTEGER_STRING OTHER
> @@ -208,6 +208,24 @@ expanded_line:
> |ELIF_EXPANDED expression NEWLINE {
>
Re: [Mesa-dev] [PATCH 2/9] mesa: Add state and getters for the GL_ARB_uniform_buffer_object maximums.
On 06/18/2012 06:35 PM, Eric Anholt wrote:
> Fixes piglit GL_ARB_uniform_buffer_object/minmax.
> ---
> src/mesa/main/context.c |9 +
> src/mesa/main/get.c | 30 ++
> src/mesa/main/mtypes.h | 12
> 3 files changed, 51 insertions(+)
>
> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
> index 3bcedec..643476b 100644
> --- a/src/mesa/main/context.c
> +++ b/src/mesa/main/context.c
> @@ -542,6 +542,9 @@ init_program_limits(GLenum type, struct
> gl_program_constants *prog)
> prog->MediumInt.RangeMax = 24;
> prog->MediumInt.Precision = 0;
> prog->LowInt = prog->HighInt = prog->MediumInt;
> +
> + prog->MaxUniformBlocks = 12;
> + prog->MaxCombinedUniformComponents = prog->MaxUniformComponents;
> }
>
>
> @@ -653,6 +656,12 @@ _mesa_init_constants(struct gl_context *ctx)
> ctx->Const.MaxTransformFeedbackSeparateComponents = 4 *
> MAX_FEEDBACK_ATTRIBS;
> ctx->Const.MaxTransformFeedbackInterleavedComponents = 4 *
> MAX_FEEDBACK_ATTRIBS;
>
> + /** GL_ARB_uniform_buffer_object */
> + ctx->Const.MaxCombinedUniformBlocks = 36;
> + ctx->Const.MaxUniformBufferBindings = 36;
> + ctx->Const.MaxUniformBlockSize = 16384;
> + ctx->Const.UniformBufferOffsetAlignment = 1;
> +
> /* GL 3.2: hard-coded for now: */
> ctx->Const.ProfileMask = GL_CONTEXT_COMPATIBILITY_PROFILE_BIT;
>
> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
> index 8dc4730..bbbaddd 100644
> --- a/src/mesa/main/get.c
> +++ b/src/mesa/main/get.c
> @@ -289,6 +289,12 @@ static const int extra_ARB_sampler_objects[] = {
> EXTRA_END
> };
>
> +static const int extra_ARB_uniform_buffer_object_and_geometry_shader[] = {
> + EXT(ARB_sampler_objects),
I think you mean ARB_uniform_buffer_object here (looks like cut&paste).
Otherwise, LGTM. With that fixed,
Reviewed-by: Kenneth Graunke
> + EXT(ARB_geometry_shader4),
> + EXTRA_END
> +};
> +
>
> EXTRA_EXT(ARB_ES2_compatibility);
> EXTRA_EXT(ARB_texture_cube_map);
> @@ -335,6 +341,7 @@ EXTRA_EXT(EXT_framebuffer_sRGB);
> EXTRA_EXT(ARB_texture_buffer_object);
> EXTRA_EXT(OES_EGL_image_external);
> EXTRA_EXT(ARB_blend_func_extended);
> +EXTRA_EXT(ARB_uniform_buffer_object);
>
> static const int
> extra_ARB_vertex_program_ARB_fragment_program_NV_vertex_program[] = {
> @@ -1321,6 +1328,29 @@ static const struct value_desc values[] = {
>
> { GL_MAX_DUAL_SOURCE_DRAW_BUFFERS,
> CONTEXT_INT(Const.MaxDualSourceDrawBuffers), extra_ARB_blend_func_extended },
>
> + /* GL_ARB_uniform_buffer_object */
> + { GL_MAX_VERTEX_UNIFORM_BLOCKS,
> CONTEXT_INT(Const.VertexProgram.MaxUniformBlocks),
> + extra_ARB_uniform_buffer_object },
> + { GL_MAX_FRAGMENT_UNIFORM_BLOCKS,
> CONTEXT_INT(Const.FragmentProgram.MaxUniformBlocks),
> + extra_ARB_uniform_buffer_object },
> + { GL_MAX_GEOMETRY_UNIFORM_BLOCKS,
> CONTEXT_INT(Const.GeometryProgram.MaxUniformBlocks),
> + extra_ARB_uniform_buffer_object_and_geometry_shader },
> + { GL_MAX_COMBINED_UNIFORM_BLOCKS,
> CONTEXT_INT(Const.MaxCombinedUniformBlocks),
> + extra_ARB_uniform_buffer_object },
> + { GL_MAX_UNIFORM_BLOCK_SIZE, CONTEXT_INT(Const.MaxUniformBlockSize),
> + extra_ARB_uniform_buffer_object },
> + { GL_MAX_UNIFORM_BUFFER_BINDINGS,
> CONTEXT_INT(Const.MaxUniformBufferBindings),
> + extra_ARB_uniform_buffer_object },
> +
> + { GL_MAX_COMBINED_VERTEX_UNIFORM_COMPONENTS,
> CONTEXT_INT(Const.VertexProgram.MaxCombinedUniformComponents),
> + extra_ARB_uniform_buffer_object },
> + { GL_MAX_COMBINED_FRAGMENT_UNIFORM_COMPONENTS,
> CONTEXT_INT(Const.FragmentProgram.MaxCombinedUniformComponents),
> + extra_ARB_uniform_buffer_object },
> + { GL_MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS,
> CONTEXT_INT(Const.GeometryProgram.MaxCombinedUniformComponents),
> + extra_ARB_uniform_buffer_object_and_geometry_shader },
> + { GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT,
> CONTEXT_INT(Const.UniformBufferOffsetAlignment),
> + extra_ARB_uniform_buffer_object },
> +
> #endif /* FEATURE_GL */
> };
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 3d18b7c..f70df8a 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -2709,6 +2709,9 @@ struct gl_program_constants
> /* ES 2.0 and GL_ARB_ES2_compatibility */
> struct gl_precision LowFloat, MediumFloat, HighFloat;
> struct gl_precision LowInt, MediumInt, HighInt;
> + /* GL_ARB_uniform_buffer_object */
> + GLuint MaxUniformBlocks;
> + GLuint MaxCombinedUniformComponents;
> };
>
>
> @@ -2774,6 +2777,15 @@ struct gl_constants
> GLuint MaxVertexVaryingComponents; /**< Between vert and geom shader */
> GLuint MaxGeometryVaryingComponents; /**< Between geom and frag shader */
>
> + /** @{
> +* GL_ARB_uniform_buffer_object
> +*/
> + GLuint MaxCombinedUniformBlocks;
> + GLuint MaxUniformBufferBindings;
> + GLuint MaxUniformBlockSize;
> + GLuint UniformBufferOff
Re: [Mesa-dev] [PATCH 7/9] mesa: Add support for glBindBufferBase/Range on GL_UNIFORM_BUFFER.
On 06/18/2012 06:35 PM, Eric Anholt wrote:
> Fixes piglits:
> GL_ARB_uniform_buffer_object/bindbuffer-general-point.
> GL_ARB_uniform_buffer_object/negative-bindbuffer-buffer
> GL_ARB_uniform_buffer_object/negative-bindbuffer-index
> GL_ARB_uniform_buffer_object/negative-bindbuffer-target
> GL_ARB_uniform_buffer_object/negative-bindbufferrange-range
> ---
> src/mesa/main/bufferobj.c | 98
> +
> 1 file changed, 98 insertions(+)
>
> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> index b69ddc9..e00eaf8 100644
> --- a/src/mesa/main/bufferobj.c
> +++ b/src/mesa/main/bufferobj.c
> @@ -1994,6 +1994,97 @@ _mesa_GetObjectParameterivAPPLE(GLenum objectType,
> GLuint name, GLenum pname,
>
> #endif /* FEATURE_APPLE_object_purgeable */
>
> +static void
> +_set_ubo_binding(struct gl_context *ctx,
> + int index,
> + struct gl_buffer_object *bufObj,
> + GLintptr offset,
> + GLsizeiptr size,
> + GLboolean autoSize)
> +{
> + struct gl_uniform_buffer_binding *binding;
> +
> + binding = &ctx->UniformBufferBindings[index];
> + if (binding->BufferObject == bufObj &&
> + binding->Offset == offset &&
> + binding->Size == size &&
> + binding->AutomaticSize == autoSize) {
> + return;
> + }
> +
> + FLUSH_VERTICES(ctx, _NEW_BUFFER_OBJECT);
> +
> + _mesa_reference_buffer_object(ctx, &binding->BufferObject, bufObj);
> + binding->Offset = offset;
> + binding->Size = size;
> + binding->AutomaticSize = autoSize;
> +}
> +
> +/**
> + * Specify a buffer object to receive vertex shader results. Plus,
> + * specify the starting offset to place the results, and max size.
> + */
> +static void
> +_mesa_bind_buffer_range_uniform_buffer(struct gl_context *ctx,
> +GLuint index,
> +struct gl_buffer_object *bufObj,
> +GLintptr offset,
> +GLsizeiptr size)
> +{
> + if (index >= ctx->Const.MaxUniformBufferBindings) {
> + _mesa_error(ctx, GL_INVALID_VALUE, "glBindBufferRange(index=%d)",
> index);
> + return;
> + }
> +
> + if (offset & (ctx->Const.UniformBufferOffsetAlignment - 1)) {
> + _mesa_error(ctx, GL_INVALID_VALUE,
> + "glBindBufferRange(offset=%d)", (int) offset);
> + return;
> + }
> +
> + if (size < 0) {
> + _mesa_error(ctx, GL_INVALID_VALUE,
> + "glBindBufferRange(size %d < 0)", (int) size);
> + return;
> + }
> +
> + if (offset + size > bufObj->Size) {
> + _mesa_error(ctx, GL_INVALID_VALUE,
> + "glBindBufferRange(offset + size %d > buffer size %d)",
> + (int) (offset + size), (int) (bufObj->Size));
> + return;
> + }
Why not put both of these checks into _mesa_BindBufferRange and remove
them from both the UBO and XFB implementations? I think basically every
version of BindBufferRange will need size < 0 and offset + size >
bufObj->Size checks.
(The XFB version ensures it's > 0, not >=, but still...better to add the
tiny redundancy and be more future-proof IMO.)
> + if (bufObj == ctx->Shared->NullBufferObj) {
> + offset = -1;
> + size = -1;
> + }
> +
> + _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer, bufObj);
> + _set_ubo_binding(ctx, index, bufObj, offset, size, GL_FALSE);
> +}
> +
> +
> +/**
> + * Specify a buffer object to receive vertex shader results.
> + * As above, but start at offset = 0.
> + */
> +static void
> +_mesa_bind_buffer_base_uniform_buffer(struct gl_context *ctx,
> + GLuint index,
> + struct gl_buffer_object *bufObj)
> +{
> + if (index >= ctx->Const.MaxUniformBufferBindings) {
> + _mesa_error(ctx, GL_INVALID_VALUE, "glBindBufferBase(index=%d)",
> index);
> + return;
> + }
> +
> + _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer, bufObj);
> + if (bufObj == ctx->Shared->NullBufferObj)
> + _set_ubo_binding(ctx, index, bufObj, -1, -1, GL_TRUE);
> + else
> + _set_ubo_binding(ctx, index, bufObj, 0, 0, GL_TRUE);
> +}
>
> void GLAPIENTRY
> _mesa_BindBufferRange(GLenum target, GLuint index,
> @@ -2019,6 +2110,10 @@ _mesa_BindBufferRange(GLenum target, GLuint index,
>_mesa_bind_buffer_range_transform_feedback(ctx, index, bufObj,
>offset, size);
>return;
> + case GL_UNIFORM_BUFFER:
> + _mesa_bind_buffer_range_uniform_buffer(ctx, index, bufObj,
> + offset, size);
> + return;
> default:
>_mesa_error(ctx, GL_INVALID_ENUM, "glBindBufferRange(target)");
>return;
> @@ -2047,6 +2142,9 @@ _mesa_BindBufferBase(GLenum target, GLuint index,
> GLuint buffer)
> case GL_TRANSFORM_FEEDBACK_BUFFER:
>_mesa_bind_buffer_base_transfor
Re: [Mesa-dev] [PATCH 8/9] mesa: Add support for glGetIntegeri_v from GL_ARB_uniform_buffer_object.
On 06/18/2012 06:35 PM, Eric Anholt wrote:
> Fixes piglit ARB_uniform_buffer_object/getintegeri_v.
> ---
> src/mesa/main/get.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
> index 933bfe7..4798c02 100644
> --- a/src/mesa/main/get.c
> +++ b/src/mesa/main/get.c
> @@ -2566,6 +2566,30 @@ find_value_indexed(const char *func, GLenum pname, int
> index, union value *v)
>goto invalid_enum;
>v->value_int =
> ctx->TransformFeedback.CurrentObject->BufferNames[index];
>return TYPE_INT;
> +
> + case GL_UNIFORM_BUFFER_BINDING:
> + if (index >= ctx->Const.MaxUniformBufferBindings)
> + goto invalid_value;
> + if (!ctx->Extensions.ARB_uniform_buffer_object)
> + goto invalid_enum;
> + v->value_int = ctx->UniformBufferBindings[index].BufferObject->Name;
> + return TYPE_INT;
> +
> + case GL_UNIFORM_BUFFER_START:
> + if (index >= ctx->Const.MaxUniformBufferBindings)
> + goto invalid_value;
> + if (!ctx->Extensions.ARB_uniform_buffer_object)
> + goto invalid_enum;
> + v->value_int = ctx->UniformBufferBindings[index].Offset;
> + return TYPE_INT;
> +
> + case GL_UNIFORM_BUFFER_SIZE:
> + if (index >= ctx->Const.MaxUniformBufferBindings)
> + goto invalid_value;
> + if (!ctx->Extensions.ARB_uniform_buffer_object)
> + goto invalid_enum;
> + v->value_int = ctx->UniformBufferBindings[index].Size;
> + return TYPE_INT;
> }
>
> invalid_enum:
Total nitpick: it seems like you should reorder the two checks, i.e.
if (!ctx->Extensions.ARB_uniform_buffer_object)
goto invalid_enum;
if (index out of bounds)
goto invalid_value;
because if I query these on an implementation that doesn't support
ARB_uniform_buffer_object, I would expect to get GL_INVALID_ENUM ("WTF
are you talking about?"), not a complaint that my index value is out of
bounds. (Not to mention the fact that you can't glGet() the upper bound
in the first place...)
It doesn't really matter, though I bet there's some picky conformance
suite out there that might care. (I haven't checked oglconform, but it
just sounds like the sort of thing they'd check for. :))
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/9] glapi: Add uniform buffer object API
On 06/18/2012 06:35 PM, Eric Anholt wrote: > From: Vincent Lejeune > > v2: Fix a typo spotted by Eric Anholt. > v3: Fix missing "GL" on types, fix style, fix Studly_Caps extension name, > drop commented code duplicated with GL3x.xml [anholt] Aside from the pithy comments and one tiny fix, this series looks good to me! It's a start at least :) Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Do not build glx on Solaris.
- Original Message -
> On 06/19/2012 11:34 PM, Vinson Lee wrote:
> > The GLX headers on Solaris are not recent enough.
> >
> > Signed-off-by: Vinson Lee
> > ---
> > src/SConscript |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/src/SConscript b/src/SConscript
> > index 75c4446..f55a20e 100644
> > --- a/src/SConscript
> > +++ b/src/SConscript
> > @@ -23,7 +23,7 @@ SConscript('mesa/SConscript')
> > SConscript('mapi/vgapi/SConscript')
> >
> > if not env['embedded']:
> > -if env['platform'] not in ('cygwin', 'darwin', 'freebsd',
> > 'haiku', 'windows'):
> > +if env['platform'] not in ('cygwin', 'darwin', 'freebsd',
> > 'haiku', 'sunos', 'windows'):
> > SConscript('glx/SConscript')
> > if env['platform'] not in ['darwin', 'haiku', 'sunos']:
> > SConscript('egl/main/SConscript')
>
> It doesn't sound very useful to build Mesa on Solaris without GLX
> support. I guess you could use EGL, but...most existing apps use
> GLX,
> so I imagine not much would run...
>
> That said, I don't use Solaris nor SCons, so it's not really my place
> to
> say...
I agree. I don't know what's the end goal of Solaris support, but I can't see
much use to build on Solaris without GLX.
Mesa already ships some glx headers, so maybe a better solution would be to
ensure that they are included before system headers on scons.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 07/21] mesa/samplerobj: Support EXT_texture_sRGB_decode
On 06/12/2012 11:38 AM, Pauli Nieminen wrote:
> sRGBDecode state is part of sampler object state but mesa was missing
> handlers to access the state. This patch adds the support for required
> state changes and queries.
>
> GL_EXT_texture_sRGB_decode issue 4:
> "4) Should we add forward-looking support for ARB_sampler_objects?
>
> RESOLVED: YES
>
> If ARB_sampler_objects exists in the implementation, the sampler
> objects should also include this parameter per sampler."
>
> Signed-off-by: Pauli Nieminen
> Reviewed-by: Brian Paul
> ---
> src/mesa/main/samplerobj.c | 56
>
> 1 file changed, 56 insertions(+)
>
> diff --git a/src/mesa/main/samplerobj.c b/src/mesa/main/samplerobj.c
> index 8c54c9a..f276296 100644
> --- a/src/mesa/main/samplerobj.c
> +++ b/src/mesa/main/samplerobj.c
> @@ -582,6 +582,24 @@ set_sampler_cube_map_seamless(struct gl_context *ctx,
> return GL_TRUE;
> }
>
> +static GLuint
> +set_sampler_srgb_decode(struct gl_context *ctx,
> + struct gl_sampler_object *samp, GLenum param)
> +{
> + if (!ctx->Extensions.EXT_texture_sRGB_decode)
> + return INVALID_PNAME;
> +
> + if (samp->sRGBDecode == param)
> + return GL_FALSE;
> +
> + if (param != GL_DECODE_EXT && param != GL_SKIP_DECODE_EXT)
> + return INVALID_VALUE;
The correct return value for glSamplerParameter when passed an invalid
pname is GL_INVALID_ENUM, not GL_INVALID_VALUE. From the GL 4.0 core
spec, page 177: "An INVALID_ENUM error is generated if pname is not the
name of a parameter accepted by SamplerParameter*."
To make that happen, you should return INVALID_PARAM here, and the code
at the bottom of _mesa_SamplerParameter* will make translate it.
> + flush(ctx);
> + samp->sRGBDecode = param;
> + return GL_TRUE;
> +}
> +
>
> static void GLAPIENTRY
> _mesa_SamplerParameteri(GLuint sampler, GLenum pname, GLint param)
> @@ -634,6 +652,9 @@ _mesa_SamplerParameteri(GLuint sampler, GLenum pname,
> GLint param)
> case GL_TEXTURE_CUBE_MAP_SEAMLESS:
>res = set_sampler_cube_map_seamless(ctx, sampObj, param);
>break;
> + case GL_TEXTURE_SRGB_DECODE_EXT:
> + res = set_sampler_srgb_decode(ctx, sampObj, param);
> + break;
> case GL_TEXTURE_BORDER_COLOR:
>/* fall-through */
> default:
> @@ -718,6 +739,9 @@ _mesa_SamplerParameterf(GLuint sampler, GLenum pname,
> GLfloat param)
> case GL_TEXTURE_CUBE_MAP_SEAMLESS:
>res = set_sampler_cube_map_seamless(ctx, sampObj, (GLboolean) param);
>break;
> + case GL_TEXTURE_SRGB_DECODE_EXT:
> + res = set_sampler_srgb_decode(ctx, sampObj, (GLenum) param);
> + break;
> case GL_TEXTURE_BORDER_COLOR:
>/* fall-through */
> default:
> @@ -799,6 +823,9 @@ _mesa_SamplerParameteriv(GLuint sampler, GLenum pname,
> const GLint *params)
> case GL_TEXTURE_CUBE_MAP_SEAMLESS:
>res = set_sampler_cube_map_seamless(ctx, sampObj, params[0]);
>break;
> + case GL_TEXTURE_SRGB_DECODE_EXT:
> + res = set_sampler_srgb_decode(ctx, sampObj, params[0]);
> + break;
> case GL_TEXTURE_BORDER_COLOR:
>{
> GLfloat c[4];
> @@ -890,6 +917,9 @@ _mesa_SamplerParameterfv(GLuint sampler, GLenum pname,
> const GLfloat *params)
> case GL_TEXTURE_CUBE_MAP_SEAMLESS:
>res = set_sampler_cube_map_seamless(ctx, sampObj, (GLboolean)
> params[0]);
>break;
> + case GL_TEXTURE_SRGB_DECODE_EXT:
> + res = set_sampler_srgb_decode(ctx, sampObj, (GLenum) params[0]);
> + break;
> case GL_TEXTURE_BORDER_COLOR:
>res = set_sampler_border_colorf(ctx, sampObj, params);
>break;
> @@ -972,6 +1002,9 @@ _mesa_SamplerParameterIiv(GLuint sampler, GLenum pname,
> const GLint *params)
> case GL_TEXTURE_CUBE_MAP_SEAMLESS:
>res = set_sampler_cube_map_seamless(ctx, sampObj, params[0]);
>break;
> + case GL_TEXTURE_SRGB_DECODE_EXT:
> + res = set_sampler_srgb_decode(ctx, sampObj, (GLenum) params[0]);
> + break;
> case GL_TEXTURE_BORDER_COLOR:
>res = set_sampler_border_colori(ctx, sampObj, params);
>break;
> @@ -1055,6 +1088,9 @@ _mesa_SamplerParameterIuiv(GLuint sampler, GLenum
> pname, const GLuint *params)
> case GL_TEXTURE_CUBE_MAP_SEAMLESS:
>res = set_sampler_cube_map_seamless(ctx, sampObj, params[0]);
>break;
> + case GL_TEXTURE_SRGB_DECODE_EXT:
> + res = set_sampler_srgb_decode(ctx, sampObj, (GLenum) params[0]);
> + break;
> case GL_TEXTURE_BORDER_COLOR:
>res = set_sampler_border_colorui(ctx, sampObj, params);
>break;
> @@ -1149,6 +1185,11 @@ _mesa_GetSamplerParameteriv(GLuint sampler, GLenum
> pname, GLint *params)
> goto invalid_pname;
>*params = sampObj->CubeMapSeamless;
>break;
> + case GL_TEXTURE_SRGB_DECODE_EXT:
> + if (!ctx->Extensions.EXT_texture_sRGB_decode)
> + goto invalid_pname;
>
Re: [Mesa-dev] [PATCH v2 03/21] mesa: Remove unnecessary parameters from TexImage
On 06/12/2012 11:38 AM, Pauli Nieminen wrote: > gl_texture_image structure always holds size and internal format before > TexImage driver hook is called. Those passing same information in > function parameters only duplicates information making the interface > harder to understand. > > Signed-off-by: Pauli Nieminen > Reviewed-by: Brian Paul Nice cleanups! Patches 3-6 are: Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] softpipe: Take all lods into account when texture sampling.
On 06/19/2012 08:01 PM, Olivier Galibert wrote: This patch churns a lot because it needs to change 4-wide filters into single pixel filters, since each fragment may use a different filter. The only case not entirely supported is the anisotropic filtering. Not sure what we want to do there, since a full quad is required by that filter. Signed-off-by: Olivier Galibert A lot of code I just glossed over it, but seems to look ok other than the (performance) implications this might have. --- src/gallium/drivers/softpipe/sp_tex_sample.c | 1383 -- src/gallium/drivers/softpipe/sp_tex_sample.h | 28 +- 2 files changed, 645 insertions(+), 766 deletions(-) @@ -837,64 +773,61 @@ print_sample(const char *function, float rgba[TGSI_NUM_CHANNELS][TGSI_QUAD_SIZE] rgba[0][3], rgba[1][3], rgba[2][3], rgba[3][3]); } - /* Some image-filter fastpaths: */ static INLINE void img_filter_2d_linear_repeat_POT(struct tgsi_sampler *tgsi_sampler, -const float s[TGSI_QUAD_SIZE], -const float t[TGSI_QUAD_SIZE], -const float p[TGSI_QUAD_SIZE], -const float c0[TGSI_QUAD_SIZE], +float s, +float t, +float p, + unsigned level, whitespace +unsigned face_id, enum tgsi_sampler_control control, -float rgba[TGSI_NUM_CHANNELS][TGSI_QUAD_SIZE]) +float *rgba) Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] softpipe: Take all lods into account when texture sampling.
On 06/20/2012 05:43 AM, Olivier Galibert wrote: On Tue, Jun 19, 2012 at 02:46:35PM -0700, Jose Fonseca wrote: Could you give more background on why is this necessary? This will make software renderering slower, so I'd really like to avoid it on llvmpipe if at all possible. Well, given the existence of textureLod and textureGrad every texture sample can easily hit a different mipmap or even, by switching between minification and magnification, a different filter entirely. Even a simple texture() is hit, if your polygon is horizontal enough. And this goes double for vertex shaders, where texture fetches there have less reason to be close in texture space. textureSize and textureFetch, with their explicit lod, have of course the same problem. only worse. If I see that right, this only really affects sampling with either (per-pixel) lodbias, explicit lod or explicit gradients. For "normal" texture sampling results shouldn't change since rho/lambda (which determines lod) is per-quad. In this case I think we'd want to split the fetch functions in llvmpipe if any of that is present, since this is going to require per-pixel lookups of mip level offsets at least. Also, min/mag filter selection needs to be handled different in this case too (doing this with per-pixel branch code isn't really an option) - maybe keep the branch to choose between min/mag filter if all pixels use the same filter, and use some hacked-up linear path instead if not which forces weights for the pixels using nearest to the appropriate value. Sounds like a lot of effort though. In any case for softpipe performance isn't as critical, though I'm curious if it makes a large performance difference for "ordinary" texture sampling (in which case things could be split as well, though I guess for softpipe code simplicity wins over faster code). Otherwise this looks like the right thing to do in principle to me, though I'd like to hear Brian's opinion on that too. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/9] mesa: Add support for glGetIntegeri_v from GL_ARB_uniform_buffer_object.
On 06/19/2012 01:26 PM, Eric Anholt wrote: On Tue, 19 Jun 2012 08:10:25 -0600, Brian Paul wrote: On 06/18/2012 07:35 PM, Eric Anholt wrote: Fixes piglit ARB_uniform_buffer_object/getintegeri_v. --- src/mesa/main/get.c | 24 1 file changed, 24 insertions(+) diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c index 933bfe7..4798c02 100644 --- a/src/mesa/main/get.c +++ b/src/mesa/main/get.c @@ -2566,6 +2566,30 @@ find_value_indexed(const char *func, GLenum pname, int index, union value *v) goto invalid_enum; v->value_int = ctx->TransformFeedback.CurrentObject->BufferNames[index]; return TYPE_INT; + + case GL_UNIFORM_BUFFER_BINDING: + if (index>= ctx->Const.MaxUniformBufferBindings) +goto invalid_value; + if (!ctx->Extensions.ARB_uniform_buffer_object) +goto invalid_enum; I think it's a bit more natural to do the extension check before the index check. Since all the other enums are handled in this order, too, I'd rather that be an independent change. It does seem like a silly ordering, though. Kenneth spotted the same thing. Reordering in a follow-on commit sounds fine. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building under Windows
I use MinGW cross compilation exclusively, so never run into this issue. However, I use scons w/ MSVC and this nevers happens, because scons passes options to MS lib/link via a option file. GNU ar too, supports this, so it is probably just a matter of teaching scons to use option files to GNU ar too. Jose - Original Message - > I am trying to build with LLVM under windows. Using SCons and MinGW. > After solving some basic problems with llvm-config and applying the > patches for 8.0.3 most things are going OK. > > Until it is time to generate the libgallium.a library. The "ar" > command > to build this library is over 10kBytes long, and windows has a hard > limit of 8kB for commands in the terminal window. > > So the build halts with "command line too long". > > I can manually edit the command and replace a lot of specific > build/windows-x86/gallium/auxiliary/xxx/yyy.o filenames with *.o > wildcards, which makes the command much shorter, run it manually, and > then it works. This doesn't help me however, since SCons doesn't like > the manually generated libgallium.a file, and deletes it and tries to > build a new one, which then fails. > > Any ideas how I can get passed this and have the build continue? I > just > want to build a working llvmpipe driver for a performance test. > /jesper > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Do not build glx on Solaris.
On 06/20/2012 04:18 AM, Jose Fonseca wrote:
- Original Message -
On 06/19/2012 11:34 PM, Vinson Lee wrote:
The GLX headers on Solaris are not recent enough.
Signed-off-by: Vinson Lee
---
src/SConscript |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/SConscript b/src/SConscript
index 75c4446..f55a20e 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -23,7 +23,7 @@ SConscript('mesa/SConscript')
SConscript('mapi/vgapi/SConscript')
if not env['embedded']:
-if env['platform'] not in ('cygwin', 'darwin', 'freebsd',
'haiku', 'windows'):
+if env['platform'] not in ('cygwin', 'darwin', 'freebsd',
'haiku', 'sunos', 'windows'):
SConscript('glx/SConscript')
if env['platform'] not in ['darwin', 'haiku', 'sunos']:
SConscript('egl/main/SConscript')
It doesn't sound very useful to build Mesa on Solaris without GLX
support. I guess you could use EGL, but...most existing apps use
GLX,
so I imagine not much would run...
That said, I don't use Solaris nor SCons, so it's not really my place
to
say...
I agree. I don't know what's the end goal of Solaris support, but I can't see
much use to build on Solaris without GLX.
Mesa already ships some glx headers, so maybe a better solution would be to
ensure that they are included before system headers on scons.
There's two GLX implementations: the "real" one in src/glx/ and the
"fake" one built on Xlib in src/gallium/state_trackers/glx/xlib/ (or
src/mesa/drivers/xlib).
If you're only going to use software drivers, the fake glx is sufficient.
Vinson, I think we're curious what the goal is for Solaris support.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/9] mesa: Add support for glGetIntegeri_v from GL_ARB_uniform_buffer_object.
On Tue, Jun 19, 2012 at 3:26 PM, Eric Anholt wrote: > On Tue, 19 Jun 2012 08:10:25 -0600, Brian Paul wrote: >> On 06/18/2012 07:35 PM, Eric Anholt wrote: >> > Fixes piglit ARB_uniform_buffer_object/getintegeri_v. >> > --- >> > src/mesa/main/get.c | 24 >> > 1 file changed, 24 insertions(+) >> > >> > diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c >> > index 933bfe7..4798c02 100644 >> > --- a/src/mesa/main/get.c >> > +++ b/src/mesa/main/get.c >> > @@ -2566,6 +2566,30 @@ find_value_indexed(const char *func, GLenum pname, >> > int index, union value *v) >> > goto invalid_enum; >> > v->value_int = >> > ctx->TransformFeedback.CurrentObject->BufferNames[index]; >> > return TYPE_INT; >> > + >> > + case GL_UNIFORM_BUFFER_BINDING: >> > + if (index>= ctx->Const.MaxUniformBufferBindings) >> > + goto invalid_value; >> > + if (!ctx->Extensions.ARB_uniform_buffer_object) >> > + goto invalid_enum; >> >> I think it's a bit more natural to do the extension check before the >> index check. > > Since all the other enums are handled in this order, too, I'd rather > that be an independent change. It does seem like a silly ordering, > though. You can use the "extra" mechanism to check the extension automatically before even getting into find_value_indexed. Add: EXTRA_EXT(ARB_uniform_buffer_object); and then add &extra_ARB_uniform_buffer_object instead of NO_EXTRA where the token is defined. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/9] mesa: Add support for glGetIntegeri_v from GL_ARB_uniform_buffer_object.
On 06/20/2012 08:00 AM, Kristian Høgsberg wrote: On Tue, Jun 19, 2012 at 3:26 PM, Eric Anholt wrote: On Tue, 19 Jun 2012 08:10:25 -0600, Brian Paul wrote: On 06/18/2012 07:35 PM, Eric Anholt wrote: Fixes piglit ARB_uniform_buffer_object/getintegeri_v. --- src/mesa/main/get.c | 24 1 file changed, 24 insertions(+) diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c index 933bfe7..4798c02 100644 --- a/src/mesa/main/get.c +++ b/src/mesa/main/get.c @@ -2566,6 +2566,30 @@ find_value_indexed(const char *func, GLenum pname, int index, union value *v) goto invalid_enum; v->value_int = ctx->TransformFeedback.CurrentObject->BufferNames[index]; return TYPE_INT; + + case GL_UNIFORM_BUFFER_BINDING: + if (index>= ctx->Const.MaxUniformBufferBindings) +goto invalid_value; + if (!ctx->Extensions.ARB_uniform_buffer_object) +goto invalid_enum; I think it's a bit more natural to do the extension check before the index check. Since all the other enums are handled in this order, too, I'd rather that be an independent change. It does seem like a silly ordering, though. You can use the "extra" mechanism to check the extension automatically before even getting into find_value_indexed. Add: EXTRA_EXT(ARB_uniform_buffer_object); and then add&extra_ARB_uniform_buffer_object instead of NO_EXTRA where the token is defined. Actually, it looks like check_extra() isn't called for the indexed glGet functions. find_value_indexed() isn't using any sort of table for its implementation. There aren't too many indexed queries yet but maybe someone should take a look at that. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Do not build glx on Solaris.
On 06/19/12 11:34 PM, Vinson Lee wrote: > The GLX headers on Solaris are not recent enough. Huh? Which Solaris? Solaris 11 ships with X.Org's glproto 1.4.10 - how new do you need? Or what headers do you need if not glproto? (Not that I know anyone who uses scons, so maybe this doesn't matter.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] softpipe: Take all lods into account when texture sampling.
On 06/20/2012 06:39 AM, Roland Scheidegger wrote: On 06/20/2012 05:43 AM, Olivier Galibert wrote: On Tue, Jun 19, 2012 at 02:46:35PM -0700, Jose Fonseca wrote: Could you give more background on why is this necessary? This will make software renderering slower, so I'd really like to avoid it on llvmpipe if at all possible. Well, given the existence of textureLod and textureGrad every texture sample can easily hit a different mipmap or even, by switching between minification and magnification, a different filter entirely. Even a simple texture() is hit, if your polygon is horizontal enough. And this goes double for vertex shaders, where texture fetches there have less reason to be close in texture space. textureSize and textureFetch, with their explicit lod, have of course the same problem. only worse. If I see that right, this only really affects sampling with either (per-pixel) lodbias, explicit lod or explicit gradients. For "normal" texture sampling results shouldn't change since rho/lambda (which determines lod) is per-quad. In this case I think we'd want to split the fetch functions in llvmpipe if any of that is present, since this is going to require per-pixel lookups of mip level offsets at least. Also, min/mag filter selection needs to be handled different in this case too (doing this with per-pixel branch code isn't really an option) - maybe keep the branch to choose between min/mag filter if all pixels use the same filter, and use some hacked-up linear path instead if not which forces weights for the pixels using nearest to the appropriate value. Sounds like a lot of effort though. In any case for softpipe performance isn't as critical, though I'm curious if it makes a large performance difference for "ordinary" texture sampling (in which case things could be split as well, though I guess for softpipe code simplicity wins over faster code). Otherwise this looks like the right thing to do in principle to me, though I'd like to hear Brian's opinion on that too. Yeah, I think it's pretty clear that we need to support per-pixel LOD selection. For softpipe, Olivier's big patch looks good. For llvmpipe it's important to maintain performance for the common case where we compute LOD per quad but we'll also need new paths for per-pixel LOD. Hopefully, the two paths can share some code. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Add glsl/glcpp to the include path.
On 06/20/2012 12:15 AM, Vinson Lee wrote:
Fixes this build failure on Solaris.
Compiling build/sunos-debug/glsl/glcpp/glcpp-lex.c ...
"src/glsl/glcpp/glcpp-lex.l", line 30: cannot find include file: "glcpp-parse.h"
Signed-off-by: Vinson Lee
---
src/glsl/SConscript |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/SConscript b/src/glsl/SConscript
index f8e8723..2fc57c6 100644
--- a/src/glsl/SConscript
+++ b/src/glsl/SConscript
@@ -14,8 +14,8 @@ env.Prepend(CPPPATH = [
'#src/glsl/glcpp',
])
-# Make glcpp/glcpp-parse.h and glsl_parser.h reacheable from the include path
-env.Append(CPPPATH = [Dir('.').abspath])
+# Make glcpp-parse.h and glsl_parser.h reachable from the include path.
+env.Append(CPPPATH = [Dir('.').abspath, Dir('glcpp').abspath])
env.Append(YACCFLAGS = '-d')
Looks OK to me.
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/9] mesa: Add support for glGetIntegeri_v from GL_ARB_uniform_buffer_object.
On Wed, Jun 20, 2012 at 10:11 AM, Brian Paul wrote: > On 06/20/2012 08:00 AM, Kristian Høgsberg wrote: >> >> On Tue, Jun 19, 2012 at 3:26 PM, Eric Anholt wrote: >>> >>> On Tue, 19 Jun 2012 08:10:25 -0600, Brian Paul wrote: On 06/18/2012 07:35 PM, Eric Anholt wrote: > > Fixes piglit ARB_uniform_buffer_object/getintegeri_v. > --- > src/mesa/main/get.c | 24 > 1 file changed, 24 insertions(+) > > diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c > index 933bfe7..4798c02 100644 > --- a/src/mesa/main/get.c > +++ b/src/mesa/main/get.c > @@ -2566,6 +2566,30 @@ find_value_indexed(const char *func, GLenum > pname, int index, union value *v) > goto invalid_enum; > v->value_int = > ctx->TransformFeedback.CurrentObject->BufferNames[index]; > return TYPE_INT; > + > + case GL_UNIFORM_BUFFER_BINDING: > + if (index>= ctx->Const.MaxUniformBufferBindings) > + goto invalid_value; > + if (!ctx->Extensions.ARB_uniform_buffer_object) > + goto invalid_enum; I think it's a bit more natural to do the extension check before the index check. >>> >>> >>> Since all the other enums are handled in this order, too, I'd rather >>> that be an independent change. It does seem like a silly ordering, >>> though. >> >> >> You can use the "extra" mechanism to check the extension automatically >> before even getting into find_value_indexed. Add: >> >> EXTRA_EXT(ARB_uniform_buffer_object); >> >> and then add&extra_ARB_uniform_buffer_object instead of NO_EXTRA >> >> where the token is defined. > > > Actually, it looks like check_extra() isn't called for the indexed glGet > functions. find_value_indexed() isn't using any sort of table for its > implementation. There aren't too many indexed queries yet but maybe someone > should take a look at that. Hm, yea, I even wrote that code myself, apparently. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] softpipe: Take all lods into account when texture sampling.
- Original Message - > On 06/20/2012 06:39 AM, Roland Scheidegger wrote: > > On 06/20/2012 05:43 AM, Olivier Galibert wrote: > >> On Tue, Jun 19, 2012 at 02:46:35PM -0700, Jose Fonseca wrote: > >>> Could you give more background on why is this necessary? > >>> > >>> This will make software renderering slower, so I'd really like to > >>> avoid it on llvmpipe if at all possible. > >> > >> Well, given the existence of textureLod and textureGrad every > >> texture > >> sample can easily hit a different mipmap or even, by switching > >> between > >> minification and magnification, a different filter entirely. Even > >> a > >> simple texture() is hit, if your polygon is horizontal enough. > >> > >> And this goes double for vertex shaders, where texture fetches > >> there > >> have less reason to be close in texture space. > >> > >> textureSize and textureFetch, with their explicit lod, have of > >> course > >> the same problem. only worse. > > > > If I see that right, this only really affects sampling with either > > (per-pixel) lodbias, explicit lod or explicit gradients. For > > "normal" > > texture sampling results shouldn't change since rho/lambda (which > > determines lod) is per-quad. > > > > In this case I think we'd want to split the fetch functions in > > llvmpipe if any of that is present, since this is going to require > > per-pixel lookups of mip level offsets at least. Also, min/mag > > filter > > selection needs to be handled different in this case too (doing > > this > > with per-pixel branch code isn't really an option) - maybe keep the > > branch to choose between min/mag filter if all pixels use the same > > filter, and use some hacked-up linear path instead if not which > > forces > > weights for the pixels using nearest to the appropriate value. > > Sounds > > like a lot of effort though. > > > > In any case for softpipe performance isn't as critical, though I'm > > curious if it makes a large performance difference for "ordinary" > > texture sampling (in which case things could be split as well, > > though > > I guess for softpipe code simplicity wins over faster code). > > > > Otherwise this looks like the right thing to do in principle to me, > > though I'd like to hear Brian's opinion on that too. > > Yeah, I think it's pretty clear that we need to support per-pixel LOD > selection. I haven't read the relevant specs, but with such agreement I'm more than convinced. > For softpipe, Olivier's big patch looks good. For > llvmpipe it's important to maintain performance for the common case > where we compute LOD per quad but we'll also need new paths for > per-pixel LOD. Hopefully, the two paths can share some code. Yes, I think it should be possible to accomodate both cases with common code. On x86_64 bits w/ SSE/AVX, a vector of pointers is innefficient -- it's better to use scalar 64bit pointer plus a vector of 32bit offsets. Therefore, for efficient per-pixel llvmpipe, we should allocate whole resource tree (all faces/levels/slices) with a single malloc. draw module is used by many other drivers, so it probably can't make such assumption, but vertex shading seldom is a bottleneck anyway. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Fix brw_swap_cmod() for LE/GE comparisons.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/16/2012 02:20 AM, Kenneth Graunke wrote:
> The idea here is to rewrite comparisons like 2 >= x with x <= 2; we want to
> simply exchange arguments, not negate
> the condition. If equality was part of the original comparison, it should
> remain part of the swapped version.
>
> This is the true cause of bug #50298. It didn't manifest itself on
> Sandybridge because we embed the conditional
> modifier in the IF instruction rather than emitting a CMP. All other
> platforms use CMP.
>
> It also didn't manifest itself on the master branch because commit be5f27a84d
> ("glsl: Refine the loop instruction
> counting.") papered over the problem.
>
> NOTE: This is a candidate for stable release branches.
>
> Cc: Eric Anholt Cc: Chad Versace
> Bugzilla:
> https://bugs.freedesktop.org/show_bug.cgi?id=50298 Signed-off-by: Kenneth
> Graunke ---
> src/mesa/drivers/dri/i965/brw_eu.c |8 1 file changed, 4
> insertions(+), 4 deletions(-)
Oh, wow...
Reviewed-by: Chad Versace
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJP4ghCAAoJEAIvNt057x8iGrsP/j6iqPbU6wctahvRXuf4JOe8
YW/3jSKSS33JBIjqoWgJG4QdF3kQ+Pvd4KkvKqNIb4exErUVRQLeNodJPakyrkIC
dSyPUPepzfCK2H+iECcBd+Xtok1C71IrP1YCJxc0yH/hZSGYwxtMJzUdMX80e6oQ
mkyz3VvBu7dwpiZdGdaPK3nSEnCV9EYLdEKRfPuHj2mKd3KLuEYei5EAJST6rvlB
cDRLQ5nFe1JdruhXOJADL9Wc4rwSnHg2AFT/jhoi5q4mEGq6eU6yPL0G6n+bnc/c
0HS4TcOuQK3jMyZ997+8VhwmniqIqrZQYil+IvLDpJmZs76OZ0KiTHpsjY8L57bE
6jpUcF9r9EPslBE6ikNo2IXV+cFx+FbiGX3Hmzt7jsKw/iRnfY6LkG3rgrxsANqm
9DbMg3wi8o8ZbM0bD6Tn0ZVNcRNKy0O2jpbFASbUDawuvQ1suxoMg5/EAEOZ2xj7
FVwj44nQGWFaWmc9AsmMJJ8lbF/uH2WeToyRiyorjnaZhb2hIZhND4dzPF3hRmDm
k0egahLF+vAHo7dwr0ZnIRp+uD0bjtwYPZigQrwIQmYKvl2QNtu8oiCq3bLe55g3
qhm7fvlZMuu6O/uLScheiwjprhygwI8Qfy0VV54ym28cpOQluSmVhBFP0eGRdTe1
qE/R/GdSK1Wqmb7gPqAl
=UfrR
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Compute dFdy() correctly for FBOs.
On i965, dFdx() and dFdy() are computed by taking advantage of the
fact that each consecutive set of 4 pixels dispatched to the fragment
shader always constitutes a contiguous 2x2 block of pixels in a fixed
arrangement known as a "sub-span". So we calculate dFdx() by taking
the difference between the values computed for the left and right
halves of the sub-span, and we calculate dFdy() by taking the
difference between the values computed for the top and bottom halves
of the sub-span.
However, there's a subtlety when FBOs are in use: since FBOs use a
coordinate system where the origin is at the upper left, and window
system framebuffers use a coordinate system where the origin is at the
lower left, the computation of dFdy() needs to be negated for FBOs.
This patch modifies the fragment shader back-ends to negate the value
of dFdy() when an FBO is in use. It also modifies the code that
populates the program key (brw_wm_populate_key() and
brw_fs_precompile()) so that they always record in the program key
whether we are rendering to an FBO or to a window system framebuffer;
this ensures that the fragment shader will get recompiled when
switching between FBO and non-FBO use.
This will result in unnecessary recompiles of fragment shaders that
don't use dFdy(). To fix that, we will need to adapt the GLSL and
NV_fragment_program front-ends to record whether or not a given shader
uses dFdy(). I plan to implement this in a future patch series; I've
left FIXME comments in the code as a reminder.
Fixes Piglit test "fbo-deriv".
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 10 ++
src/mesa/drivers/dri/i965/brw_fs.h|3 ++-
src/mesa/drivers/dri/i965/brw_fs_emit.cpp | 14 +++---
src/mesa/drivers/dri/i965/brw_wm.c| 10 ++
src/mesa/drivers/dri/i965/brw_wm.h|3 ++-
src/mesa/drivers/dri/i965/brw_wm_emit.c | 15 +++
6 files changed, 46 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 313e720..43efd68 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1848,6 +1848,13 @@ brw_fs_precompile(struct gl_context *ctx, struct
gl_shader_program *prog)
struct brw_context *brw = brw_context(ctx);
struct brw_wm_prog_key key;
+ /* As a temporary measure we assume that all programs use dFdy() (and hence
+* need to be compiled differently depending on whether we're rendering to
+* an FBO). FIXME: set this bool correctly based on the contents of the
+* program.
+*/
+ bool program_uses_dfdy = true;
+
if (!prog->_LinkedShaders[MESA_SHADER_FRAGMENT])
return true;
@@ -1892,6 +1899,9 @@ brw_fs_precompile(struct gl_context *ctx, struct
gl_shader_program *prog)
if (fp->Base.InputsRead & FRAG_BIT_WPOS) {
key.drawable_height = ctx->DrawBuffer->Height;
+ }
+
+ if ((fp->Base.InputsRead & FRAG_BIT_WPOS) || program_uses_dfdy) {
key.render_to_fbo = _mesa_is_user_fbo(ctx->DrawBuffer);
}
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 0c6c3e4..2c2cb6c 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -534,7 +534,8 @@ public:
struct brw_reg src);
void generate_discard(fs_inst *inst);
void generate_ddx(fs_inst *inst, struct brw_reg dst, struct brw_reg src);
- void generate_ddy(fs_inst *inst, struct brw_reg dst, struct brw_reg src);
+ void generate_ddy(fs_inst *inst, struct brw_reg dst, struct brw_reg src,
+ bool negate_value);
void generate_spill(fs_inst *inst, struct brw_reg src);
void generate_unspill(fs_inst *inst, struct brw_reg dst);
void generate_pull_constant_load(fs_inst *inst, struct brw_reg dst);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
index 522123c..0881ad7 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
@@ -441,8 +441,13 @@ fs_visitor::generate_ddx(fs_inst *inst, struct brw_reg
dst, struct brw_reg src)
brw_ADD(p, dst, src0, negate(src1));
}
+/* The negate_value boolean is used to negate the derivative computation for
+ * FBOs, since they place the origin at the upper left instead of the lower
+ * left.
+ */
void
-fs_visitor::generate_ddy(fs_inst *inst, struct brw_reg dst, struct brw_reg src)
+fs_visitor::generate_ddy(fs_inst *inst, struct brw_reg dst, struct brw_reg src,
+ bool negate_value)
{
struct brw_reg src0 = brw_reg(src.file, src.nr, 0,
BRW_REGISTER_TYPE_F,
@@ -456,7 +461,10 @@ fs_visitor::generate_ddy(fs_inst *inst, struct brw_reg
dst, struct brw_reg src)
BRW_WIDTH_4,
BRW_HORIZONTAL_STRIDE_0,
BRW_SWIZZLE_XYZW, WRITEMASK_XYZW
