date:20131206

[Mesa-dev] [PATCH] Fix line number on no matching function call

2013-12-06 Thread Kevin Rogovin

This (very tiny) patch fixes the bug (#72264) where when 
no matching function call was found the error message
gave the line and column number as 0.

---
 src/glsl/ast_function.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index 6423759..9dc5427 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -1656,7 +1656,7 @@ ast_function_expression::hir(exec_list *instructions,
} else {
   const ast_expression *id = subexpressions[0];
   const char *func_name = id-primary_expression.identifier;
-  YYLTYPE loc = id-get_location();
+  YYLTYPE loc = get_location();
   exec_list actual_parameters;
 
   process_parameters(instructions, actual_parameters, this-expressions,
-- 
1.8.1.2

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

[Mesa-dev] [RFC PATCH] dri megadriver_stub: provide compatibility with older DRI loader

2013-12-06 Thread Jordan Justen

To help the transition period when DRI loaders are being updated
to support the newer __driDriverExtensions_foo mechanism,
we populate __DRIextension with the extensions returned
by __driDriverExtensions_foo during a library contructor
function.

We find the driver foo's name by using the dladdr function
which gives the path of the dynamic library's name that
was being loaded.

Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
Trying to allow Mesa 10 to be loaded by older DRI loaders.

This seems to help glxinfo get the i965 driver if Mesa 10's
i965_dri.so is added to into a Mesa 9.2 libGL stack.

It still needs to be tested more with older X servers.

 src/mesa/drivers/dri/common/megadriver_stub.c | 113 ++
 1 file changed, 113 insertions(+)

diff --git a/src/mesa/drivers/dri/common/megadriver_stub.c 
b/src/mesa/drivers/dri/common/megadriver_stub.c
index 6bf5d73..79d31a9 100644
--- a/src/mesa/drivers/dri/common/megadriver_stub.c
+++ b/src/mesa/drivers/dri/common/megadriver_stub.c
@@ -23,6 +23,119 @@
 
 #include stdio.h
 #include dri_util.h
+#include dlfcn.h
+#include main/macros.h
+
+/* The extensions that allow the megadriver stub to provide backward
+ * compatibility for the older DRI driver loader require GNU
+ * extensions from dlfcn.h.
+ */
+#ifdef _GNU_SOURCE
+
+#define MEGADRIVER_STUB_MAX_EXTENSIONS 10
+
+/* This is the table of extensions that the loader will dlsym() for.
+ *
+ * Initially it is empty for the megadriver stub, but the library
+ * contructor may initialize it based on the name of the library that
+ * is being loaded.
+ */
+PUBLIC const __DRIextension *
+__driDriverExtensions[MEGADRIVER_STUB_MAX_EXTENSIONS] = {
+   NULL
+};
+
+/**
+ * This is a contructor function for the megadriver dynamic library.
+ *
+ * When the driver is dlopen'ed, this function will run. It will
+ * search for the name of the foo_dri.so file that was opened using
+ * the dladdr function.
+ *
+ * After finding foo's name, it will call __driDriverGetExtensions_foo
+ * and use the return to update __driDriverExtensions to achieve
+ * compatibility with older DRI driver loaders.
+ */
+__attribute__((constructor)) static void
+megadriver_stub_init(void)
+{
+   Dl_info info;
+   char *driver_path;
+   char *driver_name;
+   size_t name_len;
+   char *get_extensions_name;
+   const __DRIextension **(*get_extensions)(void);
+   const __DRIextension **extensions;
+   int i;
+
+   i = dladdr((void*) megadriver_stub_init, info);
+   if (i == 0)
+  return;
+
+   driver_path = strdup(info.dli_fname);
+   if (!driver_path)
+  return;
+
+   driver_name = strrchr(driver_path, '/');
+   if (driver_name != NULL) {
+  /* Skip '/' character */
+  driver_name++;
+   } else {
+  /* Try using the start of the path */
+  driver_name = driver_path;
+   }
+
+   /* Make sure the patch ends with _dri.so */
+   name_len = strlen(driver_name);
+   if (strcmp(driver_name + (name_len - 7), _dri.so) != 0) {
+  free(driver_path);
+  return;
+   }
+
+   /* If the path ends with _dri.so, then chop this part of the
+* string off, and then we have the name
+*/
+   driver_name[name_len - 7] = '\0';
+
+   i = asprintf(get_extensions_name, %s_%s,
+__DRI_DRIVER_GET_EXTENSIONS, driver_name);
+   free(driver_path);
+   if (i == -1 || !get_extensions_name)
+  return;
+
+   get_extensions = dlsym(RTLD_DEFAULT, get_extensions_name);
+   free(get_extensions_name);
+   if (!get_extensions)
+  return;
+
+   /* Use the newer DRI loader entrypoint to find extensions.
+* We will then expose these extensions via the older
+* __driDriverExtensions symbol.
+*/
+   extensions = get_extensions();
+
+   /* Copy the extensions into the __driDriverExtensions array
+* we declared.
+*/
+   for (i = 0; i  ARRAY_SIZE(__driDriverExtensions); i++) {
+  __driDriverExtensions[i] = extensions[i];
+  if (extensions[i] == NULL)
+ break;
+   }
+
+   /* If the driver had more extensions that we reserved, then
+* bail out. This will cause the driver to fail to load using
+* the older loader mechanism.
+*/
+   if (extensions[i] != NULL) {
+  __driDriverExtensions[0] = NULL;
+  fprintf(stderr, An updated DRI driver loader (libGL.so or X Server) is 
+  required for this Mesa driver.\n);
+  return;
+   }
+}
+
+#endif // #ifdef _GNU_SOURCE
 
 static const
 __DRIconfig **stub_error_init_screen(__DRIscreen *psp)
-- 
1.8.5.1

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

Re: [Mesa-dev] [PATCH 00/11] Core mesa changes for ARB_shader_image_load_store.

2013-12-06 Thread Francisco Jerez

Paul Berry stereotype...@gmail.com writes:

[...]
 This order of patches introduces temporary build breakages, which I'd
 prefer to avoid if possible.  Here's one order which I've verified works
 (there may be other possibilities):

 [PATCH 03/11] mesa: Add state data structures requried for
 ARB_shader_image_load_store.
 [PATCH 04/11] mesa: Add driver interface for ARB_shader_image_load_store.
 [PATCH 06/11] mesa: Add MESA_FORMAT_ABGR2101010.
 [PATCH 08/11] mesa: Implement the GL entry points defined by
 ARB_shader_image_load_store.
 [PATCH 01/11] glapi: Update dispatch XML files for
 ARB_shader_image_load_store.
 [PATCH 02/11] mesa: Add ARB_shader_image_load_store to the extension table.
 [PATCH 05/11] mesa: Add image parameter queries for
 ARB_shader_image_load_store.
 [PATCH 07/11] mesa: Add MESA_FORMAT_SIGNED_RG88 and _RG1616.
 [PATCH 09/11] mesa: Unbind deleted textures from the shader image units.
 [PATCH 10/11] mesa: Validate image units when the texture state changes.
 [PATCH 11/11] docs: Mark ARB_shader_image_load_store as work in progress.

Thanks Paul, I've adopted your patch ordering in my branch, it should be
fixed now.


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

Re: [Mesa-dev] [PATCH 2/6] glsl: Add ir support for `sample` qualifier; adjust compiler and linker

2013-12-06 Thread Francisco Jerez

Chris Forbes chr...@ijw.co.nz writes:
[...]
 @@ -4662,6 +4673,7 @@ ast_process_structure_or_interface_block(exec_list 
 *instructions,
   fields[i].interpolation =
  interpret_interpolation_qualifier(qual, var_mode, state, loc);
   fields[i].centroid = qual-flags.q.centroid ? 1 : 0;
 + fields[i].sample = qual-flags.q.sample ? 1 : 0;

Hi Chris, I just realized, we should probably make sure that this
doesn't happen in a struct member declaration -- Only precision
qualifiers are allowed in them according to the GL spec.

  
   if (qual-flags.q.row_major || qual-flags.q.column_major) {
  if (!qual-flags.q.uniform) {
 @@ -4930,6 +4942,8 @@ ast_interface_block::hir(exec_list *instructions,
 earlier_per_vertex-fields.structure[j].interpolation;
  fields[i].centroid =
 earlier_per_vertex-fields.structure[j].centroid;
 +fields[i].sample =
 +   earlier_per_vertex-fields.structure[j].sample;
   }
}
  



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

Re: [Mesa-dev] [PATCH 5/6] st/mesa: set correct PIPE_CLEAR_COLORn flags

2013-12-06 Thread Roland Scheidegger

Oh I wasn't aware of that extension.
It seems though those functions aren't quite ideally suited for that
neither. First, they require surfaces, whereas the OpenGL extension is
done specifically so the texture may be cleared even if the texture is
non-renderable (hence surface creation may fail).
Second, the functions do not allow to specify depth/zoffset currently as
they always clear all attached layers.
Those should be fixable though I guess.

Roland

Am 05.12.2013 23:02, schrieb Marek Olšák:
 We'll probably use clear_render_target for GL_ARB_clear_texture (GL
 4.4), so it will be useful finally.
 
 Marek
 
 On Thu, Dec 5, 2013 at 10:49 PM, Roland Scheidegger srol...@vmware.com 
 wrote:
 Am 05.12.2013 18:53, schrieb Marek Olšák:
 From: Marek Olšák marek.ol...@amd.com

 This also fixes the clear_with_quad function for glClearBuffer.
 ---
  src/mesa/state_tracker/st_cb_clear.c | 37 
 +---
  1 file changed, 26 insertions(+), 11 deletions(-)

 diff --git a/src/mesa/state_tracker/st_cb_clear.c 
 b/src/mesa/state_tracker/st_cb_clear.c
 index 5a7a00c..887e58b 100644
 --- a/src/mesa/state_tracker/st_cb_clear.c
 +++ b/src/mesa/state_tracker/st_cb_clear.c
 @@ -213,8 +213,7 @@ draw_quad(struct st_context *st,
   * ctx-DrawBuffer-_X/Ymin/max fields.
   */
  static void
 -clear_with_quad(struct gl_context *ctx,
 -GLboolean color, GLboolean depth, GLboolean stencil)
 +clear_with_quad(struct gl_context *ctx, unsigned clear_buffers)
  {
 struct st_context *st = st_context(ctx);
 const struct gl_framebuffer *fb = ctx-DrawBuffer;
 @@ -253,7 +252,7 @@ clear_with_quad(struct gl_context *ctx,
 {
struct pipe_blend_state blend;
memset(blend, 0, sizeof(blend));
 -  if (color) {
 +  if (clear_buffers  PIPE_CLEAR_COLOR) {
   int num_buffers = ctx-Extensions.EXT_draw_buffers2 ?
 ctx-DrawBuffer-_NumColorDrawBuffers : 1;
   int i;
 @@ -261,6 +260,9 @@ clear_with_quad(struct gl_context *ctx,
   blend.independent_blend_enable = num_buffers  1;

   for (i = 0; i  num_buffers; i++) {
 +if (!(clear_buffers  (PIPE_CLEAR_COLOR0  i)))
 +   continue;
 +
  if (ctx-Color.ColorMask[i][0])
 blend.rt[i].colormask |= PIPE_MASK_R;
  if (ctx-Color.ColorMask[i][1])
 @@ -281,13 +283,13 @@ clear_with_quad(struct gl_context *ctx,
 {
struct pipe_depth_stencil_alpha_state depth_stencil;
memset(depth_stencil, 0, sizeof(depth_stencil));
 -  if (depth) {
 +  if (clear_buffers  PIPE_CLEAR_DEPTH) {
   depth_stencil.depth.enabled = 1;
   depth_stencil.depth.writemask = 1;
   depth_stencil.depth.func = PIPE_FUNC_ALWAYS;
}

 -  if (stencil) {
 +  if (clear_buffers  PIPE_CLEAR_STENCIL) {
   struct pipe_stencil_ref stencil_ref;
   memset(stencil_ref, 0, sizeof(stencil_ref));
   depth_stencil.stencil[0].enabled = 1;
 @@ -371,6 +373,19 @@ is_scissor_enabled(struct gl_context *ctx, struct 
 gl_renderbuffer *rb)


  /**
 + * Return if all of the color channels are masked.
 + */
 +static INLINE GLboolean
 +is_color_disabled(struct gl_context *ctx, int i)
 +{
 +   return !ctx-Color.ColorMask[i][0] 
 +  !ctx-Color.ColorMask[i][1] 
 +  !ctx-Color.ColorMask[i][2] 
 +  !ctx-Color.ColorMask[i][3];
 +}
 Technically you could also return true if not all channels are masked,
 as long as these channels don't exist in the rb. I guess though that gets
 a bit too complicated...


 +
 +/**
   * Return if any of the color channels are masked.
   */
  static INLINE GLboolean
 @@ -427,11 +442,14 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
  if (!strb || !strb-surface)
 continue;

 +if (is_color_disabled(ctx, colormask_index))
 +   continue;
 +
  if (is_scissor_enabled(ctx, rb) ||
  is_color_masked(ctx, colormask_index))
 -   quad_buffers |= PIPE_CLEAR_COLOR;
 +   quad_buffers |= PIPE_CLEAR_COLOR0  i;
  else
 -   clear_buffers |= PIPE_CLEAR_COLOR;
 +   clear_buffers |= PIPE_CLEAR_COLOR0  i;
   }
}
 }
 @@ -464,10 +482,7 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
  */
 if (quad_buffers) {
quad_buffers |= clear_buffers;
 -  clear_with_quad(ctx,
 -  quad_buffers  PIPE_CLEAR_COLOR,
 -  quad_buffers  PIPE_CLEAR_DEPTH,
 -  quad_buffers  PIPE_CLEAR_STENCIL);
 +  clear_with_quad(ctx, quad_buffers);
 } else if (clear_buffers) {
/* We can't translate the clear color to the colorbuffer format,
 * because different colorbuffers may have different formats.


 Series makes sense to me if you don't want to use the
 clear_render_target() function for that instead. And I guess the latter
 hasn't many

Re: [Mesa-dev] [PATCH 5/6] st/mesa: set correct PIPE_CLEAR_COLORn flags

2013-12-06 Thread Marek Olšák

We can easily change the functions, so that they take pipe_box instead
of pipe_surface. It's not a problem. The state tracker or gallium/util
will have to provide a fallback path for compressed and
non-renderable formats anyway.

Marek

On Fri, Dec 6, 2013 at 2:29 PM, Roland Scheidegger srol...@vmware.com wrote:
 Oh I wasn't aware of that extension.
 It seems though those functions aren't quite ideally suited for that
 neither. First, they require surfaces, whereas the OpenGL extension is
 done specifically so the texture may be cleared even if the texture is
 non-renderable (hence surface creation may fail).
 Second, the functions do not allow to specify depth/zoffset currently as
 they always clear all attached layers.
 Those should be fixable though I guess.

 Roland

 Am 05.12.2013 23:02, schrieb Marek Olšák:
 We'll probably use clear_render_target for GL_ARB_clear_texture (GL
 4.4), so it will be useful finally.

 Marek

 On Thu, Dec 5, 2013 at 10:49 PM, Roland Scheidegger srol...@vmware.com 
 wrote:
 Am 05.12.2013 18:53, schrieb Marek Olšák:
 From: Marek Olšák marek.ol...@amd.com

 This also fixes the clear_with_quad function for glClearBuffer.
 ---
  src/mesa/state_tracker/st_cb_clear.c | 37 
 +---
  1 file changed, 26 insertions(+), 11 deletions(-)

 diff --git a/src/mesa/state_tracker/st_cb_clear.c 
 b/src/mesa/state_tracker/st_cb_clear.c
 index 5a7a00c..887e58b 100644
 --- a/src/mesa/state_tracker/st_cb_clear.c
 +++ b/src/mesa/state_tracker/st_cb_clear.c
 @@ -213,8 +213,7 @@ draw_quad(struct st_context *st,
   * ctx-DrawBuffer-_X/Ymin/max fields.
   */
  static void
 -clear_with_quad(struct gl_context *ctx,
 -GLboolean color, GLboolean depth, GLboolean stencil)
 +clear_with_quad(struct gl_context *ctx, unsigned clear_buffers)
  {
 struct st_context *st = st_context(ctx);
 const struct gl_framebuffer *fb = ctx-DrawBuffer;
 @@ -253,7 +252,7 @@ clear_with_quad(struct gl_context *ctx,
 {
struct pipe_blend_state blend;
memset(blend, 0, sizeof(blend));
 -  if (color) {
 +  if (clear_buffers  PIPE_CLEAR_COLOR) {
   int num_buffers = ctx-Extensions.EXT_draw_buffers2 ?
 ctx-DrawBuffer-_NumColorDrawBuffers : 1;
   int i;
 @@ -261,6 +260,9 @@ clear_with_quad(struct gl_context *ctx,
   blend.independent_blend_enable = num_buffers  1;

   for (i = 0; i  num_buffers; i++) {
 +if (!(clear_buffers  (PIPE_CLEAR_COLOR0  i)))
 +   continue;
 +
  if (ctx-Color.ColorMask[i][0])
 blend.rt[i].colormask |= PIPE_MASK_R;
  if (ctx-Color.ColorMask[i][1])
 @@ -281,13 +283,13 @@ clear_with_quad(struct gl_context *ctx,
 {
struct pipe_depth_stencil_alpha_state depth_stencil;
memset(depth_stencil, 0, sizeof(depth_stencil));
 -  if (depth) {
 +  if (clear_buffers  PIPE_CLEAR_DEPTH) {
   depth_stencil.depth.enabled = 1;
   depth_stencil.depth.writemask = 1;
   depth_stencil.depth.func = PIPE_FUNC_ALWAYS;
}

 -  if (stencil) {
 +  if (clear_buffers  PIPE_CLEAR_STENCIL) {
   struct pipe_stencil_ref stencil_ref;
   memset(stencil_ref, 0, sizeof(stencil_ref));
   depth_stencil.stencil[0].enabled = 1;
 @@ -371,6 +373,19 @@ is_scissor_enabled(struct gl_context *ctx, struct 
 gl_renderbuffer *rb)


  /**
 + * Return if all of the color channels are masked.
 + */
 +static INLINE GLboolean
 +is_color_disabled(struct gl_context *ctx, int i)
 +{
 +   return !ctx-Color.ColorMask[i][0] 
 +  !ctx-Color.ColorMask[i][1] 
 +  !ctx-Color.ColorMask[i][2] 
 +  !ctx-Color.ColorMask[i][3];
 +}
 Technically you could also return true if not all channels are masked,
 as long as these channels don't exist in the rb. I guess though that gets
 a bit too complicated...


 +
 +/**
   * Return if any of the color channels are masked.
   */
  static INLINE GLboolean
 @@ -427,11 +442,14 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
  if (!strb || !strb-surface)
 continue;

 +if (is_color_disabled(ctx, colormask_index))
 +   continue;
 +
  if (is_scissor_enabled(ctx, rb) ||
  is_color_masked(ctx, colormask_index))
 -   quad_buffers |= PIPE_CLEAR_COLOR;
 +   quad_buffers |= PIPE_CLEAR_COLOR0  i;
  else
 -   clear_buffers |= PIPE_CLEAR_COLOR;
 +   clear_buffers |= PIPE_CLEAR_COLOR0  i;
   }
}
 }
 @@ -464,10 +482,7 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
  */
 if (quad_buffers) {
quad_buffers |= clear_buffers;
 -  clear_with_quad(ctx,
 -  quad_buffers  PIPE_CLEAR_COLOR,
 -  quad_buffers  PIPE_CLEAR_DEPTH,
 -  quad_buffers  PIPE_CLEAR_STENCIL);
 +  clear_with_quad(ctx, quad_buffers);

Re: [Mesa-dev] [PATCH 03/11] mesa: Add state data structures requried for ARB_shader_image_load_store.

2013-12-06 Thread Paul Berry

On 24 November 2013 21:00, Francisco Jerez curroje...@riseup.net wrote:

 ---
  src/mesa/main/config.h |   1 +
  src/mesa/main/dd.h |   1 +
  src/mesa/main/mtypes.h | 100
 +
  src/mesa/main/texobj.c |   1 +
  4 files changed, 103 insertions(+)

 diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
 index 22bbfa0..8bd9765 100644
 --- a/src/mesa/main/config.h
 +++ b/src/mesa/main/config.h
 @@ -175,6 +175,7 @@
  #define MAX_COMBINED_ATOMIC_BUFFERS(MAX_UNIFORM_BUFFERS * 6)
  /* Size of an atomic counter in bytes according to
 ARB_shader_atomic_counters */
  #define ATOMIC_COUNTER_SIZE4
 +#define MAX_IMAGE_UNITS32


It would be nice to have a note in the commit message explaining why you
chose 32 for MAX_IMAGE_UNITS (the spec only requires 8 so it's not obvious).


  /*@}*/

  /**
 diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
 index b5b874f..648062f 100644
 --- a/src/mesa/main/dd.h
 +++ b/src/mesa/main/dd.h
 @@ -39,6 +39,7 @@ struct gl_buffer_object;
  struct gl_context;
  struct gl_display_list;
  struct gl_framebuffer;
 +struct gl_image_unit;
  struct gl_pixelstore_attrib;
  struct gl_program;
  struct gl_renderbuffer;
 diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
 index e9750f4..7be0664 100644
 --- a/src/mesa/main/mtypes.h
 +++ b/src/mesa/main/mtypes.h
 @@ -1207,6 +1207,9 @@ struct gl_texture_object

 /** GL_OES_EGL_image_external */
 GLint RequiredTextureImageUnits;
 +
 +   /** GL_ARB_shader_image_load_store */
 +   GLenum ImageFormatCompatibility;


This is called IMAGE_FORMAT_COMPATIBILITY_TYPE in the GL spec.  Can we
rename it to ImageFormatCompatibilityType for consistency?


  };


 @@ -2373,6 +2376,29 @@ struct gl_shader
  */
GLenum OutputType;
 } Geom;
 +
 +   /**
 +* Map from image uniform index to image unit (set by glUniform1i())
 +*
 +* An image uniform index is associated with each image uniform by
 +* the linker.  The image index associated with each uniform is
 +* stored in the \c gl_uniform_storage::image field.


Can we assume image uniform indices are always in the range [0,
NumImages-1]?  If so it would be nice to document that here.


 +*/
 +   GLubyte ImageUnits[MAX_IMAGE_UNITS];
 +
 +   /**
 +* Access qualifier specified in the shader for each image uniform.
 +* Either \c GL_READ_ONLY, \c GL_WRITE_ONLY or \c GL_READ_WRITE.
 +*
 +* It may be different, though only more strict than the value of
 +* \c gl_image_unit::Access for the corresponding image unit.


Is this array indexed by image uniform index or by image unit?  The comment
should clarify that.


 +*/
 +   GLenum ImageAccess[MAX_IMAGE_UNITS];


With those changes, this patch is:

Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Unreviewed patches marked for stable

2013-12-06 Thread Ian Romanick

There are a number of patches marked for stable that don't appear to
have any reviews.  Most of these patches cover areas that I'm not
qualified to review, so I don't really feel comfortable cherry-picking
them over.  Can I get anyone other than the patch authors to vouch for
any of these?

c45cf6199fc493538cef33125c8a97a892e2ca83 nv50: Fix GPU_READING/WRITING bit 
removal
ce6dd69697ae62d9336bbd4f5808bc4d75cdcc04 nouveau: avoid leaking fences while 
waiting
0e5bf8565106833e1a678ebdae81fdf1657391c9 nv50: wait on the buf's fence before 
sticking it into pushbuf
402bf6e8d098b64390277b229f7fae769e4449e5 egl/wayland: Flush the wl_display at 
the end of SwapBuffers
33eb5eabeec0c17e81b6bb11be703701e4025d4e egl/wayland: Send commit after 
flushing the driver context
afcce46fd505da51883000249ef29dd69f1d7791 Enable throttling in SwapBuffers
bce64c6c83122b1f4a684cc7890c7a61d2f9ffd7 egl/wayland: Damage INT32_MAX x 
INT32_MAX region for eglSwapBuffers
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Fix line number on no matching function call

2013-12-06 Thread Ian Romanick

On 12/06/2013 12:34 AM, Kevin Rogovin wrote:
 This (very tiny) patch fixes the bug (#72264) where when 
 no matching function call was found the error message
 gave the line and column number as 0.

The commit message should describe why the change was made.  This just
reiterates the problem.  The commit messages are one of our best sources
of documentation of the code (in conjunction with git-blame), so it's
important for them to be useful.

From this code and commit message, I have no clue why this fixes the
problem, and I have no evidence that this is the correct fix.  From the
bug, I would have expected the fix to be ensuring that id had the proper
location set.  Why is this a better fix than that?

Also, the usual way to refer to a bug in a commit message is:

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

Try looking that git-log to see numerous examples.

 ---
  src/glsl/ast_function.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
 index 6423759..9dc5427 100644
 --- a/src/glsl/ast_function.cpp
 +++ b/src/glsl/ast_function.cpp
 @@ -1656,7 +1656,7 @@ ast_function_expression::hir(exec_list *instructions,
 } else {
const ast_expression *id = subexpressions[0];
const char *func_name = id-primary_expression.identifier;
 -  YYLTYPE loc = id-get_location();
 +  YYLTYPE loc = get_location();
exec_list actual_parameters;
  
process_parameters(instructions, actual_parameters, 
 this-expressions,
 

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

Re: [Mesa-dev] Unreviewed patches marked for stable

2013-12-06 Thread Ilia Mirkin

On Fri, Dec 6, 2013 at 11:19 AM, Ian Romanick i...@freedesktop.org wrote:
 There are a number of patches marked for stable that don't appear to
 have any reviews.  Most of these patches cover areas that I'm not
 qualified to review, so I don't really feel comfortable cherry-picking
 them over.  Can I get anyone other than the patch authors to vouch for
 any of these?

 c45cf6199fc493538cef33125c8a97a892e2ca83 nv50: Fix GPU_READING/WRITING bit 
 removal
 ce6dd69697ae62d9336bbd4f5808bc4d75cdcc04 nouveau: avoid leaking fences while 
 waiting
 0e5bf8565106833e1a678ebdae81fdf1657391c9 nv50: wait on the buf's fence before 
 sticking it into pushbuf

Maarten -- you checked these in, one could assume you reviewed them as well?
Christoph -- perhaps you can vouch for these?

Would be nice to have source games finally rendering correctly on nv50...

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

Re: [Mesa-dev] [PATCH 06/11] mesa: Add MESA_FORMAT_ABGR2101010.

2013-12-06 Thread Paul Berry

On 24 November 2013 21:00, Francisco Jerez curroje...@riseup.net wrote:

 Including pack/unpack and texstore code.  This texture format is a
 requirement for ARB_shader_image_load_store.
 ---
  src/mesa/main/format_pack.c   | 29 +++
  src/mesa/main/format_unpack.c | 32 ++
  src/mesa/main/formats.c   | 19 ++
  src/mesa/main/formats.h   |  2 ++
  src/mesa/main/texstore.c  | 46
 +++
  src/mesa/swrast/s_texfetch.c  |  6 ++
  6 files changed, 134 insertions(+)

 diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c
 index 826fc10..9b6929d 100644
 --- a/src/mesa/main/format_pack.c
 +++ b/src/mesa/main/format_pack.c
 @@ -1824,6 +1824,31 @@ pack_float_XBGR32323232_FLOAT(const GLfloat src[4],
 void *dst)
 d[3] = 1.0;
  }

 +/* MESA_FORMAT_ABGR2101010 */
 +
 +static void
 +pack_ubyte_ABGR2101010(const GLubyte src[4], void *dst)
 +{
 +   GLuint *d = ((GLuint *) dst);
 +   GLushort r = UBYTE_TO_USHORT(src[RCOMP]);
 +   GLushort g = UBYTE_TO_USHORT(src[GCOMP]);
 +   GLushort b = UBYTE_TO_USHORT(src[BCOMP]);
 +   GLushort a = UBYTE_TO_USHORT(src[ACOMP]);
 +   *d = PACK_COLOR_2101010_US(a, b, g, r);


I don't know if we care, but this conversion is not as accurate as it could
be.  For example, if the input has an r value of 0x3f, then a perfect
conversion would convert this to a float by dividing by 255.0 (to get
0.24706), then convert to 10 bits by multiplying by 1023.0 (to get 252.74),
and then round to the nearest integer, which is 253, or 0xfd.

However, what the function above does is convert to 16 bits (0x3f3f), then
chop off the lower 6 bits by downshifting, to get 0xfc, or 252.


 +}
 +
 +static void
 +pack_float_ABGR2101010(const GLfloat src[4], void *dst)
 +{
 +   GLuint *d = ((GLuint *) dst);
 +   GLushort r, g, b, a;
 +   UNCLAMPED_FLOAT_TO_USHORT(r, src[RCOMP]);
 +   UNCLAMPED_FLOAT_TO_USHORT(g, src[GCOMP]);
 +   UNCLAMPED_FLOAT_TO_USHORT(b, src[BCOMP]);
 +   UNCLAMPED_FLOAT_TO_USHORT(a, src[ACOMP]);
 +   *d = PACK_COLOR_2101010_US(a, b, g, r);


This function has similar problems, because PACK_COLOR_2101010_US chops off
low order bits, so in effect it always rounds down.


 +}
 +

  /**
   * Return a function that can pack a GLubyte rgba[4] color.
 @@ -1978,6 +2003,8 @@ _mesa_get_pack_ubyte_rgba_function(gl_format format)
table[MESA_FORMAT_XBGR32323232_UINT] = NULL;
table[MESA_FORMAT_XBGR32323232_SINT] = NULL;

 +  table[MESA_FORMAT_ABGR2101010] = pack_ubyte_ABGR2101010;
 +
initialized = GL_TRUE;
 }

 @@ -2136,6 +2163,8 @@ _mesa_get_pack_float_rgba_function(gl_format format)
table[MESA_FORMAT_XBGR32323232_UINT] = NULL;
table[MESA_FORMAT_XBGR32323232_SINT] = NULL;

 +  table[MESA_FORMAT_ABGR2101010] = pack_float_ABGR2101010;
 +
initialized = GL_TRUE;
 }

 diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
 index 0a8b8b1..fa55930 100644
 --- a/src/mesa/main/format_unpack.c
 +++ b/src/mesa/main/format_unpack.c
 @@ -2268,6 +2268,18 @@ unpack_XBGR32323232_SINT(const void *src, GLfloat
 dst[][4], GLuint n)
 }
  }

 +static void
 +unpack_ABGR2101010(const void *src, GLfloat dst[][4], GLuint n)
 +{
 +   const GLuint *s = ((const GLuint *) src);
 +   GLuint i;
 +   for (i = 0; i  n; i++) {
 +  dst[i][RCOMP] = ((s[i]  0)  0x3ff) * (1.0F / 1023.0F);
 +  dst[i][GCOMP] = ((s[i]  10)  0x3ff) * (1.0F / 1023.0F);
 +  dst[i][BCOMP] = ((s[i]  20)  0x3ff) * (1.0F / 1023.0F);
 +  dst[i][ACOMP] = ((s[i]  30)   0x03) * (1.0F / 3.0F);
 +   }
 +}

  /**
   * Return the unpacker function for the given format.
 @@ -2481,6 +2493,8 @@ get_unpack_rgba_function(gl_format format)
table[MESA_FORMAT_XBGR32323232_UINT] = unpack_XBGR32323232_UINT;
table[MESA_FORMAT_XBGR32323232_SINT] = unpack_XBGR32323232_SINT;

 +  table[MESA_FORMAT_ABGR2101010] = unpack_ABGR2101010;
 +
initialized = GL_TRUE;
 }

 @@ -3582,6 +3596,20 @@ unpack_int_rgba_XBGR32323232_UINT(const GLuint
 *src, GLuint dst[][4], GLuint n)
 }
  }

 +static void
 +unpack_int_rgba_ABGR2101010(const GLuint *src, GLuint dst[][4], GLuint n)
 +{
 +   unsigned int i;
 +
 +   for (i = 0; i  n; i++) {
 +  GLuint tmp = src[i];
 +  dst[i][0] = (tmp  0)  0x3ff;
 +  dst[i][1] = (tmp  10)  0x3ff;
 +  dst[i][2] = (tmp  20)  0x3ff;
 +  dst[i][3] = (tmp  30)  0x3;
 +   }
 +}
 +
  void
  _mesa_unpack_uint_rgba_row(gl_format format, GLuint n,
 const void *src, GLuint dst[][4])
 @@ -3782,6 +3810,10 @@ _mesa_unpack_uint_rgba_row(gl_format format, GLuint
 n,
unpack_int_rgba_XBGR32323232_UINT(src, dst, n);
break;

 +   case MESA_FORMAT_ABGR2101010:
 +  unpack_int_rgba_ABGR2101010(src, dst, n);
 +  break;
 +
 default:
_mesa_problem(NULL, %s: bad format %s, __FUNCTION__,
  _mesa_get_format_name(format));
 diff --git

Re: [Mesa-dev] [Mesa-stable] Unreviewed patches marked for stable

2013-12-06 Thread Ian Romanick

On 12/06/2013 09:21 AM, Ilia Mirkin wrote:
 On Fri, Dec 6, 2013 at 11:19 AM, Ian Romanick i...@freedesktop.org wrote:
 There are a number of patches marked for stable that don't appear to
 have any reviews.  Most of these patches cover areas that I'm not
 qualified to review, so I don't really feel comfortable cherry-picking
 them over.  Can I get anyone other than the patch authors to vouch for
 any of these?

 c45cf6199fc493538cef33125c8a97a892e2ca83 nv50: Fix GPU_READING/WRITING bit 
 removal
 ce6dd69697ae62d9336bbd4f5808bc4d75cdcc04 nouveau: avoid leaking fences while 
 waiting
 0e5bf8565106833e1a678ebdae81fdf1657391c9 nv50: wait on the buf's fence 
 before sticking it into pushbuf
 
 Maarten -- you checked these in, one could assume you reviewed them as well?
 Christoph -- perhaps you can vouch for these?
 
 Would be nice to have source games finally rendering correctly on nv50...

I agree! :)  I planning 10.0.1 next week (preferably early in the week),
so hopefully we'll hear back from Maarten and / or Christoph soon.

   -ilia
 ___
 mesa-stable mailing list
 mesa-sta...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-stable

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

Re: [Mesa-dev] [Mesa-stable] Unreviewed patches marked for stable

2013-12-06 Thread Maarten Lankhorst

op 06-12-13 18:45, Ian Romanick schreef:
 On 12/06/2013 09:21 AM, Ilia Mirkin wrote:
 On Fri, Dec 6, 2013 at 11:19 AM, Ian Romanick i...@freedesktop.org wrote:
 There are a number of patches marked for stable that don't appear to
 have any reviews.  Most of these patches cover areas that I'm not
 qualified to review, so I don't really feel comfortable cherry-picking
 them over.  Can I get anyone other than the patch authors to vouch for
 any of these?

 c45cf6199fc493538cef33125c8a97a892e2ca83 nv50: Fix GPU_READING/WRITING bit 
 removal
 ce6dd69697ae62d9336bbd4f5808bc4d75cdcc04 nouveau: avoid leaking fences 
 while waiting
 0e5bf8565106833e1a678ebdae81fdf1657391c9 nv50: wait on the buf's fence 
 before sticking it into pushbuf
 Maarten -- you checked these in, one could assume you reviewed them as well?
 Christoph -- perhaps you can vouch for these?

 Would be nice to have source games finally rendering correctly on nv50...
 I agree! :)  I planning 10.0.1 next week (preferably early in the week),
 so hopefully we'll hear back from Maarten and / or Christoph soon.

I wouldn't have checked them if I thought they would be unsuited for stable, so 
go ahead. :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/5] radeonsi: fix binding the dummy pixel shader

2013-12-06 Thread Marek Olšák

On Fri, Dec 6, 2013 at 4:08 AM, Michel Dänzer mic...@daenzer.net wrote:
 On Don, 2013-12-05 at 18:43 +0100, Marek Olšák wrote:
 From: Marek Olšák marek.ol...@amd.com

 This fixes valgrind errors in glxinfo.

 [...]

 diff --git a/src/gallium/drivers/radeonsi/si_state.c 
 b/src/gallium/drivers/radeonsi/si_state.c
 index 9831fd8..b644d56 100644
 --- a/src/gallium/drivers/radeonsi/si_state.c
 +++ b/src/gallium/drivers/radeonsi/si_state.c
 @@ -2282,15 +2282,12 @@ static void si_bind_vs_shader(struct pipe_context 
 *ctx, void *state)
   if (rctx-vs_shader == sel)
   return;

 - rctx-vs_shader = sel;
 -
 - if (sel  sel-current) {
 - si_pm4_bind_state(rctx, vs, sel-current-pm4);
 - rctx-b.streamout.stride_in_dw = sel-so.stride;
 - } else {
 - si_pm4_bind_state(rctx, vs, rctx-dummy_pixel_shader-pm4);
 - }
 + if (!sel || !sel-current)
 + return;

 + rctx-vs_shader = sel;
 + si_pm4_bind_state(rctx, vs, sel-current-pm4);
 + rctx-b.streamout.stride_in_dw = sel-so.stride;
   rctx-b.flags |= R600_CONTEXT_INV_SHADER_CACHE;
  }

 I've been wondering for a while if it's a good idea to use the dummy
 pixel shader as the vertex shader... It might be safer to just not draw
 anything if there is no vertex shader, or is there anything sensible a
 dummy vertex shader could do?

The vertex shader must never be NULL when draw_vbo is called. The
pixel shader can be NULL if pipe_rasterizer_state::rasterizer_discard
is 1. That's the only reason we care about a NULL pixel shader.

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

Re: [Mesa-dev] [PATCH 2/6] glsl: Add ir support for `sample` qualifier; adjust compiler and linker

2013-12-06 Thread Chris Forbes

OK, I'd like to handle that [and any similar cases] in a follow-up
patch with some additional piglits.

-- Chris

On Sat, Dec 7, 2013 at 12:24 AM, Francisco Jerez curroje...@riseup.net wrote:
 Chris Forbes chr...@ijw.co.nz writes:
[...]
 @@ -4662,6 +4673,7 @@ ast_process_structure_or_interface_block(exec_list 
 *instructions,
   fields[i].interpolation =
  interpret_interpolation_qualifier(qual, var_mode, state, loc);
   fields[i].centroid = qual-flags.q.centroid ? 1 : 0;
 + fields[i].sample = qual-flags.q.sample ? 1 : 0;

 Hi Chris, I just realized, we should probably make sure that this
 doesn't happen in a struct member declaration -- Only precision
 qualifiers are allowed in them according to the GL spec.


   if (qual-flags.q.row_major || qual-flags.q.column_major) {
  if (!qual-flags.q.uniform) {
 @@ -4930,6 +4942,8 @@ ast_interface_block::hir(exec_list *instructions,
 earlier_per_vertex-fields.structure[j].interpolation;
  fields[i].centroid =
 earlier_per_vertex-fields.structure[j].centroid;
 +fields[i].sample =
 +   earlier_per_vertex-fields.structure[j].sample;
   }
}


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

Re: [Mesa-dev] [RFC PATCH] dri megadriver_stub: provide compatibility with older DRI loader

2013-12-06 Thread Jordan Justen

On Fri, Dec 6, 2013 at 2:35 AM, Jordan Justen jordan.l.jus...@intel.com wrote:
 To help the transition period when DRI loaders are being updated
 to support the newer __driDriverExtensions_foo mechanism,
 we populate __DRIextension with the extensions returned
 by __driDriverExtensions_foo during a library contructor
 function.

 We find the driver foo's name by using the dladdr function
 which gives the path of the dynamic library's name that
 was being loaded.

 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
 Cc: 10.0 mesa-sta...@lists.freedesktop.org
 ---
 Trying to allow Mesa 10 to be loaded by older DRI loaders.

 This seems to help glxinfo get the i965 driver if Mesa 10's
 i965_dri.so is added to into a Mesa 9.2 libGL stack.

 It still needs to be tested more with older X servers.

I tested mesa master with and without this patch on a system running
xserver-xorg-core 1.12.4 and gnome-shell.

Without this change, gnome-shell will fail to load and metacity will
load as the fallback. Xorg.0.log reports that it can't find the
__driDriverExtensions symbol in i965_dri.so, as expected.

With the change gnome-shell starts, and glxinfo reports that it is
running Mesa i965 from master. I did not see any errors mention in
Xorg.0.log.

Is there anything else I should look for?

-Jordan

  src/mesa/drivers/dri/common/megadriver_stub.c | 113 
 ++
  1 file changed, 113 insertions(+)

 diff --git a/src/mesa/drivers/dri/common/megadriver_stub.c 
 b/src/mesa/drivers/dri/common/megadriver_stub.c
 index 6bf5d73..79d31a9 100644
 --- a/src/mesa/drivers/dri/common/megadriver_stub.c
 +++ b/src/mesa/drivers/dri/common/megadriver_stub.c
 @@ -23,6 +23,119 @@

  #include stdio.h
  #include dri_util.h
 +#include dlfcn.h
 +#include main/macros.h
 +
 +/* The extensions that allow the megadriver stub to provide backward
 + * compatibility for the older DRI driver loader require GNU
 + * extensions from dlfcn.h.
 + */
 +#ifdef _GNU_SOURCE
 +
 +#define MEGADRIVER_STUB_MAX_EXTENSIONS 10
 +
 +/* This is the table of extensions that the loader will dlsym() for.
 + *
 + * Initially it is empty for the megadriver stub, but the library
 + * contructor may initialize it based on the name of the library that
 + * is being loaded.
 + */
 +PUBLIC const __DRIextension *
 +__driDriverExtensions[MEGADRIVER_STUB_MAX_EXTENSIONS] = {
 +   NULL
 +};
 +
 +/**
 + * This is a contructor function for the megadriver dynamic library.
 + *
 + * When the driver is dlopen'ed, this function will run. It will
 + * search for the name of the foo_dri.so file that was opened using
 + * the dladdr function.
 + *
 + * After finding foo's name, it will call __driDriverGetExtensions_foo
 + * and use the return to update __driDriverExtensions to achieve
 + * compatibility with older DRI driver loaders.
 + */
 +__attribute__((constructor)) static void
 +megadriver_stub_init(void)
 +{
 +   Dl_info info;
 +   char *driver_path;
 +   char *driver_name;
 +   size_t name_len;
 +   char *get_extensions_name;
 +   const __DRIextension **(*get_extensions)(void);
 +   const __DRIextension **extensions;
 +   int i;
 +
 +   i = dladdr((void*) megadriver_stub_init, info);
 +   if (i == 0)
 +  return;
 +
 +   driver_path = strdup(info.dli_fname);
 +   if (!driver_path)
 +  return;
 +
 +   driver_name = strrchr(driver_path, '/');
 +   if (driver_name != NULL) {
 +  /* Skip '/' character */
 +  driver_name++;
 +   } else {
 +  /* Try using the start of the path */
 +  driver_name = driver_path;
 +   }
 +
 +   /* Make sure the patch ends with _dri.so */
 +   name_len = strlen(driver_name);
 +   if (strcmp(driver_name + (name_len - 7), _dri.so) != 0) {
 +  free(driver_path);
 +  return;
 +   }
 +
 +   /* If the path ends with _dri.so, then chop this part of the
 +* string off, and then we have the name
 +*/
 +   driver_name[name_len - 7] = '\0';
 +
 +   i = asprintf(get_extensions_name, %s_%s,
 +__DRI_DRIVER_GET_EXTENSIONS, driver_name);
 +   free(driver_path);
 +   if (i == -1 || !get_extensions_name)
 +  return;
 +
 +   get_extensions = dlsym(RTLD_DEFAULT, get_extensions_name);
 +   free(get_extensions_name);
 +   if (!get_extensions)
 +  return;
 +
 +   /* Use the newer DRI loader entrypoint to find extensions.
 +* We will then expose these extensions via the older
 +* __driDriverExtensions symbol.
 +*/
 +   extensions = get_extensions();
 +
 +   /* Copy the extensions into the __driDriverExtensions array
 +* we declared.
 +*/
 +   for (i = 0; i  ARRAY_SIZE(__driDriverExtensions); i++) {
 +  __driDriverExtensions[i] = extensions[i];
 +  if (extensions[i] == NULL)
 + break;
 +   }
 +
 +   /* If the driver had more extensions that we reserved, then
 +* bail out. This will cause the driver to fail to load using
 +* the older loader mechanism.
 +*/
 +   if (extensions[i] != NULL) {
 +  __driDriverExtensions[0] = NULL;
 +  fprintf(stderr,

Re: [Mesa-dev] [PATCH 08/11] mesa: Implement the GL entry points defined by ARB_shader_image_load_store.

2013-12-06 Thread Paul Berry

On 24 November 2013 21:00, Francisco Jerez curroje...@riseup.net wrote:

 +static gl_format
 +get_image_format(GLenum format)
 +{
 +   switch (format) {
 +   case GL_RGBA32F:
 +  return MESA_FORMAT_RGBA_FLOAT32;
 +
 +   case GL_RGBA16F:
 +  return MESA_FORMAT_RGBA_FLOAT16;
 +
 +   case GL_RG32F:
 +  return MESA_FORMAT_RG_FLOAT32;
 +
 +   case GL_RG16F:
 +  return MESA_FORMAT_RG_FLOAT16;
 +
 +   case GL_R11F_G11F_B10F:
 +  return MESA_FORMAT_R11_G11_B10_FLOAT;
 +
 +   case GL_R32F:
 +  return MESA_FORMAT_R_FLOAT32;
 +
 +   case GL_R16F:
 +  return MESA_FORMAT_R_FLOAT16;
 +
 +   case GL_RGBA32UI:
 +  return MESA_FORMAT_RGBA_UINT32;
 +
 +   case GL_RGBA16UI:
 +  return MESA_FORMAT_RGBA_UINT16;
 +
 +   case GL_RGB10_A2UI:
 +  return MESA_FORMAT_ABGR2101010_UINT;


I don't understand the naming conventions of the GL and MESA formats well
enough to be sure about this, but I'm troubled by the inconsistency between
the two case statements above.  In the GL_RGBA16UI case, the MESA format
lists the components in the same order as the GL format (RGBA).  But in the
GL_RGB10_A2UI case, the MESA format lists the components in the opposite
order as the GL format (ABGR instead of RGBA).  Unless there are some
really counterintuitive naming conventions at work here, it seems like
these cases can't both be right.

Assuming the above code is really correct, could you add some comments
explaining the apparent inconsistency?  Also, do you have piglit tests that
validate the above code?


 +
 +   case GL_RGBA8UI:
 +  return MESA_FORMAT_RGBA_UINT8;
 +
 +   case GL_RG32UI:
 +  return MESA_FORMAT_RG_UINT32;
 +
 +   case GL_RG16UI:
 +  return MESA_FORMAT_RG_UINT16;
 +
 +   case GL_RG8UI:
 +  return MESA_FORMAT_RG_UINT8;
 +
 +   case GL_R32UI:
 +  return MESA_FORMAT_R_UINT32;
 +
 +   case GL_R16UI:
 +  return MESA_FORMAT_R_UINT16;
 +
 +   case GL_R8UI:
 +  return MESA_FORMAT_R_UINT8;
 +
 +   case GL_RGBA32I:
 +  return MESA_FORMAT_RGBA_INT32;
 +
 +   case GL_RGBA16I:
 +  return MESA_FORMAT_RGBA_INT16;
 +
 +   case GL_RGBA8I:
 +  return MESA_FORMAT_RGBA_INT8;
 +
 +   case GL_RG32I:
 +  return MESA_FORMAT_RG_INT32;
 +
 +   case GL_RG16I:
 +  return MESA_FORMAT_RG_INT16;
 +
 +   case GL_RG8I:
 +  return MESA_FORMAT_RG_INT8;
 +
 +   case GL_R32I:
 +  return MESA_FORMAT_R_INT32;
 +
 +   case GL_R16I:
 +  return MESA_FORMAT_R_INT16;
 +
 +   case GL_R8I:
 +  return MESA_FORMAT_R_INT8;
 +
 +   case GL_RGBA16:
 +  return MESA_FORMAT_RGBA_16;
 +
 +   case GL_RGB10_A2:
 +  return MESA_FORMAT_ABGR2101010;
 +
 +   case GL_RGBA8:
 +  return MESA_FORMAT_RGBA_8;
 +
 +   case GL_RG16:
 +  return MESA_FORMAT_RG_16;
 +
 +   case GL_RG8:
 +  return MESA_FORMAT_RG_8;
 +
 +   case GL_R16:
 +  return MESA_FORMAT_R16;
 +
 +   case GL_R8:
 +  return MESA_FORMAT_R8;
 +
 +   case GL_RGBA16_SNORM:
 +  return MESA_FORMAT_SIGNED_RGBA_16;
 +
 +   case GL_RGBA8_SNORM:
 +  return MESA_FORMAT_SIGNED_RGBA_8;
 +
 +   case GL_RG16_SNORM:
 +  return MESA_FORMAT_SIGNED_RG_16;
 +
 +   case GL_RG8_SNORM:
 +  return MESA_FORMAT_SIGNED_RG_8;
 +
 +   case GL_R16_SNORM:
 +  return MESA_FORMAT_SIGNED_R16;
 +
 +   case GL_R8_SNORM:
 +  return MESA_FORMAT_SIGNED_R8;
 +
 +   default:
 +  return MESA_FORMAT_NONE;
 +   }
 +}
 +
 +enum image_format_class
 +{
 +   /** Not a valid image format. */
 +   IMAGE_FORMAT_CLASS_NONE = 0,
 +
 +   /** Classes of image formats you can cast into each other. */
 +   /** \{ */
 +   IMAGE_FORMAT_CLASS_1X8,
 +   IMAGE_FORMAT_CLASS_1X16,
 +   IMAGE_FORMAT_CLASS_1X32,
 +   IMAGE_FORMAT_CLASS_2X8,
 +   IMAGE_FORMAT_CLASS_2X16,
 +   IMAGE_FORMAT_CLASS_2X32,
 +   IMAGE_FORMAT_CLASS_11_11_10,


The ARB_shader_load_store spec describes this class as for 11/11/10 packed
floating-point formats


 +   IMAGE_FORMAT_CLASS_4X8,
 +   IMAGE_FORMAT_CLASS_4X16,
 +   IMAGE_FORMAT_CLASS_4X32,
 +   IMAGE_FORMAT_CLASS_2_10_10_10


and it describes this class as for 10/10/10/2 packed formats.  Is there a
good reason why we're reversing the order of the bit counts in one case but
not the other?


 +   /** \} */
 +};
 +
 +
 +static GLboolean
 +validate_image_unit(struct gl_context *ctx, struct gl_image_unit *u)
 +{
 +   struct gl_texture_object *t = u-TexObj;
 +   struct gl_texture_image *img;
 +
 +   if (!t || u-Level  t-BaseLevel ||
 +   u-Level  t-_MaxLevel)
 +  return GL_FALSE;
 +
 +   _mesa_test_texobj_completeness(ctx, t);
 +
 +   if ((u-Level == t-BaseLevel  !t-_BaseComplete) ||
 +   (u-Level != t-BaseLevel  !t-_MipmapComplete))
 +  return GL_FALSE;
 +
 +   if (u-Layered)
 +  img = t-Image[0][u-Level];
 +   else
 +  img = t-Image[u-Layer][u-Level];


This can't be right, because u-Layer can be much larger than 6, but the
size of the t-Image[] array is 6.  I believe what we need to do instead is:

(a) for cubemaps, we need to validate that 0 = u-Layer  6 before
accessing t-Image,

[Mesa-dev] [PATCH] r600/llvm: Allow arbitrary amount of temps in tgsi to llvm

2013-12-06 Thread Vincent Lejeune

---
 src/gallium/drivers/radeon/radeon_llvm.h   |  6 +++
 .../drivers/radeon/radeon_setup_tgsi_llvm.c| 43 --
 2 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_llvm.h 
b/src/gallium/drivers/radeon/radeon_llvm.h
index 2cab6b0..00714fb 100644
--- a/src/gallium/drivers/radeon/radeon_llvm.h
+++ b/src/gallium/drivers/radeon/radeon_llvm.h
@@ -112,6 +112,12 @@ struct radeon_llvm_context {
LLVMValueRef outputs[RADEON_LLVM_MAX_OUTPUTS][TGSI_NUM_CHANNELS];
unsigned output_reg_count;
 
+   /** This pointer is used to contain the temporary values.
+ * The amount of temporary used in tgsi can't be bound to a max value 
and
+ * thus we must allocate this array at runtime.
+ */
+   LLVMValueRef *temps;
+   unsigned temps_count;
LLVMValueRef system_values[RADEON_LLVM_MAX_SYSTEM_VALUES];
 
/*=== Private Members ===*/
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c 
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 3bb01ec..4c30de4 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -142,6 +142,13 @@ emit_array_fetch(
return result;
 }
 
+static bool uses_temp_indirect_addressing(
+   struct lp_build_tgsi_context *bld_base)
+{
+   struct lp_build_tgsi_soa_context *bld = lp_soa_context(bld_base);
+   return (bld-indirect_files  (1  TGSI_FILE_TEMPORARY));
+}
+
 static LLVMValueRef
 emit_fetch(
struct lp_build_tgsi_context *bld_base,
@@ -184,7 +191,11 @@ emit_fetch(
break;
 
case TGSI_FILE_TEMPORARY:
-   ptr = lp_get_temp_ptr_soa(bld, reg-Register.Index, swizzle);
+   if (uses_temp_indirect_addressing(bld_base)) {
+   ptr = lp_get_temp_ptr_soa(bld, reg-Register.Index, 
swizzle);
+   break;
+   }
+   ptr = ctx-temps[reg-Register.Index * TGSI_NUM_CHANNELS + 
swizzle];
result = LLVMBuildLoad(builder, ptr, );
break;
 
@@ -216,6 +227,7 @@ static void emit_declaration(
const struct tgsi_full_declaration *decl)
 {
struct radeon_llvm_context * ctx = radeon_llvm_context(bld_base);
+   unsigned first, last, i, idx;
switch(decl-Declaration.File) {
case TGSI_FILE_ADDRESS:
{
@@ -234,7 +246,23 @@ static void emit_declaration(
case TGSI_FILE_TEMPORARY:
if (decl-Declaration.Array  decl-Array.ArrayID = 
RADEON_LLVM_MAX_ARRAYS)
ctx-arrays[decl-Array.ArrayID - 1] = decl-Range;
-   lp_emit_declaration_soa(bld_base, decl);
+   if (uses_temp_indirect_addressing(bld_base)) {
+   lp_emit_declaration_soa(bld_base, decl);
+   break;
+   }
+   first = decl-Range.First;
+   last = decl-Range.Last;
+   if (!ctx-temps_count) {
+   ctx-temps_count = 
bld_base-info-file_max[TGSI_FILE_TEMPORARY] + 1;
+   ctx-temps = MALLOC(TGSI_NUM_CHANNELS * 
ctx-temps_count * sizeof(LLVMValueRef));
+   }
+   for (idx = first; idx = last; idx++) {
+   for (i = 0; i  TGSI_NUM_CHANNELS; i++) {
+   ctx-temps[idx * TGSI_NUM_CHANNELS + i] =
+   lp_build_alloca(bld_base-base.gallivm, 
bld_base-base.vec_type,
+   temp);
+   }
+   }
break;
 
case TGSI_FILE_INPUT:
@@ -284,6 +312,7 @@ emit_store(
const struct tgsi_opcode_info * info,
LLVMValueRef dst[4])
 {
+   struct radeon_llvm_context * ctx = radeon_llvm_context(bld_base);
struct lp_build_tgsi_soa_context *bld = lp_soa_context(bld_base);
struct gallivm_state *gallivm = bld-bld_base.base.gallivm;
struct lp_build_context base = bld-bld_base.base;
@@ -359,7 +388,10 @@ emit_store(
break;
 
case TGSI_FILE_TEMPORARY:
-   temp_ptr = lp_get_temp_ptr_soa(bld, i + 
range.First, chan_index);
+   if 
(uses_temp_indirect_addressing(bld_base))
+   temp_ptr = 
lp_get_temp_ptr_soa(bld, i + range.First, chan_index);
+   else
+   temp_ptr = ctx-temps[(i + 
range.First) * TGSI_NUM_CHANNELS + chan_index];
break;
 
default:
@@ -377,7 +409,9 @@ emit_store(
break;
 
case TGSI_FILE_TEMPORARY:
-   temp_ptr = lp_get_temp_ptr_soa(bld,

Re: [Mesa-dev] [PATCH 01/11] glapi: Update dispatch XML files for ARB_shader_image_load_store.

2013-12-06 Thread Paul Berry

On 24 November 2013 21:00, Francisco Jerez curroje...@riseup.net wrote:

 +enum name=VERTEX_ATTRIB_ARRAY_BARRIER_BIT value=0x0001/
 +enum name=ELEMENT_ARRAY_BARRIER_BIT value=0x0002/
 +enum name=UNIFORM_BARRIER_BIT value=0x0004/
 +enum name=TEXTURE_FETCH_BARRIER_BIT value=0x0008/
 +enum name=SHADER_IMAGE_ACCESS_BARRIER_BIT value=0x0020/
 +enum name=COMMAND_BARRIER_BIT value=0x0040/
 +enum name=PIXEL_BUFFER_BARRIER_BIT value=0x0080/
 +enum name=TEXTURE_UPDATE_BARRIER_BIT value=0x0100/
 +enum name=BUFFER_UPDATE_BARRIER_BIT value=0x0200/
 +enum name=FRAMEBUFFER_BARRIER_BIT value=0x0400/
 +enum name=TRANSFORM_FEEDBACK_BARRIER_BIT value=0x0800/
 +enum name=ATOMIC_COUNTER_BARRIER_BIT value=0x1000/
 +enum name=ALL_BARRIER_BITS value=0x/
 +enum name=MAX_IMAGE_UNITS value=0x8F38/
 +enum name=MAX_COMBINED_IMAGE_UNITS_AND_FRAGMENT_OUTPUTS
 value=0x8F39/
 +enum name=IMAGE_BINDING_NAME value=0x8F3A/
 +enum name=IMAGE_BINDING_LEVEL value=0x8F3B/
 +enum name=IMAGE_BINDING_LAYERED value=0x8F3C/
 +enum name=IMAGE_BINDING_LAYERED_EXT value=0x8F3C/


I'm surprised to see IMAGE_BINDING_LAYERED_EXT here instead of
IMAGE_BINDING_LAYER.  I assume this was just a typographical error?

Change this line to:

enum name=IMAGE_BINDING_LAYER value=0x8F3D/

(note: the value also needs to change), and this patch is:

Reviewed-by: Paul Berry stereotype...@gmail.com


 +enum name=IMAGE_BINDING_ACCESS value=0x8F3E/
 +enum name=IMAGE_1D value=0x904C/
 +enum name=IMAGE_2D value=0x904D/
 +enum name=IMAGE_3D value=0x904E/
 +enum name=IMAGE_2D_RECT value=0x904F/
 +enum name=IMAGE_CUBE value=0x9050/
 +enum name=IMAGE_BUFFER value=0x9051/
 +enum name=IMAGE_1D_ARRAY value=0x9052/
 +enum name=IMAGE_2D_ARRAY value=0x9053/
 +enum name=IMAGE_CUBE_MAP_ARRAY value=0x9054/
 +enum name=IMAGE_2D_MULTISAMPLE value=0x9055/
 +enum name=IMAGE_2D_MULTISAMPLE_ARRAY value=0x9056/
 +enum name=INT_IMAGE_1D value=0x9057/
 +enum name=INT_IMAGE_2D value=0x9058/
 +enum name=INT_IMAGE_3D value=0x9059/
 +enum name=INT_IMAGE_2D_RECT value=0x905A/
 +enum name=INT_IMAGE_CUBE value=0x905B/
 +enum name=INT_IMAGE_BUFFER value=0x905C/
 +enum name=INT_IMAGE_1D_ARRAY value=0x905D/
 +enum name=INT_IMAGE_2D_ARRAY value=0x905E/
 +enum name=INT_IMAGE_CUBE_MAP_ARRAY value=0x905F/
 +enum name=INT_IMAGE_2D_MULTISAMPLE value=0x9060/
 +enum name=INT_IMAGE_2D_MULTISAMPLE_ARRAY value=0x9061/
 +enum name=UNSIGNED_INT_IMAGE_1D value=0x9062/
 +enum name=UNSIGNED_INT_IMAGE_2D value=0x9063/
 +enum name=UNSIGNED_INT_IMAGE_3D value=0x9064/
 +enum name=UNSIGNED_INT_IMAGE_2D_RECT value=0x9065/
 +enum name=UNSIGNED_INT_IMAGE_CUBE value=0x9066/
 +enum name=UNSIGNED_INT_IMAGE_BUFFER value=0x9067/
 +enum name=UNSIGNED_INT_IMAGE_1D_ARRAY value=0x9068/
 +enum name=UNSIGNED_INT_IMAGE_2D_ARRAY value=0x9069/
 +enum name=UNSIGNED_INT_IMAGE_CUBE_MAP_ARRAY value=0x906A/
 +enum name=UNSIGNED_INT_IMAGE_2D_MULTISAMPLE value=0x906B/
 +enum name=UNSIGNED_INT_IMAGE_2D_MULTISAMPLE_ARRAY value=0x906C/
 +enum name=MAX_IMAGE_SAMPLES value=0x906D/
 +enum name=IMAGE_BINDING_FORMAT value=0x906E/
 +enum name=IMAGE_FORMAT_COMPATIBILITY_TYPE value=0x90C7/
 +enum name=IMAGE_FORMAT_COMPATIBILITY_BY_SIZE value=0x90C8/
 +enum name=IMAGE_FORMAT_COMPATIBILITY_BY_CLASS value=0x90C9/
 +enum name=MAX_VERTEX_IMAGE_UNIFORMS value=0x90CA/
 +enum name=MAX_TESS_CONTROL_IMAGE_UNIFORMS value=0x90CB/
 +enum name=MAX_TESS_EVALUATION_IMAGE_UNIFORMS value=0x90CC/
 +enum name=MAX_GEOMETRY_IMAGE_UNIFORMS value=0x90CD/
 +enum name=MAX_FRAGMENT_IMAGE_UNIFORMS value=0x90CE/
 +enum name=MAX_COMBINED_IMAGE_UNIFORMS value=0x90CF/

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

Re: [Mesa-dev] [PATCH 00/11] Core mesa changes for ARB_shader_image_load_store.

2013-12-06 Thread Paul Berry

On 6 December 2013 02:54, Francisco Jerez curroje...@riseup.net wrote:

 Paul Berry stereotype...@gmail.com writes:

 [...]
  This order of patches introduces temporary build breakages, which I'd
  prefer to avoid if possible.  Here's one order which I've verified works
  (there may be other possibilities):
 
  [PATCH 03/11] mesa: Add state data structures requried for
  ARB_shader_image_load_store.
  [PATCH 04/11] mesa: Add driver interface for ARB_shader_image_load_store.
  [PATCH 06/11] mesa: Add MESA_FORMAT_ABGR2101010.
  [PATCH 08/11] mesa: Implement the GL entry points defined by
  ARB_shader_image_load_store.
  [PATCH 01/11] glapi: Update dispatch XML files for
  ARB_shader_image_load_store.
  [PATCH 02/11] mesa: Add ARB_shader_image_load_store to the extension
 table.
  [PATCH 05/11] mesa: Add image parameter queries for
  ARB_shader_image_load_store.
  [PATCH 07/11] mesa: Add MESA_FORMAT_SIGNED_RG88 and _RG1616.
  [PATCH 09/11] mesa: Unbind deleted textures from the shader image units.
  [PATCH 10/11] mesa: Validate image units when the texture state changes.
  [PATCH 11/11] docs: Mark ARB_shader_image_load_store as work in progress.

 Thanks Paul, I've adopted your patch ordering in my branch, it should be
 fixed now.


Cool, thanks.

I sent comments on patches 1, 3, 6, and 8 (relative to the original
ordering).  The remainder of this series is:

Reviewed-by: Paul Berry stereotype...@gmail.com

I'll try to get to the other ARB_image_shader_load_store series next week.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] dri megadriver_stub: provide compatibility with older DRI loader

2013-12-06 Thread Keith Packard

Jordan Justen jljus...@gmail.com writes:

 We find the driver foo's name by using the dladdr function
 which gives the path of the dynamic library's name that
 was being loaded.

That sounds like all kinds of win for existing X servers. Thanks for
doing it up in style, so that a megadrivers build can actually work for
all chips in the megadriver.

(as a style issue, I probably would have computed the driver name from
the dli_fname value directly and then copied it out into new storage, or
directly into get_extensions_name, but that's just me, so you should
feel free to ignore it :-)

 +   /* Make sure the patch ends with _dri.so */
 +   name_len = strlen(driver_name);
 +   if (strcmp(driver_name + (name_len - 7), _dri.so) != 0) {

Need to make sure name_len is = 7 here. Should probably just have a
test that checks namelen and bails if it's  7 as there are other places
using this magic value.

(Oh, I'd probably stick _dri.so in a #define and then #define the
length of it too, instead of using '7' in several places. Again, style,
not substance, so you can ignore that as you please.)

 +   i = asprintf(get_extensions_name, %s_%s,
 +__DRI_DRIVER_GET_EXTENSIONS, driver_name);
 +   free(driver_path);
 +   if (i == -1 || !get_extensions_name)
 +  return;

Is the null pointer check here useful or necessary? asprintf doesn't
define the value when allocation fails, preferring to return -1
instead. Are there systems which return valid 'i' and null pointer?

 +   /* Copy the extensions into the __driDriverExtensions array
 +* we declared.
 +*/
 +   for (i = 0; i  ARRAY_SIZE(__driDriverExtensions); i++) {
 +  __driDriverExtensions[i] = extensions[i];
 +  if (extensions[i] == NULL)
 + break;
 +   }
 +
 +   /* If the driver had more extensions that we reserved, then
 +* bail out. This will cause the driver to fail to load using
 +* the older loader mechanism.
 +*/
 +   if (extensions[i] != NULL) {

This check is incorrect -- you will dereference off the end of the array
when you fill it. Instead, you should just check for

if (i == ARRAY_SIZE(__driDriverExtensions))

as that will let you know the array was filled

-- 
keith.pack...@intel.com


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

Re: [Mesa-dev] [PATCH 2/6] mesa: fix interpretation of glClearBuffer(drawbuffer)

2013-12-06 Thread Ian Romanick

On 12/05/2013 09:52 AM, Marek Olšák wrote:
 From: Marek Olšák marek.ol...@amd.com
 
 This corresponding piglit tests supported this incorrect behavior instead of
 pointing at it.
 
 See the GL 4.4 spec if the GL 3.0 spec is not clear enough.

I looked at the 4.0 spec, and I think I see where the initial confusion
was.  The spec said:

If buffer is COLOR, a particular draw buffer DRAW_BUFFERi is
specified by passing i as the parameter drawbuffer, and value
points to a four-element vector specifying the R, G, B, and A
color to clear that draw buffer to. If the draw buffer is one
of FRONT, BACK, LEFT, RIGHT, or FRONT_AND_BACK, identifying
multiple buffers, each selected buffer is cleared to the same
value.

drawbuffer and draw buffer having two different meanings in two
sentences in the same paragraph is... suck.

Could we get the above text and some clarification of drawbuffer vs.
draw buffer as a comment in make_color_buffer_mask?  With that change,
this patch is

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

 Cc: 10.0 9.2 9.1 mesa-sta...@lists.freedesktop.org
 ---
  src/mesa/main/clear.c | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)
 
 diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
 index 304d135..4239240 100644
 --- a/src/mesa/main/clear.c
 +++ b/src/mesa/main/clear.c
 @@ -219,7 +219,11 @@ make_color_buffer_mask(struct gl_context *ctx, GLint 
 drawbuffer)
 const struct gl_renderbuffer_attachment *att = 
 ctx-DrawBuffer-Attachment;
 GLbitfield mask = 0x0;
  
 -   switch (drawbuffer) {
 +   if (drawbuffer  0 || drawbuffer = (GLint)ctx-Const.MaxDrawBuffers) {
 +  return INVALID_MASK;
 +   }
 +
 +   switch (ctx-DrawBuffer-ColorDrawBuffer[drawbuffer]) {
 case GL_FRONT:
if (att[BUFFER_FRONT_LEFT].Renderbuffer)
   mask |= BUFFER_BIT_FRONT_LEFT;
 @@ -255,11 +259,12 @@ make_color_buffer_mask(struct gl_context *ctx, GLint 
 drawbuffer)
   mask |= BUFFER_BIT_BACK_RIGHT;
break;
 default:
 -  if (drawbuffer  0 || drawbuffer = (GLint)ctx-Const.MaxDrawBuffers) {
 - mask = INVALID_MASK;
 -  }
 -  else if (att[BUFFER_COLOR0 + drawbuffer].Renderbuffer) {
 - mask |= (BUFFER_BIT_COLOR0  drawbuffer);
 +  {
 + GLuint buf = ctx-DrawBuffer-_ColorDrawBufferIndexes[drawbuffer];
 +
 + if (buf = 0  att[buf].Renderbuffer) {
 +mask |= 1  buf;
 + }
}
 }
  

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

Re: [Mesa-dev] [RFC PATCH] dri megadriver_stub: provide compatibility with older DRI loader

2013-12-06 Thread Ian Romanick

On 12/06/2013 01:12 PM, Jordan Justen wrote:
 On Fri, Dec 6, 2013 at 2:35 AM, Jordan Justen jordan.l.jus...@intel.com 
 wrote:
 To help the transition period when DRI loaders are being updated
 to support the newer __driDriverExtensions_foo mechanism,
 we populate __DRIextension with the extensions returned
 by __driDriverExtensions_foo during a library contructor
 function.

 We find the driver foo's name by using the dladdr function
 which gives the path of the dynamic library's name that
 was being loaded.

I like this approach much better than the one we were discussing in the
office yesterday.  It's much cleaner, and it's not specific to any
particular driver.  I'd really like to hear Eric and / or Keith's opinion

 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
 Cc: 10.0 mesa-sta...@lists.freedesktop.org
 ---
 Trying to allow Mesa 10 to be loaded by older DRI loaders.

 This seems to help glxinfo get the i965 driver if Mesa 10's
 i965_dri.so is added to into a Mesa 9.2 libGL stack.

 It still needs to be tested more with older X servers.
 
 I tested mesa master with and without this patch on a system running
 xserver-xorg-core 1.12.4 and gnome-shell.
 
 Without this change, gnome-shell will fail to load and metacity will
 load as the fallback. Xorg.0.log reports that it can't find the
 __driDriverExtensions symbol in i965_dri.so, as expected.
 
 With the change gnome-shell starts, and glxinfo reports that it is
 running Mesa i965 from master. I did not see any errors mention in
 Xorg.0.log.
 
 Is there anything else I should look for?

And I assume that there were no piglit regressions on this
configuration?  Did 'LIBGL_ALWAYS_INDIRECT=y glxgears' run properly?

 -Jordan
 
  src/mesa/drivers/dri/common/megadriver_stub.c | 113 
 ++
  1 file changed, 113 insertions(+)

 diff --git a/src/mesa/drivers/dri/common/megadriver_stub.c 
 b/src/mesa/drivers/dri/common/megadriver_stub.c
 index 6bf5d73..79d31a9 100644
 --- a/src/mesa/drivers/dri/common/megadriver_stub.c
 +++ b/src/mesa/drivers/dri/common/megadriver_stub.c
 @@ -23,6 +23,119 @@

  #include stdio.h
  #include dri_util.h
 +#include dlfcn.h
 +#include main/macros.h
 +
 +/* The extensions that allow the megadriver stub to provide backward
 + * compatibility for the older DRI driver loader require GNU
 + * extensions from dlfcn.h.
 + */
 +#ifdef _GNU_SOURCE
 +
 +#define MEGADRIVER_STUB_MAX_EXTENSIONS 10
 +
 +/* This is the table of extensions that the loader will dlsym() for.
 + *
 + * Initially it is empty for the megadriver stub, but the library
 + * contructor may initialize it based on the name of the library that
 + * is being loaded.
 + */
 +PUBLIC const __DRIextension *
 +__driDriverExtensions[MEGADRIVER_STUB_MAX_EXTENSIONS] = {
 +   NULL
 +};
 +
 +/**
 + * This is a contructor function for the megadriver dynamic library.
 + *
 + * When the driver is dlopen'ed, this function will run. It will
 + * search for the name of the foo_dri.so file that was opened using
 + * the dladdr function.
 + *
 + * After finding foo's name, it will call __driDriverGetExtensions_foo
 + * and use the return to update __driDriverExtensions to achieve
 + * compatibility with older DRI driver loaders.
 + */
 +__attribute__((constructor)) static void
 +megadriver_stub_init(void)
 +{
 +   Dl_info info;
 +   char *driver_path;
 +   char *driver_name;
 +   size_t name_len;
 +   char *get_extensions_name;
 +   const __DRIextension **(*get_extensions)(void);
 +   const __DRIextension **extensions;
 +   int i;
 +
 +   i = dladdr((void*) megadriver_stub_init, info);
 +   if (i == 0)
 +  return;
 +
 +   driver_path = strdup(info.dli_fname);
 +   if (!driver_path)
 +  return;
 +
 +   driver_name = strrchr(driver_path, '/');
 +   if (driver_name != NULL) {
 +  /* Skip '/' character */
 +  driver_name++;
 +   } else {
 +  /* Try using the start of the path */
 +  driver_name = driver_path;
 +   }
 +
 +   /* Make sure the patch ends with _dri.so */
 +   name_len = strlen(driver_name);
 +   if (strcmp(driver_name + (name_len - 7), _dri.so) != 0) {
 +  free(driver_path);
 +  return;
 +   }
 +
 +   /* If the path ends with _dri.so, then chop this part of the
 +* string off, and then we have the name
 +*/
 +   driver_name[name_len - 7] = '\0';
 +
 +   i = asprintf(get_extensions_name, %s_%s,
 +__DRI_DRIVER_GET_EXTENSIONS, driver_name);
 +   free(driver_path);
 +   if (i == -1 || !get_extensions_name)
 +  return;
 +
 +   get_extensions = dlsym(RTLD_DEFAULT, get_extensions_name);
 +   free(get_extensions_name);
 +   if (!get_extensions)
 +  return;
 +
 +   /* Use the newer DRI loader entrypoint to find extensions.
 +* We will then expose these extensions via the older
 +* __driDriverExtensions symbol.
 +*/
 +   extensions = get_extensions();
 +
 +   /* Copy the extensions into the __driDriverExtensions array
 +* we declared.
 +*/
 +   for (i = 0; i

Re: [Mesa-dev] [RFC PATCH] dri megadriver_stub: provide compatibility with older DRI loader

2013-12-06 Thread Jordan Justen

On Fri, Dec 6, 2013 at 3:50 PM, Ian Romanick i...@freedesktop.org wrote:
 On 12/06/2013 01:12 PM, Jordan Justen wrote:
 On Fri, Dec 6, 2013 at 2:35 AM, Jordan Justen jordan.l.jus...@intel.com 
 wrote:
 To help the transition period when DRI loaders are being updated
 to support the newer __driDriverExtensions_foo mechanism,
 we populate __DRIextension with the extensions returned
 by __driDriverExtensions_foo during a library contructor
 function.

 We find the driver foo's name by using the dladdr function
 which gives the path of the dynamic library's name that
 was being loaded.

 I like this approach much better than the one we were discussing in the
 office yesterday.  It's much cleaner, and it's not specific to any
 particular driver.  I'd really like to hear Eric and / or Keith's opinion

 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
 Cc: 10.0 mesa-sta...@lists.freedesktop.org
 ---
 Trying to allow Mesa 10 to be loaded by older DRI loaders.

 This seems to help glxinfo get the i965 driver if Mesa 10's
 i965_dri.so is added to into a Mesa 9.2 libGL stack.

 It still needs to be tested more with older X servers.

 I tested mesa master with and without this patch on a system running
 xserver-xorg-core 1.12.4 and gnome-shell.

 Without this change, gnome-shell will fail to load and metacity will
 load as the fallback. Xorg.0.log reports that it can't find the
 __driDriverExtensions symbol in i965_dri.so, as expected.

 With the change gnome-shell starts, and glxinfo reports that it is
 running Mesa i965 from master. I did not see any errors mention in
 Xorg.0.log.

 Is there anything else I should look for?

 And I assume that there were no piglit regressions on this
 configuration?

Sorry, I haven't run piglit yet.

I have a v2 almost ready based on Keith's feedback, and I'll run
piglit before sending it out.

  Did 'LIBGL_ALWAYS_INDIRECT=y glxgears' run properly?

Yeah, that seems to work.

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

Re: [Mesa-dev] [PATCH 2/6] mesa: fix interpretation of glClearBuffer(drawbuffer)

2013-12-06 Thread Marek Olšák

The spec is cleaned up in GL 4.4 Compatibility (this is the only one I
read except GL 3.0). It doesn't mention FRONT, BACK, etc. Instead it
just says that DRAW_BUFFERi can identify one or more colorbuffers and
all of them are cleared, therefore no clarification is needed for
readers of GL 4.4. Some clarification may be needed for readers of
older specs indeed.

Marek

On Sat, Dec 7, 2013 at 12:12 AM, Ian Romanick i...@freedesktop.org wrote:
 On 12/05/2013 09:52 AM, Marek Olšák wrote:
 From: Marek Olšák marek.ol...@amd.com

 This corresponding piglit tests supported this incorrect behavior instead of
 pointing at it.

 See the GL 4.4 spec if the GL 3.0 spec is not clear enough.

 I looked at the 4.0 spec, and I think I see where the initial confusion
 was.  The spec said:

 If buffer is COLOR, a particular draw buffer DRAW_BUFFERi is
 specified by passing i as the parameter drawbuffer, and value
 points to a four-element vector specifying the R, G, B, and A
 color to clear that draw buffer to. If the draw buffer is one
 of FRONT, BACK, LEFT, RIGHT, or FRONT_AND_BACK, identifying
 multiple buffers, each selected buffer is cleared to the same
 value.

 drawbuffer and draw buffer having two different meanings in two
 sentences in the same paragraph is... suck.

 Could we get the above text and some clarification of drawbuffer vs.
 draw buffer as a comment in make_color_buffer_mask?  With that change,
 this patch is

 Reviewed-by: Ian Romanick ian.d.roman...@intel.com

 Cc: 10.0 9.2 9.1 mesa-sta...@lists.freedesktop.org
 ---
  src/mesa/main/clear.c | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)

 diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
 index 304d135..4239240 100644
 --- a/src/mesa/main/clear.c
 +++ b/src/mesa/main/clear.c
 @@ -219,7 +219,11 @@ make_color_buffer_mask(struct gl_context *ctx, GLint 
 drawbuffer)
 const struct gl_renderbuffer_attachment *att = 
 ctx-DrawBuffer-Attachment;
 GLbitfield mask = 0x0;

 -   switch (drawbuffer) {
 +   if (drawbuffer  0 || drawbuffer = (GLint)ctx-Const.MaxDrawBuffers) {
 +  return INVALID_MASK;
 +   }
 +
 +   switch (ctx-DrawBuffer-ColorDrawBuffer[drawbuffer]) {
 case GL_FRONT:
if (att[BUFFER_FRONT_LEFT].Renderbuffer)
   mask |= BUFFER_BIT_FRONT_LEFT;
 @@ -255,11 +259,12 @@ make_color_buffer_mask(struct gl_context *ctx, GLint 
 drawbuffer)
   mask |= BUFFER_BIT_BACK_RIGHT;
break;
 default:
 -  if (drawbuffer  0 || drawbuffer = (GLint)ctx-Const.MaxDrawBuffers) 
 {
 - mask = INVALID_MASK;
 -  }
 -  else if (att[BUFFER_COLOR0 + drawbuffer].Renderbuffer) {
 - mask |= (BUFFER_BIT_COLOR0  drawbuffer);
 +  {
 + GLuint buf = ctx-DrawBuffer-_ColorDrawBufferIndexes[drawbuffer];
 +
 + if (buf = 0  att[buf].Renderbuffer) {
 +mask |= 1  buf;
 + }
}
 }


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

Re: [Mesa-dev] [PATCH] r600/llvm: Allow arbitrary amount of temps in tgsi to llvm

2013-12-06 Thread Tom Stellard

On Fri, Dec 06, 2013 at 10:43:42PM +0100, Vincent Lejeune wrote:
 ---


Reviewed-by: Tom Stellard thomas.stell...@amd.com

  src/gallium/drivers/radeon/radeon_llvm.h   |  6 +++
  .../drivers/radeon/radeon_setup_tgsi_llvm.c| 43 
 --
  2 files changed, 45 insertions(+), 4 deletions(-)
 
 diff --git a/src/gallium/drivers/radeon/radeon_llvm.h 
 b/src/gallium/drivers/radeon/radeon_llvm.h
 index 2cab6b0..00714fb 100644
 --- a/src/gallium/drivers/radeon/radeon_llvm.h
 +++ b/src/gallium/drivers/radeon/radeon_llvm.h
 @@ -112,6 +112,12 @@ struct radeon_llvm_context {
   LLVMValueRef outputs[RADEON_LLVM_MAX_OUTPUTS][TGSI_NUM_CHANNELS];
   unsigned output_reg_count;
  
 + /** This pointer is used to contain the temporary values.
 +   * The amount of temporary used in tgsi can't be bound to a max value 
 and
 +   * thus we must allocate this array at runtime.
 +   */
 + LLVMValueRef *temps;
 + unsigned temps_count;
   LLVMValueRef system_values[RADEON_LLVM_MAX_SYSTEM_VALUES];
  
   /*=== Private Members ===*/
 diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c 
 b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
 index 3bb01ec..4c30de4 100644
 --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
 +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
 @@ -142,6 +142,13 @@ emit_array_fetch(
   return result;
  }
  
 +static bool uses_temp_indirect_addressing(
 + struct lp_build_tgsi_context *bld_base)
 +{
 + struct lp_build_tgsi_soa_context *bld = lp_soa_context(bld_base);
 + return (bld-indirect_files  (1  TGSI_FILE_TEMPORARY));
 +}
 +
  static LLVMValueRef
  emit_fetch(
   struct lp_build_tgsi_context *bld_base,
 @@ -184,7 +191,11 @@ emit_fetch(
   break;
  
   case TGSI_FILE_TEMPORARY:
 - ptr = lp_get_temp_ptr_soa(bld, reg-Register.Index, swizzle);
 + if (uses_temp_indirect_addressing(bld_base)) {
 + ptr = lp_get_temp_ptr_soa(bld, reg-Register.Index, 
 swizzle);
 + break;
 + }
 + ptr = ctx-temps[reg-Register.Index * TGSI_NUM_CHANNELS + 
 swizzle];
   result = LLVMBuildLoad(builder, ptr, );
   break;
  
 @@ -216,6 +227,7 @@ static void emit_declaration(
   const struct tgsi_full_declaration *decl)
  {
   struct radeon_llvm_context * ctx = radeon_llvm_context(bld_base);
 + unsigned first, last, i, idx;
   switch(decl-Declaration.File) {
   case TGSI_FILE_ADDRESS:
   {
 @@ -234,7 +246,23 @@ static void emit_declaration(
   case TGSI_FILE_TEMPORARY:
   if (decl-Declaration.Array  decl-Array.ArrayID = 
 RADEON_LLVM_MAX_ARRAYS)
   ctx-arrays[decl-Array.ArrayID - 1] = decl-Range;
 - lp_emit_declaration_soa(bld_base, decl);
 + if (uses_temp_indirect_addressing(bld_base)) {
 + lp_emit_declaration_soa(bld_base, decl);
 + break;
 + }
 + first = decl-Range.First;
 + last = decl-Range.Last;
 + if (!ctx-temps_count) {
 + ctx-temps_count = 
 bld_base-info-file_max[TGSI_FILE_TEMPORARY] + 1;
 + ctx-temps = MALLOC(TGSI_NUM_CHANNELS * 
 ctx-temps_count * sizeof(LLVMValueRef));
 + }
 + for (idx = first; idx = last; idx++) {
 + for (i = 0; i  TGSI_NUM_CHANNELS; i++) {
 + ctx-temps[idx * TGSI_NUM_CHANNELS + i] =
 + lp_build_alloca(bld_base-base.gallivm, 
 bld_base-base.vec_type,
 + temp);
 + }
 + }
   break;
  
   case TGSI_FILE_INPUT:
 @@ -284,6 +312,7 @@ emit_store(
   const struct tgsi_opcode_info * info,
   LLVMValueRef dst[4])
  {
 + struct radeon_llvm_context * ctx = radeon_llvm_context(bld_base);
   struct lp_build_tgsi_soa_context *bld = lp_soa_context(bld_base);
   struct gallivm_state *gallivm = bld-bld_base.base.gallivm;
   struct lp_build_context base = bld-bld_base.base;
 @@ -359,7 +388,10 @@ emit_store(
   break;
  
   case TGSI_FILE_TEMPORARY:
 - temp_ptr = lp_get_temp_ptr_soa(bld, i + 
 range.First, chan_index);
 + if 
 (uses_temp_indirect_addressing(bld_base))
 + temp_ptr = 
 lp_get_temp_ptr_soa(bld, i + range.First, chan_index);
 + else
 + temp_ptr = ctx-temps[(i + 
 range.First) * TGSI_NUM_CHANNELS + chan_index];
   break;
  
   default:
 @@ -377,7 +409,9 @@ emit_store(
   break;

[Mesa-dev] [PATCH v2] dri megadriver_stub: provide compatibility with older DRI loader

2013-12-06 Thread Jordan Justen

To help the transition period when DRI loaders are being updated
to support the newer __driDriverExtensions_foo mechanism,
we populate __DRIextension with the extensions returned
by __driDriverExtensions_foo during a library contructor
function.

We find the driver foo's name by using the dladdr function
which gives the path of the dynamic library's name that
was being loaded.

v2:
 * dladdr on public symbol __driDriverExtensions rather
   than static megadriver_stub_init.
 * Incorporate fixes and suggestions from Keith

Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/common/megadriver_stub.c | 125 ++
 1 file changed, 125 insertions(+)

diff --git a/src/mesa/drivers/dri/common/megadriver_stub.c 
b/src/mesa/drivers/dri/common/megadriver_stub.c
index 6bf5d73..cb1078d 100644
--- a/src/mesa/drivers/dri/common/megadriver_stub.c
+++ b/src/mesa/drivers/dri/common/megadriver_stub.c
@@ -23,6 +23,131 @@
 
 #include stdio.h
 #include dri_util.h
+#include dlfcn.h
+#include main/macros.h
+
+/* The extensions that allow the megadriver stub to provide backward
+ * compatibility for the older DRI driver loader require GNU
+ * extensions from dlfcn.h.
+ */
+#ifdef _GNU_SOURCE
+
+#define MEGADRIVER_STUB_MAX_EXTENSIONS 10
+#define LIB_PATH_SUFFIX _dri.so
+#define LIB_PATH_SUFFIX_LENGTH (sizeof(LIB_PATH_SUFFIX)-1)
+
+/* This is the table of extensions that the loader will dlsym() for.
+ *
+ * Initially it is empty for the megadriver stub, but the library
+ * contructor may initialize it based on the name of the library that
+ * is being loaded.
+ */
+PUBLIC const __DRIextension *
+__driDriverExtensions[MEGADRIVER_STUB_MAX_EXTENSIONS] = {
+   NULL
+};
+
+/**
+ * This is a contructor function for the megadriver dynamic library.
+ *
+ * When the driver is dlopen'ed, this function will run. It will
+ * search for the name of the foo_dri.so file that was opened using
+ * the dladdr function.
+ *
+ * After finding foo's name, it will call __driDriverGetExtensions_foo
+ * and use the return to update __driDriverExtensions to enable
+ * compatibility with older DRI driver loaders.
+ */
+__attribute__((constructor)) static void
+megadriver_stub_init(void)
+{
+   Dl_info info;
+   char *driver_name;
+   size_t name_len;
+   char *get_extensions_name;
+   const __DRIextension **(*get_extensions)(void);
+   const __DRIextension **extensions;
+   int i;
+
+   /* Call dladdr on __driDriverExtensions. We are really
+* interested in the returned info.dli_fname so we can
+* figure out the path name of the library being loaded.
+*/
+   i = dladdr((void*) __driDriverExtensions, info);
+   if (i == 0)
+  return;
+
+   /* Search for the last '/' character in the path. */
+   driver_name = strrchr(info.dli_fname, '/');
+   if (driver_name != NULL) {
+  /* Skip '/' character */
+  driver_name++;
+   } else {
+  /* Try using the start of the path */
+  driver_name = (char*) info.dli_fname;
+   }
+
+   /* Make sure the path ends with _dri.so */
+   name_len = strlen(driver_name);
+   i = name_len - LIB_PATH_SUFFIX_LENGTH;
+   if (i  0 || strcmp(driver_name + i, LIB_PATH_SUFFIX) != 0)
+  return;
+
+   /* Duplicate the string so we can modify it.
+* So far we've been using info.dli_fname.
+*/
+   driver_name = strdup(driver_name);
+   if (!driver_name)
+  return;
+
+   /* The path ends with _dri.so. Chop this part of the
+* string off. Then we'll have the driver's final name.
+*/
+   driver_name[i] = '\0';
+
+   i = asprintf(get_extensions_name, %s_%s,
+__DRI_DRIVER_GET_EXTENSIONS, driver_name);
+   free(driver_name);
+   if (i == -1)
+  return;
+
+   /* dlsym to get the driver's get extensions function. We
+* don't have the dlopen handle, so we have to use
+* RTLD_DEFAULT. It seems unlikely that the symbol will
+* be found in another library, but this isn't optimal.
+*/
+   get_extensions = dlsym(RTLD_DEFAULT, get_extensions_name);
+   free(get_extensions_name);
+   if (!get_extensions)
+  return;
+
+   /* Use the newer DRI loader entrypoint to find extensions.
+* We will then expose these extensions via the older
+* __driDriverExtensions symbol.
+*/
+   extensions = get_extensions();
+
+   /* Copy the extensions into the __driDriverExtensions array
+* we declared.
+*/
+   for (i = 0; i  ARRAY_SIZE(__driDriverExtensions); i++) {
+  __driDriverExtensions[i] = extensions[i];
+  if (extensions[i] == NULL)
+ break;
+   }
+
+   /* If the driver had more extensions than we reserved, then
+* bail out.
+*/
+   if (i == ARRAY_SIZE(__driDriverExtensions)) {
+  __driDriverExtensions[0] = NULL;
+  fprintf(stderr, Megadriver stub did not reserve enough extension 
+  slots.\n);
+  return;
+   }
+}
+
+#endif // #ifdef _GNU_SOURCE
 
 static const
 __DRIconfig **stub_error_init_screen(__DRIscreen *psp)
--

Re: [Mesa-dev] [PATCH v2] dri megadriver_stub: provide compatibility with older DRI loader

2013-12-06 Thread Matt Turner

On Fri, Dec 6, 2013 at 7:11 PM, Jordan Justen jordan.l.jus...@intel.com wrote:
 To help the transition period when DRI loaders are being updated
 to support the newer __driDriverExtensions_foo mechanism,
 we populate __DRIextension with the extensions returned
 by __driDriverExtensions_foo during a library contructor
 function.

 We find the driver foo's name by using the dladdr function
 which gives the path of the dynamic library's name that
 was being loaded.

 v2:
  * dladdr on public symbol __driDriverExtensions rather
than static megadriver_stub_init.
  * Incorporate fixes and suggestions from Keith

 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
 Cc: 10.0 mesa-sta...@lists.freedesktop.org
 ---
  src/mesa/drivers/dri/common/megadriver_stub.c | 125 
 ++
  1 file changed, 125 insertions(+)

 diff --git a/src/mesa/drivers/dri/common/megadriver_stub.c 
 b/src/mesa/drivers/dri/common/megadriver_stub.c
 index 6bf5d73..cb1078d 100644
 --- a/src/mesa/drivers/dri/common/megadriver_stub.c
 +++ b/src/mesa/drivers/dri/common/megadriver_stub.c
 @@ -23,6 +23,131 @@

  #include stdio.h
  #include dri_util.h
 +#include dlfcn.h
 +#include main/macros.h
 +
 +/* The extensions that allow the megadriver stub to provide backward
 + * compatibility for the older DRI driver loader require GNU
 + * extensions from dlfcn.h.
 + */
 +#ifdef _GNU_SOURCE

More specifically, what extension do we use?

 +#define MEGADRIVER_STUB_MAX_EXTENSIONS 10
 +#define LIB_PATH_SUFFIX _dri.so
 +#define LIB_PATH_SUFFIX_LENGTH (sizeof(LIB_PATH_SUFFIX)-1)
 +
 +/* This is the table of extensions that the loader will dlsym() for.
 + *
 + * Initially it is empty for the megadriver stub, but the library
 + * contructor may initialize it based on the name of the library that

constructor

 + * is being loaded.
 + */
 +PUBLIC const __DRIextension *
 +__driDriverExtensions[MEGADRIVER_STUB_MAX_EXTENSIONS] = {
 +   NULL
 +};
 +
 +/**
 + * This is a contructor function for the megadriver dynamic library.

constructor

 + *
 + * When the driver is dlopen'ed, this function will run. It will
 + * search for the name of the foo_dri.so file that was opened using
 + * the dladdr function.
 + *
 + * After finding foo's name, it will call __driDriverGetExtensions_foo
 + * and use the return to update __driDriverExtensions to enable
 + * compatibility with older DRI driver loaders.
 + */
 +__attribute__((constructor)) static void
 +megadriver_stub_init(void)
 +{
 +   Dl_info info;
 +   char *driver_name;
 +   size_t name_len;
 +   char *get_extensions_name;
 +   const __DRIextension **(*get_extensions)(void);
 +   const __DRIextension **extensions;
 +   int i;
 +
 +   /* Call dladdr on __driDriverExtensions. We are really
 +* interested in the returned info.dli_fname so we can
 +* figure out the path name of the library being loaded.
 +*/
 +   i = dladdr((void*) __driDriverExtensions, info);
 +   if (i == 0)
 +  return;
 +
 +   /* Search for the last '/' character in the path. */
 +   driver_name = strrchr(info.dli_fname, '/');
 +   if (driver_name != NULL) {
 +  /* Skip '/' character */
 +  driver_name++;
 +   } else {
 +  /* Try using the start of the path */
 +  driver_name = (char*) info.dli_fname;
 +   }
 +
 +   /* Make sure the path ends with _dri.so */
 +   name_len = strlen(driver_name);
 +   i = name_len - LIB_PATH_SUFFIX_LENGTH;
 +   if (i  0 || strcmp(driver_name + i, LIB_PATH_SUFFIX) != 0)
 +  return;
 +
 +   /* Duplicate the string so we can modify it.
 +* So far we've been using info.dli_fname.
 +*/
 +   driver_name = strdup(driver_name);
 +   if (!driver_name)
 +  return;
 +
 +   /* The path ends with _dri.so. Chop this part of the
 +* string off. Then we'll have the driver's final name.
 +*/
 +   driver_name[i] = '\0';
 +
 +   i = asprintf(get_extensions_name, %s_%s,
 +__DRI_DRIVER_GET_EXTENSIONS, driver_name);
 +   free(driver_name);
 +   if (i == -1)
 +  return;
 +
 +   /* dlsym to get the driver's get extensions function. We
 +* don't have the dlopen handle, so we have to use
 +* RTLD_DEFAULT. It seems unlikely that the symbol will
 +* be found in another library, but this isn't optimal.
 +*/
 +   get_extensions = dlsym(RTLD_DEFAULT, get_extensions_name);
 +   free(get_extensions_name);
 +   if (!get_extensions)
 +  return;
 +
 +   /* Use the newer DRI loader entrypoint to find extensions.
 +* We will then expose these extensions via the older
 +* __driDriverExtensions symbol.
 +*/
 +   extensions = get_extensions();
 +
 +   /* Copy the extensions into the __driDriverExtensions array
 +* we declared.
 +*/
 +   for (i = 0; i  ARRAY_SIZE(__driDriverExtensions); i++) {
 +  __driDriverExtensions[i] = extensions[i];
 +  if (extensions[i] == NULL)
 + break;
 +   }
 +
 +   /* If the driver had more extensions than we reserved, then
 +* bail out.
 +*/
 +   if (i ==

Re: [Mesa-dev] [Mesa-stable] [PATCH v2] dri megadriver_stub: provide compatibility with older DRI loader

2013-12-06 Thread Ian Romanick

On 12/06/2013 07:54 PM, Matt Turner wrote:
 On Fri, Dec 6, 2013 at 7:11 PM, Jordan Justen jordan.l.jus...@intel.com 
 wrote:
 To help the transition period when DRI loaders are being updated
 to support the newer __driDriverExtensions_foo mechanism,
 we populate __DRIextension with the extensions returned
 by __driDriverExtensions_foo during a library contructor
 function.

 We find the driver foo's name by using the dladdr function
 which gives the path of the dynamic library's name that
 was being loaded.

 v2:
  * dladdr on public symbol __driDriverExtensions rather
than static megadriver_stub_init.
  * Incorporate fixes and suggestions from Keith

 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
 Cc: 10.0 mesa-sta...@lists.freedesktop.org
 ---
  src/mesa/drivers/dri/common/megadriver_stub.c | 125 
 ++
  1 file changed, 125 insertions(+)

 diff --git a/src/mesa/drivers/dri/common/megadriver_stub.c 
 b/src/mesa/drivers/dri/common/megadriver_stub.c
 index 6bf5d73..cb1078d 100644
 --- a/src/mesa/drivers/dri/common/megadriver_stub.c
 +++ b/src/mesa/drivers/dri/common/megadriver_stub.c
 @@ -23,6 +23,131 @@

  #include stdio.h
  #include dri_util.h
 +#include dlfcn.h
 +#include main/macros.h
 +
 +/* The extensions that allow the megadriver stub to provide backward
 + * compatibility for the older DRI driver loader require GNU
 + * extensions from dlfcn.h.
 + */
 +#ifdef _GNU_SOURCE
 
 More specifically, what extension do we use?
 
 +#define MEGADRIVER_STUB_MAX_EXTENSIONS 10
 +#define LIB_PATH_SUFFIX _dri.so
 +#define LIB_PATH_SUFFIX_LENGTH (sizeof(LIB_PATH_SUFFIX)-1)
 +
 +/* This is the table of extensions that the loader will dlsym() for.
 + *
 + * Initially it is empty for the megadriver stub, but the library
 + * contructor may initialize it based on the name of the library that
 
 constructor
 
 + * is being loaded.
 + */
 +PUBLIC const __DRIextension *
 +__driDriverExtensions[MEGADRIVER_STUB_MAX_EXTENSIONS] = {
 +   NULL
 +};
 +
 +/**
 + * This is a contructor function for the megadriver dynamic library.
 
 constructor
 
 + *
 + * When the driver is dlopen'ed, this function will run. It will
 + * search for the name of the foo_dri.so file that was opened using
 + * the dladdr function.
 + *
 + * After finding foo's name, it will call __driDriverGetExtensions_foo
 + * and use the return to update __driDriverExtensions to enable
 + * compatibility with older DRI driver loaders.
 + */
 +__attribute__((constructor)) static void
 +megadriver_stub_init(void)
 +{
 +   Dl_info info;
 +   char *driver_name;
 +   size_t name_len;
 +   char *get_extensions_name;
 +   const __DRIextension **(*get_extensions)(void);
 +   const __DRIextension **extensions;
 +   int i;
 +
 +   /* Call dladdr on __driDriverExtensions. We are really
 +* interested in the returned info.dli_fname so we can
 +* figure out the path name of the library being loaded.
 +*/
 +   i = dladdr((void*) __driDriverExtensions, info);
 +   if (i == 0)
 +  return;
 +
 +   /* Search for the last '/' character in the path. */
 +   driver_name = strrchr(info.dli_fname, '/');
 +   if (driver_name != NULL) {
 +  /* Skip '/' character */
 +  driver_name++;
 +   } else {
 +  /* Try using the start of the path */
 +  driver_name = (char*) info.dli_fname;
 +   }
 +
 +   /* Make sure the path ends with _dri.so */
 +   name_len = strlen(driver_name);
 +   i = name_len - LIB_PATH_SUFFIX_LENGTH;
 +   if (i  0 || strcmp(driver_name + i, LIB_PATH_SUFFIX) != 0)
 +  return;
 +
 +   /* Duplicate the string so we can modify it.
 +* So far we've been using info.dli_fname.
 +*/
 +   driver_name = strdup(driver_name);
 +   if (!driver_name)
 +  return;
 +
 +   /* The path ends with _dri.so. Chop this part of the
 +* string off. Then we'll have the driver's final name.
 +*/
 +   driver_name[i] = '\0';
 +
 +   i = asprintf(get_extensions_name, %s_%s,
 +__DRI_DRIVER_GET_EXTENSIONS, driver_name);
 +   free(driver_name);
 +   if (i == -1)
 +  return;
 +
 +   /* dlsym to get the driver's get extensions function. We
 +* don't have the dlopen handle, so we have to use
 +* RTLD_DEFAULT. It seems unlikely that the symbol will
 +* be found in another library, but this isn't optimal.
 +*/
 +   get_extensions = dlsym(RTLD_DEFAULT, get_extensions_name);
 +   free(get_extensions_name);
 +   if (!get_extensions)
 +  return;
 +
 +   /* Use the newer DRI loader entrypoint to find extensions.
 +* We will then expose these extensions via the older
 +* __driDriverExtensions symbol.
 +*/
 +   extensions = get_extensions();
 +
 +   /* Copy the extensions into the __driDriverExtensions array
 +* we declared.
 +*/
 +   for (i = 0; i  ARRAY_SIZE(__driDriverExtensions); i++) {
 +  __driDriverExtensions[i] = extensions[i];
 +  if (extensions[i] == NULL)
 + break;
 +   }
 +
 +   /* If the driver had more extensions than we reserved, then

Re: [Mesa-dev] [Mesa-stable] [PATCH v2] dri megadriver_stub: provide compatibility with older DRI loader

2013-12-06 Thread Matt Turner

On Fri, Dec 6, 2013 at 7:58 PM, Ian Romanick i...@freedesktop.org wrote:
 This part gets build using C99, right?  If so, that should be fine.

It's fine technically, but we don't use // comments in any other .c
files in i965 except for two (one added by Jordan).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nv50: enable H.264 for NV98+ (VP3, VP4.0)

2013-12-06 Thread Ilia Mirkin

Create the ref_bo without any storage type flags set for now. This can
probably be split up somehow later on, but this seems to work.

Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---

Would be great if someone could see if this also makes MPEG4 work on NVA3+. In
order to do that, remove the if (chipset  0xc0) conditional entirely from
nouveau_vp3_video.c (which I modify in this patch).

 src/gallium/drivers/nouveau/nouveau_vp3_video.c | 5 +++--
 src/gallium/drivers/nouveau/nv50/nv98_video.c   | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video.c 
b/src/gallium/drivers/nouveau/nouveau_vp3_video.c
index 07ce016..2f4196c 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video.c
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video.c
@@ -362,10 +362,11 @@ nouveau_vp3_screen_get_video_param(struct pipe_screen 
*pscreen,
enum pipe_video_format codec = u_reduce_video_profile(profile);
switch (param) {
case PIPE_VIDEO_CAP_SUPPORTED:
-  /* For now, h264 and mpeg4 don't work on pre-nvc0. */
+  /* For now, mpeg4 doesn't work on pre-nvc0. */
   if (chipset  0xc0)
  return codec == PIPE_VIDEO_FORMAT_MPEG12 ||
-codec == PIPE_VIDEO_FORMAT_VC1;
+codec == PIPE_VIDEO_FORMAT_VC1 ||
+codec == PIPE_VIDEO_FORMAT_MPEG4_AVC;
   /* In the general case, this should work, once the pre-nvc0 problems are
* resolved. */
   return profile = PIPE_VIDEO_PROFILE_MPEG1  (
diff --git a/src/gallium/drivers/nouveau/nv50/nv98_video.c 
b/src/gallium/drivers/nouveau/nv50/nv98_video.c
index 069481d..f748c81 100644
--- a/src/gallium/drivers/nouveau/nv50/nv98_video.c
+++ b/src/gallium/drivers/nouveau/nv50/nv98_video.c
@@ -200,7 +200,7 @@ nv98_create_decoder(struct pipe_context *context,
dec-ref_stride = mb(templ-width)*16 * (mb_half(templ-height)*32 + 
nouveau_vp3_video_align(templ-height)/2);
ret = nouveau_bo_new(screen-device, NOUVEAU_BO_VRAM, 0,
 dec-ref_stride * (templ-max_references+2) + tmp_size,
-cfg, dec-ref_bo);
+NULL, dec-ref_bo);
if (ret)
   goto fail;
 
-- 
1.8.3.2

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

[Mesa-dev] [PATCH] Fix line number on no matching function call

[Mesa-dev] [RFC PATCH] dri megadriver_stub: provide compatibility with older DRI loader

Re: [Mesa-dev] [PATCH 00/11] Core mesa changes for ARB_shader_image_load_store.

Re: [Mesa-dev] [PATCH 2/6] glsl: Add ir support for `sample` qualifier; adjust compiler and linker

Re: [Mesa-dev] [PATCH 5/6] st/mesa: set correct PIPE_CLEAR_COLORn flags

Re: [Mesa-dev] [PATCH 5/6] st/mesa: set correct PIPE_CLEAR_COLORn flags

Re: [Mesa-dev] [PATCH 03/11] mesa: Add state data structures requried for ARB_shader_image_load_store.

[Mesa-dev] Unreviewed patches marked for stable

Re: [Mesa-dev] [PATCH] Fix line number on no matching function call

Re: [Mesa-dev] Unreviewed patches marked for stable

Re: [Mesa-dev] [PATCH 06/11] mesa: Add MESA_FORMAT_ABGR2101010.

Re: [Mesa-dev] [Mesa-stable] Unreviewed patches marked for stable

Re: [Mesa-dev] [Mesa-stable] Unreviewed patches marked for stable

Re: [Mesa-dev] [PATCH 4/5] radeonsi: fix binding the dummy pixel shader

Re: [Mesa-dev] [PATCH 2/6] glsl: Add ir support for `sample` qualifier; adjust compiler and linker

Re: [Mesa-dev] [RFC PATCH] dri megadriver_stub: provide compatibility with older DRI loader

Re: [Mesa-dev] [PATCH 08/11] mesa: Implement the GL entry points defined by ARB_shader_image_load_store.

[Mesa-dev] [PATCH] r600/llvm: Allow arbitrary amount of temps in tgsi to llvm

Re: [Mesa-dev] [PATCH 01/11] glapi: Update dispatch XML files for ARB_shader_image_load_store.

Re: [Mesa-dev] [PATCH 00/11] Core mesa changes for ARB_shader_image_load_store.

Re: [Mesa-dev] [RFC PATCH] dri megadriver_stub: provide compatibility with older DRI loader

Re: [Mesa-dev] [PATCH 2/6] mesa: fix interpretation of glClearBuffer(drawbuffer)

Re: [Mesa-dev] [RFC PATCH] dri megadriver_stub: provide compatibility with older DRI loader

Re: [Mesa-dev] [RFC PATCH] dri megadriver_stub: provide compatibility with older DRI loader

Re: [Mesa-dev] [PATCH 2/6] mesa: fix interpretation of glClearBuffer(drawbuffer)

Re: [Mesa-dev] [PATCH] r600/llvm: Allow arbitrary amount of temps in tgsi to llvm

[Mesa-dev] [PATCH v2] dri megadriver_stub: provide compatibility with older DRI loader

Re: [Mesa-dev] [PATCH v2] dri megadriver_stub: provide compatibility with older DRI loader

Re: [Mesa-dev] [Mesa-stable] [PATCH v2] dri megadriver_stub: provide compatibility with older DRI loader

Re: [Mesa-dev] [Mesa-stable] [PATCH v2] dri megadriver_stub: provide compatibility with older DRI loader

[Mesa-dev] [PATCH] nv50: enable H.264 for NV98+ (VP3, VP4.0)

31 matches

Site Navigation

Mail list logo

Footer information