Re: [Mesa-dev] [PATCH 3/3] glsl: Update builtin variables for GLSL 1.40.

2012-03-12 Thread Kenneth Graunke 

On 03/09/2012 01:27 PM, Eric Anholt wrote:

Mostly this is a matter of removing variables that have been moved to
the compatibility profile.  There's one addition: gl_InstanceID is
present in the core now.

This fixes the new piglit tests for GLSL 1.40 builtins.
---
  src/glsl/builtin_variables.cpp |  259 +++-
  1 files changed, 150 insertions(+), 109 deletions(-)

diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 26deeeb..516a69c 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -528,25 +528,30 @@ generate_100ES_uniforms(exec_list *instructions,

  static void
  generate_110_uniforms(exec_list *instructions,
- struct _mesa_glsl_parse_state *state)
+ struct _mesa_glsl_parse_state *state,
+ bool add_deprecated)
  {
 glsl_symbol_table *const symtab = state->symbols;

-   for (unsigned i = 0
-  ; i<  Elements(builtin_110_deprecated_uniforms)
-  ; i++) {
-  add_builtin_variable(instructions, symtab,
-   &  builtin_110_deprecated_uniforms[i]);
+   if (add_deprecated) {
+  for (unsigned i = 0
+ ; i<  Elements(builtin_110_deprecated_uniforms)
+ ; i++) {
+add_builtin_variable(instructions, symtab,
+   &  builtin_110_deprecated_uniforms[i]);
+  }
 }

-   add_builtin_constant(instructions, symtab, "gl_MaxLights",
-   state->Const.MaxLights);
-   add_builtin_constant(instructions, symtab, "gl_MaxClipPlanes",
-   state->Const.MaxClipPlanes);
-   add_builtin_constant(instructions, symtab, "gl_MaxTextureUnits",
-   state->Const.MaxTextureUnits);
-   add_builtin_constant(instructions, symtab, "gl_MaxTextureCoords",
-   state->Const.MaxTextureCoords);
+   if (add_deprecated) {
+  add_builtin_constant(instructions, symtab, "gl_MaxLights",
+  state->Const.MaxLights);


I can't find gl_MaxLights defined in 1.30 or 1.40.  I agree that it 
makes sense to drop it as it pertains to fixed-function lighting.



+  add_builtin_constant(instructions, symtab, "gl_MaxClipPlanes",
+  state->Const.MaxClipPlanes);
+  add_builtin_constant(instructions, symtab, "gl_MaxTextureUnits",
+  state->Const.MaxTextureUnits);


gl_MaxTextureUnits is not deprecated.  (See GLSL 1.40.08 section 7.4. 
Note the lack of "// Deprecated" comment.)



+  add_builtin_constant(instructions, symtab, "gl_MaxTextureCoords",
+  state->Const.MaxTextureCoords);
+   }
 add_builtin_constant(instructions, symtab, "gl_MaxVertexAttribs",
state->Const.MaxVertexAttribs);
 add_builtin_constant(instructions, symtab, "gl_MaxVertexUniformComponents",
@@ -562,65 +567,69 @@ generate_110_uniforms(exec_list *instructions,
 add_builtin_constant(instructions, symtab, 
"gl_MaxFragmentUniformComponents",
state->Const.MaxFragmentUniformComponents);

-   const glsl_type *const mat4_array_type =
-  glsl_type::get_array_instance(glsl_type::mat4_type,
-   state->Const.MaxTextureCoords);
+   if (add_deprecated) {
+  const glsl_type *const mat4_array_type =
+glsl_type::get_array_instance(glsl_type::mat4_type,
+  state->Const.MaxTextureCoords);

-   add_uniform(instructions, symtab, "gl_TextureMatrix", mat4_array_type);
-   add_uniform(instructions, symtab, "gl_TextureMatrixInverse", 
mat4_array_type);
-   add_uniform(instructions, symtab, "gl_TextureMatrixTranspose", 
mat4_array_type);
-   add_uniform(instructions, symtab, "gl_TextureMatrixInverseTranspose", 
mat4_array_type);
+  add_uniform(instructions, symtab, "gl_TextureMatrix", mat4_array_type);
+  add_uniform(instructions, symtab, "gl_TextureMatrixInverse", 
mat4_array_type);
+  add_uniform(instructions, symtab, "gl_TextureMatrixTranspose", 
mat4_array_type);
+  add_uniform(instructions, symtab, "gl_TextureMatrixInverseTranspose", 
mat4_array_type);
+   }

 add_uniform(instructions, symtab, "gl_DepthRange",
symtab->get_type("gl_DepthRangeParameters"));

-   add_uniform(instructions, symtab, "gl_ClipPlane",
-  glsl_type::get_array_instance(glsl_type::vec4_type,
-state->Const.MaxClipPlanes));
-   add_uniform(instructions, symtab, "gl_Point",
-  symtab->get_type("gl_PointParameters"));
-
-   const glsl_type *const material_parameters_type =
-  symtab->get_type("gl_MaterialParameters");
-   add_uniform(instructions, symtab, "gl_FrontMaterial", 
material_parameters_type);
-   add_uniform(instructions, symtab, "gl_BackMaterial", 
material_parameters_type);
-
-   const glsl_type *const light_source_array_type =
-  glsl_type::get_array_i

Re: [Mesa-dev] Initial pieces of GLSL 1.40

2012-03-12 Thread Kenneth Graunke 

On 03/09/2012 01:27 PM, Eric Anholt wrote:

For the tests I've run this through, and a list of what I know is
remaining, see:

http://lists.freedesktop.org/archives/piglit/2012-March/002003.html

All but the discard infinite loop test work on i965 with this series.


I haven't looked at the Piglit tests yet, but this patch series looks 
good (except for one issue in patch 3).


Patches 1 and 2 are:
Reviewed-by: Kenneth Graunke 

There's a bit more janitorial work left, though.  Below are my notes 
from triaging the 1.30/1.40 specs:


===

New keywords:
- layout
- sampler2DRect, i, u, sampler2DRectShadow
- samplerBuffer, i, u

UBOs (4.3.5)

Precision:
- floats are highp by default (4.5.3)

VS Special Variables (7.1):
- New in int gl_InstanceID

FS Special variables (7.2):
- Removed text: "If the frame buffer is configured as a color index 
buffer..."


Remove VS variables:
- gl_ClipVertex
- gl_Color
- gl_SecondaryColor
- gl_Normal
- gl_Vertex
- gl_MultiTexCoord0, 1, 2, 3, 4, 5, 6, 7
- gl_FogCoord
and constants:
- gl_MaxClipPlanes
- gl_MaxTextureCoords
and uniform state (7.5):
- gl_ModelViewMatrix
- gl_ProjectionMatrix
- gl_ModelViewProjectionMatrix
- gl_TextureMatrix[]
- gl_NormalMatrix
- gl_ModelViewMatrixInverse
- gl_ProjectionMatrixInverse
- gl_ModelViewProjectionInverse
- gl_TextureMatrixInverse[]
- gl_ModelViewMatrixTranspose
- gl_ProjectionMatrixTranspose
- gl_ModelViewProjectionMatrixTranspose
- gl_TextureMatrixTranspose[]
- gl_ModelViewMatrixInverseTranspose
- gl_ProjectionMatrixInverseTranspose
- gl_ModelViewProjectionMatrixInverseTranspose
- gl_TextureMatrixInverseTranspose[]
- gl_NormalScale
- gl_ClipPlane
- gl_Point
- gl_FrontMaterial
- gl_BackMaterial
- gl_LightSource[]
- gl_LightModel
- gl_FrontLightModelProduct
- gl_BackLightModelProduct
- gl_FrontLightProduct[]
- gl_BackLightProduct[]
- gl_TextureEnvColor[]
- gl_EyePlaneS[]
- gl_EyePlaneT[]
- gl_EyePlaneR[]
- gl_EyePlaneQ[]
- gl_ObjectPlaneS[]
- gl_ObjectPlaneT[]
- gl_ObjectPlaneR[]
- gl_ObjectPlaneQ[]
- gl_Fog
and types:
- struct gl_PointParameters type
- struct gl_MaterialParameters
- struct gl_LightSourceParameters
- struct gl_LightModelProducts
- struct gl_LightModelParameters
- struct gl_LightProducts
- struct gl_FogParameters
and VS outputs ("There are no longer any built-in vertex output variables.":
and FS inputs: everything except gl_PointCoord dies.

Shaders are Mandatory (7.6):
"All programmable pipeline stages that are in use while rendering must
 have a shader provided; fixed functionality is not provided for
 programmable stages."

Built-ins:
- Remove ftransform()
- Add inverse() for square matrices

New texture built-ins (no bias/lod allowed):
- ivec2 textureSize(gsampler2DRect)
- ivec2 textureSize(sampler2DRectShadow)
- int textureSize(gsamplerBuffer)
- gvec4 texture(gsampler2DRect)
- float texture(sampler2DRectShadow)
- gvec4 textureProj(gsampler2DRect, vec3)
- gvec4 textureProj(gsampler2DRect, vec4)
- float textureProj(sampler2DRectShadow, vec4)
- gvec4 textureOffset(gsampler2DRect, vec2, ivec2)
- float textureOffset(sampler2DRectShadow, vec3, ivec2)
- gvec4 texelFetch(gsampler2DRect, ivec2)
- gvec4 texelFetch(gsamplerBuffer, int)
- gvec4 texelFetchOffset(gsampler2DRect, ivec2, ivec2)
- gvec4 textureProjOffset(gsampler2DRect, vec3, ivec2)
- gvec4 textureProjOffset(gsampler2DRect, vec4, ivec2)
- float textureProjOffset(sampler2DRectShadow, vec4, ivec2)
- gvec4 textureGrad(gsampler2DRect, vec2, vec2, vec2)
- float textureGrad(sampler2DRectShadow, vec3, vec2, vec2)
- gvec4 textureGradOffset(gsampler2DRect, vec2, vec2, vec2, ivec2)
- float textureGradOffset(sampler2DRectShadow, vec3, vec2, vec2, ivec2)
- gvec4 textureProjGrad(gsampler2DRect, vec3, vec2, vec2)
- float textureProjGrad(sampler2DRectShadow, vec4, vec2, vec2)
Deprecated texturing functions still exist (sadly).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/7] radeon/r200: remove hyperz/fast clear testing code

2012-03-12 Thread Dave Airlie 
On Mon, Mar 12, 2012 at 12:33 AM, Brian Paul  wrote:
> The flags which were computed were never actually used.
> ---
>  src/mesa/drivers/dri/r200/r200_ioctl.c     |   10 --
>  src/mesa/drivers/dri/radeon/radeon_ioctl.c |   10 --
>  2 files changed, 0 insertions(+), 20 deletions(-)

For the series,

Reviewed-by: Dave Airlie 

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i915: fallback when point sprite is enabled while handling varying inputs

2012-03-12 Thread Yuanhan Liu 
On Mon, Mar 12, 2012 at 10:14:06AM +0800, Yuanhan Liu wrote:
> On Fri, Mar 09, 2012 at 10:35:33AM -0800, Eric Anholt wrote:
> > On Thu, 8 Mar 2012 19:21:23 +0800, Yuanhan Liu 
> >  wrote:
> > > From ddd1a9d8f0d82c2f5fcb78a471608a005a6a077c Mon Sep 17 00:00:00 2001
> > > From: Yuanhan Liu 
> > > Date: Thu, 8 Mar 2012 18:48:54 +0800
> > > Subject: [PATCH] i915: set SPRITE_POINT_ENABLE bit just when we need do 
> > > coord
> > >  replace
> > > 
> > > When SPRITE_POINT_ENABLE bit is set, the texture coord would be
> > > replaced, and this is only needed when we called something like
> > > glTexEnvi(GL_POINT_SPRITE, GL_COORD_REPLACE, GL_TRUE).
> > > 
> > > Since we currently handling varying inputs as tex coord, we would be
> > > careful when setting this bit and set it just when needed, or you will
> > > find the value of varying input is not right and changed.
> > > 
> > > With handling the bit setup at i915ValidateFragmentProgram, we don't
> > > need the code at i915Enable then.
> > > 
> > > This patch would _really_ fix the webglc point-size.html test case and
> > > of course, not regress piglit point-sprite and glean-pointSprite testcase.
> > > 
> > > NOTE: This is a candidate for stable release branches.
> > > 
> > > Signed-off-by: Yuanhan Liu 
> > > ---
> > >  src/mesa/drivers/dri/i915/i915_fragprog.c |5 +
> > >  src/mesa/drivers/dri/i915/i915_state.c|   13 +
> > >  2 files changed, 6 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c 
> > > b/src/mesa/drivers/dri/i915/i915_fragprog.c
> > > index 5b7e93e..8829e8d 100644
> > > --- a/src/mesa/drivers/dri/i915/i915_fragprog.c
> > > +++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
> > > @@ -1379,7 +1379,12 @@ i915ValidateFragmentProgram(struct i915_context 
> > > *i915)
> > >EMIT_ATTR(_TNL_ATTRIB_FOG, EMIT_1F, S4_VFMT_FOG_PARAM, 4);
> > > }
> > >  
> > > +   s4 &= ~S4_SPRITE_POINT_ENABLE;
> > > for (i = 0; i < p->ctx->Const.MaxTextureCoordUnits; i++) {
> > > +  /* Do set SPRITE_POINT_ENABLE bit when we need do coord replace */
> > > +  if (ctx->Point.CoordReplace[i] && ctx->Point.PointSprite)
> > > + s4 |= S4_SPRITE_POINT_ENABLE;
> > > +
> > >if (inputsRead & FRAG_BIT_TEX(i)) {
> > >   int sz = VB->AttribPtr[_TNL_ATTRIB_TEX0 + i]->size;
> > 
> > I don't think you've done anything to guarantee that this code is called
> > when CoordReplace changes.
> 
> Yes, you are right. Maybe we can do it at the final _draw_ time, say
> i915_reduced_primitive_state?

Acutally, it seems we can guarantee that: since i915ValidateFragmentProgram
is called at the _draw_ time, which makes sure the previous call of
CoordReplace is handled. Right?

Anyway, I made another 2 patches, please help to review it.

Thanks,
Yuanhan Liu


> 
> > 
> > A more general problem: you're turning on point sprite if coord replace
> > is set on any texcoord.  i915 replaces all texcoords with (0,0)-(1,1)
> > when point sprite is enabled, which breaks any non-point-sprite
> > coordinates, plus varyings as you noted. 
> 
> Well, I guess that's also what the current code do. Since
> SPRITE_POINT_ENABLE is just _one_ bit instead of a set of mask bits.
> 
> > If you need point sprite
> > coordinates and actual texcoords, a fallback should be done.
> 
> Yes, agreed acoording to the above state.
> 
> > 
> > (Well, if we did better compiling, we could route a couple of varyings
> > through color/secondarycolor while still getting point sprite
> > coordinates on the texcoords)
> 
> That's a good hint. But I'd like to do the fallback first. Since I don't
> know how many works should be done to get the better compiling.
> 
> Thanks,
> Yuanhan Liu
> ___
> 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

[Mesa-dev] [PATCH 1/2] i915: set SPRITE_POINT_ENABLE bit correctly

2012-03-12 Thread Yuanhan Liu 
When SPRITE_POINT_ENABLE bit is set, the texture coord would be
replaced, and this is only needed when we called something like
glTexEnvi(GL_POINT_SPRITE, GL_COORD_REPLACE, GL_TRUE).

And more,  we currently handle varying inputs as texture coord,
we would be careful when setting this bit and set it just when
needed, or you will find the value of varying input is not right
and changed.

Thus we do set SPRITE_POINT_ENABLE bit only when all enabled tex
coord units need do CoordReplace. Or fallback is needed to make
sure the rendering is right.

As we need guarantee the CoordReplace changes handled well and
be able to fallback when finding something wrong, I added another
function to handle it at intelRunPipepline, where the drawing
happened here and tnl pipeline hasn't started yet.

With handling the bit setup at intel_validate_sprite_point_enable(),
we don't need the relative code at i915Enable then.

This patch would _really_ fix the webglc point-size.html test case and
of course, not regress piglit point-sprite and glean-pointSprite testcase.

NOTE: This is a candidate for stable release branches.

v2: fallback just when all enabled tex coord units need do
CoordReplace(Eric).

Signed-off-by: Yuanhan Liu 
---
 src/mesa/drivers/dri/i915/i915_context.h |1 +
 src/mesa/drivers/dri/i915/i915_state.c   |   13 +---
 src/mesa/drivers/dri/i915/intel_tris.c   |   52 ++
 3 files changed, 54 insertions(+), 12 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i915_context.h 
b/src/mesa/drivers/dri/i915/i915_context.h
index 8167137..59eeb6e 100644
--- a/src/mesa/drivers/dri/i915/i915_context.h
+++ b/src/mesa/drivers/dri/i915/i915_context.h
@@ -40,6 +40,7 @@
 #define I915_FALLBACK_POINT_SMOOTH  0x8
 #define I915_FALLBACK_POINT_SPRITE_COORD_ORIGIN 0x10
 #define I915_FALLBACK_DRAW_OFFSET   0x20
+#define I915_FALLBACK_COORD_REPLACE 0x40
 
 #define I915_UPLOAD_CTX  0x1
 #define I915_UPLOAD_BUFFERS  0x2
diff --git a/src/mesa/drivers/dri/i915/i915_state.c 
b/src/mesa/drivers/dri/i915/i915_state.c
index 756001f..3c751e4 100644
--- a/src/mesa/drivers/dri/i915/i915_state.c
+++ b/src/mesa/drivers/dri/i915/i915_state.c
@@ -869,18 +869,7 @@ i915Enable(struct gl_context * ctx, GLenum cap, GLboolean 
state)
   break;
 
case GL_POINT_SPRITE:
-  /* This state change is handled in i915_reduced_primitive_state because
-   * the hardware bit should only be set when rendering points.
-   */
-dw = i915->state.Ctx[I915_CTXREG_LIS4];
-  if (state)
-dw |= S4_SPRITE_POINT_ENABLE;
-  else
-dw &= ~S4_SPRITE_POINT_ENABLE;
-  if (dw != i915->state.Ctx[I915_CTXREG_LIS4]) {
-i915->state.Ctx[I915_CTXREG_LIS4] = dw;
-I915_STATECHANGE(i915, I915_UPLOAD_CTX);
-  }
+  /* Handle it at intel_validate_sprite_point_enable() */
   break;
 
case GL_POINT_SMOOTH:
diff --git a/src/mesa/drivers/dri/i915/intel_tris.c 
b/src/mesa/drivers/dri/i915/intel_tris.c
index a36011a..58f6a59 100644
--- a/src/mesa/drivers/dri/i915/intel_tris.c
+++ b/src/mesa/drivers/dri/i915/intel_tris.c
@@ -1052,6 +1052,48 @@ static const GLenum reduced_prim[GL_POLYGON + 1] = {
GL_TRIANGLES
 };
 
+static void
+intel_validate_sprite_point_enable(struct intel_context *intel)
+{
+   struct gl_context *ctx = &intel->ctx;
+   struct i915_fragment_program *p =
+  (struct i915_fragment_program *) ctx->FragmentProgram._Current;
+   const GLbitfield64 inputsRead = p->FragProg.Base.InputsRead;
+   struct i915_context *i915 = i915_context(ctx);
+   GLuint s4 = i915->state.Ctx[I915_CTXREG_LIS4] & ~S4_VFMT_MASK;
+   int i;
+   GLuint coord_replace_bits = 0x0;
+   GLuint tex_coord_unit_bits = 0x0;
+
+   for (i = 0; i < ctx->Const.MaxTextureCoordUnits; i++) {
+  if (ctx->Point.CoordReplace[i] && ctx->Point.PointSprite)
+ coord_replace_bits |= (1 << i);
+  if (inputsRead & FRAG_BIT_TEX(i))
+ tex_coord_unit_bits |= (1 << i);
+   }
+
+   s4 &= ~S4_SPRITE_POINT_ENABLE;
+   if (coord_replace_bits) {
+  if (coord_replace_bits != tex_coord_unit_bits) {
+ /*
+  * Here we can't enable the SPRITE_POINT_ENABLE bit due to the
+  * mis-match of tex_coord_unit_bits and coord_replace_bits, or
+  * this will make all the other non-point-sprite coords be
+  * replaced to value (0, 0)-(1, 1).
+  *
+  * Thus, a fallback is needed.
+  */
+ FALLBACK(intel, I915_FALLBACK_COORD_REPLACE, true);
+  } else {
+ s4 |= S4_SPRITE_POINT_ENABLE;
+  }
+   }
+
+   if (s4 != i915->state.Ctx[I915_CTXREG_LIS4]) {
+  i915->state.Ctx[I915_CTXREG_LIS4] = s4;
+  I915_STATECHANGE(i915, I915_UPLOAD_CTX);
+   }
+}
 
 /**/
 /* High level hooks for t_vb_render.c */
@@ -1070,6 +1112,15 @@ intelRunPipeline(struct gl_context * ctx)
if (ctx->

[Mesa-dev] [PATCH 2/2] i915: set SPRITE_POINT_ENABLE bit only for points

2012-03-12 Thread Yuanhan Liu 
Signed-off-by: Yuanhan Liu 
---
 src/mesa/drivers/dri/i915/i915_state.c |8 +++-
 src/mesa/drivers/dri/i915/i915_vtbl.c  |9 +
 2 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i915_state.c 
b/src/mesa/drivers/dri/i915/i915_state.c
index 3c751e4..d7c6918 100644
--- a/src/mesa/drivers/dri/i915/i915_state.c
+++ b/src/mesa/drivers/dri/i915/i915_state.c
@@ -869,7 +869,13 @@ i915Enable(struct gl_context * ctx, GLenum cap, GLboolean 
state)
   break;
 
case GL_POINT_SPRITE:
-  /* Handle it at intel_validate_sprite_point_enable() */
+  /*
+   * Handle it at intel_validate_sprite_point_enable()
+   *
+   * And final handle it in i915_reduced_primitive_state()
+   * because the hardware bit should only be set when
+   * rendering points
+   */
   break;
 
case GL_POINT_SMOOTH:
diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c 
b/src/mesa/drivers/dri/i915/i915_vtbl.c
index e78dbc8..b131b19 100644
--- a/src/mesa/drivers/dri/i915/i915_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i915_vtbl.c
@@ -87,6 +87,15 @@ i915_reduced_primitive_state(struct intel_context *intel, 
GLenum rprim)
 
i915->intel.reduced_primitive = rprim;
 
+   /* Set SPRITE_POINT_ENABLE bit only for points */
+   if (rpim != GL_POINTS &&
+   i915->state.Ctx[I915_CTXREG_LIS4] & S4_SPRITE_POINT_ENABLE) {
+  INTEL_FIREVERTICES(intel);
+
+  i915->state.Ctx[I915_CTXREG_LIS4] &= ~S4_SPRITE_POINT_ENABLE;
+  I915_STATECHANGE(i915, I915_UPLOAD_CTX);
+   }
+
if (st1 != i915->state.Stipple[I915_STPREG_ST1]) {
   INTEL_FIREVERTICES(intel);
 
-- 
1.7.7

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/9] gallium: add R8G8_R8B8 and G8R8_B8R8 format

2012-03-12 Thread Roland Scheidegger 
Hmm actually I think these new pipe formats are a mistake.
Why do you need them and don't just use the existing R8G8_B8G8 and
G8R8_G8B8?
Do you really care if Y ends up in G channel instead of R? And if you do
why don't you just use a sampler swizzle?
The R8G8_B8G8 and G8R8_G8B8 formats are there because these correspond
to the subsampled DX10 formats. I just see absolutely no point in
introducing similar formats which just have different channel mapping -
we generally don't have arbitrary swizzled formats, with the exception
of "old" ones which can be used for legacy purposes. But no such case
can be made for these new formats.
(I just checked the i965 docs which doesn't support sampler swizzling,
and in fact these new formats wouldn't help you there neither, since all
4 subsampled ycbcr format map Y to the green channel. So with hw
supporting sampler swizzling, these formats don't buy you anything, and
with hw not supporting it they don't help neither as no hardware out
there supports them anyway.)
Or is there another reason why you need these formats I'm missing?

Roland

Am 07.03.2012 15:10, schrieb Christian König:
> v2: simplify implementation by using correct swizzle
> 
> Signed-off-by: Christian König 
> --- a/src/gallium/include/pipe/p_format.h
> +++ b/src/gallium/include/pipe/p_format.h
> @@ -311,6 +311,9 @@ enum pipe_format {
>  
> PIPE_FORMAT_ETC1_RGB8   = 226,
>  
> +   PIPE_FORMAT_R8G8_R8B8_UNORM = 227,
> +   PIPE_FORMAT_G8R8_B8R8_UNORM = 228,
> +
> PIPE_FORMAT_COUNT
>  };
>  

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/9] gallium: add R8G8_R8B8 and G8R8_B8R8 format

2012-03-12 Thread Christian König 

On 12.03.2012 13:26, Roland Scheidegger wrote:

Hmm actually I think these new pipe formats are a mistake.
Why do you need them and don't just use the existing R8G8_B8G8 and
G8R8_G8B8?
Do you really care if Y ends up in G channel instead of R? And if you do
why don't you just use a sampler swizzle?
The R8G8_B8G8 and G8R8_G8B8 formats are there because these correspond
to the subsampled DX10 formats. I just see absolutely no point in
introducing similar formats which just have different channel mapping -
we generally don't have arbitrary swizzled formats, with the exception
of "old" ones which can be used for legacy purposes. But no such case
can be made for these new formats.
Well, we definitely already have separate formats for different channel 
mappings. otherwise we should handle the difference between RGBA and 
BGRA with sampler swizzle’s also.



(I just checked the i965 docs which doesn't support sampler swizzling,
and in fact these new formats wouldn't help you there neither, since all
4 subsampled ycbcr format map Y to the green channel. So with hw
supporting sampler swizzling, these formats don't buy you anything, and
with hw not supporting it they don't help neither as no hardware out
there supports them anyway.)
Or is there another reason why you need these formats I'm missing?
Nope, not really I just added them for consistency with the existing 
format handling, and it actually makes the implementation of YUV -> RGB 
conversion a bit easier.


Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/9] gallium: add R8G8_R8B8 and G8R8_B8R8 format

2012-03-12 Thread Jose Fonseca 
- Original Message -
> On 12.03.2012 13:26, Roland Scheidegger wrote:
> > Hmm actually I think these new pipe formats are a mistake.
> > Why do you need them and don't just use the existing R8G8_B8G8 and
> > G8R8_G8B8?
> > Do you really care if Y ends up in G channel instead of R? And if
> > you do
> > why don't you just use a sampler swizzle?
> > The R8G8_B8G8 and G8R8_G8B8 formats are there because these
> > correspond
> > to the subsampled DX10 formats. I just see absolutely no point in
> > introducing similar formats which just have different channel
> > mapping -
> > we generally don't have arbitrary swizzled formats, with the
> > exception
> > of "old" ones which can be used for legacy purposes. But no such
> > case
> > can be made for these new formats.
> Well, we definitely already have separate formats for different
> channel
> mappings. otherwise we should handle the difference between RGBA and
> BGRA with sampler swizzle’s also.
> 
> > (I just checked the i965 docs which doesn't support sampler
> > swizzling,
> > and in fact these new formats wouldn't help you there neither,
> > since all
> > 4 subsampled ycbcr format map Y to the green channel. So with hw
> > supporting sampler swizzling, these formats don't buy you anything,
> > and
> > with hw not supporting it they don't help neither as no hardware
> > out
> > there supports them anyway.)
> > Or is there another reason why you need these formats I'm missing?
> Nope, not really I just added them for consistency with the existing
> format handling, and it actually makes the implementation of YUV ->
> RGB
> conversion a bit easier.

I think it's fine to have additional formats if they help in anyway. I 
certainly rather have more formats than, e.g., jamming multiple semantics on an 
existing format.

If formats eventually become unused we can always remove them.

Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/9] gallium: add R8G8_R8B8 and G8R8_B8R8 format

2012-03-12 Thread Roland Scheidegger 
Am 12.03.2012 15:00, schrieb Jose Fonseca:
> - Original Message -
>> On 12.03.2012 13:26, Roland Scheidegger wrote:
>>> Hmm actually I think these new pipe formats are a mistake. Why do
>>> you need them and don't just use the existing R8G8_B8G8 and 
>>> G8R8_G8B8? Do you really care if Y ends up in G channel instead
>>> of R? And if you do why don't you just use a sampler swizzle? The
>>> R8G8_B8G8 and G8R8_G8B8 formats are there because these 
>>> correspond to the subsampled DX10 formats. I just see absolutely
>>> no point in introducing similar formats which just have different
>>> channel mapping - we generally don't have arbitrary swizzled
>>> formats, with the exception of "old" ones which can be used for
>>> legacy purposes. But no such case can be made for these new
>>> formats.
>> Well, we definitely already have separate formats for different 
>> channel mappings. otherwise we should handle the difference between
>> RGBA and BGRA with sampler swizzle’s also.
Only for "old" formats for which this makes sense (because some api uses
them). None of the sint/float formats for instance have different
formats which only differ in rgba ordering.

>> 
>>> (I just checked the i965 docs which doesn't support sampler 
>>> swizzling, and in fact these new formats wouldn't help you there
>>> neither, since all 4 subsampled ycbcr format map Y to the green
>>> channel. So with hw supporting sampler swizzling, these formats
>>> don't buy you anything, and with hw not supporting it they don't
>>> help neither as no hardware out there supports them anyway.) Or
>>> is there another reason why you need these formats I'm missing?
>> Nope, not really I just added them for consistency with the
>> existing format handling, and it actually makes the implementation
>> of YUV -> RGB conversion a bit easier.
I don't see why that makes handling yuv->rgb conversion easier.
I don't think that you can really say that's for consistency with other
formats handling, you don't have a api which claims it must be this
order when sampled (as yuyv does not imply anything about in what rgba
channels these values should end up).

> 
> I think it's fine to have additional formats if they help in anyway.
> I certainly rather have more formats than, e.g., jamming multiple
> semantics on an existing format.
Yes, jamming multiple semantics on existing formats is bad, but this is
not the case here. The only difference is really the sampler swizzle,
and the choice which one to use is somewhat arbitrary (as vl really has
u8y8_v8y8 data, the mapping to rgb is entirely up to the state tracker,
not api imposed). That's why I'd think it would be better to use the
formats we already have, these could be translated to other hw which
doesn't have native sampler swizzling, and drivers wouldn't need to care
about even more formats.

> 
> If formats eventually become unused we can always remove them.
That much is true, but why introduce unneeded ones in the first place?
Now if this really simplifies yuv->rgb conversion then there's a use for
it, but otherwise this just looks unnecessary to me. I think state
trackers should deal with something like that if if they just need an
arbitrary sampler swizzle, not impose that (admittedly tiny) additional
complexity on everything.

Anyway, I can certainly live with this, I just think it's not really the
best solution.

Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Fix the cause of piglit test fbo-array failure

2012-03-12 Thread Brian Paul 

On 03/09/2012 07:07 PM, Anuj Phogat wrote:

Handle the special case of glFramebufferTextureLayer() for which we pass
teximage = 0 internally in framebuffer_texture(). This patch makes failing
piglit test fbo-array, fbo-depth-array to pass.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47126

Note: This is a candidate for stable branches

Signed-off-by: Anuj Phogat
---
  src/mesa/main/fbobject.c |   20 ++--
  1 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 281b1ca..670b464 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1993,12 +1993,20 @@ framebuffer_texture(struct gl_context *ctx, const char 
*caller, GLenum target,
   }
}

-  if ((level<  0) ||
-  (level>= _mesa_max_texture_levels(ctx, textarget))) {
- _mesa_error(ctx, GL_INVALID_VALUE,
- "glFramebufferTexture%sEXT(level)", caller);
- return;
-  }
+  if (target == 0)
+ if ((level<  0) ||
+ (level>= _mesa_max_texture_levels(ctx, texObj->Target))) {
+_mesa_error(ctx, GL_INVALID_VALUE,
+"glFramebufferTexture%sEXT(level)", caller);
+return;
+ }
+  else
+ if ((level<  0) ||
+ (level>= _mesa_max_texture_levels(ctx, textarget))) {
+_mesa_error(ctx, GL_INVALID_VALUE,
+"glFramebufferTexture%sEXT(level)", caller);
+return;
+ }
 }

 att = _mesa_get_attachment(ctx, fb, attachment);


Let's try to avoid so much duplicated code.  How about something like 
this:


  GLenum maxLevelsTarget;

  maxLevelsTarget = textarget ? textarget : texObj->Target;

  if ((level < 0) ||
  (level >= _mesa_max_texture_levels(ctx, maxLevelsTarget))) {
  _mesa_error(ctx, GL_INVALID_VALUE,
  "glFramebufferTexture%sEXT(level)", caller);
  return;
  }

I think it's kind of confusing that we pass textarget=0 for 
glFramebufferTextureLayer().  I'm going to beef up the comments for that.


-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 47175] piglit fbo-alphatest-formats regression

2012-03-12 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=47175

--- Comment #2 from Brian Paul  2012-03-12 09:02:10 PDT 
---
Actually, I think mesa is right and the test is wrong.  The NVIDIA driver fails
the same tests as Mesa.  It looks like the test is doing the wrong thing when
computing the expected result colors when the texture is luminance, L/A or
intensity.

I'll try to fix that.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/9] i915: remove occurances of _DD_NEW_x flags

2012-03-12 Thread Jose Fonseca 
The series looks good to me AFAICT.

Joe

- Original Message -
> Just use the corresponding _NEW_x flags intead.  The _DD_NEW_x flags
> will be removed in a following patch.
> ---
>  src/mesa/drivers/dri/i915/intel_tris.h |   12 +---
>  1 files changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i915/intel_tris.h
> b/src/mesa/drivers/dri/i915/intel_tris.h
> index ad84de8..8f45367 100644
> --- a/src/mesa/drivers/dri/i915/intel_tris.h
> +++ b/src/mesa/drivers/dri/i915/intel_tris.h
> @@ -34,13 +34,11 @@
>  /** 3 dwords of state_immediate and 2 of 3dprim, in intel_flush_prim
>  */
>  #define INTEL_PRIM_EMIT_SIZE (5 * 4)
>  
> -#define _INTEL_NEW_RENDERSTATE (_DD_NEW_LINE_STIPPLE |   \
> -_DD_NEW_TRI_UNFILLED |   \
> -_DD_NEW_TRI_LIGHT_TWOSIDE |  \
> -_DD_NEW_TRI_OFFSET | \
> -_DD_NEW_TRI_STIPPLE |\
> -_NEW_PROGRAM |   \
> -_NEW_POLYGONSTIPPLE)
> +#define _INTEL_NEW_RENDERSTATE (_NEW_LINE | \
> +_NEW_POLYGON | \
> +_NEW_LIGHT | \
> +_NEW_PROGRAM | \
> +_NEW_POLYGONSTIPPLE)
>  
>  extern void intelInitTriFuncs(struct gl_context * ctx);
>  
> --
> 1.7.3.4
> 
> ___
> 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 3/3] glsl: Update builtin variables for GLSL 1.40.

2012-03-12 Thread Eric Anholt 
On Sun, 11 Mar 2012 23:59:35 -0700, Kenneth Graunke  
wrote:
> On 03/09/2012 01:27 PM, Eric Anholt wrote:
> > Mostly this is a matter of removing variables that have been moved to
> > the compatibility profile.  There's one addition: gl_InstanceID is
> > present in the core now.
> >
> > This fixes the new piglit tests for GLSL 1.40 builtins.
> >
> > -   add_builtin_constant(instructions, symtab, "gl_MaxLights",
> > -   state->Const.MaxLights);
> > -   add_builtin_constant(instructions, symtab, "gl_MaxClipPlanes",
> > -   state->Const.MaxClipPlanes);
> > -   add_builtin_constant(instructions, symtab, "gl_MaxTextureUnits",
> > -   state->Const.MaxTextureUnits);
> > -   add_builtin_constant(instructions, symtab, "gl_MaxTextureCoords",
> > -   state->Const.MaxTextureCoords);
> > +   if (add_deprecated) {
> > +  add_builtin_constant(instructions, symtab, "gl_MaxLights",
> > +  state->Const.MaxLights);
> 
> I can't find gl_MaxLights defined in 1.30 or 1.40.  I agree that it 
> makes sense to drop it as it pertains to fixed-function lighting.

I'm pretty sure it was an unintentional omission (should have been
present under ARB_compat) in 1.30, given that it existed in 1.20 and the
1.30 spec still defines some of the ARB_compatibility variables in terms
of it.

> > +  add_builtin_constant(instructions, symtab, "gl_MaxClipPlanes",
> > +  state->Const.MaxClipPlanes);
> > +  add_builtin_constant(instructions, symtab, "gl_MaxTextureUnits",
> > +  state->Const.MaxTextureUnits);
> 
> gl_MaxTextureUnits is not deprecated.  (See GLSL 1.40.08 section 7.4. 
> Note the lack of "// Deprecated" comment.)

I think gl_MaxTextureUnits is a special case -- Here's what I wrote in
the compiler test to check that it's not present:

/* This value (number of fixed function texture environment
 * units) was erroneously left in the core profile on release
 * of GLSL 1.40, similar to the typo of increasing the minimum
 * from 2 to 16 in GLSL 1.30.  In GLSL 1.50, a later
 * clarification moved it to to the compatibility profile, but
 * that was never backported to 1.40.
 */


pgprEffcnkHHI.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 47241] New: docs/autoconf.html is invalid

2012-03-12 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=47241

 Bug #: 47241
   Summary: docs/autoconf.html is invalid
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86-64 (AMD64)
   URL: http://mesa3d.org/autoconf.html
OS/Version: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: giecr...@stegny.2a.pl


+ tidy autoconf.html
line 1 column 1 - Warning: missing  declaration
line 15 column 3 - Warning: missing 
line 21 column 3 - Warning: missing 
line 28 column 1 - Warning: missing  before 
line 29 column 5 - Warning: inserting implicit 
line 32 column 1 - Warning: inserting implicit 
line 42 column 1 - Warning: inserting implicit 
line 57 column 1 - Warning: inserting implicit 
line 63 column 1 - Warning: inserting implicit 
line 63 column 1 - Warning: missing  before 
line 107 column 1 - Warning: inserting implicit 
line 142 column 1 - Warning: inserting implicit 
line 145 column 1 - Warning: missing  before 
line 146 column 5 - Warning: inserting implicit 
line 149 column 1 - Warning: inserting implicit 
line 149 column 1 - Warning: missing  before 
line 158 column 1 - Warning: missing 
line 158 column 1 - Warning: missing  before 
line 166 column 1 - Warning: missing 
line 166 column 1 - Warning: missing  before 
line 175 column 1 - Warning: missing 
line 207 column 1 - Warning: inserting implicit 
line 209 column 1 - Warning: missing  before 
line 217 column 1 - Warning: missing 
line 227 column 1 - Warning: inserting implicit 
line 232 column 1 - Warning: missing  before 
line 233 column 5 - Warning: inserting implicit 
line 236 column 1 - Warning: inserting implicit 
line 236 column 1 - Warning: missing  before 
line 242 column 1 - Warning: missing 
line 242 column 1 - Warning: missing  before 
line 248 column 1 - Warning: inserting implicit 
line 251 column 1 - Warning: missing  before 
line 252 column 5 - Warning: inserting implicit 
line 255 column 1 - Warning: inserting implicit 
line 255 column 1 - Warning: missing  before 
line 271 column 1 - Warning: inserting implicit 
line 32 column 1 - Warning:  anchor "basic" already defined
line 38 column 1 - Warning:  anchor "basic" already defined
line 42 column 1 - Warning:  anchor "basic" already defined
line 53 column 1 - Warning:  anchor "basic" already defined
line 57 column 1 - Warning:  anchor "basic" already defined
line 63 column 1 - Warning:  anchor "basic" already defined
line 149 column 1 - Warning:  anchor "driver" already defined
line 236 column 1 - Warning:  anchor "library" already defined
line 255 column 1 - Warning:  anchor "demos" already defined
line 107 column 1 - Warning: trimming empty 
line 142 column 1 - Warning: trimming empty 
line 175 column 1 - Warning: trimming empty 
line 207 column 1 - Warning: trimming empty 
line 217 column 1 - Warning: trimming empty 
line 227 column 1 - Warning: trimming empty 
line 248 column 1 - Warning: trimming empty 
line 271 column 1 - Warning: trimming empty 
Info: Document content looks like HTML 4.01 Transitional
Info: No system identifier in emitted doctype
54 warnings, 0 errors were found!

Note: HTML tidy reports these as warnings because it things it can deal with
them.  They are errors and they cannot be automatically fixed because the
existing markup is semantically flawed anyway.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 47241] docs/autoconf.html is invalid

2012-03-12 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=47241

--- Comment #1 from Christopher Yeleighton  2012-03-12 
09:58:14 PDT ---
Created attachment 58332
  --> https://bugs.freedesktop.org/attachment.cgi?id=58332
upgrade markup

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/9] i915: remove occurances of _DD_NEW_x flags

2012-03-12 Thread Eric Anholt 
On Sun, 11 Mar 2012 18:34:38 -0600, Brian Paul  wrote:
> Just use the corresponding _NEW_x flags intead.  The _DD_NEW_x flags
> will be removed in a following patch.

Series is:

Reviewed-by: Eric Anholt 


pgpZKmg4uBziS.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: Fix the cause of piglit test fbo-array failure

2012-03-12 Thread Anuj Phogat 
Handle the special case of glFramebufferTextureLayer() for which we pass
teximage = 0 internally in framebuffer_texture(). This patch makes failing
piglit test fbo-array, fbo-depth-array to pass.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47126

V4: Removed the duplicated code.
Note: This is a candidate for the stable branches.

Signed-off-by: Anuj Phogat 
---
 src/mesa/main/fbobject.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 281b1ca..372d16f 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1924,6 +1924,7 @@ framebuffer_texture(struct gl_context *ctx, const char 
*caller, GLenum target,
struct gl_renderbuffer_attachment *att;
struct gl_texture_object *texObj = NULL;
struct gl_framebuffer *fb;
+   GLenum maxLevelsTarget;
 
ASSERT_OUTSIDE_BEGIN_END(ctx);
 
@@ -1993,8 +1994,9 @@ framebuffer_texture(struct gl_context *ctx, const char 
*caller, GLenum target,
  }
   }
 
+  maxLevelsTarget = textarget ? textarget : texObj->Target;
   if ((level < 0) ||
-  (level >= _mesa_max_texture_levels(ctx, textarget))) {
+  (level >= _mesa_max_texture_levels(ctx, maxLevelsTarget))) {
  _mesa_error(ctx, GL_INVALID_VALUE,
  "glFramebufferTexture%sEXT(level)", caller);
  return;
-- 
1.7.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 47241] docs/autoconf.html is invalid

2012-03-12 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=47241

Brian Paul  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Brian Paul  2012-03-12 11:23:15 PDT 
---
Thanks.  I've applied your patch.
7f94d9819dd05bf00191c1f1ff98551de9aa4d1b

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] glsl: Update builtin variables for GLSL 1.40.

2012-03-12 Thread Kenneth Graunke 

On 03/12/2012 09:50 AM, Eric Anholt wrote:

On Sun, 11 Mar 2012 23:59:35 -0700, Kenneth Graunke  
wrote:

On 03/09/2012 01:27 PM, Eric Anholt wrote:

Mostly this is a matter of removing variables that have been moved to
the compatibility profile.  There's one addition: gl_InstanceID is
present in the core now.

This fixes the new piglit tests for GLSL 1.40 builtins.

-   add_builtin_constant(instructions, symtab, "gl_MaxLights",
-   state->Const.MaxLights);
-   add_builtin_constant(instructions, symtab, "gl_MaxClipPlanes",
-   state->Const.MaxClipPlanes);
-   add_builtin_constant(instructions, symtab, "gl_MaxTextureUnits",
-   state->Const.MaxTextureUnits);
-   add_builtin_constant(instructions, symtab, "gl_MaxTextureCoords",
-   state->Const.MaxTextureCoords);
+   if (add_deprecated) {
+  add_builtin_constant(instructions, symtab, "gl_MaxLights",
+  state->Const.MaxLights);


I can't find gl_MaxLights defined in 1.30 or 1.40.  I agree that it
makes sense to drop it as it pertains to fixed-function lighting.


I'm pretty sure it was an unintentional omission (should have been
present under ARB_compat) in 1.30, given that it existed in 1.20 and the
1.30 spec still defines some of the ARB_compatibility variables in terms
of it.


+  add_builtin_constant(instructions, symtab, "gl_MaxClipPlanes",
+  state->Const.MaxClipPlanes);
+  add_builtin_constant(instructions, symtab, "gl_MaxTextureUnits",
+  state->Const.MaxTextureUnits);


gl_MaxTextureUnits is not deprecated.  (See GLSL 1.40.08 section 7.4.
Note the lack of "// Deprecated" comment.)


I think gl_MaxTextureUnits is a special case -- Here's what I wrote in
the compiler test to check that it's not present:

/* This value (number of fixed function texture environment
 * units) was erroneously left in the core profile on release
 * of GLSL 1.40, similar to the typo of increasing the minimum
 * from 2 to 16 in GLSL 1.30.  In GLSL 1.50, a later
 * clarification moved it to to the compatibility profile, but
 * that was never backported to 1.40.
 */


Yes, that makes sense.  Spec bug.  Without any changes:

Reviewed-by: Kenneth Graunke 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 47175] piglit fbo-alphatest-formats regression

2012-03-12 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=47175

Brian Paul  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Brian Paul  2012-03-12 11:24:22 PDT 
---
Fixed with commit 731669c0667325f311fcbcd0f1be63801faaec82 to piglit.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Fix the cause of piglit test fbo-array failure

2012-03-12 Thread Brian Paul 

On 03/12/2012 12:00 PM, Anuj Phogat wrote:

Handle the special case of glFramebufferTextureLayer() for which we pass
teximage = 0 internally in framebuffer_texture(). This patch makes failing
piglit test fbo-array, fbo-depth-array to pass.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47126

V4: Removed the duplicated code.
Note: This is a candidate for the stable branches.

Signed-off-by: Anuj Phogat
---
  src/mesa/main/fbobject.c |4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 281b1ca..372d16f 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1924,6 +1924,7 @@ framebuffer_texture(struct gl_context *ctx, const char 
*caller, GLenum target,
 struct gl_renderbuffer_attachment *att;
 struct gl_texture_object *texObj = NULL;
 struct gl_framebuffer *fb;
+   GLenum maxLevelsTarget;

 ASSERT_OUTSIDE_BEGIN_END(ctx);

@@ -1993,8 +1994,9 @@ framebuffer_texture(struct gl_context *ctx, const char 
*caller, GLenum target,
   }
}

+  maxLevelsTarget = textarget ? textarget : texObj->Target;
if ((level<  0) ||
-  (level>= _mesa_max_texture_levels(ctx, textarget))) {
+  (level>= _mesa_max_texture_levels(ctx, maxLevelsTarget))) {
   _mesa_error(ctx, GL_INVALID_VALUE,
   "glFramebufferTexture%sEXT(level)", caller);
   return;


Reviewed-by: Brian Paul 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: fix _mesa_DebugMessageCallbackARB() to silence warnings

2012-03-12 Thread Brian Paul 
---
 src/mesa/main/errors.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index 2256100..fcf873f 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa/main/errors.c
@@ -718,10 +718,10 @@ _mesa_DebugMessageControlARB(GLenum source, GLenum type, 
GLenum severity,
 }
 
 static void GLAPIENTRY
-_mesa_DebugMessageCallbackARB(GLvoid *callback, GLvoid *userParam)
+_mesa_DebugMessageCallbackARB(GLDEBUGPROCARB callback, GLvoid *userParam)
 {
GET_CURRENT_CONTEXT(ctx);
-   ctx->Debug.Callback = (GLDEBUGPROCARB)callback;
+   ctx->Debug.Callback = callback;
ctx->Debug.CallbackData = userParam;
 }
 
-- 
1.7.3.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: fix _mesa_DebugMessageCallbackARB() to silence warnings

2012-03-12 Thread Jose Fonseca 
Ah, yes. Missed this with my changes. Thanks.

Joe

- Original Message -
> ---
>  src/mesa/main/errors.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
> index 2256100..fcf873f 100644
> --- a/src/mesa/main/errors.c
> +++ b/src/mesa/main/errors.c
> @@ -718,10 +718,10 @@ _mesa_DebugMessageControlARB(GLenum source,
> GLenum type, GLenum severity,
>  }
>  
>  static void GLAPIENTRY
> -_mesa_DebugMessageCallbackARB(GLvoid *callback, GLvoid *userParam)
> +_mesa_DebugMessageCallbackARB(GLDEBUGPROCARB callback, GLvoid
> *userParam)
>  {
> GET_CURRENT_CONTEXT(ctx);
> -   ctx->Debug.Callback = (GLDEBUGPROCARB)callback;
> +   ctx->Debug.Callback = callback;
> ctx->Debug.CallbackData = userParam;
>  }
>  
> --
> 1.7.3.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

-- 
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 47248] New: autogen missing dependency on flex and bison, causes infinite loop in glsl build

2012-03-12 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=47248

 Bug #: 47248
   Summary: autogen missing dependency on flex and bison, causes
infinite loop in glsl build
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: dar...@chaosreigns.com


Last good commit:

commit 4ff8fd93e8e91672bb02543ecaa0c6e462a87551
Author: Matt Turner 
Date:   Sat Jan 28 20:13:51 2012 -0500

glsl: rename Makefile.sources' _SOURCES variables

automake uses variables named *_SOURCES.

Reviewed-by: Eric Anholt 
Tested-by: Eric Anholt 
Signed-off-by: Matt Turner 

First bad commit:

commit dfb6142548df0dccbe6eed2c57986e208eb0d437
Author: Matt Turner 
Date:   Fri Jan 13 14:31:39 2012 -0500

autoconf: use AC_PROG_YACC/LEX

Needed for automake. Using AC_PROG_PATH(bison/flex) causes automake to
fail to build .y and .l files.

It is up to the builder to use bison/flex instead of yacc/lex.

Reviewed-by: Eric Anholt 
Tested-by: Eric Anholt 
Signed-off-by: Matt Turner 


Without flex installed, autogen.sh should end with:

checking for flex... no
configure: error: flex is needed to build Mesa

Similar for bison.

Currently, it doesn't.  

I feel like this is only one of two problems here, the second being that if
autogen misses the absence of flex, there is no error when the build tries to
use it for glsl.  

At least when missing bison, it throws a useful error: 
/bin/bash: yacc: command not found


This is similar to bug 36651.

Latest commit, also has this problem:  
commit 5ac910c0146ca852566ad0328301b2d40f8f5e54
Author: Kenneth Graunke 
Date:   Sun Mar 11 23:38:36 2012 -0700

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 47248] autogen missing dependency on flex and bison, causes infinite loop in glsl build

2012-03-12 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=47248

Darxus  changed:

   What|Removed |Added

 CC||dar...@chaosreigns.com

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i915: set SPRITE_POINT_ENABLE bit only for points

2012-03-12 Thread Eric Anholt 
On Mon, 12 Mar 2012 16:04:01 +0800, Yuanhan Liu  
wrote:
> Signed-off-by: Yuanhan Liu 

Is there a reason for this change?  What test does it fix?

The hardware docs I have say "This bit controls the generation of
texture coordinates at the corners of point primitives. When ENABLED,
the corners of the point primitive will be different..." suggesting that
it doesn't affect non-points.


pgpC0qPZ8mlka.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Doing 8.0.1 release?

2012-03-12 Thread Jakob Bornecrantz 
Hi all

We well over due for a 8.0.1 release, so I thought
we do it aggressively this week. A quick rc tomorrow
and a release on Thursday or Friday? Is that okay with
people, comments please?

Cheers, Jakob.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/9] i965: Add disasm for gen6+ UIP/JIP on BREAK/CONT/HALT.

2012-03-12 Thread Eric Anholt 
---
 src/mesa/drivers/dri/i965/brw_disasm.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c 
b/src/mesa/drivers/dri/i965/brw_disasm.c
index 187bc0a..aebfa73 100644
--- a/src/mesa/drivers/dri/i965/brw_disasm.c
+++ b/src/mesa/drivers/dri/i965/brw_disasm.c
@@ -1118,6 +1118,10 @@ int brw_disasm (FILE *file, struct brw_instruction 
*inst, int gen)
   inst->header.opcode == BRW_OPCODE_ENDIF ||
   inst->header.opcode == BRW_OPCODE_WHILE)) {
  format (file, " %d", inst->bits1.branch_gen6.jump_count);
+   } else if (gen >= 6 && (inst->header.opcode == BRW_OPCODE_BREAK ||
+  inst->header.opcode == BRW_OPCODE_CONTINUE ||
+  inst->header.opcode == BRW_OPCODE_HALT)) {
+ format (file, " %d %d", inst->bits3.break_cont.uip, 
inst->bits3.break_cont.jip);
} else if (inst->header.opcode == BRW_OPCODE_JMPI) {
  format (file, " %d", inst->bits3.d);
}
-- 
1.7.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/9] glsl: Let the builtin compiler process GLSL 1.40 shaders.

2012-03-12 Thread Eric Anholt 
This is required to put the new 1.40 builtins in place, since they
require new types.
---
 src/glsl/main.cpp |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/glsl/main.cpp b/src/glsl/main.cpp
index e174224..d43bf1a 100644
--- a/src/glsl/main.cpp
+++ b/src/glsl/main.cpp
@@ -35,10 +35,10 @@ initialize_context(struct gl_context *ctx, gl_api api)
 {
initialize_context_to_defaults(ctx, api);
 
-   /* GLSL 1.30 isn't fully supported, but we need to advertise 1.30 so that
-* the built-in functions for 1.30 can be built.
+   /* The standalone compiler needs to claim support for almost
+* everything in order to compile the built-in functions.
 */
-   ctx->Const.GLSLVersion = 130;
+   ctx->Const.GLSLVersion = 140;
 
ctx->Const.MaxClipPlanes = 8;
ctx->Const.MaxDrawBuffers = 2;
-- 
1.7.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] GLSL 1.40 progress: hooking up builtin functions

2012-03-12 Thread Eric Anholt 
This is a continuation of the GLSL 1.40 work, which now gets the
newly-submitted textureSize(*2DRect) tests working, with a brief
detour to fix the GPU hangs due to the discard-exiting-the-shader
test.  I want to rework that test, actually, because in my first
attempt at fixing it I only exited the shader if all pixels were
discarded, which missed the point of the spec change (stop computing
for *any* pixel which is discarded).

Much work remains to be done with hooking up the other new
texture*(*2DRect) builtins, and of course *samplerBuffer.

Do we want to encode what we know is remaining to be done in
docs/GL3.txt?

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/9] glsl: When failing to compile some builtins, print the error.

2012-03-12 Thread Eric Anholt 
This makes the process slightly more debuggable, though it would be
nice if the build just failed immediately instead.
---
 src/glsl/builtins/tools/generate_builtins.py |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/src/glsl/builtins/tools/generate_builtins.py 
b/src/glsl/builtins/tools/generate_builtins.py
index 72d12bb..9ab6edd 100755
--- a/src/glsl/builtins/tools/generate_builtins.py
+++ b/src/glsl/builtins/tools/generate_builtins.py
@@ -63,6 +63,14 @@ def run_compiler(args):
 p = Popen(command, 1, stdout=PIPE, shell=False)
 output = p.communicate()[0]
 
+if (p.returncode):
+sys.stderr.write("Failed to compile builtins with command:\n")
+for arg in command:
+sys.stderr.write(arg + " ")
+sys.stderr.write("\n")
+sys.stderr.write("Result:\n")
+sys.stderr.write(output)
+
 # Clean up output a bit by killing whitespace before a closing paren.
 kill_paren_whitespace = re.compile(r'[ \n]*\)', re.MULTILINE)
 output = kill_paren_whitespace.sub(')', output)
-- 
1.7.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/9] i965/fs: Jump from discard statements to the end of the program when done.

2012-03-12 Thread Eric Anholt 
>From the GLSL 1.30 spec:

 The discard keyword is only allowed within fragment shaders. It
 can be used within a fragment shader to abandon the operation on
 the current fragment. This keyword causes the fragment to be
 discarded and no updates to any buffers will occur. Control flow
 exits the shader, and subsequent implicit or explicit derivatives
 are undefined when this control flow is non-uniform (meaning
 different fragments within the primitive take different control
 paths).
---
 src/mesa/drivers/dri/i965/brw_eu.h|1 +
 src/mesa/drivers/dri/i965/brw_eu_emit.c   |   53 +---
 src/mesa/drivers/dri/i965/brw_fs.h|   22 +++
 src/mesa/drivers/dri/i965/brw_fs_emit.cpp |   55 +
 4 files changed, 126 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_eu.h 
b/src/mesa/drivers/dri/i965/brw_eu.h
index dbc84be..373f2ab 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -1063,6 +1063,7 @@ struct brw_instruction *brw_WHILE(struct brw_compile *p);
 struct brw_instruction *brw_BREAK(struct brw_compile *p);
 struct brw_instruction *brw_CONT(struct brw_compile *p);
 struct brw_instruction *gen6_CONT(struct brw_compile *p);
+struct brw_instruction *gen6_HALT(struct brw_compile *p);
 /* Forward jumps:
  */
 void brw_land_fwd_jump(struct brw_compile *p, int jmp_insn_idx);
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 179b59a..597157e 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -1421,6 +1421,20 @@ struct brw_instruction *brw_CONT(struct brw_compile *p)
return insn;
 }
 
+struct brw_instruction *gen6_HALT(struct brw_compile *p)
+{
+   struct brw_instruction *insn;
+
+   insn = next_insn(p, BRW_OPCODE_HALT);
+   brw_set_dest(p, insn, retype(brw_null_reg(), BRW_REGISTER_TYPE_D));
+   brw_set_src0(p, insn, retype(brw_null_reg(), BRW_REGISTER_TYPE_D));
+   brw_set_src1(p, insn, brw_imm_d(0x0)); /* UIP and JIP, updated later. */
+
+   insn->header.compression_control = BRW_COMPRESSION_NONE;
+   insn->header.execution_size = BRW_EXECUTE_8;
+   return insn;
+}
+
 /* DO/WHILE loop:
  *
  * The DO/WHILE is just an unterminated loop -- break or continue are
@@ -2477,8 +2491,8 @@ brw_find_next_block_end(struct brw_compile *p, int start)
 return ip;
   }
}
-   assert(!"not reached");
-   return start + 1;
+
+   return 0;
 }
 
 /* There is no DO instruction on gen6, so to find the end of the loop
@@ -2507,7 +2521,7 @@ brw_find_loop_end(struct brw_compile *p, int start)
 }
 
 /* After program generation, go back and update the UIP and JIP of
- * BREAK and CONT instructions to their correct locations.
+ * BREAK, CONT, and HALT instructions to their correct locations.
  */
 void
 brw_set_uip_jip(struct brw_compile *p)
@@ -2521,21 +2535,50 @@ brw_set_uip_jip(struct brw_compile *p)
 
for (ip = 0; ip < p->nr_insn; ip++) {
   struct brw_instruction *insn = &p->store[ip];
+  int block_end_ip = 0;
+
+  if (insn->header.opcode == BRW_OPCODE_BREAK ||
+ insn->header.opcode == BRW_OPCODE_CONTINUE ||
+ insn->header.opcode == BRW_OPCODE_HALT) {
+block_end_ip = brw_find_next_block_end(p, ip);
+  }
 
   switch (insn->header.opcode) {
   case BRW_OPCODE_BREAK:
-insn->bits3.break_cont.jip = br * (brw_find_next_block_end(p, ip) - 
ip);
+assert(block_end_ip != 0);
+insn->bits3.break_cont.jip = br * (block_end_ip - ip);
 /* Gen7 UIP points to WHILE; Gen6 points just after it */
 insn->bits3.break_cont.uip =
br * (brw_find_loop_end(p, ip) - ip + (intel->gen == 6 ? 1 : 0));
 break;
   case BRW_OPCODE_CONTINUE:
-insn->bits3.break_cont.jip = br * (brw_find_next_block_end(p, ip) - 
ip);
+assert(block_end_ip != 0);
+insn->bits3.break_cont.jip = br * (block_end_ip - ip);
 insn->bits3.break_cont.uip = br * (brw_find_loop_end(p, ip) - ip);
 
 assert(insn->bits3.break_cont.uip != 0);
 assert(insn->bits3.break_cont.jip != 0);
 break;
+  case BRW_OPCODE_HALT:
+/* From the Sandy Bridge PRM (volume 4, part 2, section 8.3.19):
+ *
+ *"In case of the halt instruction not inside any conditional code
+ * block, the value of  and  should be the same. In case
+ * of the halt instruction inside conditional code block, the 
+ * should be the end of the program, and the  should be end of
+ * the most inner conditional code block."
+ *
+ * The uip will have already been set by whoever set up the
+ * instruction.
+ */
+if (block_end_ip == 0) {
+   insn->bits3.break_cont.jip = insn->bits3.break_cont.uip;
+} else {
+   insn->bits3.break_cont.jip = br * (block_end_ip - i

[Mesa-dev] [PATCH 6/9] glsl: Drop ftransform() from GLSL 1.40 profile.

2012-03-12 Thread Eric Anholt 
This is the one builtin function claimed to be dropped due to the
ARB_compatibility split.

Fixes piglit spec/GLSL-1.40/compiler/ftransform.vert
---
 src/glsl/builtins/profiles/140.vert |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/src/glsl/builtins/profiles/140.vert 
b/src/glsl/builtins/profiles/140.vert
index d9f5b4d..0fad767 100644
--- a/src/glsl/builtins/profiles/140.vert
+++ b/src/glsl/builtins/profiles/140.vert
@@ -328,8 +328,6 @@ vec2  normalize(vec2  x);
 vec3  normalize(vec3  x);
 vec4  normalize(vec4  x);
 
-vec4 ftransform();
-
 float faceforward(float N, float I, float Nref);
 vec2  faceforward(vec2  N, vec2  I, vec2  Nref);
 vec3  faceforward(vec3  N, vec3  I, vec3  Nref);
-- 
1.7.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 8/9] glsl: Set up generated builtin functions handling for GLSL 1.40.

2012-03-12 Thread Eric Anholt 
Otherwise, when we go to use ir_reader on the generated code, we won't
have the types present.
---
 src/glsl/builtins/tools/generate_builtins.py |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/glsl/builtins/tools/generate_builtins.py 
b/src/glsl/builtins/tools/generate_builtins.py
index 9ab6edd..9c1aeb5 100755
--- a/src/glsl/builtins/tools/generate_builtins.py
+++ b/src/glsl/builtins/tools/generate_builtins.py
@@ -162,14 +162,14 @@ read_builtins(GLenum target, const char *protos, const 
char **functions, unsigne
 {
struct gl_context fakeCtx;
fakeCtx.API = API_OPENGL;
-   fakeCtx.Const.GLSLVersion = 130;
+   fakeCtx.Const.GLSLVersion = 140;
fakeCtx.Extensions.ARB_ES2_compatibility = true;
gl_shader *sh = _mesa_new_shader(NULL, 0, target);
struct _mesa_glsl_parse_state *st =
   new(sh) _mesa_glsl_parse_state(&fakeCtx, target, sh);
 
-   st->language_version = 130;
-   st->symbols->language_version = 130;
+   st->language_version = 140;
+   st->symbols->language_version = 140;
st->ARB_texture_rectangle_enable = true;
st->EXT_texture_array_enable = true;
st->OES_EGL_image_external_enable = true;
-- 
1.7.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 7/9] glsl: Add support for integer sampler2DRect variants in GLSL 1.40.

2012-03-12 Thread Eric Anholt 
---
 src/glsl/builtin_types.h |   12 
 src/glsl/glsl_types.cpp  |   15 +--
 src/glsl/glsl_types.h|2 ++
 3 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/src/glsl/builtin_types.h b/src/glsl/builtin_types.h
index cc99b1b..890c121 100644
--- a/src/glsl/builtin_types.h
+++ b/src/glsl/builtin_types.h
@@ -259,6 +259,18 @@ const glsl_type *const glsl_type::uvec3_type = & 
builtin_130_types[2];
 const glsl_type *const glsl_type::uvec4_type = & builtin_130_types[3];
 /*@}*/
 
+
+/** \name Types added in GLSL 1.30
+ */
+/*@{*/
+const glsl_type glsl_type::builtin_140_types[] = {
+   glsl_type(GL_INT_SAMPLER_2D_RECT,
+GLSL_SAMPLER_DIM_RECT, 0, 0, GLSL_TYPE_INT, "isampler2DRect"),
+   glsl_type(GL_UNSIGNED_INT_SAMPLER_2D_RECT,
+GLSL_SAMPLER_DIM_RECT, 0, 0, GLSL_TYPE_UINT, "usampler2DRect"),
+};
+/*@}*/
+
 /** \name Sampler types added by GL_ARB_texture_rectangle
  */
 /*@{*/
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index a327197..4baec41 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -205,6 +205,16 @@ glsl_type::generate_130_types(glsl_symbol_table *symtab)
 
 
 void
+glsl_type::generate_140_types(glsl_symbol_table *symtab)
+{
+   generate_130_types(symtab);
+
+   add_types_to_symbol_table(symtab, builtin_140_types,
+Elements(builtin_140_types), false);
+}
+
+
+void
 glsl_type::generate_ARB_texture_rectangle_types(glsl_symbol_table *symtab,
bool warn)
 {
@@ -258,14 +268,15 @@ _mesa_glsl_initialize_types(struct _mesa_glsl_parse_state 
*state)
   glsl_type::generate_130_types(state->symbols);
   break;
case 140:
-  glsl_type::generate_130_types(state->symbols);
+  glsl_type::generate_140_types(state->symbols);
   break;
default:
   /* error */
   break;
}
 
-   if (state->ARB_texture_rectangle_enable) {
+   if (state->ARB_texture_rectangle_enable ||
+   state->language_version >= 140) {
   glsl_type::generate_ARB_texture_rectangle_types(state->symbols,
   state->ARB_texture_rectangle_warn);
}
diff --git a/src/glsl/glsl_types.h b/src/glsl/glsl_types.h
index 2997c93..8f2a3ff 100644
--- a/src/glsl/glsl_types.h
+++ b/src/glsl/glsl_types.h
@@ -498,6 +498,7 @@ private:
static const glsl_type builtin_110_types[];
static const glsl_type builtin_120_types[];
static const glsl_type builtin_130_types[];
+   static const glsl_type builtin_140_types[];
static const glsl_type builtin_ARB_texture_rectangle_types[];
static const glsl_type builtin_EXT_texture_array_types[];
static const glsl_type builtin_EXT_texture_buffer_object_types[];
@@ -517,6 +518,7 @@ private:
static void generate_110_types(glsl_symbol_table *);
static void generate_120_types(glsl_symbol_table *);
static void generate_130_types(glsl_symbol_table *);
+   static void generate_140_types(glsl_symbol_table *);
static void generate_ARB_texture_rectangle_types(glsl_symbol_table *, bool);
static void generate_EXT_texture_array_types(glsl_symbol_table *, bool);
static void generate_OES_texture_3D_types(glsl_symbol_table *, bool);
-- 
1.7.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 9/9] glsl: Add GLSL 1.40 textureSize() implementations for sampler2DRect.

2012-03-12 Thread Eric Anholt 
By setting lod to 0 in the builtin function implementation, we avoid
needing to update all the visitors to ignore LOD in this case, when
the hardware drivers actually want to ask for LOD 0 for rectangular
textures.

Fixes piglit spec/GLSL-1.40/textureSize-*Rect.
---
 src/glsl/builtins/profiles/140.frag |5 +
 src/glsl/builtins/profiles/140.vert |5 +
 src/glsl/builtins/tools/texture_builtins.py |   11 +--
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/src/glsl/builtins/profiles/140.frag 
b/src/glsl/builtins/profiles/140.frag
index 1bf6c75..da28473 100644
--- a/src/glsl/builtins/profiles/140.frag
+++ b/src/glsl/builtins/profiles/140.frag
@@ -499,6 +499,11 @@ ivec3 textureSize(usampler2DArray sampler, int lod);
 ivec2 textureSize(sampler1DArrayShadow sampler, int lod);
 ivec3 textureSize(sampler2DArrayShadow sampler, int lod);
 
+ivec2 textureSize(sampler2DRect sampler);
+ivec2 textureSize(isampler2DRect sampler);
+ivec2 textureSize(usampler2DRect sampler);
+ivec2 textureSize(sampler2DRectShadow sampler);
+
 /* texture - no bias */
  vec4 texture( sampler1D sampler, float P);
 ivec4 texture(isampler1D sampler, float P);
diff --git a/src/glsl/builtins/profiles/140.vert 
b/src/glsl/builtins/profiles/140.vert
index 0fad767..bfef4ed 100644
--- a/src/glsl/builtins/profiles/140.vert
+++ b/src/glsl/builtins/profiles/140.vert
@@ -499,6 +499,11 @@ ivec3 textureSize(usampler2DArray sampler, int lod);
 ivec2 textureSize(sampler1DArrayShadow sampler, int lod);
 ivec3 textureSize(sampler2DArrayShadow sampler, int lod);
 
+ivec2 textureSize(sampler2DRect sampler);
+ivec2 textureSize(isampler2DRect sampler);
+ivec2 textureSize(usampler2DRect sampler);
+ivec2 textureSize(sampler2DRectShadow sampler);
+
 /* texture */
  vec4 texture( sampler1D sampler, float P);
 ivec4 texture(isampler1D sampler, float P);
diff --git a/src/glsl/builtins/tools/texture_builtins.py 
b/src/glsl/builtins/tools/texture_builtins.py
index 07d0a1b..35571e8 100755
--- a/src/glsl/builtins/tools/texture_builtins.py
+++ b/src/glsl/builtins/tools/texture_builtins.py
@@ -71,7 +71,7 @@ def generate_sigs(g, tex_inst, sampler_type, variant = 0, 
unused_fields = 0):
 print "\n   (declare (in) " + vec_type("i" if tex_inst == "txf" 
else "", coord_dim + extra_dim) + " P)",
 if tex_inst == "txl":
 print "\n   (declare (in) float lod)",
-elif tex_inst == "txf" or tex_inst == "txs":
+elif tex_inst == "txf" or (tex_inst == "txs" and sampler_type.find("Rect") 
== -1):
 print "\n   (declare (in) int lod)",
 elif tex_inst == "txd":
 grad_type = vec_type("", coord_dim)
@@ -115,7 +115,12 @@ def generate_sigs(g, tex_inst, sampler_type, variant = 0, 
unused_fields = 0):
 # Bias/explicit LOD/gradient:
 if tex_inst == "txb":
 print "(var_ref bias)",
-elif tex_inst == "txl" or tex_inst == "txf" or tex_inst == "txs":
+elif tex_inst == "txs":
+if sampler_type.find("Rect") == -1:
+print "(var_ref lod)",
+else:
+print "(constant int (0))"
+elif tex_inst == "txl" or tex_inst == "txf":
 print "(var_ref lod)",
 elif tex_inst == "txd":
 print "((var_ref dPdx) (var_ref dPdy))",
@@ -153,6 +158,8 @@ def generate_texture_functions(fs):
 generate_sigs("", "txs", "CubeShadow")
 generate_sigs("", "txs", "1DArrayShadow")
 generate_sigs("", "txs", "2DArrayShadow")
+generate_fiu_sigs("txs", "2DRect")
+generate_sigs("", "txs", "2DRectShadow")
 end_function(fs, "textureSize")
 
 start_function("texture")
-- 
1.7.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i915: set SPRITE_POINT_ENABLE bit only for points

2012-03-12 Thread Yuanhan Liu 
On Mon, Mar 12, 2012 at 12:30:20PM -0700, Eric Anholt wrote:
> On Mon, 12 Mar 2012 16:04:01 +0800, Yuanhan Liu  
> wrote:
> > Signed-off-by: Yuanhan Liu 
> 
> Is there a reason for this change?  What test does it fix?

No big reason and it doesn't fix anyting so far. I made this patch for:
1. There is a comment so long ago at i915Enable() like this:
   /* This state change is handled in i915_reduced_primitive_state because   
* the hardware bit should only be set when rendering points.  
*/
   
   (A simple view of the history, it seems that it's Ian add this
comments but I see nowhere he did it)

2. It make sense to me to clear those bits for non-point prims.

> 
> The hardware docs I have say "This bit controls the generation of
> texture coordinates at the corners of point primitives. When ENABLED,
> the corners of the point primitive will be different..." suggesting that
> it doesn't affect non-points.

Yes, I just confirmed that. So, I'm fine to drop this patch.

Thanks,
Yuanhan Liu


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 47259] New: piglit fbo-blending-formats regression

2012-03-12 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=47259

 Bug #: 47259
   Summary: piglit fbo-blending-formats regression
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: v...@freedesktop.org


mesa: cc5b0ffae048824a6bdcaf43e0c8c2dd4a7ff14b (master)

piglit fbo-blending-formats fails on softpipe and llvmpipe.

$ ./bin/fbo-blending-formats -auto
Using test set: Core formats
Testing 3
Testing 4
Testing GL_RGB
Testing GL_RGBA
Testing GL_ALPHA
Testing GL_LUMINANCE
Probe at (10,0)
  Expected: 0.30 0.30 0.30 1.00
  Observed: 0.298039 0.00 0.00 1.00
  when testing FBO result, simple.
Probe at (32,0)
  Expected: 0.48 0.48 0.48 1.00
  Observed: 0.478431 0.00 0.00 1.00
  when testing FBO result, blending with CONSTANT_COLOR.
Probe at (53,0)
  Expected: 0.81 0.81 0.81 1.00
  Observed: 0.811765 0.00 0.00 1.00
  when testing FBO result, blending with DST_COLOR.
Probe at (74,0)
  Expected: 0.76 0.76 0.76 1.00
  Observed: 0.760784 0.00 0.00 1.00
  when testing FBO result, blending with SRC_COLOR.
Probe at (117,0)
  Expected: 0.76 0.76 0.76 1.00
  Observed: 0.760784 0.00 0.00 1.00
  when testing FBO result, blending with SRC_ALPHA.
Testing GL_LUMINANCE_ALPHA
Probe at (10,0)
  Expected: 0.30 0.30 0.30 0.00
  Observed: 0.298039 0.00 0.00 0.00
  when testing FBO result, simple.
Probe at (32,0)
  Expected: 0.48 0.48 0.48 0.50
  Observed: 0.478431 0.00 0.00 0.498039
  when testing FBO result, blending with CONSTANT_COLOR.
Probe at (53,0)
  Expected: 0.81 0.81 0.81 0.70
  Observed: 0.811765 0.00 0.00 0.701961
  when testing FBO result, blending with DST_COLOR.
Probe at (74,0)
  Expected: 0.76 0.76 0.76 0.74
  Observed: 0.760784 0.00 0.00 0.741176
  when testing FBO result, blending with SRC_COLOR.
Probe at (96,0)
  Expected: 0.85 0.85 0.85 0.70
  Observed: 0.850980 0.00 0.00 0.701961
  when testing FBO result, blending with DST_ALPHA.
Probe at (117,0)
  Expected: 0.76 0.76 0.76 0.74
  Observed: 0.760784 0.00 0.00 0.741176
  when testing FBO result, blending with SRC_ALPHA.
Testing GL_INTENSITY
Probe at (10,0)
  Expected: 0.30 0.30 0.30 0.30
  Observed: 0.298039 0.00 0.00 1.00
  when testing FBO result, simple.
Probe at (32,0)
  Expected: 0.48 0.48 0.48 0.48
  Observed: 0.478431 0.00 0.00 1.00
  when testing FBO result, blending with CONSTANT_COLOR.
Probe at (53,0)
  Expected: 0.81 0.81 0.81 0.81
  Observed: 0.811765 0.00 0.00 1.00
  when testing FBO result, blending with DST_COLOR.
Probe at (74,0)
  Expected: 0.76 0.76 0.76 0.76
  Observed: 0.760784 0.00 0.00 1.00
  when testing FBO result, blending with SRC_COLOR.
Probe at (96,0)
  Expected: 0.81 0.81 0.81 0.81
  Observed: 0.80 0.00 0.00 1.00
  when testing FBO result, blending with DST_ALPHA.
Probe at (117,0)
  Expected: 0.76 0.76 0.76 0.76
  Observed: 0.760784 0.00 0.00 1.00
  when testing FBO result, blending with SRC_ALPHA.
Testing GL_ALPHA4
Testing GL_ALPHA8
Testing GL_ALPHA12
Testing GL_ALPHA16
Testing GL_LUMINANCE4
Probe at (10,0)
  Expected: 0.30 0.30 0.30 1.00
  Observed: 0.298039 0.00 0.00 1.00
  when testing FBO result, simple.
Probe at (32,0)
  Expected: 0.48 0.48 0.48 1.00
  Observed: 0.478431 0.00 0.00 1.00
  when testing FBO result, blending with CONSTANT_COLOR.
Probe at (53,0)
  Expected: 0.81 0.81 0.81 1.00
  Observed: 0.811765 0.00 0.00 1.00
  when testing FBO result, blending with DST_COLOR.
Probe at (74,0)
  Expected: 0.76 0.76 0.76 1.00
  Observed: 0.760784 0.00 0.00 1.00
  when testing FBO result, blending with SRC_COLOR.
Probe at (117,0)
  Expected: 0.76 0.76 0.76 1.00
  Observed: 0.760784 0.00 0.00 1.00
  when testing FBO result, blending with SRC_ALPHA.
Testing GL_LUMINANCE8
Probe at (10,0)
  Expected: 0.30 0.30 0.30 1.00
  Observed: 0.298039 0.00 0.00 1.00
  when testing FBO result, simple.
Probe at (32,0)
  Expected: 0.48 0.48 0.48 1.00
  Observed: 0.478431 0.00 0.00 1.00
  when testing FBO result, blending with CONSTANT_COLOR.
Probe at (53,0)
  Expected: 0.81 0.81 0.81 1.00
  Observed: 0.811765 0.00 0.00 1.00
  when testing FBO result, blending with DST_COLOR.
Probe at (74,0)
  Expected: 0.

[Mesa-dev] [Bug 47259] piglit fbo-blending-formats regression

2012-03-12 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=47259

Vinson Lee  changed:

   What|Removed |Added

 CC||bri...@vmware.com,
   ||jfons...@vmware.com

--- Comment #1 from Vinson Lee  2012-03-12 22:42:25 PDT 
---
ad897fff7730298c21289768d9b1b55f3d166ac5 is the first bad commit
commit ad897fff7730298c21289768d9b1b55f3d166ac5
Author: Brian Paul 
Date:   Wed Feb 29 20:55:50 2012 -0700

mesa: use _mesa_rebase_rgba_float/uint() in glReadPixels code

See the comments for _mesa_rebase_rgba_float() for details.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=46679

NOTE: This is a candidate for the 8.0 branch.

Reviewed-by: José Fonseca 

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 47261] New: piglit fbo-luminance-alpha regression

2012-03-12 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=47261

 Bug #: 47261
   Summary: piglit fbo-luminance-alpha regression
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: v...@freedesktop.org


mesa: cc5b0ffae048824a6bdcaf43e0c8c2dd4a7ff14b (master)

piglit fbo-luminance-alpha fails on softpipe and llvmpipe.

$ ./bin/fbo-luminance-alpha -auto
Testing FBO result, simple 1.
Probe at (8,0)
  Expected: 0.30 0.30 0.30 0.00
  Observed: 0.298039 0.00 0.00 0.00
Testing FBO result, simple 2.
Probe at (24,0)
  Expected: 0.60 0.60 0.60 1.00
  Observed: 0.60 0.00 0.00 1.00
Testing FBO result, blending DST_ALPHA.
Probe at (40,0)
  Expected: 0.40 0.40 0.40 0.50
  Observed: 0.40 0.00 0.00 0.501961
Testing FBO result, blending SRC_ALPHA.
Probe at (56,0)
  Expected: 0.56 0.56 0.56 0.40
  Observed: 0.556863 0.00 0.00 0.40
Testing window result, simple 1.
Testing window result, simple 2.
Testing window result, blending DST_ALPHA.
Testing window result, blending SRC_ALPHA.
PIGLIT: {'result': 'fail' }

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 47261] piglit fbo-luminance-alpha regression

2012-03-12 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=47261

Vinson Lee  changed:

   What|Removed |Added

 CC||bri...@vmware.com,
   ||jfons...@vmware.com

--- Comment #1 from Vinson Lee  2012-03-12 23:14:00 PDT 
---
ad897fff7730298c21289768d9b1b55f3d166ac5 is the first bad commit
commit ad897fff7730298c21289768d9b1b55f3d166ac5
Author: Brian Paul 
Date:   Wed Feb 29 20:55:50 2012 -0700

mesa: use _mesa_rebase_rgba_float/uint() in glReadPixels code

See the comments for _mesa_rebase_rgba_float() for details.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=46679

NOTE: This is a candidate for the 8.0 branch.

Reviewed-by: José Fonseca 

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev