[Mesa-dev] [Bug 39017] [bisected] Segfault in Gallium drivers in Mupen64Plus

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

--- Comment #10 from Diego Viola diego.vi...@gmail.com 2012-02-02 00:36:13 
PST ---
I'm actually not sure if this is the same issue the reporter was experiencing.

But setting ColorQuality to 1 in [Video-Rice] section worked as a workaround
for me.

Like this:

[Video-Rice]
# Color bit depth for rendering window (0=32 bits, 1=16 bits)
ColorQuality = 1

I set that in this file:

/home/diego/.config/mupen64plus

Then mupen64plus doesn't crash/segfault.

This is with nouveau driver, Arch Linux x86-64, Linux 3.2.2, mupen64plus
1.99.4.

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


[Mesa-dev] [Bug 39017] [bisected] Segfault in Gallium drivers in Mupen64Plus

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

Diego Viola diego.vi...@gmail.com changed:

   What|Removed |Added

 CC||diego.vi...@gmail.com

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


[Mesa-dev] [Bug 45420] undefined reference to `LLVMInitializeARMDisassembler'

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

José Fonseca jfons...@vmware.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #8 from José Fonseca jfons...@vmware.com 2012-02-02 01:03:50 PST 
---
I pushed ojab's patch. Thanks Vinson and ojab.

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


Re: [Mesa-dev] patches (Re: undefined C++ GLSL symbol error)

2012-02-02 Thread Pekka Paalanen
On Wed, 1 Feb 2012 06:14:40 -0800 (PST)
Jose Fonseca jfons...@vmware.com wrote:

 - Original Message -
  On Wed, 1 Feb 2012 05:03:21 -0800 (PST)
  Jose Fonseca jfons...@vmware.com wrote:
  
   I wonder if people have use any tools to facility applying patches
   posted to mesa, as for me locate, save, and applying them takes a
   lot of time, and more often than not fails due to white space
   munging. I barely can keep up with the review requests anyway.
   
  
  If a patch is malformatted to begin with, I can't help it. But, if
  your email client happens to support running external commands on
  mail
  files, I have a script that applies them to a given local git repo,
  launching a terminal window for it and optionally running it though
  the
  kernel checkpatch.pl. On any errors, it drops you to a shell.
  
  Personally I use claws-mail, and could share my setup, if
  anyone is interested in homebrewn solution for the save  apply part.
 
 I use webmail (mostly due to namely calendar integration, quick search of all 
 email, easy access anywhere, etc), which makes this difficult.  So I probably 
 would need to tag and/or move the mail messages w/ the patches to an IMAP 
 folder, and then have the fetchmail + apply + etc on the script which I'd run 
 from a git checkout.
 
 I wouldn't mind take a look to your script.

Attached. The scripts rely on me selecting the emails in order, and
then clicking a menu item that runs the UI script with the email file
names as arguments.


Thanks,
pq



claws-git-am.bash
Description: Binary data


claws-git-am-UI.bash
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa: Fix copy-and-paste error in _mesa_pack_rgba_span_float

2012-02-02 Thread Kenneth Graunke

On 02/01/2012 09:50 PM, Ian Romanick wrote:

From: Ian Romanickian.d.roman...@intel.com

GL_RG_INTEGER only has two components, not three.  I'll be surprised
if anyone ever tries to glReadPixels(..., GL_SHORT, GL_RG_INTEGER,
...).  This was found by inspection.


Me too; good catch nonetheless.

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


[Mesa-dev] [PATCH] mapi/glapi: Never use a generic no-op entry-point on Windows.

2012-02-02 Thread jfonseca
From: José Fonseca jfons...@vmware.com

When GLAPIENTRY is __stdcall (ie Windows), the stack is popped by the
callee making the number/type of arguments significant, therefore
using a generic no-op causes stack corruption for many entry-points.
---
 src/mapi/glapi/glapi_nop.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/mapi/glapi/glapi_nop.c b/src/mapi/glapi/glapi_nop.c
index 9b09297..69b1ae6 100644
--- a/src/mapi/glapi/glapi_nop.c
+++ b/src/mapi/glapi/glapi_nop.c
@@ -51,7 +51,11 @@ _glapi_set_warning_func(_glapi_proc func)
 {
 }
 
-#ifdef DEBUG
+/*
+ * When GLAPIENTRY is __stdcall (i.e. Windows), the stack is popped by the
+ * callee making the number/type of arguments significant.
+ */
+#if defined(_WIN32) || defined(DEBUG)
 
 /**
  * Called by each of the no-op GL entrypoints.
@@ -59,7 +63,7 @@ _glapi_set_warning_func(_glapi_proc func)
 static int
 Warn(const char *func)
 {
-#if !defined(_WIN32_WCE)
+#if defined(DEBUG)  !defined(_WIN32_WCE)
if (getenv(MESA_DEBUG) || getenv(LIBGL_DEBUG)) {
   fprintf(stderr, GL User Error: gl%s called without a rendering 
context\n,
   func);
-- 
1.7.7.3

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


Re: [Mesa-dev] Mesa (master): dri: make sure to build libdricommon.la

2012-02-02 Thread Jon TURNEY
On 27/01/2012 20:20, Matt Turner wrote:
 On Fri, Jan 27, 2012 at 8:11 PM, Jon TURNEY wrote:
 On 27/01/2012 08:03, Eric Anholt wrote:
 On Thu, 26 Jan 2012 16:32:24 -0800 (PST), matts...@kemper.freedesktop.org 
 (Matt Turner) wrote:
 Module: Mesa
 Branch: master
 Commit: 80aa78142d12b21dd7d4f0edc786af98a159a80f
 URL:
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=80aa78142d12b21dd7d4f0edc786af98a159a80f

 Author: Matt Turner matts...@gmail.com
 Date:   Thu Jan 26 19:31:12 2012 -0500

 dri: make sure to build libdricommon.la

 Ouch.  Sorry about this, folks, I built with a dirty tree and didn't
 notice that the rebase off of the drirc changes wasn't good enough.

 This commit breaks the ability to build when ./configured -with-driver=dri
 --disable-driglx-direct --with-dri-drivers=swrast for platforms which don't
 have DRM (See [1]), as it tries to build libdricommon.la even if we aren't
 building a dri driver which requires it.

 Attached is a patch which fixes this, although I'm not sure if that's the 
 best
 way of solving this problem (it might make more sense to conditionalize on
 DRI_DIRS containing something other than swrast if all dri drivers are going
 to use libdricommon)

Attached is a patch which fixes this the other way, which I think is probably
better.

 and it looks like swrast is still broken anyway. It should have
 ../common/utils.c ../common/drisw_util.c in its sources.

I can't see a problem?  These are included in SWRAST_C_FILES via
SWRAST_COMMON_FILES
From 97438ef51aaed032ced49f9ab2568a57969176df Mon Sep 17 00:00:00 2001
From: Jon TURNEY jon.tur...@dronecode.org.uk
Date: Thu, 2 Feb 2012 10:39:04 +
Subject: [PATCH] dri: Don't build libdricommon.la if we don't need it

Refine 80aa78142d12b21dd7d4f0edc786af98a159a80f dri: make sure to build 
libdricommon.la
so we don't build libdricommon if we aren't building a dri driver which needs 
it (i.e.
if we are just building swrast)

In particular, this restores the ability to build the swrast dri driver without 
having to
have a xf86drm.h

Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
 configure.ac |6 +-
 src/mesa/drivers/dri/Makefile.am |6 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index f7c0814..7af8319 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1240,11 +1240,14 @@ if test x$enable_dri = xyes; then
LIBS=$save_LIBS
 fi
 
-# libdrm is required for all except swrast
+# if we are building any dri driver other than swrast ...
 if test -n $DRI_DIRS -a x$DRI_DIRS != xswrast; then
+# ... libdrm is required
 if test x$have_libdrm != xyes; then
 AC_MSG_ERROR([DRI drivers requires libdrm = $LIBDRM_REQUIRED])
 fi
+# ... and build dricommon
+HAVE_COMMON_DRI=yes
 fi
 
 # put all the necessary libs together
@@ -1309,6 +1312,7 @@ AM_CONDITIONAL(HAVE_NOUVEAU_DRI, test x$HAVE_NOUVEAU_DRI 
= xyes)
 AM_CONDITIONAL(HAVE_R200_DRI, test x$HAVE_R200_DRI = xyes)
 AM_CONDITIONAL(HAVE_RADEON_DRI, test x$HAVE_RADEON_DRI = xyes)
 AM_CONDITIONAL(HAVE_SWRAST_DRI, test x$HAVE_SWRAST_DRI = xyes)
+AM_CONDITIONAL(HAVE_COMMON_DRI, test x$HAVE_COMMON_DRI = xyes)
 
 dnl
 dnl OSMesa configuration
diff --git a/src/mesa/drivers/dri/Makefile.am b/src/mesa/drivers/dri/Makefile.am
index 8b93582..48d3685 100644
--- a/src/mesa/drivers/dri/Makefile.am
+++ b/src/mesa/drivers/dri/Makefile.am
@@ -1,4 +1,8 @@
-SUBDIRS = common
+SUBDIRS =
+
+if HAVE_COMMON_DRI
+SUBDIRS+=common
+endif
 
 if HAVE_I915_DRI
 SUBDIRS+=i915
-- 
1.7.5.1

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


[Mesa-dev] [PATCH] r600g: Use a fake reloc to sleep for fences

2012-02-02 Thread Simon Farnsworth
r300g is able to sleep until a fence completes rather than busywait because
it creates a special buffer object and relocation that stays busy until the
CS containing the fence is finished.

Copy the idea into r600g, and use it to sleep if the user asked for an
infinite wait, falling back to busywaiting if the user provided a timeout.

Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---

v2: Address Michel's review comments.

The fake bo is now unconditional, and is unreferenced when the fence is
moved to the fence pool by fence_reference. This entailed shifting to
r600_resource, which cleaned the code up a little to boot.

 src/gallium/drivers/r600/r600.h|2 +-
 src/gallium/drivers/r600/r600_hw_context.c |9 -
 src/gallium/drivers/r600/r600_pipe.c   |9 -
 src/gallium/drivers/r600/r600_pipe.h   |1 +
 4 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/r600/r600.h b/src/gallium/drivers/r600/r600.h
index baf09c1..c5813c2 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -284,7 +284,7 @@ void r600_context_queries_resume(struct r600_context *ctx);
 void r600_query_predication(struct r600_context *ctx, struct r600_query 
*query, int operation,
int flag_wait);
 void r600_context_emit_fence(struct r600_context *ctx, struct r600_resource 
*fence,
- unsigned offset, unsigned value);
+ unsigned offset, unsigned value, struct 
r600_resource **sleep_bo);
 void r600_context_flush_all(struct r600_context *ctx, unsigned flush_flags);
 void r600_context_flush_dest_caches(struct r600_context *ctx);
 
diff --git a/src/gallium/drivers/r600/r600_hw_context.c 
b/src/gallium/drivers/r600/r600_hw_context.c
index 8eb8e6d..acfa494 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -1603,7 +1603,7 @@ void r600_context_flush(struct r600_context *ctx, 
unsigned flags)
}
 }
 
-void r600_context_emit_fence(struct r600_context *ctx, struct r600_resource 
*fence_bo, unsigned offset, unsigned value)
+void r600_context_emit_fence(struct r600_context *ctx, struct r600_resource 
*fence_bo, unsigned offset, unsigned value, struct r600_resource **sleep_bo)
 {
uint64_t va;
 
@@ -1623,6 +1623,13 @@ void r600_context_emit_fence(struct r600_context *ctx, 
struct r600_resource *fen
ctx-pm4[ctx-pm4_cdwords++] = 0;   /* DATA_HI */
ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_NOP, 0, 0);
ctx-pm4[ctx-pm4_cdwords++] = r600_context_bo_reloc(ctx, fence_bo, 
RADEON_USAGE_WRITE);
+
+   /* Create a dummy BO so that fence_finish without a timeout can sleep 
waiting for completion */
+   *sleep_bo = (struct r600_resource*)
+   pipe_buffer_create(ctx-screen-screen, 
PIPE_BIND_CUSTOM,
+  PIPE_USAGE_STAGING, 1);
+   /* Add the fence as a dummy relocation. */
+   r600_context_bo_reloc(ctx, *sleep_bo, RADEON_USAGE_READWRITE);
 }
 
 static unsigned r600_query_read_result(char *map, unsigned start_index, 
unsigned end_index,
diff --git a/src/gallium/drivers/r600/r600_pipe.c 
b/src/gallium/drivers/r600/r600_pipe.c
index c38fbc5..748869a 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -115,7 +115,7 @@ static struct r600_fence *r600_create_fence(struct 
r600_pipe_context *ctx)
pipe_reference_init(fence-reference, 1);
 
rscreen-fences.data[fence-index] = 0;
-   r600_context_emit_fence(ctx-ctx, rscreen-fences.bo, fence-index, 1);
+   r600_context_emit_fence(ctx-ctx, rscreen-fences.bo, fence-index, 1, 
fence-sleep_bo);
 out:
pipe_mutex_unlock(rscreen-fences.mutex);
return fence;
@@ -572,6 +572,7 @@ static void r600_fence_reference(struct pipe_screen 
*pscreen,
if (pipe_reference((*oldf)-reference, newf-reference)) {
struct r600_screen *rscreen = (struct r600_screen *)pscreen;
pipe_mutex_lock(rscreen-fences.mutex);
+   pipe_resource_reference((struct 
pipe_resource**)(*oldf)-sleep_bo, NULL);
LIST_ADDTAIL((*oldf)-head, rscreen-fences.pool);
pipe_mutex_unlock(rscreen-fences.mutex);
}
@@ -605,6 +606,12 @@ static boolean r600_fence_finish(struct pipe_screen 
*pscreen,
}
 
while (rscreen-fences.data[rfence-index] == 0) {
+   /* Special-case infinite timeout */
+   if (timeout == PIPE_TIMEOUT_INFINITE) {
+   rscreen-ws-buffer_wait(rfence-sleep_bo-buf, 
RADEON_USAGE_READWRITE);
+   continue;
+   }
+
if (++spins % 256)
continue;
 #ifdef PIPE_OS_UNIX
diff --git a/src/gallium/drivers/r600/r600_pipe.h 
b/src/gallium/drivers/r600/r600_pipe.h
index 9ba60c8..df56560 100644
--- 

Re: [Mesa-dev] [PATCH 0/2] gallium/postprocess: some fixes

2012-02-02 Thread Lauri Kasanen
 The first patch fixes a bug where the depth filters may have used an old 
 depth buffer.
 The second adds safeguards suggested by Michael Dänzer.
 
 Could they both be applied to the stable 8.0 tree too?

Hi list

Ping on the above. If at all possible, I'd like the 8.0 release have all three 
PP fixes, Michel's and these two.

Also apologies to Michel for mistyping your name.

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


[Mesa-dev] [PATCH] draw: Avoid NULL pointer dereference when binding NULL fragment shaders.

2012-02-02 Thread jfonseca
From: José Fonseca jfons...@vmware.com

Now that the draw module avoids flushing, it may flush precisely when
binding a NULL shader, so care must be taken when restoring the original
fragment shader.
---
 src/gallium/auxiliary/draw/draw_pipe_aaline.c   |2 +-
 src/gallium/auxiliary/draw/draw_pipe_aapoint.c  |2 +-
 src/gallium/auxiliary/draw/draw_pipe_pstipple.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c 
b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
index 0b368da..ea0a4fb 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
@@ -738,7 +738,7 @@ aaline_flush(struct draw_stage *stage, unsigned flags)
 
/* restore original frag shader, texture, sampler state */
draw-suspend_flushing = TRUE;
-   aaline-driver_bind_fs_state(pipe, aaline-fs-driver_fs);
+   aaline-driver_bind_fs_state(pipe, aaline-fs ? aaline-fs-driver_fs : 
NULL);
aaline-driver_bind_sampler_states(pipe, aaline-num_samplers,
   aaline-state.sampler);
aaline-driver_set_sampler_views(pipe,
diff --git a/src/gallium/auxiliary/draw/draw_pipe_aapoint.c 
b/src/gallium/auxiliary/draw/draw_pipe_aapoint.c
index 248f26b..a900dd3 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aapoint.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aapoint.c
@@ -744,7 +744,7 @@ aapoint_flush(struct draw_stage *stage, unsigned flags)
 
/* restore original frag shader */
draw-suspend_flushing = TRUE;
-   aapoint-driver_bind_fs_state(pipe, aapoint-fs-driver_fs);
+   aapoint-driver_bind_fs_state(pipe, aapoint-fs ? aapoint-fs-driver_fs : 
NULL);
 
/* restore original rasterizer state */
if (draw-rast_handle) {
diff --git a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c 
b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
index 0401a45..62c54b3 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
@@ -565,7 +565,7 @@ pstip_flush(struct draw_stage *stage, unsigned flags)
 
/* restore original frag shader, texture, sampler state */
draw-suspend_flushing = TRUE;
-   pstip-driver_bind_fs_state(pipe, pstip-fs-driver_fs);
+   pstip-driver_bind_fs_state(pipe, pstip-fs ? pstip-fs-driver_fs : NULL);
pstip-driver_bind_sampler_states(pipe, pstip-num_samplers,
  pstip-state.samplers);
pstip-driver_set_sampler_views(pipe,
-- 
1.7.7.3

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


Re: [Mesa-dev] [PATCH] mesa: Add unpack_uint_z_row support for floating-point depth buffers

2012-02-02 Thread Henri Verbeet
On 1 February 2012 23:12, Brian Paul bri...@vmware.com wrote:
 +static void
 +unpack_uint_z_Z32_FLOAT(const void *src, GLuint *dst, GLuint n)
 +{
 +   const float *s = ((const float *)src);


 More parens than necessary there.

The entire cast is unnecessary, IMO. But of course that would apply to
the other functions in that file as well.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/3] mesa: new _mesa_error_check_format_and_type() function

2012-02-02 Thread Brian Paul
This replaces the _mesa_is_legal_format_and_type() function.

According to the spec, some invalid format/type combinations to
glDrawPixels, ReadPixels and glTexImage should generate
GL_INVALID_ENUM but others should generate GL_INVALID_OPERATION.

With the old function we didn't make that distinction and generated
GL_INVALID_ENUM errors instead of GL_INVALID_OPERATION.  The new
function returns one of those errors or GL_NO_ERROR.

This will also let us remove some redundant format/type checks in
follow-on commit.
---
 src/mesa/main/image.c   |  212 ++-
 src/mesa/main/image.h   |6 +-
 src/mesa/main/readpix.c |9 +-
 src/mesa/main/texgetimage.c |   16 ++--
 src/mesa/main/teximage.c|   25 ++---
 5 files changed, 174 insertions(+), 94 deletions(-)

diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c
index 3491704..cc44468 100644
--- a/src/mesa/main/image.c
+++ b/src/mesa/main/image.c
@@ -356,18 +356,79 @@ _mesa_bytes_per_pixel( GLenum format, GLenum type )
 
 
 /**
- * Test for a legal pixel format and type.
+ * Do error checking of format/type combinations for glReadPixels,
+ * glDrawPixels and glTex[Sub]Image.  Note that depending on the format
+ * and type values, we may either generate GL_INVALID_OPERATION or
+ * GL_INVALID_ENUM.
  *
  * \param format pixel format.
  * \param type pixel type.
  *
- * \return GL_TRUE if the given pixel format and type are legal, or GL_FALSE
- * otherwise.
+ * \return GL_INVALID_ENUM, GL_INVALID_OPERATION or GL_NO_ERROR
  */
-GLboolean
-_mesa_is_legal_format_and_type(const struct gl_context *ctx,
-   GLenum format, GLenum type)
+GLenum
+_mesa_error_check_format_and_type(const struct gl_context *ctx,
+  GLenum format, GLenum type)
 {
+   /* special type-based checks (see glReadPixels, glDrawPixels error lists) */
+   switch (type) {
+   case GL_BITMAP:
+  if (format != GL_COLOR_INDEX 
+  format != GL_STENCIL_INDEX) {
+ return GL_INVALID_ENUM;
+  }
+  break;
+
+   case GL_UNSIGNED_BYTE_3_3_2:
+   case GL_UNSIGNED_BYTE_2_3_3_REV:
+   case GL_UNSIGNED_SHORT_5_6_5:
+   case GL_UNSIGNED_SHORT_5_6_5_REV:
+  if (format != GL_RGB 
+  format != GL_RGB_INTEGER_EXT) {
+ return GL_INVALID_OPERATION;
+  }
+  break;
+
+   case GL_UNSIGNED_SHORT_4_4_4_4:
+   case GL_UNSIGNED_SHORT_4_4_4_4_REV:
+   case GL_UNSIGNED_SHORT_5_5_5_1:
+   case GL_UNSIGNED_SHORT_1_5_5_5_REV:
+   case GL_UNSIGNED_INT_8_8_8_8:
+   case GL_UNSIGNED_INT_8_8_8_8_REV:
+   case GL_UNSIGNED_INT_10_10_10_2:
+   case GL_UNSIGNED_INT_2_10_10_10_REV:
+  if (format != GL_RGBA 
+  format != GL_BGRA 
+  format != GL_ABGR_EXT 
+  format != GL_RGBA_INTEGER_EXT 
+  format != GL_BGRA_INTEGER_EXT) {
+ return GL_INVALID_OPERATION;
+  }
+  break;
+
+   case GL_UNSIGNED_INT_24_8:
+  if (!ctx-Extensions.EXT_packed_depth_stencil) {
+ return GL_INVALID_ENUM;
+  }
+  if (format != GL_DEPTH_STENCIL) {
+ return GL_INVALID_OPERATION;
+  }
+  return GL_NO_ERROR;
+
+   case GL_FLOAT_32_UNSIGNED_INT_24_8_REV:
+  if (!ctx-Extensions.ARB_depth_buffer_float) {
+ return GL_INVALID_ENUM;
+  }
+  if (format != GL_DEPTH_STENCIL) {
+ return GL_INVALID_OPERATION;
+  }
+  return GL_NO_ERROR;
+
+   default:
+  ; /* fall-through */
+   }
+
+   /* now, for each format, check the type for compatibility */
switch (format) {
   case GL_COLOR_INDEX:
   case GL_STENCIL_INDEX:
@@ -380,12 +441,14 @@ _mesa_is_legal_format_and_type(const struct gl_context 
*ctx,
 case GL_INT:
 case GL_UNSIGNED_INT:
 case GL_FLOAT:
-   return GL_TRUE;
-case GL_HALF_FLOAT_ARB:
-   return ctx-Extensions.ARB_half_float_pixel;
+   return GL_NO_ERROR;
+case GL_HALF_FLOAT:
+   return ctx-Extensions.ARB_half_float_pixel
+  ? GL_NO_ERROR : GL_INVALID_ENUM;
 default:
-   return GL_FALSE;
+   return GL_INVALID_ENUM;
  }
+
   case GL_RED:
   case GL_GREEN:
   case GL_BLUE:
@@ -404,16 +467,17 @@ _mesa_is_legal_format_and_type(const struct gl_context 
*ctx,
 case GL_INT:
 case GL_UNSIGNED_INT:
 case GL_FLOAT:
-   return GL_TRUE;
-case GL_HALF_FLOAT_ARB:
-   return ctx-Extensions.ARB_half_float_pixel;
+   return GL_NO_ERROR;
+case GL_HALF_FLOAT:
+   return ctx-Extensions.ARB_half_float_pixel
+  ? GL_NO_ERROR : GL_INVALID_ENUM;
 default:
-   return GL_FALSE;
+   return GL_INVALID_ENUM;
  }
+
   case GL_RG:
 if (!ctx-Extensions.ARB_texture_rg)
-   return GL_FALSE;
-
+   return GL_INVALID_ENUM;
  switch 

[Mesa-dev] [PATCH 2/3] mesa: remove redundant format/type checks in glGetTexImage()

2012-02-02 Thread Brian Paul
The _mesa_error_check_format_and_type() function will catch all those
cases now.
---
 src/mesa/main/texgetimage.c |   34 --
 1 files changed, 0 insertions(+), 34 deletions(-)

diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 58fed11..bff003d 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -746,40 +746,6 @@ getteximage_error_check(struct gl_context *ctx, GLenum 
target, GLint level,
   return GL_TRUE;
}
 
-   if (_mesa_sizeof_packed_type(type) = 0) {
-  _mesa_error( ctx, GL_INVALID_ENUM, glGetTexImage(type) );
-  return GL_TRUE;
-   }
-
-   if (_mesa_components_in_format(format) = 0 ||
-   format == GL_STENCIL_INDEX ||
-   format == GL_COLOR_INDEX) {
-  _mesa_error( ctx, GL_INVALID_ENUM, glGetTexImage(format) );
-  return GL_TRUE;
-   }
-
-   if (!ctx-Extensions.ARB_depth_texture  _mesa_is_depth_format(format)) {
-  _mesa_error(ctx, GL_INVALID_ENUM, glGetTexImage(format));
-  return GL_TRUE;
-   }
-
-   if (!ctx-Extensions.MESA_ycbcr_texture  _mesa_is_ycbcr_format(format)) {
-  _mesa_error(ctx, GL_INVALID_ENUM, glGetTexImage(format));
-  return GL_TRUE;
-   }
-
-   if (!ctx-Extensions.EXT_packed_depth_stencil
-_mesa_is_depthstencil_format(format)) {
-  _mesa_error(ctx, GL_INVALID_ENUM, glGetTexImage(format));
-  return GL_TRUE;
-   }
-
-   if (!ctx-Extensions.ATI_envmap_bumpmap
-_mesa_is_dudv_format(format)) {
-  _mesa_error(ctx, GL_INVALID_ENUM, glGetTexImage(format));
-  return;
-   }
-
err = _mesa_error_check_format_and_type(ctx, format, type);
if (err != GL_NO_ERROR) {
   _mesa_error(ctx, err, glGetTexImage(format/type));
-- 
1.7.3.4

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


[Mesa-dev] [PATCH 3/3] mesa: remove redundant format/type checks in glReadPixels()

2012-02-02 Thread Brian Paul
These are done in _mesa_error_check_format_and_type().
---
 src/mesa/main/readpix.c |   35 ---
 1 files changed, 0 insertions(+), 35 deletions(-)

diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 6c64cbe..b753e40 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -593,23 +593,6 @@ _mesa_error_check_format_type(struct gl_context *ctx, 
GLenum format,
/* state validation should have already been done */
ASSERT(ctx-NewState == 0x0);
 
-   if (ctx-Extensions.EXT_packed_depth_stencil
-type == GL_UNSIGNED_INT_24_8_EXT
-format != GL_DEPTH_STENCIL_EXT) {
-  _mesa_error(ctx, GL_INVALID_OPERATION,
-  gl%sPixels(format is not GL_DEPTH_STENCIL_EXT), readDraw);
-  return GL_TRUE;
-   }
-
-   if (ctx-Extensions.ARB_depth_buffer_float
-type == GL_FLOAT_32_UNSIGNED_INT_24_8_REV
-format != GL_DEPTH_STENCIL_EXT) {
-  _mesa_error(ctx, GL_INVALID_OPERATION,
-  gl%sPixels(format is not GL_DEPTH_STENCIL_EXT), readDraw);
-  return GL_TRUE;
-   }
-
-   /* basic combinations test */
err = _mesa_error_check_format_and_type(ctx, format, type);
if (err != GL_NO_ERROR) {
   _mesa_error(ctx, err, gl%sPixels(format or type), readDraw);
@@ -690,24 +673,6 @@ _mesa_error_check_format_type(struct gl_context *ctx, 
GLenum format,
   }
   break;
case GL_DEPTH_STENCIL_EXT:
-  /* Check validity of the type first. */
-  switch (type) {
- case GL_UNSIGNED_INT_24_8_EXT:
-if (!ctx-Extensions.EXT_packed_depth_stencil) {
-   _mesa_error(ctx, GL_INVALID_ENUM, gl%sPixels(type), readDraw);
-   return GL_TRUE;
-}
-break;
- case GL_FLOAT_32_UNSIGNED_INT_24_8_REV:
-if (!ctx-Extensions.ARB_depth_buffer_float) {
-   _mesa_error(ctx, GL_INVALID_ENUM, gl%sPixels(type), readDraw);
-   return GL_TRUE;
-}
-break;
- default:
-_mesa_error(ctx, GL_INVALID_ENUM, gl%sPixels(type), readDraw);
-return GL_TRUE;
-  }
   if ((drawing  !_mesa_dest_buffer_exists(ctx, format)) ||
   (reading  !_mesa_source_buffer_exists(ctx, format))) {
  _mesa_error(ctx, GL_INVALID_OPERATION,
-- 
1.7.3.4

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


Re: [Mesa-dev] [PATCH] draw: Avoid NULL pointer dereference when binding NULL fragment shaders.

2012-02-02 Thread Brian Paul

On 02/02/2012 06:20 AM, jfons...@vmware.com wrote:

From: José Fonsecajfons...@vmware.com

Now that the draw module avoids flushing, it may flush precisely when
binding a NULL shader, so care must be taken when restoring the original
fragment shader.
---
  src/gallium/auxiliary/draw/draw_pipe_aaline.c   |2 +-
  src/gallium/auxiliary/draw/draw_pipe_aapoint.c  |2 +-
  src/gallium/auxiliary/draw/draw_pipe_pstipple.c |2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c 
b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
index 0b368da..ea0a4fb 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
@@ -738,7 +738,7 @@ aaline_flush(struct draw_stage *stage, unsigned flags)

 /* restore original frag shader, texture, sampler state */
 draw-suspend_flushing = TRUE;
-   aaline-driver_bind_fs_state(pipe, aaline-fs-driver_fs);
+   aaline-driver_bind_fs_state(pipe, aaline-fs ? aaline-fs-driver_fs : 
NULL);
 aaline-driver_bind_sampler_states(pipe, aaline-num_samplers,
aaline-state.sampler);
 aaline-driver_set_sampler_views(pipe,
diff --git a/src/gallium/auxiliary/draw/draw_pipe_aapoint.c 
b/src/gallium/auxiliary/draw/draw_pipe_aapoint.c
index 248f26b..a900dd3 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aapoint.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aapoint.c
@@ -744,7 +744,7 @@ aapoint_flush(struct draw_stage *stage, unsigned flags)

 /* restore original frag shader */
 draw-suspend_flushing = TRUE;
-   aapoint-driver_bind_fs_state(pipe, aapoint-fs-driver_fs);
+   aapoint-driver_bind_fs_state(pipe, aapoint-fs ? aapoint-fs-driver_fs : 
NULL);

 /* restore original rasterizer state */
 if (draw-rast_handle) {
diff --git a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c 
b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
index 0401a45..62c54b3 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
@@ -565,7 +565,7 @@ pstip_flush(struct draw_stage *stage, unsigned flags)

 /* restore original frag shader, texture, sampler state */
 draw-suspend_flushing = TRUE;
-   pstip-driver_bind_fs_state(pipe, pstip-fs-driver_fs);
+   pstip-driver_bind_fs_state(pipe, pstip-fs ? pstip-fs-driver_fs : NULL);
 pstip-driver_bind_sampler_states(pipe, pstip-num_samplers,
   pstip-state.samplers);
 pstip-driver_set_sampler_views(pipe,


Reviewed-by: Brian Paul bri...@vmware.com

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


Re: [Mesa-dev] [PATCH] mapi/glapi: Never use a generic no-op entry-point on Windows.

2012-02-02 Thread Brian Paul

On 02/02/2012 03:44 AM, jfons...@vmware.com wrote:

From: José Fonsecajfons...@vmware.com

When GLAPIENTRY is __stdcall (ie Windows), the stack is popped by the
callee making the number/type of arguments significant, therefore
using a generic no-op causes stack corruption for many entry-points.
---
  src/mapi/glapi/glapi_nop.c |8 ++--
  1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/mapi/glapi/glapi_nop.c b/src/mapi/glapi/glapi_nop.c
index 9b09297..69b1ae6 100644
--- a/src/mapi/glapi/glapi_nop.c
+++ b/src/mapi/glapi/glapi_nop.c
@@ -51,7 +51,11 @@ _glapi_set_warning_func(_glapi_proc func)
  {
  }

-#ifdef DEBUG
+/*
+ * When GLAPIENTRY is __stdcall (i.e. Windows), the stack is popped by the
+ * callee making the number/type of arguments significant.
+ */
+#if defined(_WIN32) || defined(DEBUG)

  /**
   * Called by each of the no-op GL entrypoints.
@@ -59,7 +63,7 @@ _glapi_set_warning_func(_glapi_proc func)
  static int
  Warn(const char *func)
  {
-#if !defined(_WIN32_WCE)
+#if defined(DEBUG)  !defined(_WIN32_WCE)
 if (getenv(MESA_DEBUG) || getenv(LIBGL_DEBUG)) {
fprintf(stderr, GL User Error: gl%s called without a rendering 
context\n,
func);



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


[Mesa-dev] [PATCH] osmesa: remove GLAPI_LIB from OSMESA_LIB_DEPS

2012-02-02 Thread Brian Paul
Fixes both the autoconf and legacy config builds.

The build was failing with /usr/bin/ld: cannot find -lglapi since
there was no -L flag pointing to the lib.  But it's redundant anyway
since libglapi.a is already in the CORE_MESA object list.
---
 src/mesa/drivers/osmesa/Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/osmesa/Makefile b/src/mesa/drivers/osmesa/Makefile
index 005f4d5..32ee6cf 100644
--- a/src/mesa/drivers/osmesa/Makefile
+++ b/src/mesa/drivers/osmesa/Makefile
@@ -25,7 +25,7 @@ CORE_MESA = \
$(TOP)/src/mapi/glapi/libglapi.a \
$(TOP)/src/glsl/libglsl.a
 
-OSMESA_LIB_DEPS := -L$(TOP)/$(LIB_DIR) -l$(GLAPI_LIB) $(OSMESA_LIB_DEPS)
+OSMESA_LIB_DEPS := -L$(TOP)/$(LIB_DIR) $(OSMESA_LIB_DEPS)
 
 .c.o:
$(CC) -c $(INCLUDE_DIRS) $(CFLAGS) $ -o $@
-- 
1.7.3.4

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


Re: [Mesa-dev] [PATCH] osmesa: remove GLAPI_LIB from OSMESA_LIB_DEPS

2012-02-02 Thread Jon TURNEY
On 02/02/2012 14:43, Brian Paul wrote:
 Fixes both the autoconf and legacy config builds.
 
 The build was failing with /usr/bin/ld: cannot find -lglapi since
 there was no -L flag pointing to the lib.  But it's redundant anyway
 since libglapi.a is already in the CORE_MESA object list.
 ---
  src/mesa/drivers/osmesa/Makefile |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/src/mesa/drivers/osmesa/Makefile 
 b/src/mesa/drivers/osmesa/Makefile
 index 005f4d5..32ee6cf 100644
 --- a/src/mesa/drivers/osmesa/Makefile
 +++ b/src/mesa/drivers/osmesa/Makefile
 @@ -25,7 +25,7 @@ CORE_MESA = \
   $(TOP)/src/mapi/glapi/libglapi.a \
   $(TOP)/src/glsl/libglsl.a
  
 -OSMESA_LIB_DEPS := -L$(TOP)/$(LIB_DIR) -l$(GLAPI_LIB) $(OSMESA_LIB_DEPS)
 +OSMESA_LIB_DEPS := -L$(TOP)/$(LIB_DIR) $(OSMESA_LIB_DEPS)
  
  .c.o:
   $(CC) -c $(INCLUDE_DIRS) $(CFLAGS) $ -o $@

After this change the line does nothing but add an unneeded -L flag

Please just revert 4e5a8937d1a1bfb2a3bd067ed01e036728675fc2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] osmesa: remove GLAPI_LIB from OSMESA_LIB_DEPS

2012-02-02 Thread Brian Paul

On 02/02/2012 08:05 AM, Jon TURNEY wrote:

On 02/02/2012 14:43, Brian Paul wrote:

Fixes both the autoconf and legacy config builds.

The build was failing with /usr/bin/ld: cannot find -lglapi since
there was no -L flag pointing to the lib.  But it's redundant anyway
since libglapi.a is already in the CORE_MESA object list.
---
  src/mesa/drivers/osmesa/Makefile |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/osmesa/Makefile b/src/mesa/drivers/osmesa/Makefile
index 005f4d5..32ee6cf 100644
--- a/src/mesa/drivers/osmesa/Makefile
+++ b/src/mesa/drivers/osmesa/Makefile
@@ -25,7 +25,7 @@ CORE_MESA = \
$(TOP)/src/mapi/glapi/libglapi.a \
$(TOP)/src/glsl/libglsl.a

-OSMESA_LIB_DEPS := -L$(TOP)/$(LIB_DIR) -l$(GLAPI_LIB) $(OSMESA_LIB_DEPS)
+OSMESA_LIB_DEPS := -L$(TOP)/$(LIB_DIR) $(OSMESA_LIB_DEPS)

  .c.o:
$(CC) -c $(INCLUDE_DIRS) $(CFLAGS) $  -o $@


After this change the line does nothing but add an unneeded -L flag

Please just revert 4e5a8937d1a1bfb2a3bd067ed01e036728675fc2


OK, that seems to fix both builds too.  Thanks.

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


Re: [Mesa-dev] [PATCH] mesa: Add unpack_uint_z_row support for floating-point depth buffers

2012-02-02 Thread Ian Romanick

On 02/02/2012 06:41 AM, Henri Verbeet wrote:

On 1 February 2012 23:12, Brian Paulbri...@vmware.com  wrote:

+static void
+unpack_uint_z_Z32_FLOAT(const void *src, GLuint *dst, GLuint n)
+{
+   const float *s = ((const float *)src);



More parens than necessary there.


The entire cast is unnecessary, IMO. But of course that would apply to
the other functions in that file as well.


Right.  This was a copy-and-paste of another Z32_FLOAT function.  I'm 
not too worried about the cosmetics of this code.  I'm planning to 
convert a bunch of these mechanical things over to generated code for 
8.1.  Each copy-and-paste bug that I find (see my recent patches) 
reinforces my desire to do that conversion. :)

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


Re: [Mesa-dev] [PATCH 1/3] mesa: new _mesa_error_check_format_and_type() function

2012-02-02 Thread Ian Romanick

On 02/02/2012 07:14 AM, Brian Paul wrote:

This replaces the _mesa_is_legal_format_and_type() function.

According to the spec, some invalid format/type combinations to
glDrawPixels, ReadPixels and glTexImage should generate
GL_INVALID_ENUM but others should generate GL_INVALID_OPERATION.

With the old function we didn't make that distinction and generated
GL_INVALID_ENUM errors instead of GL_INVALID_OPERATION.  The new
function returns one of those errors or GL_NO_ERROR.

This will also let us remove some redundant format/type checks in
follow-on commit.
---
  src/mesa/main/image.c   |  212 ++-
  src/mesa/main/image.h   |6 +-
  src/mesa/main/readpix.c |9 +-
  src/mesa/main/texgetimage.c |   16 ++--
  src/mesa/main/teximage.c|   25 ++---
  5 files changed, 174 insertions(+), 94 deletions(-)

diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c
index 3491704..cc44468 100644
--- a/src/mesa/main/image.c
+++ b/src/mesa/main/image.c
@@ -356,18 +356,79 @@ _mesa_bytes_per_pixel( GLenum format, GLenum type )


  /**
- * Test for a legal pixel format and type.
+ * Do error checking of format/type combinations for glReadPixels,
+ * glDrawPixels and glTex[Sub]Image.  Note that depending on the format
+ * and type values, we may either generate GL_INVALID_OPERATION or
+ * GL_INVALID_ENUM.
   *
   * \param format pixel format.
   * \param type pixel type.
   *
- * \return GL_TRUE if the given pixel format and type are legal, or GL_FALSE
- * otherwise.
+ * \return GL_INVALID_ENUM, GL_INVALID_OPERATION or GL_NO_ERROR
   */
-GLboolean
-_mesa_is_legal_format_and_type(const struct gl_context *ctx,
-   GLenum format, GLenum type)
+GLenum
+_mesa_error_check_format_and_type(const struct gl_context *ctx,
+  GLenum format, GLenum type)
  {
+   /* special type-based checks (see glReadPixels, glDrawPixels error lists) */
+   switch (type) {
+   case GL_BITMAP:
+  if (format != GL_COLOR_INDEX
+  format != GL_STENCIL_INDEX) {
+ return GL_INVALID_ENUM;
+  }
+  break;
+
+   case GL_UNSIGNED_BYTE_3_3_2:
+   case GL_UNSIGNED_BYTE_2_3_3_REV:
+   case GL_UNSIGNED_SHORT_5_6_5:
+   case GL_UNSIGNED_SHORT_5_6_5_REV:
+  if (format != GL_RGB
+  format != GL_RGB_INTEGER_EXT) {
+ return GL_INVALID_OPERATION;


I don't think the packed types can be used with *_INTEGER.  At the very 
least, the code in pack.c can't handle it.  Table 3.8 in the 3.0 spec 
only lists RGB, RGBA, BGRA, and DEPTH_STENCIL as valid formats for 
packed types.  The EXT_abgr spec adds ABGR_EXT, of course.



+  }
+  break;
+
+   case GL_UNSIGNED_SHORT_4_4_4_4:
+   case GL_UNSIGNED_SHORT_4_4_4_4_REV:
+   case GL_UNSIGNED_SHORT_5_5_5_1:
+   case GL_UNSIGNED_SHORT_1_5_5_5_REV:
+   case GL_UNSIGNED_INT_8_8_8_8:
+   case GL_UNSIGNED_INT_8_8_8_8_REV:
+   case GL_UNSIGNED_INT_10_10_10_2:
+   case GL_UNSIGNED_INT_2_10_10_10_REV:
+  if (format != GL_RGBA
+  format != GL_BGRA
+  format != GL_ABGR_EXT
+  format != GL_RGBA_INTEGER_EXT
+  format != GL_BGRA_INTEGER_EXT) {
+ return GL_INVALID_OPERATION;
+  }
+  break;
+
+   case GL_UNSIGNED_INT_24_8:
+  if (!ctx-Extensions.EXT_packed_depth_stencil) {
+ return GL_INVALID_ENUM;
+  }
+  if (format != GL_DEPTH_STENCIL) {
+ return GL_INVALID_OPERATION;
+  }
+  return GL_NO_ERROR;
+
+   case GL_FLOAT_32_UNSIGNED_INT_24_8_REV:
+  if (!ctx-Extensions.ARB_depth_buffer_float) {
+ return GL_INVALID_ENUM;
+  }
+  if (format != GL_DEPTH_STENCIL) {
+ return GL_INVALID_OPERATION;
+  }
+  return GL_NO_ERROR;
+
+   default:
+  ; /* fall-through */
+   }
+
+   /* now, for each format, check the type for compatibility */
 switch (format) {
case GL_COLOR_INDEX:
case GL_STENCIL_INDEX:
@@ -380,12 +441,14 @@ _mesa_is_legal_format_and_type(const struct gl_context 
*ctx,
  case GL_INT:
  case GL_UNSIGNED_INT:
  case GL_FLOAT:
-   return GL_TRUE;
-case GL_HALF_FLOAT_ARB:
-   return ctx-Extensions.ARB_half_float_pixel;
+   return GL_NO_ERROR;
+case GL_HALF_FLOAT:
+   return ctx-Extensions.ARB_half_float_pixel
+  ? GL_NO_ERROR : GL_INVALID_ENUM;
  default:
-   return GL_FALSE;
+   return GL_INVALID_ENUM;
   }
+
case GL_RED:
case GL_GREEN:
case GL_BLUE:
@@ -404,16 +467,17 @@ _mesa_is_legal_format_and_type(const struct gl_context 
*ctx,
  case GL_INT:
  case GL_UNSIGNED_INT:
  case GL_FLOAT:
-   return GL_TRUE;
-case GL_HALF_FLOAT_ARB:
-   return ctx-Extensions.ARB_half_float_pixel;
+   return GL_NO_ERROR;
+case GL_HALF_FLOAT:
+   return 

Re: [Mesa-dev] [PATCH 1/3] mesa: new _mesa_error_check_format_and_type() function

2012-02-02 Thread Brian Paul

[don't know why the indention is messed up below, but anyway...]

On 02/02/2012 10:02 AM, Ian Romanick wrote:

On 02/02/2012 07:14 AM, Brian Paul wrote:

This replaces the _mesa_is_legal_format_and_type() function.

According to the spec, some invalid format/type combinations to
glDrawPixels, ReadPixels and glTexImage should generate
GL_INVALID_ENUM but others should generate GL_INVALID_OPERATION.

With the old function we didn't make that distinction and generated
GL_INVALID_ENUM errors instead of GL_INVALID_OPERATION. The new
function returns one of those errors or GL_NO_ERROR.

This will also let us remove some redundant format/type checks in
follow-on commit.
---
src/mesa/main/image.c | 212 ++-
src/mesa/main/image.h | 6 +-
src/mesa/main/readpix.c | 9 +-
src/mesa/main/texgetimage.c | 16 ++--
src/mesa/main/teximage.c | 25 ++---
5 files changed, 174 insertions(+), 94 deletions(-)

diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c
index 3491704..cc44468 100644
--- a/src/mesa/main/image.c
+++ b/src/mesa/main/image.c
@@ -356,18 +356,79 @@ _mesa_bytes_per_pixel( GLenum format, GLenum
type )


/**
- * Test for a legal pixel format and type.
+ * Do error checking of format/type combinations for glReadPixels,
+ * glDrawPixels and glTex[Sub]Image. Note that depending on the format
+ * and type values, we may either generate GL_INVALID_OPERATION or
+ * GL_INVALID_ENUM.
*
* \param format pixel format.
* \param type pixel type.
*
- * \return GL_TRUE if the given pixel format and type are legal, or
GL_FALSE
- * otherwise.
+ * \return GL_INVALID_ENUM, GL_INVALID_OPERATION or GL_NO_ERROR
*/
-GLboolean
-_mesa_is_legal_format_and_type(const struct gl_context *ctx,
- GLenum format, GLenum type)
+GLenum
+_mesa_error_check_format_and_type(const struct gl_context *ctx,
+ GLenum format, GLenum type)
{
+ /* special type-based checks (see glReadPixels, glDrawPixels error
lists) */
+ switch (type) {
+ case GL_BITMAP:
+ if (format != GL_COLOR_INDEX
+ format != GL_STENCIL_INDEX) {
+ return GL_INVALID_ENUM;
+ }
+ break;
+
+ case GL_UNSIGNED_BYTE_3_3_2:
+ case GL_UNSIGNED_BYTE_2_3_3_REV:
+ case GL_UNSIGNED_SHORT_5_6_5:
+ case GL_UNSIGNED_SHORT_5_6_5_REV:
+ if (format != GL_RGB
+ format != GL_RGB_INTEGER_EXT) {
+ return GL_INVALID_OPERATION;


I don't think the packed types can be used with *_INTEGER. At the very
least, the code in pack.c can't handle it. Table 3.8 in the 3.0 spec
only lists RGB, RGBA, BGRA, and DEPTH_STENCIL as valid formats for
packed types. The EXT_abgr spec adds ABGR_EXT, of course.


It looks like packed integer formats are added in GL 3.3.  But they're 
also listed in GL_ARB_texture_rgb10_a2ui which is supposedly based on 
GL 3.2.  It's not clear to me if GL_ARB_texture_rgb10_a2ui is supposed 
to enable all the packed integer formats or just the 10/10/10/2 packed 
format.  Hmmm.


Anyway, if you look further down in that function you'll see 
finer-grained format/type checking which checks for 
ctx-Extensions.ARB_texture_rgb10_a2ui for those cases.  But I suppose 
we need more checks at the earlier point to generate 
GL_INVALID_OPERATION anyway.  I can do that.


I haven't looked if any drivers support GL_ARB_texture_rgb10_a2ui.

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


Re: [Mesa-dev] anongit.freedesktop.org not available?

2012-02-02 Thread Paul Berry
On 1 February 2012 20:55, Alan Coopersmith alan.coopersm...@oracle.comwrote:

 On 02/ 1/12 08:52 PM, Alexandre Demers wrote:

 Hi,

 I've been trying all day to sync sources from anongit.freedesktop.org
 (dri and mesa) and it always ends up by a time out. Is there a problem
 with the server or the address?


 Yes.  Others have reported on IRC that it works if you force the hostnames
 to resolve to 131.252.210.176 instead of the DNS reported 131.252.210.161.


Does anyone know an ETA on getting this fixed?  It would be nice to have
anongit.freedesktop.org resolving correctly when we make the by the time we
make the Mesa 8.0 release.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/3] mesa: new _mesa_error_check_format_and_type() function

2012-02-02 Thread Ian Romanick

On 02/02/2012 10:26 AM, Brian Paul wrote:

[don't know why the indention is messed up below, but anyway...]

On 02/02/2012 10:02 AM, Ian Romanick wrote:

On 02/02/2012 07:14 AM, Brian Paul wrote:

This replaces the _mesa_is_legal_format_and_type() function.

According to the spec, some invalid format/type combinations to
glDrawPixels, ReadPixels and glTexImage should generate
GL_INVALID_ENUM but others should generate GL_INVALID_OPERATION.

With the old function we didn't make that distinction and generated
GL_INVALID_ENUM errors instead of GL_INVALID_OPERATION. The new
function returns one of those errors or GL_NO_ERROR.

This will also let us remove some redundant format/type checks in
follow-on commit.
---
src/mesa/main/image.c | 212 ++-
src/mesa/main/image.h | 6 +-
src/mesa/main/readpix.c | 9 +-
src/mesa/main/texgetimage.c | 16 ++--
src/mesa/main/teximage.c | 25 ++---
5 files changed, 174 insertions(+), 94 deletions(-)

diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c
index 3491704..cc44468 100644
--- a/src/mesa/main/image.c
+++ b/src/mesa/main/image.c
@@ -356,18 +356,79 @@ _mesa_bytes_per_pixel( GLenum format, GLenum
type )


/**
- * Test for a legal pixel format and type.
+ * Do error checking of format/type combinations for glReadPixels,
+ * glDrawPixels and glTex[Sub]Image. Note that depending on the format
+ * and type values, we may either generate GL_INVALID_OPERATION or
+ * GL_INVALID_ENUM.
*
* \param format pixel format.
* \param type pixel type.
*
- * \return GL_TRUE if the given pixel format and type are legal, or
GL_FALSE
- * otherwise.
+ * \return GL_INVALID_ENUM, GL_INVALID_OPERATION or GL_NO_ERROR
*/
-GLboolean
-_mesa_is_legal_format_and_type(const struct gl_context *ctx,
- GLenum format, GLenum type)
+GLenum
+_mesa_error_check_format_and_type(const struct gl_context *ctx,
+ GLenum format, GLenum type)
{
+ /* special type-based checks (see glReadPixels, glDrawPixels error
lists) */
+ switch (type) {
+ case GL_BITMAP:
+ if (format != GL_COLOR_INDEX
+ format != GL_STENCIL_INDEX) {
+ return GL_INVALID_ENUM;
+ }
+ break;
+
+ case GL_UNSIGNED_BYTE_3_3_2:
+ case GL_UNSIGNED_BYTE_2_3_3_REV:
+ case GL_UNSIGNED_SHORT_5_6_5:
+ case GL_UNSIGNED_SHORT_5_6_5_REV:
+ if (format != GL_RGB
+ format != GL_RGB_INTEGER_EXT) {
+ return GL_INVALID_OPERATION;


I don't think the packed types can be used with *_INTEGER. At the very
least, the code in pack.c can't handle it. Table 3.8 in the 3.0 spec
only lists RGB, RGBA, BGRA, and DEPTH_STENCIL as valid formats for
packed types. The EXT_abgr spec adds ABGR_EXT, of course.


It looks like packed integer formats are added in GL 3.3. But they're
also listed in GL_ARB_texture_rgb10_a2ui which is supposedly based on GL
3.2. It's not clear to me if GL_ARB_texture_rgb10_a2ui is supposed to
enable all the packed integer formats or just the 10/10/10/2 packed
format. Hmmm.


That's right!  That's issue #4 in the GL_ARB_texture_rgb10_a2ui spec:

4. It is possible to load packed 10_10_10_2 unsigned integer data
   into GL via TexImage without this extension?

   RESOLVED:  No.  The EXT_texture_integer extension, as later
   incorporated into OpenGL 3.0, added new integer pixel format
   enums (e.g., RGBA_INTEGER) and texture formats (e.g.,
   RGBA16UI). All texture formats added by that extension had a
   matching non-packed format and type combination, so there
   wasn't a strong need to explicitly support packed pixel
   types for integer pixel formats.

   The texture format added by this extension logically maps to
   a packed format/type combination, so we add this support
   by adding RGB_INTEGER, RGBA_INTEGER, and BGRA_INTEGER (as
   appropriate) to the list of formats supported by packed pixel
   data types.

   Even though we are only adding one packed texture format,
   we chose to allow all packed types with corresponding integer
   formats for orthogonality.


Anyway, if you look further down in that function you'll see
finer-grained format/type checking which checks for
ctx-Extensions.ARB_texture_rgb10_a2ui for those cases. But I suppose we
need more checks at the earlier point to generate GL_INVALID_OPERATION
anyway. I can do that.

I haven't looked if any drivers support GL_ARB_texture_rgb10_a2ui.


'grep -r ARB_texture_rgb10_a2ui src/' indicates not.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] anongit.freedesktop.org not available?

2012-02-02 Thread Dave Airlie
On Thu, Feb 2, 2012 at 5:38 PM, Paul Berry stereotype...@gmail.com wrote:
 On 1 February 2012 20:55, Alan Coopersmith alan.coopersm...@oracle.com
 wrote:

 On 02/ 1/12 08:52 PM, Alexandre Demers wrote:

 Hi,

 I've been trying all day to sync sources from anongit.freedesktop.org
 (dri and mesa) and it always ends up by a time out. Is there a problem
 with the server or the address?


 Yes.  Others have reported on IRC that it works if you force the hostnames
 to resolve to 131.252.210.176 instead of the DNS reported 131.252.210.161.


 Does anyone know an ETA on getting this fixed?  It would be nice to have
 anongit.freedesktop.org resolving correctly when we make the by the time we
 make the Mesa 8.0 release.

The admin is on holidays, nobody else has access from what I know, and
all are at FOSDEM.

Its also not a DNS issue, the other IP address is the old anongit
service, which thankfully wasn't removed yet.

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


Re: [Mesa-dev] [PATCH 1/6] glsl: Save and restore the whole switch state for nesting.

2012-02-02 Thread Ian Romanick

On 01/30/2012 10:58 AM, Eric Anholt wrote:

The series is,

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

Sorry for taking so long to review.


This stuffs them all in a struct for sanity.  Fixes piglit
glsl-1.30/execution/switch/fs-uniform-nested.

NOTE: This is a candidate for the 8.0 branch.
---
  src/glsl/ast_to_hir.cpp |  497 +++
  src/glsl/glsl_parser_extras.cpp |2 +-
  src/glsl/glsl_parser_extras.h   |   16 +-
  3 files changed, 255 insertions(+), 260 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index cde7052..25ccdab 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -3405,7 +3405,7 @@ ast_jump_statement::hir(exec_list *instructions,
  continue may only appear in a loop);
} else if (mode == ast_break
state-loop_nesting_ast == NULL
-state-switch_nesting_ast == NULL) {
+state-switch_state.switch_nesting_ast == NULL) {
 YYLTYPE loc = this-get_location();

 _mesa_glsl_error(  loc, state,
@@ -3423,11 +3423,11 @@ ast_jump_statement::hir(exec_list *instructions,
  state);
 }

-if (state-is_switch_innermost
+if (state-switch_state.is_switch_innermost
mode == ast_break) {
/* Force break out of switch by setting is_break switch state.
 */
-   ir_variable *const is_break_var = state-is_break_var;
+   ir_variable *const is_break_var = state-switch_state.is_break_var;
ir_dereference_variable *const deref_is_break_var =
   new(ctx) ir_dereference_variable(is_break_var);
ir_constant *const true_val = new(ctx) ir_constant(true);
@@ -3530,25 +3530,22 @@ ast_switch_statement::hir(exec_list *instructions,

 /* Track the switch-statement nesting in a stack-like manner.
  */
-   ir_variable *saved_test_var = state-test_var;
-   ir_variable *saved_is_fallthru_var = state-is_fallthru_var;
-
-   bool save_is_switch_innermost = state-is_switch_innermost;
-   ast_switch_statement *saved_nesting_ast = state-switch_nesting_ast;
+   struct glsl_switch_state saved = state-switch_state;

-   state-is_switch_innermost = true;
-   state-switch_nesting_ast = this;
+   state-switch_state.is_switch_innermost = true;
+   state-switch_state.switch_nesting_ast = this;

 /* Initalize is_fallthru state to false.
  */
 ir_rvalue *const is_fallthru_val = new (ctx) ir_constant(false);
-   state-is_fallthru_var = new(ctx) ir_variable(glsl_type::bool_type,
-   switch_is_fallthru_tmp,
-   ir_var_temporary);
-   instructions-push_tail(state-is_fallthru_var);
+   state-switch_state.is_fallthru_var =
+  new(ctx) ir_variable(glsl_type::bool_type,
+  switch_is_fallthru_tmp,
+  ir_var_temporary);
+   instructions-push_tail(state-switch_state.is_fallthru_var);

 ir_dereference_variable *deref_is_fallthru_var =
-  new(ctx) ir_dereference_variable(state-is_fallthru_var);
+  new(ctx) ir_dereference_variable(state-switch_state.is_fallthru_var);
 instructions-push_tail(new(ctx) ir_assignment(deref_is_fallthru_var,
  is_fallthru_val,
  NULL));
@@ -3556,13 +3553,13 @@ ast_switch_statement::hir(exec_list *instructions,
 /* Initalize is_break state to false.
  */
 ir_rvalue *const is_break_val = new (ctx) ir_constant(false);
-   state-is_break_var = new(ctx) ir_variable(glsl_type::bool_type,
- switch_is_break_tmp,
- ir_var_temporary);
-   instructions-push_tail(state-is_break_var);
+   state-switch_state.is_break_var = new(ctx) 
ir_variable(glsl_type::bool_type,
+  
switch_is_break_tmp,
+  ir_var_temporary);
+   instructions-push_tail(state-switch_state.is_break_var);

 ir_dereference_variable *deref_is_break_var =
-  new(ctx) ir_dereference_variable(state-is_break_var);
+  new(ctx) ir_dereference_variable(state-switch_state.is_break_var);
 instructions-push_tail(new(ctx) ir_assignment(deref_is_break_var,
  is_break_val,
  NULL));
@@ -3575,254 +3572,248 @@ ast_switch_statement::hir(exec_list *instructions,
  */
 body-hir(instructions, state);

-   /* Restore previous nesting before returning.
-*/
-   state-switch_nesting_ast = saved_nesting_ast;
-   state-is_switch_innermost = save_is_switch_innermost;
-
-   state-test_var = saved_test_var;
-   state-is_fallthru_var = saved_is_fallthru_var;
-
-   /* 

Re: [Mesa-dev] [PATCH 1/3] mesa: new _mesa_error_check_format_and_type() function

2012-02-02 Thread Brian Paul

On 02/02/2012 10:44 AM, Ian Romanick wrote:

On 02/02/2012 10:26 AM, Brian Paul wrote:

[don't know why the indention is messed up below, but anyway...]

On 02/02/2012 10:02 AM, Ian Romanick wrote:

On 02/02/2012 07:14 AM, Brian Paul wrote:

This replaces the _mesa_is_legal_format_and_type() function.

According to the spec, some invalid format/type combinations to
glDrawPixels, ReadPixels and glTexImage should generate
GL_INVALID_ENUM but others should generate GL_INVALID_OPERATION.

With the old function we didn't make that distinction and generated
GL_INVALID_ENUM errors instead of GL_INVALID_OPERATION. The new
function returns one of those errors or GL_NO_ERROR.

This will also let us remove some redundant format/type checks in
follow-on commit.
---
src/mesa/main/image.c | 212
++-
src/mesa/main/image.h | 6 +-
src/mesa/main/readpix.c | 9 +-
src/mesa/main/texgetimage.c | 16 ++--
src/mesa/main/teximage.c | 25 ++---
5 files changed, 174 insertions(+), 94 deletions(-)

diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c
index 3491704..cc44468 100644
--- a/src/mesa/main/image.c
+++ b/src/mesa/main/image.c
@@ -356,18 +356,79 @@ _mesa_bytes_per_pixel( GLenum format, GLenum
type )


/**
- * Test for a legal pixel format and type.
+ * Do error checking of format/type combinations for glReadPixels,
+ * glDrawPixels and glTex[Sub]Image. Note that depending on the
format
+ * and type values, we may either generate GL_INVALID_OPERATION or
+ * GL_INVALID_ENUM.
*
* \param format pixel format.
* \param type pixel type.
*
- * \return GL_TRUE if the given pixel format and type are legal, or
GL_FALSE
- * otherwise.
+ * \return GL_INVALID_ENUM, GL_INVALID_OPERATION or GL_NO_ERROR
*/
-GLboolean
-_mesa_is_legal_format_and_type(const struct gl_context *ctx,
- GLenum format, GLenum type)
+GLenum
+_mesa_error_check_format_and_type(const struct gl_context *ctx,
+ GLenum format, GLenum type)
{
+ /* special type-based checks (see glReadPixels, glDrawPixels error
lists) */
+ switch (type) {
+ case GL_BITMAP:
+ if (format != GL_COLOR_INDEX
+ format != GL_STENCIL_INDEX) {
+ return GL_INVALID_ENUM;
+ }
+ break;
+
+ case GL_UNSIGNED_BYTE_3_3_2:
+ case GL_UNSIGNED_BYTE_2_3_3_REV:
+ case GL_UNSIGNED_SHORT_5_6_5:
+ case GL_UNSIGNED_SHORT_5_6_5_REV:
+ if (format != GL_RGB
+ format != GL_RGB_INTEGER_EXT) {
+ return GL_INVALID_OPERATION;


I don't think the packed types can be used with *_INTEGER. At the very
least, the code in pack.c can't handle it. Table 3.8 in the 3.0 spec
only lists RGB, RGBA, BGRA, and DEPTH_STENCIL as valid formats for
packed types. The EXT_abgr spec adds ABGR_EXT, of course.


It looks like packed integer formats are added in GL 3.3. But they're
also listed in GL_ARB_texture_rgb10_a2ui which is supposedly based
on GL
3.2. It's not clear to me if GL_ARB_texture_rgb10_a2ui is supposed to
enable all the packed integer formats or just the 10/10/10/2 packed
format. Hmmm.


That's right! That's issue #4 in the GL_ARB_texture_rgb10_a2ui spec:

4. It is possible to load packed 10_10_10_2 unsigned integer data
into GL via TexImage without this extension?

RESOLVED: No. The EXT_texture_integer extension, as later
incorporated into OpenGL 3.0, added new integer pixel format
enums (e.g., RGBA_INTEGER) and texture formats (e.g.,
RGBA16UI). All texture formats added by that extension had a
matching non-packed format and type combination, so there
wasn't a strong need to explicitly support packed pixel
types for integer pixel formats.

The texture format added by this extension logically maps to
a packed format/type combination, so we add this support
by adding RGB_INTEGER, RGBA_INTEGER, and BGRA_INTEGER (as
appropriate) to the list of formats supported by packed pixel
data types.

Even though we are only adding one packed texture format,
we chose to allow all packed types with corresponding integer
formats for orthogonality.


OK, so are you saying we should add the checks per 
GL_ARB_texture_rgb10_a2ui or just forget about packed integer formats 
entirely for now?  Either way is OK by me.




Anyway, if you look further down in that function you'll see
finer-grained format/type checking which checks for
ctx-Extensions.ARB_texture_rgb10_a2ui for those cases. But I
suppose we
need more checks at the earlier point to generate GL_INVALID_OPERATION
anyway. I can do that.

I haven't looked if any drivers support GL_ARB_texture_rgb10_a2ui.


'grep -r ARB_texture_rgb10_a2ui src/' indicates not.


But the gallium state tracker queries PIPE_FORMAT_B10G10R10A2_UINT to 
turn on GL_ARB_texture_rgb10_a2ui and there's some mention of that 
format in the r600g driver:


$ grep PIPE_FORMAT_B10G10R10A2_UINT -r src/gallium/drivers
src/gallium/drivers/r600/r600_state.c:  case PIPE_FORMAT_B10G10R10A2_UINT:
src/gallium/drivers/r600/r600_state.c:  case PIPE_FORMAT_B10G10R10A2_UINT:
src/gallium/drivers/r600/evergreen_state.c:	case 
PIPE_FORMAT_B10G10R10A2_UINT:
src/gallium/drivers/r600/evergreen_state.c:	

Re: [Mesa-dev] [PATCH] mesa: fix maximum allowed proxy texture size condition

2012-02-02 Thread Anuj Phogat
On Wed, Feb 1, 2012 at 12:52 PM, Jose Fonseca jfons...@vmware.com wrote:



 - Original Message -
  On 01/28/2012 04:04 AM, Jose Fonseca wrote:
  
  
   - Original Message -
   width, height parameter of glTexImage2D() includes: texture image
   width + 2 * border (if any). So when doing the texture size check
   in _mesa_test_proxy_teximage() width and height should not exceed
   maximum supported size for target texture type.
   i.e. 1  (ctx-Const.MaxTextureLevels - 1)
  
   This patch fixes Intel oglconform test case: max_values
   Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44970
  
   Note: This is a candidate for mesa 8.0 branch.
  
   Signed-off-by: Anuj Phogatanuj.pho...@gmail.com
   ---
 src/mesa/main/teximage.c |   22 +++---
 1 files changed, 11 insertions(+), 11 deletions(-)
  
   diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
   index d11425d..018aca0 100644
   --- a/src/mesa/main/teximage.c
   +++ b/src/mesa/main/teximage.c
   @@ -1179,7 +1179,7 @@ _mesa_test_proxy_teximage(struct gl_context
   *ctx, GLenum target, GLint level,
switch (target) {
case GL_PROXY_TEXTURE_1D:
   maxSize = 1  (ctx-Const.MaxTextureLevels - 1);
   -  if (width  2 * border || width  2 + maxSize)
   +  if (width  2 * border || width  maxSize)
  
   Anuj,
  
   I may be missing something, but I'm still unsure about this,
   because this will create problems for drivers that do support
   borders.
 
  AFAIK, the only desktop graphics hardware that ever supported borders
  is
  NVIDIA.  Their driver follows the convention (width + 2 * border) 
  maxSize, and their driver advertises a maximum size of 2^n.  I tried
  creating a proxy texture that was the full 2^n plus a border on their
  closed-source Linux driver, and it was rejected.  A proxy texture
  2^n-2
  plus a border was accepted.
 
  Based on that, I believe this patch is correct.

 Fair enough. Sounds good to me then!


This patch made the intel oglconform test to pass. But the errors reported in
oglconform failure stays unfixed. This is confirmed by a piglit test
case I developed to reproduce the errors. Test case
(validate-texture-size) is posted on piglit mailing list for review.

Driver throws assertion failure or segfaults with large textures even
much below the maximum supported size.

https://bugs.freedesktop.org/show_bug.cgi?id=44970
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 0/2] gallium/postprocess: some fixes

2012-02-02 Thread Alex Deucher
On Thu, Feb 2, 2012 at 6:46 AM, Lauri Kasanen c...@gmx.com wrote:
 The first patch fixes a bug where the depth filters may have used an old 
 depth buffer.
 The second adds safeguards suggested by Michael Dänzer.

 Could they both be applied to the stable 8.0 tree too?

 Hi list

 Ping on the above. If at all possible, I'd like the 8.0 release have all 
 three PP fixes, Michel's and these two.

 Also apologies to Michel for mistyping your name.

Done.

Alex


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


[Mesa-dev] [PATCH] intel: Avoid divide by zero for very small linear blits

2012-02-02 Thread Ian Romanick
From: Ian Romanick ian.d.roman...@intel.com

If size is small (such as 1),

   pitch = ROUND_DOWN_TO(MIN2(size, (1  15) - 1), 4);

makes pitch = 0.  Then

   height = size / pitch;

causes a division-by-zero exception.  If pitch is zero, set height to
1 and avoid the division.

This fixes piglit's bin/getteximage-formats test and glean's
bufferObject test.

NOTE: This is a candidate for the 8.0 release branch.

Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44971
---
 src/mesa/drivers/dri/intel/intel_blit.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_blit.c 
b/src/mesa/drivers/dri/intel/intel_blit.c
index 9eacadd..fd4a86c 100644
--- a/src/mesa/drivers/dri/intel/intel_blit.c
+++ b/src/mesa/drivers/dri/intel/intel_blit.c
@@ -492,7 +492,7 @@ intel_emit_linear_blit(struct intel_context *intel,
 * rounding that down to the nearest DWORD is 1  15 - 4
 */
pitch = ROUND_DOWN_TO(MIN2(size, (1  15) - 1), 4);
-   height = size / pitch;
+   height = (pitch == 0) ? 1 : size / pitch;
ok = intelEmitCopyBlit(intel, 1,
  pitch, src_bo, src_offset, I915_TILING_NONE,
  pitch, dst_bo, dst_offset, I915_TILING_NONE,
-- 
1.7.6.4

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


Re: [Mesa-dev] [PATCH] glsl: move array_sizing_visitor class outside of link_intrastage_shaders()

2012-02-02 Thread Kenneth Graunke

On 01/30/2012 12:08 PM, Brian Paul wrote:

From: Brian Paulbri...@vmware.com

To silence warnings with gcc 4.4.x on Linux and llvm-g++ 4.2 on Mac.
---
  src/glsl/linker.cpp |   38 ++
  1 files changed, 22 insertions(+), 16 deletions(-)


Reviewed-by: Kenneth Graunke kenn...@whitecape.org

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


[Mesa-dev] [Bug 45571] fatal error: program/symbol_table.h: No such file or directory

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

Alexandre Demers alexandre.f.dem...@gmail.com changed:

   What|Removed |Added

 AssignedTo|i...@freedesktop.org |mesa-dev@lists.freedesktop.
   ||org
  Component|glsl-compiler   |Other

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


Re: [Mesa-dev] [PATCH 00/15] R600g cleanup and rework of cache flushing

2012-02-02 Thread Marek Olšák
On Mon, Jan 30, 2012 at 9:30 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Mon, Jan 30, 2012 at 09:23:03PM +0100, Marek Olšák wrote:
 Hi everyone,

 This patch series is a follow-up to the previous one (Remove all uses of 
 the register mask). First, it cleans up some code and merges r600_context 
 into r600_pipe_context. The split of functionality between the two 
 contexts made absolutely no sense.

 Next, it adds a new mechanism for emitting states. It's largely inspired by 
 r300g and it's really simple, yet robust. (some people should seriously 
 learn what polymorphism means and how it's used to write software before 
 even writing drivers, because I feel like I am the only one making use of it 
 in r600g, which is really a shame /rant) It can be used to schedule *any* 
 commands for execution before the next draw operation, not just register 
 updates. We'll use that more often in the future. For now, it's only used 
 for cache flushes.

 Finally, this series completely reworks cache flushes. The problem with the 
 old code was that the flags last_flush and binding, which were stored in 
 resource structs, were possible causes of race conditions. Not only does 
 this new code fix that, it also simplifies the whole thing. The flushes are 
 done explicitly when states are changed according to this scheme:
 bind_shader - r600_inval_shader_cache
 set_constant_buffer - r600_inval_shader_cache
 bind_vertex_elements - r600_inval_shader_cache (for the fetch shader)
 bind_vertex_buffers - r600_inval_vertex_cache
 bind_sampler_views - r600_inval_texture_cache
 set_framebuffer - r600_flush_framebuffer
 flush - r600_flush_framebuffer

 Besides that, SURFACE_SYNC is called at most once between draw operations 
 and flushes the whole memory range. The inval/flush functions only 
 accumulate the flush flags.

 The rework also fixes flushes on RV670. The fbo-drawbuffers test no longer 
 causes issues. Flushing CB1_DEST_BASE was not enough, DEST_BASE_0 must be 
 flushed as well. This fixes 21 piglit tests on RV670. The flushing seems to 
 be fixed finally, but the piglit results are not yet up to par with RV730.

 All this code has been tested on RV670, RV730, and REDWOOD.


 It makes no sense and it's over engineer if you forget the initial
 design decision which was for a new kernel API which matched closely
 what r600g had.

Ah, sorry, I keep forgetting that.

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


[Mesa-dev] drm/i915 fails to prepare buffer map with large textures

2012-02-02 Thread Anuj Phogat

   width, height parameter of glTexImage2D() includes: texture image
   width + 2 * border (if any). So when doing the texture size check
   in _mesa_test_proxy_teximage() width and height should not exceed
   maximum supported size for target texture type.
   i.e. 1  (ctx-Const.MaxTextureLevels - 1)
  
   This patch fixes Intel oglconform test case: max_values
   Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44970
  
   Note: This is a candidate for mesa 8.0 branch.
  
   Signed-off-by: Anuj Phogatanuj.pho...@gmail.com
   ---
 src/mesa/main/teximage.c |   22 +++---
 1 files changed, 11 insertions(+), 11 deletions(-)
  
   diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
   index d11425d..018aca0 100644
   --- a/src/mesa/main/teximage.c
   +++ b/src/mesa/main/teximage.c
   @@ -1179,7 +1179,7 @@ _mesa_test_proxy_teximage(struct gl_context
   *ctx, GLenum target, GLint level,
switch (target) {
case GL_PROXY_TEXTURE_1D:
   maxSize = 1  (ctx-Const.MaxTextureLevels - 1);
   -  if (width  2 * border || width  2 + maxSize)
   +  if (width  2 * border || width  maxSize)
  
   Anuj,
  
   I may be missing something, but I'm still unsure about this,
   because this will create problems for drivers that do support
   borders.
 
  AFAIK, the only desktop graphics hardware that ever supported borders
  is
  NVIDIA.  Their driver follows the convention (width + 2 * border) 
  maxSize, and their driver advertises a maximum size of 2^n.  I tried
  creating a proxy texture that was the full 2^n plus a border on their
  closed-source Linux driver, and it was rejected.  A proxy texture
  2^n-2
  plus a border was accepted.
 
  Based on that, I believe this patch is correct.

 Fair enough. Sounds good to me then!


 patch in commit 15986d21ebaaeedb234b066edba5cf7f6ea87a3c made the intel 
 oglconform test to pass. But the errors reported in oglconform failure stays 
 unfixed. This is confirmed by a piglit test case I developed to reproduce the 
 errors. Test case (validate-texture-size) is posted on piglit mailing list 
 for review.

 Driver throws assertion failure or segfaults with large textures even much 
 below the maximum supported size.

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

 Further debugging  shows an error while preparing buffer map in
 intel_region_map( ) =
 drm_intel_gem_bo_map_gtt( ) = drmIoctl() returns -1
Error preparing buffer map
strerror(errno) = 0x4dd6c234
bo_gem-gtt_virtual=0x0
region-map = 0x0
dstMap = 0x0 in store_texsubimage()
which results in error GL_OUT_OF_MEMORY in glTexSubImage .
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 42128] Crash when visiting a site with Firefox

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

--- Comment #7 from awima...@gmail.com 2012-02-02 22:57:21 PST ---
today i experienced the same problem when trying to open github.com 

$ firefox -safe-mode
Mesa 7.11.2 implementation error: unexpected format in
_mesa_choose_tex_format()
Please report at bugs.freedesktop.org
Mesa 7.11.2 implementation error: unexpected MESA_FORMAT for renderbuffer
Please report at bugs.freedesktop.org
###!!! ABORT: Divide by zero: file
/build/src/mozilla-release/toolkit/xre/nsSigHandlers.cpp, line 174
###!!! ABORT: Divide by zero: file
/build/src/mozilla-release/toolkit/xre/nsSigHandlers.cpp, line 174
Segmentation fault

other sites like google and youtube worked just fine. also chromium web browser
had no problem with github on the same machine. 

Mozilla Firefox 10.0

mesa 7.11.2-1

Linux blah 3.2.2-1-ARCH #1 SMP PREEMPT Thu Jan 26 08:28:27 UTC 2012 i686
Intel(R) Celeron(R) M processor 1300MHz GenuineIntel GNU/Linux

00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated
Graphics Device (rev 02)

openbox window manager

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


[Mesa-dev] [Bug 45578] New: main/image.c:1659: _mesa_convert_colors: Assertion `dstType == 0x1403' failed.

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

 Bug #: 45578
   Summary: main/image.c:1659: _mesa_convert_colors: Assertion
`dstType == 0x1403' failed.
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: v...@freedesktop.org


mesa: 84a1273e7fe1216a4724ab13cd061a12b48893c2 (master)

Run piglit fbo-mipmap-copypix on swrast.

$ ./bin/fbo-mipmap-copypix -auto
Mesa: Initializing x86-64 optimizations
fbo-mipmap-copypix: main/image.c:1659: _mesa_convert_colors: Assertion `dstType
== 0x1403' failed.
Aborted (core dumped)

(gdb) bt
#0  0x7fd272be73b5 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x7fd272beab1b in __GI_abort () at abort.c:92
#2  0x7fd272bdfd2d in __GI___assert_fail (assertion=0x7fd270a0bf8c dstType
== 0x1403, 
file=optimized out, line=1659, function=optimized out) at assert.c:81
#3  0x7fd2708a500b in _mesa_convert_colors (srcType=5126,
src=0x7fd26f4f2010, dstType=33640, 
dst=0x7fd26f4f2010, count=512, mask=optimized out) at main/image.c:1659
#4  0x7fd270997f78 in convert_color_type (newType=33640, span=optimized
out, output=optimized out)
at swrast/s_span.c:959
#5  _swrast_write_rgba_span (ctx=optimized out, span=optimized out) at
swrast/s_span.c:1331
#6  0x7fd270989e25 in copy_rgba_pixels (ctx=0x23fbb30, srcx=0,
srcy=optimized out, width=512, 
height=512, destx=0, desty=0) at swrast/s_copypix.c:192
#7  0x7fd27098ad06 in _swrast_CopyPixels (ctx=0x23fbb30, srcx=0, srcy=0,
width=512, height=512, destx=0, 
desty=0, type=6144) at swrast/s_copypix.c:636
#8  0x7fd27087d2cd in _mesa_CopyPixels (srcx=0, srcy=0, width=512,
height=512, type=6144)
at main/drawpix.c:232
#9  0x0042a131 in test_mipmap_copypixels (srcIntFormat=32856,
dstIntFormat=32857, 
doPixelTransfer=0 '\000', useReadDrawPix=0 '\000') at
piglit/tests/fbo/fbo-mipmap-copypix.c:172
#10 0x0042a41c in piglit_display () at
piglit/tests/fbo/fbo-mipmap-copypix.c:257
#11 0x0042aba1 in display () at piglit/tests/util/piglit-framework.c:56
#12 0x7fd2732a7220 in fghRedrawWindow (window=0x23d9a70) at
freeglut_main.c:210
#13 fghcbDisplayWindow (window=0x23d9a70, enumerator=0x7fffed297eb0) at
freeglut_main.c:227
#14 0x7fd2732aa939 in fgEnumWindows (enumCallback=0x7fd2732a7120
fghcbDisplayWindow, 
enumerator=0x7fffed297eb0) at freeglut_structure.c:394
#15 0x7fd2732a765a in fghDisplayAll () at freeglut_main.c:249
#16 glutMainLoopEvent () at freeglut_main.c:1450
#17 0x7fd2732a7f0e in glutMainLoop () at freeglut_main.c:1498
#18 0x0042b310 in main (argc=1, argv=0x7fffed298208)
at piglit/tests/util/piglit-framework.c:304
(gdb) frame 3
#3  0x7fd2708a500b in _mesa_convert_colors (srcType=5126,
src=0x7fd26f4f2010, dstType=33640, 
dst=0x7fd26f4f2010, count=512, mask=optimized out) at main/image.c:1659
1659 ASSERT(dstType == GL_UNSIGNED_SHORT);
(gdb) print /x dstType
$1 = 0x8368

piglit/tests/util/glew.h:1218:#define GL_UNSIGNED_INT_2_10_10_10_REV 0x8368
piglit/tests/util/glew.h:6080:#define GL_UNSIGNED_INT_2_10_10_10_REV 0x8368

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


[Mesa-dev] [Bug 42128] Crash when visiting a site with Firefox

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

--- Comment #8 from awhan awima...@gmail.com 2012-02-02 23:42:04 PST ---
just noticed that setting webgl.disabled to true in the about:config settings
of firefox lets me get away with the crashing when i visit github.com

incidently as mentioned in this bug report
https://bugs.freedesktop.org/show_bug.cgi?id=42611 firefox crashes when i visit
http://get.webgl.org/ as well

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