[Mesa-dev] [PATCH 3/3] intel: Merge identical cases in switch statement.

[Nick Bowler]

Signed-off-by: Nick Bowler 
---
 src/mesa/drivers/dri/intel/intel_fbo.c |   16 +---
 1 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c 
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 4a83886..2fdb6e4 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -137,27 +137,21 @@ intel_alloc_renderbuffer_storage(GLcontext * ctx, struct 
gl_renderbuffer *rb,
   rb->Format = MESA_FORMAT_A8;
   rb->DataType = GL_UNSIGNED_BYTE;
   break;
+   case GL_DEPTH_COMPONENT16:
+  rb->Format = MESA_FORMAT_Z16;
+  rb->DataType = GL_UNSIGNED_SHORT;
+  break;
case GL_STENCIL_INDEX:
case GL_STENCIL_INDEX1_EXT:
case GL_STENCIL_INDEX4_EXT:
case GL_STENCIL_INDEX8_EXT:
case GL_STENCIL_INDEX16_EXT:
-  /* alloc a depth+stencil buffer */
-  rb->Format = MESA_FORMAT_S8_Z24;
-  rb->DataType = GL_UNSIGNED_INT_24_8_EXT;
-  break;
-   case GL_DEPTH_COMPONENT16:
-  rb->Format = MESA_FORMAT_Z16;
-  rb->DataType = GL_UNSIGNED_SHORT;
-  break;
case GL_DEPTH_COMPONENT:
case GL_DEPTH_COMPONENT24:
case GL_DEPTH_COMPONENT32:
-  rb->Format = MESA_FORMAT_S8_Z24;
-  rb->DataType = GL_UNSIGNED_INT_24_8_EXT;
-  break;
case GL_DEPTH_STENCIL_EXT:
case GL_DEPTH24_STENCIL8_EXT:
+  /* alloc a depth+stencil buffer */
   rb->Format = MESA_FORMAT_S8_Z24;
   rb->DataType = GL_UNSIGNED_INT_24_8_EXT;
   break;
-- 
1.7.1

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

[Mesa-dev] [PATCH 2/3] mesa: Use the _BaseFormat field to determine attachment completeness.

[Nick Bowler]

Intel sometimes uses packed depth/stencil buffers even when only a
depth buffer or only a stencil buffer was requested.  GL specifies
that GL_DEPTH_COMPONENT renderbuffers are *not* stencil-attachable,
but the current check happily attaches these buffers to the stencil
attachment point (or vice-versa for GL_STENCIL_INDEX renderbuffers
and the depth attachment).  Performing such an attachment must yield
an incomplete framebuffer.

Since the renderbuffer struct has the actual base format stored in it,
use that value instead of recomputing it incorrectly.

Signed-off-by: Nick Bowler 
---
 src/mesa/main/fbobject.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 9a84e5a..80bc518 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -485,8 +485,7 @@ test_attachment_completeness(const GLcontext *ctx, GLenum 
format,
   }
}
else if (att->Type == GL_RENDERBUFFER_EXT) {
-  const GLenum baseFormat =
- _mesa_get_format_base_format(att->Renderbuffer->Format);
+  const GLenum baseFormat = att->Renderbuffer->_BaseFormat;
 
   ASSERT(att->Renderbuffer);
   if (!att->Renderbuffer->InternalFormat ||
-- 
1.7.1

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

[Mesa-dev] [PATCH 1/3] mesa: Identify packed depth/stencil buffers using the Format field.

[Nick Bowler]

Intel sometimes uses packed depth/stencil buffers even when only a depth
buffer or only a stencil buffer was requested.  Common code currently
uses the _BaseFormat field to determine whether a depth/stencil wrapper
is necessary.  But unless the user explicitly requested a packed
depth/stencil buffer, the _BaseFormat field does not encode this
information, and the required wrappers are not created.

The problem was introduced by commit 45e76d2665b38b ("mesa: remove a
bunch of gl_renderbuffer fields"), which killed off the _ActualFormat
field upon which the decision to create a wrapper used to be made.  This
patch changes the logic to use the Format field instead, which is more
like the old code.

Fixes fdo bug 27590.

Signed-off-by: Nick Bowler 
---
 src/mesa/main/framebuffer.c |   18 --
 1 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index e0aac26..869401d 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -588,6 +588,20 @@ _mesa_update_framebuffer_visual(struct gl_framebuffer *fb)
compute_depth_max(fb);
 }
 
+/**
+ * Determine if a renderbuffer is a packed depth/stencil buffer.
+ */
+static int rb_is_depth_stencil(struct gl_renderbuffer *rb)
+{
+   if (rb->Format == MESA_FORMAT_Z24_S8
+   || rb->Format == MESA_FORMAT_Z24_X8
+   || rb->Format == MESA_FORMAT_S8_Z24
+   || rb->Format == MESA_FORMAT_X8_Z24)
+  return 1;
+
+   return 0;
+}
+
 
 /**
  * Update the framebuffer's _DepthBuffer field using the renderbuffer
@@ -611,7 +625,7 @@ _mesa_update_depth_buffer(GLcontext *ctx,
 
depthRb = fb->Attachment[attIndex].Renderbuffer;
 
-   if (depthRb && depthRb->_BaseFormat == GL_DEPTH_STENCIL) {
+   if (depthRb && rb_is_depth_stencil(depthRb)) {
   /* The attached depth buffer is a GL_DEPTH_STENCIL renderbuffer */
   if (!fb->_DepthBuffer
   || fb->_DepthBuffer->Wrapped != depthRb
@@ -652,7 +666,7 @@ _mesa_update_stencil_buffer(GLcontext *ctx,
 
stencilRb = fb->Attachment[attIndex].Renderbuffer;
 
-   if (stencilRb && stencilRb->_BaseFormat == GL_DEPTH_STENCIL) {
+   if (stencilRb && rb_is_depth_stencil(stencilRb)) {
   /* The attached stencil buffer is a GL_DEPTH_STENCIL renderbuffer */
   if (!fb->_StencilBuffer
   || fb->_StencilBuffer->Wrapped != stencilRb
-- 
1.7.1

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

[Mesa-dev] [PATCH 0/3] FBO fixes for intel.

[Nick Bowler]

The following series fixes a couple issues with FBOs on the intel
driver; fallout from the driver's decision to use packed depth/stencil
buffers when only one was requested by the user.  These patches are
completely independent.

I've also prepared some piglit tests for the issues, but I am not sure
whom I should send them to.

Nick Bowler (3):
  mesa: Identify packed depth/stencil buffers using the Format field.
  mesa: Use the _BaseFormat field to determine attachment completeness.
  intel: Merge identical cases in switch statement.

 src/mesa/drivers/dri/intel/intel_fbo.c |   16 +---
 src/mesa/main/fbobject.c   |3 +--
 src/mesa/main/framebuffer.c|   18 --
 3 files changed, 22 insertions(+), 15 deletions(-)

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

Re: [Mesa-dev] [PATCH 1/3] mesa: Identify packed depth/stencil buffers using the Format field.

[Brian Paul]

On 08/25/2010 07:14 AM, Nick Bowler wrote:

Intel sometimes uses packed depth/stencil buffers even when only a depth
buffer or only a stencil buffer was requested.  Common code currently
uses the _BaseFormat field to determine whether a depth/stencil wrapper
is necessary.  But unless the user explicitly requested a packed
depth/stencil buffer, the _BaseFormat field does not encode this
information, and the required wrappers are not created.

The problem was introduced by commit 45e76d2665b38b ("mesa: remove a
bunch of gl_renderbuffer fields"), which killed off the _ActualFormat
field upon which the decision to create a wrapper used to be made.  This
patch changes the logic to use the Format field instead, which is more
like the old code.

Fixes fdo bug 27590.

Signed-off-by: Nick Bowler
---
  src/mesa/main/framebuffer.c |   18 --
  1 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index e0aac26..869401d 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -588,6 +588,20 @@ _mesa_update_framebuffer_visual(struct gl_framebuffer *fb)
 compute_depth_max(fb);
  }

+/**
+ * Determine if a renderbuffer is a packed depth/stencil buffer.
+ */
+static int rb_is_depth_stencil(struct gl_renderbuffer *rb)
+{
+   if (rb->Format == MESA_FORMAT_Z24_S8
+   || rb->Format == MESA_FORMAT_Z24_X8
+   || rb->Format == MESA_FORMAT_S8_Z24
+   || rb->Format == MESA_FORMAT_X8_Z24)
+  return 1;
+
+   return 0;
+}
+


Let's rewrite this as a format helper function and put it in formats.c:

GLboolean
_mesa_is_format_packed_depth_stencil(gl_format format)


Then pass depthRb->Format to it.




  /**
   * Update the framebuffer's _DepthBuffer field using the renderbuffer
@@ -611,7 +625,7 @@ _mesa_update_depth_buffer(GLcontext *ctx,

 depthRb = fb->Attachment[attIndex].Renderbuffer;

-   if (depthRb&&  depthRb->_BaseFormat == GL_DEPTH_STENCIL) {
+   if (depthRb&&  rb_is_depth_stencil(depthRb)) {
/* The attached depth buffer is a GL_DEPTH_STENCIL renderbuffer */
if (!fb->_DepthBuffer
|| fb->_DepthBuffer->Wrapped != depthRb
@@ -652,7 +666,7 @@ _mesa_update_stencil_buffer(GLcontext *ctx,

 stencilRb = fb->Attachment[attIndex].Renderbuffer;

-   if (stencilRb&&  stencilRb->_BaseFormat == GL_DEPTH_STENCIL) {
+   if (stencilRb&&  rb_is_depth_stencil(stencilRb)) {
/* The attached stencil buffer is a GL_DEPTH_STENCIL renderbuffer */
if (!fb->_StencilBuffer
|| fb->_StencilBuffer->Wrapped != stencilRb



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

Re: [Mesa-dev] [PATCH 2/3] mesa: Use the _BaseFormat field to determine attachment completeness.

[Brian Paul]

On 08/25/2010 07:14 AM, Nick Bowler wrote:

Intel sometimes uses packed depth/stencil buffers even when only a
depth buffer or only a stencil buffer was requested.  GL specifies
that GL_DEPTH_COMPONENT renderbuffers are *not* stencil-attachable,
but the current check happily attaches these buffers to the stencil
attachment point (or vice-versa for GL_STENCIL_INDEX renderbuffers
and the depth attachment).  Performing such an attachment must yield
an incomplete framebuffer.

Since the renderbuffer struct has the actual base format stored in it,
use that value instead of recomputing it incorrectly.

Signed-off-by: Nick Bowler
---
  src/mesa/main/fbobject.c |3 +--
  1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 9a84e5a..80bc518 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -485,8 +485,7 @@ test_attachment_completeness(const GLcontext *ctx, GLenum 
format,
}
 }
 else if (att->Type == GL_RENDERBUFFER_EXT) {
-  const GLenum baseFormat =
- _mesa_get_format_base_format(att->Renderbuffer->Format);
+  const GLenum baseFormat = att->Renderbuffer->_BaseFormat;

ASSERT(att->Renderbuffer);
if (!att->Renderbuffer->InternalFormat ||



This looks good.  I'm not sure if there's a piglit test that would 
exercise this.  Did you run the piglit fbo tests just to be sure 
there's no regressions?


-Brian

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

Re: [Mesa-dev] mesa compile, talloc

[Jakob Bornecrantz]

On 26 aug 2010, at 15.10, Trevor Woerner wrote:

Hi,

I was trying to compile Xorg and had a bit of a stumble in the mesa  
directory.


The configure.ac looks for the talloc package and assumes your
distribution has supplied a "talloc.pc" to work with the pkg-config
system. Unfortunately mine doesn't so my build doesn't succeed.

Investigating this issue it appears as though the only parts of mesa
which need talloc are:
- src/mesa/program/ir_to_mesa.cpp
- src/mesa/main/shaderapi.c
- src/glsl

But what's even more interesting is that the talloc sources appear to
be included in the mesa package:
- src/talloc

If the talloc sources are being included in the mesa package, why does
the configure.ac require talloc be installed before you can start
building?


It is only there for system which does not have nice/sane packaging  
management. For those systems that do the mesa should use the system  
provided copy.




Can the 3 components which require talloc not use the talloc already
included in the mesa package?


I more appropriate fix would be to add checks for the talloc header  
and library so we do not require a talloc.pc, mesa should however for  
autoconf builds use the system provided copy.


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

Re: [Mesa-dev] [PATCH 3/3] intel: Merge identical cases in switch statement.

[Brian Paul]

On 08/25/2010 07:14 AM, Nick Bowler wrote:

Signed-off-by: Nick Bowler
---
  src/mesa/drivers/dri/intel/intel_fbo.c |   16 +---
  1 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c 
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 4a83886..2fdb6e4 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -137,27 +137,21 @@ intel_alloc_renderbuffer_storage(GLcontext * ctx, struct 
gl_renderbuffer *rb,
rb->Format = MESA_FORMAT_A8;
rb->DataType = GL_UNSIGNED_BYTE;
break;
+   case GL_DEPTH_COMPONENT16:
+  rb->Format = MESA_FORMAT_Z16;
+  rb->DataType = GL_UNSIGNED_SHORT;
+  break;
 case GL_STENCIL_INDEX:
 case GL_STENCIL_INDEX1_EXT:
 case GL_STENCIL_INDEX4_EXT:
 case GL_STENCIL_INDEX8_EXT:
 case GL_STENCIL_INDEX16_EXT:
-  /* alloc a depth+stencil buffer */
-  rb->Format = MESA_FORMAT_S8_Z24;
-  rb->DataType = GL_UNSIGNED_INT_24_8_EXT;
-  break;
-   case GL_DEPTH_COMPONENT16:
-  rb->Format = MESA_FORMAT_Z16;
-  rb->DataType = GL_UNSIGNED_SHORT;
-  break;
 case GL_DEPTH_COMPONENT:
 case GL_DEPTH_COMPONENT24:
 case GL_DEPTH_COMPONENT32:
-  rb->Format = MESA_FORMAT_S8_Z24;
-  rb->DataType = GL_UNSIGNED_INT_24_8_EXT;
-  break;
 case GL_DEPTH_STENCIL_EXT:
 case GL_DEPTH24_STENCIL8_EXT:
+  /* alloc a depth+stencil buffer */
rb->Format = MESA_FORMAT_S8_Z24;
rb->DataType = GL_UNSIGNED_INT_24_8_EXT;
break;


Committed.  Thanks.

-Brian

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

[Mesa-dev] [Bug 29638] [glsl2]Mesa demo fpglsl render incorrectly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29638

--- Comment #3 from Brian Paul  2010-08-26 07:27:24 PDT ---
I've fixed the demo program.
ac1d244a50087cd454c0eea02115561fac932865

-- 
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 v2] mesa: Identify packed depth/stencil buffers using the Format field.

[Nick Bowler]

Intel sometimes uses packed depth/stencil buffers even when only a depth
buffer or only a stencil buffer was requested.  Common code currently
uses the _BaseFormat field to determine whether a depth/stencil wrapper
is necessary.  But unless the user explicitly requested a packed
depth/stencil buffer, the _BaseFormat field does not encode this
information, and the required wrappers are not created.

The problem was introduced by commit 45e76d2665b38b ("mesa: remove a
bunch of gl_renderbuffer fields"), which killed off the _ActualFormat
field upon which the decision to create a wrapper used to be made.  This
patch changes the logic to use the Format field instead, which is more
like the old code.

Fixes fdo bug 27590.

Signed-off-by: Nick Bowler 
---
 v2: Rewrite the helper function as a generic format helper.
 Suggested by Brian Paul.

 src/mesa/main/formats.c |   15 +++
 src/mesa/main/formats.h |3 +++
 src/mesa/main/framebuffer.c |4 ++--
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index 90449cc..464b93f 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -940,6 +940,21 @@ _mesa_is_format_compressed(gl_format format)
 
 
 /**
+ * Determine if the given format represents a packed depth/stencil buffer.
+ */
+GLboolean
+_mesa_is_format_packed_depth_stencil(gl_format format)
+{
+   if (format == MESA_FORMAT_Z24_S8
+   || format == MESA_FORMAT_Z24_X8
+   || format == MESA_FORMAT_S8_Z24
+   || format == MESA_FORMAT_X8_Z24)
+  return 1;
+
+   return 0;
+}
+
+/**
  * Return color encoding for given format.
  * \return GL_LINEAR or GL_SRGB
  */
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index ad176ca..faa922f 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -190,6 +190,9 @@ _mesa_get_format_block_size(gl_format format, GLuint *bw, 
GLuint *bh);
 extern GLboolean
 _mesa_is_format_compressed(gl_format format);
 
+extern GLboolean
+_mesa_is_format_packed_depth_stencil(gl_format format)
+
 extern GLenum
 _mesa_get_format_color_encoding(gl_format format);
 
diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index e0aac26..3099fc3 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -611,7 +611,7 @@ _mesa_update_depth_buffer(GLcontext *ctx,
 
depthRb = fb->Attachment[attIndex].Renderbuffer;
 
-   if (depthRb && depthRb->_BaseFormat == GL_DEPTH_STENCIL) {
+   if (depthRb && _mesa_format_is_packed_depth_stencil(depthRb->Format)) {
   /* The attached depth buffer is a GL_DEPTH_STENCIL renderbuffer */
   if (!fb->_DepthBuffer
   || fb->_DepthBuffer->Wrapped != depthRb
@@ -652,7 +652,7 @@ _mesa_update_stencil_buffer(GLcontext *ctx,
 
stencilRb = fb->Attachment[attIndex].Renderbuffer;
 
-   if (stencilRb && stencilRb->_BaseFormat == GL_DEPTH_STENCIL) {
+   if (stencilRb && _mesa_format_is_packed_depth_stencil(stencilRb->Format)) {
   /* The attached stencil buffer is a GL_DEPTH_STENCIL renderbuffer */
   if (!fb->_StencilBuffer
   || fb->_StencilBuffer->Wrapped != stencilRb
-- 
1.7.1

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

Re: [Mesa-dev] [PATCH 2/3] mesa: Use the _BaseFormat field to determine attachment completeness.

[Nick Bowler]

On 8/26/10, Brian Paul  wrote:
> This looks good.  I'm not sure if there's a piglit test that would
> exercise this.

I prepared piglit tests for this and the other issue.  Should I send them to
this list as well?  It's not obvious to me where the maintainer(s) want
piglit patches sent.

> Did you run the piglit fbo tests just to be sure there's no regressions?

Yeah.  No piglit regressions on i965 that I could see.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] mesa: Use the _BaseFormat field to determine attachment completeness.

[Brian Paul]

On 08/26/2010 08:33 AM, Nick Bowler wrote:

On 8/26/10, Brian Paul  wrote:

This looks good.  I'm not sure if there's a piglit test that would
exercise this.


I prepared piglit tests for this and the other issue.  Should I send them to
this list as well?  It's not obvious to me where the maintainer(s) want
piglit patches sent.


They should be posted to the piglit list.
http://lists.freedesktop.org/mailman/listinfo/piglit



Did you run the piglit fbo tests just to be sure there's no regressions?


Yeah.  No piglit regressions on i965 that I could see.


Great.

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

Re: [Mesa-dev] [PATCH v2] mesa: Identify packed depth/stencil buffers using the Format field.

[Brian Paul]

I added a missing semicolon after the prototype in formats.h and I 
changed the return values to GL_TRUE/FALSE to be consistant. 
Committed.  Thanks.


-Brian

On 08/26/2010 08:26 AM, Nick Bowler wrote:

Intel sometimes uses packed depth/stencil buffers even when only a depth
buffer or only a stencil buffer was requested.  Common code currently
uses the _BaseFormat field to determine whether a depth/stencil wrapper
is necessary.  But unless the user explicitly requested a packed
depth/stencil buffer, the _BaseFormat field does not encode this
information, and the required wrappers are not created.

The problem was introduced by commit 45e76d2665b38b ("mesa: remove a
bunch of gl_renderbuffer fields"), which killed off the _ActualFormat
field upon which the decision to create a wrapper used to be made.  This
patch changes the logic to use the Format field instead, which is more
like the old code.

Fixes fdo bug 27590.

Signed-off-by: Nick Bowler
---
  v2: Rewrite the helper function as a generic format helper.
  Suggested by Brian Paul.

  src/mesa/main/formats.c |   15 +++
  src/mesa/main/formats.h |3 +++
  src/mesa/main/framebuffer.c |4 ++--
  3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index 90449cc..464b93f 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -940,6 +940,21 @@ _mesa_is_format_compressed(gl_format format)


  /**
+ * Determine if the given format represents a packed depth/stencil buffer.
+ */
+GLboolean
+_mesa_is_format_packed_depth_stencil(gl_format format)
+{
+   if (format == MESA_FORMAT_Z24_S8
+   || format == MESA_FORMAT_Z24_X8
+   || format == MESA_FORMAT_S8_Z24
+   || format == MESA_FORMAT_X8_Z24)
+  return 1;
+
+   return 0;
+}
+
+/**
   * Return color encoding for given format.
   * \return GL_LINEAR or GL_SRGB
   */
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index ad176ca..faa922f 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -190,6 +190,9 @@ _mesa_get_format_block_size(gl_format format, GLuint *bw, 
GLuint *bh);
  extern GLboolean
  _mesa_is_format_compressed(gl_format format);

+extern GLboolean
+_mesa_is_format_packed_depth_stencil(gl_format format)
+
  extern GLenum
  _mesa_get_format_color_encoding(gl_format format);

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index e0aac26..3099fc3 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -611,7 +611,7 @@ _mesa_update_depth_buffer(GLcontext *ctx,

 depthRb = fb->Attachment[attIndex].Renderbuffer;

-   if (depthRb&&  depthRb->_BaseFormat == GL_DEPTH_STENCIL) {
+   if (depthRb&&  _mesa_format_is_packed_depth_stencil(depthRb->Format)) {
/* The attached depth buffer is a GL_DEPTH_STENCIL renderbuffer */
if (!fb->_DepthBuffer
|| fb->_DepthBuffer->Wrapped != depthRb
@@ -652,7 +652,7 @@ _mesa_update_stencil_buffer(GLcontext *ctx,

 stencilRb = fb->Attachment[attIndex].Renderbuffer;

-   if (stencilRb&&  stencilRb->_BaseFormat == GL_DEPTH_STENCIL) {
+   if (stencilRb&&  _mesa_format_is_packed_depth_stencil(stencilRb->Format)) {
/* The attached stencil buffer is a GL_DEPTH_STENCIL renderbuffer */
if (!fb->_StencilBuffer
|| fb->_StencilBuffer->Wrapped != stencilRb


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

Re: [Mesa-dev] [PATCH v2] mesa: Identify packed depth/stencil buffers using the Format field.

[Nick Bowler]

On 8/26/10, Brian Paul  wrote:
> I added a missing semicolon after the prototype in formats.h and I
> changed the return values to GL_TRUE/FALSE to be consistant.
> Committed.  Thanks.

Whoops.  I fixed the missing semicolon, but then forgot to change the
commit id I passed to git send-email.  Sorry about that :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Mesa + glxPixmaps problems

[Ian Molton]

Hi folks,

I've been working on some code that makes extensive use of glxPixmaps 
for offscreen rendering, and I've hit a number of problems.


First, My colleague and I found that the following sequence of events 
led to a crash:


context1 = glXCreateNewContext()
xPixmap = XCreatePixmap ()
glxPixmap = glXCreatePixmap (dpy, blah, xPixmap, NULL);

glXMakeCurrent (dpy, glxPixmap, context1);
context2 = glXCreateNewContext()
glXDestroyContext(dpy, context2);
glXMakeCurrent (dpy, glxPixmap, context1);
**KABOOM**

It turns out that this is down to a flaw in the garbage collection code, 
where a test is made to determine if a drawable still exists, and if 
not, it is dropped from the hashtable (src/glx/glxcmd.c)


The test is this:

XGetWindowAttributes(dpy, draw, &xwa); /* dummy request */

And if an error is caught, it is assumed the drawable is gone, however 
if draw is a glxPixmap, it appears X does not consider them drawable, 
and thus the test will ALWAYS return false, resulting in hashtable 
entries for glxPixmaps being destroyed when they should not.


Changing this line to:

XGetWindowAttributes(dpy, pdraw->xDrawable, &xwa); /* dummy request */

Fixes the problem (by extracting the underlying X drawable from the 
pdraw struct).


Sadly, however, it appears that there are many more similar looking bugs 
in Mesa. Has anyone actually used Mesa to render to glxPixmaps? are 
there patches available to make this stuff work?


Thanks,

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

[Mesa-dev] Mesa EGL extensions

[nobled]

This is a little long, but I was wondering about a couple of the EGL
extensions Mesa implements:

Re: the new EGL_KHR_screenless_opengl and friends that took up the
functionality of EGL_MESA_no_surface - are there specs for those
anywhere on the web? Google gave nothing but Mesa itself, and the KHR
string says it's a Khronos extension, but I can't find it on the
Khronos EGL registry page[1]. Where'd they come from?

Are there any docs for EGL_NOK_texture_from_pixmap either? Mesa's the
only reference I can find for that, too.

Also, the EGL_MESA_screen_surface spec[2] still says it's preliminary
and totally subject to change -- if that's still true, shouldn't it
not be shipped by default if it doesn't guarantee
backwards-compatibility, maybe leave it out unless someone passes a
flag like -DEGL_MESA_screen_surface deliberately? (It also looks like
it hasn't been touched since before the EGL headers were added in Mesa
7.5; are there any changes planned?)

'Cause one reason it probably *shouldn't* offer
backwards-compatibility is it's using EGL enums that are intentionally
just outside the available range[3]. Could someone official file for
an allocation of vendor extension enums for Mesa with Khronos?
(instructions in [3])

Finally, a few things about the new EGL_MESA_drm_image extension:
- Is it also using unallocated enums? They're in the 0x31D0
"any_vendor_use" range in the eglenum.spec file, but I think that
means 'these might belong to any vendor after Khronos allocates them;
aka Reserved', based on the instructions after that seeming to be
directed to Khronos employees who can edit the file.
- The spec file should probably go in src/egl/docs/, not in docs/ with
the OpenGL extensions.
- Same concerns about backwards-compatibility as with the
screen_surface extension - should it require an explicit -D define
until it's finalized?
- The spec allows creating an EGLImageKHR from scratch, then exporting
the underlying DRM handle, then creating a new EGLImage from that
using the standard eglCreateImageKHR call. The exporting is what lets
clients integrate with the modesetting API, but the point of
'importing' a DRM handle is to make passing the EGLImage between
processes possible, right? The trouble is that seems to go against the
EGL_KHR_image_base spec for creating EGLImages from existing EGLImage
siblings/targets/sources:[4]

   * If the resource specified by , , ,  and
  is itself an EGLImage sibling, the error
 EGL_BAD_ACCESS is generated.

It's discussed in more detail in Issues #4 and #5. I might be missing
something - can the requirement even apply to sources shared across
processes? - but if drm_image does need to contradict the base
EGLImage extension, that should probably be pointed out and more
explicitly justified (and if not, then it should clarify how it isn't
contradictory).

[1] http://www.khronos.org/registry/egl/
[2] 
http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/docs/EGL_MESA_screen_surface
[3] http://www.khronos.org/registry/egl/api/eglenum.spec
[4] http://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_image_base.txt
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29793] [glsl2]piglit glslparsertest_glsl2_struct-05.vert and glslparsertest_glsl2_redeclaration-02.vert fail

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29793

Ian Romanick  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Ian Romanick  2010-08-26 09:43:21 PDT 
---
These failures are fixed by this patch sequence:

commit a044285e25615f2d97636fe3ba47d580c3537bc4
Author: Kenneth Graunke 
Date:   Mon Aug 23 14:52:06 2010 -0700

glsl: Move built-ins to live beyond the global scope.

Per the GLSL 1.20 specification (presumably a clarification of 1.10).

Also, when creating user functions, make a new ir_function that shadows the
built-in ir_function, rather than adding new signatures.  User functions
are supposed to hide built-ins, not overload them.

Fixes piglit tests redeclaration-{04, 12, 14}.vert.

commit b6f15869b324ae64a00d0fe46fa3c8c62c1edb6c
Author: Kenneth Graunke 
Date:   Fri Aug 20 20:04:39 2010 -0700

glsl: Move is_built_in flag from ir_function_signature to ir_function.

Also rename it to "is_builtin" for consistency.

Signed-off-by: Ian Romanick 

commit 5d25746640ee27882b69a962459727cf924443db
Author: Kenneth Graunke 
Date:   Tue Aug 24 01:45:49 2010 -0700

glsl: Refactor variable declaration handling.

Moving the check for an earlier variable declaration helps cleanly
separate out the re-declaration vs. new declaration code a bit.  With
that in place, conflicts between variable names and structure types or
function names aren't caught by the earlier "redeclaration" error
message, so check the return type on glsl_symbol_table::add_variable
and issue an error there.  If one occurs, don't emit the initializer.

Fixes redeclaration-01.vert and redeclaration-09.vert.

Signed-off-by: Ian Romanick 

commit ac2376e6f51677ab321930b0200a79d1683cfbba
Author: Kenneth Graunke 
Date:   Wed Aug 25 17:10:16 2010 -0700

glsl: Don't add overloads to existing structure constructors.

Instead, make a new ir_function and try to add it to the symbol table.

Fixes piglit test redeclaration-08.vert.

commit e09591317b2470fe9c104606577d4e10255727c0
Author: Kenneth Graunke 
Date:   Wed Aug 25 16:37:46 2010 -0700

glsl: Remove name_declared_this_scope check when adding functions.

Instead, rely on the symbol table's rules.

Fixes redeclaration-02.vert.

commit e9c7ceed27f6811ad1cae46c93ce9bc3fb3668d8
Author: Kenneth Graunke 
Date:   Sat Aug 21 20:23:18 2010 -0700

glsl: Use a single shared namespace in the symbol table.

As of 1.20, variable names, function names, and structure type names all
share a single namespace, and should conflict with one another in the
same scope, or hide each other in nested scopes.

However, in 1.10, variables and functions can share the same name in the
same scope.  Structure types, however, conflict with/hide both.

Fixes piglit tests redeclaration-06.vert, redeclaration-11.vert,
redeclaration-19.vert, and struct-05.vert.

-- 
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] Mesa EGL extensions

[Kristian Høgsberg]

On Thu, Aug 26, 2010 at 11:55 AM, nobled  wrote:
> This is a little long, but I was wondering about a couple of the EGL
> extensions Mesa implements:
>
> Re: the new EGL_KHR_screenless_opengl and friends that took up the
> functionality of EGL_MESA_no_surface - are there specs for those
> anywhere on the web? Google gave nothing but Mesa itself, and the KHR
> string says it's a Khronos extension, but I can't find it on the
> Khronos EGL registry page[1]. Where'd they come from?

EGL_KHR_surfaceless_{gles1,gles2,opengl} for all practical purposes
Khronos standards, we're down to just a few minor edits.  But it is
still just a draft and as such the extension text isn't publically
available yet.

> Are there any docs for EGL_NOK_texture_from_pixmap either? Mesa's the
> only reference I can find for that, too.

It is an official extension, but I don't know why it's not available
from the Khronos registry.  I'm guessing the web page just hasn't been
updated yet.

> Also, the EGL_MESA_screen_surface spec[2] still says it's preliminary
> and totally subject to change -- if that's still true, shouldn't it
> not be shipped by default if it doesn't guarantee
> backwards-compatibility, maybe leave it out unless someone passes a
> flag like -DEGL_MESA_screen_surface deliberately? (It also looks like
> it hasn't been touched since before the EGL headers were added in Mesa
> 7.5; are there any changes planned?)
>
> 'Cause one reason it probably *shouldn't* offer
> backwards-compatibility is it's using EGL enums that are intentionally
> just outside the available range[3]. Could someone official file for
> an allocation of vendor extension enums for Mesa with Khronos?
> (instructions in [3])

I can't speak for EGL_MESA_screen_surface, but shipping unauthorized
tokens certainly is a problem.

> Finally, a few things about the new EGL_MESA_drm_image extension:
> - Is it also using unallocated enums? They're in the 0x31D0
> "any_vendor_use" range in the eglenum.spec file, but I think that
> means 'these might belong to any vendor after Khronos allocates them;
> aka Reserved', based on the instructions after that seeming to be
> directed to Khronos employees who can edit the file.

It's using allocated tokens.

> - The spec file should probably go in src/egl/docs/, not in docs/ with
> the OpenGL extensions.

I don't think so, if anything the MESA_screen surface spec should be in docs/

> - Same concerns about backwards-compatibility as with the
> screen_surface extension - should it require an explicit -D define
> until it's finalized?

It is finalized.

> - The spec allows creating an EGLImageKHR from scratch, then exporting
> the underlying DRM handle, then creating a new EGLImage from that
> using the standard eglCreateImageKHR call. The exporting is what lets
> clients integrate with the modesetting API, but the point of
> 'importing' a DRM handle is to make passing the EGLImage between
> processes possible, right?

Yes.

> The trouble is that seems to go against the
> EGL_KHR_image_base spec for creating EGLImages from existing EGLImage
> siblings/targets/sources:[4]
>
>       * If the resource specified by , , ,  and
>          is itself an EGLImage sibling, the error
>         EGL_BAD_ACCESS is generated.
>
> It's discussed in more detail in Issues #4 and #5. I might be missing
> something - can the requirement even apply to sources shared across
> processes? - but if drm_image does need to contradict the base
> EGLImage extension, that should probably be pointed out and more
> explicitly justified (and if not, then it should clarify how it isn't
> contradictory).

Yes, but this is also an issue with the image_pixmap extension, which
also concerns sharing EGLImages between multiple processes.  I guess
one way to view this is that the EGLImage created from a drm buffer
name is conceptually the same as the EGLImage in the other process
where the name was assigned.

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

[Mesa-dev] [Bug 29578] [Gallium/Draw] Kwin effects don't work with Gallium3D driver

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29578

--- Comment #14 from Marek Olšák  2010-08-26 11:17:55 PDT ---
The driver has not software fallback so I don't see how it could have so high
CPU usage. It appears to me KDE uses the selection and/or feedback mode, both
of which don't touch the driver and are processed in software.

-- 
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 29578] [Gallium/Draw] Kwin effects don't work with Gallium3D driver

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29578

Marek Olšák  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #15 from Marek Olšák  2010-08-26 11:26:15 PDT ---
Well actually I am pretty sure KDE uses one of those modes, because otherwise
you wouldn't need LLVM and you wouldn't be getting crashes in Draw. Those two
modes will never be hardware-accelerated, because they need CPU->GPU->CPU
roundtrip, which is slow.

As the original crash appears to be fixed (and I think another fix to the same
bug should be in mesa master already), I am closing this bug.

-- 
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 29822] New: [glsl bisected] Unigine Sanctuary v2.2: no shadows (allocation of uniforms failed)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29822

   Summary: [glsl bisected] Unigine Sanctuary v2.2: no shadows
(allocation of uniforms failed)
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: dra...@centrum.cz


Created an attachment (id=38193)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38193)
full terminal output

With latest mesa git there are no shadows in Unigine Sanctuary, they were
really messed up before, now they are missing completely. git bisect showed
this:

commit 0924ba0c3496160a134d37cec800f902ae805b9c
Author: Eric Anholt 
Date:   Tue Aug 24 14:27:27 2010 -0700

ir_to_mesa: Convert this code to using linker.cpp's uniform locations.

Fixes: glsl-fs-uniform-array-4.

This is being printed into terminal, full log attached:
GLShader::compile(): Allocation of uniform `s_light_shadow_iradius' to target
failed (0 vs 9)
Allocation of uniform `color_scale' to target failed (1 vs 0)
Allocation of uniform `s_texture_13' to target failed (2 vs 1)
Allocation of uniform `s_texture_11' to target failed (3 vs 2)
Allocation of uniform `s_texture_3' to target failed (4 vs 3)
Allocation of uniform `s_texture_2' to target failed (5 vs 4)
Allocation of uniform `s_texture_1' to target failed (6 vs 5)
Allocation of uniform `s_material_phong_rim' to target failed (7 vs 6)
Allocation of uniform `s_material_shading' to target failed (8 vs 7)
Allocation of uniform `s_material_fresnel' to target failed (9 vs 8)
Material::create_shader(): can't compile
"core/shaders/meshes/vertex_base.shader" vertex shader
defines:
UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,MULTISAMPLE_0,USE_INSTANCING,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,PROJ,SHADOW,BASE_LIGHT_PROJ
Material::create_shader(): can't compile
"core/shaders/meshes/fragment_base_light_proj.shader" fragment shader
defines:
UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,MULTISAMPLE_0,USE_INSTANCING,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,PROJ,SHADOW,PHONG_RIM

This is with r300g driver, RV530, 2.6.35 kernel. Sorry about using this old
version of Unigine, the last one need GL_ARB_half_float_pixel which is not
supported in r300g.

-- 
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] Mesa + glxPixmaps problems

[tom fogal]

Ian Molton  writes:
> Sadly, however, it appears that there are many more similar looking
> bugs in Mesa. Has anyone actually used Mesa to render to glxPixmaps?
> are there patches available to make this stuff work?

FBOs are a (much) better way to achieve what you want: they are cross
platform and supported well.  They accelerate well; I have a vague
recollection that in ancient times one would get SW rendering in some
drivers for pixmaps.

Even intel cards support FBOs; I imagine they're pretty universal these
days.

  http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.txt

All that said, I'm sure sane patches fixing glX pixmap issues would be
committed.

HTH,

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

[Mesa-dev] [Bug 29822] [glsl bisected] Unigine Sanctuary v2.2: no shadows (allocation of uniforms failed)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29822

Pavel Ondračka  changed:

   What|Removed |Added

   Keywords||regression
 CC||e...@anholt.net

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

Re: [Mesa-dev] [PATCH 2/3] mesa: Use the _BaseFormat field to determine attachment completeness.

[Ian Romanick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nick Bowler wrote:
> Intel sometimes uses packed depth/stencil buffers even when only a
> depth buffer or only a stencil buffer was requested.  GL specifies
> that GL_DEPTH_COMPONENT renderbuffers are *not* stencil-attachable,
> but the current check happily attaches these buffers to the stencil
> attachment point (or vice-versa for GL_STENCIL_INDEX renderbuffers
> and the depth attachment).  Performing such an attachment must yield
> an incomplete framebuffer.
> 
> Since the renderbuffer struct has the actual base format stored in it,
> use that value instead of recomputing it incorrectly.
> 
> Signed-off-by: Nick Bowler 

It may not be related (I haven't bisected yet), but at least some
programs fail with swrast now.  In particular, mandelbrot from Mesa
demos hits:

mandelbrot: main/depthstencil.c:360: _mesa_new_z24_renderbuffer_wrapper:
Assertion `dsrb->DataType == 0x84FA' failed.

> ---
>  src/mesa/main/fbobject.c |3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 9a84e5a..80bc518 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -485,8 +485,7 @@ test_attachment_completeness(const GLcontext *ctx, GLenum 
> format,
>}
> }
> else if (att->Type == GL_RENDERBUFFER_EXT) {
> -  const GLenum baseFormat =
> - _mesa_get_format_base_format(att->Renderbuffer->Format);
> +  const GLenum baseFormat = att->Renderbuffer->_BaseFormat;
>  
>ASSERT(att->Renderbuffer);
>if (!att->Renderbuffer->InternalFormat ||

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx2t4sACgkQX1gOwKyEAw+/+ACfVD/UbqSE+YbBl2soKTHzhuWz
FsgAn1cS1z7/rD/fPOqudIj1UcDE4h1U
=clNT
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] mesa: Use the _BaseFormat field to determine attachment completeness.

[Brian Paul]

On 08/26/2010 12:50 PM, Ian Romanick wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nick Bowler wrote:

Intel sometimes uses packed depth/stencil buffers even when only a
depth buffer or only a stencil buffer was requested.  GL specifies
that GL_DEPTH_COMPONENT renderbuffers are *not* stencil-attachable,
but the current check happily attaches these buffers to the stencil
attachment point (or vice-versa for GL_STENCIL_INDEX renderbuffers
and the depth attachment).  Performing such an attachment must yield
an incomplete framebuffer.

Since the renderbuffer struct has the actual base format stored in it,
use that value instead of recomputing it incorrectly.

Signed-off-by: Nick Bowler


It may not be related (I haven't bisected yet), but at least some
programs fail with swrast now.  In particular, mandelbrot from Mesa
demos hits:

mandelbrot: main/depthstencil.c:360: _mesa_new_z24_renderbuffer_wrapper:
Assertion `dsrb->DataType == 0x84FA' failed.


Hmmm, not seeing that here.

Can you print *dsrb in gdb?

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

Re: [Mesa-dev] Mesa (master): r300g: fix gl_PointCoord

[Ian Romanick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marek Olšák wrote:
> On Thu, Aug 26, 2010 at 4:08 AM, Luca Barbieri  > wrote:
> 
> Also, doesn't sprite coord replacement also affect gl_TexCoord in GLSL?
> 
> I suspect it does.

Why would it?  gl_TexCoord is a set of varyings written by the vertex
shader.  gl_PointCoord is a magic varying generated during
rasterization.  Neither has anything to do with the other in GLSL.  Like
all varyings (except the magic varyings gl_PointCoord and gl_FragCoord)
in points, the fragment shader gets the same value at every fragment.

I think there is a piglit test for this.  If it's not

Getting all the cases of fixed-function, assembly fragment programs, and
GLSL fragment shaders correct is hard.  I worked on this a bit for 965
and got really frustrated.  The fixed-function and assembly program
support (with the per-texture coordinate replacement bits) forces
state-based recompiles on most hardware.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx2u+oACgkQX1gOwKyEAw+oOQCbBf8BX1gKJK/+97p1MYnK8vPD
FIkAnjGL8tp2t+1ysZdjlH4BQNtxYSHK
=qphC
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29578] [Gallium/Draw] Kwin effects don't work with Gallium3D driver

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29578

--- Comment #16 from Niels Ole Salscheider  
2010-08-26 12:49:46 PDT ---
There seems to be something wrong in KDE's functionality check. If you disable
them all effects are hardware accelerated (at least for me; although the new
glsl compiler somehow broke the blur effect).

Maybe someone should file a bug report against KDE...

-- 
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 29823] New: GetUniform[if]v busted

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29823

   Summary: GetUniform[if]v busted
   Product: Mesa
   Version: unspecified
  Platform: Other
OS/Version: All
Status: NEW
  Severity: critical
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: vladi...@pobox.com


(Mesa 7.8.2, reproduced in 7.7.x as well.)

Given a shader that includes a uniform such as:

uniform float u_array[4];

void main()
{
... something that uses u_array[0..3];
}

glGetUniformfv with the location of "u_array" or "u_array[0]" (they're
identical locations, as per the spec) does something very strange that ends up
scribbling the stack.  For that uniform, the gl_program_parameter struct looks
like:

Name: "u_array"
Type: PROGRAM_UNIFORM
DataType: 0x1406
Size: 0x10
Used: 0x01
Initialized: 0x01
Flags: 0

The Size of 0x10 seems to have somehow ended up as the size in bytes of the
uniform storage.  This causes a problem in get_uniform_rows_cols, where it
does:

if (p->Size <= 4) {
  *rows = 1;
  *cols = p->Size;
} else {
  *rows = p->Size / 4 + 1;
  if (p->Size % 4 == 0)
*cols = 4;
  else
*cols = p->Size % 4;
}

We end up with rows = 5 and cols = 4, which causes _mesa_get_uniformfv to
attempt to write 4*5 values, which is invalid.

I'm not sure where the bogus Size = 16 is coming from...

-- 
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] Mesa (master): r300g: fix gl_PointCoord

[Luca Barbieri]

OpenGL 4.1 compatibility profile says:
<<
All fragments produced in rasterizing a point sprite are assigned the same as-
sociated data, which are those of the vertex corresponding to the
point. However,
the fragment shader built-in gl_PointCoord contains point sprite texture coor-
dinates. Additionally, for each texture coordinate set where COORD_REPLACE is
TRUE, these texture coordinates are replaced with point sprite texture
coordinates.
>>

I think "texture coordinates" here must refer to gl_TexCoord[i].
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29824] New: OSMesaMakeCurrent triggers assertion on multiple MakeCurrent calls

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29824

   Summary: OSMesaMakeCurrent triggers assertion on multiple
MakeCurrent calls
   Product: Mesa
   Version: unspecified
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: vladi...@pobox.com


OSMesaMakeCurrent seems to expect that it will be called only once, because
each time it ends up creating a new osmesa renderbuffer from the given buffer
and calls _mesa_add_renderbuffer to attach it to BUFFER_FRONT_LEFT.

Ignoring the performance implications of this if you're trying to use OSMesa
with multiple contexts, this ends up triggering an assertion in renderbuffer.c
_mesa_add_renderbuffer -- it asserts that there's no currently attached
renderbuffer at that attachment point, but of course there will be, from the
previous time that OSMesaMakeCurrent was called.

I'm not sure if this is currently leading to leaks of the renderbuffer
structures if the assertion is ignored; an easy fix would probably be to check
if there's a buffer attached to the gl_buffer, and if so, to detach it before
attaching a new one.  Not sure how to do that code-wise, though.

-- 
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] Mesa + glxPixmaps problems

[Eric Anholt]

On Thu, 26 Aug 2010 16:30:55 +0100, Ian Molton  
wrote:
> 
> Hi folks,
> 
> I've been working on some code that makes extensive use of glxPixmaps 
> for offscreen rendering, and I've hit a number of problems.
> 
> First, My colleague and I found that the following sequence of events 
> led to a crash:

What we could really use is piglit cases for excercising GLX context
handling like this.  I've started with a couple and they've been great
for catching some issues, but we clearly need a lot more.  If you could
get some cases generated (see tests/glx/*.c for existing examples), I
bet you could convince krh to take a look.


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

[Mesa-dev] [Bug 29824] OSMesaMakeCurrent triggers assertion on multiple MakeCurrent calls

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29824

Tom Fogal  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Tom Fogal  2010-08-26 14:27:49 PDT 
---
I think that a patch to fix this has been applied to the 7.8 branch, to be
released in 7.8.3.

Please reopen if you can reproduce this problem using 7.8 from git.

*** This bug has been marked as a duplicate of bug 10966 ***

-- 
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 10966] workaround to avoid the assert main/renderbuffer.c:2041: _mesa_add_renderbuffer:...

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=10966

Tom Fogal  changed:

   What|Removed |Added

 CC||vladi...@pobox.com

--- Comment #17 from Tom Fogal  2010-08-26 14:27:49 PDT 
---
*** Bug 29824 has been marked as a duplicate of this bug. ***

-- 
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: Use the format info to identify packed depth/stencil formats.

[Nick Bowler]

Due to a misunderstanding of the Z24_X8 and X8_Z24 formats, the earlier
patch created depth/stencil wrappers for them.  This broke swrast.

Use the format info instead, which only identifies Z24_S8 and S8_Z24 as
packed depth/stencil.  It also has the advantage of being nicer code.

Signed-off-by: Nick Bowler 
---
 src/mesa/main/formats.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index c5f3e0b..112d7a0 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -945,13 +945,9 @@ _mesa_is_format_compressed(gl_format format)
 GLboolean
 _mesa_is_format_packed_depth_stencil(gl_format format)
 {
-   if (format == MESA_FORMAT_Z24_S8
-   || format == MESA_FORMAT_Z24_X8
-   || format == MESA_FORMAT_S8_Z24
-   || format == MESA_FORMAT_X8_Z24)
-  return GL_TRUE;
+   const struct gl_format_info *info = _mesa_get_format_info(format);
 
-   return GL_FALSE;
+   return info->BaseFormat == GL_DEPTH_STENCIL;
 }
 
 
-- 
1.7.1

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

Re: [Mesa-dev] mesa compile, talloc

[Trevor Woerner]

On Thu, Aug 26, 2010 at 10:17 AM, Jakob Bornecrantz  wrote:
> On 26 aug 2010, at 15.10, Trevor Woerner wrote:
>> If the talloc sources are being included in the mesa package, why does
>> the configure.ac require talloc be installed before you can start
>> building?
>
> It is only there for system which does not have nice/sane packaging
> management. For those systems that do the mesa should use the system
> provided copy.

Hmm... I guess this means the configure.ac needs something more.

>> Can the 3 components which require talloc not use the talloc already
>> included in the mesa package?
>
> I more appropriate fix would be to add checks for the talloc header and
> library so we do not require a talloc.pc, mesa should however for autoconf
> builds use the system provided copy.

Okay, I could look into this if nobody else is interested.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29831] New: git Mesa 7.9-devel no longer running the 'engine' demo

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29831

   Summary: git Mesa 7.9-devel no longer running the 'engine' demo
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: wol...@onsneteindhoven.nl


The last git mesa which runs the engine demo without error is version
mesa-bda941e1b895547d680b68eaf28ae2db11e6149f, (Nick Bowler).
After this version, the engine demo no longer runs, showing the following
error:
---
~/demos$ ./engine
engine: main/depthstencil.c:150: get_values_z24: Assertion `dsrb->Format ==
MESA_FORMAT_S8_Z24' failed.
Aborted
---
I tested the engine demo using mesa OpenGL renderer string: Mesa DRI R600
(RS780 9612) 20090101  TCL DRI2, OpenGL version string: 2.1 Mesa 7.9-devel.

-- 
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] Mesa EGL extensions

[Chia-I Wu]

2010/8/27 Kristian Høgsberg :
> On Thu, Aug 26, 2010 at 11:55 AM, nobled  wrote:
>> This is a little long, but I was wondering about a couple of the EGL
>> extensions Mesa implements:
>>
>> Re: the new EGL_KHR_screenless_opengl and friends that took up the
>> functionality of EGL_MESA_no_surface - are there specs for those
>> anywhere on the web? Google gave nothing but Mesa itself, and the KHR
>> string says it's a Khronos extension, but I can't find it on the
>> Khronos EGL registry page[1]. Where'd they come from?
>
> EGL_KHR_surfaceless_{gles1,gles2,opengl} for all practical purposes
> Khronos standards, we're down to just a few minor edits.  But it is
> still just a draft and as such the extension text isn't publically
> available yet.
>
>> Are there any docs for EGL_NOK_texture_from_pixmap either? Mesa's the
>> only reference I can find for that, too.
>
> It is an official extension, but I don't know why it's not available
> from the Khronos registry.  I'm guessing the web page just hasn't been
> updated yet.
>
>> Also, the EGL_MESA_screen_surface spec[2] still says it's preliminary
>> and totally subject to change -- if that's still true, shouldn't it
>> not be shipped by default if it doesn't guarantee
>> backwards-compatibility, maybe leave it out unless someone passes a
>> flag like -DEGL_MESA_screen_surface deliberately? (It also looks like
>> it hasn't been touched since before the EGL headers were added in Mesa
>> 7.5; are there any changes planned?)
>>
>> 'Cause one reason it probably *shouldn't* offer
>> backwards-compatibility is it's using EGL enums that are intentionally
>> just outside the available range[3]. Could someone official file for
>> an allocation of vendor extension enums for Mesa with Khronos?
>> (instructions in [3])
>
> I can't speak for EGL_MESA_screen_surface, but shipping unauthorized
> tokens certainly is a problem.
I am not aware of any user of EGL_MESA_screen_surface.  It was
designed for Xegl which was dead for a while, IIRC.

It is conceptually useful though.  It enables EGL on platforms without
window systems.  The bulk of the extension is about mode setting.  But
as the extension predates KMS, which is still getting new features
itself, the extension does not receive much attention.

With the new DRM display and image extensions, there is nothing in
EGL_MESA_screen_surface that cannot be accomplished by the new
extensions.  The complexity of mode setting, which is taken care of by
EGL_MESA_screen_surface, can also be moved to an utility library.
Personally, I would vote for killing the extension in the git history.
>> Finally, a few things about the new EGL_MESA_drm_image extension:
>> - Is it also using unallocated enums? They're in the 0x31D0
>> "any_vendor_use" range in the eglenum.spec file, but I think that
>> means 'these might belong to any vendor after Khronos allocates them;
>> aka Reserved', based on the instructions after that seeming to be
>> directed to Khronos employees who can edit the file.
> It's using allocated tokens.
Allocated for Mesa?
>> - The spec file should probably go in src/egl/docs/, not in docs/ with
>> the OpenGL extensions.
>
> I don't think so, if anything the MESA_screen surface spec should be in docs/
>
>> - Same concerns about backwards-compatibility as with the
>> screen_surface extension - should it require an explicit -D define
>> until it's finalized?
>
> It is finalized.
>
>> - The spec allows creating an EGLImageKHR from scratch, then exporting
>> the underlying DRM handle, then creating a new EGLImage from that
>> using the standard eglCreateImageKHR call. The exporting is what lets
>> clients integrate with the modesetting API, but the point of
>> 'importing' a DRM handle is to make passing the EGLImage between
>> processes possible, right?
>
> Yes.
>
>> The trouble is that seems to go against the
>> EGL_KHR_image_base spec for creating EGLImages from existing EGLImage
>> siblings/targets/sources:[4]
>>
>>       * If the resource specified by , , ,  and
>>          is itself an EGLImage sibling, the error
>>         EGL_BAD_ACCESS is generated.
>>
>> It's discussed in more detail in Issues #4 and #5. I might be missing
>> something - can the requirement even apply to sources shared across
>> processes? - but if drm_image does need to contradict the base
>> EGLImage extension, that should probably be pointed out and more
>> explicitly justified (and if not, then it should clarify how it isn't
>> contradictory).
> Yes, but this is also an issue with the image_pixmap extension, which
> also concerns sharing EGLImages between multiple processes.  I guess
> one way to view this is that the EGLImage created from a drm buffer
> name is conceptually the same as the EGLImage in the other process
> where the name was assigned.
> Kristian
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



-- 
o...@lunarg.com