mesa3d-dev

[Mesa3d-dev] [PATCH 3/4] APPLE_object_purgeable: core

[Chris W. <ch...@ch...>]

Signed-off-by: Chris Wilson <ch...@ch...>
---
 src/mesa/main/api_exec.c   |    6 +
 src/mesa/main/bufferobj.c  |  356 ++++++++++++++++++++++++++++++++++++++++++++
 src/mesa/main/bufferobj.h  |   11 ++
 src/mesa/main/dd.h         |   17 ++
 src/mesa/main/dlist.c      |    6 +
 src/mesa/main/extensions.c |    4 +
 src/mesa/main/mfeatures.h  |    1 +
 src/mesa/main/mtypes.h     |    4 +
 8 files changed, 405 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/api_exec.c b/src/mesa/main/api_exec.c
index 70c154b..fa8d409 100644
--- a/src/mesa/main/api_exec.c
+++ b/src/mesa/main/api_exec.c
@@ -758,4 +758,10 @@ _mesa_init_exec_table(struct _glapi_table *exec)
    SET_EGLImageTargetTexture2DOES(exec, _mesa_EGLImageTargetTexture2DOES);
    SET_EGLImageTargetRenderbufferStorageOES(exec, _mesa_EGLImageTargetRenderbufferStorageOES);
 #endif
+
+#if FEATURE_APPLE_object_purgeable
+   SET_ObjectPurgeableAPPLE(exec, _mesa_ObjectPurgeableAPPLE);
+   SET_ObjectUnpurgeableAPPLE(exec, _mesa_ObjectUnpurgeableAPPLE);
+   SET_GetObjectParameterivAPPLE(exec, _mesa_GetObjectParameterivAPPLE);
+#endif
 }
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 971b280..3c48f6c 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -37,6 +37,8 @@
 #include "image.h"
 #include "context.h"
 #include "bufferobj.h"
+#include "fbobject.h"
+#include "texobj.h"
 
 
 /* Debug flags */
@@ -1710,3 +1712,357 @@ _mesa_FlushMappedBufferRange(GLenum target, GLintptr offset, GLsizeiptr length)
    if (ctx->Driver.FlushMappedBufferRange)
       ctx->Driver.FlushMappedBufferRange(ctx, target, offset, length, bufObj);
 }
+
+#if FEATURE_APPLE_object_purgeable
+static GLenum
+_mesa_BufferObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+   struct gl_buffer_object *bufObj;
+   GLenum retval;
+
+   bufObj = _mesa_lookup_bufferobj(ctx, name);
+   if (!bufObj) {
+      _mesa_error(ctx, GL_INVALID_VALUE,
+                  "glObjectPurgeable(name = 0x%x)", name);
+      return 0;
+   }
+   if (!_mesa_is_bufferobj(bufObj)) {
+      _mesa_error(ctx, GL_INVALID_OPERATION, "glObjectPurgeable(buffer 0)" );
+      return 0;
+   }
+
+   if (bufObj->Purgeable) {
+      _mesa_error(ctx, GL_INVALID_OPERATION,
+                  "glObjectPurgeable(name = 0x%x) is already purgeable", name);
+      return GL_VOLATILE_APPLE;
+   }
+
+   bufObj->Purgeable = GL_TRUE;
+
+   retval = GL_VOLATILE_APPLE;
+   if (ctx->Driver.BufferObjectPurgeable)
+      retval = ctx->Driver.BufferObjectPurgeable(ctx, bufObj, option);
+
+   return retval;
+}
+
+static GLenum
+_mesa_RenderObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+   struct gl_renderbuffer *bufObj;
+   GLenum retval;
+
+   bufObj = _mesa_lookup_renderbuffer(ctx, name);
+   if (!bufObj) {
+      _mesa_error(ctx, GL_INVALID_VALUE,
+                  "glObjectUnpurgeable(name = 0x%x)", name);
+      return 0;
+   }
+
+   if (bufObj->Purgeable) {
+      _mesa_error(ctx, GL_INVALID_OPERATION,
+                  "glObjectPurgeable(name = 0x%x) is already purgeable", name);
+      return GL_VOLATILE_APPLE;
+   }
+
+   bufObj->Purgeable = GL_TRUE;
+
+   retval = GL_VOLATILE_APPLE;
+   if (ctx->Driver.RenderObjectPurgeable)
+      retval = ctx->Driver.RenderObjectPurgeable(ctx, bufObj, option);
+
+   return retval;
+}
+
+static GLenum
+_mesa_TextureObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+   struct gl_texture_object *bufObj;
+   GLenum retval;
+
+   bufObj = _mesa_lookup_texture(ctx, name);
+   if (!bufObj) {
+      _mesa_error(ctx, GL_INVALID_VALUE,
+                  "glObjectPurgeable(name = 0x%x)", name);
+      return 0;
+   }
+
+   if (bufObj->Purgeable) {
+      _mesa_error(ctx, GL_INVALID_OPERATION,
+                  "glObjectPurgeable(name = 0x%x) is already purgeable", name);
+      return GL_VOLATILE_APPLE;
+   }
+
+   bufObj->Purgeable = GL_TRUE;
+
+   retval = GL_VOLATILE_APPLE;
+   if (ctx->Driver.TextureObjectPurgeable)
+      retval = ctx->Driver.TextureObjectPurgeable(ctx, bufObj, option);
+
+   return retval;
+}
+
+GLenum GLAPIENTRY
+_mesa_ObjectPurgeableAPPLE(GLenum objectType, GLuint name, GLenum option)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx, 0);
+
+   if (name == 0) {
+      _mesa_error(ctx, GL_INVALID_VALUE,
+                  "glObjectPurgeable(name = 0x%x)", name);
+      return 0;
+   }
+
+   switch (option) {
+   case GL_VOLATILE_APPLE:
+   case GL_RELEASED_APPLE:
+      break;
+
+   default:
+      _mesa_error(ctx, GL_INVALID_ENUM,
+                  "glObjectPurgeable(name = 0x%x) invalid option: %d", name, option);
+      return 0;
+   }
+
+   switch (objectType) {
+   case GL_TEXTURE:
+      return _mesa_TextureObjectPurgeable (ctx, name, option);
+   case GL_RENDERBUFFER_EXT:
+      return _mesa_RenderObjectPurgeable (ctx, name, option);
+   case GL_BUFFER_OBJECT_APPLE:
+      return _mesa_BufferObjectPurgeable (ctx, name, option);
+
+   default:
+      _mesa_error(ctx, GL_INVALID_ENUM,
+                  "glObjectPurgeable(name = 0x%x) invalid type: %d", name, objectType);
+      return 0;
+   }
+}
+
+static GLenum
+_mesa_BufferObjectUnpurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+   struct gl_buffer_object *bufObj;
+   GLenum retval;
+
+   bufObj = _mesa_lookup_bufferobj(ctx, name);
+   if (!bufObj) {
+      _mesa_error(ctx, GL_INVALID_VALUE,
+                  "glObjectUnpurgeable(name = 0x%x)", name);
+      return 0;
+   }
+
+   if (! bufObj->Purgeable) {
+      _mesa_error(ctx, GL_INVALID_OPERATION,
+                  "glObjectUnpurgeable(name = 0x%x) object is already \"unpurged\"", name);
+      return 0;
+   }
+
+   bufObj->Purgeable = GL_FALSE;
+
+   retval = GL_RETAINED_APPLE;
+   if (ctx->Driver.BufferObjectUnpurgeable)
+      retval = ctx->Driver.BufferObjectUnpurgeable(ctx, bufObj, option);
+
+   return retval;
+}
+
+static GLenum
+_mesa_RenderObjectUnpurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+   struct gl_renderbuffer *bufObj;
+   GLenum retval;
+
+   bufObj = _mesa_lookup_renderbuffer(ctx, name);
+   if (!bufObj) {
+      _mesa_error(ctx, GL_INVALID_VALUE,
+                  "glObjectUnpurgeable(name = 0x%x)", name);
+      return 0;
+   }
+
+   if (! bufObj->Purgeable) {
+      _mesa_error(ctx, GL_INVALID_OPERATION,
+                  "glObjectUnpurgeable(name = 0x%x) object is already \"unpurged\"", name);
+      return 0;
+   }
+
+   bufObj->Purgeable = GL_FALSE;
+
+   retval = GL_RETAINED_APPLE;
+   if (ctx->Driver.RenderObjectUnpurgeable)
+      retval = ctx->Driver.RenderObjectUnpurgeable(ctx, bufObj, option);
+
+   return retval;
+}
+
+static GLenum
+_mesa_TextureObjectUnpurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+   struct gl_texture_object *bufObj;
+   GLenum retval;
+
+   bufObj = _mesa_lookup_texture(ctx, name);
+   if (!bufObj) {
+      _mesa_error(ctx, GL_INVALID_VALUE,
+                  "glObjectUnpurgeable(name = 0x%x)", name);
+      return 0;
+   }
+
+   if (! bufObj->Purgeable) {
+      _mesa_error(ctx, GL_INVALID_OPERATION,
+                  "glObjectUnpurgeable(name = 0x%x) object is already \"unpurged\"", name);
+      return 0;
+   }
+
+   bufObj->Purgeable = GL_FALSE;
+
+   retval = GL_RETAINED_APPLE;
+   if (ctx->Driver.TextureObjectUnpurgeable)
+      retval = ctx->Driver.TextureObjectUnpurgeable(ctx, bufObj, option);
+
+   return retval;
+}
+
+GLenum GLAPIENTRY
+_mesa_ObjectUnpurgeableAPPLE(GLenum objectType, GLuint name, GLenum option)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx, 0);
+
+   if (name == 0) {
+      _mesa_error(ctx, GL_INVALID_VALUE,
+                  "glObjectUnpurgeable(name = 0x%x)", name);
+      return 0;
+   }
+
+   switch (option) {
+   case GL_RETAINED_APPLE:
+   case GL_UNDEFINED_APPLE:
+      break;
+
+   default:
+      _mesa_error(ctx, GL_INVALID_ENUM,
+                  "glObjectUnpurgeable(name = 0x%x) invalid option: %d", name, option);
+      return 0;
+   }
+
+   switch (objectType) {
+   case GL_BUFFER_OBJECT_APPLE:
+      return _mesa_BufferObjectUnpurgeable(ctx, name, option);
+
+   case GL_TEXTURE:
+      return _mesa_TextureObjectUnpurgeable(ctx, name, option);
+
+   case GL_RENDERBUFFER_EXT:
+      return _mesa_RenderObjectUnpurgeable(ctx, name, option);
+
+   default:
+      _mesa_error(ctx, GL_INVALID_ENUM,
+                  "glObjectUnpurgeable(name = 0x%x) invalid type: %d", name, objectType);
+      return 0;
+   }
+}
+
+static void
+_mesa_GetBufferObjectParameterivAPPLE(GLcontext *ctx, GLuint name, GLenum pname, GLint* params)
+{
+   struct gl_buffer_object *bufObj;
+
+   bufObj = _mesa_lookup_bufferobj(ctx, name);
+   if (!bufObj) {
+      _mesa_error(ctx, GL_INVALID_VALUE,
+                  "glGetObjectParameteriv(name = 0x%x) invalid object", name);
+      return;
+   }
+
+   switch (pname) {
+   case GL_PURGEABLE_APPLE:
+      *params = bufObj->Purgeable;
+      break;
+
+   default:
+      _mesa_error(ctx, GL_INVALID_ENUM,
+                  "glGetObjectParameteriv(name = 0x%x) invalid enum: %d", name, pname);
+      break;
+   }
+}
+
+static void
+_mesa_GetRenderObjectParameterivAPPLE(GLcontext *ctx, GLuint name, GLenum pname, GLint* params)
+{
+   struct gl_renderbuffer *bufObj;
+
+   bufObj = _mesa_lookup_renderbuffer(ctx, name);
+   if (!bufObj) {
+      _mesa_error(ctx, GL_INVALID_VALUE,
+                  "glObjectUnpurgeable(name = 0x%x)", name);
+      return;
+   }
+
+   switch (pname) {
+   case GL_PURGEABLE_APPLE:
+      *params = bufObj->Purgeable;
+      break;
+
+   default:
+      _mesa_error(ctx, GL_INVALID_ENUM,
+                  "glGetObjectParameteriv(name = 0x%x) invalid enum: %d", name, pname);
+      break;
+   }
+}
+
+static void
+_mesa_GetTextureObjectParameterivAPPLE(GLcontext *ctx, GLuint name, GLenum pname, GLint* params)
+{
+   struct gl_texture_object *bufObj;
+
+   bufObj = _mesa_lookup_texture(ctx, name);
+   if (!bufObj) {
+      _mesa_error(ctx, GL_INVALID_VALUE,
+                  "glObjectUnpurgeable(name = 0x%x)", name);
+      return;
+   }
+
+   switch (pname) {
+   case GL_PURGEABLE_APPLE:
+      *params = bufObj->Purgeable;
+      break;
+
+   default:
+      _mesa_error(ctx, GL_INVALID_ENUM,
+                  "glGetObjectParameteriv(name = 0x%x) invalid enum: %d", name, pname);
+      break;
+   }
+}
+
+void GLAPIENTRY
+_mesa_GetObjectParameterivAPPLE(GLenum objectType, GLuint name, GLenum pname, GLint* params)
+{
+   GET_CURRENT_CONTEXT(ctx);
+
+   if (name == 0) {
+      _mesa_error(ctx, GL_INVALID_VALUE,
+                  "glGetObjectParameteriv(name = 0x%x)", name);
+      return;
+   }
+
+   switch (objectType) {
+   case GL_TEXTURE:
+      _mesa_GetTextureObjectParameterivAPPLE (ctx, name, pname, params);
+      break;
+
+   case GL_BUFFER_OBJECT_APPLE:
+      _mesa_GetBufferObjectParameterivAPPLE (ctx, name, pname, params);
+      break;
+
+   case GL_RENDERBUFFER_EXT:
+      _mesa_GetRenderObjectParameterivAPPLE (ctx, name, pname, params);
+      break;
+
+   default:
+      _mesa_error(ctx, GL_INVALID_ENUM,
+                  "glGetObjectParameteriv(name = 0x%x) invalid type: %d", name, objectType);
+   }
+}
+#endif
diff --git a/src/mesa/main/bufferobj.h b/src/mesa/main/bufferobj.h
index f8bca5f..912529c 100644
--- a/src/mesa/main/bufferobj.h
+++ b/src/mesa/main/bufferobj.h
@@ -175,4 +175,15 @@ _mesa_MapBufferRange(GLenum target, GLintptr offset, GLsizeiptr length,
 extern void GLAPIENTRY
 _mesa_FlushMappedBufferRange(GLenum target, GLintptr offset, GLsizeiptr length);
 
+#if FEATURE_APPLE_object_purgeable
+extern GLenum GLAPIENTRY
+_mesa_ObjectPurgeableAPPLE(GLenum objectType, GLuint name, GLenum option);
+
+extern GLenum GLAPIENTRY
+_mesa_ObjectUnpurgeableAPPLE(GLenum objectType, GLuint name, GLenum option);
+
+extern void GLAPIENTRY
+_mesa_GetObjectParameterivAPPLE(GLenum objectType, GLuint name, GLenum pname, GLint* params);
+#endif
+
 #endif
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 84b83fe..197de09 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -777,6 +777,23 @@ struct dd_function_table {
 #endif
 
    /**
+    * \name Functions for GL_APPLE_object_purgeable
+    */
+#if FEATURE_APPLE_object_purgeable
+   /*@{*/
+   /* variations on ObjectPurgeable */
+   GLenum (*BufferObjectPurgeable)( GLcontext *ctx, struct gl_buffer_object *obj, GLenum option );
+   GLenum (*RenderObjectPurgeable)( GLcontext *ctx, struct gl_renderbuffer *obj, GLenum option );
+   GLenum (*TextureObjectPurgeable)( GLcontext *ctx, struct gl_texture_object *obj, GLenum option );
+
+   /* variations on ObjectUnpurgeable */
+   GLenum (*BufferObjectUnpurgeable)( GLcontext *ctx, struct gl_buffer_object *obj, GLenum option );
+   GLenum (*RenderObjectUnpurgeable)( GLcontext *ctx, struct gl_renderbuffer *obj, GLenum option );
+   GLenum (*TextureObjectUnpurgeable)( GLcontext *ctx, struct gl_texture_object *obj, GLenum option );
+   /*@}*/
+#endif
+
+   /**
     * \name Functions for GL_EXT_framebuffer_object
     */
 #if FEATURE_EXT_framebuffer_object
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 673db30..43aadb1 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -9285,6 +9285,12 @@ _mesa_init_save_table(struct _glapi_table *table)
    /* 364. GL_EXT_provoking_vertex */
    SET_ProvokingVertexEXT(table, save_ProvokingVertexEXT);
 
+   /* 371. GL_APPLE_object_purgeable */
+#if FEATURE_APPLE_object_purgeable
+   SET_ObjectPurgeableAPPLE(table, _mesa_ObjectPurgeableAPPLE);
+   SET_ObjectUnpurgeableAPPLE(table, _mesa_ObjectUnpurgeableAPPLE);
+#endif
+
    /* GL 3.0 */
 #if 0
    SET_ClearBufferiv(table, save_ClearBufferiv);
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 0e7e52a..30245d6 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -153,6 +153,7 @@ static const struct {
    { OFF, "GL_APPLE_client_storage",           F(APPLE_client_storage) },
    { ON,  "GL_APPLE_packed_pixels",            F(APPLE_packed_pixels) },
    { OFF, "GL_APPLE_vertex_array_object",      F(APPLE_vertex_array_object) },
+   { OFF, "GL_APPLE_object_purgeable",         F(APPLE_object_purgeable) },
    { OFF, "GL_ATI_blend_equation_separate",    F(EXT_blend_equation_separate) },
    { OFF, "GL_ATI_envmap_bumpmap",             F(ATI_envmap_bumpmap) },
    { OFF, "GL_ATI_texture_env_combine3",       F(ATI_texture_env_combine3)},
@@ -265,6 +266,9 @@ _mesa_enable_sw_extensions(GLcontext *ctx)
    ctx->Extensions.ARB_sync = GL_TRUE;
 #endif
    ctx->Extensions.APPLE_vertex_array_object = GL_TRUE;
+#if FEATURE_APPLE_object_purgeable
+   ctx->Extensions.APPLE_object_purgeable = GL_TRUE;
+#endif
    ctx->Extensions.ATI_envmap_bumpmap = GL_TRUE;
 #if FEATURE_ATI_fragment_shader
    ctx->Extensions.ATI_fragment_shader = GL_TRUE;
diff --git a/src/mesa/main/mfeatures.h b/src/mesa/main/mfeatures.h
index f0896ee..cb96c4d 100644
--- a/src/mesa/main/mfeatures.h
+++ b/src/mesa/main/mfeatures.h
@@ -116,6 +116,7 @@
 #define FEATURE_EXT_framebuffer_blit _HAVE_FULL_GL
 #define FEATURE_EXT_framebuffer_object _HAVE_FULL_GL
 #define FEATURE_EXT_pixel_buffer_object  _HAVE_FULL_GL
+#define FEATURE_APPLE_object_purgeable _HAVE_FULL_GL
 #define FEATURE_EXT_texture_sRGB _HAVE_FULL_GL
 #define FEATURE_ATI_fragment_shader _HAVE_FULL_GL
 #define FEATURE_NV_fence  _HAVE_FULL_GL
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 4d55ebb..9d9b475 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1244,6 +1244,7 @@ struct gl_texture_object
    GLboolean GenerateMipmap;    /**< GL_SGIS_generate_mipmap */
    GLboolean _Complete;		/**< Is texture object complete? */
    GLboolean _RenderToTexture;  /**< Any rendering to this texture? */
+   GLboolean Purgeable;         /**< Is the buffer purgeable under memory pressure? */
 
    /** Actual texture images, indexed by [cube face] and [mipmap level] */
    struct gl_texture_image *Image[MAX_FACES][MAX_TEXTURE_LEVELS];
@@ -1439,6 +1440,7 @@ struct gl_buffer_object
    GLsizeiptr Length;   /**< Mapped length */
    /*@}*/
    GLboolean Written;   /**< Ever written to? (for debugging) */
+   GLboolean Purgeable; /**< Is the buffer purgeable under memory pressure? */
 };
 
 
@@ -2104,6 +2106,7 @@ struct gl_renderbuffer
    GLuint Name;
    GLint RefCount;
    GLuint Width, Height;
+   GLboolean Purgeable;   /**< Is the buffer purgeable under memory pressure? */
 
    GLenum InternalFormat; /**< The user-specified format */
    GLenum _BaseFormat;    /**< Either GL_RGB, GL_RGBA, GL_DEPTH_COMPONENT or
@@ -2491,6 +2494,7 @@ struct gl_extensions
    GLboolean APPLE_client_storage;
    GLboolean APPLE_packed_pixels;
    GLboolean APPLE_vertex_array_object;
+   GLboolean APPLE_object_purgeable;
    GLboolean ATI_envmap_bumpmap;
    GLboolean ATI_texture_mirror_once;
    GLboolean ATI_texture_env_combine3;
-- 
1.7.0

[Mesa3d-dev] [PATCH 4/4] APPLE_object_purgeable: intel

[Chris W. <ch...@ch...>]

Implement support for purgeable objects by using the GEM madvise ioctl.

Signed-off-by: Chris Wilson <ch...@ch...>
---
 src/mesa/drivers/dri/intel/intel_buffer_objects.c |  134 ++++++++++++++++++++-
 src/mesa/drivers/dri/intel/intel_extensions.c     |    3 +
 2 files changed, 136 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_buffer_objects.c b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
index 312866d..7599bea 100644
--- a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
+++ b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
@@ -31,10 +31,12 @@
 #include "main/macros.h"
 #include "main/bufferobj.h"
 
-#include "intel_context.h"
 #include "intel_blit.h"
 #include "intel_buffer_objects.h"
 #include "intel_batchbuffer.h"
+#include "intel_context.h"
+#include "intel_fbo.h"
+#include "intel_mipmap_tree.h"
 #include "intel_regions.h"
 
 static GLboolean
@@ -588,6 +590,126 @@ intel_bufferobj_copy_subdata(GLcontext *ctx,
    intel_batchbuffer_emit_mi_flush(intel->batch);
 }
 
+#if FEATURE_APPLE_object_purgeable
+static GLenum
+intel_buffer_purgeable(GLcontext * ctx,
+                       drm_intel_bo *buffer,
+                       GLenum option)
+{
+   int retained = 0;
+
+   if (buffer != NULL)
+      retained = drm_intel_bo_madvise (buffer, I915_MADV_DONTNEED);
+
+   return retained ? GL_VOLATILE_APPLE : GL_RELEASED_APPLE;
+}
+
+static GLenum
+intel_buffer_object_purgeable(GLcontext * ctx,
+                              struct gl_buffer_object *obj,
+                              GLenum option)
+{
+   struct intel_buffer_object *intel;
+
+   intel = intel_buffer_object (obj);
+   if (intel->buffer != NULL)
+      return intel_buffer_purgeable (ctx, intel->buffer, option);
+
+   if (option == GL_RELEASED_APPLE) {
+      if (intel->sys_buffer != NULL) {
+         free(intel->sys_buffer);
+         intel->sys_buffer = NULL;
+      }
+
+      return GL_RELEASED_APPLE;
+   } else {
+      /* XXX Create the buffer and madvise(MADV_DONTNEED)? */
+      return intel_buffer_purgeable (ctx,
+                                     intel_bufferobj_buffer(intel_context(ctx),
+                                                            intel, INTEL_READ),
+                                     option);
+   }
+}
+
+static GLenum
+intel_texture_object_purgeable(GLcontext * ctx,
+                               struct gl_texture_object *obj,
+                               GLenum option)
+{
+   struct intel_texture_object *intel;
+
+   intel = intel_texture_object(obj);
+   if (intel->mt == NULL || intel->mt->region == NULL)
+      return GL_RELEASED_APPLE;
+
+   return intel_buffer_purgeable (ctx, intel->mt->region->buffer, option);
+}
+
+static GLenum
+intel_render_object_purgeable(GLcontext * ctx,
+                              struct gl_renderbuffer *obj,
+                              GLenum option)
+{
+   struct intel_renderbuffer *intel;
+
+   intel = intel_renderbuffer(obj);
+   if (intel->region == NULL)
+      return GL_RELEASED_APPLE;
+
+   return intel_buffer_purgeable (ctx, intel->region->buffer, option);
+}
+
+static GLenum
+intel_buffer_unpurgeable(GLcontext * ctx,
+                         drm_intel_bo *buffer,
+                         GLenum option)
+{
+   int retained;
+
+   retained = 0;
+   if (buffer != NULL)
+      retained = drm_intel_bo_madvise (buffer, I915_MADV_WILLNEED);
+
+   return retained ? GL_RETAINED_APPLE : GL_UNDEFINED_APPLE;
+}
+
+static GLenum
+intel_buffer_object_unpurgeable(GLcontext * ctx,
+                                struct gl_buffer_object *obj,
+                                GLenum option)
+{
+   return intel_buffer_unpurgeable (ctx, intel_buffer_object (obj)->buffer, option);
+}
+
+static GLenum
+intel_texture_object_unpurgeable(GLcontext * ctx,
+                                 struct gl_texture_object *obj,
+                                 GLenum option)
+{
+   struct intel_texture_object *intel;
+
+   intel = intel_texture_object(obj);
+   if (intel->mt == NULL || intel->mt->region == NULL)
+      return GL_UNDEFINED_APPLE;
+
+   return intel_buffer_unpurgeable (ctx, intel->mt->region->buffer, option);
+}
+
+static GLenum
+intel_render_object_unpurgeable(GLcontext * ctx,
+                                struct gl_renderbuffer *obj,
+                                GLenum option)
+{
+   struct intel_renderbuffer *intel;
+
+   intel = intel_renderbuffer(obj);
+   if (intel->region == NULL)
+      return GL_UNDEFINED_APPLE;
+
+   return intel_buffer_unpurgeable (ctx, intel->region->buffer, option);
+}
+#endif
+
 void
 intelInitBufferObjectFuncs(struct dd_function_table *functions)
 {
@@ -601,4 +723,14 @@ intelInitBufferObjectFuncs(struct dd_function_table *functions)
    functions->FlushMappedBufferRange = intel_bufferobj_flush_mapped_range;
    functions->UnmapBuffer = intel_bufferobj_unmap;
    functions->CopyBufferSubData = intel_bufferobj_copy_subdata;
+
+#if FEATURE_APPLE_object_purgeable
+   functions->BufferObjectPurgeable = intel_buffer_object_purgeable;
+   functions->TextureObjectPurgeable = intel_texture_object_purgeable;
+   functions->RenderObjectPurgeable = intel_render_object_purgeable;
+
+   functions->BufferObjectUnpurgeable = intel_buffer_object_unpurgeable;
+   functions->TextureObjectUnpurgeable = intel_texture_object_unpurgeable;
+   functions->RenderObjectUnpurgeable = intel_render_object_unpurgeable;
+#endif
 }
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c b/src/mesa/drivers/dri/intel/intel_extensions.c
index e16c33b..a1aac69 100644
--- a/src/mesa/drivers/dri/intel/intel_extensions.c
+++ b/src/mesa/drivers/dri/intel/intel_extensions.c
@@ -58,6 +58,7 @@
 #define need_GL_EXT_secondary_color
 #define need_GL_EXT_stencil_two_side
 #define need_GL_APPLE_vertex_array_object
+#define need_GL_APPLE_object_purgeable
 #define need_GL_ATI_separate_stencil
 #define need_GL_ATI_envmap_bumpmap
 #define need_GL_NV_point_sprite
@@ -121,6 +122,7 @@ static const struct dri_extension card_extensions[] = {
    { "GL_EXT_texture_lod_bias",           NULL },
    { "GL_3DFX_texture_compression_FXT1",  NULL },
    { "GL_APPLE_client_storage",           NULL },
+   { "GL_APPLE_object_purgeable",         GL_APPLE_object_purgeable_functions },
    { "GL_APPLE_vertex_array_object",      GL_APPLE_vertex_array_object_functions},
    { "GL_MESA_pack_invert",               NULL },
    { "GL_MESA_ycbcr_texture",             NULL },
@@ -182,6 +184,7 @@ static const struct dri_extension arb_oq_extensions[] = {
    { NULL, NULL }
 };
 
+
 static const struct dri_extension fragment_shader_extensions[] = {
    { "GL_ARB_fragment_shader",            NULL },
    { NULL, NULL }
-- 
1.7.0

[Mesa3d-dev] [Bug 26904] New: undefined symbol: GLwCreateM2DrawingArea

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26904

           Summary: undefined symbol: GLwCreateM2DrawingArea
           Product: Mesa
           Version: 6.5
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: pa...@ge...


I have an OpenGL application that uses the function GLwCreateMDrawingArea and
the libGLw libraries. When the application is run on RH5.4 it works fine. When
the application is run on Fedora 12, it crashes with undefined symbol:
GLwCreateM2DrawingArea. On examination of the /usr/lib/libGLw.so.1.0.0 library
on both RH5.4 & Fedora12, I can see that the GLwCreateM2DrawingArea routines
are missing from the library.

If I replace the Fedora12 libraries with the RH5.4 libraries then my app runs
fine.

On RH5.4 I have package mesa-libGLw-devel-6.5.1-7.7.el5 installed.

On Fedora 12, I have package mesa-libGLw-devel-6.5.1-8.fc12.i686 installed

I have 2 questions:

1. My concern is that on RH5.4 in a next release I could lose the
GLwCreateMDrawingArea functionality, and so is this something that may be
being depreciated. In which case do I need to implement an alternative?

2. Is this is bug in Fedora 12?

Thanks, Paul.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] Mesa (master): glsl/pp: Add asserts to check for null pointer deferences.

[Luca B. <luc...@gm...>]

Yes, from the text you quoted it seems it was indeed incorrect.
However, it almost surely ran on any common platform, and the added
assert introduced a bug because it would trip for valid usage.

My point is that the incorrectness of the patch (and the fact that the
if above that place checking for the variable being non-null was not
removed in that same patch) suggests that whether that variable could
actually be null or not was not manually evaluated, which, if actually
the case, kind of seems to defeat the purpose of doing static analysis
in the first place and seems to be counterproductive by possibly
hiding errors from further static analysis.

Of course, that is not supposed to detract from the appreciation that
such code analysis work deserves.

Re: [Mesa3d-dev] Mesa (master): glsl/pp: Add asserts to check for null pointer deferences.

[Vinson L. <vl...@vm...>]

> -----Original Message-----
> 
> BTW, I just looked at one of the assert commits, and found it actually
> _introduces_ a bug.
> Look at the assert(attrib_list) added in
> 706fffbff59be0dc884e1938f1bdf731af1efa3e.
> 
> This ends up asserting that the attrib_list in glXCreatePixmap is not
> NULL.
> But the GLX specification says that it can be NULL, and it will usually
> be.
> 
> The memcpy does not crash because when attrib_list is NULL, the length
> parameter passed to it is 0, as the code before shows.
> 
> Thus, that commit should be reverted, and replaced with either no
> change or by surrounding the memcpy with if(attrib_list) or if(i) .
> Ideally, we could also mark the if, as well as the if(attrib_list)
> above with unlikely() while we are at it.
> 

Whether this was a bug or not is subject to interpretation of the C specification.

While it doesn't explicitly state so, a reading of the C99 specification sections 7.1.4 (Use of Library functions) and 7.21.1 (String function conventions) suggests that 'memcpy(dst, NULL, 0)' is undefined behavior.

<quote>
7.21.1 String function conventions
Where an argument declared as size_t n specifies the length of the array for a function, n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values, as described in 7.1.4. On such a call, a function that locates a character finds no occurrence, a function that compares two character sequences returns zero, and a function that copies characters copies zero characters.
</quote>

Re: [Mesa3d-dev] Mesa (master): glsl/pp: Add asserts to check for null pointer deferences.

[Luca B. <luc...@gm...>]

Just noticed that has already been fixed in
5f40a7aed12500fd6792e2453f495555c3b5c54d with an if(attrib_list).

Re: [Mesa3d-dev] Mesa (master): glsl/pp: Add asserts to check for null pointer deferences.

[Luca B. <luc...@gm...>]

> For static analysis with Coverity Prevent, the added assert will clear a defect report and/or allow it to continue parsing to the next possible defect.

Are these being checked manually and determined to be false positives?
If not, then it would be beneficial to not shut up static analysis,
since it actually could be a problem.
If yes, perhaps it would be useful to have a comment explaining why it
is not a false positive, unless the reasoning is often trivial, which
means that the static analyzer isn't doing a very good job.

Also, is the whole concept of having a static analyzer assume that
asserts are true a good idea?
Shouldn't it instead specifically attempt to check whether the
assertions in the code are always true? (and have some other means to
flag false positives, perhaps not involving source modification)

Finally, does the checker provide some easy and license-allowed way of
making the analysis results public? (e.g. by putting up the same web
interface they used for their open source checking demos)

BTW, I just looked at one of the assert commits, and found it actually
_introduces_ a bug.
Look at the assert(attrib_list) added in
706fffbff59be0dc884e1938f1bdf731af1efa3e.

This ends up asserting that the attrib_list in glXCreatePixmap is not NULL.
But the GLX specification says that it can be NULL, and it will usually be.

The memcpy does not crash because when attrib_list is NULL, the length
parameter passed to it is 0, as the code before shows.

Thus, that commit should be reverted, and replaced with either no
change or by surrounding the memcpy with if(attrib_list) or if(i) .
Ideally, we could also mark the if, as well as the if(attrib_list)
above with unlikely() while we are at it.

Are we sure all the other commits like this are correct and actually
flag false positives, as opposed to hiding real bugs?

Re: [Mesa3d-dev] Mesa (master): mesa: Remove pointless comparison of unsigned integer with a negative constant.

[Brian P. <br...@vm...>]

Vinson Lee wrote:
>> -----Original Message-----
>>
>>> mesa: Remove pointless comparison of unsigned integer with a negative
>> constant.
>>> ---
>>>
>>>  src/mesa/shader/prog_execute.c |   13 ++++---------
>>>  1 files changed, 4 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/src/mesa/shader/prog_execute.c
>> b/src/mesa/shader/prog_execute.c
>>> index aea4b07..ee422e7 100644
>>> --- a/src/mesa/shader/prog_execute.c
>>> +++ b/src/mesa/shader/prog_execute.c
>>> @@ -1780,15 +1780,10 @@ _mesa_execute_program(GLcontext * ctx,
>>>           break;
>>>        case OPCODE_PRINT:
>>>           {
>>> -            if (inst->SrcReg[0].File != -1) {
>>> -               GLfloat a[4];
>>> -               fetch_vector4(&inst->SrcReg[0], machine, a);
>>> -               _mesa_printf("%s%g, %g, %g, %g\n", (const char *) inst-
>>> Data,
>>> -                            a[0], a[1], a[2], a[3]);
>>> -            }
>>> -            else {
>>> -               _mesa_printf("%s\n", (const char *) inst->Data);
>>> -            }
>>> +            GLfloat a[4];
>>> +            fetch_vector4(&inst->SrcReg[0], machine, a);
>>> +            _mesa_printf("%s%g, %g, %g, %g\n", (const char *) inst-
>>> Data,
>>> +                         a[0], a[1], a[2], a[3]);
>> I don't think this is correct.  The shader assembler used to set the
>> register file to -1 to note the difference between the following two
>> instructions:
>>
>> 	PRINT	"Hello, world";
>> 	PRINT	"vertex color", color;
>>
>> Even if comparing with -1 isn't entirely correct, removing the code
>> altogether is clearly wrong.
>>
>>>           }
>>>           break;
>>>        case OPCODE_END:
> 
> Where is the set of the register file to -1?

At nvvertparse.c:1099 it's set to zero.  I don't see where it's set to 
-1 either.


> Should the -1 comparison been against PROGRAM_FILE_MAX or PROGRAM_UNDEFINED instead?

The assignment above should probably use PROGRAM_UNDEFINED instead of 0.

-Brian

Re: [Mesa3d-dev] Mesa (master): mesa: Remove pointless comparison of unsigned integer with a negative constant.

[Vinson L. <vl...@vm...>]

> -----Original Message-----
> 
> >
> > mesa: Remove pointless comparison of unsigned integer with a negative
> constant.
> >
> > ---
> >
> >  src/mesa/shader/prog_execute.c |   13 ++++---------
> >  1 files changed, 4 insertions(+), 9 deletions(-)
> >
> > diff --git a/src/mesa/shader/prog_execute.c
> b/src/mesa/shader/prog_execute.c
> > index aea4b07..ee422e7 100644
> > --- a/src/mesa/shader/prog_execute.c
> > +++ b/src/mesa/shader/prog_execute.c
> > @@ -1780,15 +1780,10 @@ _mesa_execute_program(GLcontext * ctx,
> >           break;
> >        case OPCODE_PRINT:
> >           {
> > -            if (inst->SrcReg[0].File != -1) {
> > -               GLfloat a[4];
> > -               fetch_vector4(&inst->SrcReg[0], machine, a);
> > -               _mesa_printf("%s%g, %g, %g, %g\n", (const char *) inst-
> >Data,
> > -                            a[0], a[1], a[2], a[3]);
> > -            }
> > -            else {
> > -               _mesa_printf("%s\n", (const char *) inst->Data);
> > -            }
> > +            GLfloat a[4];
> > +            fetch_vector4(&inst->SrcReg[0], machine, a);
> > +            _mesa_printf("%s%g, %g, %g, %g\n", (const char *) inst-
> >Data,
> > +                         a[0], a[1], a[2], a[3]);
> 
> I don't think this is correct.  The shader assembler used to set the
> register file to -1 to note the difference between the following two
> instructions:
> 
> 	PRINT	"Hello, world";
> 	PRINT	"vertex color", color;
> 
> Even if comparing with -1 isn't entirely correct, removing the code
> altogether is clearly wrong.
> 
> >           }
> >           break;
> >        case OPCODE_END:
> 

Where is the set of the register file to -1?

Should the -1 comparison been against PROGRAM_FILE_MAX or PROGRAM_UNDEFINED instead?

[Mesa3d-dev] [PATCH][RFC] V2 porting code from old nouveau driver?

[<ran...@gm...>]

still not working/not plugged in......

What i need to do about lack of

->new_state and  ->current_primitive in ctx ?

[Mesa3d-dev] [PATCH] GLX: only enable OML sync if supported

[Jesse B. <jb...@vi...>]

Ian, maybe there's a better way to do this?

We need to enable OML_sync_control only if supported, now that we can
actually support it, otherwise old userspace depending on the somewhat
broken old behavior will break.

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 29d589c..d69bb32 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -614,6 +614,7 @@ dri2CreateScreen(__GLXscreenConfigs * psc, int screen,
       psp->setSwapInterval = dri2SetSwapInterval;
       psp->getSwapInterval = dri2GetSwapInterval;
 #endif
+      __glXEnableExtension(psc, "GLX_OML_sync_control");
    }
 
    /* DRI2 suports SubBuffer through DRI2CopyRegion, so it's always
diff --git a/src/glx/glxextensions.c b/src/glx/glxextensions.c
index 56c69cb..1f19ac1 100644
--- a/src/glx/glxextensions.c
+++ b/src/glx/glxextensions.c
@@ -90,7 +90,7 @@ static const struct extension_info known_glx_extensions[] = {
    { GLX(NV_render_texture_rectangle), VER(0,0), N, N, N, N },
    { GLX(NV_vertex_array_range),       VER(0,0), N, N, N, Y }, /* Deprecated */
    { GLX(OML_swap_method),             VER(0,0), Y, Y, N, N },
-   { GLX(OML_sync_control),            VER(0,0), Y, N, N, Y },
+   { GLX(OML_sync_control),            VER(0,0), N, N, N, N },
    { GLX(SGI_make_current_read),       VER(1,3), Y, N, N, N },
    { GLX(SGI_swap_control),            VER(0,0), Y, N, N, N },
    { GLX(SGI_video_sync),              VER(0,0), Y, N, N, Y },
@@ -371,6 +371,18 @@ __glXEnableDirectExtension(__GLXscreenConfigs * psc, const char *name)
                      name, strlen(name), GL_TRUE, psc->direct_support);
 }
 
+void
+__glXEnableExtension(__GLXscreenConfigs * psc, const char *name)
+{
+   __glXExtensionsCtr();
+   __glXExtensionsCtrScreen(psc);
+
+   set_glx_extension(known_glx_extensions,
+                     name, strlen(name), GL_TRUE, psc->direct_support);
+   set_glx_extension(known_glx_extensions,
+                     name, strlen(name), GL_TRUE, client_glx_support);
+}
+
 /**
  * Initialize global extension support tables.
  */
diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
index f556b12..f9f4ddd 100644
--- a/src/glx/glxextensions.h
+++ b/src/glx/glxextensions.h
@@ -259,6 +259,8 @@ extern GLboolean __glExtensionBitIsEnabled(const struct __GLXcontextRec *gc,
 extern void
 __glXEnableDirectExtension(struct __GLXscreenConfigsRec *psc,
                            const char *name);
+extern void
+__glXEnableExtension(struct __GLXscreenConfigsRec *psc, const char *name);
 
 /* Source-level backwards compatibility with old drivers. They won't
  * find the respective functions, though. 

Re: [Mesa3d-dev] Mesa (master): glsl/pp: Add asserts to check for null pointer deferences.

[Vinson L. <vl...@vm...>]

> -----Original Message-----
> From: Ian Romanick [mailto:id...@fr...]
> Sent: Thursday, March 04, 2010 3:17 PM
> To: mesa3d-dev
> Subject: Re: [Mesa3d-dev] Mesa (master): glsl/pp: Add asserts to check for
> null pointer deferences.
> 
> 
> What is the benefit of adding all these NULL pointer assertions?  I
> don't see a big benefit of an assertion failure vs. a segfault.
> 
> I'm just curious.

For static analysis with Coverity Prevent, the added assert will clear a defect report and/or allow it to continue parsing to the next possible defect.

Re: [Mesa3d-dev] Mesa (master): mesa: Remove pointless comparison of unsigned integer with a negative constant.

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vinson Lee wrote:
> Module: Mesa
> Branch: master
> Commit: a05fdbcb719ac64e6be842372813f0f4ca2f4f93
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=a05fdbcb719ac64e6be842372813f0f4ca2f4f93
> 
> Author: Vinson Lee <vl...@vm...>
> Date:   Mon Feb 15 02:01:20 2010 -0800
> 
> mesa: Remove pointless comparison of unsigned integer with a negative constant.
> 
> ---
> 
>  src/mesa/shader/prog_execute.c |   13 ++++---------
>  1 files changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/src/mesa/shader/prog_execute.c b/src/mesa/shader/prog_execute.c
> index aea4b07..ee422e7 100644
> --- a/src/mesa/shader/prog_execute.c
> +++ b/src/mesa/shader/prog_execute.c
> @@ -1780,15 +1780,10 @@ _mesa_execute_program(GLcontext * ctx,
>           break;
>        case OPCODE_PRINT:
>           {
> -            if (inst->SrcReg[0].File != -1) {
> -               GLfloat a[4];
> -               fetch_vector4(&inst->SrcReg[0], machine, a);
> -               _mesa_printf("%s%g, %g, %g, %g\n", (const char *) inst->Data,
> -                            a[0], a[1], a[2], a[3]);
> -            }
> -            else {
> -               _mesa_printf("%s\n", (const char *) inst->Data);
> -            }
> +            GLfloat a[4];
> +            fetch_vector4(&inst->SrcReg[0], machine, a);
> +            _mesa_printf("%s%g, %g, %g, %g\n", (const char *) inst->Data,
> +                         a[0], a[1], a[2], a[3]);

I don't think this is correct.  The shader assembler used to set the
register file to -1 to note the difference between the following two
instructions:

	PRINT	"Hello, world";
	PRINT	"vertex color", color;

Even if comparing with -1 isn't entirely correct, removing the code
altogether is clearly wrong.

>           }
>           break;
>        case OPCODE_END:

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

iEYEARECAAYFAkuQQEoACgkQX1gOwKyEAw+muQCfW7svf52FFKJZQmmj9l9FKmsA
qMoAn0iToPAecT/vhsrmqutoXm0h2ZXI
=nSOS
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Jesse B. <jb...@vi...>]

On Fri, 05 Mar 2010 00:16:45 +0100
Michel Dänzer <mi...@da...> wrote:

> On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote: 
> > Jesse Barnes wrote:
> > > Would anyone have objections if these lists moved to freedesktop.org?
> > > The recent thread with Linus about the drm pull request highlights the
> > > post lag and non-subscriber aspect of the current lists, and that
> > > leaves aside sf.net's horrible mail archive interface and poor
> > > performance.
> > > 
> > > If spam is an issue, another option would be vger.kernel.org.  That
> > > team runs lkml and several other very high traffic, high profile lists
> > > and manages quite well; performance is always high and spam is nearly
> > > non-existent given the amount of traffic.
> > 
> > Jesse, can you set up the new lists?  Or does someone else need to do 
> > that?
> > 
> > I can send you (or whoever) the current subscriber lists.
> 
> Ditto for dri-devel.
> 
> > BTW, I'm the current admin for the Mesa lists on SourceForge.  I 
> > manually unsubscribe people who can't figure it out for themselves, 
> > allow posts from non-members (sometimes), etc.  I'd gladly pass on 
> > that responsibility to someone else.  Would that automatically become 
> > the job of the current fd.o admins?
> 
> Not really, the lists should still have their own admins.
> 
> I've been going through the moderation queues for both lists on a daily
> basis and am volunteering to continue doing so, but other than that I'm
> not really keen on being a list admin.

I don't have access to create the new lists, but Daniel or Tollef
should.

We may as well keep you guys as admins unless someone volunteers that
you're ok with; but hopefully FDO will make the admin job a little
easier/faster.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Mesa3d-dev] Mesa (master): mesa: Fix unsigned comparison.

[Michel D. <mi...@da...>]

On Thu, 2010-03-04 at 13:56 -0700, Brian Paul wrote: 
> Michel Dänzer wrote:
> > On Thu, 2010-03-04 at 02:00 -0800, Vinson Lee wrote: 
> >> Michel, thanks for spotting this.
> >>
> >> I've reverted the bad commit. Please go ahead and submit your correct fix.
> > 
> > Actually, I wonder if something like the below isn't needed to avoid any
> > undesired effects from integer overflows.
> > 
> > 
> > diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
> > index 326ad6f..8460265 100644
> > --- a/src/mesa/main/api_validate.c
> > +++ b/src/mesa/main/api_validate.c
> > @@ -130,6 +130,7 @@ check_index_bounds(GLcontext *ctx, GLsizei count, GLenum type,
> >     struct _mesa_prim prim;
> >     struct _mesa_index_buffer ib;
> >     GLuint min, max;
> > +   GLint64 min64, max64;
> >  
> >     /* Only the X Server needs to do this -- otherwise, accessing outside
> >      * array/BO bounds allows application termination.
> > @@ -146,9 +147,12 @@ check_index_bounds(GLcontext *ctx, GLsizei count, GLenum type,
> >     ib.obj = ctx->Array.ElementArrayBufferObj;
> >  
> >     vbo_get_minmax_index(ctx, &prim, &ib, &min, &max);
> > +   min64 = min;
> > +   min64 += basevertex;
> > +   max64 = max;
> > +   max64 += basevertex;
> >  
> > -   if (min + basevertex < 0 ||
> > -       max + basevertex > ctx->Array.ArrayObj->_MaxElement) {
> > +   if (min64 < 0 || max64 > ctx->Array.ArrayObj->_MaxElement) {
> >        /* the max element is out of bounds of one or more enabled arrays */
> >        _mesa_warning(ctx, "glDrawElements() index=%u is "
> >  		    "out of bounds (max=%u)", max, ctx->Array.ArrayObj->_MaxElement);
> 
> I'd be happy with a simple cast for now.  One of these days we'll need 
> to be concerned with 4GB buffers (or 2GB buffers and signed 
> arithmetic) but we're not quite there yet.  There'd probably be other 
> issues to fix.  The buffer object code will need to be audited.

Okay cast pushed, thanks for the feedback.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mesa3d-dev] Mesa (master): glsl/pp: Add asserts to check for null pointer deferences.

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What is the benefit of adding all these NULL pointer assertions?  I
don't see a big benefit of an assertion failure vs. a segfault.

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

iEYEARECAAYFAkuQP1UACgkQX1gOwKyEAw8CSQCbBAGG+fv6I2nVsEnTPqz7ZCUZ
CygAn1UCENMoomI7305dNA8FiiAJLtGj
=2Cl+
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Stephane M. <ste...@gm...>]

On Thu, Mar 4, 2010 at 15:09, Brian Paul <br...@vm...> wrote:
> Jesse Barnes wrote:
>> Would anyone have objections if these lists moved to freedesktop.org?
>> The recent thread with Linus about the drm pull request highlights the
>> post lag and non-subscriber aspect of the current lists, and that
>> leaves aside sf.net's horrible mail archive interface and poor
>> performance.
>>

Also I've been banned from posting to the lists at sf.net in the past
because my smtp server was in their (wrong) RBLs. So I'm happy if the
lists are moving away.

>> If spam is an issue, another option would be vger.kernel.org.  That
>> team runs lkml and several other very high traffic, high profile lists
>> and manages quite well; performance is always high and spam is nearly
>> non-existent given the amount of traffic.
>
> Jesse, can you set up the new lists?  Or does someone else need to do
> that?
>
> I can send you (or whoever) the current subscriber lists.
>
> BTW, I'm the current admin for the Mesa lists on SourceForge.  I
> manually unsubscribe people who can't figure it out for themselves,
> allow posts from non-members (sometimes), etc.  I'd gladly pass on
> that responsibility to someone else.  Would that automatically become
> the job of the current fd.o admins?
>

No, you still have the mailman interface to handle all this.

Stephane

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Michel D. <mi...@da...>]

On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote: 
> Jesse Barnes wrote:
> > Would anyone have objections if these lists moved to freedesktop.org?
> > The recent thread with Linus about the drm pull request highlights the
> > post lag and non-subscriber aspect of the current lists, and that
> > leaves aside sf.net's horrible mail archive interface and poor
> > performance.
> > 
> > If spam is an issue, another option would be vger.kernel.org.  That
> > team runs lkml and several other very high traffic, high profile lists
> > and manages quite well; performance is always high and spam is nearly
> > non-existent given the amount of traffic.
> 
> Jesse, can you set up the new lists?  Or does someone else need to do 
> that?
> 
> I can send you (or whoever) the current subscriber lists.

Ditto for dri-devel.

> BTW, I'm the current admin for the Mesa lists on SourceForge.  I 
> manually unsubscribe people who can't figure it out for themselves, 
> allow posts from non-members (sometimes), etc.  I'd gladly pass on 
> that responsibility to someone else.  Would that automatically become 
> the job of the current fd.o admins?

Not really, the lists should still have their own admins.

I've been going through the moderation queues for both lists on a daily
basis and am volunteering to continue doing so, but other than that I'm
not really keen on being a list admin.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Brian P. <br...@vm...>]

Jesse Barnes wrote:
> Would anyone have objections if these lists moved to freedesktop.org?
> The recent thread with Linus about the drm pull request highlights the
> post lag and non-subscriber aspect of the current lists, and that
> leaves aside sf.net's horrible mail archive interface and poor
> performance.
> 
> If spam is an issue, another option would be vger.kernel.org.  That
> team runs lkml and several other very high traffic, high profile lists
> and manages quite well; performance is always high and spam is nearly
> non-existent given the amount of traffic.

Jesse, can you set up the new lists?  Or does someone else need to do 
that?

I can send you (or whoever) the current subscriber lists.

BTW, I'm the current admin for the Mesa lists on SourceForge.  I 
manually unsubscribe people who can't figure it out for themselves, 
allow posts from non-members (sometimes), etc.  I'd gladly pass on 
that responsibility to someone else.  Would that automatically become 
the job of the current fd.o admins?

-Brian

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Jesse B. <jb...@vi...>]

On Thu, 4 Mar 2010 14:55:29 -0800
Dan Nicholson <dbn...@gm...> wrote:

> On Thu, Mar 4, 2010 at 2:42 PM, Eric Anholt <er...@an...> wrote:
> > On Thu, 4 Mar 2010 12:37:23 -0800, Jesse Barnes <jb...@vi...> wrote:
> >> Would anyone have objections if these lists moved to freedesktop.org?
> >> The recent thread with Linus about the drm pull request highlights the
> >> post lag and non-subscriber aspect of the current lists, and that
> >> leaves aside sf.net's horrible mail archive interface and poor
> >> performance.
> >>
> >> If spam is an issue, another option would be vger.kernel.org.  That
> >> team runs lkml and several other very high traffic, high profile lists
> >> and manages quite well; performance is always high and spam is nearly
> >> non-existent given the amount of traffic.
> >
> > sf.net's mail interface is made of fail.  Here's to changing to
> > something credible.
> 
> The funny thing about it is they're clearly using mailman, which has
> an archives interface, but they felt the need to implement some dog
> slow php forum-like interface over it. Why?

And their delivery is really slow too, which is quite annoying for
active discussions.

I guess Brian or Michel could get the current subscriber lists and
transfer them over once we have the new lists.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Dan N. <dbn...@gm...>]

On Thu, Mar 4, 2010 at 2:42 PM, Eric Anholt <er...@an...> wrote:
> On Thu, 4 Mar 2010 12:37:23 -0800, Jesse Barnes <jb...@vi...> wrote:
>> Would anyone have objections if these lists moved to freedesktop.org?
>> The recent thread with Linus about the drm pull request highlights the
>> post lag and non-subscriber aspect of the current lists, and that
>> leaves aside sf.net's horrible mail archive interface and poor
>> performance.
>>
>> If spam is an issue, another option would be vger.kernel.org.  That
>> team runs lkml and several other very high traffic, high profile lists
>> and manages quite well; performance is always high and spam is nearly
>> non-existent given the amount of traffic.
>
> sf.net's mail interface is made of fail.  Here's to changing to
> something credible.

The funny thing about it is they're clearly using mailman, which has
an archives interface, but they felt the need to implement some dog
slow php forum-like interface over it. Why?

--
Dan

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Eric A. <er...@an...>]

On Thu, 4 Mar 2010 12:37:23 -0800, Jesse Barnes <jb...@vi...> wrote:
> Would anyone have objections if these lists moved to freedesktop.org?
> The recent thread with Linus about the drm pull request highlights the
> post lag and non-subscriber aspect of the current lists, and that
> leaves aside sf.net's horrible mail archive interface and poor
> performance.
> 
> If spam is an issue, another option would be vger.kernel.org.  That
> team runs lkml and several other very high traffic, high profile lists
> and manages quite well; performance is always high and spam is nearly
> non-existent given the amount of traffic.

sf.net's mail interface is made of fail.  Here's to changing to
something credible.

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Alex D. <ale...@gm...>]

On Thu, Mar 4, 2010 at 3:37 PM, Jesse Barnes <jb...@vi...> wrote:
> Would anyone have objections if these lists moved to freedesktop.org?

Yes please!

> The recent thread with Linus about the drm pull request highlights the
> post lag and non-subscriber aspect of the current lists, and that
> leaves aside sf.net's horrible mail archive interface and poor
> performance.
>
> If spam is an issue, another option would be vger.kernel.org.  That
> team runs lkml and several other very high traffic, high profile lists
> and manages quite well; performance is always high and spam is nearly
> non-existent given the amount of traffic.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> _______________________________________________
> Dri-devel mailing list
> Dri...@li...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Mike S. <mi...@lu...>]

Moving seems like a good idea.  The delays here have been very troubling.

-- 

 Mike Stroyan - Software Architect
 LunarG, Inc.  - The Graphics Experts
 Cell:  (970) 219-7905
 Email: Mi...@Lu...
 Website: http://www.lunarg.com

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Matt T. <mat...@gm...>]

On Thu, Mar 4, 2010 at 3:37 PM, Jesse Barnes <jb...@vi...> wrote:
> Would anyone have objections if these lists moved to freedesktop.org?
> The recent thread with Linus about the drm pull request highlights the
> post lag and non-subscriber aspect of the current lists, and that
> leaves aside sf.net's horrible mail archive interface and poor
> performance.
>
> If spam is an issue, another option would be vger.kernel.org.  That
> team runs lkml and several other very high traffic, high profile lists
> and manages quite well; performance is always high and spam is nearly
> non-existent given the amount of traffic.
>
> --
> Jesse Barnes, Intel Open Source Technology Center

As a user and occasional poster to these lists, that sounds very good to me.

> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev

It'd be nice to get rid of these silly advertisements too.

Matt