Re: [Mesa-dev] [PATCH 1/2] mesa: Don't validate IR trees on non-debug builds.
On 03/15/2013 12:04 PM, Eric Anholt wrote:
This was taking 5% of CPU on TF2's load time.
---
src/mesa/program/ir_to_mesa.cpp |4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 2cb5f02..ae9c0cd 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -3114,7 +3114,9 @@ _mesa_glsl_compile_shader(struct gl_context *ctx, struct
gl_shader *shader)
_mesa_ast_to_hir(shader-ir, state);
if (!state-error !shader-ir-is_empty()) {
+#ifdef DEBUG
validate_ir_tree(shader-ir);
+#endif
/* Do some optimization at compile time to reduce shader IR size
* and reduce later work if the same shader is linked multiple times
@@ -3122,7 +3124,9 @@ _mesa_glsl_compile_shader(struct gl_context *ctx, struct
gl_shader *shader)
while (do_common_optimization(shader-ir, false, false, 32))
;
+#ifdef DEBUG
validate_ir_tree(shader-ir);
+#endif
}
shader-symbols = state-symbols;
Why not just move the #ifdef DEBUG...#endif inside validate_ir_tree()
itself? The overhead of the function call is negligable compared to the
rest of compilation, and it would guarantee that we hit all current and
future cases...
But either approach gets a:
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] i965: Don't use texture swizzling to force alpha to 1.0 if unnecessary.
On 03/15/2013 04:54 PM, Eric Anholt wrote: Kenneth Graunke kenn...@whitecape.org writes: Commit 33599433c7 began setting the texture swizzle mode to XYZ1 for RED, RG, and RGB textures in order to force alpha to 1.0 in case we actually stored the texture as RGBA. This had a unforseen performance implication: the shader precompile assumes that the texture swizzle mode will be XYZW for non-shadow sampler types. By setting it to XYZ1, this means every shader used with a RED, RG, or RGB texture has to be recompiled. This is a very common case. Unfortunately, there's no way to improve the precompile, since RGBA textures still need XYZW, and there's no way to know by looking at the shader source what texture formats might be used. However, we only need to smash alpha to 1.0 if the texture's memory format actually has alpha bits. If not, the sampler already returns 1.0 for us without any special swizzling. XRGB, for example, is a very common case where this occurs. This partially fixes a performance regression since commit 33599433c7. More work is required to fully fix it in all cases. This at least helps Warsow. Now that we have MESA_FORMAT_XBGR16161616_FLOAT and company, we could potentially make this conditional just die by using those formats. Absolutely - I believe the real fix is to use XRGB formats when sampling, and ARGB formats when rendering. I'm pretty sure we have formats for all of those now. We should do that. In the meantime, this patch improves things and is simple and easily cherry-pickable... --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 59238] many new symbols in libxatracker after recent automake work
https://bugs.freedesktop.org/show_bug.cgi?id=59238 Fabio Pedretti fabio@libero.it changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Fabio Pedretti fabio@libero.it --- Patch applied: http://cgit.freedesktop.org/mesa/mesa/commit/?id=f70c3853513637fa6ed38e75f73d472a9fa61213 -- 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 59304] Meta Bug for regressions caused by automake conversion
https://bugs.freedesktop.org/show_bug.cgi?id=59304 Bug 59304 depends on bug 59238, which changed state. Bug 59238 Summary: many new symbols in libxatracker after recent automake work https://bugs.freedesktop.org/show_bug.cgi?id=59238 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 0/4] Upstream some patches from debian/ubuntu
Any objections to merge those patches? There are some further patches at [1]. Maybe someone could comment on those and tell me which patches would be accepted to merge. So far I've found out that those two patches are obsolete: 116_use_shared_galliumcore.diff 118-automake-ldrm.patch Thanks, Andreas. [1] http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=tree;f=debian/patches;hb=refs/heads/ubuntu%2B1 Andreas Boll (4): mesa: use ieee fp on s390 and m68k build: Enable x86 assembler on Hurd. osmesa: fix out-of-tree build gallium/egl: fix out-of-tree build configure.ac |2 +- src/gallium/state_trackers/egl/Makefile.am |2 +- src/mesa/drivers/osmesa/Makefile.am|1 + src/mesa/main/compiler.h |3 ++- 4 files changed, 5 insertions(+), 3 deletions(-) -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] mesa: use ieee fp on s390 and m68k
Taken from downstream: http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/patches/02_use-ieee-fp-on-s390-and-m68k.patch;h=d3d6c1d7fec3c72ecf320706167deb61c52636c3;hb=refs/heads/ubuntu%2B1 Fixes Debian bug #349437. Patch written by David Nusinow. NOTE: This is a candidate for stable branches. --- src/mesa/main/compiler.h |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h index 4871248..8b23665 100644 --- a/src/mesa/main/compiler.h +++ b/src/mesa/main/compiler.h @@ -307,8 +307,9 @@ static INLINE GLuint CPU_TO_LE32(GLuint x) * USE_IEEE: Determine if we're using IEEE floating point */ #if defined(__i386__) || defined(__386__) || defined(__sparc__) || \ -defined(__s390x__) || defined(__powerpc__) || \ +defined(__s390__) || defined(__s390x__) || defined(__powerpc__) || \ defined(__x86_64__) || \ +defined(__m68k__) || \ defined(ia64) || defined(__ia64__) || \ defined(__hppa__) || defined(hpux) || \ defined(__mips) || defined(_MIPS_ARCH) || \ -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] build: Enable x86 assembler on Hurd.
Taken from downstream: http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/patches/10-hurd-configure-tweaks.diff;h=984e17df1b8afdf8e4b36bee96aa5ab6a5691021;hb=refs/heads/ubuntu%2B1 Thanks to Pino Toscano. NOTE: This is a candidate for stable branches. --- configure.ac |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4b5b045..d0ccf5e 100644 --- a/configure.ac +++ b/configure.ac @@ -449,7 +449,7 @@ if test x$enable_asm = xyes; then case $host_cpu in i?86) case $host_os in -linux* | *freebsd* | dragonfly* | *netbsd*) +linux* | *freebsd* | dragonfly* | *netbsd* | gnu*) test x$enable_64bit = xyes asm_arch=x86_64 || asm_arch=x86 ;; esac -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] osmesa: fix out-of-tree build
Taken from downstream: http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/patches/14-fix-osmesa-build.diff;h=00581d0e1833c5492d9050e1bf3d5e658cad782e;hb=refs/heads/ubuntu%2B1 NOTE: This is a candidate for the 9.1 and 9.0 branches. --- src/mesa/drivers/osmesa/Makefile.am |1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/drivers/osmesa/Makefile.am b/src/mesa/drivers/osmesa/Makefile.am index c4b178b..0268e56 100644 --- a/src/mesa/drivers/osmesa/Makefile.am +++ b/src/mesa/drivers/osmesa/Makefile.am @@ -25,6 +25,7 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/include \ -I$(top_srcdir)/src/mapi \ -I$(top_srcdir)/src/mesa/ \ + -I$(top_builddir)/src/mapi \ $(DEFINES) \ $(API_DEFINES) AM_CFLAGS = $(PTHREAD_CFLAGS) \ -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] gallium/egl: fix out-of-tree build
Taken from downstream: http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/patches/15-fix-oot-build.diff;h=7040999a22d3937d0578cfd85ee2c71d7dc614bb;hb=refs/heads/ubuntu%2B1 NOTE: This is a candidate for the 9.1 branch. --- src/gallium/state_trackers/egl/Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/egl/Makefile.am b/src/gallium/state_trackers/egl/Makefile.am index e19e9a3..f78b36e 100644 --- a/src/gallium/state_trackers/egl/Makefile.am +++ b/src/gallium/state_trackers/egl/Makefile.am @@ -27,7 +27,7 @@ include $(top_srcdir)/src/gallium/Automake.inc AM_CFLAGS = $(GALLIUM_CFLAGS) AM_CPPFLAGS = \ -I$(top_srcdir)/src/egl/main \ - -I$(top_srcdir)/src/egl/wayland/wayland-drm/ \ + -I$(top_builddir)/src/egl/wayland/wayland-drm/ \ -I$(top_srcdir)/include noinst_LTLIBRARIES = libegl.la -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] R600: Use CONSTANT_BUFFER_0 address space for Implicit Parameters
It allows the backend to generate reads to constant cache which
are faster that VTX_READ.
---
lib/Target/R600/R600ISelLowering.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/Target/R600/R600ISelLowering.cpp
b/lib/Target/R600/R600ISelLowering.cpp
index a0e27ea..caa1899 100644
--- a/lib/Target/R600/R600ISelLowering.cpp
+++ b/lib/Target/R600/R600ISelLowering.cpp
@@ -522,7 +522,7 @@ SDValue
R600TargetLowering::LowerImplicitParameter(SelectionDAG DAG, EVT VT,
unsigned DwordOffset) const
{
unsigned ByteOffset = DwordOffset * 4;
PointerType * PtrType = PointerType::get(VT.getTypeForEVT(*DAG.getContext()),
- AMDGPUAS::PARAM_I_ADDRESS);
+ AMDGPUAS::CONSTANT_BUFFER_0);
// We shouldn't be using an offset wider than 16-bits for implicit
parameters.
assert(isInt16(ByteOffset));
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Avoid unnecessary copy when depthstencil workaround invoked by clear.
On 14 March 2013 12:38, Eric Anholt e...@anholt.net wrote:
Paul Berry stereotype...@gmail.com writes:
On 12 March 2013 16:33, Eric Anholt e...@anholt.net wrote:
Paul Berry stereotype...@gmail.com writes:
void
-brw_workaround_depthstencil_alignment(struct brw_context *brw)
+brw_workaround_depthstencil_alignment(struct brw_context *brw,
+ GLbitfield clear_mask)
{
struct intel_context *intel = brw-intel;
struct gl_context *ctx = intel-ctx;
@@ -341,10 +343,24 @@ brw_workaround_depthstencil_alignment(struct
brw_context *brw)
struct intel_mipmap_tree *stencil_mt =
get_stencil_miptree(stencil_irb);
uint32_t tile_x = 0, tile_y = 0, stencil_tile_x = 0,
stencil_tile_y
= 0;
uint32_t stencil_draw_x = 0, stencil_draw_y = 0;
+ bool invalidate_depth = clear_mask GL_DEPTH_BUFFER_BIT;
+ bool invalidate_stencil = clear_mask GL_STENCIL_BUFFER_BIT;
if (depth_irb)
depth_mt = depth_irb-mt;
+ if (depth_irb invalidate_depth
+_mesa_is_depthstencil_format(
+ _mesa_get_format_base_format(depth_mt-format))
+!depth_mt-stencil_mt) {
The only _mesa_is_depthstencil_format() returned by
_mesa_get_format_base_format() is GL_DEPTH_STENCIL, so calling that
seems kinda overkill.
Good point. I'll fix that before pushing. I'll also make a follow-up
patch to fix the function I borrowed this test from
(intel_miptree_create_layout).
If depth_mt-stencil_mt, then depth_mt-format's base format will not be
GL_DEPTH_STENCIL. I'm concerned that you're going to lose the
depth_mt-stencil_mt contents of a gl-level packed depth/stencil texture
that's backed by separate stencil.
For a separate stencil packed depth/stencil texture, mt-format will be,
for example, Z24X8, and mt-stencil_mt-format will be S8 -- see the
intel_mipmap_tree.h comment for the format field.
Thanks for carefully reviewing this, Eric. You're right, this check is
still doing the wrong thing on hardware that uses separate stencil
buffers. It turns out the reason I didn't discover this error earlier was
that my patch was completely bogus--it was using GL_DEPTH_BUFFER_BIT and
GL_STENCIL_BUFFER_BIT to check clear_mask, when in point of fact, at this
point in the code the bitmask has been converted to use BUFFER_BIT_DEPTH
and BUFFER_BIT_STENCIL. So the patch wasn't having any effect at all (and
shame on me, I should have used a breakpoint or a temporary printf to
verify that the optimization I intended was actually taking effect).
Once I had fixed both of those bugs, I discovered a third bug: it turns out
that when the invalidate flag was set, I was bypassing not only the copy,
but also the logic that associates the intel_texture_image struct to the
reallocated miptree.
V3 patch to follow. This time I've not only run it through a full piglit
run on Gen5-7, I've also verified that the copy is actually skipped in the
circumstances I intended, and there is no image corruption.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] Upstream some patches from debian/ubuntu
On 03/16/2013 06:30 AM, Andreas Boll wrote: Any objections to merge those patches? There are some further patches at [1]. Maybe someone could comment on those and tell me which patches would be accepted to merge. So far I've found out that those two patches are obsolete: 116_use_shared_galliumcore.diff 118-automake-ldrm.patch Thanks, Andreas. I'm definitely a fan of fixing things like this upstream. The patches seem sensible (well...s390...really...?), so, why not? For the series: Acked-by: Kenneth Graunke kenn...@whitecape.org Thanks for pulling these in! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Don't use texture swizzling to force alpha to 1.0 if unnecessary.
Kenneth Graunke kenn...@whitecape.org writes: On 03/15/2013 04:54 PM, Eric Anholt wrote: Kenneth Graunke kenn...@whitecape.org writes: Commit 33599433c7 began setting the texture swizzle mode to XYZ1 for RED, RG, and RGB textures in order to force alpha to 1.0 in case we actually stored the texture as RGBA. This had a unforseen performance implication: the shader precompile assumes that the texture swizzle mode will be XYZW for non-shadow sampler types. By setting it to XYZ1, this means every shader used with a RED, RG, or RGB texture has to be recompiled. This is a very common case. Unfortunately, there's no way to improve the precompile, since RGBA textures still need XYZW, and there's no way to know by looking at the shader source what texture formats might be used. However, we only need to smash alpha to 1.0 if the texture's memory format actually has alpha bits. If not, the sampler already returns 1.0 for us without any special swizzling. XRGB, for example, is a very common case where this occurs. This partially fixes a performance regression since commit 33599433c7. More work is required to fully fix it in all cases. This at least helps Warsow. Now that we have MESA_FORMAT_XBGR16161616_FLOAT and company, we could potentially make this conditional just die by using those formats. Absolutely - I believe the real fix is to use XRGB formats when sampling, and ARGB formats when rendering. I'm pretty sure we have formats for all of those now. We should do that. In the meantime, this patch improves things and is simple and easily cherry-pickable... Fair enough. Are there some big performance changes? pgpgynby9VcZq.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3] i965: Avoid unnecessary copy when depthstencil workaround invoked by clear.
Since apps typically begin rendering with a call to glClear(), it is
likely that when brw_workaround_depthstencil_alignment() moves a
miplevel to a temporary buffer, it can avoid doing a blit, since the
contents of the miplevel are about to be erased.
This patch adds the necessary plumbing to determine when
brw_workaround_depthstencil_alignment() is being called as a
consequence of glClear(), and avoids the unnecessary blit when it is
safe to do so.
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
v2: Eliminate unnecessary call to _mesa_is_depthstencil_format(). Fix
handling of depth buffer in depth/stencil format.
v3: Use correct bitfields for clear_mask. Fix handling of depth
buffer in depth/stencil format when hardware uses separate stencil.
When invalidating, make sure we still reassociate the image to the new
miptree.
---
src/mesa/drivers/dri/i965/brw_clear.c| 4 ++-
src/mesa/drivers/dri/i965/brw_context.h | 3 ++-
src/mesa/drivers/dri/i965/brw_draw.c | 2 +-
src/mesa/drivers/dri/i965/brw_misc_state.c | 31
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 +-
src/mesa/drivers/dri/intel/intel_fbo.c | 6 +++--
src/mesa/drivers/dri/intel/intel_fbo.h | 3 ++-
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 13 +++---
src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 2 +-
src/mesa/drivers/dri/intel/intel_tex_validate.c | 3 ++-
10 files changed, 52 insertions(+), 17 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
b/src/mesa/drivers/dri/i965/brw_clear.c
index cde1a06..e740f65 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -223,6 +223,8 @@ brw_clear(struct gl_context *ctx, GLbitfield mask)
{
struct brw_context *brw = brw_context(ctx);
struct intel_context *intel = brw-intel;
+ struct gl_framebuffer *fb = ctx-DrawBuffer;
+ bool partial_clear = ctx-Scissor.Enabled !noop_scissor(ctx, fb);
if (!_mesa_check_conditional_render(ctx))
return;
@@ -232,7 +234,7 @@ brw_clear(struct gl_context *ctx, GLbitfield mask)
}
intel_prepare_render(intel);
- brw_workaround_depthstencil_alignment(brw);
+ brw_workaround_depthstencil_alignment(brw, partial_clear ? 0 : mask);
if (mask BUFFER_BIT_DEPTH) {
if (brw_fast_clear_depth(ctx)) {
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 0f1d451..9f1aaf5 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1138,7 +1138,8 @@ void brw_get_depthstencil_tile_masks(struct
intel_mipmap_tree *depth_mt,
struct intel_mipmap_tree *stencil_mt,
uint32_t *out_tile_mask_x,
uint32_t *out_tile_mask_y);
-void brw_workaround_depthstencil_alignment(struct brw_context *brw);
+void brw_workaround_depthstencil_alignment(struct brw_context *brw,
+ GLbitfield clear_mask);
/*==
* brw_queryobj.c
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index e408185..809bcc5 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -439,7 +439,7 @@ static bool brw_try_draw_prims( struct gl_context *ctx,
/* This workaround has to happen outside of brw_upload_state() because it
* may flush the batchbuffer for a blit, affecting the state flags.
*/
- brw_workaround_depthstencil_alignment(brw);
+ brw_workaround_depthstencil_alignment(brw, 0);
/* Resolves must occur after updating renderbuffers, updating context state,
* and finalizing textures but before setting up any hardware state for
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 1024c42..d6bd86c 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -41,6 +41,7 @@
#include brw_defines.h
#include main/fbobject.h
+#include main/glformats.h
/* Constant single cliprect for framebuffer object or DRI2 drawing */
static void upload_drawing_rect(struct brw_context *brw)
@@ -328,7 +329,8 @@ get_stencil_miptree(struct intel_renderbuffer *irb)
}
void
-brw_workaround_depthstencil_alignment(struct brw_context *brw)
+brw_workaround_depthstencil_alignment(struct brw_context *brw,
+ GLbitfield clear_mask)
{
struct intel_context *intel = brw-intel;
struct gl_context *ctx = intel-ctx;
@@ -341,10 +343,29 @@ brw_workaround_depthstencil_alignment(struct brw_context
*brw)
struct intel_mipmap_tree *stencil_mt = get_stencil_miptree(stencil_irb);
uint32_t tile_x = 0, tile_y = 0, stencil_tile_x =
Re: [Mesa-dev] [PATCH] i965: Don't use texture swizzling to force alpha to 1.0 if unnecessary.
On 03/16/2013 10:09 AM, Eric Anholt wrote: Kenneth Graunke kenn...@whitecape.org writes: On 03/15/2013 04:54 PM, Eric Anholt wrote: Kenneth Graunke kenn...@whitecape.org writes: Commit 33599433c7 began setting the texture swizzle mode to XYZ1 for RED, RG, and RGB textures in order to force alpha to 1.0 in case we actually stored the texture as RGBA. This had a unforseen performance implication: the shader precompile assumes that the texture swizzle mode will be XYZW for non-shadow sampler types. By setting it to XYZ1, this means every shader used with a RED, RG, or RGB texture has to be recompiled. This is a very common case. Unfortunately, there's no way to improve the precompile, since RGBA textures still need XYZW, and there's no way to know by looking at the shader source what texture formats might be used. However, we only need to smash alpha to 1.0 if the texture's memory format actually has alpha bits. If not, the sampler already returns 1.0 for us without any special swizzling. XRGB, for example, is a very common case where this occurs. This partially fixes a performance regression since commit 33599433c7. More work is required to fully fix it in all cases. This at least helps Warsow. Now that we have MESA_FORMAT_XBGR16161616_FLOAT and company, we could potentially make this conditional just die by using those formats. Absolutely - I believe the real fix is to use XRGB formats when sampling, and ARGB formats when rendering. I'm pretty sure we have formats for all of those now. We should do that. In the meantime, this patch improves things and is simple and easily cherry-pickable... Fair enough. Are there some big performance changes? No, not large in terms of FPS. Generally, when we get this wrong, we recompile each shader once and then it's right from then on. It does reduce stuttering quite a bit, though, since it means we don't have to recompile on first draw. I suppose it might affect very short demos. --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/blorp: Add INTEL_DEBUG=blorp flag.
This debug flag prints out the native GEN assembly for a blitting
shader produced using BLORP. Hopefully this should be useful in
developing additional BLORP features.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 6 ++
src/mesa/drivers/dri/intel/intel_context.c | 1 +
src/mesa/drivers/dri/intel/intel_context.h | 1 +
3 files changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 37524ad..d4b1fda 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -834,6 +834,12 @@ brw_blorp_blit_program::compile(struct brw_context *brw,
* terminate the thread.
*/
render_target_write();
+
+ if (unlikely(INTEL_DEBUG DEBUG_BLORP)) {
+ printf(Native code for BLORP blit:\n);
+ brw_dump_compile(func, stdout, 0, func.next_insn_offset);
+ printf(\n);
+ }
return brw_get_program(func, program_size);
}
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 7651b46..2df70b7 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -490,6 +490,7 @@ static const struct dri_debug_control debug_control[] = {
{ aub, DEBUG_AUB },
{ shader_time, DEBUG_SHADER_TIME },
{ no16, DEBUG_NO16 },
+ { blorp, DEBUG_BLORP },
{ NULL,0 }
};
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index 5a49603..2df15d4 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -438,6 +438,7 @@ extern int INTEL_DEBUG;
#define DEBUG_CLIP 0x200
#define DEBUG_AUB 0x400
#define DEBUG_SHADER_TIME 0x800
+#define DEBUG_BLORP 0x1000
#define DEBUG_NO16 0x2000
#ifdef HAVE_ANDROID_PLATFORM
--
1.8.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] build: Enable x86 assembler on Hurd.
On Sat, Mar 16, 2013 at 6:30 AM, Andreas Boll andreas.boll@gmail.com wrote: Taken from downstream: http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/patches/10-hurd-configure-tweaks.diff;h=984e17df1b8afdf8e4b36bee96aa5ab6a5691021;hb=refs/heads/ubuntu%2B1 Thanks to Pino Toscano. NOTE: This is a candidate for stable branches. --- configure.ac |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4b5b045..d0ccf5e 100644 --- a/configure.ac +++ b/configure.ac @@ -449,7 +449,7 @@ if test x$enable_asm = xyes; then case $host_cpu in i?86) case $host_os in -linux* | *freebsd* | dragonfly* | *netbsd*) +linux* | *freebsd* | dragonfly* | *netbsd* | gnu*) test x$enable_64bit = xyes asm_arch=x86_64 || asm_arch=x86 ;; esac -- 1.7.10.4 But don't bother with x86_64? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/blorp: Add INTEL_DEBUG=blorp flag.
On Sat, Mar 16, 2013 at 10:37 AM, Paul Berry stereotype...@gmail.com wrote:
This debug flag prints out the native GEN assembly for a blitting
shader produced using BLORP. Hopefully this should be useful in
developing additional BLORP features.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 6 ++
src/mesa/drivers/dri/intel/intel_context.c | 1 +
src/mesa/drivers/dri/intel/intel_context.h | 1 +
3 files changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 37524ad..d4b1fda 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -834,6 +834,12 @@ brw_blorp_blit_program::compile(struct brw_context *brw,
* terminate the thread.
*/
render_target_write();
+
+ if (unlikely(INTEL_DEBUG DEBUG_BLORP)) {
+ printf(Native code for BLORP blit:\n);
+ brw_dump_compile(func, stdout, 0, func.next_insn_offset);
+ printf(\n);
+ }
return brw_get_program(func, program_size);
}
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 7651b46..2df70b7 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -490,6 +490,7 @@ static const struct dri_debug_control debug_control[] = {
{ aub, DEBUG_AUB },
{ shader_time, DEBUG_SHADER_TIME },
{ no16, DEBUG_NO16 },
+ { blorp, DEBUG_BLORP },
{ NULL,0 }
};
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index 5a49603..2df15d4 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -438,6 +438,7 @@ extern int INTEL_DEBUG;
#define DEBUG_CLIP 0x200
#define DEBUG_AUB 0x400
#define DEBUG_SHADER_TIME 0x800
+#define DEBUG_BLORP 0x1000
#define DEBUG_NO16 0x2000
#ifdef HAVE_ANDROID_PLATFORM
--
1.8.2
Useful!
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/blorp: Add INTEL_DEBUG=blorp flag.
On 03/16/2013 10:37 AM, Paul Berry wrote:
This debug flag prints out the native GEN assembly for a blitting
shader produced using BLORP. Hopefully this should be useful in
developing additional BLORP features.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 6 ++
src/mesa/drivers/dri/intel/intel_context.c | 1 +
src/mesa/drivers/dri/intel/intel_context.h | 1 +
3 files changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 37524ad..d4b1fda 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -834,6 +834,12 @@ brw_blorp_blit_program::compile(struct brw_context *brw,
* terminate the thread.
*/
render_target_write();
+
+ if (unlikely(INTEL_DEBUG DEBUG_BLORP)) {
+ printf(Native code for BLORP blit:\n);
+ brw_dump_compile(func, stdout, 0, func.next_insn_offset);
+ printf(\n);
+ }
return brw_get_program(func, program_size);
}
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 7651b46..2df70b7 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -490,6 +490,7 @@ static const struct dri_debug_control debug_control[] = {
{ aub, DEBUG_AUB },
{ shader_time, DEBUG_SHADER_TIME },
{ no16, DEBUG_NO16 },
+ { blorp, DEBUG_BLORP },
{ NULL,0 }
};
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index 5a49603..2df15d4 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -438,6 +438,7 @@ extern int INTEL_DEBUG;
#define DEBUG_CLIP 0x200
#define DEBUG_AUB 0x400
#define DEBUG_SHADER_TIME 0x800
+#define DEBUG_BLORP 0x1000
#define DEBUG_NO16 0x2000
#ifdef HAVE_ANDROID_PLATFORM
A great idea. I guess you must've manually hacked in debugging each
time you needed to look at it before...
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] i965/blorp: Add INTEL_DEBUG=blorp flag.
On Sat, Mar 16, 2013 at 10:37 AM, Paul Berry stereotype...@gmail.com wrote:
This debug flag prints out the native GEN assembly for a blitting
shader produced using BLORP. Hopefully this should be useful in
developing additional BLORP features.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 6 ++
src/mesa/drivers/dri/intel/intel_context.c | 1 +
src/mesa/drivers/dri/intel/intel_context.h | 1 +
3 files changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 37524ad..d4b1fda 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -834,6 +834,12 @@ brw_blorp_blit_program::compile(struct brw_context *brw,
* terminate the thread.
*/
render_target_write();
+
+ if (unlikely(INTEL_DEBUG DEBUG_BLORP)) {
+ printf(Native code for BLORP blit:\n);
+ brw_dump_compile(func, stdout, 0, func.next_insn_offset);
+ printf(\n);
+ }
return brw_get_program(func, program_size);
}
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 7651b46..2df70b7 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -490,6 +490,7 @@ static const struct dri_debug_control debug_control[] = {
{ aub, DEBUG_AUB },
{ shader_time, DEBUG_SHADER_TIME },
{ no16, DEBUG_NO16 },
+ { blorp, DEBUG_BLORP },
{ NULL,0 }
};
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index 5a49603..2df15d4 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -438,6 +438,7 @@ extern int INTEL_DEBUG;
#define DEBUG_CLIP 0x200
#define DEBUG_AUB 0x400
#define DEBUG_SHADER_TIME 0x800
+#define DEBUG_BLORP 0x1000
#define DEBUG_NO16 0x2000
#ifdef HAVE_ANDROID_PLATFORM
--
1.8.2
Thanks for this feature.
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 62425] New: Crash in vbo_save_playback_vertex_list when using glCallList in Cairo-Dock
https://bugs.freedesktop.org/show_bug.cgi?id=62425 Priority: medium Bug ID: 62425 Assignee: mesa-dev@lists.freedesktop.org Summary: Crash in vbo_save_playback_vertex_list when using glCallList in Cairo-Dock Severity: normal Classification: Unclassified OS: All Reporter: matt...@gmail.com Hardware: Other Status: NEW Version: 9.0 Component: Mesa core Product: Mesa Created attachment 76630 -- https://bugs.freedesktop.org/attachment.cgi?id=76630action=edit gdb: info registrers Hello, Firstly, thank you for developing Mesa! How to reproduce this bug: * Launch Cairo-Dock * Check that you're using the 'Rotate' animation: right click on the dock / Cairo-Dock / Settings / Advanced Mode / Taskbar / Interaction / Highlight applications demanding your attention with an animation: = Rotate * Add a subdock (right click on the dock / Cairo-Dock / Add / Subdock) * Add a launcher on this subdock (e.g. by dragging and dropping Firefox launcher from the menu) * Launch this command to animate Firefox: $ dbus-send --session --dest=org.cairodock.CairoDock /org/cairodock/CairoDock org.cairodock.CairoDock.DemandsAttention boolean:true string:default string:class=firefox * Open the subdock * Cairo-Dock will crash Note: or choose the 'Rotate' animation when the mouse is hover icons and open a subdock. Here is the backtrace of this crash: #0 vbo_save_playback_vertex_list (ctx=0xcbde30, data=0x48ddc20) at ../../../../../src/mesa/vbo/vbo_save_draw.c:264 node = 0x48ddc20 save = 0xd1d6d8 remap_vertex_store = 0 '\000' #1 0x7fffe4859702 in ext_opcode_execute (node=0x48ddc18, ctx=0xcbde30) at ../../../../../src/mesa/main/dlist.c:619 i = optimized out #2 execute_list (ctx=0xcbde30, list=optimized out) at ../../../../../src/mesa/main/dlist.c:7695 opcode = optimized out dlist = 0x48ddc18 n = 0x48ddc18 done = optimized out #3 0x7fffe485d142 in _mesa_CallList (list=3) at ../../../../../src/mesa/main/dlist.c:9137 save_compile_flag = 0 '\000' ctx = 0xcbde30 #4 0x7fffd6a8d507 in cd_animation_render_capsule (pIcon=optimized out, pDock=optimized out, bInvisibleBackground=optimized out) at /opt/cairo-dock_bzr/cairo-dock-plug-ins/Animated-icons/src/applet-rotation.c:97 No locals. #5 _draw_rotating_icon (pIcon=0x10d0310, pDock=0xcbd1d0, fScaleFactor=1, pData=optimized out, pData=optimized out) at /opt/cairo-dock_bzr/cairo-dock-plug-ins/Animated-icons/src/applet-rotation.c:222 No locals. #6 0x7fffd6a8d919 in render (pIcon=0x10d0310, pDock=0xcbd1d0, pData=0x5172890, pCairoContext=optimized out) at /opt/cairo-dock_bzr/cairo-dock-plug-ins/Animated-icons/src/applet-rotation.c:266 fAlpha = 1 #7 0x7fffd6a8f7d5 in cd_animations_render_icon ( pUserData=optimized out, pIcon=0x10d0310, pDock=0xcbd1d0, bHasBeenRendered=0x7fffce20, pCairoContext=0x0) at /opt/cairo-dock_bzr/cairo-dock-plug-ins/Animated-icons/src/applet-notifications.c:243 pData = 0x5172890 pCurrentAnimation = optimized out pAnimation = 0x118aec0 a = 0x49ca660 #8 0x76547a0a in cairo_dock_render_one_icon_opengl ( icon=icon@entry=0x10d0310, pDock=pDock@entry=0xcbd1d0, fDockMagnitude=fDockMagnitude@entry=1, bUseText=bUseText@entry=0) at /opt/cairo-dock_bzr/cairo-dock-core/src/gldit/cairo-dock-draw-opengl.c:380 pNotificationRecord = optimized out pElement = optimized out pNextElement = 0x7a2140 pNotificationRecordList = optimized out _stop = optimized out pNotificationsTab = optimized out _bStop = 0 _obj = optimized out fRatio = 1.25 __PRETTY_FUNCTION__ = cairo_dock_render_one_icon_opengl fX = 43 fY = 0.34432 bIconHasBeenDrawn = 0 #9 0x7fffd6001bbf in cd_rendering_render_parabole_opengl (pDock=0xcbd1d0) at /opt/cairo-dock_bzr/cairo-dock-plug-ins/dock-rendering/src/rendering-parabole.c:729 pFirstDrawnElement = 0xa10960 fDockMagnitude = 1 fAlpha = 0.00010018 bHorizontal = 1 icon = 0x10d0310 ic = 0xa10960 #10 0x76525d48 in cairo_dock_render_dock_notification ( pUserData=0xcbde30, pDock=0xcbd1d0, pCairoContext=0xd19f90) at /opt/cairo-dock_bzr/cairo-dock-core/src/gldit/cairo-dock-callbacks.c:166 No locals. #11 0x76525ed9 in cairo_dock_on_expose (pWidget=optimized out, ctx=optimized out, pDock=0xcbd1d0) at /opt/cairo-dock_bzr/cairo-dock-core/src/gldit/cairo-dock-callbacks.c:224 pNotificationRecord = optimized out pElement = optimized out pNextElement = 0x0 pNotificationRecordList = optimized out _stop = optimized out pNotificationsTab = optimized out
