Re: [Mesa-dev] GL 3.0 glDrawPixels(integer format)
While looking into MapRenderbuffer for glDrawPixels, I ended up looking at integer again. It looks like GL 3.0 has added sanity to drawpixels for integer, which is to say that they've disallowed it. Well I suppose the usual plan, test on binary drivers, though I expect it works on nvidia, fails on fglrx. We do also need to do something about the GL3.0 reporting as the current code specifies EXT_texture_integer which is more than the GL3.0 requirement. Maybe we need a sublevel of EXT_texture_integer support for drivers to report for GL3.0 support but not EXT_texture_integer support. But I'm happy that GL3.0 simply worked out the stupid and it nobody would possibly be using it for anything real. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: move ElementArrayBufferObj to gl_array_object
On Sat, Nov 26, 2011 at 09:01:51AM -0700, Brian Paul wrote: On 11/23/2011 06:15 PM, Yuanhan Liu wrote: On Wed, Nov 23, 2011 at 08:25:59AM -0700, Brian Paul wrote: On 11/23/2011 02:26 AM, Yuanhan Liu wrote: According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at page 515, the element buffer object is listed in vertex array object. So, move the ElementArrayBufferObj inside gl_array_object to make element buffer object per-vao. This would fix most of(3 left) intel oglc vao test fail Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com --- src/mesa/main/api_arrayelt.c |2 +- src/mesa/main/api_validate.c | 14 ++-- src/mesa/main/arrayobj.c |4 +++ src/mesa/main/attrib.c|7 ++--- src/mesa/main/bufferobj.c |9 ++- src/mesa/main/context.c |1 - src/mesa/main/get.c |2 +- src/mesa/main/mtypes.h|3 +- src/mesa/vbo/vbo_exec_array.c | 42 src/mesa/vbo/vbo_save_api.c |4 +- 10 files changed, 44 insertions(+), 44 deletions(-) I presume you've done a piglit run to check for regressions. Nope. But I did test this patch with all intel oglc testcases, and with no regression. Is this OK? You should probably find and run the piglit tests that use GL_ELEMENT_ARRAY_BUFFER, at least. Done and found no piglit regression. Can I push it? If no objection, I will push it tomorrow. Thanks, Yuanhan Liu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] mesa/formats: add mesa MESA_FORMAT_ARGB2101010_UINT description.
On Sun, Nov 27, 2011 at 10:42 PM, Eric Anholt e...@anholt.net wrote: On Sun, 27 Nov 2011 19:27:15 +, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com This format is used in the ARB_texture_rgb10_a2ui spec. Signed-off-by: Dave Airlie airl...@redhat.com --- src/mesa/main/formats.c | 17 + src/mesa/main/formats.h | 2 ++ 2 files changed, 19 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h index 5f60186..8699092 100644 --- a/src/mesa/main/formats.h +++ b/src/mesa/main/formats.h @@ -265,6 +265,8 @@ typedef enum MESA_FORMAT_Z32_FLOAT, MESA_FORMAT_Z32_FLOAT_X24S8, + MESA_FORMAT_ARGB2101010_UINT, + MESA_FORMAT_COUNT } gl_format; Hmm, are we at the point yet where we can safely put new enums somewhere more sensible than at the end of the list? Don't think so, format_info itself is still required in enum ordering, so I won't be taking that chance yet. and really we must nearly be out of formats, BPTC is all I can see coming we might be needing :-) Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] mesa/formats: add mesa MESA_FORMAT_ARGB2101010_UINT description.
On 11/28/2011 02:24 AM, Dave Airlie wrote: On Sun, Nov 27, 2011 at 10:42 PM, Eric Anholte...@anholt.net wrote: On Sun, 27 Nov 2011 19:27:15 +, Dave Airlieairl...@gmail.com wrote: From: Dave Airlieairl...@redhat.com This format is used in the ARB_texture_rgb10_a2ui spec. Signed-off-by: Dave Airlieairl...@redhat.com --- src/mesa/main/formats.c | 17 + src/mesa/main/formats.h |2 ++ 2 files changed, 19 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h index 5f60186..8699092 100644 --- a/src/mesa/main/formats.h +++ b/src/mesa/main/formats.h @@ -265,6 +265,8 @@ typedef enum MESA_FORMAT_Z32_FLOAT, MESA_FORMAT_Z32_FLOAT_X24S8, + MESA_FORMAT_ARGB2101010_UINT, + MESA_FORMAT_COUNT } gl_format; Hmm, are we at the point yet where we can safely put new enums somewhere more sensible than at the end of the list? Don't think so, format_info itself is still required in enum ordering, so I won't be taking that chance yet. I think the only places where we initialize tables in the order of the gl_format enums is in formats.c and s_texfetch.c. In both cases there's assertions that check that the tables are consistent. and really we must nearly be out of formats, BPTC is all I can see coming we might be needing :-) I don't see too many new formats coming along either. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: move ElementArrayBufferObj to gl_array_object
On 11/28/2011 01:50 AM, Yuanhan Liu wrote: On Sat, Nov 26, 2011 at 09:01:51AM -0700, Brian Paul wrote: On 11/23/2011 06:15 PM, Yuanhan Liu wrote: On Wed, Nov 23, 2011 at 08:25:59AM -0700, Brian Paul wrote: On 11/23/2011 02:26 AM, Yuanhan Liu wrote: According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at page 515, the element buffer object is listed in vertex array object. So, move the ElementArrayBufferObj inside gl_array_object to make element buffer object per-vao. This would fix most of(3 left) intel oglc vao test fail Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com --- src/mesa/main/api_arrayelt.c |2 +- src/mesa/main/api_validate.c | 14 ++-- src/mesa/main/arrayobj.c |4 +++ src/mesa/main/attrib.c|7 ++--- src/mesa/main/bufferobj.c |9 ++- src/mesa/main/context.c |1 - src/mesa/main/get.c |2 +- src/mesa/main/mtypes.h|3 +- src/mesa/vbo/vbo_exec_array.c | 42 src/mesa/vbo/vbo_save_api.c |4 +- 10 files changed, 44 insertions(+), 44 deletions(-) I presume you've done a piglit run to check for regressions. Nope. But I did test this patch with all intel oglc testcases, and with no regression. Is this OK? You should probably find and run the piglit tests that use GL_ELEMENT_ARRAY_BUFFER, at least. Done and found no piglit regression. Can I push it? If no objection, I will push it tomorrow. I think you can push this. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gl-3.0/api/drawpixels-integer: New test for GL 3.0 integer glDrawPixels.
On 11/27/2011 07:08 PM, Eric Anholt wrote:
When the extension was folded in, glDrawPixels of integer formats was
disallowed. Disable the GL_EXT_texture_integer if 3.0 is exposed, and
replace it with a simple make sure it throws the error API test.
I think actually the intent was that this is a correction to
EXT_texture_integer, because I don't see how it was actually supposed
to work back then (see comment in fbo-integer-precision-drawpixels).
---
Here's what I get with the NVIDIA driver:
$ bin/gl-3.0-drawpixels-integer -auto
PIGLIT: {'result': 'pass' }
$ bin/ext_texture_integer-fbo_integer_precision_drawpixels -auto
GL 3.0 obsoletes this test
PIGLIT: {'result': 'skip' }
$ bin/ext_texture_integer-api-drawpixels -auto
See tests/spec/gl-3.0/api/drawpixels-integer.c
PIGLIT: {'result': 'skip' }
Reviewed-by: Brian Paul bri...@vmware.com
Tested-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] mesa: Reject glDrawPixels(integer format) on GL 3.0 or greater.
On 11/27/2011 07:08 PM, Eric Anholt wrote: When folding GL_EXT_texture_integer into the core, a new (and very sensible) restriction was added. --- src/mesa/main/drawpix.c | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) 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 5/7] mesa: Fix the datatype of GL_DEPTH32F_STENCIL8's depth channel.
On 11/27/2011 03:48 PM, Eric Anholt wrote:
On Wed, 23 Nov 2011 13:52:07 -0700, Brian Paulbri...@vmware.com wrote:
On 11/23/2011 01:37 PM, Eric Anholt wrote:
Asking for the datatype of MESA_FORMAT_Z32_FLOAT_X24S8 is a bit funny
-- there's a float depth channel, and a stencil channel that doesn't
have a particular GLenum associated with its type, so what's the correct
response?
Because there is no query for stencil, just make this format's
datatype be that of the depth channel. It fixes the depth query (and
thus a failure in piglit gl-3.0-required-sized-formats), and none of
the other consumers of the _mesa_get_format_datatype() API care.
---
src/mesa/main/formats.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index b934bd4..324de65 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -1473,7 +1473,7 @@ static struct gl_format_info
format_info[MESA_FORMAT_COUNT] =
MESA_FORMAT_Z32_FLOAT_X24S8, /* Name */
MESA_FORMAT_Z32_FLOAT_X24S8, /* StrName */
GL_DEPTH_STENCIL,/* BaseFormat */
- GL_NONE /* XXX */, /* DataType */
+ GL_FLOAT,/* DataType */
0, 0, 0, 0, /* Red/Green/Blue/AlphaBits */
0, 0, 0, 32, 8, /* Lum/Int/Index/Depth/StencilBits */
1, 1, 8 /* BlockWidth/Height,Bytes */
Minor nit: maybe add a comment to the effect of we're ignoring stencil.
Updated version:
{
MESA_FORMAT_Z32_FLOAT, /* Name */
MESA_FORMAT_Z32_FLOAT, /* StrName */
GL_DEPTH_COMPONENT, /* BaseFormat */
/* DataType here is used to answer GL_TEXTURE_DEPTH_TYPE queries, and is
* never used for stencil because stencil is always GL_UNSIGNED_INT.
*/
GL_FLOAT,
0, 0, 0, 0, /* Red/Green/Blue/AlphaBits */
0, 0, 0, 32, 0, /* Lum/Int/Index/Depth/StencilBits */
1, 1, 4 /* BlockWidth/Height,Bytes */
},
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] Allow glTexImage2D with a depth component cube map
On 11/26/2011 08:13 PM, Anuj Phogat wrote: Hi Brian, This is an updated patch to allow glTexImage2D with a depth component cube map. Patch was producing an expected ouput with depth-cube-map test (posted on piglit mailing list). But i'm getting an incorrect output since i updated my mesa branch with git://anongit.freedesktop.org/mesa/mesa. Luminance value is not getting copied to green and blue channels. So the color value i'm seeing in fragment shader is (L,0,0,1). I verified that this issue is only with depth cube maps not with depth 2D textures. Is this a known issue? I will try to debug it further. Which driver are you testing with? Just figured out that my path for libdrm wasn't set correctly so driver was falling back to software rasterizer. glxinfo output: OpenGL vendor string: Mesa Project OpenGL renderer string: Software Rasterizer OpenGL version string: 3.0 Mesa 7.12-devel (git-24d25b5) OpenGL shading language version string: 1.30 So, the software rasterizer is not copying the Luminance value to green and blue channels. I'm getting the expected output (L,L,L,1) on setting correct path for libdrm. glxinfo output: OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile x86/MMX/SSE2 OpenGL version string: 3.0 Mesa 7.12-devel (git-24d25b5) OpenGL shading language version string: 1.30 I think you need to update swrast/s_texfilter.c to use sample_depth_texture() for cube textures. Same thing for 1D/2D_ARRAY textures too, it appears. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] mesa: access pixels as GLushort in unpack_SL8()
Per the format comments and the texstore code, use a GLushort to access the
pixel. The code was OK as-is on little endian machines.
---
src/mesa/main/format_unpack.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index 0ab6940..0411f5f 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -749,13 +749,13 @@ unpack_SL8(const void *src, GLfloat dst[][4], GLuint n)
static void
unpack_SLA8(const void *src, GLfloat dst[][4], GLuint n)
{
- const GLubyte *s = (const GLubyte *) src;
+ const GLushort *s = (const GLushort *) src;
GLuint i;
for (i = 0; i n; i++) {
dst[i][RCOMP] =
dst[i][GCOMP] =
- dst[i][BCOMP] = nonlinear_to_linear(s[i*2+0]);
- dst[i][ACOMP] = UBYTE_TO_FLOAT(s[i*2+1]); /* linear! */
+ dst[i][BCOMP] = nonlinear_to_linear(s[i] 0xff);
+ dst[i][ACOMP] = UBYTE_TO_FLOAT(s[i] 8); /* linear! */
}
}
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] i965: Don't depth test the fake depthbuffer when one isn't present.
For the non-separate-stencil-only case, we've been using a NULL
surface for depth, so we didn't have to care. However, to support
separate stencil with no depthbuffer, we have to make the depth
surface non-NULL or the stencil test always fails thanks to separate
stencil inheriting the surface type of depth.
Fixes hiz-depth-stencil-test-d0-s8.
---
src/mesa/drivers/dri/i965/gen6_depthstencil.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_depthstencil.c
b/src/mesa/drivers/dri/i965/gen6_depthstencil.c
index eec1bf6..c601a8f 100644
--- a/src/mesa/drivers/dri/i965/gen6_depthstencil.c
+++ b/src/mesa/drivers/dri/i965/gen6_depthstencil.c
@@ -25,6 +25,7 @@
*
*/
+#include intel_fbo.h
#include brw_context.h
#include brw_state.h
@@ -33,6 +34,10 @@ gen6_upload_depth_stencil_state(struct brw_context *brw)
{
struct gl_context *ctx = brw-intel.ctx;
struct gen6_depth_stencil_state *ds;
+ struct intel_renderbuffer *depth_irb;
+
+ /* _NEW_BUFFERS */
+ depth_irb = intel_get_renderbuffer(ctx-DrawBuffer, BUFFER_DEPTH);
ds = brw_state_batch(brw, AUB_TRACE_DEPTH_STENCIL_STATE,
sizeof(*ds), 64,
@@ -77,7 +82,7 @@ gen6_upload_depth_stencil_state(struct brw_context *brw)
}
/* _NEW_DEPTH */
- if (ctx-Depth.Test || brw-hiz.op) {
+ if ((ctx-Depth.Test || brw-hiz.op) depth_irb) {
assert(brw-hiz.op != BRW_HIZ_OP_DEPTH_RESOLVE || ctx-Depth.Test);
assert(brw-hiz.op != BRW_HIZ_OP_HIZ_RESOLVE || !ctx-Depth.Test);
assert(brw-hiz.op != BRW_HIZ_OP_DEPTH_CLEAR || !ctx-Depth.Test);
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] i965: Don't double the depth width for separate-stencil-only rendering.
This looks to have been confused with pitch setup, which does have to be doubled. The width is inherited by separate stencil, and it should naturally look like the setup in the block below involving a valid depthbuffer. --- src/mesa/drivers/dri/i965/brw_misc_state.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c b/src/mesa/drivers/dri/i965/brw_misc_state.c index cb1405c..f6a5ad6 100644 --- a/src/mesa/drivers/dri/i965/brw_misc_state.c +++ b/src/mesa/drivers/dri/i965/brw_misc_state.c @@ -298,7 +298,7 @@ static void emit_depthbuffer(struct brw_context *brw) (BRW_SURFACE_2D 29)); OUT_BATCH(0); OUT_BATCH(((region-width - 1) 6) | -(2 * region-height - 1) 19); +(region-height - 1) 19); OUT_BATCH(0); OUT_BATCH(0); -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] i965: Don't perform the precompile on fragment shaders by default.
It is useful to have this option for shader-db, and it was also good
at the time where we were rejecting shaders due to various internal
limits we hadn't supported yet. However, at this point the precompile
step takes extra time (since not all NOS is known at link time) and
spews misleading debug in the common case of debugging a real app.
This is left in place for VS, where we still have a couple of codegen
failure paths that result in link failure through precompile. Those
need to be fixed.
shader-db can still get at the debug info it wants using
shader_precompile=true driconf option.
---
src/mesa/drivers/dri/i965/brw_context.c |1 +
src/mesa/drivers/dri/i965/brw_context.h |1 +
src/mesa/drivers/dri/i965/brw_shader.cpp |4 +++-
src/mesa/drivers/dri/intel/intel_screen.c |6 +-
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 5dcf8dd..1163007 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -327,6 +327,7 @@ brwCreateContext(int api,
brw_draw_init( brw );
brw-new_vs_backend = (getenv(INTEL_OLD_VS) == NULL);
+ brw-precompile = driQueryOptionb(intel-optionCache, shader_precompile);
/* If we're using the new shader backend, we require integer uniforms
* stored as actual integers.
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index c1b123f5..a1119bb 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -604,6 +604,7 @@ struct brw_context
bool has_aa_line_parameters;
bool has_pln;
bool new_vs_backend;
+ bool precompile;
struct {
struct brw_state_flags dirty;
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index f25fab3..33c9ae5 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -65,7 +65,9 @@ brw_new_shader_program(struct gl_context *ctx, GLuint name)
bool
brw_shader_precompile(struct gl_context *ctx, struct gl_shader_program *prog)
{
- if (!brw_fs_precompile(ctx, prog))
+ struct brw_context *brw = brw_context(ctx);
+
+ if (brw-precompile !brw_fs_precompile(ctx, prog))
return false;
if (!brw_vs_precompile(ctx, prog))
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 46b822c..f67bef9 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -76,10 +76,14 @@ PUBLIC const char __driConfigOptions[] =
DRI_CONF_OPT_BEGIN(stub_occlusion_query, bool, false)
DRI_CONF_DESC(en, Enable stub ARB_occlusion_query support on
915/945.)
DRI_CONF_OPT_END
+
+ DRI_CONF_OPT_BEGIN(shader_precompile, bool, false)
+DRI_CONF_DESC(en, Perform code generation at shader link time.)
+ DRI_CONF_OPT_END
DRI_CONF_SECTION_END
DRI_CONF_END;
-const GLuint __driNConfigOptions = 11;
+const GLuint __driNConfigOptions = 12;
#include intel_batchbuffer.h
#include intel_buffers.h
--
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 1/2] mesa: fix comments for RG formats
On Mon, 28 Nov 2011 11:14:17 -0700, Brian Paul bri...@vmware.com wrote: The position of the red and green bits was misstated in the comments. Arguably, the names of these formats should be changed to GR to reflect the component ordering and to be consistent with other formats. Actually, could we get consistency in that naming? Or at least a comment for now here and in _mesa_format_matches_format_and_type(), where it's likely to get screwed up? pgpUEecIXahF7.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] swrast: Fix some static analysis warnings
To each switch statement in s_texfilter.c, add a break statement to the default case. Eliminates the Eclipse static analysis warning: No break at the end of this case. Signed-off-by: Chad Versace chad.vers...@linux.intel.com --- src/mesa/swrast/s_texfilter.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/src/mesa/swrast/s_texfilter.c b/src/mesa/swrast/s_texfilter.c index 5662625..fb172f3 100644 --- a/src/mesa/swrast/s_texfilter.c +++ b/src/mesa/swrast/s_texfilter.c @@ -273,6 +273,7 @@ linear_texel_locations(GLenum wrapMode, default: _mesa_problem(NULL, Bad wrap mode); u = 0.0F; + break; } *weight = FRAC(u); } @@ -471,6 +472,7 @@ clamp_rect_coord_linear(GLenum wrapMode, GLfloat coord, GLint max, _mesa_problem(NULL, bad wrapMode in clamp_rect_coord_linear); i0 = i1 = 0; fcol = 0.0F; + break; } *i0out = i0; *i1out = i1; @@ -533,6 +535,7 @@ nearest_texcoord(const struct gl_texture_object *texObj, break; default: *i = *j = *k = 0; + break; } } @@ -589,6 +592,7 @@ linear_texcoord(const struct gl_texture_object *texObj, default: *slice = 0; + break; } } @@ -787,6 +791,7 @@ get_border_color(const struct gl_texture_object *tObj, break; default: COPY_4V(rgba, tObj-Sampler.BorderColor.f); + break; } } @@ -1537,6 +1542,7 @@ sample_lambda_2d(struct gl_context *ctx, break; default: _mesa_problem(ctx, Bad mag filter in sample_lambda_2d); + break; } } } @@ -2528,6 +2534,7 @@ sample_lambda_cube(struct gl_context *ctx, break; default: _mesa_problem(ctx, Bad min filter in sample_lambda_cube); + break; } } @@ -2545,6 +2552,7 @@ sample_lambda_cube(struct gl_context *ctx, break; default: _mesa_problem(ctx, Bad mag filter in sample_lambda_cube); + break; } } } @@ -3473,6 +3481,7 @@ sample_depth_texture( struct gl_context *ctx, break; default: _mesa_problem(ctx, Bad depth texture mode); +break; } } } -- 1.7.7.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43316] New: swrast/s_texfetch.c:1274: _mesa_get_texel_fetch_func: Assertion `texfetch_funcs[fmt].Name == fmt' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=43316 Bug #: 43316 Summary: swrast/s_texfetch.c:1274: _mesa_get_texel_fetch_func: Assertion `texfetch_funcs[fmt].Name == fmt' failed. Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: v...@vmware.com mesa: c5012c1d56dfbf11cd631b3b37890b40d56ac884 (master) Run piglit fdo10370 on swrast. $ ./bin/fdo10370 -auto fdo10370: swrast/s_texfetch.c:1274: _mesa_get_texel_fetch_func: Assertion `texfetch_funcs[fmt].Name == fmt' failed. Aborted (core dumped) (gdb) bt #0 0x0032f416 in __kernel_vsyscall () #1 0x004db941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x004dee42 in abort () at abort.c:92 #3 0x004d48e8 in __assert_fail (assertion=0xe0ac38 texfetch_funcs[fmt].Name == fmt, file=0xe0ac21 swrast/s_texfetch.c, line=1274, function=0xe0ad0c _mesa_get_texel_fetch_func) at assert.c:81 #4 0x00c83fa8 in _mesa_get_texel_fetch_func (format=MESA_FORMAT_RGBA, dims=2) at swrast/s_texfetch.c:1274 #5 0x00c84173 in set_fetch_functions (texImage=0x927f970, dims=2) at swrast/s_texfetch.c:1318 #6 0x00c84236 in _mesa_update_fetch_functions (texObj=0x9276678) at swrast/s_texfetch.c:1333 #7 0x00c6311a in _swrast_update_texture_samplers (ctx=0x9096c78) at swrast/s_context.c:480 #8 0x00c6337e in _swrast_validate_derived (ctx=0x9096c78) at swrast/s_context.c:570 #10 0x00c634b9 in _swrast_Triangle (ctx=0x9096c78, v0=0xb6e05228, v1=0xb6e05430, v2=0xb6e05020) at swrast/s_context.c:628 #11 0x00ca44fe in triangle_rgba (ctx=0x9096c78, e0=1, e1=2, e2=0) at swrast_setup/ss_tritmp.h:176 #12 0x00c291a9 in _tnl_render_poly_verts (ctx=0x9096c78, start=0, count=4, flags=57) at tnl/t_vb_rendertmp.h:352 #13 0x00c2b16f in run_render (ctx=0x9096c78, stage=0x9107628) at tnl/t_vb_render.c:321 #14 0x00c1c0e5 in _tnl_run_pipeline (ctx=0x9096c78) at tnl/t_pipeline.c:163 #15 0x00c1d5cf in _tnl_draw_prims (ctx=0x9096c78, arrays=0x90f5308, prim=0x90f3c64, nr_prims=1, ib=0x0, min_index=0, max_index=3) at tnl/t_draw.c:538 #16 0x00c1d2e3 in _tnl_vbo_draw_prims (ctx=0x9096c78, arrays=0x90f5308, prim=0x90f3c64, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at tnl/t_draw.c:438 #17 0x00c04608 in vbo_exec_vtx_flush (exec=0x90f3850, keepUnmapped=1 '\001') at vbo/vbo_exec_draw.c:405 #18 0x00bfe11f in vbo_exec_FlushVertices_internal (exec=0x90f3850, unmap=1 '\001') at vbo/vbo_exec_api.c:444 #19 0x00c00138 in vbo_exec_FlushVertices (ctx=0x9096c78, flags=1) at vbo/vbo_exec_api.c:1188 #20 0x00d4db5e in enable_texture (ctx=0x9096c78, state=0 '\000', texBit=128) at main/enable.c:247 #21 0x00d4fd31 in _mesa_set_enable (ctx=0x9096c78, cap=3553, state=0 '\000') at main/enable.c:596 #22 0x00d51168 in _mesa_Disable (cap=3553) at main/enable.c:967 #23 0x00b40deb in save_Disable (cap=3553) at main/dlist.c:2205 #24 0x08049164 in display () at piglit/tests/bugs/fdo10370.c:81 #25 0x00490820 in fghRedrawWindow (window=0x9094838, enumerator=0xbfecb148) at freeglut_main.c:210 #26 fghcbDisplayWindow (window=0x9094838, enumerator=0xbfecb148) at freeglut_main.c:227 #27 0x00494660 in fgEnumWindows (enumCallback=0x490790 fghcbDisplayWindow, enumerator=0xbfecb148) at freeglut_structure.c:394 #28 0x00490cdb in fghDisplayAll () at freeglut_main.c:249 #29 glutMainLoopEvent () at freeglut_main.c:1450 #30 0x00491605 in glutMainLoop () at freeglut_main.c:1498 #31 0x08049658 in main (argc=2, argv=0xbfecb3c4) at piglit/tests/bugs/fdo10370.c:170 (gdb) frame 4 #4 0x00c83fa8 in _mesa_get_texel_fetch_func (format=MESA_FORMAT_RGBA, dims=2) at swrast/s_texfetch.c:1274 1274 assert(texfetch_funcs[fmt].Name == fmt); (gdb) print texfetch_funcs[fmt].Name $1 = MESA_FORMAT_NONE (gdb) print fmt $2 = MESA_FORMAT_ARGB2101010_UINT -- 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 1/7] i965: Base HW depth format setup based on MESA_FORMAT, not bpp.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/23/2011 12:37 PM, Eric Anholt wrote:
This will make handling new formats (like actually exposing Z32F)
easier and more reliable.
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 53
+--
src/mesa/drivers/dri/i965/brw_state.h |9 +++--
src/mesa/drivers/dri/i965/gen7_misc_state.c | 30 +---
src/mesa/drivers/dri/i965/gen7_sf_state.c |2 +-
src/mesa/drivers/dri/intel/intel_context.h |1 -
5 files changed, 41 insertions(+), 54 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index f6a5ad6..e66f361 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -197,6 +197,39 @@ const struct brw_tracked_state brw_psp_urb_cbs = {
.emit = upload_psp_urb_cbs,
};
+uint32_t
+brw_depthbuffer_format(struct brw_context *brw)
+{
+ struct intel_context *intel = brw-intel;
+ struct gl_context *ctx = intel-ctx;
+ struct gl_framebuffer *fb = ctx-DrawBuffer;
+ struct intel_renderbuffer *drb = intel_get_renderbuffer(fb, BUFFER_DEPTH);
+ struct intel_renderbuffer *srb;
+
+ if (!drb
+ (srb = intel_get_renderbuffer(fb, BUFFER_STENCIL))
+ srb-Base.Format == MESA_FORMAT_S8_Z24) {
+ drb = srb;
+ }
+
+ switch (drb-Base.Format) {
+ case MESA_FORMAT_Z16:
+ return BRW_DEPTHFORMAT_D16_UNORM;
+ case MESA_FORMAT_Z32_FLOAT:
+ return BRW_DEPTHFORMAT_D32_FLOAT;
+ case MESA_FORMAT_X8_Z24:
+ case MESA_FORMAT_S8_Z24:
+ if (intel_framebuffer_has_hiz(ctx-DrawBuffer))
+ return BRW_DEPTHFORMAT_D24_UNORM_X8_UINT;
+ else
+ return BRW_DEPTHFORMAT_D24_UNORM_S8_UINT;
I don't believe the special case for hiz is necessary. This should
work just fine:
+ case MESA_FORMAT_X8_Z24:
+ return BRW_DEPTHFORMAT_D24_UNORM_X8_UINT;
+ case MESA_FORMAT_S8_Z24:
+ return BRW_DEPTHFORMAT_D24_UNORM_S8_UINT;
I assume that you special-cased hiz because the old logic in emit_depthbuffer(),
which reverse-engineered the format from the bpp, did so?
-
Chad Versace
chad.vers...@linux.intel.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJO0+pPAAoJEAIvNt057x8iMksP/A18jdaxQhgh172LjLT7gOsF
9Tg1lgp5tvXloPjmRT7xiKUjf2aRWWWyc9WWsXgXTrOrEhRrF+VKTpQPPLKXcYl3
ApFh1Z6zg+dFtKs/bc7i6eF+XkPEEvx+usvwE7RXGXrmUHXZe1vPsrCT3KneoIXV
iE36+DnhJxI6p2YUj9vzd0CwjAWms+bvvcWrwt3shwZtx4HuxV8hdhcnKa/uLrcF
GJLoet/I/IcV/4cDhmZnKfOL649Sn0OEi2Lh204G+ClzLAZ01jkPTwQoMz6oAERu
6aH73OxRB7iZYgYcyHj4ri/9nDj/5NgfZUZ1GjEcMRZ9bPk4Hc9hQ+k/AwEuBK2k
x5vXrMd4qBqAE/cURkYsqYG9JfF1CeAn+7OLdhQo/RVS0FlYtz5iQhRCJFqZuHA3
5IqiIXCW5AHflrKtPrUzUt4E4QrR/Zw0Z5Il4x6yUb/dHdg0lORf7Za4TI6aVyzu
ObcRELKrj2s/lfPN/dpXLG2vJ4pgiyyAlyF3QVvBTX66xHsaLeDX60sLo3dR2mZP
Vc4Vb8M4ZG3Pq9IUd52GMZtuOtPtL9HrE4ZjDjWIJdUdKd2vuGrS86ewioeiL9Oa
Y21C0RXZOnUavmr59CBp94j2wLvYmO9px5WLMpQV5s9UwhgkkocXZKAjSeukNQzB
3K14mqoOQbvOFfqw3+pP
=873b
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XCB-only GLX protocol?
On 11/27/11 9:13 PM, Ian Romanick wrote: I'm starting to work on GLX_ARB_create_context. This extension and the layered GLX_ARB_create_context_profile extension add some GLX protocol. Is there any reason to keep supporting non-XCB protocol? Are there any platforms that can't / don't use XCB for X protocol? I'm not planning to gut any non-XCB code yet, but that would happen eventually. I just don't want to implement all of the protocol twice. That seems like an unnecessary hassle. If I had my choice, I'd prefer we drop non-XCB protocol sooner than later. IIRC there's some error paths that are difficult and/or ugly to get right without it. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] reworking pipe_video_decoder / pipe_video_buffer
Maarten Lankhorst wrote: For some reason mplayer handles all the above images as progressive with vdpau, and it sets picture_structure to 3. I can see the interlacing on movement, but it doesn't seem like mplayer tells vdpau it is interlaced, sigh. :/ That's a shame. Is there another way that the decoder will know that it's dealing with interlaced? I see lots of reference to interlaced at motion block type level. Thinking of the future - doesn't H264 have MBAFF - so is mplayer expected to tell the decoder for each motion block? Does mplayer behave differently if you use -vo vdpau:deint=1? IIRC it says in the vdpau headers/somewhere that nvidia keep fields separate internally. Doesn't look like it says it in the headers, but it doesn't really surprise me.. Hmm, I can't find where I read that now. I did see in the libvdpau header (really this time) that it's OK to treat what the player flags as progressive as interlaced to allow for mixed streams and bad edits. But I read on the nvidia site that they don't advise this (not sure if they mean just in a telecine case, though) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43316] swrast/s_texfetch.c:1274: _mesa_get_texel_fetch_func: Assertion `texfetch_funcs[fmt].Name == fmt' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=43316 --- Comment #3 from Vinson Lee v...@vmware.com 2011-11-28 13:26:14 PST --- (In reply to comment #2) Created attachment 53914 [details] [review] patch to add missing table entry This should do it, Vinson. Can you test? Patch 53914 fixes fdo10370 on swrast. Tested-by: Vinson Lee v...@vmware.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] [PATCH] gallium/i965g: hide that utterly broken driver better
And warn loudly in case people want to use it. Too many tester report gpu hangs on irc and we rootcause this ... Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch --- configure.ac |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 8885a6d..4dee3ad 100644 --- a/configure.ac +++ b/configure.ac @@ -658,7 +658,7 @@ GALLIUM_DRIVERS_DEFAULT=r300,r600,swrast AC_ARG_WITH([gallium-drivers], [AS_HELP_STRING([--with-gallium-drivers@:@=DIRS...@:@], [comma delimited Gallium drivers list, e.g. -i915,i965,nouveau,r300,r600,svga,swrast +i915,nouveau,r300,r600,svga,swrast @:@default=r300,r600,swrast@:@])], [with_gallium_drivers=$withval], [with_gallium_drivers=$GALLIUM_DRIVERS_DEFAULT]) @@ -2007,10 +2007,17 @@ if echo $SRC_DIRS | grep 'gallium' /dev/null 21; then echo Winsys dirs: $GALLIUM_WINSYS_DIRS echo Driver dirs: $GALLIUM_DRIVERS_DIRS echo Trackers dirs: $GALLIUM_STATE_TRACKERS_DIRS + if echo $GALLIUM_DRIVERS_DIRS | grep i965 /dev/null 21; then + echo + echo WARNING: enabling i965 gallium driver + echo the i965g driver is currently utterly broken, only for adventurours developers + echo + fi else echo Gallium: no fi + dnl Libraries echo echo Shared libs: $enable_shared -- 1.7.7.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/i965g: hide that utterly broken driver better
On Mon, Nov 28, 2011 at 3:32 PM, Daniel Vetter daniel.vet...@ffwll.chwrote: And warn loudly in case people want to use it. Too many tester report gpu hangs on irc and we rootcause this ... Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch --- configure.ac |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 8885a6d..4dee3ad 100644 --- a/configure.ac +++ b/configure.ac @@ -658,7 +658,7 @@ GALLIUM_DRIVERS_DEFAULT=r300,r600,swrast AC_ARG_WITH([gallium-drivers], [AS_HELP_STRING([--with-gallium-drivers@:@=DIRS...@:@], [comma delimited Gallium drivers list, e.g. -i915,i965,nouveau,r300,r600,svga,swrast +i915,nouveau,r300,r600,svga,swrast @:@default=r300,r600,swrast@:@])], [with_gallium_drivers=$withval], [with_gallium_drivers=$GALLIUM_DRIVERS_DEFAULT]) @@ -2007,10 +2007,17 @@ if echo $SRC_DIRS | grep 'gallium' /dev/null 21; then echo Winsys dirs: $GALLIUM_WINSYS_DIRS echo Driver dirs: $GALLIUM_DRIVERS_DIRS echo Trackers dirs: $GALLIUM_STATE_TRACKERS_DIRS + if echo $GALLIUM_DRIVERS_DIRS | grep i965 /dev/null 21; then + echo + echo WARNING: enabling i965 gallium driver + echo the i965g driver is currently utterly broken, only for adventurours developers I think the word is adventurous. + echo + fi else echo Gallium: no fi + dnl Libraries echo echo Shared libs: $enable_shared -- 1.7.7.1 ___ 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
Re: [Mesa-dev] [PATCH] gallium/i965g: hide that utterly broken driver better
On 11/28/2011 01:32 PM, Daniel Vetter wrote: And warn loudly in case people want to use it. Too many tester report gpu hangs on irc and we rootcause this ... Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Yes! This eliminate some future bug reports too. Reviewed-by: Chad Versace chad.vers...@linux.intel.com Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] swrast: Fix some static analysis warnings
On 11/28/2011 12:47 PM, Chad Versace wrote: To each switch statement in s_texfilter.c, add a break statement to the default case. Eliminates the Eclipse static analysis warning: No break at the end of this case. Signed-off-by: Chad Versacechad.vers...@linux.intel.com That's pretty picky, but OK by me. 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] [Bug 43317] New: swrast: glean basic sanity fails
https://bugs.freedesktop.org/show_bug.cgi?id=43317 Bug #: 43317 Summary: swrast: glean basic sanity fails Classification: Unclassified Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: nmi...@gmail.com (gdb) run -t +basic -o -r b Starting program: /home/nicholas/src/git/piglit/bin/glean -t +basic -o -r b [Thread debugging using libthread_db enabled] Using host libthread_db library /lib64/libthread_db.so.1. Breakpoint 1, main (argc=6, argv=0x7fffe2f8) at /home/nicholas/src/git/piglit/tests/glean/main.cpp:63 63Options o; [New Thread 0x767fa700 (LWP 15117)] [New Thread 0x75ff9700 (LWP 15118)] [New Thread 0x757f8700 (LWP 15119)] [New Thread 0x74ff7700 (LWP 15120)] Detaching after fork from child process 15121. basic: PASS rgba8, db, z24, s8, win+pmap, id 33 basic: PASS rgba8, db, z24, s8, win+pmap, id 34 basic: PASS rgba8, db, z24, s8, win+pmap, id 106 basic: PASS rgba8, win+pmap, id 251 X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 72 (X_PutImage) Resource id in failed request: 0x311 Serial number of failed request: 169 Current serial number in output stream: 171 Breakpoint 2, __GI_exit (status=1) at exit.c:100 100 __run_exit_handlers (status, __exit_funcs, true); (gdb) bt #0 __GI_exit (status=1) at exit.c:100 #1 0x0030ebc47fc6 in _XDefaultError (dpy=optimized out, event=optimized out) at XlibInt.c:1534 #2 0x0030ebc4810f in _XError (dpy=0x7b6a60, rep=optimized out) at XlibInt.c:1583 #3 0x0030ebc44f91 in handle_error (dpy=0x7b6a60, err=0x8cece0, in_XReply=optimized out) at xcb_io.c:166 #4 0x0030ebc44fd5 in handle_response (dpy=0x7b6a60, response=0x8cece0, in_XReply=optimized out) at xcb_io.c:266 #5 0x0030ebc45de0 in _XReply (dpy=0x7b6a60, rep=0x7fffdbf0, extra=0, discard=1) at xcb_io.c:566 #6 0x0030ebc415a3 in XSync (dpy=0x7b6a60, discard=0) at Sync.c:44 #7 0x0030ebc4164b in _XSyncFunction (dpy=optimized out) at Synchro.c:35 #8 0x0030ebc39f55 in XPutImage (dpy=0x7b6a60, d=50331665, gc=0xb32650, image=0xb32990, req_xoffset=0, req_yoffset=0, x=0, y=0, req_width=320, req_height=320) at PutImage.c:1032 #9 0x77dcca1b in swrastPutImage (draw=optimized out, op=optimized out, x=optimized out, y=optimized out, w=optimized out, h=optimized out, data=0xb8c8c0 , loaderPrivate=0xb32530) at drisw_glx.c:202 #10 0x769b504f in put_image (height=optimized out, width=optimized out, data=optimized out, dPriv=optimized out) at drisw.c:68 #11 drisw_put_image (drawable=optimized out, data=optimized out, width=optimized out, height=optimized out) at drisw.c:99 #12 0x769b50d8 in drisw_present_texture (ptex=optimized out, dPriv=0xb32a20) at drisw.c:112 #13 drisw_copy_to_front (ptex=optimized out, dPriv=0xb32a20) at drisw.c:129 #14 drisw_flush_frontbuffer (drawable=optimized out, statt=ST_ATTACHMENT_FRONT_LEFT) at drisw.c:173 #15 0x769b6231 in dri_st_framebuffer_flush_front (stfbi=optimized out, statt=optimized out) at dri_drawable.c:106 #16 0x769b5814 in dri_unbind_context (cPriv=optimized out) at dri_context.c:146 #17 0x769b29b5 in driUnbindContext (pcp=0x8ef600) at ../../../../src/mesa/drivers/dri/common/drisw_util.c:199 #18 0x77dab4a5 in MakeContextCurrent (dpy=0x7b6a60, draw=50331670, read=50331670, gc_user=0xa6e180) at glxcurrent.c:255 #19 0x0052bb57 in GLEAN::WindowSystem::makeCurrent (this=0x7fffe0a8, r=..., w=...) at /home/nicholas/src/git/piglit/tests/glean/winsys.cpp:253 #20 0x0049cad0 in GLEAN::BaseTestGLEAN::BasicResult::run (this=0x7a1b80, environment=...) at /home/nicholas/src/git/piglit/tests/glean/tbase.h:308 #21 0x00492319 in main (argc=6, argv=0x7fffe2f8) at /home/nicholas/src/git/piglit/tests/glean/main.cpp:141 Fails with master (c5012c1), 7.11, 7.10, and 7.9. Mesa 7.8 didn't build, so I stopped there. -- 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 1/2] mesa: fix comments for RG formats
On 11/28/2011 12:24 PM, Eric Anholt wrote: On Mon, 28 Nov 2011 11:14:17 -0700, Brian Paulbri...@vmware.com wrote: The position of the red and green bits was misstated in the comments. Arguably, the names of these formats should be changed to GR to reflect the component ordering and to be consistent with other formats. Actually, could we get consistency in that naming? Or at least a comment for now here and in _mesa_format_matches_format_and_type(), where it's likely to get screwed up? I'm happy to rename the formats later but I'm going to push the fixed comment for the short term. Looking at _mesa_format_matches_format_and_type() for RG88: case MESA_FORMAT_RG88: return format == GL_LUMINANCE_ALPHA type == GL_UNSIGNED_BYTE littleEndian; I think that's wrong. Is GL_LUMINANCE_ALPHA somehow compatible with GL_RG? I think the code should read: case MESA_FORMAT_RG88: return format == GL_RG type == GL_UNSIGNED_BYTE littleEndian; -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/7] i965: Add support for Z16 depth formats.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/23/2011 12:37 PM, Eric Anholt wrote:
This is required by GL 3.0's Required Texture Formats section. All
the other code for this format in hardware was already in place.
---
src/mesa/drivers/dri/i965/brw_vtbl.c |3 ++-
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index dd2e05a..a3a8d09 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -215,7 +215,8 @@ static bool brw_is_hiz_depth_format(struct intel_context
*intel,
gl_format format)
{
/* In the future, this will support Z_FLOAT32. */
- return intel-has_hiz (format == MESA_FORMAT_X8_Z24);
+ return intel-has_hiz (format == MESA_FORMAT_X8_Z24 ||
+ format == MESA_FORMAT_Z16);
}
This will break applications that use a GLX visual with 16 depth bits because
the
horrid DRI2 handshake expects that only X8_Z24 buffers will have HiZ. That's a
bug
with the DRI2 handshake, however, and not this patch.
Yet another reason that piglit_init() needs to be restructured so that
differenct GLX
visuals can be used.
void brwInitVtbl( struct brw_context *brw )
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 0f6abe2..d51fdac 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -547,6 +547,7 @@ brw_init_surface_formats(struct brw_context *brw)
*/
ctx-TextureFormatSupported[MESA_FORMAT_S8_Z24] = true;
ctx-TextureFormatSupported[MESA_FORMAT_X8_Z24] = true;
+ ctx-TextureFormatSupported[MESA_FORMAT_Z16] = true;
}
bool
I grepped around, and it looks like this is really all that is needed.
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
-
Chad Versace
chad.vers...@linux.intel.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJO1A0uAAoJEAIvNt057x8iiBEQAI35TmIOA5NQ2i3sLud2CUCb
slqakA5GkBUfFEwgAhWIpDsYj26fg9V06lnPr62yz0ZmLnR4+BUHXHUQfewpT1iC
N+PbU8AaubXzTQAStev58wpF/Gjv9ixt2y7KpsZFkNudv+AXoiiRhHl4XkS+2lHB
UxZVo1XpHUA7qqUf/1h7R3acb33zA78+QD/2sPlo+/LHYEL2rdhL4589YBb3u3gh
08spnqx1jTHYGS4IOpJezTOlO7goWNuw3HXSvGCOIlO3iRgEdUPpp9YY5AFHKw8c
DEappAGkcWAJknbSgUHKH4bOicLwhJEsSe8Lylh7fvmwquwlrZ2+Apjqdoy4y89p
lsjQViAEziQzghDiInBgYdhOXvvj7uHnUyBxZpDid2iCLTWyRnxTKHplbqdiQu6C
ZQycUaqOJ21CMbAl4ePl6jWkXHqbhpJ/AmP/IWTyha2oEANyNrvgdPJSR3f7C0/D
rkp3lG3wyLOLNlmlXp/QWX2A+4F3qjoVjkCJGnaSerlEdmnI0Ug20E9VERLIHcLh
RM7S//SGm5/IFhNZxSyt6ChrRcu7jvU9Aj/tBP20RtvaVR1zTKr7MeYZMI8jTslh
MwVS5DdyGeuZK1TwFgWdpedbuLTQxr9KpjZvMrZFDbH4Qpq0092b7TMYL351IjKx
DyztsxbTC1AXJTyGqNYo
=1/UR
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43316] swrast/s_texfetch.c:1274: _mesa_get_texel_fetch_func: Assertion `texfetch_funcs[fmt].Name == fmt' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=43316 Brian Paul bri...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Brian Paul bri...@vmware.com 2011-11-28 14:42:21 PST --- Fixed w/ commit e32ada1b267c9cc84b84400a619cbca14aba2207 -- 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 6/7] i965: Add support for MESA_FORMAT_Z32_FLOAT and expose it under 3.0 override.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/23/2011 12:37 PM, Eric Anholt wrote:
The MESA_FORMAT_Z32_FLOAT_X24S8 support will come later, and involves
a bunch of trickery with hiz. Also, Z32_FLOAT will fail for swrast
paths until they change to MapRenderbuffer.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |5 +
src/mesa/drivers/dri/intel/intel_extensions.c|2 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index d51fdac..8cfd6db 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -541,6 +541,7 @@ brw_init_surface_formats(struct brw_context *brw)
brw-format_supported_as_render_target[MESA_FORMAT_X8_Z24] = true;
brw-format_supported_as_render_target[MESA_FORMAT_S8] = true;
brw-format_supported_as_render_target[MESA_FORMAT_Z16] = true;
+ brw-format_supported_as_render_target[MESA_FORMAT_Z32_FLOAT] = true;
/* We remap depth formats to a supported texturing format in
* translate_tex_format().
@@ -548,6 +549,7 @@ brw_init_surface_formats(struct brw_context *brw)
ctx-TextureFormatSupported[MESA_FORMAT_S8_Z24] = true;
ctx-TextureFormatSupported[MESA_FORMAT_X8_Z24] = true;
ctx-TextureFormatSupported[MESA_FORMAT_Z16] = true;
+ ctx-TextureFormatSupported[MESA_FORMAT_Z32_FLOAT] = true;
}
bool
@@ -575,6 +577,9 @@ translate_tex_format(gl_format mesa_format,
case MESA_FORMAT_X8_Z24:
return BRW_SURFACEFORMAT_I24X8_UNORM;
+ case MESA_FORMAT_Z32_FLOAT:
+ return BRW_SURFACEFORMAT_I32_FLOAT;
+
case MESA_FORMAT_SARGB8:
case MESA_FORMAT_SLA8:
case MESA_FORMAT_SL8:
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drivers/dri/intel/intel_extensions.c
index 681f5f2..2e2a31f 100644
--- a/src/mesa/drivers/dri/intel/intel_extensions.c
+++ b/src/mesa/drivers/dri/intel/intel_extensions.c
@@ -109,6 +109,8 @@ intelInitExtensions(struct gl_context *ctx)
if (intel-gen = 4) {
ctx-Extensions.ARB_color_buffer_float = true;
+ if (override_version = 30)
+ ctx-Extensions.ARB_depth_buffer_float = true;
ctx-Extensions.ARB_depth_clamp = true;
ctx-Extensions.ARB_fragment_coord_conventions = true;
ctx-Extensions.ARB_fragment_program_shadow = true;
I think you need to update intel_mesa_format_to_rb_datatype() too. intel_fbo.c
relies on that function.
-
Chad Versace
chad.vers...@linux.intel.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJO1BKfAAoJEAIvNt057x8iBr0QAIREa8PnO4jR9jLPrF45dS9l
FCvomRP2UYnxRRkkzwToEP8Pqh5/TxiH0U4JK1XHc8mf+A+SAcrAVynZ9RKwdRp4
r/+KsnZaeVdOAPdiFE9e9CvTTpqcqQL/KAhFGJtG+6FLYAKXQBKgw3Cesghi4Ezp
+OUXJhC+uZOjDxcVTcu97DBiC1IBlm2hNdtrJSqrc3HP5zEGHvWKd4ljtRdiHyss
JacJrCyMohA9R4nGrA+KbRVbZNBHMEK0fxZTOuvzXthEBTVEwpBqaQKVInlFu8zR
a3Se0zhnE7RwtasNrOuReTv8HWRfI3BlRxKXdWhdUgHCjHqtZJaIJeuPRhJ7xRqx
uzXyl+L8LnXNhV/7MIlfsHfCRLpfD1VxXADnUU8bx1AYJKPdS9C/2Pbv+TmfQ81H
fDlz3vTI+j3J9KF4TpV5a+hQScsnwYREoUQagwpcfqlp6qyNZOb8Q8BHX8wSIDmN
N4x+XuVWiV4sGCRzSB/s9Ci5arCV9vt08RlIHWYnsBB0M/pWjfDVn4u+xNhU7U23
yHJywmuD1Hexc9sNt6VypWsXDM+vYrW/hdvcj/lcL52gOpYzhtO01hDEOnFWVTq/
I90n0SP9DRlpfPESTu2tW5QJI8qTGMhpxFhWiYgxodeWHqbXoQXjhGWBEPRohXxn
jS0Gl9zyu2z0Ae6pyTBq
=t9ln
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/i965g: hide that utterly broken driver better
- Original Message - And warn loudly in case people want to use it. Too many tester report gpu hangs on irc and we rootcause this ... Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch If you're doing this then why not just remove the drive all together, as agreed a few days ago? Jose - Forwarded Message - From: Keith Whitwell kei...@vmware.com To: Kenneth Graunke kenn...@whitecape.org Cc: mesa-dev@lists.freedesktop.org Sent: Friday, November 18, 2011 10:57:17 PM Subject: Re: [Mesa-dev] [PATCH 4/6] gallium: remove PIPE_CAP_GLSL and enable GLSL unconditionally - Original Message - On 11/18/2011 11:27 AM, Marek Olšák wrote: Only i965g does not enable GLSL, but that driver has been unmaintained and bitrotting for quite a while anyway. It doesn't even do GLSL? I'm pretty shocked, I figured it at least did that. Is it even worth keeping around in the tree? Seems like it's just creating extra work for you guys, having to update it for Gallium changes...when ultimately, nobody's using it. I agree -- this was never finished isn't likely to be either. Keith ___ 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
Re: [Mesa-dev] [PATCH 1/3] i965: Don't double the depth width for separate-stencil-only rendering.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The code that this patch fixes is indeed correct, but not for the reason you believe. On 11/28/2011 10:48 AM, Eric Anholt wrote: This looks to have been confused with pitch setup, which does have to be doubled. It was intentional. The width is inherited by separate stencil, and it should naturally look like the setup in the block below involving a valid depthbuffer. I disagree. The setup in the block below is different because depth_irb-region-height is the depth buffer's height, but stencil_irb-region-height is not the stencil buffer's height. That's because of the hack we resort to when allocating stencil buffers. Many months ago, the hack looked like this: irb-region = intel_region_alloc(..., rb-Format, I915_TILING_Y cpp * 2, width, (height + 1) / 2); So, in the line ``((2 * region-height - 1) 19)``, I was attempting to adjust for the divide-by-2. (Yes, there is a potential off-by-one error here, but that's moot now). Currently, the hack looks like this, both throughout Mesa and in the DDX: irb-mt = intel_miptree_create_for_rendebuffer( intel, rb-Format, I915_TILING_NONE, cpp * 2, ALIGN(width, 64), ALIGN((height + 1) / 2, 64)); So, it is now impossible to determine the renderbuffer's height from stencil_irb-region-height. Instead, we should directly appeal to stencil_irb-Base.Height. --- src/mesa/drivers/dri/i965/brw_misc_state.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c b/src/mesa/drivers/dri/i965/brw_misc_state.c index cb1405c..f6a5ad6 100644 --- a/src/mesa/drivers/dri/i965/brw_misc_state.c +++ b/src/mesa/drivers/dri/i965/brw_misc_state.c @@ -298,7 +298,7 @@ static void emit_depthbuffer(struct brw_context *brw) (BRW_SURFACE_2D 29)); OUT_BATCH(0); OUT_BATCH(((region-width - 1) 6) | - (2 * region-height - 1) 19); + (region-height - 1) 19); OUT_BATCH(0); OUT_BATCH(0); I think this is the diff we want: - OUT_BATCH(((region-width - 1) 6) | - (2 * region-height - 1) 19); + OUT_BATCH(((stencil_irb-Base.Width - 1) 6) | + (stencil_irb-Base.Height - 1) 19); - Chad Versace chad.vers...@linux.intel.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO1B1dAAoJEAIvNt057x8iCucP/iltzSWigV6G7rO4Ngg55j+8 ZEWEG5uLAv77ULqGdScoDupX3SSARvDU+dsKGbg1jL8vBg3lxZcHJji8Jb46/5pe YnbKg/BSA4OQgt/GNBtYmjF+nFAipOqWxiQdaN8ytAGhraykOgJMTVx06Pw6+xZU V/PRlRbLef7ECZT9FvI+XThiVJnyPq+OGQhpO6rYxXzUlRnutsLH0c1dohvoqHFh qD6577KK0hHjVFK+duXg6Y1N5QPWlFi5PfqUbf8UcPBYv/tAHtYyfCghaDuqtN1w uNTdv0w/2dQkgWVpBrRtZQIwGDRxoH4YN7aQi1gW4plWI6FED1XHmP5DllLH/4lI W7foFGZb3raztYDjotTV/BstIcIXm1B0ASLv8ljjOjA17t0uZarZQKapLTNYMwd8 KUCtp2Sgr7EC7Teuck3tsaQLZxJinpkIWhqotajSNjWtdww5HG7Kdkc/zQDJORF8 Ri04nTZ94RMHOfGq3/+/9J/S5zFlCMbcDrFd9c7vCJ6bGrThHEEwe18HTXYJ/fOK KlgrgTgEcmPKN32ExSkbZQm++XDenQEtQTo4Z9Nj8lQC51vWbcsPphXq3BWW8orc ju/iTFmSRNXWDoL0W7PlL7pmfX2TuLTjZV0V4Ei/BUSQXt5oRx2n7VCExXQZvdOC H9sZeKNNiQxm9VvlZxPT =31Dx -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] i965: Don't depth test the fake depthbuffer when one isn't present.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2011 10:48 AM, Eric Anholt wrote: For the non-separate-stencil-only case, we've been using a NULL surface for depth, so we didn't have to care. However, to support separate stencil with no depthbuffer, we have to make the depth surface non-NULL or the stencil test always fails thanks to separate stencil inheriting the surface type of depth. Fixes hiz-depth-stencil-test-d0-s8. Reviewed-by: Chad Versace chad.vers...@linux.intel.com - Chad Versace chad.vers...@linux.intel.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO1B2cAAoJEAIvNt057x8ilpEQAJeR3Jwk3weVRkPbnZfrNGQE zfnqfMG7rcszK+GtR0KPUCXToNgHIcn8oxpirAoRvxjjP5soDptSiytGRhbA7BTc EJb1JIB3RcAIy9hA7UMYd6Q4zbmVsd/co307+eAH3a/4z/F0h9lyxav/9Pnj5Hwb VcL9vWLVDYaOI7q/Rz8NudzNQGQBSZ9xJUBIj6n9z/UO1/qIuuTLT9+pD0LYi1L7 raZlgVDqvtTrllZZl6cY5fx5IsEhRrhSavQhJaXQQiYZ7pDPw2924311gSnXcEjh hdkrJqmsxV4R/n1ph+e8vn2zv0Ug0Ph7WiCbiV6FeiZRwNh+bWR4svXykfBhwtdO 1vCea4ZbnMyG4zNyWB5qR5M+HgPQYGGw+4G18mlpAnGg1sOKj9V0y+CyY1R8GzQP QqS783A+oci26COnFrJjNeYQQ1+EbIhc5/mzEnyWBGsIDVDF1vKDYeRIt2rX4Yio /LIKPmMg5mVW2n1k6tfrKEGF7+l0q64gSnETBvtNTmZBA9IV2BkqEUUJQpcyhvSf LlFcv78zB+SjsK1qenSmtplzbOT6AQnoVCyIQQjEQyD07P1n8dyiBZr61JS3ebI0 z6YrnbPN0MxyAwynazp4jucFSRn9myIdrpMn0Jdg3pjtmY39SHnHVzTZiRpTfsQD vMBfXHh5csoUmw4lZAl7 =t5pX -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] reworking pipe_video_decoder / pipe_video_buffer
Maarten Lankhorst wrote: Sadly mplayer tells vdpau to have all videos decoded as progressive so I can't really do anything. :-( I just had a look at an old copy of h.262 spec I have. Unless I am misreading it seems that picture_structure = 3 (frame) is perfectly valid for interlaced. It just means the picture was coded as a weaved frame rather than totally separately as fields, with other values like like top_field_first and progressive_frame used to decide how to process. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43316] swrast/s_texfetch.c:1274: _mesa_get_texel_fetch_func: Assertion `texfetch_funcs[fmt].Name == fmt' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=43316 Vinson Lee v...@vmware.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #5 from Vinson Lee v...@vmware.com 2011-11-28 16:33:43 UTC --- mesa: 8f15c31338e4c0e105ddc602773682375395b00b (master) Verified fixed. -- 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] gallium/i965g: hide that utterly broken driver better
On Mon, Nov 28, 2011 at 03:17:09PM -0800, Jose Fonseca wrote: - Original Message - And warn loudly in case people want to use it. Too many tester report gpu hangs on irc and we rootcause this ... Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch If you're doing this then why not just remove the drive all together, as agreed a few days ago? I simply missed that discussion. I also don't have any experience with frobbing the mesa build system, so I'd surely miss something ... -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] mesa: add STATIC_ASSERT() macro for compile-time assertions
This can be used to check that tables have the right number of entries,
etc. at compile-time. This will hopefully catch things that are missed
if particular drivers aren't tested, for example.
---
src/mesa/main/compiler.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 921e302..96e24e4 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -310,6 +310,17 @@ static INLINE GLuint CPU_TO_LE32(GLuint x)
#endif
#endif
+
+/**
+ * Static (compile-time) assertion.
+ * Basically, use COND to dimension an array. If COND is false/zero the
+ * array size will be -1 and we'll get a compilation error.
+ */
+#define JOIN(x, y) x##y
+#define STATIC_ASSERT_LINE(COND, LINE) do { typedef int
JOIN(static_assertion_failed_at_line_,LINE)[(!!(COND))*2-1]; } while (0)
+#define STATIC_ASSERT(COND) STATIC_ASSERT_LINE(COND, __LINE__)
+
+
#if (__GNUC__ = 3)
#define PRINTFLIKE(f, a) __attribute__ ((format(__printf__, f, a)))
#else
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] swrast: use STATIC_ASSERT to make sure texfetch table isn't missing entries
When new MESA_FORMAT_x enums are added we need to add a new entry in
the table of texture fetch functions. In the past this has been
missed if swrast isn't actually tested. Using a static assertion
should help with that.
---
src/mesa/swrast/s_texfetch.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/swrast/s_texfetch.c b/src/mesa/swrast/s_texfetch.c
index bcd63b6..ab7cfb5 100644
--- a/src/mesa/swrast/s_texfetch.c
+++ b/src/mesa/swrast/s_texfetch.c
@@ -1282,7 +1282,8 @@ _mesa_get_texel_fetch_func(gl_format format, GLuint dims)
}
#endif
- assert(Elements(texfetch_funcs) == MESA_FORMAT_COUNT);
+ STATIC_ASSERT(Elements(texfetch_funcs) == MESA_FORMAT_COUNT);
+
assert(format MESA_FORMAT_COUNT);
switch (dims) {
--
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 1/3] glapi: s/INLINE/inline/ for dispatch.h file
Patch 2 in this series is the regenerated dispatch.h file. The
patch/email is 723KB so I'm omitting it.
-Brian
On 11/28/2011 06:16 PM, Brian Paul wrote:
---
src/mapi/glapi/gen/gl_table.py |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_table.py b/src/mapi/glapi/gen/gl_table.py
index 2cbbd97..f6182b6 100644
--- a/src/mapi/glapi/gen/gl_table.py
+++ b/src/mapi/glapi/gen/gl_table.py
@@ -179,11 +179,11 @@ class PrintRemapTable(gl_XML.gl_print_base):
print 'typedef %s (GLAPIENTRYP _glptr_%s)(%s);' %
(f.return_type, f.name, arg_string)
print '#define CALL_%s(disp, parameters) \\' % (f.name)
print '(* GET_%s(disp)) parameters' % (f.name)
- print 'static INLINE _glptr_%s GET_%s(struct
_glapi_table *disp) {' % (f.name, f.name)
+ print 'static inline _glptr_%s GET_%s(struct
_glapi_table *disp) {' % (f.name, f.name)
print ' return (_glptr_%s) (GET_by_offset(disp,
_gloffset_%s));' % (f.name, f.name)
print '}'
print
- print 'static INLINE void SET_%s(struct _glapi_table
*disp, %s (GLAPIENTRYP fn)(%s)) {' % (f.name, f.return_type, arg_string)
+ print 'static inline void SET_%s(struct _glapi_table
*disp, %s (GLAPIENTRYP fn)(%s)) {' % (f.name, f.return_type, arg_string)
print ' SET_by_offset(disp, _gloffset_%s, fn);' %
(f.name)
print '}'
print
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: fix comments for RG formats
On Mon, 28 Nov 2011 15:16:58 -0700, Brian Paul bri...@vmware.com wrote: On 11/28/2011 12:24 PM, Eric Anholt wrote: On Mon, 28 Nov 2011 11:14:17 -0700, Brian Paulbri...@vmware.com wrote: The position of the red and green bits was misstated in the comments. Arguably, the names of these formats should be changed to GR to reflect the component ordering and to be consistent with other formats. Actually, could we get consistency in that naming? Or at least a comment for now here and in _mesa_format_matches_format_and_type(), where it's likely to get screwed up? I'm happy to rename the formats later but I'm going to push the fixed comment for the short term. Looking at _mesa_format_matches_format_and_type() for RG88: case MESA_FORMAT_RG88: return format == GL_LUMINANCE_ALPHA type == GL_UNSIGNED_BYTE littleEndian; I think that's wrong. Is GL_LUMINANCE_ALPHA somehow compatible with GL_RG? I think the code should read: case MESA_FORMAT_RG88: return format == GL_RG type == GL_UNSIGNED_BYTE littleEndian; That's what I thought too when rereading it. Too much copy and paste From texstore.c I think. pgp3oQ9OkB6Q2.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 1/5] mesa: add STATIC_ASSERT() macro for compile-time assertions
On Mon, 28 Nov 2011 18:15:27 -0700, Brian Paul bri...@vmware.com wrote:
This can be used to check that tables have the right number of entries,
etc. at compile-time. This will hopefully catch things that are missed
if particular drivers aren't tested, for example.
I've always wanted to go dig up one of these and start using it. Thanks!
---
src/mesa/main/compiler.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 921e302..96e24e4 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -310,6 +310,17 @@ static INLINE GLuint CPU_TO_LE32(GLuint x)
#endif
#endif
+
+/**
+ * Static (compile-time) assertion.
+ * Basically, use COND to dimension an array. If COND is false/zero the
+ * array size will be -1 and we'll get a compilation error.
+ */
+#define JOIN(x, y) x##y
+#define STATIC_ASSERT_LINE(COND, LINE) do { typedef int
JOIN(static_assertion_failed_at_line_,LINE)[(!!(COND))*2-1]; } while (0)
+#define STATIC_ASSERT(COND) STATIC_ASSERT_LINE(COND, __LINE__)
Looks like STATIC_ASSERT_LINE could get linewrapped, right?
pgpxm9BhqeHoX.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 1/3] i965: Don't double the depth width for separate-stencil-only rendering.
On Mon, 28 Nov 2011 15:46:38 -0800, Chad Versace chad.vers...@linux.intel.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The code that this patch fixes is indeed correct, but not for the reason you believe. On 11/28/2011 10:48 AM, Eric Anholt wrote: This looks to have been confused with pitch setup, which does have to be doubled. It was intentional. The width is inherited by separate stencil, and it should naturally look like the setup in the block below involving a valid depthbuffer. I disagree. The setup in the block below is different because depth_irb-region-height is the depth buffer's height, but stencil_irb-region-height is not the stencil buffer's height. That's because of the hack we resort to when allocating stencil buffers. Tricky. I just stumbled over this half an hour ago in the mapping cleanup I'm doing, too, and had concluded that rb-Height was the thing I wanted to use there. I like your proposed hunk. pgp9o6bIIAGTE.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XCB-only GLX protocol?
On Sun, 27 Nov 2011 18:13:45 -0800, Ian Romanick i...@freedesktop.org wrote: All, I'm starting to work on GLX_ARB_create_context. This extension and the layered GLX_ARB_create_context_profile extension add some GLX protocol. Is there any reason to keep supporting non-XCB protocol? Are there any platforms that can't / don't use XCB for X protocol? I'm not planning to gut any non-XCB code yet, but that would happen eventually. I just don't want to implement all of the protocol twice. That seems like an unnecessary hassle. Opinions? I'd much prefer to see XCB only for new protocol. pgpkGIo9HMwO7.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XCB-only GLX protocol?
On Mon, Nov 28, 2011 at 3:13 AM, Ian Romanick i...@freedesktop.org wrote: All, I'm starting to work on GLX_ARB_create_context. This extension and the layered GLX_ARB_create_context_profile extension add some GLX protocol. Is there any reason to keep supporting non-XCB protocol? Are there any platforms that can't / don't use XCB for X protocol? I'm not planning to gut any non-XCB code yet, but that would happen eventually. I just don't want to implement all of the protocol twice. That seems like an unnecessary hassle. Opinions? No problems with me but I think you should get sign-off from various platform stakeholders before doing it (BSD, Mac, Cygwin). Jeremy and who does cygwin? Cheers, Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XCB-only GLX protocol?
On 11/28/11 18:56, Jakob Bornecrantz wrote: On Mon, Nov 28, 2011 at 3:13 AM, Ian Romanicki...@freedesktop.org wrote: All, I'm starting to work on GLX_ARB_create_context. This extension and the layered GLX_ARB_create_context_profile extension add some GLX protocol. Is there any reason to keep supporting non-XCB protocol? Are there any platforms that can't / don't use XCB for X protocol? I'm not planning to gut any non-XCB code yet, but that would happen eventually. I just don't want to implement all of the protocol twice. That seems like an unnecessary hassle. Opinions? No problems with me but I think you should get sign-off from various platform stakeholders before doing it (BSD, Mac, Cygwin). Jeremy and who does cygwin? From the Solaris platform point of view, XCB is fine with me, as we have xcb 1.6 on Solaris 11, and no longer update the Mesa version in Solaris 10 (which has no XCB included - those who want to build new versions themselves should be able to build xcb for Solaris 10 as well). Most applications still use libX11, but since we ship the libX11 1.4.x built on top of libxcb, the standard xcb/xlib handoff calls should work just fine. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] mesa: add STATIC_ASSERT() macro for compile-time assertions
On Mon, Nov 28, 2011 at 7:06 PM, Eric Anholt e...@anholt.net wrote:
On Mon, 28 Nov 2011 18:15:27 -0700, Brian Paul bri...@vmware.com wrote:
This can be used to check that tables have the right number of entries,
etc. at compile-time. This will hopefully catch things that are missed
if particular drivers aren't tested, for example.
I've always wanted to go dig up one of these and start using it. Thanks!
---
src/mesa/main/compiler.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 921e302..96e24e4 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -310,6 +310,17 @@ static INLINE GLuint CPU_TO_LE32(GLuint x)
#endif
#endif
+
+/**
+ * Static (compile-time) assertion.
+ * Basically, use COND to dimension an array. If COND is false/zero the
+ * array size will be -1 and we'll get a compilation error.
+ */
+#define JOIN(x, y) x##y
+#define STATIC_ASSERT_LINE(COND, LINE) do { typedef int
JOIN(static_assertion_failed_at_line_,LINE)[(!!(COND))*2-1]; } while (0)
+#define STATIC_ASSERT(COND) STATIC_ASSERT_LINE(COND, __LINE__)
Looks like STATIC_ASSERT_LINE could get linewrapped, right?
Yeah, and I'm going to simplify this in general. There's really no
need for the line number stuff since the compiler will already emit
that and since the typedef is inside a do/while block we don't need to
have a unique array name for every instance. I'll post a new patch.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: add STATIC_ASSERT() macro for compile-time assertions
This can be used to check that tables have the right number of entries,
etc. at compile-time. This will hopefully catch things that are missed
if particular drivers aren't tested, for example.
v2: Simplify the macro to omit the extra line number info (the compiler
already indicates the line number). And wrap the macro for readability.
---
src/mesa/main/compiler.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 921e302..25d9810 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -310,6 +310,18 @@ static INLINE GLuint CPU_TO_LE32(GLuint x)
#endif
#endif
+
+/**
+ * Static (compile-time) assertion.
+ * Basically, use COND to dimension an array. If COND is false/zero the
+ * array size will be -1 and we'll get a compilation error.
+ */
+#define STATIC_ASSERT(COND) \
+ do { \
+ typedef int static_assertion_failed[(!!(COND))*2-1]; \
+ } while (0)
+
+
#if (__GNUC__ = 3)
#define PRINTFLIKE(f, a) __attribute__ ((format(__printf__, f, a)))
#else
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Make gen6_resolve_implied_move a no-op for MRF sources.
Attempting to move an MRF to a MRF is not only pointless, it will fail
because MRFs are read-only, resulting in garbage in your register.
If we already set up a MRF source, there's nothing to resolve anyway.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_eu_emit.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
I could've sworn I sent this out a week and a half ago, but I don't remember
getting any responses and can't seem to find it in my mail archive. Oops.
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 60350ca..9d8c701 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -67,6 +67,9 @@ gen6_resolve_implied_move(struct brw_compile *p,
if (intel-gen 6)
return;
+ if (src-file == BRW_MESSAGE_REGISTER_FILE)
+ return;
+
if (src-file != BRW_ARCHITECTURE_REGISTER_FILE || src-nr != BRW_ARF_NULL)
{
brw_push_insn_state(p);
brw_set_mask_control(p, BRW_MASK_DISABLE);
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XCB-only GLX protocol?
On Nov 28, 2011, at 6:56 PM, Jakob Bornecrantz wrote: On Mon, Nov 28, 2011 at 3:13 AM, Ian Romanick i...@freedesktop.org wrote: All, I'm starting to work on GLX_ARB_create_context. This extension and the layered GLX_ARB_create_context_profile extension add some GLX protocol. Is there any reason to keep supporting non-XCB protocol? Are there any platforms that can't / don't use XCB for X protocol? I'm not planning to gut any non-XCB code yet, but that would happen eventually. I just don't want to implement all of the protocol twice. That seems like an unnecessary hassle. Opinions? No problems with me but I think you should get sign-off from various platform stakeholders before doing it (BSD, Mac, Cygwin). Jeremy and who does cygwin? XQuartz transitioned to XCB a few releases ago, and we're fully committed to it. I bless any Xlib code that you want to nuke in the transition to XCB!! We may have some difficulty in the src/glx/apple code since AppleDRI and AppleWM are Xlib-only. I'm hoping to eventually move away from these protocols, and I'll just deal with the fallout as it happens. Please CC me on reviews with a branch I can merge to test the changes before they are merged into master. Thanks ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] mesa: Use VERT_ATTRIB_* indexed array in gl_array_object.
Hi, On Sunday, November 27, 2011 22:52:29 Eric Anholt wrote: Not an issue for this patch, but I noticed that there's this _mesa_update_array_object_max_element that does something similar, but doesn't follow this rule and would trash the _MaxElement value. Some day, the body of this function should probably be moved to that one, and state.c should call it. It's also a bit disturbing that the code for which array to look at based on program state is duplicated between vbo and here. Thanks, agreed. There is really a huge pile of cleanup possible in this area. I had included some of the 'easy cleanups' in the v1 series but it turned out that there is some surprising clause in one of the extension specs that I just missed. So for now I resorted to the bare minimum to get the array change in. Then start thinking about cleanups enabled with this change. Other than the one patch with comments, the series overall looks like a great clenaup and is: Reviewed-by: Eric Anholt e...@anholt.net Thanks for looking into this! Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
