Re: [Mesa-dev] [RFC] Merging feature work to Mesa master

2012-02-16 Thread Dave Airlie
On Wed, Feb 15, 2012 at 11:28 PM, Ian Romanick  wrote:
> Over the last six months a lot of feature work has happened in Mesa, and the
> load has been carried by a lot of different people / organization. In the
> process, we discovered a number of development process issues that made
> things more difficult than they needed to be.

While I agree with the idea, I disagree with the rationale,

You state that it made extra work to figure out what had been done,
when really it
shouldn't if the person tasked with finishing the feature is following
this plan.

Since they would go out and read the spec, propose a test list, write the tests,
then see where the current percentage done code was on their test set, then
finish things off?

The fact anyone would believe that a 50% in GL3.txt was in any way meaningful,
like they are just rough guesses to say, this isn't finished, if
someone wants to finish
it then you'll need to look into it a bit more. It might be better to just say
WIP + username of last person to look at it instead of putting percentages in.

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


Re: [Mesa-dev] [PATCH v3 2/2] GLX_TLS: use TLS macros when define those TLS variables.

2012-02-16 Thread Kenneth Graunke

On 02/15/2012 04:58 AM, tf (mobile) wrote:

Personally i don't care much about non-autoconf builds, but as this relies on a 
-DTLS= setting during configuration time, it will break non-ac builds (which 
need tls), no?

Other than that, LGTM.

-tom


That's okay, we've already broken non-automake builds.  They're going 
away at last.  We should just go ahead and delete the old configs at 
some point.


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


[Mesa-dev] [Bug 41791] Civilization V + Wine = Bug

2012-02-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=41791

Marcus Meissner  changed:

   What|Removed |Added

 CC||mar...@jet.franken.de

--- Comment #6 from Marcus Meissner  2012-02-16 03:05:10 
PST ---
I opened suse bug:

https://bugzilla.novell.com/show_bug.cgi?id=747333

if you could install Mesa-debuginfo and Mesa-debugsource 
and get the baclktrace again?

-- 
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 v3 2/2] GLX_TLS: use TLS macros when define those TLS variables.

2012-02-16 Thread Brian Paul

On 02/16/2012 01:42 AM, Kenneth Graunke wrote:

On 02/15/2012 04:58 AM, tf (mobile) wrote:

Personally i don't care much about non-autoconf builds, but as this
relies on a -DTLS= setting during configuration time, it will break
non-ac builds (which need tls), no?

Other than that, LGTM.

-tom


That's okay, we've already broken non-automake builds. They're going
away at last. We should just go ahead and delete the old configs at
some point.


Please don't do that w/out fair warning.  I'd like to verify a few 
things with automake (osmesa, static lib builds, etc.) first.  I'll 
try to do that in my spare time, but I haven't had much lately.


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


Re: [Mesa-dev] [PATCH] mesa: fix an issue with texture border and array textures

2012-02-16 Thread Brian Paul

On 02/15/2012 05:39 PM, Anuj Phogat wrote:

As suggested by Brian, for a 1D texture array, the border only applies to
the width. For a 2D texture array the border applies to the width and
height but not to the depth.  This was not handled correctly in
_mesa_init_teximage_fields().

Note: This is a candidate for stable branches

Signed-off-by: Anuj Phogat
---
Tested the patch with piglit quick.tests. No regressions.

  src/mesa/main/teximage.c |8 ++--
  1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index e4eb7f6..d5f2650 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1083,11 +1083,13 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
 GLint border, GLenum internalFormat,
 gl_format format)
  {
+   GLenum target;
 ASSERT(img);
 ASSERT(width>= 0);
 ASSERT(height>= 0);
 ASSERT(depth>= 0);

+   target = img->TexObject->Target;
 img->_BaseFormat = _mesa_base_tex_format( ctx, internalFormat );
 ASSERT(img->_BaseFormat>  0);
 img->InternalFormat = internalFormat;
@@ -1099,7 +1101,8 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
 img->Width2 = width - 2 * border;   /* == 1<<  img->WidthLog2; */
 img->WidthLog2 = _mesa_logbase2(img->Width2);

-   if (height == 1) { /* 1-D texture */
+   if (target ==  GL_TEXTURE_1D ||
+   target ==  GL_TEXTURE_1D_ARRAY) { /* 1-D texture */
img->Height2 = 1;
img->HeightLog2 = 0;
 }


That's not quite right.  If the texture is 1D_ARRAY, the Height2 value 
is the height w/out border.  So:


   if (target ==  GL_TEXTURE_1D) {
  img->Height2 = 1;
  img->HeightLog2 = 0;
   }
   else if (target ==  GL_TEXTURE_1D_ARRAY) {
  img->Height2 = height; /* no border */
  img->HeightLog2 = 0; /* not used */
   }
   else {
  img->Height2 = height - 2 * border; /* == 1 << img->HeightLog2; */
  img->HeightLog2 = _mesa_logbase2(img->Height2);
   }




@@ -1108,7 +,8 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
img->HeightLog2 = _mesa_logbase2(img->Height2);
 }

-   if (depth == 1) {  /* 2-D texture */
+   if (target == GL_TEXTURE_2D ||
+   target == GL_TEXTURE_2D_ARRAY) {  /* 2-D texture */
img->Depth2 = 1;
img->DepthLog2 = 0;
 }


Same thing as above: for TEXTURE_2D_ARRAY, Depth2 = depth.

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


Re: [Mesa-dev] [RFC] Merging feature work to Mesa master

2012-02-16 Thread Brian Paul

On 02/15/2012 04:28 PM, Ian Romanick wrote:

Over the last six months a lot of feature work has happened in Mesa,
and the load has been carried by a lot of different people /
organization. In the process, we discovered a number of development
process issues that made things more difficult than they needed to be.

The biggest problem the we encountered was the number of features
marked "50% done" in GL3.txt. To complete these features, a
significant amount of time had to be spent figuring out what was done,
and what was left to do. Since the changes had landed on master a very
long time ago, this was a frustrating and error prone process.
Transform feedback was the worst case of this. One developer spent
several weeks trying to assess the state of development. In the
process, a couple items were missed and not detected until early January.


In the future the developer could just send an email to the person who 
last worked on the feature asking "what's the status of this?".  With 
git-blame it's easy to see who last touched a section of code or the 
corresponding line in the GL3.txt file.


I'd be happy to answer such queries and I think others would too.



PROPOSAL: No feature will be merged to master until a vertical
slice[1] of functionality is complete.

To be specific, this means that some useful workload should be able to
correctly execute. This doesn't mean that everything is done or even
that any particular real application needs to work. At the very least
there should be a demo or piglit test that uses the functionality in
its intended manner that works.

This means that some incomplete features may sit on branches of a long
time. That's okay! It's really easy to see what has been done on a
branch because you can 'git log origin/master..EXT_some_feature'. This
trivializes the assessment of the state of development.


This sounds good in general.  Are you concerned about the gallium code 
too?  Personally, I'm fine with Dave chipping away at GL 3 support in 
gallium (for example) without completing a full vertical slice.




We encountered similar problems with pieces of functionality that were
ostensibly done. Many elements of OpenGL functionality are like Koch
snowflakes: everything is a corner case. Integer textures and
floating-point textures are prime cases of this. Even though the
implementation was done and enabled in several drivers, we had no way
to assess the quality. The same problem holds in cases of features
that are known to be incomplete, even if a vertical slice is functional.

PROPOSAL: No feature will be merged to master until a robust set of
tests are implemented or at least documented.


Sounds good too.

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


Re: [Mesa-dev] [RFC] Merging feature work to Mesa master

2012-02-16 Thread Brian Paul

On 02/16/2012 01:04 AM, Dave Airlie wrote:

On Wed, Feb 15, 2012 at 11:28 PM, Ian Romanick  wrote:

Over the last six months a lot of feature work has happened in Mesa, and the
load has been carried by a lot of different people / organization. In the
process, we discovered a number of development process issues that made
things more difficult than they needed to be.


While I agree with the idea, I disagree with the rationale,

You state that it made extra work to figure out what had been done,
when really it
shouldn't if the person tasked with finishing the feature is following
this plan.

Since they would go out and read the spec, propose a test list, write the tests,
then see where the current percentage done code was on their test set, then
finish things off?

The fact anyone would believe that a 50% in GL3.txt was in any way meaningful,
like they are just rough guesses to say, this isn't finished, if
someone wants to finish
it then you'll need to look into it a bit more. It might be better to just say
WIP + username of last person to look at it instead of putting percentages in.


Yeah, I just figured documenting that feature X is 50% done was better 
than nothing.  Adding info about who last worked on the feature and/or 
which branch the work is sitting in would certainly be good.


Back when I started the GL3 work I was the only one doing so.  I was 
picking away at it in my spare time.  The whole GL3 development 
process changed when Intel took on the project.  Obviously, when a 
larger group of people needs to coordinate on a big set of features 
like that more detailed status info is needed.


One thing I'll say is that I think it's better when the status info is 
kept close to the code rather than on a web/wiki page that people 
forget about.  The further away documentation is from code, the more 
likely it'll be out of date.  Maybe we could make a new 
docs/development-status.html file that has detailed info about the 
status of new features.  The website could directly point to the file 
on cgit.freedesktop.org so it'll always be up to date for browsing.


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


Re: [Mesa-dev] [PATCH 1/2] mesa: Avoid computing fixed function texture state setup if possible.

2012-02-16 Thread Brian Paul

On 02/15/2012 07:01 PM, Eric Anholt wrote:

None of the consumers of this state will be called while the fs or vs
is in place, and the update_texture_state() call will get re-called on
fs/vs change, so it should be safe to skip the computation.  Improves
the performance of a VS state change microbenchmark by 1.60186% +/-
0.443318% (n=20).
---
  src/mesa/main/texstate.c |  117 +++--
  1 files changed, 70 insertions(+), 47 deletions(-)


This looks good.  Minor comment below.



diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
index 187ec9c..2dbf530 100644
--- a/src/mesa/main/texstate.c
+++ b/src/mesa/main/texstate.c
@@ -476,6 +476,68 @@ update_tex_combine(struct gl_context *ctx, struct 
gl_texture_unit *texUnit)
 }
  }



It would be good if the following two functions had comments 
indicating that the _ReallyEnabled and _EnabledCoordUnits field must 
have already been computed first (as well as any other dependencies).



+static void
+update_fffs_texture_state(struct gl_context *ctx)
+{
+   GLuint unit;
+
+   ctx->Texture._EnabledUnits = 0;
+   ctx->Texture._EnabledCoordUnits = 0;
+
+   for (unit = 0; unit<  ctx->Const.MaxCombinedTextureImageUnits; unit++) {
+  struct gl_texture_unit *texUnit =&ctx->Texture.Unit[unit];
+
+  if (!texUnit->_ReallyEnabled)
+continue;
+
+  ctx->Texture._EnabledUnits |= (1<<  unit);
+  ctx->Texture._EnabledCoordUnits |= (1<<  unit);
+
+  update_tex_combine(ctx, texUnit);
+   }
+}
+
+static void
+update_ffvs_texture_state(struct gl_context *ctx)
+{
+   GLuint unit;
+
+   ctx->Texture._GenFlags = 0x0;
+   ctx->Texture._TexMatEnabled = 0x0;
+   ctx->Texture._TexGenEnabled = 0x0;
+
+   /* Setup texgen for those texture coordinate sets that are in use */
+   for (unit = 0; unit<  ctx->Const.MaxTextureCoordUnits; unit++) {
+  struct gl_texture_unit *texUnit =&ctx->Texture.Unit[unit];
+
+  texUnit->_GenFlags = 0x0;
+
+  if (!(ctx->Texture._EnabledCoordUnits&  (1<<  unit)))
+continue;
+
+  if (texUnit->TexGenEnabled) {
+if (texUnit->TexGenEnabled&  S_BIT) {
+   texUnit->_GenFlags |= texUnit->GenS._ModeBit;
+}
+if (texUnit->TexGenEnabled&  T_BIT) {
+   texUnit->_GenFlags |= texUnit->GenT._ModeBit;
+}
+if (texUnit->TexGenEnabled&  R_BIT) {
+   texUnit->_GenFlags |= texUnit->GenR._ModeBit;
+}
+if (texUnit->TexGenEnabled&  Q_BIT) {
+   texUnit->_GenFlags |= texUnit->GenQ._ModeBit;
+}
+
+ctx->Texture._TexGenEnabled |= ENABLE_TEXGEN(unit);
+ctx->Texture._GenFlags |= texUnit->_GenFlags;
+  }
+
+  ASSERT(unit<  Elements(ctx->TextureMatrixStack));
+  if (ctx->TextureMatrixStack[unit].Top->type != MATRIX_IDENTITY)
+ctx->Texture._TexMatEnabled |= ENABLE_TEXMAT(unit);
+   }
+}

  /**
   * \note This routine refers to derived texture matrix values to
@@ -491,7 +553,6 @@ update_texture_state( struct gl_context *ctx )
 GLuint unit;
 struct gl_program *fprog = NULL;
 struct gl_program *vprog = NULL;
-   GLbitfield enabledFragUnits = 0x0;

 if (ctx->Shader.CurrentVertexProgram&&
 ctx->Shader.CurrentVertexProgram->LinkStatus) {
@@ -518,11 +579,6 @@ update_texture_state( struct gl_context *ctx )
 /* TODO: only set this if there are actual changes */
 ctx->NewState |= _NEW_TEXTURE;

-   ctx->Texture._EnabledUnits = 0x0;
-   ctx->Texture._GenFlags = 0x0;
-   ctx->Texture._TexMatEnabled = 0x0;
-   ctx->Texture._TexGenEnabled = 0x0;
-
 /*
  * Update texture unit state.
  */
@@ -601,59 +657,26 @@ update_texture_state( struct gl_context *ctx )
  continue;
   }
}
-
-  /* if we get here, we know this texture unit is enabled */
-
-  ctx->Texture._EnabledUnits |= (1<<  unit);
-
-  if (enabledFragTargets)
- enabledFragUnits |= (1<<  unit);
-
-  update_tex_combine(ctx, texUnit);
 }


 /* Determine which texture coordinate sets are actually needed */
 if (fprog) {
const GLuint coordMask = (1<<  MAX_TEXTURE_COORD_UNITS) - 1;
+  /* Note that this gets consumed by update_ffvs_texture_state(). */
ctx->Texture._EnabledCoordUnits
   = (fprog->InputsRead>>  FRAG_ATTRIB_TEX0)&  coordMask;
 }
 else {
-  ctx->Texture._EnabledCoordUnits = enabledFragUnits;
+  update_fffs_texture_state(ctx);
 }

-   /* Setup texgen for those texture coordinate sets that are in use */
-   for (unit = 0; unit<  ctx->Const.MaxTextureCoordUnits; unit++) {
-  struct gl_texture_unit *texUnit =&ctx->Texture.Unit[unit];
-
-  texUnit->_GenFlags = 0x0;
-
-  if (!(ctx->Texture._EnabledCoordUnits&  (1<<  unit)))
-continue;
-
-  if (texUnit->TexGenEnabled) {
-if (texUnit->TexGenEnabled&  S_BIT) {
-   texUnit->_GenFlags |= texUnit->GenS._ModeBit;
-}
-if (texUnit->TexGenEnabled&  T_BIT) {
-   texUnit->_

Re: [Mesa-dev] [PATCH 2/2] mesa: Only flag _NEW_TEXTURE on texture updates when a texture changes.

2012-02-16 Thread Brian Paul

On 02/15/2012 07:01 PM, Eric Anholt wrote:

There are three reasons left for this function flagging it:
Re-computing completeness (and therefore the number of levels),
binding a new current texture object, or you're doing some sort of
fixed function (and nobody cares).  For other cases, like rebinding a
shader, we no longer trigger the driver recomputing every piece of
texture state.

Improves a VS state change microbenchmark by 14.8284% +/- 1.02% (n=10)
on gen7.  On the other hand, it causes GPU hangs on nexuiz.  Any clue
why this might be insufficient?


If you're asking: "why do we have to recompute texture state when 
binding a different fragment shader?"


One case is if fragment shader A calls texture2D() while shader B 
calls textureCube().  Depending on the shader, the _Current texture 
object would be different.




---
  src/mesa/main/texstate.c |   34 ++
  1 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
index 2dbf530..86b8b3d 100644
--- a/src/mesa/main/texstate.c
+++ b/src/mesa/main/texstate.c
@@ -577,7 +577,6 @@ update_texture_state( struct gl_context *ctx )
  */

 /* TODO: only set this if there are actual changes */
-   ctx->NewState |= _NEW_TEXTURE;

 /*
  * Update texture unit state.
@@ -588,6 +587,7 @@ update_texture_state( struct gl_context *ctx )
GLbitfield enabledFragTargets = 0x0;
GLbitfield enabledTargets = 0x0;
GLuint texIndex;
+  struct gl_texture_object *oldObj = texUnit->_Current;

/* Get the bitmask of texture target enables.
 * enableBits will be a mask of the TEXTURE_*_BIT flags indicating
@@ -609,10 +609,18 @@ update_texture_state( struct gl_context *ctx )

enabledTargets = enabledVertTargets | enabledFragTargets;

+  /* This is not flagged with _NEW_TEXTURE, because the test for changing 
of
+   * the _Current texture object will cover every case where _ReallyEnabled
+   * could have changed.
+   */
texUnit->_ReallyEnabled = 0x0;

if (enabledTargets == 0x0) {
   /* neither vertex nor fragment processing uses this unit */
+if (texUnit->_ReallyEnabled) {
+   ctx->NewState |= _NEW_TEXTURE;
+   texUnit->_ReallyEnabled = 0x0;
+}
   continue;
}

@@ -626,6 +634,10 @@ update_texture_state( struct gl_context *ctx )
   if (enabledTargets&  (1<<  texIndex)) {
  struct gl_texture_object *texObj = texUnit->CurrentTex[texIndex];
  if (!texObj->_Complete) {
+  /* While _Complete is only consumed by us, this call also updates
+ _MaxLevel, which drivers do need to see.
+   */


_Complete is also used by the gallium state tracker.



+  ctx->NewState |= _NEW_TEXTURE;
 _mesa_test_texobj_completeness(ctx, texObj);
  }
  if (texObj->_Complete) {
@@ -652,22 +664,26 @@ update_texture_state( struct gl_context *ctx )
  _mesa_reference_texobj(&texUnit->_Current, texObj);
  texUnit->_ReallyEnabled = 1<<  texTarget;
   }
- else {
-/* fixed-function: texture unit is really disabled */
-continue;
- }
}
+
+  if (oldObj != texUnit->_Current)
+ctx->NewState |= _NEW_TEXTURE;
 }


 /* Determine which texture coordinate sets are actually needed */
 if (fprog) {
const GLuint coordMask = (1<<  MAX_TEXTURE_COORD_UNITS) - 1;
+  GLuint new_coord_units = ((fprog->InputsRead>>  FRAG_ATTRIB_TEX0)&
+   coordMask);
/* Note that this gets consumed by update_ffvs_texture_state(). */
-  ctx->Texture._EnabledCoordUnits
- = (fprog->InputsRead>>  FRAG_ATTRIB_TEX0)&  coordMask;
+  if (ctx->Texture._EnabledCoordUnits != new_coord_units) {
+ctx->NewState |= _NEW_TEXTURE;
+ctx->Texture._EnabledCoordUnits = new_coord_units;
+  }
 }
 else {
+  ctx->NewState |= _NEW_TEXTURE;
update_fffs_texture_state(ctx);
 }

@@ -675,8 +691,10 @@ update_texture_state( struct gl_context *ctx )
  * program.  Those state flags are only used in the case of fixed function
  * vertex shading, in the tnl pipeline or ff_vertex_shader.
  */
-   if (!vprog)
+   if (!vprog) {
+  ctx->NewState |= _NEW_TEXTURE;
update_ffvs_texture_state(ctx);
+   }
  }




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


Re: [Mesa-dev] [PATCH] mesa: add missing texture integer test in glTexSubImage()

2012-02-16 Thread Eric Anholt
On Wed, 15 Feb 2012 15:41:01 -0700, Brian Paul  wrote:
> If the texture format is integer, the incoming user data must also be
> integer (and similarly for non-integer textures).
> 
> NOTE: This is a candidate for the stable branches.
> ---
>  src/mesa/main/teximage.c |   11 +++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index e4eb7f6..a3ffb01 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -1852,6 +1852,17 @@ subtexture_error_check2( struct gl_context *ctx, 
> GLuint dimensions,
>} 
> }
>  
> +   if (ctx->VersionMajor >= 3 || ctx->Extensions.EXT_texture_integer) {
> +  /* both source and dest must be integer-valued, or neither */
> +  if (_mesa_is_format_integer_color(destTex->TexFormat) !=
> +  _mesa_is_integer_format(format)) {
> + _mesa_error(ctx, GL_INVALID_OPERATION,
> + "glTexSubImage%d(integer/non-integer format mismatch)",
> + dimensions);
> + return GL_TRUE;
> +  }
> +   }
> +

Reviewed-by: Eric Anholt 


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


Re: [Mesa-dev] [RFC] Merging feature work to Mesa master

2012-02-16 Thread Paul Berry
On 15 February 2012 15:28, Ian Romanick  wrote:

> Over the last six months a lot of feature work has happened in Mesa, and
> the load has been carried by a lot of different people / organization. In
> the process, we discovered a number of development process issues that made
> things more difficult than they needed to be.
>
> The biggest problem the we encountered was the number of features marked
> "50% done" in GL3.txt.  To complete these features, a significant amount of
> time had to be spent figuring out what was done, and what was left to do.
>  Since the changes had landed on master a very long time ago, this was a
> frustrating and error prone process.  Transform feedback was the worst case
> of this.  One developer spent several weeks trying to assess the state of
> development.  In the process, a couple items were missed and not detected
> until early January.
>
> PROPOSAL: No feature will be merged to master until a vertical slice[1] of
> functionality is complete.
>
> To be specific, this means that some useful workload should be able to
> correctly execute.  This doesn't mean that everything is done or even that
> any particular real application needs to work.  At the very least there
> should be a demo or piglit test that uses the functionality in its intended
> manner that works.
>
> This means that some incomplete features may sit on branches of a long
> time.  That's okay!  It's really easy to see what has been done on a branch
> because you can 'git log origin/master..EXT_some_**feature'.  This
> trivializes the assessment of the state of development.
>
> We encountered similar problems with pieces of functionality that were
> ostensibly done.  Many elements of OpenGL functionality are like Koch
> snowflakes:  everything is a corner case.  Integer textures and
> floating-point textures are prime cases of this.  Even though the
> implementation was done and enabled in several drivers, we had no way to
> assess the quality.  The same problem holds in cases of features that are
> known to be incomplete, even if a vertical slice is functional.
>
> PROPOSAL: No feature will be merged to master until a robust set of tests
> are implemented or at least documented.
>
> We don't necessarily need 10,000 tests for some feature, but there should
> be some.  There should also be a list of "test this corner case, test that
> corner case, check this error condition, etc."  As an example, we've come
> up with a list of missing test cases for EXT_framebuffer_multisample:
>
> - Test turning multisample on and off on a MSAA buffer.
> - Test multisample points smooth
> - Test multisample points non-smooth
> - Test multisample lines smooth
> - Test multisample lines non-smooth
> - Test multisample line stipple
> - Test multisample polygon smooth
> - Test multisample polygon stipple
> - Test multisample glBitmap
> - Test sample alpha to one
> - Test sample coverage
> - Test sample coverage invert
> - Test sample alpha-to-coverage, with alpha-to-one
> - Test sample alpha-to-coverage, without alpha-to-one
> - Test blit multisample-to-multisample (matching sample count)
> - Test blit multisample-to-multisample (non-matching sample count)
> - Test blit multisample-to-multisample (non-matching format)
> - Test blit singlesample-to-multisample
> - Test blit multisample-to-multisample (scaling blit)
> - Iterate all the above for all the sample counts
> - Iterate all internal formats for some basic MSAA test
> - "All of the above" for depth and stencil
>- Try really hard to hit HiZ resolves too
>
> This list represents about 30 or 40 test cases.  By giving some indication
> of areas that need testing, we communicate the parts of the feature that
> are known to be incomplete or just plain broken (Keith's 1st Law: Any piece
> of code that isn't tested is broken.).
>
> The test list also need not necessarily come from the developer.  It is
> completely reasonable and desirable for reviewers to suggest or implement
> tests.  All of that information just needs to be captured, and consensus
> must be achieved.
>
> The onus of enforcing these proposals will fall on the reviewers.  This
> still leaves room for sensible things to happen while preventing the
> problems that we encountered.  For example, it should be fine to merge
> Marek and nobled's ARB_debug work with few tests implemented or specified.
>  The same could not be said for the proposed implementation of
> ARB_uniform_buffer_object.
>
> [1] 
> http://en.wikipedia.org/wiki/**Vertical_slice
> __**_
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/**mailman/listinfo/mesa-dev
>

To add some concreteness to the discussion, I went back through all of my
git commits from the last several months to see where, specifically, I had
to make unexpected fixes to code that others had only pa

Re: [Mesa-dev] [RFC] Merging feature work to Mesa master

2012-02-16 Thread Dave Airlie
>
> 1. Missing checks for error conditions that the spec requires an
> implementation to check for.
>
> 2. Newly-added state is not being saved/restored properly by meta-ops.
>
> 3. Overzealous error checks: some error condition is not being checked for
> in the correct way, causing an error to be generated even for correct input.
>
> 4. API Functions neglecting to set ctx->NewState when necessary, so the
> driver fails to notice that state has changed.
>
> IMHO, Ian's proposals, or some variant of them, would be useful because they
> directly address pain points like the ones above.  For instance, requiring
> complete vertical slices of functionality would help with 3 and 4, because
> it would ensure that at the time state was added to the front-end, we could
> easily test that things propagated properly to the back-end.  And requiring
> a robust set of tests would help with 1 and 2, because any adequately robust
> set of tests for a feature would include testing error conditions and
> meta-op behaviour.

The meta-op stuff is a misnomer, only Intel use the metaops in terms
of drivers people are developing.

also I think the gallium stuff won't always mean we miss a
ctx->NewState, until someone cleans up a lot more :)

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


[Mesa-dev] [PATCH] mesa: fix an issue with texture border and array textures

2012-02-16 Thread Anuj Phogat
As suggested by Brian, for a 1D texture array, the border only applies to
the width.  For a 2D texture array the border applies to the width and
height but not the depth.  This was not handled correctly in
_mesa_init_teximage_fields().

Note: This is a candidate for stable branches

Signed-off-by: Anuj Phogat 
---
updated patch as per Brian's comments

 src/mesa/main/teximage.c |   14 --
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index e4eb7f6..6a24e9d 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1083,11 +1083,13 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
GLint border, GLenum internalFormat,
gl_format format)
 {
+   GLenum target;
ASSERT(img);
ASSERT(width >= 0);
ASSERT(height >= 0);
ASSERT(depth >= 0);
 
+   target = img->TexObject->Target;
img->_BaseFormat = _mesa_base_tex_format( ctx, internalFormat );
ASSERT(img->_BaseFormat > 0);
img->InternalFormat = internalFormat;
@@ -1099,19 +1101,27 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
img->Width2 = width - 2 * border;   /* == 1 << img->WidthLog2; */
img->WidthLog2 = _mesa_logbase2(img->Width2);
 
-   if (height == 1) { /* 1-D texture */
+   if (target ==  GL_TEXTURE_1D) {
   img->Height2 = 1;
   img->HeightLog2 = 0;
}
+   else if(target ==  GL_TEXTURE_1D_ARRAY) {
+  img->Height2 = height; /* no border */
+  img->HeightLog2 = 0; /* not used */
+   }
else {
   img->Height2 = height - 2 * border; /* == 1 << img->HeightLog2; */
   img->HeightLog2 = _mesa_logbase2(img->Height2);
}
 
-   if (depth == 1) {  /* 2-D texture */
+   if (target == GL_TEXTURE_2D) {
   img->Depth2 = 1;
   img->DepthLog2 = 0;
}
+   else if (target == GL_TEXTURE_2D_ARRAY) {
+  img->Depth2 = depth; /* no border */
+  img->DepthLog2 = 0; /* not used */
+   }
else {
   img->Depth2 = depth - 2 * border;   /* == 1 << img->DepthLog2; */
   img->DepthLog2 = _mesa_logbase2(img->Depth2);
-- 
1.7.7.6

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


Re: [Mesa-dev] [PATCH] mesa: fix an issue with texture border and array textures

2012-02-16 Thread Brian Paul

On 02/16/2012 11:38 AM, Anuj Phogat wrote:

As suggested by Brian, for a 1D texture array, the border only applies to
the width.  For a 2D texture array the border applies to the width and
height but not the depth.  This was not handled correctly in
_mesa_init_teximage_fields().

Note: This is a candidate for stable branches

Signed-off-by: Anuj Phogat
---
updated patch as per Brian's comments

  src/mesa/main/teximage.c |   14 --
  1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index e4eb7f6..6a24e9d 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1083,11 +1083,13 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
 GLint border, GLenum internalFormat,
 gl_format format)
  {
+   GLenum target;
 ASSERT(img);
 ASSERT(width>= 0);
 ASSERT(height>= 0);
 ASSERT(depth>= 0);

+   target = img->TexObject->Target;
 img->_BaseFormat = _mesa_base_tex_format( ctx, internalFormat );
 ASSERT(img->_BaseFormat>  0);
 img->InternalFormat = internalFormat;
@@ -1099,19 +1101,27 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
 img->Width2 = width - 2 * border;   /* == 1<<  img->WidthLog2; */
 img->WidthLog2 = _mesa_logbase2(img->Width2);

-   if (height == 1) { /* 1-D texture */
+   if (target ==  GL_TEXTURE_1D) {


or target == GL_TEXTURE_BUFFER


img->Height2 = 1;
img->HeightLog2 = 0;
 }
+   else if(target ==  GL_TEXTURE_1D_ARRAY) {
+  img->Height2 = height; /* no border */
+  img->HeightLog2 = 0; /* not used */
+   }
 else {
img->Height2 = height - 2 * border; /* == 1<<  img->HeightLog2; */
img->HeightLog2 = _mesa_logbase2(img->Height2);
 }

-   if (depth == 1) {  /* 2-D texture */
+   if (target == GL_TEXTURE_2D) {
img->Depth2 = 1;
img->DepthLog2 = 0;
 }
+   else if (target == GL_TEXTURE_2D_ARRAY) {
+  img->Depth2 = depth; /* no border */
+  img->DepthLog2 = 0; /* not used */
+   }
 else {
img->Depth2 = depth - 2 * border;   /* == 1<<  img->DepthLog2; */
img->DepthLog2 = _mesa_logbase2(img->Depth2);


This will set Depth2, etc incorrectly if the texture target is 1D, 
1D_ARRAY, CUBE, etc.


I think you need to carefully consider all the possible texture 
targets and how width/height/depth will be computed for each type.


It might wind up being cleanest to have a switch(target) which sets 
both the width and height values for each possible texture type.


Or maybe just leave the "if (height==1)" and "if (depth==1)" tests 
as-is.  I'd have to take a few minutes to think that through.


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


[Mesa-dev] VBO fixes [v2]

2012-02-16 Thread Kenneth Graunke
Here's a respin of the VBO fixes, incorporating feedback from Roland,
Brian, and Ian.

I'm not entirely happy with this series.  If you look at the resulting
code, we end up marking the range invalid if:

1. (int) start + basevertex < 0
2. (int) end   + basevertex < 0
3. start + basevertex >= _MaxElement
4. end   + basevertex >= _MaxElement

but in two separate blocks.

Mesa master emits a warning about case 4, which this series removes.
This series causes a warning to be emitted for 2 and 3.  No warning
is ever emitted for case 1.

Prior to this series, Mesa didn't do 1 and 2 (the < 0 checks) at all.

I'm tempted to just throw out all of these checks and just do:

   if (all_vbo_rendering) /* all VBOs, no user-space arrays at all */
  index_bounds_valid = false;

since the whole DrawRangeElements optimization is basically irrelevant
for VBOs.  Cases 3 and 4 should only happen for VBOs anyway, as
_MaxElement is set to 2,000,000,000 for user-space arrays.

I don't think we have many (any?) tests for these corner cases, so I'm
a bit hesitant about changing this.

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


[Mesa-dev] [PATCH 1/4] vbo: Remove pedantic warning about 'end' beind out of bounds.

2012-02-16 Thread Kenneth Graunke
The application supplied [start, end] range is merely a conservative
hint of the ranges of index values inside the index buffer.  There is no
requirement that all vertices in the range [start, end] be referenced.

Passing an 'end' value larger than the maximum legal index is perfectly
acceptible; applications can legally pass 0x when they don't
have a tighter bound readily available.

Thus, the warning doesn't indicate a correctness issue; it could only
indicate a performance issue.  However, it does not even do that.

glDrawRangeElements is designed to optimize non-VBO vertex data uploads
by providing an upper bound on the size of buffers a driver would need
to allocate.  With VBOs, the data is already in an uploaded buffer, so
the range doesn't help.

The clincher is: we only know _MaxElement for VBOs.  For user-space
arrays, we just set it to 2,000,000,000 (see mesa/main/varray.h:63.)
So we can only check this in the case where it is not useful.

Many applications, including the Unigine demos, currently trigger this
warning, which suggests the applications are buggy when they're actually
fine.  Eliminating the warning should confuse users less while not
actually losing any benefit to application developers.

NOTE: This is a candidate for release branches.

Suggested-by: Jose Fonseca 
Signed-off-by: Kenneth Graunke 
Reviewed-by: Brian Paul 
---
 src/mesa/vbo/vbo_exec_array.c |   49 +---
 1 files changed, 2 insertions(+), 47 deletions(-)

diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index d6b4d61..ec4cb4f 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -708,6 +708,7 @@ vbo_exec_DrawArraysInstanced(GLenum mode, GLint start, 
GLsizei count,
  * Map GL_ELEMENT_ARRAY_BUFFER and print contents.
  * For debugging.
  */
+#if 0
 static void
 dump_element_buffer(struct gl_context *ctx, GLenum type)
 {
@@ -759,6 +760,7 @@ dump_element_buffer(struct gl_context *ctx, GLenum type)
 
ctx->Driver.UnmapBuffer(ctx, ctx->Array.ArrayObj->ElementArrayBufferObj);
 }
+#endif
 
 
 /**
@@ -856,7 +858,6 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
 const GLvoid *indices,
 GLint basevertex)
 {
-   static GLuint warnCount = 0;
GET_CURRENT_CONTEXT(ctx);
 
if (MESA_VERBOSE & VERBOSE_DRAW)
@@ -886,52 +887,6 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
}
 
if (end >= ctx->Array.ArrayObj->_MaxElement) {
-  /* the max element is out of bounds of one or more enabled arrays */
-  warnCount++;
-
-  if (warnCount < 10) {
- _mesa_warning(ctx, "glDraw[Range]Elements(start %u, end %u, count %d, 
"
-   "type 0x%x, indices=%p)\n"
-   "\tend is out of bounds (max=%u)  "
-   "Element Buffer %u (size %d)\n"
-   "\tThis should probably be fixed in the application.",
-   start, end, count, type, indices,
-   ctx->Array.ArrayObj->_MaxElement - 1,
-   ctx->Array.ArrayObj->ElementArrayBufferObj->Name,
-   (int) ctx->Array.ArrayObj->ElementArrayBufferObj->Size);
-  }
-
-  if (0)
- dump_element_buffer(ctx, type);
-
-  if (0)
- _mesa_print_arrays(ctx);
-
-  /* 'end' was out of bounds, but now let's check the actual array
-   * indexes to see if any of them are out of bounds.
-   */
-  if (0) {
- GLuint max = _mesa_max_buffer_index(ctx, count, type, indices,
- 
ctx->Array.ArrayObj->ElementArrayBufferObj);
- if (max >= ctx->Array.ArrayObj->_MaxElement) {
-if (warnCount < 10) {
-   _mesa_warning(ctx, "glDraw[Range]Elements(start %u, end %u, "
- "count %d, type 0x%x, indices=%p)\n"
- "\tindex=%u is out of bounds (max=%u)  "
- "Element Buffer %u (size %d)\n"
- "\tSkipping the glDrawRangeElements() call",
- start, end, count, type, indices, max,
- ctx->Array.ArrayObj->_MaxElement - 1,
- ctx->Array.ArrayObj->ElementArrayBufferObj->Name,
- (int) 
ctx->Array.ArrayObj->ElementArrayBufferObj->Size);
-}
- }
- /* XXX we could also find the min index and compare to 'start'
-  * to see if start is correct.  But it's more likely to get the
-  * upper bound wrong.
-  */
-  }
-
   /* Set 'end' to the max possible legal value */
   assert(ctx->Array.ArrayObj->_MaxElement >= 1);
   end = ctx->Array.ArrayObj->_MaxElement - 1;
-- 
1.7.7.6

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

[Mesa-dev] [PATCH 2/4] vbo: Ignore invalid element ranges which are outside VBO bounds.

2012-02-16 Thread Kenneth Graunke
Some applications, such as Regnum Online, appear to pass invalid
start/end values to glDrawRangeElements.  In particular, the 'start'
index sometimes exceeds the maximum array element.  This is clearly
invalid behavior, and although the spec isn't clear, seems to result
in undefined, implementation-specific behavior.

This patch takes the conservative approach and simply ignores the range,
while issuing a warning indicating that the application is broken and
should be fixed.

NOTE: This is a candidate for release branches.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45214
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44701
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41152
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40361
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28138
Signed-off-by: Kenneth Graunke 
Reviewed-by: Brian Paul  [v1]

v2: Use (int) end + basevertex < 0 instead of (int)(start + basevertex).
Change to end suggested by Roland (and Ian agrees); casting change
suggested by Brian.

Also pass 0, ~0 as the bounds as suggested by Brian.  This shouldn't
matter since the GL_FALSE means they aren't valid, and oddly doesn't
match vbo_exec_DrawArrays or vbo_exec_DrawArraysBaseVertex, but
makes a ton more sense.
---
 src/mesa/vbo/vbo_exec_array.c |   25 +
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index ec4cb4f..9c20296 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -858,6 +858,7 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
 const GLvoid *indices,
 GLint basevertex)
 {
+   static GLuint warnCount = 0;
GET_CURRENT_CONTEXT(ctx);
 
if (MESA_VERBOSE & VERBOSE_DRAW)
@@ -870,6 +871,30 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
   type, indices, basevertex ))
   return;
 
+   if ((int) end + basevertex < 0 ||
+   start + basevertex >= ctx->Array.ArrayObj->_MaxElement) {
+  /* The application requested we draw using a range of indices that's
+   * outside the bounds of the current VBO.  This is invalid and appears
+   * to give undefined results.  The safest thing to do is to simply
+   * ignore the range, in case the application botched their range tracking
+   * but did provide valid indices.  Also issue a warning indicating that
+   * the application is broken.
+   */
+  if (warnCount++ < 10) {
+ _mesa_warning(ctx, "glDrawRangeElements(start %u, end %u, "
+   "basevertex %d, count %d, type 0x%x, indices=%p):\n"
+   "\trange is outside VBO bounds (max=%u); ignoring.\n"
+   "\tThis should be fixed in the application.",
+   start, end, basevertex, count, type, indices,
+   ctx->Array.ArrayObj->_MaxElement - 1);
+  }
+
+  /* Just do an ordinary glDrawElementsBaseVertex(). */
+  vbo_validated_drawrangeelements(ctx, mode, GL_FALSE, 0, ~0,
+  count, type, indices, basevertex, 1);
+  return;
+   }
+
/* NOTE: It's important that 'end' is a reasonable value.
 * in _tnl_draw_prims(), we use end to determine how many vertices
 * to transform.  If it's too large, we can unnecessarily split prims
-- 
1.7.7.6

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


[Mesa-dev] [PATCH 3/4] vbo: Rework checking of 'end' against _MaxElement.

2012-02-16 Thread Kenneth Graunke
This failed to take basevertex into account:

If basevertex < 0:
   (end + basevertex) might actually be in-bounds while 'end' is not.
   We would have clamped in this case when we probably shouldn't.
   This could break application drawing.

If basevertex > 0:
   'end' might be in-bounds while (end + basevertex) might not.
   We would have failed to clamp in this place.  There's a comment
   indicating the TNL module depends on max_index being in-bounds;
   if so, it would likely break horribly.

Rather than trying to clamp correctly in the face of basevertex, simply
delete the clamping code and indicate that we don't have a valid range.
This causes _tnl_vbo_draw_prims to use vbo_get_minmax_indices() to
compute the actual bounds, which is much safer.

NOTE: This is a candidate for release branches.

Signed-off-by: Kenneth Graunke 
Reviewed-by: Brian Paul 

v2: Check (int) start + basevertex < 0 instead of (int)(end+basevertex).
Change to use 'end' suggested by Roland; casting change suggested by
Brian.
---
 src/mesa/vbo/vbo_exec_array.c |   17 ++---
 1 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 9c20296..809804f 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -859,6 +859,7 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
 GLint basevertex)
 {
static GLuint warnCount = 0;
+   GLboolean index_bounds_valid = GL_TRUE;
GET_CURRENT_CONTEXT(ctx);
 
if (MESA_VERBOSE & VERBOSE_DRAW)
@@ -911,16 +912,6 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
   end = MIN2(end, 0x);
}
 
-   if (end >= ctx->Array.ArrayObj->_MaxElement) {
-  /* Set 'end' to the max possible legal value */
-  assert(ctx->Array.ArrayObj->_MaxElement >= 1);
-  end = ctx->Array.ArrayObj->_MaxElement - 1;
-
-  if (end < start) {
- return;
-  }
-   }
-
if (0) {
   printf("glDraw[Range]Elements{,BaseVertex}"
 "(start %u, end %u, type 0x%x, count %d) ElemBuf %u, "
@@ -930,13 +921,17 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
 basevertex);
}
 
+   if ((int) start + basevertex < 0 ||
+   end + basevertex >= ctx->Array.ArrayObj->_MaxElement)
+  index_bounds_valid = GL_FALSE;
+
 #if 0
check_draw_elements_data(ctx, count, type, indices);
 #else
(void) check_draw_elements_data;
 #endif
 
-   vbo_validated_drawrangeelements(ctx, mode, GL_TRUE, start, end,
+   vbo_validated_drawrangeelements(ctx, mode, index_bounds_valid, start, end,
   count, type, indices, basevertex, 1);
 }
 
-- 
1.7.7.6

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


[Mesa-dev] [PATCH 4/4] vbo: Eliminate short-circuiting in invalid-start case.

2012-02-16 Thread Kenneth Graunke
Now that we have a index_range_invalid flag, we can just use that rather
than calling vbo_validated_drawrangeelements directly and returning.

NOTE: This is a candidate for release branches.

Signed-off-by: Kenneth Graunke 
Reviewed-by: Brian Paul 
---
 src/mesa/vbo/vbo_exec_array.c |6 +-
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 809804f..06e36a6 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -889,11 +889,7 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
start, end, basevertex, count, type, indices,
ctx->Array.ArrayObj->_MaxElement - 1);
   }
-
-  /* Just do an ordinary glDrawElementsBaseVertex(). */
-  vbo_validated_drawrangeelements(ctx, mode, GL_FALSE, 0, ~0,
-  count, type, indices, basevertex, 1);
-  return;
+  index_bounds_valid = GL_FALSE;
}
 
/* NOTE: It's important that 'end' is a reasonable value.
-- 
1.7.7.6

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


[Mesa-dev] [Bug 46191] New: mesa lacks manpages

2012-02-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=46191

 Bug #: 46191
   Summary: mesa lacks manpages
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: Other
OS/Version: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: matthew.fisc...@canonical.com


A user has reported that the mesa-common-dev package lacks manpages in
Ubuntu.  Ubuntu is using version 8.0.

The original bug report says:

Man pages for OpenGL subroutines appear to be missing, these are the man pages 
to describe the OpenGL API (as used from C).

The original bug is here, but there are likely no other pertinent details:

https://launchpad.net/bugs/189852

-- 
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] VBO fixes [v2]

2012-02-16 Thread Roland Scheidegger
Am 16.02.2012 20:14, schrieb Kenneth Graunke:
> Here's a respin of the VBO fixes, incorporating feedback from Roland,
> Brian, and Ian.
> 
> I'm not entirely happy with this series.  If you look at the resulting
> code, we end up marking the range invalid if:
> 
> 1. (int) start + basevertex < 0
> 2. (int) end   + basevertex < 0
> 3. start + basevertex >= _MaxElement
> 4. end   + basevertex >= _MaxElement
> 
> but in two separate blocks.
> 
> Mesa master emits a warning about case 4, which this series removes.
> This series causes a warning to be emitted for 2 and 3.  No warning
> is ever emitted for case 1.
> 
> Prior to this series, Mesa didn't do 1 and 2 (the < 0 checks) at all.
I think this makes all sense. case 2/3 mean the range can definitely not
be right (as it would be empty), case 1/4 might just mean the app was
sloppy and didn't define the start/end right (but all indices might
still be in the range).

> 
> I'm tempted to just throw out all of these checks and just do:
> 
>if (all_vbo_rendering) /* all VBOs, no user-space arrays at all */
>   index_bounds_valid = false;
Some (rather special) drivers might only want to transfer elements
referenced in the draw range if they keep VBOs in system memory. Not
sure though if it would really make a difference for any (non-hardware)
driver.
Some sanity checking can't hurt though imho.


> 
> since the whole DrawRangeElements optimization is basically irrelevant
> for VBOs.  Cases 3 and 4 should only happen for VBOs anyway, as
> _MaxElement is set to 2,000,000,000 for user-space arrays.
> 
> I don't think we have many (any?) tests for these corner cases, so I'm
> a bit hesitant about changing this.

For the series:
Reviewed-by: Roland Scheidegger 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/7] glsl: Adds an horizontal_location fields to ir_variable.

2012-02-16 Thread Vincent Lejeune
This field allows to address output variables more precisely
(varyings won't have to "hold" a whole register if they are not vec4).
---
 src/glsl/ir.cpp   |1 +
 src/glsl/ir.h |   22 ++
 src/glsl/ir_clone.cpp |1 +
 src/glsl/linker.cpp   |6 +-
 4 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index a5eca5a..a4c93ce 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -1335,6 +1335,7 @@ ir_variable::ir_variable(const struct glsl_type *type, 
const char *name,
this->pixel_center_integer = false;
this->depth_layout = ir_depth_layout_none;
this->used = false;
+   this->horizontal_location = 0;
 
if (type && type->base_type == GLSL_TYPE_SAMPLER)
   this->read_only = true;
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 1faae3c..cf0e444 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -396,6 +396,28 @@ public:
 * slot has not been assigned, the value will be -1.
 */
int location;
+   
+   /**
+* Storage starting component for this variable
+* 
+* Variable storage can be 4-bytes aligned instead of 16-bytes aligned to
+* preserve space, for instance a vec2 can be stored in FILE[location].yz
+* and in this case, its starting_component is y (eq to 1).
+* 
+* Register can be seen as a 2D array as follow :
+* - Locations are assigned to rows,
+* - Components are assigned to columns.
+*
+*  0:  [ 0.x  0.y  0.z  0.w]
+*  1:  [ 1.x  1.y  1.z  1.w]
+*  2:  [ 2.x  2.y  2.z  2.w]
+*  ...
+*  n:  [ n.x  n.y  n.z  n.w]
+*
+* Thus we refers this as "horizontal_location" (vertical location is 
+* the above "location" field).
+*/
+unsigned horizontal_location:2;
 
/**
 * Built-in state that backs this uniform
diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
index c63615c..17e800a 100644
--- a/src/glsl/ir_clone.cpp
+++ b/src/glsl/ir_clone.cpp
@@ -46,6 +46,7 @@ ir_variable::clone(void *mem_ctx, struct hash_table *ht) const
var->invariant = this->invariant;
var->interpolation = this->interpolation;
var->location = this->location;
+   var->horizontal_location = this->horizontal_location;
var->warn_extension = this->warn_extension;
var->origin_upper_left = this->origin_upper_left;
var->pixel_center_integer = this->pixel_center_integer;
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 5095751..8e690ac 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1458,6 +1458,8 @@ private:
 * variable.  -1 if a location hasn't been assigned yet.
 */
int location;
+   
+   unsigned horizontal_location;
 
/**
 * If location != -1, the number of vector elements in this variable, or 1
@@ -1496,6 +1498,7 @@ tfeedback_decl::init(struct gl_context *ctx, struct 
gl_shader_program *prog,
 */
 
this->location = -1;
+   this->horizontal_location = 0;
this->orig_name = input;
this->is_clip_distance_mesa = false;
 
@@ -1602,6 +1605,7 @@ tfeedback_decl::assign_location(struct gl_context *ctx,
   this->vector_elements = output_var->type->vector_elements;
   this->matrix_columns = output_var->type->matrix_columns;
   this->type = output_var->type->gl_type;
+  this->horizontal_location = output_var->horizontal_location;
}
 
/* From GL_EXT_transform_feedback:
@@ -1687,7 +1691,7 @@ tfeedback_decl::store(struct gl_context *ctx, struct 
gl_shader_program *prog,
   for (unsigned v = 0; v < this->matrix_columns; ++v) {
  unsigned num_components = this->vector_elements;
  assert(info->NumOutputs < max_outputs);
- info->Outputs[info->NumOutputs].ComponentOffset = 0;
+ info->Outputs[info->NumOutputs].ComponentOffset = 
this->horizontal_location;
  if (this->is_clip_distance_mesa) {
 if (this->is_subscripted) {
num_components = 1;
-- 
1.7.7

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


[Mesa-dev] [PATCH 2/7] i965: Adds support for horizontal location

2012-02-16 Thread Vincent Lejeune
---
 src/mesa/drivers/dri/i965/brw_fs.cpp   |4 +-
 src/mesa/drivers/dri/i965/brw_vec4.h   |   13 
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |   89 +---
 3 files changed, 93 insertions(+), 13 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 6ecaa6c..d095e86 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -462,7 +462,7 @@ fs_visitor::emit_general_interpolation(ir_variable *ir)
 * field of the setup reg.
 */
for (unsigned int k = 0; k < type->vector_elements; k++) {
-  struct brw_reg interp = interp_reg(location, k);
+  struct brw_reg interp = interp_reg(location, k + 
ir->horizontal_location);
   interp = suboffset(interp, 3);
interp.type = reg->type;
   emit(FS_OPCODE_CINTERP, attr, fs_reg(interp));
@@ -482,7 +482,7 @@ fs_visitor::emit_general_interpolation(ir_variable *ir)
   k == 3 && !(c->key.proj_attrib_mask & (1 << location))) {
  emit(BRW_OPCODE_MOV, attr, fs_reg(1.0f));
   } else {
- struct brw_reg interp = interp_reg(location, k);
+ struct brw_reg interp = interp_reg(location, k + 
ir->horizontal_location);
   brw_wm_barycentric_interp_mode barycoord_mode;
   if (interpolation_mode == INTERP_QUALIFIER_SMOOTH)
  barycoord_mode = BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 2555fa7..54aa99e 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -293,6 +293,17 @@ public:
 
 class vec4_visitor : public ir_visitor
 {
+protected:
+   class output_info : public exec_node {
+   public:
+   const ir_variable *var;
+   const dst_reg *reg;
+   output_info(const ir_variable *v, const dst_reg *r) 
+  : var(v), reg(r)
+  {
+  }
+   };
+
 public:
vec4_visitor(struct brw_vs_compile *c,
struct gl_shader_program *prog, struct brw_shader *shader);
@@ -388,6 +399,7 @@ public:
 */
dst_reg output_reg[BRW_VERT_RESULT_MAX];
const char *output_reg_annotation[BRW_VERT_RESULT_MAX];
+   exec_list custom_outputs;
int uniform_size[MAX_UNIFORMS];
int uniform_vector_size[MAX_UNIFORMS];
int uniforms;
@@ -504,6 +516,7 @@ public:
void emit_clip_distances(struct brw_reg reg, int offset);
void emit_generic_urb_slot(dst_reg reg, int vert_result);
void emit_urb_slot(int mrf, int vert_result);
+   void emit_custom_output(bool is_first_pass, int &max_mrf, int 
result_vert_to_slot[]);
void emit_urb_writes(void);
 
src_reg get_scratch_offset(vec4_instruction *inst,
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 13ba18b..fd76cff 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -855,16 +855,32 @@ vec4_visitor::visit(ir_variable *ir)
 
case ir_var_out:
   reg = new(mem_ctx) dst_reg(this, ir->type);
-
-  for (int i = 0; i < type_size(ir->type); i++) {
-output_reg[ir->location + i] = *reg;
-output_reg[ir->location + i].reg_offset = i;
-output_reg[ir->location + i].type =
-brw_type_for_base_type(ir->type->get_scalar_type());
-output_reg_annotation[ir->location + i] = ir->name;
+  if (ir->location < VERT_RESULT_VAR0) {
+  for (int i = 0; i < type_size(ir->type); i++) {
+   output_reg[ir->location + i] = *reg;
+   output_reg[ir->location + i].reg_offset = i;
+   output_reg[ir->location + i].type =
+  brw_type_for_base_type(ir->type->get_scalar_type());
+   output_reg_annotation[ir->location + i] = ir->name;
+  }
+  } else {
+  output_info *oi = new (mem_ctx) output_info(ir, reg);
+  custom_outputs.push_tail(oi);
   }
-  break;
+   /*   components = 
(ir->type->is_array())?ir->type->fields.array->vector_elements:ir->type->vector_elements;
+   if (!output_reg_annotation[ir->location]) {
+  // The reg has not been set
+ reg = new(mem_ctx) dst_reg(this, ir->type);
 
+
+   } else {
+  // The reg has already been set : this output is packed
+  reg = &(output_reg[ir->location]);
+  output_reg[ir->location].writemask |= (((1 << components) - 1) << 
ir->horizontal_location);
+  char * new_annotation = ralloc_asprintf(mem_ctx, "%s ; %s", 
output_reg_annotation[ir->location], ir->name);
+  output_reg_annotation[ir->location] = new_annotation;
+   }*/
+  break;
case ir_var_auto:
case ir_var_temporary:
   reg = new(mem_ctx) dst_reg(this, ir->type);
@@ -2148,6 +2164,8 @@ vec4_visitor::emit_cli

[Mesa-dev] [PATCH 3/7] glsl_to_tgsi: Adds support for horizontal location

2012-02-16 Thread Vincent Lejeune
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp |   37 +++
 1 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index ab05896..b65fad6 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -1949,6 +1949,17 @@ glsl_to_tgsi_visitor::visit(ir_dereference_variable *ir)
}
 
this->result = st_src_reg(entry->file, entry->index, var->type);
+   if (ir->type->is_scalar() || ir->type->is_vector())
+  this->result.swizzle = swizzle_for_size(ir->type->vector_elements);
+   else
+  this->result.swizzle = SWIZZLE_NOOP;
+   unsigned swz = this->result.swizzle;
+   this->result.swizzle = MAKE_SWIZZLE4(
+GET_SWZ(swz, 0) + ir->var->horizontal_location % 4,
+GET_SWZ(swz, 1) + ir->var->horizontal_location % 4,
+GET_SWZ(swz, 2) + ir->var->horizontal_location % 4,
+GET_SWZ(swz, 3) + ir->var->horizontal_location % 4
+);
if (!native_integers)
   this->result.type = GLSL_TYPE_FLOAT;
 }
@@ -2004,10 +2015,10 @@ glsl_to_tgsi_visitor::visit(ir_dereference_array *ir)
}
 
/* If the type is smaller than a vec4, replicate the last channel out. */
-   if (ir->type->is_scalar() || ir->type->is_vector())
+   /*if (ir->type->is_scalar() || ir->type->is_vector())
   src.swizzle = swizzle_for_size(ir->type->vector_elements);
else
-  src.swizzle = SWIZZLE_NOOP;
+  src.swizzle = SWIZZLE_NOOP;*/
 
this->result = src;
 }
@@ -2169,10 +2180,17 @@ glsl_to_tgsi_visitor::visit(ir_assignment *ir)
   l.writemask = WRITEMASK_XYZW;
} else if (ir->lhs->type->is_scalar() &&
   ir->lhs->variable_referenced()->mode == ir_var_out) {
-  /* FINISHME: This hack makes writing to gl_FragDepth, which lives in the
-   * FINISHME: W component of fragment shader output zero, work correctly.
-   */
-  l.writemask = WRITEMASK_XYZW;
+
+   ir_variable *inside_var = ir->lhs->variable_referenced();
+   if (inside_var->location >= VERT_RESULT_VAR0) {
+  l.writemask = 1 << inside_var->horizontal_location;
+   } else {
+  /* FINISHME: This hack makes writing to gl_FragDepth, which lives in 
the
+* FINISHME: W component of fragment shader output zero, work 
correctly.
+*/
+  l.writemask = WRITEMASK_XYZW;
+   }
+
} else {
   int swizzles[4];
   int first_enabled_chan = 0;
@@ -2180,6 +2198,13 @@ glsl_to_tgsi_visitor::visit(ir_assignment *ir)
 
   l.writemask = ir->write_mask;
 
+   if (ir_variable *inside_var = ir->lhs->variable_referenced()) {
+  if (inside_var->location >= VERT_RESULT_VAR0) {
+   l.writemask = l.writemask << inside_var->horizontal_location;
+
+  }
+   }
+
   for (int i = 0; i < 4; i++) {
  if (l.writemask & (1 << i)) {
 first_enabled_chan = GET_SWZ(r.swizzle, i);
-- 
1.7.7

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


[Mesa-dev] [PATCH 4/7] mesa: Adds parameter to drive varyings packing

2012-02-16 Thread Vincent Lejeune
---
 src/mesa/main/mtypes.h|   10 ++
 src/mesa/main/shaderapi.c |1 +
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index a2b01d0..f2f2dae 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2389,6 +2389,14 @@ struct gl_shader_state
GLbitfield Flags;/**< Mask of GLSL_x flags */
 };
 
+enum packing_constraint
+{
+   NONE, /** no limitation (scalar architecture : swrast, nouveau) */
+   SMOOTH_NOPERSPECTIVE_MIXED, /** Smooth and noperspective varying can be 
mixed but not with flat (i965) */
+   NO_MIXED_INTERPOLATION, /** Dont mix different interpolation (r300 and 
r600) */
+   AVOID_PACKING, /** Disable packing */
+};
+
 /**
  * Compiler options for a single GLSL shaders type
  */
@@ -2419,6 +2427,8 @@ struct gl_shader_compiler_options
GLuint MaxUnrollIterations;
 
struct gl_sl_pragmas DefaultPragmas; /**< Default #pragma settings */
+
+   enum packing_constraint VaryingsPackingConstraint;
 };
 
 /**
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 0e655a0..cdda499 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -103,6 +103,7 @@ _mesa_init_shader_state(struct gl_context *ctx)
 
memset(&options, 0, sizeof(options));
options.MaxUnrollIterations = 32;
+   options.VaryingsPackingConstraint = AVOID_PACKING;
 
/* Default pragma settings */
options.DefaultPragmas.Optimize = GL_TRUE;
-- 
1.7.7

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


[Mesa-dev] [PATCH 5/7] glsl: rework the way varying location are assigned to prepare varying packing

2012-02-16 Thread Vincent Lejeune
---
 src/glsl/linker.cpp |  125 ++-
 1 files changed, 74 insertions(+), 51 deletions(-)

diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 8e690ac..4a5e3bb 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1813,6 +1813,36 @@ assign_varying_location(ir_variable *input_var, 
ir_variable *output_var,
}
 }
 
+namespace pack {
+
+class varying_info : public exec_node
+{
+public:
+   ir_variable *produced;
+   ir_variable *consumed;
+   varying_info( ir_variable *p, ir_variable *c)
+  : produced(p), consumed(c)
+   {
+
+   }
+};
+
+bool
+varying_pack_avoid(exec_list *lst, gl_shader_program *prog, unsigned 
max_varyings)
+{
+   unsigned input_index = FRAG_ATTRIB_VAR0, output_index = VERT_RESULT_VAR0;
+   foreach_list_const(node, lst) {
+   const varying_info *vi = (class varying_info *) node;
+   assign_varying_location(vi->consumed, vi->produced, &input_index, 
&output_index);
+   }
+
+   unsigned varyings_count = MAX2(input_index - FRAG_ATTRIB_VAR0, output_index 
- VERT_RESULT_VAR0);
+   if (varyings_count > max_varyings) {
+   linker_error(prog, "This driver does not support packing, too much 
varyings.");
+   return false;
+   }
+   return true;
+}
 
 /**
  * Assign locations for all variables that are produced in one pipeline stage
@@ -1841,10 +1871,9 @@ assign_varying_locations(struct gl_context *ctx,
  unsigned num_tfeedback_decls,
  tfeedback_decl *tfeedback_decls)
 {
-   /* FINISHME: Set dynamically when geometry shader support is added. */
-   unsigned output_index = VERT_RESULT_VAR0;
-   unsigned input_index = FRAG_ATTRIB_VAR0;
-
+   void *rctx = ralloc_context(NULL);
+   exec_list *delayed_assignment = new (rctx) exec_list();
+   
/* Operate in a total of three passes.
 *
 * 1. Assign locations for any matching inputs and outputs.
@@ -1872,26 +1901,58 @@ assign_varying_locations(struct gl_context *ctx,
   if (input_var && input_var->mode != ir_var_in)
  input_var = NULL;
 
+  varying_info *vi = NULL;
+
   if (input_var) {
- assign_varying_location(input_var, output_var, &input_index,
- &output_index);
+ vi = new (rctx) varying_info (output_var, input_var);
+ delayed_assignment->push_tail(vi);
   }
 
   for (unsigned i = 0; i < num_tfeedback_decls; ++i) {
  if (!tfeedback_decls[i].is_assigned() &&
  tfeedback_decls[i].matches_var(output_var)) {
-if (output_var->location == -1) {
-   assign_varying_location(input_var, output_var, &input_index,
-   &output_index);
+if (output_var->location != -1) {
+   if (!tfeedback_decls[i].assign_location(ctx, prog, output_var)) 
{
+  ralloc_free(rctx);
+  return false;
+   }
+} else if (!vi) {
+   vi = new (rctx) varying_info (output_var, NULL);
+   delayed_assignment->push_tail(vi);
 }
-if (!tfeedback_decls[i].assign_location(ctx, prog, output_var))
-   return false;
  }
   }
}
 
-   unsigned varying_vectors = 0;
+   bool (* varying_pack)(exec_list *, gl_shader_program *, unsigned);
+
+   switch (ctx->ShaderCompilerOptions[0].VaryingsPackingConstraint) {
+   default:
+  varying_pack = varying_pack_avoid;
+  break;
+   }
 
+   if (!varying_pack(delayed_assignment, prog, ctx->Const.MaxVarying)) {
+  ralloc_free(rctx);
+  return false;
+   }
+   
+   // Do TFB assignments
+   foreach_list(node, delayed_assignment) {
+  varying_info *vi = (varying_info *) node;
+  for (unsigned i = 0; i < num_tfeedback_decls; ++i) {
+ printf("name is %s, at %d,%d\n", vi->produced->name, 
vi->produced->location, vi->produced->horizontal_location);
+ printf("assigned is 
%d\n",tfeedback_decls[i].matches_var(vi->produced));
+ if (!tfeedback_decls[i].is_assigned() &&
+ tfeedback_decls[i].matches_var(vi->produced)) {
+if (!tfeedback_decls[i].assign_location(ctx, prog, vi->produced)) {
+   ralloc_free(rctx);
+   return false;
+}
+ }
+  }
+   }
+   
if (consumer) {
   foreach_list(node, consumer->ir) {
  ir_variable *const var = ((ir_instruction *) node)->as_variable();
@@ -1922,48 +1983,10 @@ assign_varying_locations(struct gl_context *ctx,
  * value is written by the previous stage.
  */
 var->mode = ir_var_auto;
- } else {
-/* The packing rules are used for vertex shader inputs are also
- * used for fragment shader inputs.
- */
-varying_vectors += count_attribute_slots(var->type);
  }
   }
}
-
-   if (ctx->API == API_OPENGLES2 || prog->Version == 100) {
-  if (varying_vectors > ct

[Mesa-dev] [PATCH 6/7] glsl: Adds GLES 2.0 varyings packing heuristic

2012-02-16 Thread Vincent Lejeune
---
 src/glsl/linker.cpp |  442 +++
 1 files changed, 442 insertions(+), 0 deletions(-)

diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 4a5e3bb..8441854 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1815,6 +1815,369 @@ assign_varying_location(ir_variable *input_var, 
ir_variable *output_var,
 
 namespace pack {
 
+/**
+ * Varyings packing can be seen as an instance of the bin packing problem.
+ * It is a NP hard problem in general.
+ *
+ * ES 2.0 specs gives (GLSL_ES_Specification_1.0.17-3.pdf, p111) an algorithm
+ * that specifies a minimum requirement for when a set of varyings must be 
+ * supported.
+ * We almost follow the algorithm : the target architecture should be a
+ * 8x4 grid, we use a {number_of_available_reg}x4 grid.
+ */
+class buffer_representation
+{
+protected:
+   class delayed_location_assignment : public exec_node
+   {
+   public:
+   ir_variable *producer;
+   ir_variable *consumer;
+   unsigned location;
+   unsigned horizontal_location;
+   delayed_location_assignment(ir_variable *p, ir_variable *c)
+  : producer(p), consumer(c)
+   {
+   }
+   
+   bool is_before(const delayed_location_assignment *comparee) const
+   {
+  unsigned local_size = 
(producer->type->is_array())?producer->type->length:1;
+  unsigned comparee_size = 
(comparee->producer->type->is_array())?comparee->producer->type->length:1;
+  return local_size >= comparee_size;
+   }
+   
+   void set_location_to_vars(unsigned producer_offset, unsigned 
consumer_offset, unsigned location, unsigned horizontal_location)
+   {
+  producer->location = producer_offset + location;
+  producer->horizontal_location = horizontal_location;
+  if (consumer) {
+   consumer->location = consumer_offset + location;
+   consumer->horizontal_location = horizontal_location;
+  }
+   }
+   
+   };
+   
+   void *ctx;
+   unsigned number_of_regs;
+   bool * is_occupied;
+   unsigned occupied_space_in_column[4];
+   unsigned producer_offset, consumer_offset;
+   exec_list *stored_vars[8];
+   
+   
+   #define ARGMAX(i, j) (occupied_space_in_column[(i)] >= 
occupied_space_in_column[(j)])?(i):(j)
+   #define ARGMIN(i, j) (occupied_space_in_column[(i)] >= 
occupied_space_in_column[(j)])?(j):(i)
+   
+   /**
+* Order index from most occupied column index to least occupied column 
index
+*/
+   void order(unsigned reordered[4]) const
+   {
+   unsigned mx1 = ARGMAX(0, 1), mx2 = ARGMAX(2, 3);
+   unsigned mn1 = ARGMIN(0, 1), mn2 = ARGMIN(2, 3);
+   
+   reordered[0] = ARGMAX(mx1, mx2);
+   unsigned semi_max = ARGMIN(mx1, mx2);
+   reordered[3] = ARGMIN(mn1, mn2);
+   unsigned semi_min = ARGMAX(mn1, mn2);
+   reordered[1] = ARGMAX(semi_max, semi_min);
+   reordered[2] = ARGMIN(semi_min, semi_max);
+   }
+   
+   #undef ARGMAX
+   #undef ARGMIN
+   
+   INLINE
+   bool& is_occupied_ref(unsigned index, unsigned components)
+   {
+   assert (components < 4 && index < number_of_regs);
+   return is_occupied[4 * index + components];
+   }
+   
+   bool is_range_free(unsigned reg, unsigned component_start, unsigned 
row_occupied, unsigned components_occupied)
+   {
+
+   if (component_start + components_occupied - 1 > 3)
+  return false;
+   if (reg + row_occupied - 1 > number_of_regs - 1)
+  return false;
+   for (unsigned j = 0; j < row_occupied; j++) {
+  for (unsigned i = 0; i < components_occupied; i++) {
+   if (is_occupied_ref(reg + j, component_start + i))
+  return false;
+  }
+   }
+   return true;
+   }
+   
+   void mark_as_occupied(unsigned location, unsigned horizontal_location, 
unsigned size, unsigned components_occupied) 
+   {
+   for (unsigned j = 0; j < size; j++) {
+  for (unsigned i = 0; i < components_occupied; i++) {
+   is_occupied_ref(location + j, horizontal_location + i) = true;
+   occupied_space_in_column[horizontal_location + i] ++;
+  }
+   }
+   }
+   
+   void insert(delayed_location_assignment *dla, const glsl_type *const type)
+   {
+   if (type->is_array()) {
+  insert(dla, type->fields.array);
+   }
+   
+   // MAT4
+   if (type->is_matrix() && type->vector_elements == 4) {
+  insert_largest_first(stored_vars[1], dla);
+  return;
+   }
+   
+   // MAT2
+   if (type->is_matrix() && type->vector_elements == 2) {
+  insert_largest_first(stored_vars[2], dla);
+  return;
+   }
+   
+   // {I,B,}VEC4
+   if (type->is_vector() && type->vector_elements == 4) {
+  insert_largest_first(stored_vars[3], dla);
+  return;
+   }
+   
+   // MAT3
+   if (type->is_matrix() && type->vector_elements == 3) {
+

[Mesa-dev] [PATCH 7/7] i965 options set

2012-02-16 Thread Vincent Lejeune
---
 src/mesa/drivers/dri/i965/brw_context.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 87ea1a5..fbfaeba 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -234,6 +234,7 @@ brwCreateContext(int api,
   ctx->ShaderCompilerOptions[i].EmitNoIndirectTemp =
 (i == MESA_SHADER_FRAGMENT);
   ctx->ShaderCompilerOptions[i].LowerClipDistance = true;
+   ctx->ShaderCompilerOptions[i].VaryingsPackingConstraint = 
SMOOTH_NOPERSPECTIVE_MIXED;
}
 
ctx->Const.VertexProgram.MaxNativeInstructions = (16 * 1024);
-- 
1.7.7

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


[Mesa-dev] [PATCH 0/6] R600 invariant state and draw_vbo cleanup

2012-02-16 Thread Marek Olšák
Hi everyone,

The main motivation behind this series is to move updates of invariant 
registers to the beginning of CS. Invariant registers are those which never 
change thoughout a CS, so they don't need to be part of gallium states and 
examined everytime such states are changed. Besides that, the series cleans up 
the draw_vbo code.

Please review.

I would like to mention that I can't test Cayman. If somebody has a 
Cayman-based GPU, the patches can be pulled from here:
  git://people.freedesktop.org/~mareko/mesa r600-invariant-state

Thanks.

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


[Mesa-dev] [PATCH 2/6] r600g: move all invariant state from draw_vbo into start_cs

2012-02-16 Thread Marek Olšák
---
 src/gallium/drivers/r600/evergreen_hw_context.c |5 -
 src/gallium/drivers/r600/evergreen_state.c  |   14 +++---
 src/gallium/drivers/r600/r600_hw_context.c  |3 ---
 src/gallium/drivers/r600/r600_pipe.h|   20 ++--
 src/gallium/drivers/r600/r600_state.c   |6 ++
 src/gallium/drivers/r600/r600_state_common.c|6 --
 src/gallium/drivers/r600/r600d.h|1 -
 7 files changed, 35 insertions(+), 20 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c 
b/src/gallium/drivers/r600/evergreen_hw_context.c
index 00fdade..5d56cfb 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -44,7 +44,6 @@ static const struct r600_reg cayman_config_reg_list[] = {
 };
 
 static const struct r600_reg evergreen_ctl_const_list[] = {
-   {R_03CFF0_SQ_VTX_BASE_VTX_LOC, 0, 0},
{R_03CFF4_SQ_VTX_START_INST_LOC, 0, 0},
 };
 
@@ -104,8 +103,6 @@ static const struct r600_reg evergreen_context_reg_list[] = 
{
{R_0282D4_PA_SC_VPORT_ZMAX_0, 0, 0},
{R_028350_SX_MISC, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
-   {R_028400_VGT_MAX_VTX_INDX, 0, 0},
-   {R_028404_VGT_MIN_VTX_INDX, 0, 0},
{R_028408_VGT_INDX_OFFSET, 0, 0},
{R_02840C_VGT_MULTI_PRIM_IB_RESET_INDX, 0, 0},
{R_028A94_VGT_MULTI_PRIM_IB_RESET_EN, 0, 0},
@@ -413,8 +410,6 @@ static const struct r600_reg cayman_context_reg_list[] = {
{R_0282D4_PA_SC_VPORT_ZMAX_0, 0, 0},
{R_028350_SX_MISC, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
-   {R_028400_VGT_MAX_VTX_INDX, 0, 0},
-   {R_028404_VGT_MIN_VTX_INDX, 0, 0},
{R_028408_VGT_INDX_OFFSET, 0, 0},
{R_02840C_VGT_MULTI_PRIM_IB_RESET_INDX, 0, 0},
{R_028A94_VGT_MULTI_PRIM_IB_RESET_EN, 0, 0},
diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index 905aef9..9eb243c 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1859,7 +1859,7 @@ static void cayman_init_atom_start_cs(struct r600_context 
*rctx)
 
r600_store_context_reg(cb, CM_R_028804_DB_EQAA, 0x11);
 
-   r600_store_context_reg_seq(cb, R_028380_SQ_VTX_SEMANTIC_0, 32);
+   r600_store_context_reg_seq(cb, R_028380_SQ_VTX_SEMANTIC_0, 34);
r600_store_value(cb, 0); /* R_028380_SQ_VTX_SEMANTIC_0 */
r600_store_value(cb, 0);
r600_store_value(cb, 0);
@@ -1892,6 +1892,10 @@ static void cayman_init_atom_start_cs(struct 
r600_context *rctx)
r600_store_value(cb, 0);
r600_store_value(cb, 0);
r600_store_value(cb, 0); /* R_0283FC_SQ_VTX_SEMANTIC_31 */
+   r600_store_value(cb, ~0); /* R_028400_VGT_MAX_VTX_INDX */
+   r600_store_value(cb, 0); /* R_028404_VGT_MIN_VTX_INDX */
+
+   r600_store_ctl_const(cb, R_03CFF0_SQ_VTX_BASE_VTX_LOC, 0);
 }
 
 void evergreen_init_atom_start_cs(struct r600_context *rctx)
@@ -2286,7 +2290,7 @@ void evergreen_init_atom_start_cs(struct r600_context 
*rctx)
 
r600_store_config_reg(cb, R_008A14_PA_CL_ENHANCE, (3 << 1) | 1);
 
-   r600_store_context_reg_seq(cb, R_028380_SQ_VTX_SEMANTIC_0, 32);
+   r600_store_context_reg_seq(cb, R_028380_SQ_VTX_SEMANTIC_0, 34);
r600_store_value(cb, 0); /* R_028380_SQ_VTX_SEMANTIC_0 */
r600_store_value(cb, 0);
r600_store_value(cb, 0);
@@ -2318,7 +2322,11 @@ void evergreen_init_atom_start_cs(struct r600_context 
*rctx)
r600_store_value(cb, 0);
r600_store_value(cb, 0);
r600_store_value(cb, 0);
-   r600_store_value(cb, 0); /* R_028380_SQ_VTX_SEMANTIC_31 */
+   r600_store_value(cb, 0); /* R_0283FC_SQ_VTX_SEMANTIC_31 */
+   r600_store_value(cb, ~0); /* R_028400_VGT_MAX_VTX_INDX */
+   r600_store_value(cb, 0); /* R_028404_VGT_MIN_VTX_INDX */
+
+   r600_store_ctl_const(cb, R_03CFF0_SQ_VTX_BASE_VTX_LOC, 0);
 }
 
 void evergreen_polygon_offset_update(struct r600_context *rctx)
diff --git a/src/gallium/drivers/r600/r600_hw_context.c 
b/src/gallium/drivers/r600/r600_hw_context.c
index ef29ddf..6e3b809 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -250,7 +250,6 @@ static const struct r600_reg r600_config_reg_list[] = {
 };
 
 static const struct r600_reg r600_ctl_const_list[] = {
-   {R_03CFF0_SQ_VTX_BASE_VTX_LOC, 0, 0},
{R_03CFF4_SQ_VTX_START_INST_LOC, 0, 0},
 };
 
@@ -571,8 +570,6 @@ static const struct r600_reg r600_context_reg_list[] = {
{R_028850_SQ_PGM_RESOURCES_PS, 0, 0},
{R_028854_SQ_PGM_EXPORTS_PS, 0, 0},
{R_0288CC_SQ_PGM_CF_OFFSET_PS, 0, 0},
-   {R_028400_VGT_MAX_VTX_INDX, 0, 0},
-   {R_028404_VGT_MIN_VTX_INDX, 0, 0},
{R_028408_VGT_INDX_OFFSET, 0, 0},
{R_02840C_VGT_MULTI_PRIM_IB_RESET_INDX, 0, 0},
{R_028A94_VGT_MULTI_PRIM_IB_RESET_EN, 0, 0},
diff --git a/src/gallium/driv

[Mesa-dev] [PATCH 3/6] r600g: consolidate the main draw code

2012-02-16 Thread Marek Olšák
The code was almost the same for r600 and eg. What can't be consolidated is
in the *_prepare functions.
---
 src/gallium/drivers/r600/evergreen_hw_context.c |   55 --
 src/gallium/drivers/r600/r600.h |   15 +-
 src/gallium/drivers/r600/r600_hw_context.c  |   57 ---
 src/gallium/drivers/r600/r600_state_common.c|   56 --
 4 files changed, 50 insertions(+), 133 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c 
b/src/gallium/drivers/r600/evergreen_hw_context.c
index 5d56cfb..f3b207b 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -981,59 +981,22 @@ void evergreen_context_pipe_state_set_vs_sampler(struct 
r600_context *ctx, struc
evergreen_context_pipe_state_set_sampler_border(ctx, state, 
R_00A414_TD_VS_SAMPLER0_BORDER_INDEX, id);
 }
 
-
-void evergreen_context_draw(struct r600_context *ctx, const struct r600_draw 
*draw)
+/* XXX make a proper state object (atom or pipe_state) out of this */
+void evergreen_context_draw_prepare(struct r600_context *ctx)
 {
+   struct r600_pipe_dsa *dsa = (struct 
r600_pipe_dsa*)ctx->states[R600_PIPE_STATE_DSA];
struct radeon_winsys_cs *cs = ctx->cs;
-   unsigned ndwords = 7;
-   uint32_t *pm4;
-   uint64_t va;
-
-   if (draw->indices) {
-   ndwords = 11;
-   }
-   if (ctx->num_cs_dw_queries_suspend)
-   ndwords += 6;
-
-   /* when increasing ndwords, bump the max limit too */
-   assert(ndwords <= R600_MAX_DRAW_CS_DWORDS);
 
/* queries need some special values
 * (this is non-zero if any query is active) */
if (ctx->num_cs_dw_queries_suspend) {
-   pm4 = &cs->buf[cs->cdw];
-   pm4[0] = PKT3(PKT3_SET_CONTEXT_REG, 1, 0);
-   pm4[1] = (R_028004_DB_COUNT_CONTROL - 
EVERGREEN_CONTEXT_REG_OFFSET) >> 2;
-   pm4[2] = S_028004_PERFECT_ZPASS_COUNTS(1);
-   pm4[3] = PKT3(PKT3_SET_CONTEXT_REG, 1, 0);
-   pm4[4] = (R_02800C_DB_RENDER_OVERRIDE - 
EVERGREEN_CONTEXT_REG_OFFSET) >> 2;
-   pm4[5] = draw->db_render_override | 
S_02800C_NOOP_CULL_DISABLE(1);
-   cs->cdw += 6;
-   ndwords -= 6;
-   }
-
-   /* draw packet */
-   pm4 = &cs->buf[cs->cdw];
-   pm4[0] = PKT3(PKT3_INDEX_TYPE, 0, ctx->predicate_drawing);
-   pm4[1] = draw->vgt_index_type;
-   pm4[2] = PKT3(PKT3_NUM_INSTANCES, 0, ctx->predicate_drawing);
-   pm4[3] = draw->vgt_num_instances;
-   if (draw->indices) {
-   va = r600_resource_va(&ctx->screen->screen, 
(void*)draw->indices);
-   va += draw->indices_bo_offset;
-   pm4[4] = PKT3(PKT3_DRAW_INDEX, 3, ctx->predicate_drawing);
-   pm4[5] = va;
-   pm4[6] = (va >> 32UL) & 0xFF;
-   pm4[7] = draw->vgt_num_indices;
-   pm4[8] = draw->vgt_draw_initiator;
-   pm4[9] = PKT3(PKT3_NOP, 0, ctx->predicate_drawing);
-   pm4[10] = r600_context_bo_reloc(ctx, draw->indices, 
RADEON_USAGE_READ);
-   } else {
-   pm4[4] = PKT3(PKT3_DRAW_INDEX_AUTO, 1, ctx->predicate_drawing);
-   pm4[5] = draw->vgt_num_indices;
-   pm4[6] = draw->vgt_draw_initiator;
+   cs->buf[cs->cdw++] = PKT3(PKT3_SET_CONTEXT_REG, 1, 0);
+   cs->buf[cs->cdw++] = (R_028004_DB_COUNT_CONTROL - 
EVERGREEN_CONTEXT_REG_OFFSET) >> 2;
+   cs->buf[cs->cdw++] = S_028004_PERFECT_ZPASS_COUNTS(1);
+   cs->buf[cs->cdw++] = PKT3(PKT3_SET_CONTEXT_REG, 1, 0);
+   cs->buf[cs->cdw++] = (R_02800C_DB_RENDER_OVERRIDE - 
EVERGREEN_CONTEXT_REG_OFFSET) >> 2;
+   cs->buf[cs->cdw++] = dsa->db_render_override | 
S_02800C_NOOP_CULL_DISABLE(1);
}
-   cs->cdw += ndwords;
 }
 
 void evergreen_flush_vgt_streamout(struct r600_context *ctx)
diff --git a/src/gallium/drivers/r600/r600.h b/src/gallium/drivers/r600/r600.h
index 229fa70..1bb6c4b 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -195,17 +195,6 @@ struct r600_so_target {
 #define R600_CONTEXT_DST_CACHES_DIRTY  (1 << 1)
 #define R600_CONTEXT_CHECK_EVENT_FLUSH (1 << 2)
 
-struct r600_draw {
-   uint32_tvgt_num_indices;
-   uint32_tvgt_num_instances;
-   uint32_tvgt_index_type;
-   uint32_tvgt_draw_initiator;
-   uint32_tindices_bo_offset;
-   unsigneddb_render_override;
-   unsigneddb_render_control;
-   struct r600_resource*indices;
-};
-
 struct r600_context;
 struct r600_screen;
 
@@ -219,7 +208,7 @@ void r600_context_pipe_state_set_fs_resource(struct 
r600_context *ctx, struct r6
 void r600_context_pipe_state_set_ps_sampler(struct r600_context *ctx, struct 
r600_pipe_state *sta

[Mesa-dev] [PATCH 4/6] r600g: add a depth misc state which depends on occlusion queries

2012-02-16 Thread Marek Olšák
This is a state which is derived from other states and is actually the first
state which doesn't correspond to any gallium state.

There are two state flags:
  bool occlusion_query_enabled
  bool flush_depthstencil_enabled

Additional flags can be added later if needed, e.g. bool hiz_enabled.
The emit function will have to figure out the register values by itself.

It basically just emits the registers when the state changes.
This commit also adds a few helper functions for writing registers directly
into a command stream.
---
 src/gallium/drivers/r600/evergreen_hw_context.c |   22 
 src/gallium/drivers/r600/evergreen_state.c  |   30 ---
 src/gallium/drivers/r600/r600.h |2 -
 src/gallium/drivers/r600/r600_hw_context.c  |   23 +
 src/gallium/drivers/r600/r600_hw_context_priv.h |2 +-
 src/gallium/drivers/r600/r600_pipe.c|4 +-
 src/gallium/drivers/r600/r600_pipe.h|   65 ++-
 src/gallium/drivers/r600/r600_query.c   |   23 
 src/gallium/drivers/r600/r600_state.c   |   54 +++
 src/gallium/drivers/r600/r600_state_common.c|   18 +++
 10 files changed, 152 insertions(+), 91 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c 
b/src/gallium/drivers/r600/evergreen_hw_context.c
index f3b207b..a7ba04d 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -49,9 +49,7 @@ static const struct r600_reg evergreen_ctl_const_list[] = {
 
 static const struct r600_reg evergreen_context_reg_list[] = {
{R_028000_DB_RENDER_CONTROL, 0, 0},
-   {R_028004_DB_COUNT_CONTROL, 0, 0},
{R_028008_DB_DEPTH_VIEW, 0, 0},
-   {R_02800C_DB_RENDER_OVERRIDE, 0, 0},
{R_028010_DB_RENDER_OVERRIDE2, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028014_DB_HTILE_DATA_BASE, REG_FLAG_NEED_BO, 0},
@@ -356,9 +354,7 @@ static const struct r600_reg evergreen_context_reg_list[] = 
{
 
 static const struct r600_reg cayman_context_reg_list[] = {
{R_028000_DB_RENDER_CONTROL, 0, 0},
-   {R_028004_DB_COUNT_CONTROL, 0, 0},
{R_028008_DB_DEPTH_VIEW, 0, 0},
-   {R_02800C_DB_RENDER_OVERRIDE, 0, 0},
{R_028010_DB_RENDER_OVERRIDE2, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028014_DB_HTILE_DATA_BASE, REG_FLAG_NEED_BO, 0},
@@ -981,24 +977,6 @@ void evergreen_context_pipe_state_set_vs_sampler(struct 
r600_context *ctx, struc
evergreen_context_pipe_state_set_sampler_border(ctx, state, 
R_00A414_TD_VS_SAMPLER0_BORDER_INDEX, id);
 }
 
-/* XXX make a proper state object (atom or pipe_state) out of this */
-void evergreen_context_draw_prepare(struct r600_context *ctx)
-{
-   struct r600_pipe_dsa *dsa = (struct 
r600_pipe_dsa*)ctx->states[R600_PIPE_STATE_DSA];
-   struct radeon_winsys_cs *cs = ctx->cs;
-
-   /* queries need some special values
-* (this is non-zero if any query is active) */
-   if (ctx->num_cs_dw_queries_suspend) {
-   cs->buf[cs->cdw++] = PKT3(PKT3_SET_CONTEXT_REG, 1, 0);
-   cs->buf[cs->cdw++] = (R_028004_DB_COUNT_CONTROL - 
EVERGREEN_CONTEXT_REG_OFFSET) >> 2;
-   cs->buf[cs->cdw++] = S_028004_PERFECT_ZPASS_COUNTS(1);
-   cs->buf[cs->cdw++] = PKT3(PKT3_SET_CONTEXT_REG, 1, 0);
-   cs->buf[cs->cdw++] = (R_02800C_DB_RENDER_OVERRIDE - 
EVERGREEN_CONTEXT_REG_OFFSET) >> 2;
-   cs->buf[cs->cdw++] = dsa->db_render_override | 
S_02800C_NOOP_CULL_DISABLE(1);
-   }
-}
-
 void evergreen_flush_vgt_streamout(struct r600_context *ctx)
 {
struct radeon_winsys_cs *cs = ctx->cs;
diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index 9eb243c..8f6a8a0 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -716,7 +716,7 @@ static void *evergreen_create_dsa_state(struct pipe_context 
*ctx,
struct r600_context *rctx = (struct r600_context *)ctx;
struct r600_pipe_dsa *dsa = CALLOC_STRUCT(r600_pipe_dsa);
unsigned db_depth_control, alpha_test_control, alpha_ref;
-   unsigned db_render_override, db_render_control;
+   unsigned db_render_control;
struct r600_pipe_state *rstate;
 
if (dsa == NULL) {
@@ -764,9 +764,6 @@ static void *evergreen_create_dsa_state(struct pipe_context 
*ctx,
 
/* misc */
db_render_control = 0;
-   db_render_override = S_02800C_FORCE_HIZ_ENABLE(V_02800C_FORCE_DISABLE) |
-   S_02800C_FORCE_HIS_ENABLE0(V_02800C_FORCE_DISABLE) |
-   S_02800C_FORCE_HIS_ENABLE1(V_02800C_FORCE_DISABLE);
/* TODO db_render_override depends on query */
r600_pipe_state_add_reg(rstate, R_028028_DB_STENCIL_CLEAR, 0x, 
NULL, 0);
r600_pipe_state_add_reg(rstate, R_02802C_DB_DEPTH_CLEAR, 0x3F80, 
NULL, 0);
@@ -777,13 +774,10 @@ stat

[Mesa-dev] [PATCH 5/6] r600g: move invariant register updates into start_cs for r6xx-r7xx

2012-02-16 Thread Marek Olšák
---
 src/gallium/drivers/r600/r600_hw_context.c |   38 
 src/gallium/drivers/r600/r600_pipe.h   |   16 
 src/gallium/drivers/r600/r600_state.c  |  130 ++--
 3 files changed, 82 insertions(+), 102 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_hw_context.c 
b/src/gallium/drivers/r600/r600_hw_context.c
index c59b853..56a83ae 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -255,8 +255,6 @@ static const struct r600_reg r600_ctl_const_list[] = {
 
 static const struct r600_reg r600_context_reg_list[] = {
{R_028A4C_PA_SC_MODE_CNTL, 0, 0},
-   {R_028028_DB_STENCIL_CLEAR, 0, 0},
-   {R_02802C_DB_DEPTH_CLEAR, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028040_CB_COLOR0_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU, 
SURFACE_BASE_UPDATE_COLOR(0)},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
@@ -267,7 +265,6 @@ static const struct r600_reg r600_context_reg_list[] = {
{R_0280E0_CB_COLOR0_FRAG, REG_FLAG_NEED_BO, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_0280C0_CB_COLOR0_TILE, REG_FLAG_NEED_BO, 0},
-   {R_028100_CB_COLOR0_MASK, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028044_CB_COLOR1_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU, 
SURFACE_BASE_UPDATE_COLOR(1)},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
@@ -278,7 +275,6 @@ static const struct r600_reg r600_context_reg_list[] = {
{R_0280E4_CB_COLOR1_FRAG, REG_FLAG_NEED_BO, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_0280C4_CB_COLOR1_TILE, REG_FLAG_NEED_BO, 0},
-   {R_028104_CB_COLOR1_MASK, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028048_CB_COLOR2_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU, 
SURFACE_BASE_UPDATE_COLOR(2)},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
@@ -289,7 +285,6 @@ static const struct r600_reg r600_context_reg_list[] = {
{R_0280E8_CB_COLOR2_FRAG, REG_FLAG_NEED_BO, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_0280C8_CB_COLOR2_TILE, REG_FLAG_NEED_BO, 0},
-   {R_028108_CB_COLOR2_MASK, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_02804C_CB_COLOR3_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU, 
SURFACE_BASE_UPDATE_COLOR(3)},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
@@ -300,7 +295,6 @@ static const struct r600_reg r600_context_reg_list[] = {
{R_0280EC_CB_COLOR3_FRAG, REG_FLAG_NEED_BO, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_0280CC_CB_COLOR3_TILE, REG_FLAG_NEED_BO, 0},
-   {R_02810C_CB_COLOR3_MASK, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028050_CB_COLOR4_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU, 
SURFACE_BASE_UPDATE_COLOR(4)},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
@@ -311,7 +305,6 @@ static const struct r600_reg r600_context_reg_list[] = {
{R_0280F0_CB_COLOR4_FRAG, REG_FLAG_NEED_BO, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_0280D0_CB_COLOR4_TILE, REG_FLAG_NEED_BO, 0},
-   {R_028110_CB_COLOR4_MASK, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028054_CB_COLOR5_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU, 
SURFACE_BASE_UPDATE_COLOR(5)},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
@@ -322,7 +315,6 @@ static const struct r600_reg r600_context_reg_list[] = {
{R_0280F4_CB_COLOR5_FRAG, REG_FLAG_NEED_BO, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_0280D4_CB_COLOR5_TILE, REG_FLAG_NEED_BO, 0},
-   {R_028114_CB_COLOR5_MASK, 0, 0},
{R_028058_CB_COLOR6_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU, 
SURFACE_BASE_UPDATE_COLOR(6)},
{R_0280B8_CB_COLOR6_INFO, REG_FLAG_NEED_BO, 0},
{R_028078_CB_COLOR6_SIZE, 0, 0},
@@ -331,7 +323,6 @@ static const struct r600_reg r600_context_reg_list[] = {
{R_0280F8_CB_COLOR6_FRAG, REG_FLAG_NEED_BO, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_0280D8_CB_COLOR6_TILE, REG_FLAG_NEED_BO, 0},
-   {R_028118_CB_COLOR6_MASK, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_02805C_CB_COLOR7_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU, 
SURFACE_BASE_UPDATE_COLOR(7)},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
@@ -340,7 +331,6 @@ static const struct r600_reg r600_context_reg_list[] = {
{R_02809C_CB_COLOR7_VIEW, 0, 0},
{R_0280FC_CB_COLOR7_FRAG, REG_FLAG_NEED_BO, 0},
{R_0280DC_CB_COLOR7_TILE, REG_FLAG_NEED_BO, 0},
-   {R_02811C_CB_COLOR7_MASK, 0, 0},
{R_028120_CB_CLEAR_RED, 0, 0},
{R_028124_CB_CLEAR_GREEN, 0, 0},
{R_028128_CB_CLEAR_BLUE, 0, 0},
@@ -366,9 +356,6 @@ static const struct r600_reg r600_context_reg_list[] = {
{R_028430_DB_STENCILREFMASK, 0, 0},
{R_028434_DB_STENCILREFMASK_BF, 0, 0},
{R_028438_SX_ALPHA_REF, 0, 0},
-   {R_0286DC_SPI_FOG_CNTL, 0, 0},
-   {R_0286E0_SPI_FOG_FUNC_SCALE, 0, 0},
-   {R_0286E4_SPI_FOG_FUNC_BIAS, 0, 0},
{R_028780_CB_BLEND0_CONTROL, REG_FLAG_NOT_R600, 0},
{R_028784_CB_BLEND1_CONTROL, REG_FLAG_NOT_R600, 0},
{R_028788_CB_BLEND2_CONTROL, REG_FLAG_NOT_R600, 0}

[Mesa-dev] [PATCH 6/6] r600g: move invariant register updates into start_cs for evergreen and cayman

2012-02-16 Thread Marek Olšák
---
 src/gallium/drivers/r600/evergreen_hw_context.c |   48 ---
 src/gallium/drivers/r600/evergreen_state.c  |  155 +--
 src/gallium/drivers/r600/r600_pipe.h|   15 +++
 3 files changed, 100 insertions(+), 118 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c 
b/src/gallium/drivers/r600/evergreen_hw_context.c
index a7ba04d..71edc26 100644
--- a/src/gallium/drivers/r600/evergreen_hw_context.c
+++ b/src/gallium/drivers/r600/evergreen_hw_context.c
@@ -54,8 +54,6 @@ static const struct r600_reg evergreen_context_reg_list[] = {
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028014_DB_HTILE_DATA_BASE, REG_FLAG_NEED_BO, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
-   {R_028028_DB_STENCIL_CLEAR, 0, 0},
-   {R_02802C_DB_DEPTH_CLEAR, 0, 0},
{R_028030_PA_SC_SCREEN_SCISSOR_TL, 0, 0},
{R_028034_PA_SC_SCREEN_SCISSOR_BR, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
@@ -77,7 +75,6 @@ static const struct r600_reg evergreen_context_reg_list[] = {
{R_028144_ALU_CONST_BUFFER_SIZE_PS_1, REG_FLAG_DIRTY_ALWAYS, 0},
{R_028180_ALU_CONST_BUFFER_SIZE_VS_0, REG_FLAG_DIRTY_ALWAYS, 0},
{R_028184_ALU_CONST_BUFFER_SIZE_VS_1, REG_FLAG_DIRTY_ALWAYS, 0},
-   {R_028200_PA_SC_WINDOW_OFFSET, 0, 0},
{R_028204_PA_SC_WINDOW_SCISSOR_TL, 0, 0},
{R_028208_PA_SC_WINDOW_SCISSOR_BR, 0, 0},
{R_02820C_PA_SC_CLIPRECT_RULE, 0, 0},
@@ -89,7 +86,6 @@ static const struct r600_reg evergreen_context_reg_list[] = {
{R_028224_PA_SC_CLIPRECT_2_BR, 0, 0},
{R_028228_PA_SC_CLIPRECT_3_TL, 0, 0},
{R_02822C_PA_SC_CLIPRECT_3_BR, 0, 0},
-   {R_028230_PA_SC_EDGERULE, 0, 0},
{R_028234_PA_SU_HARDWARE_SCREEN_OFFSET, 0, 0},
{R_028238_CB_TARGET_MASK, 0, 0},
{R_02823C_CB_SHADER_MASK, 0, 0},
@@ -97,8 +93,6 @@ static const struct r600_reg evergreen_context_reg_list[] = {
{R_028244_PA_SC_GENERIC_SCISSOR_BR, 0, 0},
{R_028250_PA_SC_VPORT_SCISSOR_0_TL, 0, 0},
{R_028254_PA_SC_VPORT_SCISSOR_0_BR, 0, 0},
-   {R_0282D0_PA_SC_VPORT_ZMIN_0, 0, 0},
-   {R_0282D4_PA_SC_VPORT_ZMAX_0, 0, 0},
{R_028350_SX_MISC, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028408_VGT_INDX_OFFSET, 0, 0},
@@ -194,7 +188,6 @@ static const struct r600_reg evergreen_context_reg_list[] = 
{
{R_0286D0_SPI_PS_IN_CONTROL_1, 0, 0},
{R_0286D4_SPI_INTERP_CONTROL_0, 0, 0},
{R_0286D8_SPI_INPUT_Z, 0, 0},
-   {R_0286DC_SPI_FOG_CNTL, 0, 0},
{R_0286E0_SPI_BARYC_CNTL, 0, 0},
{R_0286E4_SPI_PS_IN_CONTROL_2, 0, 0},
{R_0286E8_SPI_COMPUTE_INPUT_CNTL, 0, 0},
@@ -211,18 +204,13 @@ static const struct r600_reg evergreen_context_reg_list[] 
= {
{R_028808_CB_COLOR_CONTROL, 0, 0},
{R_028810_PA_CL_CLIP_CNTL, 0, 0},
{R_028814_PA_SU_SC_MODE_CNTL, 0, 0},
-   {R_028818_PA_CL_VTE_CNTL, 0, 0},
{R_02881C_PA_CL_VS_OUT_CNTL, 0, 0},
-   {R_028820_PA_CL_NANINF_CNTL, 0, 0},
{R_028840_SQ_PGM_START_PS, REG_FLAG_NEED_BO, 0},
{R_028844_SQ_PGM_RESOURCES_PS, 0, 0},
-   {R_028848_SQ_PGM_RESOURCES_2_PS, 0, 0},
{R_02884C_SQ_PGM_EXPORTS_PS, 0, 0},
{R_02885C_SQ_PGM_START_VS, REG_FLAG_NEED_BO, 0},
{R_028860_SQ_PGM_RESOURCES_VS, 0, 0},
-   {R_028864_SQ_PGM_RESOURCES_2_VS, 0, 0},
{R_0288A4_SQ_PGM_START_FS, REG_FLAG_NEED_BO, 0},
-   {R_0288A8_SQ_PGM_RESOURCES_FS, 0, 0},
{R_0288EC_SQ_LDS_ALLOC_PS, 0, 0},
{R_028940_ALU_CONST_CACHE_PS_0, REG_FLAG_NEED_BO, 0},
{R_028944_ALU_CONST_CACHE_PS_1, REG_FLAG_NEED_BO, 0},
@@ -234,26 +222,14 @@ static const struct r600_reg evergreen_context_reg_list[] 
= {
{R_028A0C_PA_SC_LINE_STIPPLE, 0, 0},
{R_028A48_PA_SC_MODE_CNTL_0, 0, 0},
{R_028ABC_DB_HTILE_SURFACE, 0, 0},
-   {R_028AC0_DB_SRESULTS_COMPARE_STATE0, 0, 0},
-   {R_028AC4_DB_SRESULTS_COMPARE_STATE1, 0, 0},
-   {R_028AC8_DB_PRELOAD_CONTROL, 0, 0},
{R_028B54_VGT_SHADER_STAGES_EN, 0, 0},
-   {R_028B70_DB_ALPHA_TO_MASK, 0, 0},
{R_028B78_PA_SU_POLY_OFFSET_DB_FMT_CNTL, 0, 0},
{R_028B7C_PA_SU_POLY_OFFSET_CLAMP, 0, 0},
{R_028B80_PA_SU_POLY_OFFSET_FRONT_SCALE, 0, 0},
{R_028B84_PA_SU_POLY_OFFSET_FRONT_OFFSET, 0, 0},
{R_028B88_PA_SU_POLY_OFFSET_BACK_SCALE, 0, 0},
{R_028B8C_PA_SU_POLY_OFFSET_BACK_OFFSET, 0, 0},
-   {R_028C00_PA_SC_LINE_CNTL, 0, 0},
-   {R_028C04_PA_SC_AA_CONFIG, 0, 0},
{R_028C08_PA_SU_VTX_CNTL, 0, 0},
-   {R_028C0C_PA_CL_GB_VERT_CLIP_ADJ, 0, 0},
-   {R_028C10_PA_CL_GB_VERT_DISC_ADJ, 0, 0},
-   {R_028C14_PA_CL_GB_HORZ_CLIP_ADJ, 0, 0},
-   {R_028C18_PA_CL_GB_HORZ_DISC_ADJ, 0, 0},
-   {R_028C1C_PA_SC_AA_SAMPLE_LOCS_0, 0, 0},
-   {R_028C3C_PA_SC_AA_MASK, 0, 0},
{GROUP_FORCE_NEW_BLOCK, 0, 0},
{R_028C60_CB_COLOR0_BASE, REG_FLAG_NEED_BO, 0},
{R_028C64_CB_COLOR0_PITCH, 0, 0},
@@ -359,8 +335,6 @@ static const stru

[Mesa-dev] [Bug 46191] mesa lacks manpages

2012-02-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=46191

Sven Arvidsson  changed:

   What|Removed |Added

 CC||s...@whiz.se

--- Comment #1 from Sven Arvidsson  2012-02-16 13:13:44 UTC ---
There are OpenGL manpages, but not in Mesa:
http://www.opengl.org/wiki/Getting_started/XML_Toolchain_and_Man_Pages

These seems to be the ones other distributions are shipping (such as Arch).

-- 
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] [PATCH] glsl: Avoid extra if statements for logic and/or with no side effects.

2012-02-16 Thread Eric Anholt
This avoids extra if statements in the common case of just comparing
two expressions that don't involve assignments or function calls,
along with simplifying the handling of constant expressions.  Since GL
3.0 availability, my actual application testcases for improvement from
this patch have apparently gone away, but it still seems like the
right thing to do.

Reveals a bug in piglit's glsl-algebraic-logicor-true.
---
 src/glsl/ast_to_hir.cpp |   23 ++-
 1 files changed, 6 insertions(+), 17 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index c580359..75d7e9d 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -1199,15 +1199,9 @@ ast_expression::hir(exec_list *instructions,
   op[1] = get_scalar_boolean_operand(&rhs_instructions, state, this, 1,
 "RHS", &error_emitted);
 
-  ir_constant *op0_const = op[0]->constant_expression_value();
-  if (op0_const) {
-if (op0_const->value.b[0]) {
-   instructions->append_list(&rhs_instructions);
-   result = op[1];
-} else {
-   result = op0_const;
-}
-type = glsl_type::bool_type;
+  if (rhs_instructions.is_empty()) {
+result = new(ctx) ir_expression(ir_binop_logic_and, op[0], op[1]);
+type = result->type;
   } else {
 ir_variable *const tmp = new(ctx) ir_variable(glsl_type::bool_type,
   "and_tmp",
@@ -1241,14 +1235,9 @@ ast_expression::hir(exec_list *instructions,
   op[1] = get_scalar_boolean_operand(&rhs_instructions, state, this, 1,
 "RHS", &error_emitted);
 
-  ir_constant *op0_const = op[0]->constant_expression_value();
-  if (op0_const) {
-if (op0_const->value.b[0]) {
-   result = op0_const;
-} else {
-   result = op[1];
-}
-type = glsl_type::bool_type;
+  if (rhs_instructions.is_empty()) {
+result = new(ctx) ir_expression(ir_binop_logic_or, op[0], op[1]);
+type = result->type;
   } else {
 ir_variable *const tmp = new(ctx) ir_variable(glsl_type::bool_type,
   "or_tmp",
-- 
1.7.9

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


Re: [Mesa-dev] [PATCH 0/6] R600 invariant state and draw_vbo cleanup

2012-02-16 Thread Tom Stellard
On Thu, Feb 16, 2012 at 10:04:07PM +0100, Marek Olšák wrote:
> Hi everyone,
> 
> The main motivation behind this series is to move updates of invariant 
> registers to the beginning of CS. Invariant registers are those which never 
> change thoughout a CS, so they don't need to be part of gallium states and 
> examined everytime such states are changed. Besides that, the series cleans 
> up the draw_vbo code.
> 
> Please review.
> 
> I would like to mention that I can't test Cayman. If somebody has a 
> Cayman-based GPU, the patches can be pulled from here:
>   git://people.freedesktop.org/~mareko/mesa r600-invariant-state

Hi Marek,

Just tested on Cayman, no piglit regressions.

-Tom

> 
> Thanks.
> 
> Marek
> ___
> 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 3/3] mesa: Only flag _NEW_TEXTURE on texture updates when a texture changes.

2012-02-16 Thread Eric Anholt
There are three reasons left for this function flagging it:
Re-computing completeness (and therefore the number of levels),
binding a new current texture object, or you're doing some sort of
fixed function (and nobody cares).  For other cases, like rebinding a
shader, we no longer trigger the driver recomputing every piece of
texture state.

Improves a VS state change microbenchmark by 14.8284% +/- 1.02% (n=10)
on gen7.  No statistically significant performance difference on
640x480 nexuiz (n=78).

v2: Remove obsoleted comment, fix state flagging on transition to
!_ReallyEnabled by unreffing the object (which seems like a good
idea anyway).
---

The unreffing appears to have cleared up my hang.  I'm thinking about
how to write a testcase.

 src/mesa/main/texstate.c |   36 ++--
 1 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
index 641e1f8..8c811d7 100644
--- a/src/mesa/main/texstate.c
+++ b/src/mesa/main/texstate.c
@@ -592,9 +592,6 @@ update_texture_state( struct gl_context *ctx )
 * FINISHME: here.
 */
 
-   /* TODO: only set this if there are actual changes */
-   ctx->NewState |= _NEW_TEXTURE;
-
/*
 * Update texture unit state.
 */
@@ -604,6 +601,7 @@ update_texture_state( struct gl_context *ctx )
   GLbitfield enabledFragTargets = 0x0;
   GLbitfield enabledTargets = 0x0;
   GLuint texIndex;
+  struct gl_texture_object *oldObj = texUnit->_Current;
 
   /* Get the bitmask of texture target enables.
* enableBits will be a mask of the TEXTURE_*_BIT flags indicating
@@ -625,10 +623,18 @@ update_texture_state( struct gl_context *ctx )
 
   enabledTargets = enabledVertTargets | enabledFragTargets;
 
+  /* This is not flagged with _NEW_TEXTURE, because the test for changing 
of
+   * the _Current texture object will cover every case where _ReallyEnabled
+   * could have changed.
+   */
   texUnit->_ReallyEnabled = 0x0;
 
   if (enabledTargets == 0x0) {
  /* neither vertex nor fragment processing uses this unit */
+if (texUnit->_Current) {
+   _mesa_reference_texobj(&texUnit->_Current, NULL);
+   ctx->NewState |= _NEW_TEXTURE;
+}
  continue;
   }
 
@@ -642,6 +648,10 @@ update_texture_state( struct gl_context *ctx )
  if (enabledTargets & (1 << texIndex)) {
 struct gl_texture_object *texObj = texUnit->CurrentTex[texIndex];
 if (!texObj->_Complete) {
+  /* While _Complete is only consumed by us, this call also updates
+ _MaxLevel, which drivers do need to see.
+   */
+  ctx->NewState |= _NEW_TEXTURE;
_mesa_test_texobj_completeness(ctx, texObj);
 }
 if (texObj->_Complete) {
@@ -668,22 +678,26 @@ update_texture_state( struct gl_context *ctx )
 _mesa_reference_texobj(&texUnit->_Current, texObj);
 texUnit->_ReallyEnabled = 1 << texTarget;
  }
- else {
-/* fixed-function: texture unit is really disabled */
-continue;
- }
   }
+
+  if (oldObj != texUnit->_Current)
+ctx->NewState |= _NEW_TEXTURE;
}
 
 
/* Determine which texture coordinate sets are actually needed */
if (fprog) {
   const GLuint coordMask = (1 << MAX_TEXTURE_COORD_UNITS) - 1;
+  GLuint new_coord_units = ((fprog->InputsRead >> FRAG_ATTRIB_TEX0) &
+   coordMask);
   /* Note that this gets consumed by update_ffvs_texture_state(). */
-  ctx->Texture._EnabledCoordUnits
- = (fprog->InputsRead >> FRAG_ATTRIB_TEX0) & coordMask;
+  if (ctx->Texture._EnabledCoordUnits != new_coord_units) {
+ctx->NewState |= _NEW_TEXTURE;
+ctx->Texture._EnabledCoordUnits = new_coord_units;
+  }
}
else {
+  ctx->NewState |= _NEW_TEXTURE;
   update_fffs_texture_state(ctx);
}
 
@@ -691,8 +705,10 @@ update_texture_state( struct gl_context *ctx )
 * program.  Those state flags are only used in the case of fixed function
 * vertex shading, in the tnl pipeline or ff_vertex_shader.
 */
-   if (!vprog)
+   if (!vprog) {
+  ctx->NewState |= _NEW_TEXTURE;
   update_ffvs_texture_state(ctx);
+   }
 }
 
 
-- 
1.7.9

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


[Mesa-dev] [PATCH 2/3] mesa: Avoid computing fixed function texture state setup if possible.

2012-02-16 Thread Eric Anholt
None of the consumers of this state will be called while the fs or vs
is in place, and the update_texture_state() call will get re-called on
fs/vs change, so it should be safe to skip the computation.  Improves
the performance of a VS state change microbenchmark by 1.60186% +/-
0.443318% (n=20).

v2: Add comments explaining the flow of state to these two functions.
---
 src/mesa/main/texstate.c |  133 +
 1 files changed, 86 insertions(+), 47 deletions(-)

diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
index 187ec9c..641e1f8 100644
--- a/src/mesa/main/texstate.c
+++ b/src/mesa/main/texstate.c
@@ -476,6 +476,84 @@ update_tex_combine(struct gl_context *ctx, struct 
gl_texture_unit *texUnit)
}
 }
 
+/**
+ * Sets up the computed texture combiner state to be used by the fixed function
+ * fragment program, and the texture coordinates used by the fixed function
+ * fragment program, for use in setting up the fixed function vertex program.
+ *
+ * Thus, this has to come after _ReallyEnabled setup, but before
+ * update_ffvs_texture_state().
+ */
+static void
+update_fffs_texture_state(struct gl_context *ctx)
+{
+   GLuint unit;
+
+   ctx->Texture._EnabledUnits = 0;
+   ctx->Texture._EnabledCoordUnits = 0;
+
+   for (unit = 0; unit < ctx->Const.MaxCombinedTextureImageUnits; unit++) {
+  struct gl_texture_unit *texUnit = &ctx->Texture.Unit[unit];
+
+  if (!texUnit->_ReallyEnabled)
+continue;
+
+  ctx->Texture._EnabledUnits |= (1 << unit);
+  ctx->Texture._EnabledCoordUnits |= (1 << unit);
+
+  update_tex_combine(ctx, texUnit);
+   }
+}
+
+/**
+ * Sets up the computed fixed function vertex program state for texturing by 
the
+ * fragment shader, which is all about choosing what texture coordinates we 
need
+ * as vertex outputs and how to compute them.
+ *
+ * This relies on the choice of texture units (_ReallyEnabled) and the choice 
of
+ * texture coordinates needed as FS inputs (_EnabledCoordUnits).
+ */
+static void
+update_ffvs_texture_state(struct gl_context *ctx)
+{
+   GLuint unit;
+
+   ctx->Texture._GenFlags = 0x0;
+   ctx->Texture._TexMatEnabled = 0x0;
+   ctx->Texture._TexGenEnabled = 0x0;
+
+   /* Setup texgen for those texture coordinate sets that are in use */
+   for (unit = 0; unit < ctx->Const.MaxTextureCoordUnits; unit++) {
+  struct gl_texture_unit *texUnit = &ctx->Texture.Unit[unit];
+
+  texUnit->_GenFlags = 0x0;
+
+  if (!(ctx->Texture._EnabledCoordUnits & (1 << unit)))
+continue;
+
+  if (texUnit->TexGenEnabled) {
+if (texUnit->TexGenEnabled & S_BIT) {
+   texUnit->_GenFlags |= texUnit->GenS._ModeBit;
+}
+if (texUnit->TexGenEnabled & T_BIT) {
+   texUnit->_GenFlags |= texUnit->GenT._ModeBit;
+}
+if (texUnit->TexGenEnabled & R_BIT) {
+   texUnit->_GenFlags |= texUnit->GenR._ModeBit;
+}
+if (texUnit->TexGenEnabled & Q_BIT) {
+   texUnit->_GenFlags |= texUnit->GenQ._ModeBit;
+}
+
+ctx->Texture._TexGenEnabled |= ENABLE_TEXGEN(unit);
+ctx->Texture._GenFlags |= texUnit->_GenFlags;
+  }
+
+  ASSERT(unit < Elements(ctx->TextureMatrixStack));
+  if (ctx->TextureMatrixStack[unit].Top->type != MATRIX_IDENTITY)
+ctx->Texture._TexMatEnabled |= ENABLE_TEXMAT(unit);
+   }
+}
 
 /**
  * \note This routine refers to derived texture matrix values to
@@ -491,7 +569,6 @@ update_texture_state( struct gl_context *ctx )
GLuint unit;
struct gl_program *fprog = NULL;
struct gl_program *vprog = NULL;
-   GLbitfield enabledFragUnits = 0x0;
 
if (ctx->Shader.CurrentVertexProgram &&
ctx->Shader.CurrentVertexProgram->LinkStatus) {
@@ -518,11 +595,6 @@ update_texture_state( struct gl_context *ctx )
/* TODO: only set this if there are actual changes */
ctx->NewState |= _NEW_TEXTURE;
 
-   ctx->Texture._EnabledUnits = 0x0;
-   ctx->Texture._GenFlags = 0x0;
-   ctx->Texture._TexMatEnabled = 0x0;
-   ctx->Texture._TexGenEnabled = 0x0;
-
/*
 * Update texture unit state.
 */
@@ -601,59 +673,26 @@ update_texture_state( struct gl_context *ctx )
 continue;
  }
   }
-
-  /* if we get here, we know this texture unit is enabled */
-
-  ctx->Texture._EnabledUnits |= (1 << unit);
-
-  if (enabledFragTargets)
- enabledFragUnits |= (1 << unit);
-
-  update_tex_combine(ctx, texUnit);
}
 
 
/* Determine which texture coordinate sets are actually needed */
if (fprog) {
   const GLuint coordMask = (1 << MAX_TEXTURE_COORD_UNITS) - 1;
+  /* Note that this gets consumed by update_ffvs_texture_state(). */
   ctx->Texture._EnabledCoordUnits
  = (fprog->InputsRead >> FRAG_ATTRIB_TEX0) & coordMask;
}
else {
-  ctx->Texture._EnabledCoordUnits = enabledFragUnits;
+  update_fffs_texture_state(ctx);
}
 
-   /* Setup texgen for those texture coordinate sets that are in

[Mesa-dev] [PATCH 1/3] intel: Silence valgrind warning for getparam ioctl argument.

2012-02-16 Thread Eric Anholt
It was concerned that the 4 pad bytes on LP64 were uninitialized.
---
 src/mesa/drivers/dri/intel/intel_screen.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_screen.c 
b/src/mesa/drivers/dri/intel/intel_screen.c
index 60781e5..4eeeb2f 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -361,6 +361,7 @@ intel_get_param(__DRIscreen *psp, int param, int *value)
int ret;
struct drm_i915_getparam gp;
 
+   memset(&gp, 0, sizeof(gp));
gp.param = param;
gp.value = value;
 
-- 
1.7.9

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


Re: [Mesa-dev] [RFC] Merging feature work to Mesa master

2012-02-16 Thread Marek Olšák
On Thu, Feb 16, 2012 at 12:28 AM, Ian Romanick  wrote:
> Over the last six months a lot of feature work has happened in Mesa, and the
> load has been carried by a lot of different people / organization. In the
> process, we discovered a number of development process issues that made
> things more difficult than they needed to be.
>
> The biggest problem the we encountered was the number of features marked
> "50% done" in GL3.txt.  To complete these features, a significant amount of
> time had to be spent figuring out what was done, and what was left to do.
>  Since the changes had landed on master a very long time ago, this was a
> frustrating and error prone process.  Transform feedback was the worst case
> of this.  One developer spent several weeks trying to assess the state of
> development.  In the process, a couple items were missed and not detected
> until early January.
>
> PROPOSAL: No feature will be merged to master until a vertical slice[1] of
> functionality is complete.
>
> To be specific, this means that some useful workload should be able to
> correctly execute.  This doesn't mean that everything is done or even that
> any particular real application needs to work.  At the very least there
> should be a demo or piglit test that uses the functionality in its intended
> manner that works.
>
> This means that some incomplete features may sit on branches of a long time.
>  That's okay!  It's really easy to see what has been done on a branch
> because you can 'git log origin/master..EXT_some_feature'.  This trivializes
> the assessment of the state of development.
>
> We encountered similar problems with pieces of functionality that were
> ostensibly done.  Many elements of OpenGL functionality are like Koch
> snowflakes:  everything is a corner case.  Integer textures and
> floating-point textures are prime cases of this.  Even though the
> implementation was done and enabled in several drivers, we had no way to
> assess the quality.  The same problem holds in cases of features that are
> known to be incomplete, even if a vertical slice is functional.
>
> PROPOSAL: No feature will be merged to master until a robust set of tests
> are implemented or at least documented.
>
> We don't necessarily need 10,000 tests for some feature, but there should be
> some.  There should also be a list of "test this corner case, test that
> corner case, check this error condition, etc."  As an example, we've come up
> with a list of missing test cases for EXT_framebuffer_multisample:
>
> - Test turning multisample on and off on a MSAA buffer.
> - Test multisample points smooth
> - Test multisample points non-smooth
> - Test multisample lines smooth
> - Test multisample lines non-smooth
> - Test multisample line stipple
> - Test multisample polygon smooth
> - Test multisample polygon stipple
> - Test multisample glBitmap
> - Test sample alpha to one
> - Test sample coverage
> - Test sample coverage invert
> - Test sample alpha-to-coverage, with alpha-to-one
> - Test sample alpha-to-coverage, without alpha-to-one
> - Test blit multisample-to-multisample (matching sample count)
> - Test blit multisample-to-multisample (non-matching sample count)
> - Test blit multisample-to-multisample (non-matching format)
> - Test blit singlesample-to-multisample
> - Test blit multisample-to-multisample (scaling blit)
> - Iterate all the above for all the sample counts
> - Iterate all internal formats for some basic MSAA test
> - "All of the above" for depth and stencil
>    - Try really hard to hit HiZ resolves too
>
> This list represents about 30 or 40 test cases.  By giving some indication
> of areas that need testing, we communicate the parts of the feature that are
> known to be incomplete or just plain broken (Keith's 1st Law: Any piece of
> code that isn't tested is broken.).
>
> The test list also need not necessarily come from the developer.  It is
> completely reasonable and desirable for reviewers to suggest or implement
> tests.  All of that information just needs to be captured, and consensus
> must be achieved.
>
> The onus of enforcing these proposals will fall on the reviewers.  This
> still leaves room for sensible things to happen while preventing the
> problems that we encountered.  For example, it should be fine to merge Marek
> and nobled's ARB_debug work with few tests implemented or specified.  The
> same could not be said for the proposed implementation of
> ARB_uniform_buffer_object.

I don't think your first proposal is anything new. Some of us have
been doing that already (me included). Also, I don't see how the first
proposal is related to your complains. Yes, we don't usually write
down what has been done when a feature is incomplete, because there is
no _official_ place where we could just dump our personal notes, todo
lists, ideas, and whatnot.

I think you are unhappy with the current processes, because you and
your colleagues had a punishing deadline in a people-starved project
and it didn't go e

Re: [Mesa-dev] [PATCH] i915: Set swrast_texture_image::Buffer and ::Map during swrast mapping

2012-02-16 Thread Eric Anholt
On Tue, 14 Feb 2012 10:57:17 -0800, "Ian Romanick"  wrote:
> From: Ian Romanick 
> 
> Before calling _tnl_run_pipeline, the i915 driver maps all textures
> used in vertex shaders (via intel_tex_map_images).  Later run_vp tries
> to map the textures again (via _swrast_map_texture).  However, this
> just replaces the actual mappings with NULL pointers.  When the
> pointers are dereferened, a segfault occurs.
> 
> Setting swrast_texture_image::Buffer in intel_tex_map_images works
> around the problem, but I have a hard time believing this is the right
> fix.

Seems to me like the swrast map-things-for-texturing should be using
MapTextureImage.  Then we wouldn't need the intel
pre-_tnl_run_pipeline() mapping.


pgpQDVeOQIuSS.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 an issue with texture border and array textures

2012-02-16 Thread Anuj Phogat
As suggested by Brian, for a 1D texture array, the border only applies to the
width.  For a 2D texture array the border applies to the width and height but
not the depth.  This was not handled correctly _mesa_init_teximage_fields().

Note: This is a candidate for stable branches

Signed-off-by: Anuj Phogat 
---
Sorry for not considering all the cases in my previous patch. Let me know
if i have still missed anything.

 src/mesa/main/teximage.c |   56 +
 1 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index e4eb7f6..a1d5d26 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1083,11 +1083,13 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
GLint border, GLenum internalFormat,
gl_format format)
 {
+   GLenum target;
ASSERT(img);
ASSERT(width >= 0);
ASSERT(height >= 0);
ASSERT(depth >= 0);
 
+   target = img->TexObject->Target;
img->_BaseFormat = _mesa_base_tex_format( ctx, internalFormat );
ASSERT(img->_BaseFormat > 0);
img->InternalFormat = internalFormat;
@@ -1099,26 +1101,60 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
img->Width2 = width - 2 * border;   /* == 1 << img->WidthLog2; */
img->WidthLog2 = _mesa_logbase2(img->Width2);
 
-   if (height == 1) { /* 1-D texture */
+   switch(target) {
+   case GL_TEXTURE_1D:
+   case GL_TEXTURE_BUFFER:
+   case GL_PROXY_TEXTURE_1D:
   img->Height2 = 1;
   img->HeightLog2 = 0;
-   }
-   else {
+  img->Depth2 = 1;
+  img->DepthLog2 = 0;
+  break;
+   case GL_TEXTURE_1D_ARRAY:
+   case GL_PROXY_TEXTURE_1D_ARRAY:
+  img->Height2 = height; /* no border */
+  img->HeightLog2 = 0; /* not used */
+  img->Depth2 = 1;
+  img->DepthLog2 = 0;
+  break;
+   case GL_TEXTURE_2D:
+   case GL_TEXTURE_RECTANGLE:
+   case GL_TEXTURE_CUBE_MAP:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_X:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_X:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_Y:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_Z:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z:
+   case GL_TEXTURE_EXTERNAL_OES:
+   case GL_PROXY_TEXTURE_2D:
+   case GL_PROXY_TEXTURE_RECTANGLE:
+   case GL_PROXY_TEXTURE_CUBE_MAP:
   img->Height2 = height - 2 * border; /* == 1 << img->HeightLog2; */
   img->HeightLog2 = _mesa_logbase2(img->Height2);
-   }
-
-   if (depth == 1) {  /* 2-D texture */
   img->Depth2 = 1;
   img->DepthLog2 = 0;
-   }
-   else {
+  break;
+   case GL_TEXTURE_2D_ARRAY:
+   case GL_PROXY_TEXTURE_2D_ARRAY:
+  img->Height2 = height - 2 * border; /* == 1 << img->HeightLog2; */
+  img->HeightLog2 = _mesa_logbase2(img->Height2);
+  img->Depth2 = depth; /* no border */
+  img->DepthLog2 = 0; /* not used */
+  break;
+   case GL_TEXTURE_3D:
+   case GL_PROXY_TEXTURE_3D:
+  img->Height2 = height - 2 * border; /* == 1 << img->HeightLog2; */
+  img->HeightLog2 = _mesa_logbase2(img->Height2);
   img->Depth2 = depth - 2 * border;   /* == 1 << img->DepthLog2; */
   img->DepthLog2 = _mesa_logbase2(img->Depth2);
+  break;
+   default:
+  _mesa_problem(NULL, "invalid target 0x%x in 
_mesa_init_teximage_fields()",
+target);
}
-
+
img->MaxLog2 = MAX2(img->WidthLog2, img->HeightLog2);
-
img->TexFormat = format;
 }
 
-- 
1.7.7.6

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


Re: [Mesa-dev] [PATCH 2/3] mesa: Avoid computing fixed function texture state setup if possible.

2012-02-16 Thread Brian Paul

On 02/16/2012 04:40 PM, Eric Anholt wrote:

None of the consumers of this state will be called while the fs or vs
is in place, and the update_texture_state() call will get re-called on
fs/vs change, so it should be safe to skip the computation.  Improves
the performance of a VS state change microbenchmark by 1.60186% +/-
0.443318% (n=20).

v2: Add comments explaining the flow of state to these two functions.
---


It looks like the comments might be longer than 80 columns, but it's 
not a big deal.


Reviewed-by: Brian Paul 

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


Re: [Mesa-dev] [PATCH 3/3] mesa: Only flag _NEW_TEXTURE on texture updates when a texture changes.

2012-02-16 Thread Brian Paul

On 02/16/2012 04:40 PM, Eric Anholt wrote:

There are three reasons left for this function flagging it:
Re-computing completeness (and therefore the number of levels),
binding a new current texture object, or you're doing some sort of
fixed function (and nobody cares).  For other cases, like rebinding a
shader, we no longer trigger the driver recomputing every piece of
texture state.

Improves a VS state change microbenchmark by 14.8284% +/- 1.02% (n=10)
on gen7.  No statistically significant performance difference on
640x480 nexuiz (n=78).

v2: Remove obsoleted comment, fix state flagging on transition to
 !_ReallyEnabled by unreffing the object (which seems like a good
 idea anyway).
---

The unreffing appears to have cleared up my hang.  I'm thinking about
how to write a testcase.

  src/mesa/main/texstate.c |   36 ++--
  1 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
index 641e1f8..8c811d7 100644
--- a/src/mesa/main/texstate.c
+++ b/src/mesa/main/texstate.c
@@ -592,9 +592,6 @@ update_texture_state( struct gl_context *ctx )
  * FINISHME: here.
  */

-   /* TODO: only set this if there are actual changes */
-   ctx->NewState |= _NEW_TEXTURE;
-
 /*
  * Update texture unit state.
  */
@@ -604,6 +601,7 @@ update_texture_state( struct gl_context *ctx )
GLbitfield enabledFragTargets = 0x0;
GLbitfield enabledTargets = 0x0;
GLuint texIndex;
+  struct gl_texture_object *oldObj = texUnit->_Current;

/* Get the bitmask of texture target enables.
 * enableBits will be a mask of the TEXTURE_*_BIT flags indicating
@@ -625,10 +623,18 @@ update_texture_state( struct gl_context *ctx )

enabledTargets = enabledVertTargets | enabledFragTargets;

+  /* This is not flagged with _NEW_TEXTURE, because the test for changing 
of
+   * the _Current texture object will cover every case where _ReallyEnabled
+   * could have changed.
+   */
texUnit->_ReallyEnabled = 0x0;

if (enabledTargets == 0x0) {
   /* neither vertex nor fragment processing uses this unit */
+if (texUnit->_Current) {
+   _mesa_reference_texobj(&texUnit->_Current, NULL);
+   ctx->NewState |= _NEW_TEXTURE;
+}
   continue;
}

@@ -642,6 +648,10 @@ update_texture_state( struct gl_context *ctx )
   if (enabledTargets&  (1<<  texIndex)) {
  struct gl_texture_object *texObj = texUnit->CurrentTex[texIndex];
  if (!texObj->_Complete) {
+  /* While _Complete is only consumed by us, this call also updates
+ _MaxLevel, which drivers do need to see.
+   */
+  ctx->NewState |= _NEW_TEXTURE;
 _mesa_test_texobj_completeness(ctx, texObj);
  }
  if (texObj->_Complete) {
@@ -668,22 +678,26 @@ update_texture_state( struct gl_context *ctx )
  _mesa_reference_texobj(&texUnit->_Current, texObj);
  texUnit->_ReallyEnabled = 1<<  texTarget;
   }
- else {
-/* fixed-function: texture unit is really disabled */
-continue;
- }
}
+
+  if (oldObj != texUnit->_Current)
+ctx->NewState |= _NEW_TEXTURE;
 }


 /* Determine which texture coordinate sets are actually needed */
 if (fprog) {
const GLuint coordMask = (1<<  MAX_TEXTURE_COORD_UNITS) - 1;
+  GLuint new_coord_units = ((fprog->InputsRead>>  FRAG_ATTRIB_TEX0)&
+   coordMask);


I have a feeling that MSVC is going to generate a warning here since 
InpusRead is a 64-bit field but new_coord_units is 32 bits.  If so, I 
can follow-up with a fix.




/* Note that this gets consumed by update_ffvs_texture_state(). */
-  ctx->Texture._EnabledCoordUnits
- = (fprog->InputsRead>>  FRAG_ATTRIB_TEX0)&  coordMask;
+  if (ctx->Texture._EnabledCoordUnits != new_coord_units) {
+ctx->NewState |= _NEW_TEXTURE;
+ctx->Texture._EnabledCoordUnits = new_coord_units;
+  }
 }
 else {
+  ctx->NewState |= _NEW_TEXTURE;
update_fffs_texture_state(ctx);
 }

@@ -691,8 +705,10 @@ update_texture_state( struct gl_context *ctx )
  * program.  Those state flags are only used in the case of fixed function
  * vertex shading, in the tnl pipeline or ff_vertex_shader.
  */
-   if (!vprog)
+   if (!vprog) {
+  ctx->NewState |= _NEW_TEXTURE;
update_ffvs_texture_state(ctx);
+   }
  }




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


Re: [Mesa-dev] [RFC] Merging feature work to Mesa master

2012-02-16 Thread Eric Anholt
On Fri, 17 Feb 2012 00:45:00 +0100, Marek Olšák  wrote:
> I think the problem is not in the process itself, but in the fact that
> this project lacks manpower (at least outside of the Intel camp) and I
> am afraid it will not get better without another 5-10 people working
> full-time on the project. Independent contributors like myself will
> never have enough time to implement tests for every possible corner
> case which may occur.

I don't think I want the project to demand a complete set of tests (nor
did Ian's post ask for that), but I think some sort of assessment along
with the first pile of code of "here's a summary of what's in the spec
that I know I haven't finished for testing and implementation" is
entirely reasonable and would have would have been a big deal to have.

I came into EXT_texture_integer thinking that things were supposed to be
about half done in core, since it said ~50%.  I think today it might be
close to 50%, and piglit testing is maybe at 25%.  (I only think that
because of our internal testsuite, where we're at about 50%)

On the other hand, after my experience with the "50% done" GL3 features,
I started poking at MSAA (supposedly already done in core) assuming that
nobody had done anything and that everything was broken.  So far, the
record is that >50% of tests I write show things that are broken, even
though this is something that was supposed to have already been done in
core.

Similarly, when I hit a bug in ARB_copy_buffer, I decided to go write
tests for the spec instead of just patching up the driver: it took two
hours, and at the end I posted a list of things that I knew were
weaknesses in our testing that the next person picking up
ARB_copy_buffer might want to think about.  That's the model I'd like to
see, except that it should come with the first implementation.


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


Re: [Mesa-dev] [RFC] Merging feature work to Mesa master

2012-02-16 Thread Ian Romanick

On 02/16/2012 07:08 AM, Brian Paul wrote:

On 02/15/2012 04:28 PM, Ian Romanick wrote:

Over the last six months a lot of feature work has happened in Mesa,
and the load has been carried by a lot of different people /
organization. In the process, we discovered a number of development
process issues that made things more difficult than they needed to be.

The biggest problem the we encountered was the number of features
marked "50% done" in GL3.txt. To complete these features, a
significant amount of time had to be spent figuring out what was done,
and what was left to do. Since the changes had landed on master a very
long time ago, this was a frustrating and error prone process.
Transform feedback was the worst case of this. One developer spent
several weeks trying to assess the state of development. In the
process, a couple items were missed and not detected until early January.


In the future the developer could just send an email to the person who
last worked on the feature asking "what's the status of this?". With
git-blame it's easy to see who last touched a section of code or the
corresponding line in the GL3.txt file.


git-blame tells a lot, but it doesn't tell the whole story.  Big 
features like transform feedback or integer textures hit code all over 
the place.  It's really hard to track all of that down.  The new 
function entrypoints, setting up the dispatch tables, new enables, new 
gets, etc.  The archaeology is nontrivial.



I'd be happy to answer such queries and I think others would too.


That presumes:

a) The author remembers.  A lot of the transform feedback code landed a 
around March 2010.  That made it over a year old when Dan started.  I 
surely don't remember the details of any of my partial branches from a 
year ago. :)


b) The author is still around.  Quite a number of people only hang 
around the project for a short time.  Who would a person ask about the 
DX11 state tracker, for example?



PROPOSAL: No feature will be merged to master until a vertical
slice[1] of functionality is complete.

To be specific, this means that some useful workload should be able to
correctly execute. This doesn't mean that everything is done or even
that any particular real application needs to work. At the very least
there should be a demo or piglit test that uses the functionality in
its intended manner that works.

This means that some incomplete features may sit on branches of a long
time. That's okay! It's really easy to see what has been done on a
branch because you can 'git log origin/master..EXT_some_feature'. This
trivializes the assessment of the state of development.


This sounds good in general. Are you concerned about the gallium code
too? Personally, I'm fine with Dave chipping away at GL 3 support in
gallium (for example) without completing a full vertical slice.


At this point, the vertical slice for the GL 3.0 stuff is done.

I'm thinking of future "big" things like uniform buffer objects, 
tessellation shaders, shader image load / store, etc.  I can see someone 
trying to land only the shading language portions of those or only the 
linker portions, for example.  That's the case where we have a big blob 
of untested (and untestable) code laying around.  I want to avoid that.


One thing that /could/ mitigate this is unit tests.  A partial piece of 
functionality with unit tests to exercise the implemented bits (and 
thereby document what has been done) would be a different situation 
altogether.



We encountered similar problems with pieces of functionality that were
ostensibly done. Many elements of OpenGL functionality are like Koch
snowflakes: everything is a corner case. Integer textures and
floating-point textures are prime cases of this. Even though the
implementation was done and enabled in several drivers, we had no way
to assess the quality. The same problem holds in cases of features
that are known to be incomplete, even if a vertical slice is functional.

PROPOSAL: No feature will be merged to master until a robust set of
tests are implemented or at least documented.


Sounds good too.

-Brian

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


Re: [Mesa-dev] [RFC] Merging feature work to Mesa master

2012-02-16 Thread Ian Romanick

On 02/16/2012 03:45 PM, Marek Olšák wrote:

On Thu, Feb 16, 2012 at 12:28 AM, Ian Romanick  wrote:

Over the last six months a lot of feature work has happened in Mesa, and the
load has been carried by a lot of different people / organization. In the
process, we discovered a number of development process issues that made
things more difficult than they needed to be.

The biggest problem the we encountered was the number of features marked
"50% done" in GL3.txt.  To complete these features, a significant amount of
time had to be spent figuring out what was done, and what was left to do.
  Since the changes had landed on master a very long time ago, this was a
frustrating and error prone process.  Transform feedback was the worst case
of this.  One developer spent several weeks trying to assess the state of
development.  In the process, a couple items were missed and not detected
until early January.

PROPOSAL: No feature will be merged to master until a vertical slice[1] of
functionality is complete.

To be specific, this means that some useful workload should be able to
correctly execute.  This doesn't mean that everything is done or even that
any particular real application needs to work.  At the very least there
should be a demo or piglit test that uses the functionality in its intended
manner that works.

This means that some incomplete features may sit on branches of a long time.
  That's okay!  It's really easy to see what has been done on a branch
because you can 'git log origin/master..EXT_some_feature'.  This trivializes
the assessment of the state of development.

We encountered similar problems with pieces of functionality that were
ostensibly done.  Many elements of OpenGL functionality are like Koch
snowflakes:  everything is a corner case.  Integer textures and
floating-point textures are prime cases of this.  Even though the
implementation was done and enabled in several drivers, we had no way to
assess the quality.  The same problem holds in cases of features that are
known to be incomplete, even if a vertical slice is functional.

PROPOSAL: No feature will be merged to master until a robust set of tests
are implemented or at least documented.

We don't necessarily need 10,000 tests for some feature, but there should be
some.  There should also be a list of "test this corner case, test that
corner case, check this error condition, etc."  As an example, we've come up
with a list of missing test cases for EXT_framebuffer_multisample:

- Test turning multisample on and off on a MSAA buffer.
- Test multisample points smooth
- Test multisample points non-smooth
- Test multisample lines smooth
- Test multisample lines non-smooth
- Test multisample line stipple
- Test multisample polygon smooth
- Test multisample polygon stipple
- Test multisample glBitmap
- Test sample alpha to one
- Test sample coverage
- Test sample coverage invert
- Test sample alpha-to-coverage, with alpha-to-one
- Test sample alpha-to-coverage, without alpha-to-one
- Test blit multisample-to-multisample (matching sample count)
- Test blit multisample-to-multisample (non-matching sample count)
- Test blit multisample-to-multisample (non-matching format)
- Test blit singlesample-to-multisample
- Test blit multisample-to-multisample (scaling blit)
- Iterate all the above for all the sample counts
- Iterate all internal formats for some basic MSAA test
- "All of the above" for depth and stencil
- Try really hard to hit HiZ resolves too

This list represents about 30 or 40 test cases.  By giving some indication
of areas that need testing, we communicate the parts of the feature that are
known to be incomplete or just plain broken (Keith's 1st Law: Any piece of
code that isn't tested is broken.).

The test list also need not necessarily come from the developer.  It is
completely reasonable and desirable for reviewers to suggest or implement
tests.  All of that information just needs to be captured, and consensus
must be achieved.

The onus of enforcing these proposals will fall on the reviewers.  This
still leaves room for sensible things to happen while preventing the
problems that we encountered.  For example, it should be fine to merge Marek
and nobled's ARB_debug work with few tests implemented or specified.  The
same could not be said for the proposed implementation of
ARB_uniform_buffer_object.


I don't think your first proposal is anything new. Some of us have
been doing that already (me included). Also, I don't see how the first
proposal is related to your complains. Yes, we don't usually write
down what has been done when a feature is incomplete, because there is
no _official_ place where we could just dump our personal notes, todo
lists, ideas, and whatnot.


It's certainly contrary to how some things have been done in Mesa. 
There are already dangling bits for GL_ARB_uniform_buffer_object, 
GL_ARB_texture_buffer_object, GL_EXT_gpu_shader4, and probably others.



I think you are unhappy with the current processes, 

Re: [Mesa-dev] [PATCH] mesa: fix an issue with texture border and array textures

2012-02-16 Thread Ian Romanick

On 02/16/2012 04:11 PM, Anuj Phogat wrote:

As suggested by Brian, for a 1D texture array, the border only applies to the
width.  For a 2D texture array the border applies to the width and height but
not the depth.  This was not handled correctly _mesa_init_teximage_fields().

Note: This is a candidate for stable branches

Signed-off-by: Anuj Phogat
---
Sorry for not considering all the cases in my previous patch. Let me know
if i have still missed anything.


It looks like everything is here, but I think we need some piglit tests. 
 I would at least like to see a couple tests that would have failed 
with one or more of the previous patches.  I think the right thing is to 
try create a texture with (and without) border for each possible target. 
 Then query the dimensions and border size and test against the 
expected values.


Brian, does that sound like it would catch the issues you raised in the 
previous versions of the patch?



  src/mesa/main/teximage.c |   56 +
  1 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index e4eb7f6..a1d5d26 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1083,11 +1083,13 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
 GLint border, GLenum internalFormat,
 gl_format format)
  {
+   GLenum target;
 ASSERT(img);
 ASSERT(width>= 0);
 ASSERT(height>= 0);
 ASSERT(depth>= 0);

+   target = img->TexObject->Target;
 img->_BaseFormat = _mesa_base_tex_format( ctx, internalFormat );
 ASSERT(img->_BaseFormat>  0);
 img->InternalFormat = internalFormat;
@@ -1099,26 +1101,60 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
 img->Width2 = width - 2 * border;   /* == 1<<  img->WidthLog2; */
 img->WidthLog2 = _mesa_logbase2(img->Width2);

-   if (height == 1) { /* 1-D texture */
+   switch(target) {
+   case GL_TEXTURE_1D:
+   case GL_TEXTURE_BUFFER:
+   case GL_PROXY_TEXTURE_1D:
img->Height2 = 1;
img->HeightLog2 = 0;
-   }
-   else {
+  img->Depth2 = 1;
+  img->DepthLog2 = 0;
+  break;
+   case GL_TEXTURE_1D_ARRAY:
+   case GL_PROXY_TEXTURE_1D_ARRAY:
+  img->Height2 = height; /* no border */
+  img->HeightLog2 = 0; /* not used */
+  img->Depth2 = 1;
+  img->DepthLog2 = 0;
+  break;
+   case GL_TEXTURE_2D:
+   case GL_TEXTURE_RECTANGLE:
+   case GL_TEXTURE_CUBE_MAP:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_X:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_X:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_Y:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_Z:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z:
+   case GL_TEXTURE_EXTERNAL_OES:
+   case GL_PROXY_TEXTURE_2D:
+   case GL_PROXY_TEXTURE_RECTANGLE:
+   case GL_PROXY_TEXTURE_CUBE_MAP:
img->Height2 = height - 2 * border; /* == 1<<  img->HeightLog2; */
img->HeightLog2 = _mesa_logbase2(img->Height2);
-   }
-
-   if (depth == 1) {  /* 2-D texture */
img->Depth2 = 1;
img->DepthLog2 = 0;
-   }
-   else {
+  break;
+   case GL_TEXTURE_2D_ARRAY:
+   case GL_PROXY_TEXTURE_2D_ARRAY:
+  img->Height2 = height - 2 * border; /* == 1<<  img->HeightLog2; */
+  img->HeightLog2 = _mesa_logbase2(img->Height2);
+  img->Depth2 = depth; /* no border */
+  img->DepthLog2 = 0; /* not used */
+  break;
+   case GL_TEXTURE_3D:
+   case GL_PROXY_TEXTURE_3D:
+  img->Height2 = height - 2 * border; /* == 1<<  img->HeightLog2; */
+  img->HeightLog2 = _mesa_logbase2(img->Height2);
img->Depth2 = depth - 2 * border;   /* == 1<<  img->DepthLog2; */
img->DepthLog2 = _mesa_logbase2(img->Depth2);
+  break;
+   default:
+  _mesa_problem(NULL, "invalid target 0x%x in 
_mesa_init_teximage_fields()",
+target);
 }
-
+
 img->MaxLog2 = MAX2(img->WidthLog2, img->HeightLog2);
-
 img->TexFormat = format;
  }



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


[Mesa-dev] [PATCH 1/3] gallium: remove unused winsys pointers in pipe_screen and pipe_context

2012-02-16 Thread Marek Olšák
A winsys is already a private object of a driver.
---
 src/gallium/drivers/galahad/glhd_context.c |1 -
 src/gallium/drivers/galahad/glhd_screen.c  |2 --
 src/gallium/drivers/i915/i915_context.c|1 -
 src/gallium/drivers/i915/i915_screen.c |2 --
 src/gallium/drivers/identity/id_context.c  |1 -
 src/gallium/drivers/identity/id_screen.c   |2 --
 src/gallium/drivers/llvmpipe/lp_context.c  |1 -
 src/gallium/drivers/noop/noop_pipe.c   |2 --
 src/gallium/drivers/r300/r300_context.c|1 -
 src/gallium/drivers/r300/r300_screen.c |1 -
 src/gallium/drivers/r600/r600_pipe.c   |2 --
 src/gallium/drivers/rbug/rbug_context.c|1 -
 src/gallium/drivers/rbug/rbug_screen.c |2 --
 src/gallium/drivers/softpipe/sp_context.c  |1 -
 src/gallium/drivers/softpipe/sp_screen.c   |1 -
 src/gallium/drivers/svga/svga_context.c|1 -
 src/gallium/drivers/trace/tr_context.c |1 -
 src/gallium/drivers/trace/tr_screen.c  |9 -
 src/gallium/include/pipe/p_context.h   |1 -
 src/gallium/include/pipe/p_screen.h|3 ---
 src/gallium/include/state_tracker/drm_driver.h |1 -
 21 files changed, 0 insertions(+), 37 deletions(-)

diff --git a/src/gallium/drivers/galahad/glhd_context.c 
b/src/gallium/drivers/galahad/glhd_context.c
index a4afa81..f710480 100644
--- a/src/gallium/drivers/galahad/glhd_context.c
+++ b/src/gallium/drivers/galahad/glhd_context.c
@@ -973,7 +973,6 @@ galahad_context_create(struct pipe_screen *_screen, struct 
pipe_context *pipe)
   return NULL;
}
 
-   glhd_pipe->base.winsys = NULL;
glhd_pipe->base.screen = _screen;
glhd_pipe->base.priv = pipe->priv; /* expose wrapped data */
glhd_pipe->base.draw = NULL;
diff --git a/src/gallium/drivers/galahad/glhd_screen.c 
b/src/gallium/drivers/galahad/glhd_screen.c
index 2fe82fe..49702b6 100644
--- a/src/gallium/drivers/galahad/glhd_screen.c
+++ b/src/gallium/drivers/galahad/glhd_screen.c
@@ -311,8 +311,6 @@ galahad_screen_create(struct pipe_screen *screen)
   return screen;
}
 
-   glhd_screen->base.winsys = NULL;
-
glhd_screen->base.destroy = galahad_screen_destroy;
glhd_screen->base.get_name = galahad_screen_get_name;
glhd_screen->base.get_vendor = galahad_screen_get_vendor;
diff --git a/src/gallium/drivers/i915/i915_context.c 
b/src/gallium/drivers/i915/i915_context.c
index 8197629..5e0ced2 100644
--- a/src/gallium/drivers/i915/i915_context.c
+++ b/src/gallium/drivers/i915/i915_context.c
@@ -143,7 +143,6 @@ i915_create_context(struct pipe_screen *screen, void *priv)
   return NULL;
 
i915->iws = i915_screen(screen)->iws;
-   i915->base.winsys = NULL;
i915->base.screen = screen;
i915->base.priv = priv;
 
diff --git a/src/gallium/drivers/i915/i915_screen.c 
b/src/gallium/drivers/i915/i915_screen.c
index a37241f..61340f3 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -452,8 +452,6 @@ i915_screen_create(struct i915_winsys *iws)
 
is->iws = iws;
 
-   is->base.winsys = NULL;
-
is->base.destroy = i915_destroy_screen;
is->base.flush_frontbuffer = i915_flush_frontbuffer;
 
diff --git a/src/gallium/drivers/identity/id_context.c 
b/src/gallium/drivers/identity/id_context.c
index a9043c1..681ef7b 100644
--- a/src/gallium/drivers/identity/id_context.c
+++ b/src/gallium/drivers/identity/id_context.c
@@ -860,7 +860,6 @@ identity_context_create(struct pipe_screen *_screen, struct 
pipe_context *pipe)
   return NULL;
}
 
-   id_pipe->base.winsys = NULL;
id_pipe->base.screen = _screen;
id_pipe->base.priv = pipe->priv; /* expose wrapped data */
id_pipe->base.draw = NULL;
diff --git a/src/gallium/drivers/identity/id_screen.c 
b/src/gallium/drivers/identity/id_screen.c
index 5675c27..a173235 100644
--- a/src/gallium/drivers/identity/id_screen.c
+++ b/src/gallium/drivers/identity/id_screen.c
@@ -274,8 +274,6 @@ identity_screen_create(struct pipe_screen *screen)
   return NULL;
}
 
-   id_screen->base.winsys = NULL;
-
id_screen->base.destroy = identity_screen_destroy;
id_screen->base.get_name = identity_screen_get_name;
id_screen->base.get_vendor = identity_screen_get_vendor;
diff --git a/src/gallium/drivers/llvmpipe/lp_context.c 
b/src/gallium/drivers/llvmpipe/lp_context.c
index c19272f..8c0206b 100644
--- a/src/gallium/drivers/llvmpipe/lp_context.c
+++ b/src/gallium/drivers/llvmpipe/lp_context.c
@@ -171,7 +171,6 @@ llvmpipe_create_context( struct pipe_screen *screen, void 
*priv )
make_empty_list(&llvmpipe->setup_variants_list);
 
 
-   llvmpipe->pipe.winsys = screen->winsys;
llvmpipe->pipe.screen = screen;
llvmpipe->pipe.priv = priv;
 
diff --git a/src/gallium/drivers/noop/noop_pipe.c 
b/src/gallium/drivers/noop/noop_pipe.c
index ec20e0d..5453def 100644
--- a/src/gallium/drivers/noop/noop_pipe.c
+++ b/src/gallium/drivers

[Mesa-dev] [PATCH 2/3] gallium/util: remove u_simple_screen

2012-02-16 Thread Marek Olšák
Deprecated and unused.
---
 src/gallium/auxiliary/util/u_simple_screen.h |  180 --
 src/gallium/drivers/nouveau/nouveau_screen.c |1 -
 src/gallium/drivers/nvfx/nvfx_screen.c   |1 -
 3 files changed, 0 insertions(+), 182 deletions(-)
 delete mode 100644 src/gallium/auxiliary/util/u_simple_screen.h

diff --git a/src/gallium/auxiliary/util/u_simple_screen.h 
b/src/gallium/auxiliary/util/u_simple_screen.h
deleted file mode 100644
index 7caeb75..000
--- a/src/gallium/auxiliary/util/u_simple_screen.h
+++ /dev/null
@@ -1,180 +0,0 @@
-/**
- *
- * Copyright 2009 VMware, Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
- * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
- * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
- * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
- * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
- * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- **/
-
-#ifndef U_SIMPLE_SCREEN_H
-#define U_SIMPLE_SCREEN_H
-
-#include "pipe/p_format.h"
-
-struct pipe_screen;
-struct pipe_fence_handle;
-struct pipe_surface;
-struct pipe_resource;
-
-/**
- * Gallium3D drivers are (meant to be!) independent of both GL and the
- * window system.  The window system provides a buffer manager and a
- * set of additional hooks for things like command buffer submission,
- * etc.
- *
- * There clearly has to be some agreement between the window system
- * driver and the hardware driver about the format of command buffers,
- * etc.
- */
-struct pipe_winsys
-{
-   void (*destroy)( struct pipe_winsys *ws );
-
-   /** Returns name of this winsys interface */
-   const char *(*get_name)( struct pipe_winsys *ws );
-
-   /**
-* Do any special operations to ensure frontbuffer contents are
-* displayed, eg copy fake frontbuffer.
-*/
-   void (*flush_frontbuffer)( struct pipe_winsys *ws,
-  struct pipe_resource *resource,
-  unsigned level, unsigned layer,
-  void *context_private );
-
-
-   /**
-* Buffer management. Buffer attributes are mostly fixed over its lifetime.
-*
-* Remember that gallium gets to choose the interface it needs, and the
-* window systems must then implement that interface (rather than the
-* other way around...).
-*
-* usage is a bitmask of PIPE_BIND_*.
-* All possible usages must be present.
-*
-* alignment indicates the client's alignment requirements, eg for
-* SSE instructions.
-*/
-   struct pipe_resource *(*buffer_create)( struct pipe_winsys *ws,
- unsigned alignment,
- unsigned usage,
- unsigned size );
-
-   /**
-* Create a buffer that wraps user-space data.
-*
-* Effectively this schedules a delayed call to buffer_create
-* followed by an upload of the data at *some point in the future*,
-* or perhaps never.  Basically the allocate/upload is delayed
-* until the buffer is actually passed to hardware.
-*
-* The intention is to provide a quick way to turn regular data
-* into a buffer, and secondly to avoid a copy operation if that
-* data subsequently turns out to be only accessed by the CPU.
-*
-* Common example is OpenGL vertex buffers that are subsequently
-* processed either by software TNL in the driver or by passing to
-* hardware.
-*
-* XXX: What happens if the delayed call to buffer_create() fails?
-*
-* Note that ptr may be accessed at any time upto the time when the
-* buffer is destroyed, so the data must not be freed before then.
-*/
-   struct pipe_resource *(*user_buffer_create)(struct pipe_winsys *ws,
-void *ptr,
-unsigned bytes);
-
-   /**
-* Allocate storage for a display target surface.
-*
-* Of

[Mesa-dev] [PATCH 3/3] gallium/cso: kill off non-functional shader caching

2012-02-16 Thread Marek Olšák
Suggested by José.
---
 src/gallium/auxiliary/cso_cache/cso_cache.c   |   24 -
 src/gallium/auxiliary/cso_cache/cso_cache.h   |   16 
 src/gallium/auxiliary/cso_cache/cso_context.c |  118 -
 src/gallium/auxiliary/cso_cache/cso_context.h |   13 ---
 4 files changed, 0 insertions(+), 171 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_cache.c 
b/src/gallium/auxiliary/cso_cache/cso_cache.c
index c606992..e276fd1 100644
--- a/src/gallium/auxiliary/cso_cache/cso_cache.c
+++ b/src/gallium/auxiliary/cso_cache/cso_cache.c
@@ -119,22 +119,6 @@ static void delete_rasterizer_state(void *state, void 
*data)
FREE(state);
 }
 
-static void delete_fs_state(void *state, void *data)
-{
-   struct cso_fragment_shader *cso = (struct cso_fragment_shader *)state;
-   if (cso->delete_state)
-  cso->delete_state(cso->context, cso->data);
-   FREE(state);
-}
-
-static void delete_vs_state(void *state, void *data)
-{
-   struct cso_vertex_shader *cso = (struct cso_vertex_shader *)state;
-   if (cso->delete_state)
-  cso->delete_state(cso->context, cso->data);
-   FREE(state);
-}
-
 static void delete_velements(void *state, void *data)
 {
struct cso_velements *cso = (struct cso_velements *)state;
@@ -158,12 +142,6 @@ static INLINE void delete_cso(void *state, enum 
cso_cache_type type)
case CSO_RASTERIZER:
   delete_rasterizer_state(state, 0);
   break;
-   case CSO_FRAGMENT_SHADER:
-  delete_fs_state(state, 0);
-  break;
-   case CSO_VERTEX_SHADER:
-  delete_vs_state(state, 0);
-  break;
case CSO_VELEMENTS:
   delete_velements(state, 0);
   break;
@@ -309,8 +287,6 @@ void cso_cache_delete(struct cso_cache *sc)
/* delete driver data */
cso_for_each_state(sc, CSO_BLEND, delete_blend_state, 0);
cso_for_each_state(sc, CSO_DEPTH_STENCIL_ALPHA, delete_depth_stencil_state, 
0);
-   cso_for_each_state(sc, CSO_FRAGMENT_SHADER, delete_fs_state, 0);
-   cso_for_each_state(sc, CSO_VERTEX_SHADER, delete_vs_state, 0);
cso_for_each_state(sc, CSO_RASTERIZER, delete_rasterizer_state, 0);
cso_for_each_state(sc, CSO_SAMPLER, delete_sampler_state, 0);
cso_for_each_state(sc, CSO_VELEMENTS, delete_velements, 0);
diff --git a/src/gallium/auxiliary/cso_cache/cso_cache.h 
b/src/gallium/auxiliary/cso_cache/cso_cache.h
index 1b17423..cc1f1c0 100644
--- a/src/gallium/auxiliary/cso_cache/cso_cache.h
+++ b/src/gallium/auxiliary/cso_cache/cso_cache.h
@@ -89,8 +89,6 @@ enum cso_cache_type {
CSO_RASTERIZER,
CSO_BLEND,
CSO_DEPTH_STENCIL_ALPHA,
-   CSO_FRAGMENT_SHADER,
-   CSO_VERTEX_SHADER,
CSO_SAMPLER,
CSO_VELEMENTS,
CSO_CACHE_MAX,
@@ -126,20 +124,6 @@ struct cso_rasterizer {
struct pipe_context *context;
 };
 
-struct cso_fragment_shader {
-   struct pipe_shader_state state;
-   void *data;
-   cso_state_callback delete_state;
-   struct pipe_context *context;
-};
-
-struct cso_vertex_shader {
-   struct pipe_shader_state state;
-   void *data;
-   cso_state_callback delete_state;
-   struct pipe_context *context;
-};
-
 struct cso_sampler {
struct pipe_sampler_state state;
void *data;
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index c95a1ba..60a6e02 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -165,28 +165,6 @@ static boolean delete_rasterizer_state(struct cso_context 
*ctx, void *state)
return TRUE;
 }
 
-static boolean delete_fs_state(struct cso_context *ctx, void *state)
-{
-   struct cso_fragment_shader *cso = (struct cso_fragment_shader *)state;
-   if (ctx->fragment_shader == cso->data)
-  return FALSE;
-   if (cso->delete_state)
-  cso->delete_state(cso->context, cso->data);
-   FREE(state);
-   return TRUE;
-}
-
-static boolean delete_vs_state(struct cso_context *ctx, void *state)
-{
-   struct cso_vertex_shader *cso = (struct cso_vertex_shader *)state;
-   if (ctx->vertex_shader == cso->data)
-  return TRUE;
-   if (cso->delete_state)
-  cso->delete_state(cso->context, cso->data);
-   FREE(state);
-   return FALSE;
-}
-
 static boolean delete_vertex_elements(struct cso_context *ctx,
   void *state)
 {
@@ -218,12 +196,6 @@ static INLINE boolean delete_cso(struct cso_context *ctx,
case CSO_RASTERIZER:
   return delete_rasterizer_state(ctx, state);
   break;
-   case CSO_FRAGMENT_SHADER:
-  return delete_fs_state(ctx, state);
-  break;
-   case CSO_VERTEX_SHADER:
-  return delete_vs_state(ctx, state);
-  break;
case CSO_VELEMENTS:
   return delete_vertex_elements(ctx, state);
   break;
@@ -571,52 +543,6 @@ void cso_delete_fragment_shader(struct cso_context *ctx, 
void *handle )
ctx->pipe->delete_fs_state(ctx->pipe, handle);
 }
 
-/* Not really working:
- */
-#if 0
-enum pipe_error cso_set_fragment_shader(struct cso_context *ctx,
-

Re: [Mesa-dev] [PATCH] mesa: fix an issue with texture border and array textures

2012-02-16 Thread Brian Paul

On 02/16/2012 05:11 PM, Anuj Phogat wrote:

As suggested by Brian, for a 1D texture array, the border only applies to the
width.  For a 2D texture array the border applies to the width and height but
not the depth.  This was not handled correctly _mesa_init_teximage_fields().

Note: This is a candidate for stable branches

Signed-off-by: Anuj Phogat
---
Sorry for not considering all the cases in my previous patch. Let me know
if i have still missed anything.

  src/mesa/main/teximage.c |   56 +
  1 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index e4eb7f6..a1d5d26 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1083,11 +1083,13 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
 GLint border, GLenum internalFormat,
 gl_format format)
  {
+   GLenum target;
 ASSERT(img);
 ASSERT(width>= 0);
 ASSERT(height>= 0);
 ASSERT(depth>= 0);

+   target = img->TexObject->Target;
 img->_BaseFormat = _mesa_base_tex_format( ctx, internalFormat );
 ASSERT(img->_BaseFormat>  0);
 img->InternalFormat = internalFormat;
@@ -1099,26 +1101,60 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
 img->Width2 = width - 2 * border;   /* == 1<<  img->WidthLog2; */
 img->WidthLog2 = _mesa_logbase2(img->Width2);

-   if (height == 1) { /* 1-D texture */
+   switch(target) {
+   case GL_TEXTURE_1D:
+   case GL_TEXTURE_BUFFER:
+   case GL_PROXY_TEXTURE_1D:
img->Height2 = 1;
img->HeightLog2 = 0;
-   }
-   else {
+  img->Depth2 = 1;
+  img->DepthLog2 = 0;


If the incoming 'height' or 'depth' is zero, then Height2 or Depth2 
should be zero also (not 1).  This probably wouldn't make any 
difference in the end, but it's more consistent.


Otherwise this is looking good.

The original code managed to get this right in a non-obvious way.



+  break;
+   case GL_TEXTURE_1D_ARRAY:
+   case GL_PROXY_TEXTURE_1D_ARRAY:
+  img->Height2 = height; /* no border */
+  img->HeightLog2 = 0; /* not used */
+  img->Depth2 = 1;


Same as above.



+  img->DepthLog2 = 0;
+  break;
+   case GL_TEXTURE_2D:
+   case GL_TEXTURE_RECTANGLE:
+   case GL_TEXTURE_CUBE_MAP:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_X:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_X:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_Y:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_Z:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z:
+   case GL_TEXTURE_EXTERNAL_OES:
+   case GL_PROXY_TEXTURE_2D:
+   case GL_PROXY_TEXTURE_RECTANGLE:
+   case GL_PROXY_TEXTURE_CUBE_MAP:
img->Height2 = height - 2 * border; /* == 1<<  img->HeightLog2; */
img->HeightLog2 = _mesa_logbase2(img->Height2);
-   }
-
-   if (depth == 1) {  /* 2-D texture */
img->Depth2 = 1;
img->DepthLog2 = 0;
-   }
-   else {
+  break;
+   case GL_TEXTURE_2D_ARRAY:
+   case GL_PROXY_TEXTURE_2D_ARRAY:
+  img->Height2 = height - 2 * border; /* == 1<<  img->HeightLog2; */
+  img->HeightLog2 = _mesa_logbase2(img->Height2);
+  img->Depth2 = depth; /* no border */
+  img->DepthLog2 = 0; /* not used */
+  break;
+   case GL_TEXTURE_3D:
+   case GL_PROXY_TEXTURE_3D:
+  img->Height2 = height - 2 * border; /* == 1<<  img->HeightLog2; */
+  img->HeightLog2 = _mesa_logbase2(img->Height2);
img->Depth2 = depth - 2 * border;   /* == 1<<  img->DepthLog2; */
img->DepthLog2 = _mesa_logbase2(img->Depth2);
+  break;
+   default:
+  _mesa_problem(NULL, "invalid target 0x%x in 
_mesa_init_teximage_fields()",
+target);
 }
-
+
 img->MaxLog2 = MAX2(img->WidthLog2, img->HeightLog2);
-
 img->TexFormat = format;
  }



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


Re: [Mesa-dev] [PATCH] mesa: fix an issue with texture border and array textures

2012-02-16 Thread Brian Paul

On 02/16/2012 06:04 PM, Ian Romanick wrote:

On 02/16/2012 04:11 PM, Anuj Phogat wrote:

As suggested by Brian, for a 1D texture array, the border only
applies to the
width. For a 2D texture array the border applies to the width and
height but
not the depth. This was not handled correctly
_mesa_init_teximage_fields().

Note: This is a candidate for stable branches

Signed-off-by: Anuj Phogat
---
Sorry for not considering all the cases in my previous patch. Let me
know
if i have still missed anything.


It looks like everything is here, but I think we need some piglit
tests. I would at least like to see a couple tests that would have
failed with one or more of the previous patches. I think the right
thing is to try create a texture with (and without) border for each
possible target. Then query the dimensions and border size and test
against the expected values.

Brian, does that sound like it would catch the issues you raised in
the previous versions of the patch?


A piglit test like you describe would be great.  Though, I have a 
feeling that there's more issues related to texture arrays and borders 
than just _mesa_init_teximage_fields().


As long as there's no regressions though, this would be good step forward.

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


Re: [Mesa-dev] [PATCH] i915: Set swrast_texture_image::Buffer and ::Map during swrast mapping

2012-02-16 Thread Brian Paul

On 02/16/2012 04:48 PM, Eric Anholt wrote:

On Tue, 14 Feb 2012 10:57:17 -0800, "Ian Romanick"  wrote:

From: Ian Romanick

Before calling _tnl_run_pipeline, the i915 driver maps all textures
used in vertex shaders (via intel_tex_map_images).  Later run_vp tries
to map the textures again (via _swrast_map_texture).  However, this
just replaces the actual mappings with NULL pointers.  When the
pointers are dereferened, a segfault occurs.

Setting swrast_texture_image::Buffer in intel_tex_map_images works
around the problem, but I have a hard time believing this is the right
fix.


Seems to me like the swrast map-things-for-texturing should be using
MapTextureImage.  Then we wouldn't need the intel
pre-_tnl_run_pipeline() mapping.


I may have been too hasty with commit 
4bbab2275f792553f8ed6bcebfe6acc4cb4179c2 which removed some tex image 
mapping code from tnl.


The tnl module should probably call ctx->Driver.MapTextureImage() for 
the vertex textures that it needs, like Eric says.


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


[Mesa-dev] [Bug 46204] New: Missing support of pointcoord and point size in Mesa core

2012-02-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=46204

 Bug #: 46204
   Summary: Missing support of pointcoord and point size in Mesa
core
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: jian.j.z...@intel.com


System Environment:
--
Mesa:(master)26de5273acf1ebe6730b5e72b55b3bcceba167c6

Bug detailed description:
-
When run some shaders involving pointcoord and point size, it fails with 
software rendering on all platforms(Pinetrail, Piketon, HuronRiver). 

Reproduce steps:
-
1. xinit
2. LIBGL_ALWAYS_SOFTWARE=1 ./fbo-gl_pointcoord

-- 
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 46204] Missing support of pointcoord and point size in Mesa core

2012-02-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=46204

zhao jian  changed:

   What|Removed |Added

 AssignedTo|mesa-dev@lists.freedesktop. |yuanhan@intel.com
   |org |

-- 
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] [PATCH] mesa: fix an issue with texture border and array textures

2012-02-16 Thread Anuj Phogat
As suggested by Brian, for a 1D texture array, the border only applies to the
width.  For a 2D texture array the border applies to the width and height but
not the depth.  This was not handled correctly _mesa_init_teximage_fields().

Note: This is a candidate for stable branches

Signed-off-by: Anuj Phogat 
---
Added the case when incoming height, depth is zero. I will develop a piglit
test case as suggested.

 src/mesa/main/teximage.c |   70 ++---
 1 files changed, 59 insertions(+), 11 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 6acff24..9b6c6c8 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1083,11 +1083,13 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
GLint border, GLenum internalFormat,
gl_format format)
 {
+   GLenum target;
ASSERT(img);
ASSERT(width >= 0);
ASSERT(height >= 0);
ASSERT(depth >= 0);
 
+   target = img->TexObject->Target;
img->_BaseFormat = _mesa_base_tex_format( ctx, internalFormat );
ASSERT(img->_BaseFormat > 0);
img->InternalFormat = internalFormat;
@@ -1099,26 +1101,72 @@ _mesa_init_teximage_fields(struct gl_context *ctx,
img->Width2 = width - 2 * border;   /* == 1 << img->WidthLog2; */
img->WidthLog2 = _mesa_logbase2(img->Width2);
 
-   if (height == 1) { /* 1-D texture */
-  img->Height2 = 1;
+   switch(target) {
+   case GL_TEXTURE_1D:
+   case GL_TEXTURE_BUFFER:
+   case GL_PROXY_TEXTURE_1D:
+  if (height == 0)
+ img->Height2 = 0;
+  else
+ img->Height2 = 1;
   img->HeightLog2 = 0;
-   }
-   else {
+  if (depth == 0)
+ img->Depth2 = 0;
+  else
+ img->Depth2 = 1;
+  img->DepthLog2 = 0;
+  break;
+   case GL_TEXTURE_1D_ARRAY:
+   case GL_PROXY_TEXTURE_1D_ARRAY:
+  img->Height2 = height; /* no border */
+  img->HeightLog2 = 0; /* not used */
+  if (depth == 0)
+ img->Depth2 = 0;
+  else
+ img->Depth2 = 1;
+  img->DepthLog2 = 0;
+  break;
+   case GL_TEXTURE_2D:
+   case GL_TEXTURE_RECTANGLE:
+   case GL_TEXTURE_CUBE_MAP:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_X:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_X:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_Y:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_Z:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z:
+   case GL_TEXTURE_EXTERNAL_OES:
+   case GL_PROXY_TEXTURE_2D:
+   case GL_PROXY_TEXTURE_RECTANGLE:
+   case GL_PROXY_TEXTURE_CUBE_MAP:
   img->Height2 = height - 2 * border; /* == 1 << img->HeightLog2; */
   img->HeightLog2 = _mesa_logbase2(img->Height2);
-   }
-
-   if (depth == 1) {  /* 2-D texture */
-  img->Depth2 = 1;
+  if (depth == 0)
+ img->Depth2 = 0;
+  else
+ img->Depth2 = 1;
   img->DepthLog2 = 0;
-   }
-   else {
+  break;
+   case GL_TEXTURE_2D_ARRAY:
+   case GL_PROXY_TEXTURE_2D_ARRAY:
+  img->Height2 = height - 2 * border; /* == 1 << img->HeightLog2; */
+  img->HeightLog2 = _mesa_logbase2(img->Height2);
+  img->Depth2 = depth; /* no border */
+  img->DepthLog2 = 0; /* not used */
+  break;
+   case GL_TEXTURE_3D:
+   case GL_PROXY_TEXTURE_3D:
+  img->Height2 = height - 2 * border; /* == 1 << img->HeightLog2; */
+  img->HeightLog2 = _mesa_logbase2(img->Height2);
   img->Depth2 = depth - 2 * border;   /* == 1 << img->DepthLog2; */
   img->DepthLog2 = _mesa_logbase2(img->Depth2);
+  break;
+   default:
+  _mesa_problem(NULL, "invalid target 0x%x in 
_mesa_init_teximage_fields()",
+target);
}
 
img->MaxLog2 = MAX2(img->WidthLog2, img->HeightLog2);
-
img->TexFormat = format;
 }
 
-- 
1.7.7.6

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


[Mesa-dev] [Bug 45277] [bisected] Shading not working properly in Heroes of Newerth

2012-02-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=45277

--- Comment #3 from Chris  2012-02-16 20:14:30 PST ---
I can confirm this too.
I also noticed around the same time (I assume the same commit) that Mass Effect 
2 has serious rendering issues with some textures through wine.

-- 
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] [PATCH] i915: Initialize swrast_texture_image structure fields.

2012-02-16 Thread Paul Berry
Commit 980f6f1 (mesa: move gl_texture_image::Width/Height/DepthScale
fields to swrast) moved the initialization of the Width, Height, and
DepthScale fields to _swrast_alloc_texture_image_buffer().  However,
i915 doesn't call this function because it performs its own buffer
allocation.  As a result, the Width, Height, and DepthScale fields
weren't getting initialized properly, and some operations requiring
swrast would fail.

This patch ensures that Width, Height, and DepthScale are properly
initialized by separating the code that sets them into a new function,
_swrast_init_texture_image(), which is called by
intel_alloc_texture_image_buffer() as well as
_swrast_alloc_texture_image_buffer().  It also moves the
initialization of _IsPowerOfTwo into this function.

Fixes piglit test fbo/fbo-cubemap on i915.

Partially fixes https://bugs.freedesktop.org/show_bug.cgi?id=41216
---
 src/mesa/drivers/dri/intel/intel_tex.c |2 ++
 src/mesa/swrast/s_texture.c|   21 +++--
 src/mesa/swrast/swrast.h   |4 
 3 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_tex.c 
b/src/mesa/drivers/dri/intel/intel_tex.c
index 2ebd654..b3ac226 100644
--- a/src/mesa/drivers/dri/intel/intel_tex.c
+++ b/src/mesa/drivers/dri/intel/intel_tex.c
@@ -84,6 +84,8 @@ intel_alloc_texture_image_buffer(struct gl_context *ctx,
assert(!intel_image->base.ImageOffsets);
intel_image->base.ImageOffsets = malloc(slices * sizeof(GLuint));
 
+   _swrast_init_texture_image(image, width, height, depth);
+
if (intel_texobj->mt &&
intel_miptree_match_image(intel_texobj->mt, image)) {
   intel_miptree_reference(&intel_image->mt, intel_texobj->mt);
diff --git a/src/mesa/swrast/s_texture.c b/src/mesa/swrast/s_texture.c
index 72d3093..9718367 100644
--- a/src/mesa/swrast/s_texture.c
+++ b/src/mesa/swrast/s_texture.c
@@ -96,6 +96,25 @@ _swrast_alloc_texture_image_buffer(struct gl_context *ctx,
   swImg->ImageOffsets[i] = i * width * height;
}
 
+   _swrast_init_texture_image(texImage, width, height, depth);
+
+   return GL_TRUE;
+}
+
+
+/**
+ * Code that overrides ctx->Driver.AllocTextureImageBuffer may use this to
+ * initialize the fields of swrast_texture_image without allocating the image
+ * buffer or initializing ImageOffsets or RowStride.
+ *
+ * Returns GL_TRUE on success, GL_FALSE on memory allocation failure.
+ */
+void
+_swrast_init_texture_image(struct gl_texture_image *texImage, GLsizei width,
+   GLsizei height, GLsizei depth)
+{
+   struct swrast_texture_image *swImg = swrast_texture_image(texImage);
+
if ((width == 1 || _mesa_is_pow_two(texImage->Width2)) &&
(height == 1 || _mesa_is_pow_two(texImage->Height2)) &&
(depth == 1 || _mesa_is_pow_two(texImage->Depth2)))
@@ -115,8 +134,6 @@ _swrast_alloc_texture_image_buffer(struct gl_context *ctx,
   swImg->HeightScale = (GLfloat) texImage->Height;
   swImg->DepthScale = (GLfloat) texImage->Depth;
}
-
-   return GL_TRUE;
 }
 
 
diff --git a/src/mesa/swrast/swrast.h b/src/mesa/swrast/swrast.h
index 468d22f..ad19eee 100644
--- a/src/mesa/swrast/swrast.h
+++ b/src/mesa/swrast/swrast.h
@@ -192,6 +192,10 @@ _swrast_alloc_texture_image_buffer(struct gl_context *ctx,
GLsizei height, GLsizei depth);
 
 extern void
+_swrast_init_texture_image(struct gl_texture_image *texImage, GLsizei width,
+   GLsizei height, GLsizei depth);
+
+extern void
 _swrast_free_texture_image_buffer(struct gl_context *ctx,
   struct gl_texture_image *texImage);
 
-- 
1.7.7.6

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


[Mesa-dev] Mesa 8.0.1 release

2012-02-16 Thread Ian Romanick
Mesa 8.0.1 has been released.  Mesa 8.0.1 is a bug fix release which 
fixes bugs found since the 8.0 release.


The tag in the GIT repository for Mesa 8.0.1 is 'mesa-8.0.1'.

Mesa 8.0.1 is available for download at
ftp://freedesktop.org/pub/mesa/8.0.1/

md5sums:

4855c2d93bd2ebd43f384bdcc92c9a27  MesaLib-8.0.1.tar.gz
24eeebf66971809d8f40775a379b36c9  MesaLib-8.0.1.tar.bz2
54e745d14dac5717f7f65b4e2d5c1df2  MesaLib-8.0.1.zip

I have verified building from the .tar.bz2 file by doing:

tar -xjf MesaLib-8.0.1.tar.bz2
cd Mesa-8.0.1
./configure --enable-dri --with-dri-drivers=yes \
--enable-gles1 --enable-gles2 --enable-glx-tls \
--disable-glu --with-gallium-drivers \
--enable-gallium-llvm
make -j6

I have also verified that I pushed all the cherry picks and the tag.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i915: Initialize swrast_texture_image structure fields.

2012-02-16 Thread Ian Romanick

On 02/16/2012 10:57 PM, Paul Berry wrote:

Commit 980f6f1 (mesa: move gl_texture_image::Width/Height/DepthScale
fields to swrast) moved the initialization of the Width, Height, and
DepthScale fields to _swrast_alloc_texture_image_buffer().  However,
i915 doesn't call this function because it performs its own buffer
allocation.  As a result, the Width, Height, and DepthScale fields
weren't getting initialized properly, and some operations requiring
swrast would fail.

This patch ensures that Width, Height, and DepthScale are properly
initialized by separating the code that sets them into a new function,
_swrast_init_texture_image(), which is called by
intel_alloc_texture_image_buffer() as well as
_swrast_alloc_texture_image_buffer().  It also moves the
initialization of _IsPowerOfTwo into this function.

Fixes piglit test fbo/fbo-cubemap on i915.


Reviewed-and-tested-by: Ian Romanick 

This should also be marked as a candidate for the 8.0 branch.


Partially fixes https://bugs.freedesktop.org/show_bug.cgi?id=41216
---
  src/mesa/drivers/dri/intel/intel_tex.c |2 ++
  src/mesa/swrast/s_texture.c|   21 +++--
  src/mesa/swrast/swrast.h   |4 
  3 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_tex.c 
b/src/mesa/drivers/dri/intel/intel_tex.c
index 2ebd654..b3ac226 100644
--- a/src/mesa/drivers/dri/intel/intel_tex.c
+++ b/src/mesa/drivers/dri/intel/intel_tex.c
@@ -84,6 +84,8 @@ intel_alloc_texture_image_buffer(struct gl_context *ctx,
 assert(!intel_image->base.ImageOffsets);
 intel_image->base.ImageOffsets = malloc(slices * sizeof(GLuint));

+   _swrast_init_texture_image(image, width, height, depth);
+
 if (intel_texobj->mt&&
 intel_miptree_match_image(intel_texobj->mt, image)) {
intel_miptree_reference(&intel_image->mt, intel_texobj->mt);
diff --git a/src/mesa/swrast/s_texture.c b/src/mesa/swrast/s_texture.c
index 72d3093..9718367 100644
--- a/src/mesa/swrast/s_texture.c
+++ b/src/mesa/swrast/s_texture.c
@@ -96,6 +96,25 @@ _swrast_alloc_texture_image_buffer(struct gl_context *ctx,
swImg->ImageOffsets[i] = i * width * height;
 }

+   _swrast_init_texture_image(texImage, width, height, depth);
+
+   return GL_TRUE;
+}
+
+
+/**
+ * Code that overrides ctx->Driver.AllocTextureImageBuffer may use this to
+ * initialize the fields of swrast_texture_image without allocating the image
+ * buffer or initializing ImageOffsets or RowStride.
+ *
+ * Returns GL_TRUE on success, GL_FALSE on memory allocation failure.
+ */
+void
+_swrast_init_texture_image(struct gl_texture_image *texImage, GLsizei width,
+   GLsizei height, GLsizei depth)
+{
+   struct swrast_texture_image *swImg = swrast_texture_image(texImage);
+
 if ((width == 1 || _mesa_is_pow_two(texImage->Width2))&&
 (height == 1 || _mesa_is_pow_two(texImage->Height2))&&
 (depth == 1 || _mesa_is_pow_two(texImage->Depth2)))
@@ -115,8 +134,6 @@ _swrast_alloc_texture_image_buffer(struct gl_context *ctx,
swImg->HeightScale = (GLfloat) texImage->Height;
swImg->DepthScale = (GLfloat) texImage->Depth;
 }
-
-   return GL_TRUE;
  }


diff --git a/src/mesa/swrast/swrast.h b/src/mesa/swrast/swrast.h
index 468d22f..ad19eee 100644
--- a/src/mesa/swrast/swrast.h
+++ b/src/mesa/swrast/swrast.h
@@ -192,6 +192,10 @@ _swrast_alloc_texture_image_buffer(struct gl_context *ctx,
 GLsizei height, GLsizei depth);

  extern void
+_swrast_init_texture_image(struct gl_texture_image *texImage, GLsizei width,
+   GLsizei height, GLsizei depth);
+
+extern void
  _swrast_free_texture_image_buffer(struct gl_context *ctx,
struct gl_texture_image *texImage);



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


[Mesa-dev] [PATCH] intel: Refine the swapbuffers throttling by emitting a small no-op batch.

2012-02-16 Thread Eric Anholt
Improves citybench performance by 39.8638% +/- 2.26632% (n=10) (at
default resolution and about the same for 320x240).
---
 src/mesa/drivers/dri/intel/intel_batchbuffer.c |5 -
 src/mesa/drivers/dri/intel/intel_context.c |   21 +
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c 
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index d10e008..5631c19 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -211,11 +211,6 @@ _intel_batchbuffer_flush(struct intel_context *intel,
if (intel->batch.used == 0)
   return 0;
 
-   if (intel->first_post_swapbuffers_batch == NULL) {
-  intel->first_post_swapbuffers_batch = intel->batch.bo;
-  drm_intel_bo_reference(intel->first_post_swapbuffers_batch);
-   }
-
if (unlikely(INTEL_DEBUG & DEBUG_BATCH))
   fprintf(stderr, "%s:%d: Batchbuffer flush with %db used\n", file, line,
  4*intel->batch.used);
diff --git a/src/mesa/drivers/dri/intel/intel_context.c 
b/src/mesa/drivers/dri/intel/intel_context.c
index 377bcbc..3d3feb6 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -419,18 +419,31 @@ intel_prepare_render(struct intel_context *intel)
 * We're using intelDRI2Flush (called from the loader before
 * swapbuffer) and glFlush (for front buffer rendering) as the
 * indicator that a frame is done and then throttle when we get
-* here as we prepare to render the next frame.  At this point for
+* here as we prepare to render the next frame.  At this point our
 * round trips for swap/copy and getting new buffers are done and
-* we'll spend less time waiting on the GPU.
+* we'll spend less time waiting on the GPU when we throttle here.
 *
 * Unfortunately, we don't have a handle to the batch containing
 * the swap, and getting our hands on that doesn't seem worth it,
-* so we just us the first batch we emitted after the last swap.
+* so we just use the first batch we emitted after the last swap.
+* To bring the point we wait on closer to the swapbuffers, we make
+* a tiny batchbuffer containing just a noop and flush it out.  The
+* overhead of it is worth the savings on apps that only emit one or
+* a few batchbuffers per frame.
 */
if (intel->need_throttle && intel->first_post_swapbuffers_batch) {
   drm_intel_bo_wait_rendering(intel->first_post_swapbuffers_batch);
   drm_intel_bo_unreference(intel->first_post_swapbuffers_batch);
-  intel->first_post_swapbuffers_batch = NULL;
+
+  BEGIN_BATCH(1);
+  OUT_BATCH(MI_NOOP);
+  ADVANCE_BATCH();
+
+  intel->first_post_swapbuffers_batch = intel->batch.bo;
+  drm_intel_bo_reference(intel->batch.bo);
+
+  intel_batchbuffer_flush(intel);
+
   intel->need_throttle = false;
}
 }
-- 
1.7.9

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