[Mesa-dev] [PATCH] mesa: do not define NDEBUG to make sure assert work
If you include mtypes.h, which would define macro NDEBUG, before including compiler.h, you would find that the assert macro will no longer work; it just make it slient by replacing it with ((void) (0)); Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com --- src/mesa/main/mtypes.h |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 749324d..5edecf2 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -3336,9 +3336,6 @@ extern int MESA_DEBUG_FLAGS; # define MESA_VERBOSE 0 # define MESA_DEBUG_FLAGS 0 # define MESA_FUNCTION a function -# ifndef NDEBUG -# define NDEBUG -# endif #endif -- 1.7.4.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: do not define NDEBUG to make sure assert work
On 10/08/2011 02:08 AM, Yuanhan Liu wrote: If you include mtypes.h, which would define macro NDEBUG, before including compiler.h, you would find that the assert macro will no longer work; it just make it slient by replacing it with ((void) (0)); Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com --- src/mesa/main/mtypes.h |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 749324d..5edecf2 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -3336,9 +3336,6 @@ extern int MESA_DEBUG_FLAGS; Isn't this intentional? To give some context to the patch: #ifdef DEBUG extern int MESA_VERBOSE; extern int MESA_DEBUG_FLAGS; # define MESA_FUNCTION __FUNCTION__ #else # define MESA_VERBOSE 0 # define MESA_DEBUG_FLAGS 0 # define MESA_FUNCTION a function -# ifndef NDEBUG -# define NDEBUG -# endif #endif So NDEBUG only gets defined if !DEBUG. In other words, assertions happen if you build with --enable-debug, but not in release mode (since it's extra overhead). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g shader optimization
Hi Vadim, wow quite impressive, does it also contains peep-hole optimisation? I tried to implement that once, but failed because I never got all the dependencies between opcodes correctly resolved. Rescheduling export instructions and setting the barrier flag of CF instructions correctly can also be quite an improvement. Just a side note in commit r600g: make some functions in r600_asm.c externally accessible you make a whole bunch of functions externally accessible, but didn't add a proper prefix like r600_ to the function name. That could led to a bit confusion when somebody else tries to hack on the code. Regards, Christian. Am Freitag, den 07.10.2011, 18:14 +0400 schrieb Vadim Girlin: Hi, Recently I've been working on the shader optimization for r600g, and now I have the initial working implementation of simple alu scheduler and register allocator. It has no piglit regressions, though it's still a work in progress and there are known issues with some applications. I've pushed the working branch to github: https://github.com/VadimGirlin/mesa/tree/r600_shader_opt Currently it supports evergreen only, but I'm planning to make it work with other chips too. It uses struct r600_bytecode as the source, converting it to SSA-based internal representation. I'm going to implement some optimization passes at that phase, but currently it's then doing final steps - register allocation, alu scheduling, and building new bytecode. I'm attaching as an example the dump for one of the shaders in the glxgears. You could get such dump for all shaders before and after processing by setting R600_OPT_DUMP environment variable to 2. Setting this variable to 1 will only print some information for the processed shaders - size, number of gprs, and number of alu instruction groups. Vadim ___ 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] mesa: do not define NDEBUG to make sure assert work
On Sat, Oct 08, 2011 at 02:17:29AM -0700, Kenneth Graunke wrote: On 10/08/2011 02:08 AM, Yuanhan Liu wrote: If you include mtypes.h, which would define macro NDEBUG, before including compiler.h, you would find that the assert macro will no longer work; it just make it slient by replacing it with ((void) (0)); Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com --- src/mesa/main/mtypes.h |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 749324d..5edecf2 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -3336,9 +3336,6 @@ extern int MESA_DEBUG_FLAGS; Isn't this intentional? To give some context to the patch: #ifdef DEBUG extern int MESA_VERBOSE; extern int MESA_DEBUG_FLAGS; # define MESA_FUNCTION __FUNCTION__ #else # define MESA_VERBOSE 0 # define MESA_DEBUG_FLAGS 0 # define MESA_FUNCTION a function -# ifndef NDEBUG -# define NDEBUG -# endif #endif So NDEBUG only gets defined if !DEBUG. In other words, assertions happen if you build with --enable-debug, but not in release mode (since it's extra overhead). Thanks for the explanation. I thought assertion is a must. But from your point, it's just for debug purpose. Thanks, Yuanhan Liu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GL_DEPTH_BUFFER and GL_STENCIL_BUFFER
Just noticed that the latest glext.h doesn't define DEPTH_BUFFER/STENCIL_BUFFER anymore. This is what enum.spec says: # Due to a syncing problem between the ARB_framebuffer_object extension # specification and the core API specification during development, the # following tokens were present in the .spec file for some time. They are # not actually used anywhere in the OpenGL API or extensions and have been # withdrawn (use DEPTH or STENCIL respectively, instead, as attachment # parameters to GetFramebufferAttachmentParameteriv). #DEPTH_BUFFER= 0x8223 #STENCIL_BUFFER = 0x8224 But Mesa code actually seems to do the opposite, i.e., GetFramebufferAttachmentParameteriv handles DEPTH_BUFFER but not DEPTH. The GL specs is consistent with the comment. So I think it's better to remove this. Any objects? Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] pb_bufmgr_cache: flush cache when create_buffer fails and try again
- Original Message - On Sat, Oct 8, 2011 at 1:44 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - NOTE: This is a candidate for the stable branches. --- src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c | 7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c b/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c index 58721c0..0e6896a 100644 --- a/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c +++ b/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c @@ -324,6 +324,13 @@ pb_cache_manager_create_buffer(struct pb_manager *_mgr, return NULL; buf-buffer = mgr-provider-create_buffer(mgr-provider, size, desc); This looks OK, but shouldn't we try flushing the cache first (i.e., invoke pb_cache_manager_flush) before flushing the inner buffer manager? That's what the patch does. mgr-base.flush is equal to pb_cache_manager_flush, but the function is declared later in the code, so I called it this way. I was mixing up mgr-base with mgr-provider. Looks good Marek. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GL_DEPTH_BUFFER and GL_STENCIL_BUFFER
On Sat, Oct 8, 2011 at 6:55 AM, Jose Fonseca jfons...@vmware.com wrote: Just noticed that the latest glext.h doesn't define DEPTH_BUFFER/STENCIL_BUFFER anymore. This is what enum.spec says: # Due to a syncing problem between the ARB_framebuffer_object extension # specification and the core API specification during development, the # following tokens were present in the .spec file for some time. They are # not actually used anywhere in the OpenGL API or extensions and have been # withdrawn (use DEPTH or STENCIL respectively, instead, as attachment # parameters to GetFramebufferAttachmentParameteriv). # DEPTH_BUFFER = 0x8223 # STENCIL_BUFFER = 0x8224 But Mesa code actually seems to do the opposite, i.e., GetFramebufferAttachmentParameteriv handles DEPTH_BUFFER but not DEPTH. The GL specs is consistent with the comment. So I think it's better to remove this. Any objects? Ian and I were talking off-list about this too (and he filed a spec bug w/ the ARB). I added those cases quite a while ago when the spec said x_BUFFER were the token names. Both Ian and I have patches to fix this. I thought Ian was going to post/commit his soon. Ian? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36792] [PATCH] link to shared LLVM library
https://bugs.freedesktop.org/show_bug.cgi?id=36792 --- Comment #4 from Johannes Obermayr johannesoberm...@gmx.de 2011-10-08 07:14:32 PDT --- Created an attachment (id=52118) View: https://bugs.freedesktop.org/attachment.cgi?id=52118 Review: https://bugs.freedesktop.org/review?bug=36792attachment=52118 LLVM should prefer shared libraries. Please try this patch on LLVM. It should also work if you patch /usr/bin/llvm-config (maybe other path on your system?). Then you do not have to recompile LLVM ... -- 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 1/2] Sort/Unify CFLAGS and CXXFLAGS.
--- configure.ac |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 49e81ad..942084b 100644 --- a/configure.ac +++ b/configure.ac @@ -1875,9 +1875,9 @@ dnl Restore LDFLAGS and CPPFLAGS LDFLAGS=$_SAVE_LDFLAGS CPPFLAGS=$_SAVE_CPPFLAGS -dnl Add user CFLAGS and CXXFLAGS -CFLAGS=$CFLAGS $USER_CFLAGS -CXXFLAGS=$CXXFLAGS $USER_CXXFLAGS +dnl Add user CFLAGS and CXXFLAGS and sort them +CFLAGS=`echo $CFLAGS $USER_CFLAGS|tr \n|sort -u|tr \n ` +CXXFLAGS=`echo $CXXFLAGS $USER_CXXFLAGS|tr \n|sort -u|tr \n ` dnl Substitute the config AC_CONFIG_FILES([configs/autoconf]) -- 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/2] Use USER_CFLAGS in xa state tracker and xa-vmwfx target. This is required to silence some post build warnings on openSUSE.
--- configs/autoconf.in|1 + configure.ac |1 + src/gallium/state_trackers/xa/Makefile |2 +- src/gallium/targets/xa-vmwgfx/Makefile |2 +- 4 files changed, 4 insertions(+), 2 deletions(-) diff --git a/configs/autoconf.in b/configs/autoconf.in index 9bbafc9..30d2df1 100644 --- a/configs/autoconf.in +++ b/configs/autoconf.in @@ -21,6 +21,7 @@ CFLAGS_NOVISIBILITY = @CPPFLAGS@ @CFLAGS@ \ CXXFLAGS_NOVISIBILITY = @CPPFLAGS@ @CXXFLAGS@ \ $(OPT_FLAGS) $(PIC_FLAGS) $(ARCH_FLAGS) $(DEFINES) CFLAGS = $(CFLAGS_NOVISIBILITY) @VISIBILITY_CFLAGS@ +USER_CFLAGS = @USER_CFLAGS@ CXXFLAGS = $(CXXFLAGS_NOVISIBILITY) @VISIBILITY_CXXFLAGS@ LDFLAGS = @LDFLAGS@ EXTRA_LIB_PATH = @EXTRA_LIB_PATH@ diff --git a/configure.ac b/configure.ac index 942084b..08b2ef6 100644 --- a/configure.ac +++ b/configure.ac @@ -20,6 +20,7 @@ AC_CANONICAL_HOST dnl Save user CFLAGS and CXXFLAGS so one can override the default ones USER_CFLAGS=$CFLAGS USER_CXXFLAGS=$CXXFLAGS +AC_SUBST([USER_CFLAGS]) dnl Versions for external dependencies LIBDRM_REQUIRED=2.4.24 diff --git a/src/gallium/state_trackers/xa/Makefile b/src/gallium/state_trackers/xa/Makefile index d95f938..132a181 100644 --- a/src/gallium/state_trackers/xa/Makefile +++ b/src/gallium/state_trackers/xa/Makefile @@ -32,7 +32,7 @@ OBJECTS = $(SOURCES:.c=.o) # RULES # .c.o: - $(CC) -c $(XA_CFLAGS) $(XA_INCLUDES) $ + $(CC) -c $(XA_CFLAGS) $(USER_CFLAGS) $(XA_INCLUDES) $ # TARGETS # diff --git a/src/gallium/targets/xa-vmwgfx/Makefile b/src/gallium/targets/xa-vmwgfx/Makefile index fecdba6..3761f52 100644 --- a/src/gallium/targets/xa-vmwgfx/Makefile +++ b/src/gallium/targets/xa-vmwgfx/Makefile @@ -40,7 +40,7 @@ endif # RULES # .c.o: - $(CC) -c $(XA_CFLAGS) $(XA_INCLUDES) $ + $(CC) -c $(XA_CFLAGS) $(USER_CFLAGS) $(XA_INCLUDES) $ # TARGETS # -- 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/2] Sort/Unify CFLAGS and CXXFLAGS.
- Original Message - --- configure.ac |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 49e81ad..942084b 100644 --- a/configure.ac +++ b/configure.ac @@ -1875,9 +1875,9 @@ dnl Restore LDFLAGS and CPPFLAGS LDFLAGS=$_SAVE_LDFLAGS CPPFLAGS=$_SAVE_CPPFLAGS -dnl Add user CFLAGS and CXXFLAGS -CFLAGS=$CFLAGS $USER_CFLAGS -CXXFLAGS=$CXXFLAGS $USER_CXXFLAGS +dnl Add user CFLAGS and CXXFLAGS and sort them +CFLAGS=`echo $CFLAGS $USER_CFLAGS|tr \n|sort -u|tr \n ` +CXXFLAGS=`echo $CXXFLAGS $USER_CXXFLAGS|tr \n|sort -u|tr NACK, order matters for example -O3 -O0 would be sorted as -O0 -O3 and have different meanings. Cheers Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] Use USER_CFLAGS in xa state tracker and xa-vmwfx target. This is required to silence some post build warnings on openSUSE.
- Original Message - --- configs/autoconf.in|1 + configure.ac |1 + src/gallium/state_trackers/xa/Makefile |2 +- src/gallium/targets/xa-vmwgfx/Makefile |2 +- 4 files changed, 4 insertions(+), 2 deletions(-) diff --git a/configs/autoconf.in b/configs/autoconf.in index 9bbafc9..30d2df1 100644 --- a/configs/autoconf.in +++ b/configs/autoconf.in @@ -21,6 +21,7 @@ CFLAGS_NOVISIBILITY = @CPPFLAGS@ @CFLAGS@ \ CXXFLAGS_NOVISIBILITY = @CPPFLAGS@ @CXXFLAGS@ \ $(OPT_FLAGS) $(PIC_FLAGS) $(ARCH_FLAGS) $(DEFINES) CFLAGS = $(CFLAGS_NOVISIBILITY) @VISIBILITY_CFLAGS@ +USER_CFLAGS = @USER_CFLAGS@ CXXFLAGS = $(CXXFLAGS_NOVISIBILITY) @VISIBILITY_CXXFLAGS@ LDFLAGS = @LDFLAGS@ EXTRA_LIB_PATH = @EXTRA_LIB_PATH@ diff --git a/configure.ac b/configure.ac index 942084b..08b2ef6 100644 --- a/configure.ac +++ b/configure.ac @@ -20,6 +20,7 @@ AC_CANONICAL_HOST dnl Save user CFLAGS and CXXFLAGS so one can override the default ones USER_CFLAGS=$CFLAGS USER_CXXFLAGS=$CXXFLAGS +AC_SUBST([USER_CFLAGS]) dnl Versions for external dependencies LIBDRM_REQUIRED=2.4.24 diff --git a/src/gallium/state_trackers/xa/Makefile b/src/gallium/state_trackers/xa/Makefile index d95f938..132a181 100644 --- a/src/gallium/state_trackers/xa/Makefile +++ b/src/gallium/state_trackers/xa/Makefile @@ -32,7 +32,7 @@ OBJECTS = $(SOURCES:.c=.o) # RULES # .c.o: - $(CC) -c $(XA_CFLAGS) $(XA_INCLUDES) $ + $(CC) -c $(XA_CFLAGS) $(USER_CFLAGS) $(XA_INCLUDES) $ # TARGETS # diff --git a/src/gallium/targets/xa-vmwgfx/Makefile b/src/gallium/targets/xa-vmwgfx/Makefile index fecdba6..3761f52 100644 --- a/src/gallium/targets/xa-vmwgfx/Makefile +++ b/src/gallium/targets/xa-vmwgfx/Makefile @@ -40,7 +40,7 @@ endif # RULES # .c.o: - $(CC) -c $(XA_CFLAGS) $(XA_INCLUDES) $ + $(CC) -c $(XA_CFLAGS) $(USER_CFLAGS) $(XA_INCLUDES) $ This looks good, but I'm assuming this depends on the first patch? Cheers Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] u_blitter: add integer clear support
From: Dave Airlie airl...@redhat.com
We need add a new set of fragment shader variants, along with new vertex
elements for signed and unsigned clears.
The new fragment shader variants are due to the integers values requiring
CONSTANT interpolation. The new vertex element descriptions are for passing
the clear color as an unsigned or signed integer value.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/auxiliary/util/u_blitter.c | 86 ---
src/gallium/auxiliary/util/u_blitter.h |1 +
src/gallium/drivers/r300/r300_blit.c |3 +-
src/gallium/drivers/r600/r600_blit.c |6 +-
4 files changed, 72 insertions(+), 24 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index 1500aa4..5c87489 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -68,6 +68,7 @@ struct blitter_context_priv
/* Fragment shaders. */
/* The shader at index i outputs color to color buffers 0,1,...,i-1. */
void *fs_col[PIPE_MAX_COLOR_BUFS+1];
+ void *fs_col_int[PIPE_MAX_COLOR_BUFS+1];
/* FS which outputs a color from a texture,
where the index is PIPE_TEXTURE_* to be sampled. */
@@ -88,6 +89,8 @@ struct blitter_context_priv
void *dsa_keep_depth_write_stencil;
void *velem_state;
+ void *velem_uint_state;
+ void *velem_sint_state;
/* Sampler state for clamping to a miplevel. */
void *sampler_state[PIPE_MAX_TEXTURE_LEVELS * 2];
@@ -208,6 +211,27 @@ struct blitter_context *util_blitter_create(struct
pipe_context *pipe)
}
ctx-velem_state = pipe-create_vertex_elements_state(pipe, 2, velem[0]);
+ memset(velem[0], 0, sizeof(velem[0]) * 2);
+ for (i = 0; i 2; i++) {
+ velem[i].src_offset = i * 4 * sizeof(float);
+ if (i == 0) {
+ velem[i].src_format = PIPE_FORMAT_R32G32B32A32_FLOAT;
+ } else {
+ velem[i].src_format = PIPE_FORMAT_R32G32B32A32_SINT;
+ }
+ }
+ ctx-velem_sint_state = pipe-create_vertex_elements_state(pipe, 2,
velem[0]);
+
+ memset(velem[0], 0, sizeof(velem[0]) * 2);
+ for (i = 0; i 2; i++) {
+ velem[i].src_offset = i * 4 * sizeof(float);
+ if (i == 0) {
+ velem[i].src_format = PIPE_FORMAT_R32G32B32A32_FLOAT;
+ } else {
+ velem[i].src_format = PIPE_FORMAT_R32G32B32A32_UINT;
+ }
+ }
+ ctx-velem_uint_state = pipe-create_vertex_elements_state(pipe, 2,
velem[0]);
/* fragment shaders are created on-demand */
/* vertex shader */
@@ -250,6 +274,8 @@ void util_blitter_destroy(struct blitter_context *blitter)
pipe-delete_rasterizer_state(pipe, ctx-rs_state);
pipe-delete_vs_state(pipe, ctx-vs);
pipe-delete_vertex_elements_state(pipe, ctx-velem_state);
+ pipe-delete_vertex_elements_state(pipe, ctx-velem_sint_state);
+ pipe-delete_vertex_elements_state(pipe, ctx-velem_uint_state);
for (i = 0; i PIPE_MAX_TEXTURE_TYPES; i++) {
if (ctx-fs_texfetch_col[i])
@@ -261,6 +287,8 @@ void util_blitter_destroy(struct blitter_context *blitter)
for (i = 0; i = PIPE_MAX_COLOR_BUFS; i++)
if (ctx-fs_col[i])
pipe-delete_fs_state(pipe, ctx-fs_col[i]);
+ if (ctx-fs_col_int[i])
+ pipe-delete_fs_state(pipe, ctx-fs_col_int[i]);
for (i = 0; i PIPE_MAX_TEXTURE_LEVELS * 2; i++)
if (ctx-sampler_state[i])
@@ -451,10 +479,11 @@ static void blitter_set_clear_color(struct
blitter_context_priv *ctx,
if (color) {
for (i = 0; i 4; i++) {
- ctx-vertices[i][1][0] = color-f[0];
- ctx-vertices[i][1][1] = color-f[1];
- ctx-vertices[i][1][2] = color-f[2];
- ctx-vertices[i][1][3] = color-f[3];
+ uint32_t *uiverts = (uint32_t *)ctx-vertices[i][1];
+ uiverts[0] = color-ui[0];
+ uiverts[1] = color-ui[1];
+ uiverts[2] = color-ui[2];
+ uiverts[3] = color-ui[3];
}
} else {
for (i = 0; i 4; i++) {
@@ -609,19 +638,28 @@ void **blitter_get_sampler_state(struct
blitter_context_priv *ctx,
}
static INLINE
-void *blitter_get_fs_col(struct blitter_context_priv *ctx, unsigned num_cbufs)
+void *blitter_get_fs_col(struct blitter_context_priv *ctx, unsigned num_cbufs,
+ boolean int_format)
{
struct pipe_context *pipe = ctx-base.pipe;
assert(num_cbufs = PIPE_MAX_COLOR_BUFS);
- if (!ctx-fs_col[num_cbufs])
- ctx-fs_col[num_cbufs] =
- util_make_fragment_cloneinput_shader(pipe, num_cbufs,
- TGSI_SEMANTIC_GENERIC,
- TGSI_INTERPOLATE_LINEAR);
-
- return ctx-fs_col[num_cbufs];
+ if (int_format) {
+ if (!ctx-fs_col_int[num_cbufs])
+ ctx-fs_col_int[num_cbufs] =
+util_make_fragment_cloneinput_shader(pipe, num_cbufs,
+ TGSI_SEMANTIC_GENERIC,
+
[Mesa-dev] [PATCH 1/2] softpipe: add integer support
From: Dave Airlie airl...@redhat.com
This adds support to the clear and tile caches for integer storage
and clearing, avoiding any floating paths.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/drivers/softpipe/sp_clear.c |7 +-
src/gallium/drivers/softpipe/sp_tex_tile_cache.c | 32 -
src/gallium/drivers/softpipe/sp_tex_tile_cache.h |2 +
src/gallium/drivers/softpipe/sp_tile_cache.c | 142 +-
src/gallium/drivers/softpipe/sp_tile_cache.h |7 +-
5 files changed, 146 insertions(+), 44 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_clear.c
b/src/gallium/drivers/softpipe/sp_clear.c
index bfb16be..3cb3b72 100644
--- a/src/gallium/drivers/softpipe/sp_clear.c
+++ b/src/gallium/drivers/softpipe/sp_clear.c
@@ -68,17 +68,16 @@ softpipe_clear(struct pipe_context *pipe, unsigned buffers,
for (i = 0; i softpipe-framebuffer.nr_cbufs; i++) {
struct pipe_surface *ps = softpipe-framebuffer.cbufs[i];
- util_pack_color(color-f, ps-format, uc);
- sp_tile_cache_clear(softpipe-cbuf_cache[i], color-f, uc.ui);
+ sp_tile_cache_clear(softpipe-cbuf_cache[i], color, 0);
}
}
if (buffers PIPE_CLEAR_DEPTHSTENCIL) {
- static const float zero[4] = { 0.0F, 0.0F, 0.0F, 0.0F };
+ static const union pipe_color_union zero;
struct pipe_surface *ps = softpipe-framebuffer.zsbuf;
cv = util_pack_z_stencil(ps-format, depth, stencil);
- sp_tile_cache_clear(softpipe-zsbuf_cache, zero, cv);
+ sp_tile_cache_clear(softpipe-zsbuf_cache, zero, cv);
}
softpipe-dirty_render_cache = TRUE;
diff --git a/src/gallium/drivers/softpipe/sp_tex_tile_cache.c
b/src/gallium/drivers/softpipe/sp_tex_tile_cache.c
index e589ee7..2e665c9 100644
--- a/src/gallium/drivers/softpipe/sp_tex_tile_cache.c
+++ b/src/gallium/drivers/softpipe/sp_tex_tile_cache.c
@@ -35,6 +35,7 @@
#include util/u_inlines.h
#include util/u_memory.h
#include util/u_tile.h
+#include util/u_format.h
#include util/u_math.h
#include sp_context.h
#include sp_texture.h
@@ -228,7 +229,7 @@ sp_find_cached_tile_tex(struct softpipe_tex_tile_cache *tc,
union tex_tile_address addr )
{
struct softpipe_tex_cached_tile *tile;
-
+
tile = tc-entries + tex_cache_pos( addr );
if (addr.value != tile-addr.value) {
@@ -290,15 +291,34 @@ sp_find_cached_tile_tex(struct softpipe_tex_tile_cache
*tc,
/* Get tile from the transfer (view into texture), explicitly passing
* the image format.
*/
- pipe_get_tile_rgba_format(tc-pipe,
+ if (util_format_is_pure_uint(tc-format)) {
+ pipe_get_tile_ui_format(tc-pipe,
+ tc-tex_trans,
+ addr.bits.x * TILE_SIZE,
+ addr.bits.y * TILE_SIZE,
+ TILE_SIZE,
+ TILE_SIZE,
+ tc-format,
+ (unsigned *) tile-data.colorui);
+ } else if (util_format_is_pure_sint(tc-format)) {
+ pipe_get_tile_i_format(tc-pipe,
tc-tex_trans,
-addr.bits.x * TILE_SIZE,
+addr.bits.x * TILE_SIZE,
addr.bits.y * TILE_SIZE,
TILE_SIZE,
-TILE_SIZE,
+ TILE_SIZE,
tc-format,
-(float *) tile-data.color);
-
+(int *) tile-data.colori);
+ } else {
+ pipe_get_tile_rgba_format(tc-pipe,
+ tc-tex_trans,
+ addr.bits.x * TILE_SIZE,
+ addr.bits.y * TILE_SIZE,
+ TILE_SIZE,
+ TILE_SIZE,
+ tc-format,
+ (float *) tile-data.color);
+ }
tile-addr = addr;
}
diff --git a/src/gallium/drivers/softpipe/sp_tex_tile_cache.h
b/src/gallium/drivers/softpipe/sp_tex_tile_cache.h
index 9bced37..4098aa1 100644
--- a/src/gallium/drivers/softpipe/sp_tex_tile_cache.h
+++ b/src/gallium/drivers/softpipe/sp_tex_tile_cache.h
@@ -68,6 +68,8 @@ struct softpipe_tex_cached_tile
union tex_tile_address addr;
union {
float color[TILE_SIZE][TILE_SIZE][4];
+ unsigned int colorui[TILE_SIZE][TILE_SIZE][4];
+ int colori[TILE_SIZE][TILE_SIZE][4];
} data;
};
diff --git a/src/gallium/drivers/softpipe/sp_tile_cache.c
b/src/gallium/drivers/softpipe/sp_tile_cache.c
index d3d9eb9..ad6b015 100644
--- a/src/gallium/drivers/softpipe/sp_tile_cache.c
+++ b/src/gallium/drivers/softpipe/sp_tile_cache.c
@@ -219,22 +219,43 @@ sp_tile_cache_unmap_transfers(struct
Re: [Mesa-dev] r600g shader optimization
On Sat, 2011-10-08 at 11:35 +0200, Christian König wrote: Hi Vadim, wow quite impressive, does it also contains peep-hole optimisation? Not yet, I want to create a stable framework first (conversion to the internal representation and back to the bytecode), and this is still not finished. Only some simple optimizations which are integrated in these phases are currently implemented - e.g. dead code elimination. When this task will be completed, it'll be possible to insert any optimizations in the middle, using the SSA form, def/use chains and other precomputed information, and without the need to bother about most of the hardware specific details. I tried to implement that once, but failed because I never got all the dependencies between opcodes correctly resolved. Rescheduling export instructions and setting the barrier flag of CF instructions correctly can also be quite an improvement. Currently I'm working on global scheduling, and I hope it will handle this. Just a side note in commit r600g: make some functions in r600_asm.c externally accessible you make a whole bunch of functions externally accessible, but didn't add a proper prefix like r600_ to the function name. That could led to a bit confusion when somebody else tries to hack on the code. I'll fix this, though probably I'll use some universal function to compute all instruction properties once and store them as flags, instead of using existing is_*_inst functions all over the code. Checking bank swizzles also should be done in more efficient for my code way, so I won't need check_and_set_bank_swizzles too. This commit is a temporary solution. There is a lot of such things in this code which were implemented in a quick and simple way just to check if this will work at all, it will be improved later. Vadim Regards, Christian. Am Freitag, den 07.10.2011, 18:14 +0400 schrieb Vadim Girlin: Hi, Recently I've been working on the shader optimization for r600g, and now I have the initial working implementation of simple alu scheduler and register allocator. It has no piglit regressions, though it's still a work in progress and there are known issues with some applications. I've pushed the working branch to github: https://github.com/VadimGirlin/mesa/tree/r600_shader_opt Currently it supports evergreen only, but I'm planning to make it work with other chips too. It uses struct r600_bytecode as the source, converting it to SSA-based internal representation. I'm going to implement some optimization passes at that phase, but currently it's then doing final steps - register allocation, alu scheduling, and building new bytecode. I'm attaching as an example the dump for one of the shaders in the glxgears. You could get such dump for all shaders before and after processing by setting R600_OPT_DUMP environment variable to 2. Setting this variable to 1 will only print some information for the processed shaders - size, number of gprs, and number of alu instruction groups. Vadim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 41595] New: Hi10P videos produce improper playback in gl unless yv12 is used.
https://bugs.freedesktop.org/show_bug.cgi?id=41595 Summary: Hi10P videos produce improper playback in gl unless yv12 is used. Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: erapple...@gmail.com Created an attachment (id=52128) -- (https://bugs.freedesktop.org/attachment.cgi?id=52128) gl output without yv12 I can confirm this on both Sandy Bridge and Nouveau nvc3. Kernel is 3.1-rc9, X stack is xorg-edgers. -- 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 41595] Hi10P videos produce improper output in gl unless yv12 is used.
https://bugs.freedesktop.org/show_bug.cgi?id=41595 Eric Appleman erapple...@gmail.com changed: What|Removed |Added Summary|Hi10P videos produce|Hi10P videos produce |improper playback in gl |improper output in gl |unless yv12 is used.|unless yv12 is used. -- 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 2/2] u_blitter: add integer clear support
On Sat, Oct 8, 2011 at 7:07 PM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
We need add a new set of fragment shader variants, along with new vertex
elements for signed and unsigned clears.
The new fragment shader variants are due to the integers values requiring
CONSTANT interpolation. The new vertex element descriptions are for passing
the clear color as an unsigned or signed integer value.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/auxiliary/util/u_blitter.c | 86 ---
src/gallium/auxiliary/util/u_blitter.h | 1 +
src/gallium/drivers/r300/r300_blit.c | 3 +-
src/gallium/drivers/r600/r600_blit.c | 6 +-
4 files changed, 72 insertions(+), 24 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index 1500aa4..5c87489 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -68,6 +68,7 @@ struct blitter_context_priv
/* Fragment shaders. */
/* The shader at index i outputs color to color buffers 0,1,...,i-1. */
void *fs_col[PIPE_MAX_COLOR_BUFS+1];
+ void *fs_col_int[PIPE_MAX_COLOR_BUFS+1];
/* FS which outputs a color from a texture,
where the index is PIPE_TEXTURE_* to be sampled. */
@@ -88,6 +89,8 @@ struct blitter_context_priv
void *dsa_keep_depth_write_stencil;
void *velem_state;
+ void *velem_uint_state;
+ void *velem_sint_state;
/* Sampler state for clamping to a miplevel. */
void *sampler_state[PIPE_MAX_TEXTURE_LEVELS * 2];
@@ -208,6 +211,27 @@ struct blitter_context *util_blitter_create(struct
pipe_context *pipe)
}
ctx-velem_state = pipe-create_vertex_elements_state(pipe, 2, velem[0]);
+ memset(velem[0], 0, sizeof(velem[0]) * 2);
+ for (i = 0; i 2; i++) {
+ velem[i].src_offset = i * 4 * sizeof(float);
+ if (i == 0) {
+ velem[i].src_format = PIPE_FORMAT_R32G32B32A32_FLOAT;
+ } else {
+ velem[i].src_format = PIPE_FORMAT_R32G32B32A32_SINT;
+ }
+ }
+ ctx-velem_sint_state = pipe-create_vertex_elements_state(pipe, 2,
velem[0]);
+
+ memset(velem[0], 0, sizeof(velem[0]) * 2);
+ for (i = 0; i 2; i++) {
+ velem[i].src_offset = i * 4 * sizeof(float);
+ if (i == 0) {
+ velem[i].src_format = PIPE_FORMAT_R32G32B32A32_FLOAT;
+ } else {
+ velem[i].src_format = PIPE_FORMAT_R32G32B32A32_UINT;
+ }
+ }
+ ctx-velem_uint_state = pipe-create_vertex_elements_state(pipe, 2,
velem[0]);
/* fragment shaders are created on-demand */
/* vertex shader */
@@ -250,6 +274,8 @@ void util_blitter_destroy(struct blitter_context *blitter)
pipe-delete_rasterizer_state(pipe, ctx-rs_state);
pipe-delete_vs_state(pipe, ctx-vs);
pipe-delete_vertex_elements_state(pipe, ctx-velem_state);
+ pipe-delete_vertex_elements_state(pipe, ctx-velem_sint_state);
+ pipe-delete_vertex_elements_state(pipe, ctx-velem_uint_state);
for (i = 0; i PIPE_MAX_TEXTURE_TYPES; i++) {
if (ctx-fs_texfetch_col[i])
@@ -261,6 +287,8 @@ void util_blitter_destroy(struct blitter_context *blitter)
for (i = 0; i = PIPE_MAX_COLOR_BUFS; i++)
if (ctx-fs_col[i])
pipe-delete_fs_state(pipe, ctx-fs_col[i]);
+ if (ctx-fs_col_int[i])
+ pipe-delete_fs_state(pipe, ctx-fs_col_int[i]);
I guess you wanted to enclose the loop body in { }.
With that fixed, this is:
Reviewed-by: Marek Olšák mar...@gmail.com
I wonder what happens if cb[0] is FLOAT, cb[1] is UINT, and cb[2] is SINT.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
