headers
Paul Berry | 1 Nov 2011 01:44
Picon
Gravatar

[PATCH 1/2] mesa: Set the "Integer" field of gl_client_array properly.

This patch ensures that gl_client_array::Integer is properly set to
GL_TRUE for vertex attributes specified using glVertexAttribIPointer,
and to GL_FALSE for vertex attributes specified using
glVertexAttribPointer, so that the vertex attributes can be
interpreted properly by driver back-ends.
---
 src/mesa/main/arrayobj.c      |    1 +
 src/mesa/main/varray.c        |    1 +
 src/mesa/vbo/vbo_split_copy.c |    1 +
 3 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index 78f56ab..1283940 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
 <at>  <at>  -208,6 +208,7  <at>  <at>  init_array(struct gl_context *ctx,
    array->Ptr = NULL;
    array->Enabled = GL_FALSE;
    array->Normalized = GL_FALSE;
+   array->Integer = GL_FALSE;
    array->_ElementSize = size * _mesa_sizeof_type(type);
 #if FEATURE_ARB_vertex_buffer_object
    /* Vertex array buffers */
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 13b3405..f1a57c1 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
 <at>  <at>  -212,6 +212,7  <at>  <at>  update_array(struct gl_context *ctx,
    array->Stride = stride;
    array->StrideB = stride ? stride : elementSize;
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Berry | 1 Nov 2011 01:44
Picon
Gravatar

[PATCH 2/2] i965: Add support for integral vertex attributes.

When a vertex shader input attribute is declared with an integral type
(e.g. ivec4), we need to ensure that the generated vertex shader code
addresses the vertex attribute register using the proper register
type.  (Previously, we assumed all vertex shader input attributes were
floating-point).

In addition, when uploading vertex data that was specified with
VertexAttribIPointer, we need to instruct the vertex fetch unit to
convert the data to signed or unsigned int, rather than float.  And
when filling in the implied w=1 on a vector with less than 4
components, we need to fill it in with the integer representation of 1
rather than the floating-point representation of 1.

Fixes piglit tests vs-attrib-{ivec4,uvec4}-precision.
---
 src/mesa/drivers/dri/i965/brw_draw_upload.c    |   69 ++++++++++++++++++++++--
 src/mesa/drivers/dri/i965/brw_vec4_emit.cpp    |    1 +
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |    1 +
 3 files changed, 67 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index b7ae4cd..db0cb18 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
 <at>  <at>  -65,6 +65,14  <at>  <at>  static GLuint half_float_types[5] = {
    BRW_SURFACEFORMAT_R16G16B16A16_FLOAT
 };

+static GLuint uint_types_direct[5] = {
+   0,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Romanick | 1 Nov 2011 02:07

[PATCH 2/4] glsl: Put all bitfields in ir_variable together for better packing

From: Ian Romanick <ian.d.romanick <at> intel.com>

The diff looks weird because ir_variable::depth_layout was between the
last two bitfields in the structure.

Signed-off-by: Ian Romanick <ian.d.romanick <at> intel.com>
---
 src/glsl/ir.h |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 404d4cf..abbf455 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
 <at>  <at>  -356,14 +356,6  <at>  <at>  public:
    /* <at> }*/

    /**
-    * \brief Layout qualifier for gl_FragDepth.
-    *
-    * This is not equal to \c ir_depth_layout_none if and only if this
-    * variable is \c gl_FragDepth and a layout qualifier is specified.
-    */
-   ir_depth_layout depth_layout;
-
-   /**
     * Was the location explicitly set in the shader?
     *
     * If the location is explicitly set in the shader, it \b cannot be changed
 <at>  <at>  -373,6 +365,14  <at>  <at>  public:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Romanick | 1 Nov 2011 02:07

[PATCH 3/4] glsl: Refactor generate_ARB_draw_buffers_variables to use add_builtin_constant

From: Ian Romanick <ian.d.romanick <at> intel.com>

Signed-off-by: Ian Romanick <ian.d.romanick <at> intel.com>
---
 src/glsl/ir_variable.cpp |   11 ++++-------
 1 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/src/glsl/ir_variable.cpp b/src/glsl/ir_variable.cpp
index 1ee84d2..bea0b2b 100644
--- a/src/glsl/ir_variable.cpp
+++ b/src/glsl/ir_variable.cpp
 <at>  <at>  -400,7 +400,7  <at>  <at>  add_builtin_variable(exec_list *instructions, glsl_symbol_table *symtab,
    }
 }

-static void
+static ir_variable *
 add_builtin_constant(exec_list *instructions, glsl_symbol_table *symtab,
 		     const char *name, int value)
 {
 <at>  <at>  -408,6 +408,7  <at>  <at>  add_builtin_constant(exec_list *instructions, glsl_symbol_table *symtab,
 					 name, glsl_type::int_type,
 					 ir_var_auto, -1);
    var->constant_value = new(var) ir_constant(value);
+   return var;
 }

 /* Several constants in GLSL ES have different names than normal desktop GLSL.
 <at>  <at>  -749,16 +750,12  <at>  <at>  generate_ARB_draw_buffers_variables(exec_list *instructions,
    /* gl_MaxDrawBuffers is available in all shader stages.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ian Romanick | 1 Nov 2011 02:07

[PATCH 1/4] linker: Fix the indentation of a block in cross_validate_globals

From: Ian Romanick <ian.d.romanick <at> intel.com>

I suspect the indentation got messed up during a code merge.

Signed-off-by: Ian Romanick <ian.d.romanick <at> intel.com>
---
 src/glsl/linker.cpp |   57 ++++++++++++++++++++++++++++----------------------
 1 files changed, 32 insertions(+), 25 deletions(-)

diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index beadec6..a595c9c 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
 <at>  <at>  -415,31 +415,38  <at>  <at>  cross_validate_globals(struct gl_shader_program *prog,
 	       existing->explicit_location = true;
 	    }

-        /* Validate layout qualifiers for gl_FragDepth.
-         *
-         * From the AMD/ARB_conservative_depth specs:
-         *    "If gl_FragDepth is redeclared in any fragment shader in
-         *    a program, it must be redeclared in all fragment shaders in that
-         *    program that have static assignments to gl_FragDepth. All
-         *    redeclarations of gl_FragDepth in all fragment shaders in
-         *    a single program must have the same set of qualifiers."
-         */
-        if (strcmp(var->name, "gl_FragDepth") == 0) {
-           bool layout_declared = var->depth_layout != ir_depth_layout_none;
-           bool layout_differs = var->depth_layout != existing->depth_layout;
-           if (layout_declared && layout_differs) {
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ian Romanick | 1 Nov 2011 02:07

[PATCH 4/4] linker: Check that initializers for global variables match

From: Ian Romanick <ian.d.romanick <at> intel.com>

This requires tracking a couple extra fields in ir_variable:

 * A flag to indicate that a variable had an initializer.

 * For non-const variables, a field to track the constant value of the
   variable's initializer.

For variables non-constant initalizers, ir_variable::has_initializer
will be true, but ir_variable::constant_initializer will be NULL.  The
linker can use the values of these fields to check adherence to the
GLSL 4.20 rules for shared global variables:

    "If a shared global has multiple initializers, the initializers
    must all be constant expressions, and they must all have the same
    value. Otherwise, a link error will result. (A shared global
    having only one initializer does not require that initializer to
    be a constant expression.)"

Previous to 4.20 the GLSL spec simply said that initializers must have
the same value.  In this case of non-constant initializers, this was
impossible to determine.  As a result, no vendor actually implemented
that behavior.  The 4.20 behavior matches the behavior of NVIDIA's
shipping implementations.

NOTE: This is candidate for the 7.11 branch.  This patch also needs
the preceding patch "glsl: Refactor generate_ARB_draw_buffers_variables
to use add_builtin_constant"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Berry | 1 Nov 2011 04:34
Picon
Gravatar

[PATCH] glsl: Fix type mismatch when incrementing or decrementing uint.

When converting an expression like "++x" to GLSL IR we were failing to
account for the possibility that x might be an unsigned integral type.
As a result the user would receive a bogus error message "Could not
implicitly convert operands to arithmetic operator".

Fixes piglit tests {vs,fs}-{increment,decrement}-uint.
---
 src/glsl/ast_to_hir.cpp |   31 +++++++++++++++++++++++--------
 1 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 7584fdf..a4eec50 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
 <at>  <at>  -935,6 +935,27  <at>  <at>  check_builtin_array_max_size(const char *name, unsigned size,
    return false;
 }

+/**
+ * Create the constant 1, with the given GLSL type, for use in increment and
+ * decrement operators.
+ *
+ * If the given type is invalid for increment and decrement operators, return
+ * a floating point 1--the error will be detected later.
+ */
+static ir_rvalue *
+constant_one_for_inc_dec(void *ctx, const glsl_type *type)
+{
+   switch (type->base_type) {
+   case GLSL_TYPE_UINT:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chia-I Wu | 1 Nov 2011 04:39
Picon

Re: [RFC-PATCH 00/11] add support for GL_OES_EGL_image_external

On Mon, Oct 31, 2011 at 11:46 PM, Eric Anholt <eric <at> anholt.net> wrote:
> On Mon, 31 Oct 2011 03:07:26 +0800, Chia-I Wu <olvaffe <at> gmail.com> wrote:
>> From: Chia-I Wu <olv <at> lunarg.com>
>>
>> Hi,
>>
>> This patch series adds support for the OpenGL ES specific
>> GL_OES_EGL_image_external extension[1].  It is enabled in st/mesa.
>
>> The extension is written with YUV formats in mind.  It describes two possible
>> ways to to support them.  One is to insert extra instructions to the shaders
>> to let GPU perform the necessary color conversions on the fly.  The other is
>> to allocate an internal storage to perform the conversions when the EGLImage
>> is specified.  Neither is supported for this series.  It effectively makes the
>> implementation a subset of GL_OES_EGL_image function-wise.
>
> Both of these options are why I hated the idea of this extension.
>
> If the application wants to do YUV conversion, it should be doing YUV
> conversion.  We give them access to shaders for a reason.  Hiding the
> interaction between planar YUV and actual texture units is going to be
> miserable.
I agree.  But I think the design of this extension just chooses a
clean, maybe oversimplified, API over a clean implementation.

EGLImage is designed to be a completely opaque object.  Its pixel
format or any other property is unknown and unknownable.  To be able
to sample from an EGLImage, you either define the return values to be
always RGBA as is done in this extension, or to export its pixel
format in some sense after it is bound to a texture.  The former
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chia-I Wu | 1 Nov 2011 04:48
Picon

Re: [RFC-PATCH 00/11] add support for GL_OES_EGL_image_external

On Mon, Oct 31, 2011 at 10:16 PM, Jakob Bornecrantz <jakob <at> vmware.com> wrote:
> ----- Original Message -----
>> From: Chia-I Wu <olv <at> lunarg.com>
>>
>> Hi,
>>
>> This patch series adds support for the OpenGL ES specific
>> GL_OES_EGL_image_external extension[1].  It is enabled in st/mesa.
>>
>> The extension adds a new texture target, GL_TEXTURE_EXTERNAL_OES.  It
>> can only be specified with an EGLImage.  Calling gl*Tex*Image* to
>> manipulate an external texture will result in GL_INVALID_ENUM.
>> Because of the restrictions, it allows formats that are not otherwise
>> supported to be sampled from.
>>
>> The extension is written with YUV formats in mind.  It describes two
>> possible ways to to support them.  One is to insert extra
>> instructions to the shaders to let GPU perform the necessary color
>> conversions on the fly.  The other is to allocate an internal storage
>> to perform the conversions when the EGLImage is specified.  Neither
>> is supported for this series.  It effectively makes the
>> implementation a subset of GL_OES_EGL_image function-wise.
>>
>> Later, I plan to adopt the latter, also easier, approach to support
>> NV21 and YV12 formats[2] (for Android, but haven't started).  The
>> changes will be limitied to the winsys code.  The idea is that the
>> pixel format of an EGLImage is winsys dependent.  There are too
>> many formats, well defined or not, to be enumerated in pipe_format
>> or gl_format.
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chia-I Wu | 1 Nov 2011 05:00
Picon

Re: [PATCH 1/3] glsl: Refactor source lists to Makefile.sources

On Mon, Oct 31, 2011 at 9:52 PM, Brian Paul <brianp <at> vmware.com> wrote:
>
> [...]
>
> Maybe call this file sources.mak to match src/mesa/sources.mak
It is already named Makefile.sources in several other places (that was
me too...).  To try to justify the inconsistency, the file differs
from sources.mak in that it is only for source listing, and could not
use variables defined elsewhere such as $(TOP) or $(MESA_ASM_SOURCES).

> Otherwise, looks good to me.
>
> Reviewed-by: Brian Paul <brianp <at> vmware.com>
>
>

--

-- 
olv <at> LunarG.com
Permalink | Reply | 0 comments |

Gmane