[Mesa-dev] [PATCH] gallium: specify resource_resolve destination via a pipe_surface
The format member of pipe_surface may differ from that of the
pipe_resource, which is used to communicate, for instance, whether
sRGB encode should be enabled in the resolve operation or not.
Fixes resolve to sRGB surfaces in mesa/st when GL_FRAMEBUFFER_SRGB
is disabled.
---
src/gallium/drivers/nv30/nv30_miptree.c |5 +++-
src/gallium/drivers/nv50/nv50_surface.c | 32 --
src/gallium/drivers/nvc0/nvc0_surface.c | 32 --
src/gallium/drivers/r300/r300_render.c |7 +-
src/gallium/include/pipe/p_state.h |6 +---
src/mesa/state_tracker/st_cb_blit.c | 15 +
6 files changed, 39 insertions(+), 58 deletions(-)
diff --git a/src/gallium/drivers/nv30/nv30_miptree.c
b/src/gallium/drivers/nv30/nv30_miptree.c
index 7e67729..cd6a814 100644
--- a/src/gallium/drivers/nv30/nv30_miptree.c
+++ b/src/gallium/drivers/nv30/nv30_miptree.c
@@ -153,7 +153,10 @@ nv30_resource_resolve(struct pipe_context *pipe,
define_rect(info-src.res, 0, 0, info-src.x0, info-src.y0,
info-src.x1 - info-src.x0, info-src.y1 - info-src.y0, src);
- define_rect(info-dst.res, info-dst.level, 0, info-dst.x0, info-dst.y0,
+ define_rect(info-dst.surface-texture,
+ info-dst.surface-u.tex.level,
+ info-dst.surface-u.tex.first_layer,
+ info-dst.x0, info-dst.y0,
info-dst.x1 - info-dst.x0, info-dst.y1 - info-dst.y0, dst);
nv30_transfer_rect(nv30, BILINEAR, src, dst);
diff --git a/src/gallium/drivers/nv50/nv50_surface.c
b/src/gallium/drivers/nv50/nv50_surface.c
index 0872f8d..ed5223b 100644
--- a/src/gallium/drivers/nv50/nv50_surface.c
+++ b/src/gallium/drivers/nv50/nv50_surface.c
@@ -436,6 +436,7 @@ struct nv50_blitctx
unsigned num_samplers[3];
struct pipe_sampler_view *texture[2];
struct nv50_tsc_entry *sampler[2];
+ enum pipe_format format;
unsigned dirty;
} saved;
struct nv50_program vp;
@@ -661,26 +662,19 @@ nv50_blitctx_get_color_mask_and_fp(struct nv50_blitctx
*blit,
}
static void
-nv50_blit_set_dst(struct nv50_context *nv50,
- struct pipe_resource *res, unsigned level, unsigned layer)
+nv50_blit_set_dst(struct nv50_context *nv50, struct pipe_surface *surf,
+ struct nv50_blitctx *blit)
{
- struct pipe_context *pipe = nv50-base.pipe;
- struct pipe_surface templ;
+ blit-saved.format = surf-format;
- if (util_format_is_depth_or_stencil(res-format))
- templ.format = nv50_blit_zeta_to_colour_format(res-format);
- else
- templ.format = res-format;
-
- templ.usage = PIPE_USAGE_STREAM;
- templ.u.tex.level = level;
- templ.u.tex.first_layer = templ.u.tex.last_layer = layer;
+ if (util_format_is_depth_or_stencil(surf-format))
+ surf-format = nv50_blit_zeta_to_colour_format(surf-format);
- nv50-framebuffer.cbufs[0] = nv50_miptree_surface_new(pipe, res, templ);
+ nv50-framebuffer.cbufs[0] = surf;
nv50-framebuffer.nr_cbufs = 1;
nv50-framebuffer.zsbuf = NULL;
- nv50-framebuffer.width = nv50-framebuffer.cbufs[0]-width;
- nv50-framebuffer.height = nv50-framebuffer.cbufs[0]-height;
+ nv50-framebuffer.width = surf-width;
+ nv50-framebuffer.height = surf-height;
}
static INLINE void
@@ -822,7 +816,7 @@ nv50_blitctx_post_blit(struct nv50_context *nv50, struct
nv50_blitctx *blit)
{
int s;
- pipe_surface_reference(nv50-framebuffer.cbufs[0], NULL);
+ nv50-framebuffer.cbufs[0]-format = blit-saved.format;
nv50-framebuffer.width = blit-saved.fb.width;
nv50-framebuffer.height = blit-saved.fb.height;
@@ -862,7 +856,7 @@ nv50_resource_resolve(struct pipe_context *pipe,
struct nv50_blitctx *blit = screen-blitctx;
struct nouveau_pushbuf *push = nv50-base.pushbuf;
struct pipe_resource *src = info-src.res;
- struct pipe_resource *dst = info-dst.res;
+ struct pipe_resource *dst = info-dst.surface-texture;
float x0, x1, y0, y1, z;
float x_range, y_range;
@@ -872,8 +866,8 @@ nv50_resource_resolve(struct pipe_context *pipe,
nv50_blitctx_pre_blit(blit, nv50);
- nv50_blit_set_dst(nv50, dst, info-dst.level, info-dst.layer);
- nv50_blit_set_src(nv50, src, 0, info-src.layer);
+ nv50_blit_set_dst(nv50, info-dst.surface, blit);
+ nv50_blit_set_src(nv50, src, 0, info-src.layer);
nv50_blitctx_prepare_state(blit);
diff --git a/src/gallium/drivers/nvc0/nvc0_surface.c
b/src/gallium/drivers/nvc0/nvc0_surface.c
index 607b02e..6773f96 100644
--- a/src/gallium/drivers/nvc0/nvc0_surface.c
+++ b/src/gallium/drivers/nvc0/nvc0_surface.c
@@ -457,6 +457,7 @@ struct nvc0_blitctx
unsigned num_samplers[5];
struct pipe_sampler_view *texture[2];
struct nv50_tsc_entry *sampler[2];
+ enum pipe_format format;
unsigned dirty;
} saved;
struct nvc0_program vp;
@@ -727,26 +728,19 @@ nvc0_blitctx_get_color_mask_and_fp(struct nvc0_blitctx
*blit,
}
static void
[Mesa-dev] [PATCH] mesa: loosen small matrix determinant check
When computing a matrix inverse, if the determinant is too small we could hit a divide by zero. There's a check to prevent this (we basically give up on computing the inverse and return the identity matrix.) This patch loosens this test to fix a lighting bug reported by Lars Henning Wendt. v2: use abs(det) to handle negative values NOTE: This is a candidate for the 8.0 branch. --- src/mesa/math/m_matrix.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c index 02aedba..ffbdcdb 100644 --- a/src/mesa/math/m_matrix.c +++ b/src/mesa/math/m_matrix.c @@ -513,7 +513,7 @@ static GLboolean invert_matrix_3d_general( GLmatrix *mat ) det = pos + neg; - if (det*det 1e-25) + if (FABSF(det) 1e-25) return GL_FALSE; det = 1.0F / det; -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: remove _math_matrix_alloc_inv()
Always allocate space for the inverse matrix in _math_matrix_ctr()
since we were always calling _math_matrix_alloc_inv() anyway.
---
src/mesa/main/matrix.c|4 +--
src/mesa/math/m_matrix.c | 51 -
src/mesa/math/m_matrix.h |5 +---
src/mesa/program/prog_statevars.c |1 -
4 files changed, 13 insertions(+), 48 deletions(-)
diff --git a/src/mesa/main/matrix.c b/src/mesa/main/matrix.c
index f479a22..b09fa4d 100644
--- a/src/mesa/main/matrix.c
+++ b/src/mesa/main/matrix.c
@@ -658,8 +658,7 @@ void _mesa_update_modelview_project( struct gl_context
*ctx, GLuint new_state )
* \param dirtyFlag dirty flag.
*
* Allocates an array of \p maxDepth elements for the matrix stack and calls
- * _math_matrix_ctr() and _math_matrix_alloc_inv() for each element to
- * initialize it.
+ * _math_matrix_ctr() for each element to initialize it.
*/
static void
init_matrix_stack( struct gl_matrix_stack *stack,
@@ -674,7 +673,6 @@ init_matrix_stack( struct gl_matrix_stack *stack,
stack-Stack = (GLmatrix *) CALLOC(maxDepth * sizeof(GLmatrix));
for (i = 0; i maxDepth; i++) {
_math_matrix_ctr(stack-Stack[i]);
- _math_matrix_alloc_inv(stack-Stack[i]);
}
stack-Top = stack-Stack;
}
diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
index ffbdcdb..58a691c 100644
--- a/src/mesa/math/m_matrix.c
+++ b/src/mesa/math/m_matrix.c
@@ -296,19 +296,15 @@ static void print_matrix_floats( const GLfloat m[16] )
void
_math_matrix_print( const GLmatrix *m )
{
+ GLfloat prod[16];
+
_mesa_debug(NULL, Matrix type: %s, flags: %x\n, types[m-type], m-flags);
print_matrix_floats(m-m);
_mesa_debug(NULL, Inverse: \n);
- if (m-inv) {
- GLfloat prod[16];
- print_matrix_floats(m-inv);
- matmul4(prod, m-m, m-inv);
- _mesa_debug(NULL, Mat * Inverse:\n);
- print_matrix_floats(prod);
- }
- else {
- _mesa_debug(NULL, - not available\n);
- }
+ print_matrix_floats(m-inv);
+ matmul4(prod, m-m, m-inv);
+ _mesa_debug(NULL, Mat * Inverse:\n);
+ print_matrix_floats(prod);
}
/*@}*/
@@ -1141,9 +1137,7 @@ void
_math_matrix_set_identity( GLmatrix *mat )
{
memcpy( mat-m, Identity, 16*sizeof(GLfloat) );
-
- if (mat-inv)
- memcpy( mat-inv, Identity, 16*sizeof(GLfloat) );
+ memcpy( mat-inv, Identity, 16*sizeof(GLfloat) );
mat-type = MATRIX_IDENTITY;
mat-flags = ~(MAT_DIRTY_FLAGS|
@@ -1444,17 +1438,9 @@ void
_math_matrix_copy( GLmatrix *to, const GLmatrix *from )
{
memcpy( to-m, from-m, sizeof(Identity) );
+ memcpy(to-inv, from-inv, sizeof(from-inv));
to-flags = from-flags;
to-type = from-type;
-
- if (to-inv != 0) {
- if (from-inv == 0) {
-matrix_invert( to );
- }
- else {
-memcpy(to-inv, from-inv, sizeof(GLfloat)*16);
- }
- }
}
/**
@@ -1486,7 +1472,9 @@ _math_matrix_ctr( GLmatrix *m )
m-m = (GLfloat *) _mesa_align_malloc( 16 * sizeof(GLfloat), 16 );
if (m-m)
memcpy( m-m, Identity, sizeof(Identity) );
- m-inv = NULL;
+ m-inv = (GLfloat *) _mesa_align_malloc( 16 * sizeof(GLfloat), 16 );
+ if (m-inv)
+ memcpy( m-inv, Identity, sizeof(Identity) );
m-type = MATRIX_IDENTITY;
m-flags = 0;
}
@@ -1511,23 +1499,6 @@ _math_matrix_dtr( GLmatrix *m )
}
}
-/**
- * Allocate a matrix inverse.
- *
- * \param m matrix.
- *
- * Allocates the matrix inverse, GLmatrix::inv, and sets it to Identity.
- */
-void
-_math_matrix_alloc_inv( GLmatrix *m )
-{
- if (!m-inv) {
- m-inv = (GLfloat *) _mesa_align_malloc( 16 * sizeof(GLfloat), 16 );
- if (m-inv)
- memcpy( m-inv, Identity, 16 * sizeof(GLfloat) );
- }
-}
-
/*@}*/
diff --git a/src/mesa/math/m_matrix.h b/src/mesa/math/m_matrix.h
index e8e48aa..9f4ea25 100644
--- a/src/mesa/math/m_matrix.h
+++ b/src/mesa/math/m_matrix.h
@@ -74,7 +74,7 @@ enum GLmatrixtype {
*/
typedef struct {
GLfloat *m; /** 16 matrix elements (16-byte aligned) */
- GLfloat *inv; /** optional 16-element inverse (16-byte aligned) */
+ GLfloat *inv; /** 16-element inverse (16-byte aligned) */
GLuint flags;/** possible values determined by (of \link
* MatFlags MAT_FLAG_* flags\endlink)
*/
@@ -91,9 +91,6 @@ extern void
_math_matrix_dtr( GLmatrix *m );
extern void
-_math_matrix_alloc_inv( GLmatrix *m );
-
-extern void
_math_matrix_mul_matrix( GLmatrix *dest, const GLmatrix *a, const GLmatrix *b
);
extern void
diff --git a/src/mesa/program/prog_statevars.c
b/src/mesa/program/prog_statevars.c
index 98ab9d0..2517908 100644
--- a/src/mesa/program/prog_statevars.c
+++ b/src/mesa/program/prog_statevars.c
@@ -322,7 +322,6 @@ _mesa_fetch_state(struct gl_context *ctx, const
gl_state_index state[],
modifier == STATE_MATRIX_INVTRANS) {
/* Be sure inverse is up to date:
*/
-_math_matrix_alloc_inv(
[Mesa-dev] [Bug 52369] [softpipe] piglit mipmap-setup regression
https://bugs.freedesktop.org/show_bug.cgi?id=52369 Brian Paul brian.e.p...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Brian Paul brian.e.p...@gmail.com 2012-07-25 13:48:12 PDT --- Fixed with commit fa76d04aeaf249956072c023661b1e2cda103584 -- 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 47375] Blender crash on startup after upgrade to mesa 8.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=47375 --- Comment #13 from Brian Paul brian.e.p...@gmail.com 2012-07-25 13:53:09 PDT --- Sorry, I misread your update too quickly and thought that you had added some assertions. I think we still need to get to the root cause of those before trying to diagnose performance problems. The unexpected type in get_row() error is probably related to the failed assertion and will hopefully be fixed when the first problem is fixed. Unfortunately, I can't reproduce this here. I have blender 2.63a and tested it with swrast. I forced Mesa to take the _mesa_meta_DrawPixels() path but it's not calling _swrast_DrawPixels(). The 'fallback' variable is false while it seems to be true for you. Maybe you could find out why 'fallback' is getting set. I also tried forcing fallback=1 so that _swrast_DrawPixels() gets called but I didn't see any failed assertions. I'm using the Mesa 8.0.x branch. I don't have a r200 gpu to try that driver. -- 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] scons: Fix build with clang.
On 07/25/2012 12:06 AM, Vinson Lee wrote:
Signed-off-by: Vinson Leev...@freedesktop.org
---
scons/gallium.py |3 ++-
src/gallium/winsys/svga/drm/SConscript |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/scons/gallium.py b/scons/gallium.py
index 001a5de..458651b 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -140,6 +140,7 @@ def generate(env):
env['gcc'] = 'gcc' in os.path.basename(env['CC']).split('-')
env['msvc'] = env['CC'] == 'cl'
env['suncc'] = env['platform'] == 'sunos' and os.path.basename(env['CC'])
== 'cc'
+env['clang'] = env['CC'] == 'clang'
if env['msvc'] and env['toolchain'] == 'default' and env['machine'] ==
'x86_64':
# MSVC x64 support is broken in earlier versions of scons
@@ -482,7 +483,7 @@ def generate(env):
env.Append(SHLINKFLAGS = shlinkflags)
# We have C++ in several libraries, so always link with the C++ compiler
-if env['gcc']:
+if env['gcc'] or env['clang']:
env['LINK'] = env['CXX']
# Default libs
diff --git a/src/gallium/winsys/svga/drm/SConscript
b/src/gallium/winsys/svga/drm/SConscript
index ee782c8..2d511d2 100644
--- a/src/gallium/winsys/svga/drm/SConscript
+++ b/src/gallium/winsys/svga/drm/SConscript
@@ -4,7 +4,7 @@ env = env.Clone()
env.PkgUseModules('DRM')
-if env['gcc']:
+if env['gcc'] or env['clang']:
env.Append(CCFLAGS = ['-fvisibility=hidden'])
env.Append(CPPDEFINES = [
'HAVE_STDINT_H',
Looks OK to 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
Re: [Mesa-dev] Check the compilation problems in mesa-user
On 07/23/2012 07:06 PM, Juhana Sadeharju wrote: Hello. Would you please check the compilation problem posted at mesa-user? Could you repost the issue here where more developers can see it? Several days passed and no software renderer. I rather would like to test the llvmpipe than fix the compiler... What is the status with OSMesa and llvmpipe? OSMesa only works with the legacy swrast driver, not llvmpipe. One thing on my to-do list is to write a gallium state tracker to implement OSMesa for gallium drivers. But I don't know when I'll get to that. How to compile Mesa so that gtkglext can be used with llvmpipe? What other choises than gtkglext? Is gtkglext up-to-date? I used it previously with Mesa 5.0 or the like. I suspect that gtkglext uses the GLX interface so if you compile llvmpipe normally you'll get a libGL.so with the GLX interface and llvmpipe (and softpipe) driver(s). It should work fine. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: specify resource_resolve destination via a pipe_surface
On 07/25/2012 05:54 AM, Christoph Bumiller wrote:
The format member of pipe_surface may differ from that of the
pipe_resource, which is used to communicate, for instance, whether
sRGB encode should be enabled in the resolve operation or not.
Fixes resolve to sRGB surfaces in mesa/st when GL_FRAMEBUFFER_SRGB
is disabled.
---
src/gallium/drivers/nv30/nv30_miptree.c |5 +++-
src/gallium/drivers/nv50/nv50_surface.c | 32 --
src/gallium/drivers/nvc0/nvc0_surface.c | 32 --
src/gallium/drivers/r300/r300_render.c |7 +-
src/gallium/include/pipe/p_state.h |6 +---
src/mesa/state_tracker/st_cb_blit.c | 15 +
6 files changed, 39 insertions(+), 58 deletions(-)
diff --git a/src/gallium/drivers/nv30/nv30_miptree.c
b/src/gallium/drivers/nv30/nv30_miptree.c
index 7e67729..cd6a814 100644
--- a/src/gallium/drivers/nv30/nv30_miptree.c
+++ b/src/gallium/drivers/nv30/nv30_miptree.c
@@ -153,7 +153,10 @@ nv30_resource_resolve(struct pipe_context *pipe,
define_rect(info-src.res, 0, 0, info-src.x0, info-src.y0,
info-src.x1 - info-src.x0, info-src.y1 - info-src.y0,src);
- define_rect(info-dst.res, info-dst.level, 0, info-dst.x0, info-dst.y0,
+ define_rect(info-dst.surface-texture,
+ info-dst.surface-u.tex.level,
+ info-dst.surface-u.tex.first_layer,
+ info-dst.x0, info-dst.y0,
info-dst.x1 - info-dst.x0, info-dst.y1 - info-dst.y0,dst);
nv30_transfer_rect(nv30, BILINEAR,src,dst);
diff --git a/src/gallium/drivers/nv50/nv50_surface.c
b/src/gallium/drivers/nv50/nv50_surface.c
index 0872f8d..ed5223b 100644
--- a/src/gallium/drivers/nv50/nv50_surface.c
+++ b/src/gallium/drivers/nv50/nv50_surface.c
@@ -436,6 +436,7 @@ struct nv50_blitctx
unsigned num_samplers[3];
struct pipe_sampler_view *texture[2];
struct nv50_tsc_entry *sampler[2];
+ enum pipe_format format;
unsigned dirty;
} saved;
struct nv50_program vp;
@@ -661,26 +662,19 @@ nv50_blitctx_get_color_mask_and_fp(struct nv50_blitctx
*blit,
}
static void
-nv50_blit_set_dst(struct nv50_context *nv50,
- struct pipe_resource *res, unsigned level, unsigned layer)
+nv50_blit_set_dst(struct nv50_context *nv50, struct pipe_surface *surf,
+ struct nv50_blitctx *blit)
{
- struct pipe_context *pipe =nv50-base.pipe;
- struct pipe_surface templ;
+ blit-saved.format = surf-format;
- if (util_format_is_depth_or_stencil(res-format))
- templ.format = nv50_blit_zeta_to_colour_format(res-format);
- else
- templ.format = res-format;
-
- templ.usage = PIPE_USAGE_STREAM;
- templ.u.tex.level = level;
- templ.u.tex.first_layer = templ.u.tex.last_layer = layer;
+ if (util_format_is_depth_or_stencil(surf-format))
+ surf-format = nv50_blit_zeta_to_colour_format(surf-format);
- nv50-framebuffer.cbufs[0] = nv50_miptree_surface_new(pipe, res,templ);
+ nv50-framebuffer.cbufs[0] = surf;
nv50-framebuffer.nr_cbufs = 1;
nv50-framebuffer.zsbuf = NULL;
- nv50-framebuffer.width = nv50-framebuffer.cbufs[0]-width;
- nv50-framebuffer.height = nv50-framebuffer.cbufs[0]-height;
+ nv50-framebuffer.width = surf-width;
+ nv50-framebuffer.height = surf-height;
}
static INLINE void
@@ -822,7 +816,7 @@ nv50_blitctx_post_blit(struct nv50_context *nv50, struct
nv50_blitctx *blit)
{
int s;
- pipe_surface_reference(nv50-framebuffer.cbufs[0], NULL);
+ nv50-framebuffer.cbufs[0]-format = blit-saved.format;
nv50-framebuffer.width = blit-saved.fb.width;
nv50-framebuffer.height = blit-saved.fb.height;
@@ -862,7 +856,7 @@ nv50_resource_resolve(struct pipe_context *pipe,
struct nv50_blitctx *blit = screen-blitctx;
struct nouveau_pushbuf *push = nv50-base.pushbuf;
struct pipe_resource *src = info-src.res;
- struct pipe_resource *dst = info-dst.res;
+ struct pipe_resource *dst = info-dst.surface-texture;
float x0, x1, y0, y1, z;
float x_range, y_range;
@@ -872,8 +866,8 @@ nv50_resource_resolve(struct pipe_context *pipe,
nv50_blitctx_pre_blit(blit, nv50);
- nv50_blit_set_dst(nv50, dst, info-dst.level, info-dst.layer);
- nv50_blit_set_src(nv50, src, 0, info-src.layer);
+ nv50_blit_set_dst(nv50, info-dst.surface, blit);
+ nv50_blit_set_src(nv50, src, 0, info-src.layer);
nv50_blitctx_prepare_state(blit);
diff --git a/src/gallium/drivers/nvc0/nvc0_surface.c
b/src/gallium/drivers/nvc0/nvc0_surface.c
index 607b02e..6773f96 100644
--- a/src/gallium/drivers/nvc0/nvc0_surface.c
+++ b/src/gallium/drivers/nvc0/nvc0_surface.c
@@ -457,6 +457,7 @@ struct nvc0_blitctx
unsigned num_samplers[5];
struct pipe_sampler_view *texture[2];
struct nv50_tsc_entry *sampler[2];
+ enum pipe_format format;
unsigned dirty;
} saved;
struct nvc0_program vp;
@@ -727,26 +728,19 @@
[Mesa-dev] [Bug 52282] [softpipe] piglit arb_shader_texture_lod-texgrad regression
https://bugs.freedesktop.org/show_bug.cgi?id=52282 Brian Paul brian.e.p...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Brian Paul brian.e.p...@gmail.com 2012-07-25 14:03:29 PDT --- This was also fixed by commit fa76d04aeaf249956072c023661b1e2cda103584. -- 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 4/4] i965: Use sendc for all render target writes on Gen6+.
The sendc instruction causes the fragment shader thread to wait for
any dependent threads (i.e. threads rendering to overlapping pixels)
to complete before sending the message. We need to use sendc on the
first render target write in order to guarantee that fragment shader
outputs are written to the render target in the correct order.
Previously, we only used the sendc instruction when writing to
binding table index 0. This did the right thing for fragment shaders,
because our fragment shader back-ends always issue their first render
target write to binding table index 0. However, it did the wrong
thing for blorp, which performs its render target writes to binding
table index 1.
A more robust solution is to use sendc for all render target writes.
This should not produce any performance penalty, since after the first
sendc, all of the dependent threads will have completed.
For more information about sendc, see the Ivy Bridge PRM, Vol4 Part3
p218 (sendc - Conditional Send Message), and p54 (TDR Registers).
---
src/mesa/drivers/dri/i965/brw_eu_emit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 93e84ae..25bf91b 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -2259,7 +2259,7 @@ void brw_fb_WRITE(struct brw_compile *p,
else
dest = retype(vec8(brw_null_reg()), BRW_REGISTER_TYPE_UW);
- if (intel-gen = 6 binding_table_index == 0) {
+ if (intel-gen = 6) {
insn = next_insn(p, BRW_OPCODE_SENDC);
} else {
insn = next_insn(p, BRW_OPCODE_SEND);
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] mesa: Make more consistent use of _mesa_is_{user, winsys}_fbo()
On 07/25/2012 08:19 AM, Paul Berry wrote: A lot of code was still differentiating between between winsys and user fbos by testing the fbo's name against zero. This converts everything in core mesa, the state tracker, and src/mesa/program over to use _mesa_is_user_fbo() and _mesa_is_winsys_fbo(). Nice. Patches 1 2: 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] Check the compilation problems in mesa-user
On Wed, Jul 25, 2012 at 6:57 AM, Brian Paul bri...@vmware.com wrote: Several days passed and no software renderer. I rather would like to test the llvmpipe than fix the compiler... What is the status with OSMesa and llvmpipe? OSMesa only works with the legacy swrast driver, not llvmpipe. One thing on my to-do list is to write a gallium state tracker to implement OSMesa for gallium drivers. But I don't know when I'll get to that. OSMesa does software offscreen rendering? Why wouldn't developers just use FBOs these days? Beyond not depending on OSMesa, they'd have hardware acceleration. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Check the compilation problems in mesa-user
On 07/25/2012 09:01 AM, Matt Turner wrote: On Wed, Jul 25, 2012 at 6:57 AM, Brian Paulbri...@vmware.com wrote: Several days passed and no software renderer. I rather would like to test the llvmpipe than fix the compiler... What is the status with OSMesa and llvmpipe? OSMesa only works with the legacy swrast driver, not llvmpipe. One thing on my to-do list is to write a gallium state tracker to implement OSMesa for gallium drivers. But I don't know when I'll get to that. OSMesa does software offscreen rendering? Why wouldn't developers just use FBOs these days? Beyond not depending on OSMesa, they'd have hardware acceleration. I think it's mostly legacay apps that use OSMesa. But some OSMesa apps do unusual things like directly touching the color/depth buffer values to avoid glRead/DrawPixels (see the OSMesaGetDepth/ColorBuffer() functions). -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Check the compilation problems in mesa-user
Brian Paul bri...@vmware.com writes: On 07/25/2012 09:01 AM, Matt Turner wrote: On Wed, Jul 25, 2012 at 6:57 AM, Brian Paulbri...@vmware.com wrote: Several days passed and no software renderer. I rather would like to test the llvmpipe than fix the compiler... What is the status with OSMesa and llvmpipe? OSMesa only works with the legacy swrast driver, not llvmpipe. One thing on my to-do list is to write a gallium state tracker to implement OSMesa for gallium drivers. But I don't know when I'll get to that. OSMesa does software offscreen rendering? Why wouldn't developers just use FBOs these days? Beyond not depending on OSMesa, they'd have hardware acceleration. I think it's mostly legacay apps that use OSMesa. But some OSMesa apps do unusual things like directly touching the color/depth buffer values to avoid glRead/DrawPixels (see the OSMesaGetDepth/ColorBuffer() functions). Even for hardware drivers, people want to be able to directly map renderbuffers (wine, ported DX apps, chromium at least I've hard of). If someone writes an extension for that, we might be able to stop having a custom GL library just for that purpose. pgpOSmUUcd1gG.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Check the compilation problems in mesa-user
On 07/25/2012 10:57 AM, Eric Anholt wrote: Brian Paulbri...@vmware.com writes: On 07/25/2012 09:01 AM, Matt Turner wrote: On Wed, Jul 25, 2012 at 6:57 AM, Brian Paulbri...@vmware.com wrote: Several days passed and no software renderer. I rather would like to test the llvmpipe than fix the compiler... What is the status with OSMesa and llvmpipe? OSMesa only works with the legacy swrast driver, not llvmpipe. One thing on my to-do list is to write a gallium state tracker to implement OSMesa for gallium drivers. But I don't know when I'll get to that. OSMesa does software offscreen rendering? Why wouldn't developers just use FBOs these days? Beyond not depending on OSMesa, they'd have hardware acceleration. I think it's mostly legacay apps that use OSMesa. But some OSMesa apps do unusual things like directly touching the color/depth buffer values to avoid glRead/DrawPixels (see the OSMesaGetDepth/ColorBuffer() functions). Even for hardware drivers, people want to be able to directly map renderbuffers (wine, ported DX apps, chromium at least I've hard of). If someone writes an extension for that, we might be able to stop having a custom GL library just for that purpose. I've actually thought about prototyping a GL extension which would allow the user to map renderbuffers and texture images for direct access. One messy part is the need to completely describe the format/layout of the memory since OpenGL doesn't normally let you know those exact details. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] mesa: Make more consistent use of _mesa_is_{user, winsys}_fbo()
On 07/25/2012 07:19 AM, Paul Berry wrote:
A lot of code was still differentiating between between winsys and
user fbos by testing the fbo's name against zero. This converts
everything in core mesa, the state tracker, and src/mesa/program over
to use _mesa_is_user_fbo() and _mesa_is_winsys_fbo().
---
src/mesa/main/context.c |8
src/mesa/main/drawpix.c |4 +++-
src/mesa/main/framebuffer.c |6 +++---
src/mesa/main/readpix.c |4 +++-
src/mesa/program/prog_statevars.c |3 ++-
src/mesa/state_tracker/st_cb_viewport.c |3 ++-
src/mesa/state_tracker/st_context.h |3 ++-
src/mesa/state_tracker/st_manager.c |3 ++-
8 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 41550f9..243053e 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1456,8 +1456,8 @@ _mesa_make_current( struct gl_context *newCtx,
_glapi_set_dispatch(newCtx-CurrentDispatch);
if (drawBuffer readBuffer) {
- ASSERT(drawBuffer-Name == 0);
- ASSERT(readBuffer-Name == 0);
+ ASSERT(_mesa_is_winsys_fbo(drawBuffer));
+ ASSERT(_mesa_is_winsys_fbo(readBuffer));
_mesa_reference_framebuffer(newCtx-WinSysDrawBuffer, drawBuffer);
_mesa_reference_framebuffer(newCtx-WinSysReadBuffer, readBuffer);
@@ -1465,7 +1465,7 @@ _mesa_make_current( struct gl_context *newCtx,
* Only set the context's Draw/ReadBuffer fields if they're NULL
* or not bound to a user-created FBO.
*/
- if (!newCtx-DrawBuffer || newCtx-DrawBuffer-Name == 0) {
+ if (!newCtx-DrawBuffer || _mesa_is_winsys_fbo(newCtx-DrawBuffer))
{
_mesa_reference_framebuffer(newCtx-DrawBuffer, drawBuffer);
/* Update the FBO's list of drawbuffers/renderbuffers.
* For winsys FBOs this comes from the GL state (which may have
@@ -1473,7 +1473,7 @@ _mesa_make_current( struct gl_context *newCtx,
*/
_mesa_update_draw_buffers(newCtx);
}
- if (!newCtx-ReadBuffer || newCtx-ReadBuffer-Name == 0) {
+ if (!newCtx-ReadBuffer || _mesa_is_winsys_fbo(newCtx-ReadBuffer))
{
_mesa_reference_framebuffer(newCtx-ReadBuffer, readBuffer);
}
diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c
index 49b0782..bd9837f 100644
--- a/src/mesa/main/drawpix.c
+++ b/src/mesa/main/drawpix.c
@@ -36,6 +36,7 @@
#include state.h
#include dispatch.h
#include glformats.h
+#include fbobject.h
#if FEATURE_drawpix
@@ -240,7 +241,8 @@ _mesa_CopyPixels( GLint srcx, GLint srcy, GLsizei width,
GLsizei height,
goto end;
}
- if (ctx-ReadBuffer-Name != 0 ctx-ReadBuffer-Visual.samples 0) {
+ if (_mesa_is_user_fbo(ctx-ReadBuffer)
+ ctx-ReadBuffer-Visual.samples 0) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glCopyPixels(multisample FBO));
goto end;
diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index f45ece6..13887f8 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -347,7 +347,7 @@ _mesa_resizebuffers( struct gl_context *ctx )
GLuint newWidth, newHeight;
struct gl_framebuffer *buffer = ctx-WinSysDrawBuffer;
- assert(buffer-Name == 0);
+ assert(_mesa_is_winsys_fbo(buffer));
/* ask device driver for size of output buffer */
ctx-Driver.GetBufferSize( buffer, newWidth, newHeight );
@@ -364,7 +364,7 @@ _mesa_resizebuffers( struct gl_context *ctx )
GLuint newWidth, newHeight;
struct gl_framebuffer *buffer = ctx-WinSysReadBuffer;
- assert(buffer-Name == 0);
+ assert(_mesa_is_winsys_fbo(buffer));
/* ask device driver for size of read buffer */
ctx-Driver.GetBufferSize( buffer, newWidth, newHeight );
@@ -444,7 +444,7 @@ _mesa_update_draw_buffer_bounds(struct gl_context *ctx)
if (!buffer)
return;
- if (buffer-Name) {
+ if (_mesa_is_user_fbo(buffer)) {
/* user-created framebuffer size depends on the renderbuffers */
update_framebuffer_size(ctx, buffer);
}
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 82d99fd..7ac8774 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -37,6 +37,7 @@
#include pbo.h
#include state.h
#include glformats.h
+#include fbobject.h
/**
@@ -722,7 +723,8 @@ _mesa_ReadnPixelsARB( GLint x, GLint y, GLsizei width,
GLsizei height,
}
}
- if (ctx-ReadBuffer-Name != 0 ctx-ReadBuffer-Visual.samples 0) {
+ if (_mesa_is_user_fbo(ctx-ReadBuffer)
+ ctx-ReadBuffer-Visual.samples 0) {
_mesa_error(ctx, GL_INVALID_OPERATION, glReadPixels(multisample
FBO));
return;
}
diff --git
Re: [Mesa-dev] [PATCH 2/4] intel: Make more consistent use of _mesa_is_{user, winsys}_fbo()
On 07/25/2012 07:20 AM, Paul Berry wrote:
A lot of code was still differentiating between between winsys and
user fbos by testing the fbo's name against zero. This converts
everything in the i915 and 965 drivers over to use _mesa_is_user_fbo()
and _mesa_is_winsys_fbo().
---
src/mesa/drivers/dri/i915/i830_vtbl.c |3 ++-
src/mesa/drivers/dri/i915/intel_tris.c |3 ++-
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp|5 +++--
src/mesa/drivers/dri/intel/intel_blit.c |3 ++-
src/mesa/drivers/dri/intel/intel_buffers.c |2 +-
src/mesa/drivers/dri/intel/intel_fbo.c |2 +-
src/mesa/drivers/dri/intel/intel_pixel_bitmap.c |5 +++--
src/mesa/drivers/dri/intel/intel_pixel_copy.c |5 +++--
src/mesa/drivers/dri/intel/intel_tex_copy.c |3 ++-
9 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c
b/src/mesa/drivers/dri/i915/i830_vtbl.c
index 28e95d9..6019852 100644
--- a/src/mesa/drivers/dri/i915/i830_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i830_vtbl.c
@@ -39,6 +39,7 @@
#include swrast_setup/swrast_setup.h
#include main/renderbuffer.h
#include main/framebuffer.h
+#include main/fbobject.h
#define FILE_DEBUG_FLAG DEBUG_STATE
@@ -769,7 +770,7 @@ i830_update_draw_buffer(struct intel_context *intel)
/* Get the intel_renderbuffer for the single colorbuffer we're drawing
* into.
*/
- if (fb-Name == 0) {
+ if (_mesa_is_winsys_fbo(fb)) {
/* drawing to window system buffer */
if (fb-_ColorDrawBufferIndexes[0] == BUFFER_FRONT_LEFT)
colorRegions[0] = intel_get_rb_region(fb, BUFFER_FRONT_LEFT);
diff --git a/src/mesa/drivers/dri/i915/intel_tris.c
b/src/mesa/drivers/dri/i915/intel_tris.c
index cf67d74..5954b24 100644
--- a/src/mesa/drivers/dri/i915/intel_tris.c
+++ b/src/mesa/drivers/dri/i915/intel_tris.c
@@ -38,6 +38,7 @@
#include main/texobj.h
#include main/state.h
#include main/dd.h
+#include main/fbobject.h
#include swrast/swrast.h
#include swrast_setup/swrast_setup.h
@@ -503,7 +504,7 @@ intel_emit_fragcoord(struct intel_context *intel,
intelVertexPtr v)
fragcoord[0] = vertex_position[0];
- if (fb-Name)
+ if (_mesa_is_user_fbo(fb))
fragcoord[1] = vertex_position[1];
else
fragcoord[1] = fb-Height - vertex_position[1];
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index f8b7e4a..bd15632 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -22,6 +22,7 @@
*/
#include main/teximage.h
+#include main/fbobject.h
#include glsl/ralloc.h
@@ -214,13 +215,13 @@ try_blorp_blit(struct intel_context *intel,
/* Account for the fact that in the system framebuffer, the origin is at
* the lower left.
*/
- if (read_fb-Name == 0) {
+ if (_mesa_is_winsys_fbo(read_fb)) {
GLint tmp = read_fb-Height - srcY0;
srcY0 = read_fb-Height - srcY1;
srcY1 = tmp;
mirror_y = !mirror_y;
}
- if (draw_fb-Name == 0) {
+ if (_mesa_is_winsys_fbo(draw_fb)) {
GLint tmp = draw_fb-Height - dstY0;
dstY0 = draw_fb-Height - dstY1;
dstY1 = tmp;
diff --git a/src/mesa/drivers/dri/intel/intel_blit.c
b/src/mesa/drivers/dri/intel/intel_blit.c
index fd4a86c..36a2c6a 100644
--- a/src/mesa/drivers/dri/intel/intel_blit.c
+++ b/src/mesa/drivers/dri/intel/intel_blit.c
@@ -30,6 +30,7 @@
#include main/context.h
#include main/enums.h
#include main/colormac.h
+#include main/fbobject.h
#include intel_blit.h
#include intel_buffers.h
@@ -248,7 +249,7 @@ intelClearWithBlit(struct gl_context *ctx, GLbitfield
mask)
}
cx = fb-_Xmin;
- if (fb-Name == 0)
+ if (_mesa_is_winsys_fbo(fb))
cy = ctx-DrawBuffer-Height - fb-_Ymax;
else
cy = fb-_Ymin;
diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c
b/src/mesa/drivers/dri/intel/intel_buffers.c
index 2b02763..9a9a259 100644
--- a/src/mesa/drivers/dri/intel/intel_buffers.c
+++ b/src/mesa/drivers/dri/intel/intel_buffers.c
@@ -70,7 +70,7 @@ void
intel_check_front_buffer_rendering(struct intel_context *intel)
{
const struct gl_framebuffer *fb = intel-ctx.DrawBuffer;
- if (fb-Name == 0) {
+ if (_mesa_is_winsys_fbo(fb)) {
/* drawing to window system buffer */
if (fb-_NumColorDrawBuffers 0) {
if (fb-_ColorDrawBufferIndexes[0] == BUFFER_FRONT_LEFT) {
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index ac7d6c1..a53985b 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -359,7 +359,7 @@ intel_resize_buffers(struct gl_context *ctx, struct
gl_framebuffer *fb,
fb-Initialized = true; /* XXX remove someday */
- if (fb-Name !=
Re: [Mesa-dev] [PATCH 4/4] i965: Use sendc for all render target writes on Gen6+.
On 07/25/2012 07:20 AM, Paul Berry wrote:
The sendc instruction causes the fragment shader thread to wait for
any dependent threads (i.e. threads rendering to overlapping pixels)
to complete before sending the message. We need to use sendc on the
first render target write in order to guarantee that fragment shader
outputs are written to the render target in the correct order.
Previously, we only used the sendc instruction when writing to
binding table index 0. This did the right thing for fragment shaders,
because our fragment shader back-ends always issue their first render
target write to binding table index 0. However, it did the wrong
thing for blorp, which performs its render target writes to binding
table index 1.
A more robust solution is to use sendc for all render target writes.
This should not produce any performance penalty, since after the first
sendc, all of the dependent threads will have completed.
For more information about sendc, see the Ivy Bridge PRM, Vol4 Part3
p218 (sendc - Conditional Send Message), and p54 (TDR Registers).
---
src/mesa/drivers/dri/i965/brw_eu_emit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 93e84ae..25bf91b 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -2259,7 +2259,7 @@ void brw_fb_WRITE(struct brw_compile *p,
else
dest = retype(vec8(brw_null_reg()), BRW_REGISTER_TYPE_UW);
- if (intel-gen = 6 binding_table_index == 0) {
+ if (intel-gen = 6) {
insn = next_insn(p, BRW_OPCODE_SENDC);
} else {
insn = next_insn(p, BRW_OPCODE_SEND);
For the series (pithy comments aside):
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Please wait for Eric's ack on patch 4 before pushing that, though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: remove _math_matrix_alloc_inv()
On 07/25/2012 06:33 AM, Brian Paul wrote: Always allocate space for the inverse matrix in _math_matrix_ctr() since we were always calling _math_matrix_alloc_inv() anyway. --- src/mesa/main/matrix.c|4 +-- src/mesa/math/m_matrix.c | 51 - src/mesa/math/m_matrix.h |5 +--- src/mesa/program/prog_statevars.c |1 - 4 files changed, 13 insertions(+), 48 deletions(-) Nice cleanup! Much less fiddly code. Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/15] intel: Refactor quantize_num_samples
Chad Versace chad.vers...@linux.intel.com writes: Rename quantize_num_samples to intel_quantize_num_samples and change the first param from struct intel_context* to struct intel_screen*. The function will later be used by intelCreateBuffer, which is not bound to any context but is bound to a screen. Since the function now depends on the screen, move it to intel_screen.[ch]. intel_fbo seems like a good place for it as well -- we've got other screen-dependent function scattered around. I don't really care either way, but I think I would have looked in intel_fbo.c first. pgppzRxQzqjPm.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 05/15] intel: Set num samples for winsys renderbuffers
Chad Versace chad.vers...@linux.intel.com writes: Add a new param, num_samples, to intel_create_renderbuffer and intel_create_private_renderbuffer. The caller, intelCreateBuffer, passes in the value of gl_config::NumSamples. No multisample GL config is yet advertised, so the value of num_samples is currently 0. For server-owned winsys buffers, gl_renderbuffer::NumSamples is not yet used. It would make more sense to me if the quantizing was done once and passed to the create_renderbuffer call (you need the same NumSamples across them, anyway). Then you wouldn't need the screen argument, either. pgpHslJpdodl6.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] radeonsi: fix shader size and handling
We should always upload the shader here.
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 26
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index 0edb379..32290a2 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
@@ -552,6 +552,7 @@ int si_pipe_shader_create(
unsigned char * inst_bytes;
unsigned inst_byte_count;
unsigned i;
+ uint32_t *ptr;
bool dump;
dump = debug_get_bool_option(RADEON_DUMP_SHADERS, FALSE);
@@ -606,23 +607,22 @@ int si_pipe_shader_create(
tgsi_parse_free(si_shader_ctx.parse);
/* copy new shader */
+ si_resource_reference(shader-bo, NULL);
+ shader-bo = si_resource_create_custom(ctx-screen,
PIPE_USAGE_IMMUTABLE,
+ inst_byte_count - 12);
if (shader-bo == NULL) {
- uint32_t *ptr;
+ return -ENOMEM;
+ }
- shader-bo = si_resource_create_custom(ctx-screen,
PIPE_USAGE_IMMUTABLE, inst_byte_count);
- if (shader-bo == NULL) {
- return -ENOMEM;
- }
- ptr = (uint32_t*)rctx-ws-buffer_map(shader-bo-cs_buf,
rctx-cs, PIPE_TRANSFER_WRITE);
- if (0 /*R600_BIG_ENDIAN*/) {
- for (i = 0; i (inst_byte_count-12)/4; ++i) {
- ptr[i] =
util_bswap32(*(uint32_t*)(inst_bytes+12 + i*4));
- }
- } else {
- memcpy(ptr, inst_bytes + 12, inst_byte_count - 12);
+ ptr = (uint32_t*)rctx-ws-buffer_map(shader-bo-cs_buf, rctx-cs,
PIPE_TRANSFER_WRITE);
+ if (0 /*R600_BIG_ENDIAN*/) {
+ for (i = 0; i (inst_byte_count-12)/4; ++i) {
+ ptr[i] = util_bswap32(*(uint32_t*)(inst_bytes+12 +
i*4));
}
- rctx-ws-buffer_unmap(shader-bo-cs_buf);
+ } else {
+ memcpy(ptr, inst_bytes + 12, inst_byte_count - 12);
}
+ rctx-ws-buffer_unmap(shader-bo-cs_buf);
free(inst_bytes);
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] radeonsi: rename r600_resource to si_resource
Also split it into seperate header and add
some helper functions.
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/drivers/radeonsi/r600.h| 21 ++
src/gallium/drivers/radeonsi/r600_buffer.c | 12 ++--
src/gallium/drivers/radeonsi/r600_hw_context.c | 23 +++
.../drivers/radeonsi/r600_hw_context_priv.h|2 +-
src/gallium/drivers/radeonsi/r600_resource.h |9 +--
src/gallium/drivers/radeonsi/r600_texture.c| 24 +++
src/gallium/drivers/radeonsi/radeonsi_pipe.c | 15 ++---
src/gallium/drivers/radeonsi/radeonsi_pipe.h |8 +--
src/gallium/drivers/radeonsi/radeonsi_pm4.c|8 +--
src/gallium/drivers/radeonsi/radeonsi_pm4.h|4 +-
src/gallium/drivers/radeonsi/radeonsi_resource.h | 67
src/gallium/drivers/radeonsi/radeonsi_shader.c |5 +-
src/gallium/drivers/radeonsi/si_state.c| 23 +++
src/gallium/drivers/radeonsi/si_state.h|2 +-
src/gallium/drivers/radeonsi/si_state_draw.c | 11 ++--
15 files changed, 140 insertions(+), 94 deletions(-)
create mode 100644 src/gallium/drivers/radeonsi/radeonsi_resource.h
diff --git a/src/gallium/drivers/radeonsi/r600.h
b/src/gallium/drivers/radeonsi/r600.h
index 6ff0bf8..f22d920 100644
--- a/src/gallium/drivers/radeonsi/r600.h
+++ b/src/gallium/drivers/radeonsi/r600.h
@@ -30,6 +30,8 @@
#include util/u_double_list.h
#include util/u_transfer.h
+#include radeonsi_resource.h
+
#define R600_ERR(fmt, args...) \
fprintf(stderr, EE %s:%d %s - fmt, __FILE__, __LINE__, __func__,
##args)
@@ -55,17 +57,6 @@ struct r600_tiling_info {
unsigned group_bytes;
};
-struct r600_resource {
- struct u_resource b;
-
- /* Winsys objects. */
- struct pb_buffer*buf;
- struct radeon_winsys_cs_handle *cs_buf;
-
- /* Resource state. */
- unsigneddomains;
-};
-
/* R600/R700 STATES */
struct r600_query {
union {
@@ -85,7 +76,7 @@ struct r600_query {
/* The buffer where query results are stored. It's used as a ring,
* data blocks for current query are stored sequentially from
* results_start to results_end, with wrapping on the buffer end */
- struct r600_resource*buffer;
+ struct si_resource *buffer;
/* The number of dwords for begin_query or end_query. */
unsignednum_cs_dw;
/* linked list of queries */
@@ -96,7 +87,7 @@ struct r600_so_target {
struct pipe_stream_output_target b;
/* The buffer where BUFFER_FILLED_SIZE is stored. */
- struct r600_resource*filled_size;
+ struct si_resource *filled_size;
unsignedstride;
unsignedso_index;
};
@@ -113,7 +104,7 @@ struct r600_draw {
uint32_tindices_bo_offset;
unsigneddb_render_override;
unsigneddb_render_control;
- struct r600_resource*indices;
+ struct si_resource *indices;
};
struct r600_context;
@@ -133,7 +124,7 @@ void r600_context_queries_suspend(struct r600_context *ctx);
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,
+void r600_context_emit_fence(struct r600_context *ctx, struct si_resource
*fence,
unsigned offset, unsigned value);
void r600_context_streamout_begin(struct r600_context *ctx);
diff --git a/src/gallium/drivers/radeonsi/r600_buffer.c
b/src/gallium/drivers/radeonsi/r600_buffer.c
index 15bff91..76de941 100644
--- a/src/gallium/drivers/radeonsi/r600_buffer.c
+++ b/src/gallium/drivers/radeonsi/r600_buffer.c
@@ -40,7 +40,7 @@ static void r600_buffer_destroy(struct pipe_screen *screen,
struct pipe_resource *buf)
{
struct r600_screen *rscreen = (struct r600_screen*)screen;
- struct r600_resource *rbuffer = r600_resource(buf);
+ struct si_resource *rbuffer = si_resource(buf);
pb_reference(rbuffer-buf, NULL);
FREE(rbuffer);
@@ -72,7 +72,7 @@ static struct pipe_transfer *r600_get_transfer(struct
pipe_context *ctx,
static void *r600_buffer_transfer_map(struct pipe_context *pipe,
struct pipe_transfer *transfer)
{
- struct r600_resource *rbuffer = r600_resource(transfer-resource);
+ struct si_resource *rbuffer = si_resource(transfer-resource);
struct r600_context *rctx = (struct r600_context*)pipe;
uint8_t *data;
@@ -115,7 +115,7 @@ static const struct u_resource_vtbl r600_buffer_vtbl =
};
bool
[Mesa-dev] [PATCH 3/5] radeonsi: fix vertex buffer and elements
Let's just use the T# descriptors until we get a fetch shader.
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/drivers/radeonsi/radeonsi_shader.c |6 +-
src/gallium/drivers/radeonsi/si_state.c| 43 +++--
src/gallium/drivers/radeonsi/si_state.h|9 +--
src/gallium/drivers/radeonsi/si_state_draw.c | 80 +---
4 files changed, 74 insertions(+), 64 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index 32290a2..4c9e4fa 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
@@ -182,7 +182,7 @@ static void declare_input_vs(
struct lp_build_context * uint =
si_shader_ctx-radeon_bld.soa.bld_base.uint_bld;
struct lp_build_context * base =
si_shader_ctx-radeon_bld.soa.bld_base.base;
struct r600_context *rctx = si_shader_ctx-rctx;
- struct pipe_vertex_element *velem =
rctx-vertex_elements-elements[input_index];
+ //struct pipe_vertex_element *velem =
rctx-vertex_elements-elements[input_index];
unsigned chan;
/* Load the T list */
@@ -191,12 +191,12 @@ static void declare_input_vs(
* now */
t_list_ptr = use_sgpr(base-gallivm, SGPR_CONST_PTR_V4I32, 6);
- t_offset = lp_build_const_int32(base-gallivm,
velem-vertex_buffer_index);
+ t_offset = lp_build_const_int32(base-gallivm, input_index);
t_list = build_indexed_load(base-gallivm, t_list_ptr, t_offset);
/* Build the attribute offset */
- attribute_offset = lp_build_const_int32(base-gallivm,
velem-src_offset);
+ attribute_offset = lp_build_const_int32(base-gallivm, 0);
/* Load the buffer index is always, which is always stored in VGPR0
* for Vertex Shaders */
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 297d791..c417c9c 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -1226,10 +1226,10 @@ static bool si_is_sampler_format_supported(struct
pipe_screen *screen, enum pipe
util_format_get_first_non_void_channel(format)) != ~0U;
}
-uint32_t si_translate_vertexformat(struct pipe_screen *screen,
- enum pipe_format format,
- const struct util_format_description *desc,
- int first_non_void)
+static uint32_t si_translate_vertexformat(struct pipe_screen *screen,
+ enum pipe_format format,
+ const struct util_format_description
*desc,
+ int first_non_void)
{
uint32_t result;
@@ -2078,12 +2078,45 @@ static void *si_create_vertex_elements(struct
pipe_context *ctx,
const struct pipe_vertex_element
*elements)
{
struct si_vertex_element *v = CALLOC_STRUCT(si_vertex_element);
+ int i;
- assert(count 32);
+ assert(count PIPE_MAX_ATTRIBS);
if (!v)
return NULL;
v-count = count;
+ for (i = 0; i count; ++i) {
+ const struct util_format_description *desc;
+ unsigned data_format, num_format;
+ int first_non_void;
+
+ desc = util_format_description(elements[i].src_format);
+ first_non_void =
util_format_get_first_non_void_channel(elements[i].src_format);
+ data_format = si_translate_vertexformat(ctx-screen,
elements[i].src_format,
+ desc, first_non_void);
+
+ switch (desc-channel[first_non_void].type) {
+ case UTIL_FORMAT_TYPE_FIXED:
+ num_format = V_008F0C_BUF_NUM_FORMAT_USCALED; /* XXX */
+ break;
+ case UTIL_FORMAT_TYPE_SIGNED:
+ num_format = V_008F0C_BUF_NUM_FORMAT_SNORM;
+ break;
+ case UTIL_FORMAT_TYPE_UNSIGNED:
+ num_format = V_008F0C_BUF_NUM_FORMAT_UNORM;
+ break;
+ case UTIL_FORMAT_TYPE_FLOAT:
+ default:
+ num_format = V_008F14_IMG_NUM_FORMAT_FLOAT;
+ }
+
+ v-rsrc_word3[i] =
S_008F0C_DST_SEL_X(si_map_swizzle(desc-swizzle[0])) |
+
S_008F0C_DST_SEL_Y(si_map_swizzle(desc-swizzle[1])) |
+
S_008F0C_DST_SEL_Z(si_map_swizzle(desc-swizzle[2])) |
+
S_008F0C_DST_SEL_W(si_map_swizzle(desc-swizzle[3])) |
+ S_008F0C_NUM_FORMAT(num_format) |
+ S_008F0C_DATA_FORMAT(data_format);
+ }
[Mesa-dev] [PATCH 4/5] radeonsi: fix register count calculation
Signed-off-by: Christian König deathsim...@vodafone.de --- src/gallium/drivers/radeonsi/si_state_draw.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c b/src/gallium/drivers/radeonsi/si_state_draw.c index 0d9f009..74ed01f 100644 --- a/src/gallium/drivers/radeonsi/si_state_draw.c +++ b/src/gallium/drivers/radeonsi/si_state_draw.c @@ -86,8 +86,8 @@ static void si_pipe_shader_vs(struct pipe_context *ctx, struct si_pipe_shader *s assert(num_sgprs = 104); si_pm4_set_reg(pm4, R_00B128_SPI_SHADER_PGM_RSRC1_VS, - S_00B128_VGPRS((shader-num_vgprs - 1) / 4) | - S_00B128_SGPRS((num_sgprs - 1) / 8)); + S_00B128_VGPRS((align(shader-num_vgprs,4) / 4) - 1) | + S_00B128_SGPRS((align(num_sgprs, 8) / 8) - 1)); si_pm4_set_reg(pm4, R_00B12C_SPI_SHADER_PGM_RSRC2_VS, S_00B12C_USER_SGPR(num_user_sgprs)); @@ -192,8 +192,8 @@ static void si_pipe_shader_ps(struct pipe_context *ctx, struct si_pipe_shader *s assert(num_sgprs = 104); si_pm4_set_reg(pm4, R_00B028_SPI_SHADER_PGM_RSRC1_PS, - S_00B028_VGPRS((shader-num_vgprs - 1) / 4) | - S_00B028_SGPRS((num_sgprs - 1) / 8)); + S_00B028_VGPRS((align(shader-num_vgprs, 4) / 4) - 1) | + S_00B028_SGPRS((align(num_sgprs, 8) / 8) - 1)); si_pm4_set_reg(pm4, R_00B02C_SPI_SHADER_PGM_RSRC2_PS, S_00B02C_USER_SGPR(num_user_sgprs)); -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] radeonsi: fix dst clobber of buffer loads
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/drivers/radeon/SIInstrInfo.td |2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/radeon/SIInstrInfo.td
b/src/gallium/drivers/radeon/SIInstrInfo.td
index aac6443..3fcf4e2 100644
--- a/src/gallium/drivers/radeon/SIInstrInfo.td
+++ b/src/gallium/drivers/radeon/SIInstrInfo.td
@@ -424,6 +424,7 @@ class MUBUF_Load_Helper bits7 op, string asm,
RegisterClass regClass : MUBUF
asm,
[] {
let mayLoad = 1;
+ let Constraints = @earlyclobber $dst;
}
class MTBUF_Load_Helper bits3 op, string asm, RegisterClass regClass :
MTBUF
@@ -435,6 +436,7 @@ class MTBUF_Load_Helper bits3 op, string asm,
RegisterClass regClass : MTBUF
asm,
[] {
let mayLoad = 1;
+ let Constraints = @earlyclobber $dst;
}
class MTBUF_Store_Helper bits3 op, string asm, RegisterClass regClass :
MTBUF
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 14/15] intel: Refactor intel_screen_make_configs
Chad Versace chad.vers...@linux.intel.com writes: Transform the code from clever, obfuscated, and imperative to straight-forward and table-driven. I don't like this change. It increases the amount of code, and to change any single option, you need to change more code. If we were to change back_buffer_modes (and I think we need to, since we potentially pageflip instead of blitting, so we don't adhere to GLX_SWAP_COPY_OML), we would need to hit each struct's count instead of just the shared list. And MSAA was incoherent with single sample in those bits for reasons I don't understand. If we were to expose 16 and 24 depth on both 16 and 32 color, we would need to duplicate it across all the color setup, instead of just removing the if/else in the previous code and bumping the count. If we were to choose whether to expose non-stencil depth configs based on whether the hardware requires separate stencil or not... I don't know what we would do. If I was to go cleaning up config creation code, I would change driCreateConfigs to have sentinels terminating the arrays instead of separate counts. pgpQT5pGnP5Nt.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 47375] Blender crash on startup after upgrade to mesa 8.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=47375 --- Comment #14 from Barto mister.free...@laposte.net 2012-07-25 18:56:11 PDT --- (In reply to comment #13) I also tried forcing fallback=1 so that _swrast_DrawPixels() gets called but I didn't see any failed assertions. I'm using the Mesa 8.0.x branch. I don't have a r200 gpu to try that driver. Brian, can you tell me what are the differences in swrast component between the 7.11.2-1 mesa release version and the 8.0.x release ? we know that swrast runs without problems in 7.11.2-1 mesa version with blender and an old ati radeon card ( rv250, rv280 cards ), but something in the 8.0.x mesa release has changed in the swrast component, if we can locate these new lines in the source code then we will find probably the culprit, maybe a new onpenGL instruction who is not supported by old card like rv250, rv280, don't forget that radeon 9000 card ( rv250 ) only supports opengl 1.3 version, I need some tips in order to debug this problem ( I'm a newbie in debugging opengl/multimedia software ) thanks -- 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 v2, android-build] android-build: fix dricore build for autogenerated files
On 07/23/2012 12:13 PM, Daniel Charles wrote: Recently more files were removed from control to be auto-generated in the dricore library. Android build was not able to locate the new files if they were not created beforehand. LOCAL_SRC_FILES includes some of those files and Android.gen.mk re-defines this variable by filtering out the auto-generated files. Unfortunately for this variable it is not the same to have the SRCDIR variable defined as the current directory. By re-defining SRCDIR for the autotools build the Android build system is happy again and the new files were actually removed from the sources to use the auto generated versions. Also patch d5c1801a018efda8ac2b was partially reverted as the files can not be compiled to the LOCAL_PATH, instead they should live on the intermediates folder so that a clean can wipe them out. Change-Id: I75e86453d23f6b6f0e2a7dfb1b48272965c9fbf2 Signed-off-by: Daniel Charles daniel.char...@intel.com --- src/mesa/Android.gen.mk | 68 +-- src/mesa/Android.mk |1 - src/mesa/Makefile.am|4 +- src/mesa/sources.mak| 561 --- 4 files changed, 337 insertions(+), 297 deletions(-) Looks good to me. Reviewed-by: Chad Versace chad.vers...@linux.intel.com I'll commit this tomorrow if no one objects. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can --enable-shared-glapi die?
On Tue, 2012-07-24 at 10:45 -0700, Ian Romanick wrote: On 07/23/2012 12:59 PM, Ian Romanick wrote: Perhaps someone can refresh my memory as to what exactly this option does? Can we make this the default and remove the option from configure? Thanks to all for the refresher. Off-list someone raised another issue to me that seems like a deal breaker. If an application links with a libGL that uses libglapi it appears that the application gets implicitly linked with libglapi (as shown by objdump -x | grep -i need). This will cause the application to fail if a non-glapi libGL (i.e., any of the closed-source drivers) is later installed. The problem seems to be that symbols like glBegin are in libglapi. Is this fixable? I think the usual cause for this is linking with libtool. By default, libtool will read the libGL.la file associated with your libGL.so, and add all of the dependency libraries listed in the .la file to the link command line, even if the operating system does not require them to be linked in. (There are some options that some versions of ld have that will cause ld to ignore these libraries and not *actually* link them in; some newer distributions are starting to use these options) The easy workaround is simply to delete the libGL.la file after installation, to force libtool to link *only* to libGL.so. -- Calvin Walton calvin.wal...@kepstin.ca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] radeonsi: rename r600_resource to si_resource
On Wed, Jul 25, 2012 at 1:58 PM, Christian König deathsim...@vodafone.de wrote: Also split it into seperate header and add some helper functions. Signed-off-by: Christian König deathsim...@vodafone.de For the series: Reviewed-by: Alex Deucher alexander.deuc...@amd.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 47375] Blender crash on startup after upgrade to mesa 8.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=47375 --- Comment #15 from Brian Paul brian.e.p...@gmail.com 2012-07-25 22:22:58 PDT --- (In reply to comment #14) Brian, can you tell me what are the differences in swrast component between the 7.11.2-1 mesa release version and the 8.0.x release ? There's a ton of changes in swrast since 7.11, unfortunately. we know that swrast runs without problems in 7.11.2-1 mesa version with blender and an old ati radeon card ( rv250, rv280 cards ), but something in the 8.0.x mesa release has changed in the swrast component, if we can locate these new lines in the source code then we will find probably the culprit, maybe a new onpenGL instruction who is not supported by old card like rv250, rv280, don't forget that radeon 9000 card ( rv250 ) only supports opengl 1.3 version, I need some tips in order to debug this problem ( I'm a newbie in debugging opengl/multimedia software ) Let's first find out why the 'fallback' variable in _mesa_meta_DrawPixels() is getting set. Basically, use gdb to set a breakpoint in _mesa_meta_DrawPixels() then go step by step to see where 'fallback = GL_TRUE' is getting hit. To set a breakpoint: break _mesa_meta_DrawPixels() To step one instruction: s or step When you find the point where fallback = GL_TRUE is set, note the current line and try to print some of the variables in the conditionals. -- 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] i965: Enable window system multisampling
On 21 July 2012 17:36, Chad Versace chad.vers...@linux.intel.com wrote: No Piglit regressions on Ivybridge. Tested with `glxgears -samples 1`. Passes 53/70 of oglconform's winsys multisample tests. The failing tests mostly consist of those that call glDrawPixels on the depth and stencil buffer (which fail due to a swrast fallback) or do fancy things with the msaa alpha enums (which also fail with non-winsys msaa). We probably need to write some Piglit tests for some winsys msaa corner cases, but I think the series is good enough to push now based on the evidence of oglconform's pass rate. Chad Versace (15): intel: Remove dead code in intelAllocateBuffer intel: Decrease nesting level in intelCreateBuffer intel: Use consistent pattern in intelCreateBuffer intel: Refactor quantize_num_samples intel: Set num samples for winsys renderbuffers intel: Add intel_mipmap_tree::singlesample_mt intel: Refactor creation of hiz and mcs miptrees intel: Allocate miptree for multisample DRI2 buffers i965: Add function intel_miptree_downsample i965: Mark winsys MSAA color buffer as needing resolve postdraw intel: Downsample during glReadPixels intel: Downsample on DRI2 flush intel: Refactor creation of DRI2 configs intel: Refactor intel_screen_make_configs intel: Advertise multisample DRI2 configs on gen = 6 To update the list on what Chad and I discussed in person today: Patches 1-7, 9, and 12-13 are Reviewed-by: Paul Berry stereotype...@gmail.com I have some concerns about patches 8, 10, and 11 which I've already emailed you about. I don't feel qualified to review patches 14-15, but fortunately Ian and Eric already seem to be weighing in on those patches. You and I discovered this morning that patch 15 introduces a bug with gnome--it makes gnome-terminal windows fail to show up when using the gnome compositing window manager. The bug seems to be related to where the multisampled visuals appear in the list of visuals, and we suspect that some part of gnome is erroneously relying on the visuals being in a certain order. I will try to investigate this bug as soon as I get a chance (partly because I think you are busier than me these days, and partly because I think it will be educational for me). I'll keep you posted on my progress. If things get too busy for you and you want me to take over the patch series, let me know. For now I'll assume you still own the patch series, and I'm just providing troubleshooting assistance :) src/mesa/drivers/dri/i965/Makefile.sources | 1 + src/mesa/drivers/dri/i965/brw_blorp_orphans.cpp | 66 +++ src/mesa/drivers/dri/i965/brw_draw.c| 17 +- src/mesa/drivers/dri/intel/intel_context.c | 26 +- src/mesa/drivers/dri/intel/intel_fbo.c | 58 +-- src/mesa/drivers/dri/intel/intel_fbo.h | 8 +- src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 82 src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 39 ++ src/mesa/drivers/dri/intel/intel_screen.c | 540 +--- src/mesa/drivers/dri/intel/intel_screen.h | 3 + 10 files changed, 536 insertions(+), 304 deletions(-) create mode 100644 src/mesa/drivers/dri/i965/brw_blorp_orphans.cpp -- 1.7.11.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] xlib: add X error handler around XGetImage() call
XGetImage() will generate a BadMatch error if the source window isn't
visible. When that happens, create a new XImage. Fixes piglit 'select'
test failures with swrast/xlib driver.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/drivers/x11/xm_buffer.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/x11/xm_buffer.c b/src/mesa/drivers/x11/xm_buffer.c
index a7395a3..eb68f94 100644
--- a/src/mesa/drivers/x11/xm_buffer.c
+++ b/src/mesa/drivers/x11/xm_buffer.c
@@ -446,14 +446,43 @@ xmesa_MapRenderbuffer(struct gl_context *ctx,
}
else {
/* this must be a pixmap/window renderbuffer */
+ int (*old_handler)(XMesaDisplay *, XErrorEvent *);
int y2 = rb-Height - y - h;
assert(xrb-pixmap);
+ /* Install error handler for XGetImage() in case the the window
+ * isn't mapped. If we fail we'll create a temporary XImage.
+ */
+ mesaXErrorFlag = 0;
+ old_handler = XSetErrorHandler(mesaHandleXError);
+
/* read pixel data out of the pixmap/window into an XImage */
ximage = XGetImage(xrb-Parent-display,
xrb-pixmap, x, y2, w, h,
AllPlanes, ZPixmap);
+
+ XSetErrorHandler(old_handler);
+
+ if (mesaXErrorFlag) {
+/* create new, temporary XImage */
+int bytes_per_line =
+ _mesa_format_row_stride(xrb-Base.Base.Format,
+ xrb-Base.Base.Width);
+char *image = (char *) malloc(bytes_per_line *
+ xrb-Base.Base.Height);
+ximage = XCreateImage(xrb-Parent-display,
+ xrb-Parent-xm_visual-visinfo-visual,
+ xrb-Parent-xm_visual-visinfo-depth,
+ ZPixmap, /* format */
+ 0, /* offset */
+ image, /* data */
+ xrb-Base.Base.Width,
+ xrb-Base.Base.Height,
+ 8, /* pad */
+ bytes_per_line);
+ }
+
if (!ximage) {
*mapOut = NULL;
*rowStrideOut = 0;
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52512] New: Build failures: glsl_lexer.cc glsl_parser.cc don't exist
https://bugs.freedesktop.org/show_bug.cgi?id=52512 Bug #: 52512 Summary: Build failures: glsl_lexer.cc glsl_parser.cc don't exist Classification: Unclassified Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: bugs...@moreofthesa.me.uk make[5]: *** No rule to make target `../../../../../src/mesa/libdricore/../../glsl/glsl_lexer.cc', needed by `glsl_lexer.lo'. Stop. And similarly for glsl_parser.cc. Fixed locally by symlinking glsl_lexer.cc to glsl_lexer.cpp and glsl_parser.cc to glsl_parser.cpp. -- 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 52513] New: Building static libs doesn't work
https://bugs.freedesktop.org/show_bug.cgi?id=52513 Bug #: 52513 Summary: Building static libs doesn't work Classification: Unclassified Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: bugs...@moreofthesa.me.uk Created attachment 64688 -- https://bugs.freedesktop.org/attachment.cgi?id=64688 Patch (git am) I've been seeing build failures when compiling static libs due to an assumption that shared libraries are being built despite configuration options. The attached patch fixes this. (I'm using tweaked Debian packaging for local builds.) -- 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 52512] Build failures: glsl_lexer.cc glsl_parser.cc don't exist
https://bugs.freedesktop.org/show_bug.cgi?id=52512 --- Comment #1 from Kenneth Graunke kenn...@whitecape.org 2012-07-25 23:06:30 UTC --- Presumably this is with the latest git master? Have you done make clean/git clean? Also, what version of automake do you have? -- 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
