Re: [Mesa-dev] [PATCH] i965: Flush batchbuffer containing the query on glQueryCounter.
Hi Kenneth, D'oh. Thanks :) Reviewed-by: Kenneth Graunke kenn...@whitecape.org Cc: mesa-sta...@lists.freedesktop.org Thanks for the review and pushed! Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/fs: Correct mistake in determining whether a MUL is negated.
a * b is equivalent to -a * -b, and the previous code was failing at
that.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89961
---
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
index f2c4098..c1d0616 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
@@ -145,7 +145,7 @@ operands_match(const fs_inst *a, const fs_inst *b, bool
*negate)
xs[1].fixed_hw_reg.dw1.f = xs1_imm;
ys[1].fixed_hw_reg.dw1.f = ys1_imm;
- *negate = (xs0_negate + xs1_negate) != (ys0_negate + ys1_negate);
+ *negate = (xs0_negate != xs1_negate) != (ys0_negate != ys1_negate);
return ret;
} else if (!a-is_commutative()) {
bool match = true;
--
2.0.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Flush batchbuffer containing the query on glQueryCounter.
Hi, On Sunday, April 12, 2015 10:29:57 Matt Turner wrote: In the future, instead of putting this in the commit message itself, use git send-email --annotate and put it below the --- Commentary below --- won't be put into the git log when you git am the patch. Ok, I try to remember this when I have any next patch! Thanks! Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Always use Y-tiled buffers on SKL+
On Mon, Apr 13, 2015 at 04:31:29PM +0200, Daniel Vetter wrote: On Sat, Apr 11, 2015 at 01:16:11PM -0700, Ben Widawsky wrote: Starting with Skylake, the display engine is capable of scanning out from Y-tiled buffers. As such, we can and should use Y-tiling for better efficiency. Note that the buffer allocation done for mipmaps will already never allocate an X-tiled buffer for GEN9. Signed-off-by: Ben Widawsky b...@bwidawsk.net You need a recent enough ddx to make use of Y-tiled buffers, which atm still doesn't yet exist. This would at least need some kind of handshake with the compositor to make sure it understands this, presuming I didn't miss something. You can send Y-tiled buffers to the DDX. The problem is that the kernel won't allow us to display them and so we will (and always have been) copying from them. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 86701] [regression] weston-simple-egl not running anymore inside qemu
https://bugs.freedesktop.org/show_bug.cgi?id=86701 --- Comment #13 from Daniel Stone dan...@fooishbar.org --- Two reasons why VGEM is less helpful on Wayland than X11: - MIT-SHM on X forces you to allocate out of POSIX/SysV (forget which) SHM regions, i.e. shmat() and friends; this is not true of wl_shm, which lets you specify an arbitrary fd, as long as it's mmap()able - MIT-SHM requires you to schedule a server-side copy out of the SHM Image to a Drawable (Pixmap or Window), whereas DRI2 adds the notion of flips and exchanging storage; this is not true of wl_shm, as the wl_surface/wl_buffer model natively supports buffer exchange So I think just the relatively obvious wl_shm approach - which is less divergent from the existing platform_wayland.c code than platform_x11's, given that it shares the same buffer-surface relationship, only diverging at buffer allocation - will do just fine. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] gallium/ttn: add support for texture offsets
On Mon, Apr 13, 2015 at 1:34 PM, Eric Anholt e...@anholt.net wrote:
Rob Clark robdcl...@gmail.com writes:
From: Rob Clark robcl...@freedesktop.org
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 9d988b06..c9f9e03 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -982,7 +982,7 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
struct tgsi_full_instruction *tgsi_inst = c-token-FullInstruction;
nir_tex_instr *instr;
nir_texop op;
- unsigned num_srcs, samp = 1;
+ unsigned num_srcs, samp = 1, i;
switch (tgsi_inst-Instruction.Opcode) {
case TGSI_OPCODE_TEX:
@@ -1026,6 +1026,8 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
num_srcs++;
}
+ num_srcs += tgsi_inst-Texture.NumOffsets;
+
instr = nir_tex_instr_create(b-shader, num_srcs);
instr-op = op;
@@ -1103,6 +1105,32 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
src_number++;
}
+ for (i = 0; i tgsi_inst-Texture.NumOffsets; i++) {
+ struct tgsi_texture_offset *tex_offset = tgsi_inst-TexOffsets[i];
+ /* since TexOffset ins't using tgsi_full_src_register we get to
+ * do some extra gymnastics:
+ */
+ nir_alu_src src;
+
+ memset(src, 0, sizeof(src));
+
+ src.src = ttn_src_for_file_and_index(c,
+ tex_offset-File,
+ tex_offset-Index,
+ NULL);
+
+ src.swizzle[0] = tex_offset-SwizzleX;
+ src.swizzle[1] = tex_offset-SwizzleY;
+ src.swizzle[2] = tex_offset-SwizzleZ;
+ src.swizzle[3] = TGSI_SWIZZLE_W;
+
+ nir_ssa_def *off = nir_fmov_alu(b, src, instr-coord_components);
For a cubemap array, won't coord_components be 4, but you only want a
3-component value as the offset? I'm suspicious of this fixed SWIZZLE_W
here. If you move the .src_type setting above this, you could use
nir_tex_instr_src_size(instr, src_number) to get the right number of
components.
When are offsets on cubemaps supported? The real question is what will
coord_components be for a 2darray -- if it's 2, then this is fine, if
it's 3, then it needs fixing.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 86701] [regression] weston-simple-egl not running anymore inside qemu
https://bugs.freedesktop.org/show_bug.cgi?id=86701 --- Comment #12 from Daniel Stone dan...@fooishbar.org --- (In reply to Marek Olšák from comment #11) Is it the EGL_WL_bind_wayland_display extension that you'd like to have or something else? I'd like to understand exactly what is missing. Client-side support for swrast in src/egl/drivers/dri2/platform_wayland.c. platform_x11.c has a whole section (see dri2_initialize_x11_swrast) with alternate codepaths to support swrast. platform_wayland totally lacks this, so not only does $LIBGL_ALWAYS_SOFTWARE do nothing, but on Wayland servers lacking hardware GL support (e.g. EGL_WL_bind_wayland_display), there is no fallback to the wl_shm interface. Implementing this is the minimum requirement. Supporting swrast-on-VGEM (EGL_WL_bind_wayland_display support when running on swrast; client-side support for allocating VGEM backing buffers for swrast) would also allow us to cut down on alternate codepaths a little, but probably doesn't buy us too much. -- 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] glsl-1.10: new test for a special case in glsl-to-tgsi
From: Marek Olšák marek.ol...@amd.com
---
.../glsl-1.10/execution/uniform-update.shader_test | 50 ++
1 file changed, 50 insertions(+)
create mode 100644 tests/spec/glsl-1.10/execution/uniform-update.shader_test
diff --git a/tests/spec/glsl-1.10/execution/uniform-update.shader_test
b/tests/spec/glsl-1.10/execution/uniform-update.shader_test
new file mode 100644
index 000..be6d61d
--- /dev/null
+++ b/tests/spec/glsl-1.10/execution/uniform-update.shader_test
@@ -0,0 +1,50 @@
+# Use 4 uniforms and gl_FragCoord (which adds a mesa state parameter) and see
+# if the uniform storage was updated after reallocating the parameter list.
+
+[require]
+GLSL = 1.10
+
+[vertex shader]
+#version 110
+
+void main()
+{
+ gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
+}
+
+[fragment shader]
+#version 110
+
+uniform float zero0, zero1, zero2;
+uniform float u;
+
+void main()
+{
+gl_FragColor = u + zero0 * gl_FragCoord + zero1 + zero2;
+}
+
+[test]
+uniform float zero0 0
+uniform float zero1 0
+uniform float zero2 0
+uniform float u 0.3
+
+clear color 0.0 0.0 0.0 0.0
+clear
+ortho
+
+draw rect 0 0 50 50
+
+uniform float u 0.4
+draw rect 50 0 50 50
+
+uniform float u 0.5
+draw rect 100 0 50 50
+
+uniform float u 0.6
+draw rect 150 0 50 50
+
+probe rgb 25 25 0.3 0.3 0.3
+probe rgb 75 25 0.4 0.4 0.4
+probe rgb 125 25 0.5 0.5 0.5
+probe rgb 175 25 0.6 0.6 0.6
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] configure.ac: add --enable-assertions
From: Marek Olšák marek.ol...@amd.com --- configure.ac | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 6ccf3b4..f5eeb7d 100644 --- a/configure.ac +++ b/configure.ac @@ -402,6 +402,13 @@ AC_ARG_ENABLE([debug], [enable_debug=$enableval], [enable_debug=no] ) +AC_ARG_ENABLE([assertions], +[AS_HELP_STRING([--enable-assertions], +[add debug definitions to enable assertions and other debug checks @:@default=disabled@:@])], +[enable_assertions=$enableval], +[enable_assertions=no] +) + if test x$enable_debug = xyes; then DEFINES=$DEFINES -DDEBUG if test x$GCC = xyes; then @@ -420,8 +427,10 @@ if test x$enable_debug = xyes; then CXXFLAGS=$CXXFLAGS -O0 fi fi +elif test x$enable_assertions = xyes; then +DEFINES=$DEFINES -DDEBUG else - DEFINES=$DEFINES -DNDEBUG +DEFINES=$DEFINES -DNDEBUG fi dnl -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] configure.ac: print LLVM_LDFLAGS
From: Marek Olšák marek.ol...@amd.com --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index 9e8c1d8..6ccf3b4 100644 --- a/configure.ac +++ b/configure.ac @@ -2543,6 +2543,7 @@ if test x$MESA_LLVM = x1; then echo LLVM_CFLAGS: $LLVM_CFLAGS echo LLVM_CXXFLAGS: $LLVM_CXXFLAGS echo LLVM_CPPFLAGS: $LLVM_CPPFLAGS +echo LLVM_LDFLAGS:$LLVM_LDFLAGS echo fi echo PYTHON2: $PYTHON2 -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] radeon/llvm: Improve codegen for KILL_IF
Rather than emitting one kill instruction per component of KILL_IF's src
reg, we now or the components of the src register together and use the
result as a condition for just one kill instruction.
shader-db stats (bonaire):
979 shaders
Totals:
SGPRS: 34872 - 34848 (-0.07 %)
VGPRS: 20696 - 20676 (-0.10 %)
Code Size: 749032 - 748452 (-0.08 %) bytes
LDS: 11 - 11 (0.00 %) blocks
Scratch: 12288 - 12288 (0.00 %) bytes per wave
Totals from affected shaders:
SGPRS: 1184 - 1160 (-2.03 %)
VGPRS: 600 - 580 (-3.33 %)
Code Size: 13200 - 12620 (-4.39 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
Increases:
SGPRS: 2 (0.00 %)
VGPRS: 0 (0.00 %)
Code Size: 0 (0.00 %)
LDS: 0 (0.00 %)
Scratch: 0 (0.00 %)
Decreases:
SGPRS: 5 (0.01 %)
VGPRS: 5 (0.01 %)
Code Size: 25 (0.03 %)
LDS: 0 (0.00 %)
Scratch: 0 (0.00 %)
*** BY PERCENTAGE ***
Max Increase:
SGPRS: 32 - 40 (25.00 %)
VGPRS: 0 - 0 (0.00 %)
Code Size: 0 - 0 (0.00 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
Max Decrease:
SGPRS: 32 - 24 (-25.00 %)
VGPRS: 16 - 12 (-25.00 %)
Code Size: 116 - 96 (-17.24 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
*** BY UNIT ***
Max Increase:
SGPRS: 64 - 72 (12.50 %)
VGPRS: 0 - 0 (0.00 %)
Code Size: 0 - 0 (0.00 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
Max Decrease:
SGPRS: 32 - 24 (-25.00 %)
VGPRS: 16 - 12 (-25.00 %)
Code Size: 424 - 356 (-16.04 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
---
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 29 ++
1 file changed, 29 insertions(+)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 91c56a3..18afbcb 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -637,6 +637,34 @@ static void uif_emit(
if_cond_emit(action, bld_base, emit_data, cond);
}
+static void kill_if_fetch_args(
+ struct lp_build_tgsi_context * bld_base,
+ struct lp_build_emit_data * emit_data)
+{
+ const struct tgsi_full_instruction * inst = emit_data-inst;
+ struct gallivm_state *gallivm = bld_base-base.gallivm;
+ LLVMBuilderRef builder = gallivm-builder;
+ unsigned i;
+ LLVMValueRef conds[TGSI_NUM_CHANNELS];
+
+ for (i = 0; i TGSI_NUM_CHANNELS; i++) {
+ LLVMValueRef value = lp_build_emit_fetch(bld_base, inst, 0, i);
+ conds[i] = LLVMBuildFCmp(builder, LLVMRealOLT, value,
+ bld_base-base.zero, );
+ }
+
+ /* Or the conditions together */
+ for (i = TGSI_NUM_CHANNELS - 1; i 0; i--) {
+ conds[i - 1] = LLVMBuildOr(builder, conds[i], conds[i - 1], );
+ }
+
+ emit_data-dst_type = LLVMVoidTypeInContext(gallivm-context);
+ emit_data-arg_count = 1;
+ emit_data-args[0] = LLVMBuildSelect(builder, conds[0],
+ lp_build_const_float(gallivm, -1.0f),
+ bld_base-base.zero, );
+}
+
static void kil_emit(
const struct lp_build_tgsi_action * action,
struct lp_build_tgsi_context * bld_base,
@@ -1467,6 +1495,7 @@ void radeon_llvm_context_init(struct radeon_llvm_context
* ctx)
bld_base-op_actions[TGSI_OPCODE_ISLT].emit = emit_icmp;
bld_base-op_actions[TGSI_OPCODE_ISSG].emit = emit_ssg;
bld_base-op_actions[TGSI_OPCODE_I2F].emit = emit_i2f;
+ bld_base-op_actions[TGSI_OPCODE_KILL_IF].fetch_args =
kill_if_fetch_args;
bld_base-op_actions[TGSI_OPCODE_KILL_IF].emit = kil_emit;
bld_base-op_actions[TGSI_OPCODE_KILL_IF].intr_name =
llvm.AMDGPU.kill;
bld_base-op_actions[TGSI_OPCODE_KILL].emit = lp_build_tgsi_intrinsic;
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] radeon/llvm: Run LLVM's instruction combining pass
This should improve code quality in general and will help with some future changes to how we emit kill instructions. shader-db shows a few regressions, but these don't seem to be the result of deficiencies in instcombine. They're mostly caused by the scheduler making different decisions than before. shader-db stats (bonaire): 979 shaders Totals: SGPRS: 35056 - 34872 (-0.52 %) VGPRS: 20624 - 20696 (0.35 %) Code Size: 764372 - 749032 (-2.01 %) bytes LDS: 11 - 11 (0.00 %) blocks Scratch: 12288 - 12288 (0.00 %) bytes per wave Totals from affected shaders: SGPRS: 13264 - 13072 (-1.45 %) VGPRS: 8248 - 8316 (0.82 %) Code Size: 486320 - 470992 (-3.15 %) bytes LDS: 11 - 11 (0.00 %) blocks Scratch: 11264 - 11264 (0.00 %) bytes per wave Increases: SGPRS: 6 (0.01 %) VGPRS: 20 (0.02 %) Code Size: 14 (0.01 %) LDS: 0 (0.00 %) Scratch: 0 (0.00 %) Decreases: SGPRS: 32 (0.03 %) VGPRS: 8 (0.01 %) Code Size: 244 (0.25 %) LDS: 0 (0.00 %) Scratch: 0 (0.00 %) *** BY PERCENTAGE *** Max Increase: SGPRS: 32 - 48 (50.00 %) VGPRS: 12 - 20 (66.67 %) Code Size: 216 - 224 (3.70 %) bytes LDS: 0 - 0 (0.00 %) blocks Scratch: 0 - 0 (0.00 %) bytes per wave Max Decrease: SGPRS: 40 - 32 (-20.00 %) VGPRS: 16 - 12 (-25.00 %) Code Size: 368 - 280 (-23.91 %) bytes LDS: 0 - 0 (0.00 %) blocks Scratch: 0 - 0 (0.00 %) bytes per wave *** BY UNIT *** Max Increase: SGPRS: 32 - 48 (50.00 %) VGPRS: 28 - 36 (28.57 %) Code Size: 39320 - 40132 (2.07 %) bytes LDS: 0 - 0 (0.00 %) blocks Scratch: 0 - 0 (0.00 %) bytes per wave Max Decrease: SGPRS: 72 - 64 (-11.11 %) VGPRS: 48 - 40 (-16.67 %) Code Size: 6272 - 5852 (-6.70 %) bytes LDS: 0 - 0 (0.00 %) blocks Scratch: 0 - 0 (0.00 %) bytes per wave --- src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c index 1690194..91c56a3 100644 --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c @@ -1579,6 +1579,7 @@ void radeon_llvm_finalize_module(struct radeon_llvm_context * ctx) LLVMAddLICMPass(gallivm-passmgr); LLVMAddAggressiveDCEPass(gallivm-passmgr); LLVMAddCFGSimplificationPass(gallivm-passmgr); + LLVMAddInstructionCombiningPass(gallivm-passmgr); /* Run the pass */ LLVMRunFunctionPassManager(gallivm-passmgr, ctx-main_fn); -- 2.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] radeonsi: Add header and footer to shader stat dump
This makes it easier to parse. --- src/gallium/drivers/radeonsi/si_shader.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_shader.c b/src/gallium/drivers/radeonsi/si_shader.c index b4709ac..89f02ab 100644 --- a/src/gallium/drivers/radeonsi/si_shader.c +++ b/src/gallium/drivers/radeonsi/si_shader.c @@ -2669,8 +2669,10 @@ int si_shader_binary_read(struct si_screen *sscreen, binary-code[i]); } } - fprintf(stderr, SGPRS: %d\nVGPRS: %d\nCode Size: %d bytes\nLDS: %d blocks\n - Scratch: %d bytes per wave\n, + + fprintf(stderr, *** SHADER STATS ***\n + SGPRS: %d\nVGPRS: %d\nCode Size: %d bytes\nLDS: %d blocks\n + Scratch: %d bytes per wave\n\n, shader-num_sgprs, shader-num_vgprs, binary-code_size, shader-lds_size, shader-scratch_bytes_per_wave); } -- 2.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl-1.10: new test for a special case in glsl-to-tgsi
Sorry, wrong mailing list.
Marek
On Mon, Apr 13, 2015 at 7:59 PM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
---
.../glsl-1.10/execution/uniform-update.shader_test | 50
++
1 file changed, 50 insertions(+)
create mode 100644 tests/spec/glsl-1.10/execution/uniform-update.shader_test
diff --git a/tests/spec/glsl-1.10/execution/uniform-update.shader_test
b/tests/spec/glsl-1.10/execution/uniform-update.shader_test
new file mode 100644
index 000..be6d61d
--- /dev/null
+++ b/tests/spec/glsl-1.10/execution/uniform-update.shader_test
@@ -0,0 +1,50 @@
+# Use 4 uniforms and gl_FragCoord (which adds a mesa state parameter) and see
+# if the uniform storage was updated after reallocating the parameter list.
+
+[require]
+GLSL = 1.10
+
+[vertex shader]
+#version 110
+
+void main()
+{
+ gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
+}
+
+[fragment shader]
+#version 110
+
+uniform float zero0, zero1, zero2;
+uniform float u;
+
+void main()
+{
+gl_FragColor = u + zero0 * gl_FragCoord + zero1 + zero2;
+}
+
+[test]
+uniform float zero0 0
+uniform float zero1 0
+uniform float zero2 0
+uniform float u 0.3
+
+clear color 0.0 0.0 0.0 0.0
+clear
+ortho
+
+draw rect 0 0 50 50
+
+uniform float u 0.4
+draw rect 50 0 50 50
+
+uniform float u 0.5
+draw rect 100 0 50 50
+
+uniform float u 0.6
+draw rect 150 0 50 50
+
+probe rgb 25 25 0.3 0.3 0.3
+probe rgb 75 25 0.4 0.4 0.4
+probe rgb 125 25 0.5 0.5 0.5
+probe rgb 175 25 0.6 0.6 0.6
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89018] Civilization: Beyond Earth terrain section not rendered
https://bugs.freedesktop.org/show_bug.cgi?id=89018 --- Comment #14 from Sami Liedes sami.lie...@iki.fi --- I grepped the game executable for any of the 159 extensions which are either available in Mesa but not in fglrx or the other way round, since it's obvious something (maybe the presence or lack of an extension?) makes CivBE behave different on fglrx and mesa. Not sure how much this helps narrow things down, but here's a list of the interesting (different availability on the two drivers) extensions mentioned in the executable. I think next I'm going to try and disable stuff selectively, or perhaps make mesa advertise some extension it doesn't have, to see how that affects the game. Available in mesa, but not in fglrx: GLX_EXT_create_context_es2_profile GL_EXT_stencil_two_side GL_NV_texture_rectangle Available in fglrx, but not in mesa: GLX_EXT_swap_control GL_ARB_geometry_shader4 GL_ARB_gpu_shader5 GL_ARB_imaging GL_EXT_bindable_uniform GL_EXT_geometry_shader4 GL_EXT_gpu_shader4 GL_NV_half_float -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] nir: Fix bug in handling non-SSA copy prop of indirect register access.
Patches 1 and 2 are
Reviewed-by: Connor Abbott cwabbo...@gmail.com
Adding stricter assertions for tex sources makes sense to me now after
some thought/discussion, but if we're going to do it then we should go
all the way and make intrinsic srcs and dests and if srcs more strict
as well. Also, maybe you've done this already, but especially after
doing that we should piglit i965 since it uses a different path to
generate NIR -- I wouldn't expect any regressions though.
Connor
On Mon, Apr 13, 2015 at 4:36 PM, Eric Anholt e...@anholt.net wrote:
The intention was to not copy propagate this source (which has some
variable access), but instead copy propagate its variable offset value.
---
src/glsl/nir/nir_opt_copy_propagate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/nir/nir_opt_copy_propagate.c
b/src/glsl/nir/nir_opt_copy_propagate.c
index ee78e5a..027143e 100644
--- a/src/glsl/nir/nir_opt_copy_propagate.c
+++ b/src/glsl/nir/nir_opt_copy_propagate.c
@@ -154,7 +154,7 @@ copy_prop_src(nir_src *src, nir_instr *parent_instr,
nir_if *parent_if)
{
if (!src-is_ssa) {
if (src-reg.indirect)
- return copy_prop_src(src, parent_instr, parent_if);
+ return copy_prop_src(src-reg.indirect, parent_instr, parent_if);
return false;
}
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/12] nir: Rewrite instr_rewrite_src
The old code wasn't correctly handling the case where the new value of the
source contains an indirect.
---
src/glsl/nir/nir.c | 52
1 file changed, 28 insertions(+), 24 deletions(-)
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index a7ee361..4cc074b 100644
--- a/src/glsl/nir/nir.c
+++ b/src/glsl/nir/nir.c
@@ -1860,33 +1860,37 @@ src_does_not_use_reg(nir_src *src, void *void_reg)
void
nir_instr_rewrite_src(nir_instr *instr, nir_src *src, nir_src new_src)
{
- if (src-is_ssa) {
- nir_ssa_def *old_ssa = src-ssa;
- *src = new_src;
- if (old_ssa nir_foreach_src(instr, src_does_not_use_def, old_ssa)) {
- struct set_entry *entry = _mesa_set_search(old_ssa-uses, instr);
- assert(entry);
- _mesa_set_remove(old_ssa-uses, entry);
- }
- } else {
- if (src-reg.indirect)
- nir_instr_rewrite_src(instr, src-reg.indirect, new_src);
-
- nir_register *old_reg = src-reg.reg;
- *src = new_src;
- if (old_reg nir_foreach_src(instr, src_does_not_use_reg, old_reg)) {
- struct set_entry *entry = _mesa_set_search(old_reg-uses, instr);
- assert(entry);
- _mesa_set_remove(old_reg-uses, entry);
+ nir_src old_src = *src;
+ *src = new_src;
+
+ for (nir_src *iter_src = old_src; iter_src;
+iter_src = iter_src-is_ssa ? NULL : iter_src-reg.indirect) {
+ if (iter_src-is_ssa) {
+ nir_ssa_def *ssa = iter_src-ssa;
+ if (ssa nir_foreach_src(instr, src_does_not_use_def, ssa)) {
+struct set_entry *entry = _mesa_set_search(ssa-uses, instr);
+assert(entry);
+_mesa_set_remove(ssa-uses, entry);
+ }
+ } else {
+ nir_register *reg = iter_src-reg.reg;
+ if (reg nir_foreach_src(instr, src_does_not_use_reg, reg)) {
+struct set_entry *entry = _mesa_set_search(reg-uses, instr);
+assert(entry);
+_mesa_set_remove(reg-uses, entry);
+ }
}
}
- if (new_src.is_ssa) {
- if (new_src.ssa)
- _mesa_set_add(new_src.ssa-uses, instr);
- } else {
- if (new_src.reg.reg)
- _mesa_set_add(new_src.reg.reg-uses, instr);
+ for (nir_src *iter_src = new_src; iter_src;
+iter_src = iter_src-is_ssa ? NULL : iter_src-reg.indirect) {
+ if (iter_src-is_ssa) {
+ if (iter_src-ssa)
+_mesa_set_add(iter_src-ssa-uses, instr);
+ } else {
+ if (iter_src-reg.reg)
+_mesa_set_add(iter_src-reg.reg-uses, instr);
+ }
}
}
--
2.3.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 14/12] nir/lower_source_mods: Don't propagate register sources
The nir_lower_source_mods pass does a weak form of copy propagation to
clean up all of the mov-with-negate's that get generated. However, we
weren't properly checking that the sources were SSA and so we could end up
moving a register read which is not, in general, valid.
---
src/glsl/nir/nir_lower_to_source_mods.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/glsl/nir/nir_lower_to_source_mods.c
b/src/glsl/nir/nir_lower_to_source_mods.c
index d6bf77f..7b4a0f6 100644
--- a/src/glsl/nir/nir_lower_to_source_mods.c
+++ b/src/glsl/nir/nir_lower_to_source_mods.c
@@ -67,6 +67,13 @@ nir_lower_to_source_mods_block(nir_block *block, void *state)
continue;
}
+ /* We can only do a rewrite if the source we are copying is SSA.
+ * Otherwise, moving the read might invalidly reorder reads/writes
+ * on a register.
+ */
+ if (!parent-src[0].src.is_ssa)
+continue;
+
nir_instr_rewrite_src(instr, alu-src[i].src, parent-src[0].src);
if (alu-src[i].abs) {
/* abs trumps both neg and abs, do nothing */
--
2.3.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix 32bit compilation with -Werror=implicit-function-declaration
On Monday 13 April 2015 21:26:32 Pali Rohár wrote: File glapi_entrypoint.c calls memcpy() function, but does not include string.h header. So compilation can fail at error: implicit declaration of function 'memcpy'. --- src/mapi/glapi/glapi_entrypoint.c 2015-04-13 21:11:09.0 +0200 +++ src/mapi/glapi/glapi_entrypoint.c 2015-04-13 21:11:55.284118513 +0200 @@ -33,6 +33,7 @@ #include glapi/glapi_priv.h #include u_execmem.h +#include string.h #ifdef USE_X86_ASM This problem is caused by commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=9fbbd60c1da4467683d93540c64164ad337ce454 which removes #include string.h from glapi_priv.h file. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Fix 32bit compilation with -Werror=implicit-function-declaration
File glapi_entrypoint.c calls memcpy() function, but does not include string.h header. So compilation can fail at error: implicit declaration of function 'memcpy'. --- src/mapi/glapi/glapi_entrypoint.c 2015-04-13 21:11:09.0 +0200 +++ src/mapi/glapi/glapi_entrypoint.c 2015-04-13 21:11:55.284118513 +0200 @@ -33,6 +33,7 @@ #include glapi/glapi_priv.h #include u_execmem.h +#include string.h #ifdef USE_X86_ASM -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: extend GLSLSkipStrictMaxUniformLimitCheck to uniform block size
On Mon, Apr 13, 2015 at 02:17:24PM -0700, Ian Romanick wrote:
On 04/11/2015 09:48 AM, Marcin Ślusarz wrote:
ARB_uniform_buffer_object spec says:
The total amount of buffer object storage available for any given uniform
block is subject to an implementation-dependent limit; the maximum amount
of available space, in basic machine units, can be queried by calling
GetIntegerv with the constant MAX_UNIFORM_BLOCK_SIZE. If the amount
of storage required for a uniform block exceeds this limit, a program may
fail to link.
Fixes these piglit tests:
spec@arb_uniform_buffer_object@maxuniformblocksize@fsexceed
spec@arb_uniform_buffer_object@maxuniformblocksize@vsexceed
on nouveau/gk107.
Can you elaborate on how this fixes the test?
Yeah
The fsexceed and vsexceed tests are supposed to pass if linking fails.
Currently *exceed tests fail on nouveau because shader can't calculate
expected values. With this patch linking fails
(GLSLSkipStrictMaxUniformLimitCheck
is false on nouveau), allowing tests to pass.
---
src/glsl/linker.cpp | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 85830e6..88a4548 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2308,6 +2308,25 @@ check_resources(struct gl_context *ctx, struct
gl_shader_program *prog)
_mesa_shader_stage_to_string(i));
}
}
+
+ for (unsigned j = 0; j sh-NumUniformBlocks; ++j) {
+ if (sh-UniformBlocks[j].UniformBufferSize
+ ctx-Const.MaxUniformBlockSize) {
+if (ctx-Const.GLSLSkipStrictMaxUniformLimitCheck) {
+ linker_warning(prog,
+ %s shader uses uniform block whose size
exceeds
+ MAX_UNIFORM_BLOCK_SIZE, but the driver will
try
+ to optimize them out; this is non-portable
+ out-of-spec behaviour\n,
+ _mesa_shader_stage_to_string(i));
+} else {
+ linker_error(prog,
+%s shader uses uniform block whose size
exceeds
+MAX_UNIFORM_BLOCK_SIZE\n,
+_mesa_shader_stage_to_string(i));
+}
+ }
+ }
}
unsigned blocks[MESA_SHADER_STAGES] = {0};
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] Hash-table and hash-set, V4
On Sat, Apr 11, 2015 at 4:25 PM, Thomas Helland thomashellan...@gmail.com wrote: The performance numbers (shader-db runtime) are: Difference at 95.0% confidence -14.7608 +/- 3.36786 -9.05064% +/- 2.06501% (Original runtime was 160 seconds) Good Work! I had one comment on the hash set patch. With that fixed, the series is Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com Probably want to give Eric a a couple of days to look at it too. While the profile data looked promising for increasing the table size we start with, decreasing load factor, and integer hashing, there seems to be no benefit to shader-db runtime. Therefore I have dropped these from the series. Thomas Helland (3): util/tests: Expand collision test for hash table util: Change hash_table to use quadratic probing util: Change util/set to use quadratic probing src/util/hash_table.c | 102 + src/util/hash_table.h | 3 +- src/util/set.c| 118 -- src/util/set.h| 3 +- src/util/tests/hash_table/collision.c | 14 5 files changed, 89 insertions(+), 151 deletions(-) -- 2.3.4 ___ 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] i965/fs: Correct mistake in determining whether a MUL is negated.
On Mon, Apr 13, 2015 at 1:11 PM, Matt Turner matts...@gmail.com wrote:
a * b is equivalent to -a * -b, and the previous code was failing at
that.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89961
---
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
index f2c4098..c1d0616 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
@@ -145,7 +145,7 @@ operands_match(const fs_inst *a, const fs_inst *b,
bool *negate)
xs[1].fixed_hw_reg.dw1.f = xs1_imm;
ys[1].fixed_hw_reg.dw1.f = ys1_imm;
- *negate = (xs0_negate + xs1_negate) != (ys0_negate + ys1_negate);
+ *negate = (xs0_negate != xs1_negate) != (ys0_negate != ys1_negate);
return ret;
} else if (!a-is_commutative()) {
bool match = true;
--
2.0.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
Re: [Mesa-dev] [PATCH] glx: Allow to create any OpenGL ES version.
On 04/10/2015 04:57 PM, Chad Versace wrote:
On Fri 10 Apr 2015, Jose Fonseca wrote:
From: José Fonseca jfons...@vmware.com
The latest version of GLX_EXT_create_context_es2_profile states:
If the version requested is a valid and supported OpenGL-ES version,
and the GLX_CONTEXT_ES_PROFILE_BIT_EXT bit is set in the
GLX_CONTEXT_PROFILE_MASK_ARB attribute (see below), then the context
returned will implement the OpenGL ES version requested.
We must also export EXT_create_context_es_profile too, as
EXT_create_context_es2_profile specification is crystal clear:
NOTE: implementations of this extension must export BOTH extension
strings, for backwards compatibility with applications written
against version 1 of this extension.
Totally untested. (Just happened to noticed this while implementing
GLX_EXT_create_context_es2_profile for st/xlib.)
Reviewed-by: Brian Paul bri...@vmware.com
Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
v2: Replicate the drisw_glx.c to dri2_glx.c and dri3_glx.c as suggested
by Emil Velikov.
---
src/glx/dri2_glx.c | 5 -
src/glx/dri3_glx.c | 5 -
src/glx/dri_common.c | 32
src/glx/drisw_glx.c | 2 ++
4 files changed, 26 insertions(+), 18 deletions(-)
Jose, you also need to add the extensions to the extension table in
glxextensions.c. Otherwise, __glXEnableDirectExtension() fails to find
and enable the extensions.
Also, Ian has a strange hack for es2_profile
__glXCalculateUsableExtensions that I don't understand, but probably
needs replicating for es_profile.
I tried to explain the situation in the cooment. :( In order to use
GLX_EXT_create_context_es2_profile, you have to use functions that were
added with GLX_ARB_create_context_profile. The ARB extension depends on
both client and server support, but the EXT only depends on client
support. So, if the client says it supports both the ARB and EXT but
the server does not support the ARB, we would say that
GLX_EXT_create_context_es2_profile, and that would be a lie.
That bit of code just disables GLX_EXT_create_context_es2_profile when
GLX_ARB_create_context_profile is not fully supported.
Your assertion that a similar change is necessary for the new extension
string is correct. Good catch. :)
I applied the diff below on top of your patch, and glxinfo began
correctly advertising your extensions. Even with that diff, it's still
broken though. I tested it with waffle 1.5.0 as below:
[chadv@daring mesa]$ wflinfo -p glx -a gles1
Waffle error: 0x2 WAFFLE_ERROR_UNKNOWN: glXCreateContextAttribsARB
failed
[chadv@daring mesa]$ wflinfo -p glx -a gles2
Waffle platform: glx
Waffle api: gles2
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell
GT2)
OpenGL version string: OpenGL ES 3.0 Mesa 10.6.0-devel (git-cd130b3)
[chadv@daring mesa]$ wflinfo -p glx -a gles3
Waffle error: 0x2 WAFFLE_ERROR_UNKNOWN: glXCreateContextAttribsARB
failed
diff --git a/src/glx/glxextensions.c b/src/glx/glxextensions.c
index ce5d66d..8f2f194 100644
--- a/src/glx/glxextensions.c
+++ b/src/glx/glxextensions.c
@@ -84,6 +84,7 @@ static const struct extension_info
known_glx_extensions[] = {
{ GLX(EXT_visual_rating), VER(0,0), Y, Y, N, N },
{ GLX(EXT_fbconfig_packed_float), VER(0,0), Y, Y, N, N },
{ GLX(EXT_framebuffer_sRGB),VER(0,0), Y, Y, N, N },
+ { GLX(EXT_create_context_es_profile), VER(0,0), Y, N, N, Y },
{ GLX(EXT_create_context_es2_profile), VER(0,0), Y, N, N, Y },
{ GLX(MESA_copy_sub_buffer),VER(0,0), Y, N, N, N },
{ GLX(MESA_multithread_makecurrent),VER(0,0), Y, N, Y, N },
@@ -628,12 +629,13 @@ __glXCalculateUsableExtensions(struct glx_screen *
psc,
}
/* This hack is necessary because GLX_ARB_create_context_profile
depends on
-* server support, but GLX_EXT_create_context_es2_profile is
direct-only.
-* Without this hack, it would be possible to advertise
-* GLX_EXT_create_context_es2_profile without
+* server support, but GLX_EXT_create_context_es2_profile and
es_profile is
+* direct-only. Without this hack, it would be possible to advertise
+* GLX_EXT_create_context_es2_profile and es_profile without
* GLX_ARB_create_context_profile. That would be a problem.
*/
if (!IS_SET(server_support, ARB_create_context_profile_bit)) {
+ CLR_BIT(usable, EXT_create_context_es_profile_bit);
CLR_BIT(usable, EXT_create_context_es2_profile_bit);
}
diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
index 37e4ccc..3618127 100644
--- a/src/glx/glxextensions.h
+++ b/src/glx/glxextensions.h
@@ -45,6 +45,7 @@ enum
EXT_import_context_bit,
EXT_framebuffer_sRGB_bit,
EXT_fbconfig_packed_float_bit,
+ EXT_create_context_es_profile_bit,
EXT_create_context_es2_profile_bit,
MESA_copy_sub_buffer_bit,
[Mesa-dev] [PATCH 3/4] nir: Validate that tex_instr src components are the right size.
---
src/glsl/nir/nir_validate.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
index a7aa798..d7ba374 100644
--- a/src/glsl/nir/nir_validate.c
+++ b/src/glsl/nir/nir_validate.c
@@ -97,6 +97,16 @@ typedef struct {
static void validate_src(nir_src *src, validate_state *state);
static void
+validate_src_components(nir_src *src, int num_components)
+{
+ if (src-is_ssa) {
+ assert(num_components = src-ssa-num_components);
+ } else if (!src-reg.reg-is_packed) {
+ assert(num_components = src-reg.reg-num_components);
+ }
+}
+
+static void
validate_reg_src(nir_reg_src *src, validate_state *state)
{
assert(src-reg != NULL);
@@ -361,13 +371,8 @@ validate_intrinsic_instr(nir_intrinsic_instr *instr,
validate_state *state)
assert(components_read 0);
- if (instr-src[i].is_ssa) {
- assert(components_read = instr-src[i].ssa-num_components);
- } else if (!instr-src[i].reg.reg-is_packed) {
- assert(components_read = instr-src[i].reg.reg-num_components);
- }
-
validate_src(instr-src[i], state);
+ validate_src_components(instr-src[i], components_read);
}
if (nir_intrinsic_infos[instr-intrinsic].has_dest) {
@@ -423,6 +428,8 @@ validate_tex_instr(nir_tex_instr *instr, validate_state
*state)
assert(!src_type_seen[instr-src[i].src_type]);
src_type_seen[instr-src[i].src_type] = true;
validate_src(instr-src[i].src, state);
+ validate_src_components(instr-src[i].src,
+ nir_tex_instr_src_size(instr, i));
}
if (instr-sampler != NULL)
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] nir: Fix bug in handling non-SSA copy prop of indirect register access.
The intention was to not copy propagate this source (which has some
variable access), but instead copy propagate its variable offset value.
---
src/glsl/nir/nir_opt_copy_propagate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/nir/nir_opt_copy_propagate.c
b/src/glsl/nir/nir_opt_copy_propagate.c
index ee78e5a..027143e 100644
--- a/src/glsl/nir/nir_opt_copy_propagate.c
+++ b/src/glsl/nir/nir_opt_copy_propagate.c
@@ -154,7 +154,7 @@ copy_prop_src(nir_src *src, nir_instr *parent_instr, nir_if
*parent_if)
{
if (!src-is_ssa) {
if (src-reg.indirect)
- return copy_prop_src(src, parent_instr, parent_if);
+ return copy_prop_src(src-reg.indirect, parent_instr, parent_if);
return false;
}
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] gallium/ttn: Validate our shader after we generate it.
There's a bunch of lovely code to sanity-check us in ways that we might not catch immediately (or as obviously) through piglit fails, so let's use it. --- src/gallium/auxiliary/nir/tgsi_to_nir.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c b/src/gallium/auxiliary/nir/tgsi_to_nir.c index 9d988b06..43f070c 100644 --- a/src/gallium/auxiliary/nir/tgsi_to_nir.c +++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c @@ -1656,6 +1656,8 @@ tgsi_to_nir(const void *tgsi_tokens, ttn_add_output_stores(c); + nir_validate_shader(s); + ralloc_free(c); return s; } -- 2.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] nir: Validate that the tex_instr dest is the right size.
---
src/glsl/nir/nir_validate.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
index d7ba374..2c80e44 100644
--- a/src/glsl/nir/nir_validate.c
+++ b/src/glsl/nir/nir_validate.c
@@ -107,6 +107,16 @@ validate_src_components(nir_src *src, int num_components)
}
static void
+validate_dest_components(nir_dest *dest, int num_components)
+{
+ if (dest-is_ssa) {
+ assert(num_components = dest-ssa.num_components);
+ } else if (!dest-reg.reg-is_packed) {
+ assert(num_components = dest-reg.reg-num_components);
+ }
+}
+
+static void
validate_reg_src(nir_reg_src *src, validate_state *state)
{
assert(src-reg != NULL);
@@ -383,13 +393,8 @@ validate_intrinsic_instr(nir_intrinsic_instr *instr,
validate_state *state)
assert(components_written 0);
- if (instr-dest.is_ssa) {
- assert(components_written = instr-dest.ssa.num_components);
- } else if (!instr-dest.reg.reg-is_packed) {
- assert(components_written = instr-dest.reg.reg-num_components);
- }
-
validate_dest(instr-dest, state);
+ validate_dest_components(instr-dest, components_written);
}
unsigned num_vars = nir_intrinsic_infos[instr-intrinsic].num_variables;
@@ -434,6 +439,8 @@ validate_tex_instr(nir_tex_instr *instr, validate_state
*state)
if (instr-sampler != NULL)
validate_deref_var(instr, instr-sampler, state);
+
+ validate_dest_components(instr-dest, nir_tex_instr_dest_size(instr));
}
static void
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH shader-db 1/5] run.c: Use computed value of max_threads
---
run.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/run.c b/run.c
index 414f21d..a9d370d 100644
--- a/run.c
+++ b/run.c
@@ -477,7 +477,7 @@ main(int argc, char **argv)
if (signal(SIGSEGV, abort_handler) == SIG_ERR)
fprintf(stderr, WARNING: could not install SIGSEGV handler.\n);
-#pragma omp parallel if(shader_test_length omp_get_max_threads())
+#pragma omp parallel if(shader_test_length max_threads)
{
const char *current_shader_name;
unsigned shaders_compiled = 0;
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH shader-db 3/5] run.c: Add -1 option for disabling multi-threading
---
run.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/run.c b/run.c
index 3027004..8dc1be0 100644
--- a/run.c
+++ b/run.c
@@ -276,7 +276,9 @@ const struct platform platforms[] = {
void print_usage(const char *prog_name)
{
fprintf(stderr,
-Usage: %s [-p platform] directories and *.shader_test
files\n,
+Usage: %s [-p platform] directories and *.shader_test files\n
+Other options: \n
+ -1Disable multi-threading\n,
prog_name);
}
@@ -286,7 +288,9 @@ main(int argc, char **argv)
int opt;
-while((opt = getopt(argc, argv, p:)) != -1) {
+max_threads = omp_get_max_threads();
+
+while((opt = getopt(argc, argv, 1p:)) != -1) {
switch(opt) {
case 'p': {
const struct platform *platform = NULL;
@@ -309,6 +313,9 @@ main(int argc, char **argv)
setenv(INTEL_DEVID_OVERRIDE, platform-pci_id, 1);
break;
}
+ case '1':
+ max_threads = 1;
+ break;
default:
fprintf(stderr, Unknown option: %x\n, opt);
print_usage(argv[0]);
@@ -487,7 +494,6 @@ main(int argc, char **argv)
ftw(argv[i], gather_shader_test, 100);
}
-max_threads = omp_get_max_threads();
current_shader_names = calloc(max_threads, sizeof(const char *));
if (signal(SIGABRT, abort_handler) == SIG_ERR)
@@ -495,7 +501,7 @@ main(int argc, char **argv)
if (signal(SIGSEGV, abort_handler) == SIG_ERR)
fprintf(stderr, WARNING: could not install SIGSEGV handler.\n);
-#pragma omp parallel if(shader_test_length max_threads)
+#pragma omp parallel if(max_threads 1 shader_test_length
max_threads)
{
const char *current_shader_name;
unsigned shaders_compiled = 0;
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH shader-db 4/5] Add si-report.py for parsing dumps from radeonsi
---
si-report.py | 324 +++
1 file changed, 324 insertions(+)
create mode 100755 si-report.py
diff --git a/si-report.py b/si-report.py
new file mode 100755
index 000..fbeed11
--- /dev/null
+++ b/si-report.py
@@ -0,0 +1,324 @@
+#!/usr/bin/env python
+# vim: set expandtab tabstop=4 softtabstop=4 shiftwidth=4: */
+#
+# Copyright 2015 Advanced Micro Devices, Inc.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the Software),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+#
+
+import re
+import sys
+
+def format_float(f, suffix = ' %'):
+return {0:0.2f}{1}.format(f, suffix)
+
+def get_str(value, suffix = ' %'):
+if type(value) == float:
+return format_float(value, suffix)
+else:
+return value
+
+def get_value_str(value, prefix, suffix):
+space = ' '
+if len(suffix) == 0:
+space = ''
+return {}: {}{}{}\n.format(prefix, get_str(value), space, suffix)
+
+def get_sgpr_str(value, suffixes = True):
+return get_value_str(value, 'SGPRS', '')
+
+def get_vgpr_str(value, suffixes = True):
+return get_value_str(value, 'VGPRS', '')
+
+def get_code_size_str(value, suffixes = True):
+suffix = ''
+if suffixes:
+suffix = 'bytes'
+return get_value_str(value, 'Code Size', suffix)
+
+def get_lds_str(value, suffixes = True):
+suffix = ''
+if suffixes:
+suffix = 'blocks'
+return get_value_str(value, 'LDS', suffix)
+
+def get_scratch_str(value, suffixes = True):
+suffix = ''
+if suffixes:
+suffix = 'bytes per wave'
+return get_value_str(value, 'Scratch', suffix)
+
+def calculate_percent_change(b, a):
+if b == 0:
+return 0
+return 100 * float(a - b) / float(b)
+
+def cmp_max_unit(current, comp):
+return comp[0] current[0]
+
+def cmp_min_unit(current, comp):
+return comp[0] current[0]
+
+def cmp_max_per(current, comp):
+return calculate_percent_change(comp[1], comp[2])
calculate_percent_change(current[1], current[2])
+
+def cmp_min_per(current, comp):
+return calculate_percent_change(comp[1], comp[2])
calculate_percent_change(current[1], current[2])
+
+class si_stats:
+def __init__(self):
+self.sgprs = 0
+self.vgprs = 0
+self.code_size = 0
+self.lds = 0
+self.scratch = 0
+
+
+def to_string(self, suffixes = True):
+return {}{}{}{}{}.format(
+get_sgpr_str(self.sgprs, suffixes),
+get_vgpr_str(self.vgprs, suffixes),
+get_code_size_str(self.code_size, suffixes),
+get_lds_str(self.lds, suffixes),
+get_scratch_str(self.scratch, suffixes))
+
+
+def __str__(self):
+return self.to_string()
+
+def add(self, other):
+self.sgprs += other.sgprs
+self.vgprs += other.vgprs
+self.code_size += other.code_size
+self.lds += other.lds
+self.scratch += other.scratch
+
+def update(self, comp, cmp_fn):
+for name in self.__dict__.keys():
+current = self.__dict__[name]
+if type(current) != tuple:
+current = (0, 0, 0)
+if cmp_fn(current, comp.__dict__[name]):
+self.__dict__[name] = comp.__dict__[name]
+
+def update_max(self, comp):
+for name in self.__dict__.keys():
+current = self.__dict__[name]
+if type(current) == tuple:
+current = self.__dict__[name][0]
+if comp.__dict__[name][0] current:
+self.__dict__[name] = comp.__dict__[name]
+
+def update_min(self, comp):
+for name in self.__dict__.keys():
+current = self.__dict__[name]
+if type(current) == tuple:
+current = self.__dict__[name][0]
+if comp.__dict__[name][0] current:
+self.__dict__[name] = comp.__dict__[name]
+
+def update_increase(self, comp):
+for name in
[Mesa-dev] [PATCH shader-db 5/5] README: Add instructions for radeonsi
--- README | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/README b/README index 4e09937..adb970c 100644 --- a/README +++ b/README @@ -4,7 +4,7 @@ A giant pile of shaders from various apps, for whatever purpose. In particular, we use it to capture assembly output of the shader compiler for analysis of regressions in compiler behavior. -Currently it supports Mesa's i965 driver only. +Currently it supports Mesa's i965 and radeonsi drivers. === Capturing shaders === env MESA_GLSL=dump appname | tee log @@ -13,6 +13,8 @@ env MESA_GLSL=dump appname | tee log # complete. $EDITOR shaders/appname/* +=== i965 Usage === + === Running shaders === ./run shaders 2 err | tee new-run @@ -30,6 +32,19 @@ to run. === Analysis === ./report.py old-run new-run + +=== radeonsi Usage === + +=== Running shaders === + +ST_DEBUG=precompile R600_DEBUG=ps,vs,gs,precompile ./run shaders -1 2 new-run + +-1 option for disabling multi-threading is required to avoid garbled shader dumps. + +=== Analysis === +./si-report.py old-run new-run + + === Dependencies === run requires some GNU C extensions, render nodes (/dev/dri/renderD128), libepoxy, OpenMP, and Mesa configured with --with-egl-platforms=x11,drm -- 2.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH shader-db 2/5] run.c: Use getopt for argument parsing
---
run.c | 62 --
1 file changed, 40 insertions(+), 22 deletions(-)
diff --git a/run.c b/run.c
index a9d370d..3027004 100644
--- a/run.c
+++ b/run.c
@@ -1,6 +1,7 @@
/* vim: set expandtab tabstop=4 softtabstop=4 shiftwidth=4: */
/*
* Copyright © 2014 Intel Corporation
+ * Copyright © 2015 Advanced Micro Devices, Inc.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the Software),
@@ -272,35 +273,52 @@ const struct platform platforms[] = {
bdw, 0x162E,
};
+void print_usage(const char *prog_name)
+{
+fprintf(stderr,
+Usage: %s [-p platform] directories and *.shader_test
files\n,
+prog_name);
+}
+
int
main(int argc, char **argv)
{
-if (argc = 2 strcmp(argv[1], -p) == 0) {
-const struct platform *platform;
-for (unsigned i = 0; i ARRAY_SIZE(platforms); i++) {
-if (strcmp(argv[2], platforms[i].name) == 0) {
-platform = platforms + i;
-break;
+
+int opt;
+
+while((opt = getopt(argc, argv, p:)) != -1) {
+switch(opt) {
+case 'p': {
+const struct platform *platform = NULL;
+for (unsigned i = 0; i ARRAY_SIZE(platforms); i++) {
+if (strcmp(optarg, platforms[i].name) == 0) {
+platform = platforms + i;
+break;
+}
}
-}
-if (platform == NULL) {
-fprintf(stderr, Invalid platform.\nValid platforms are:);
-for (unsigned i = 0; i ARRAY_SIZE(platforms); i++)
-fprintf(stderr, %s, platforms[i].name);
-fprintf(stderr, \n);
+if (platform == NULL) {
+fprintf(stderr, Invalid platform.\nValid platforms are:);
+for (unsigned i = 0; i ARRAY_SIZE(platforms); i++)
+fprintf(stderr, %s, platforms[i].name);
+fprintf(stderr, \n);
+return -1;
+}
+
+printf(### Compiling for %s ###\n, platform-name);
+setenv(INTEL_DEVID_OVERRIDE, platform-pci_id, 1);
+break;
+}
+default:
+fprintf(stderr, Unknown option: %x\n, opt);
+print_usage(argv[0]);
return -1;
}
-
-printf(### Compiling for %s ###\n, platform-name);
-setenv(INTEL_DEVID_OVERRIDE, platform-pci_id, 1);
-argv += 2;
-argc -= 2;
}
-if (unlikely(argc 2)) {
-fprintf(stderr, Usage: %s [-p platform] directories and
*.shader_test files\n,
-argv[0]);
+if (unlikely(optind = argc)) {
+fprintf(stderr, No directories specified\n);
+print_usage(argv[0]);
return -1;
}
@@ -312,7 +330,7 @@ main(int argc, char **argv)
if (!client_extensions) {
fprintf(stderr, ERROR: Missing EGL_EXT_client_extensions\n);
return -1;
-}
+}
if (!strstr(client_extensions, EGL_MESA_platform_gbm)) {
fprintf(stderr, ERROR: Missing EGL_MESA_platform_gbm\n);
@@ -465,7 +483,7 @@ main(int argc, char **argv)
}
shader_test = malloc(shader_test_size * sizeof(struct shader_test));
-for (int i = 1; i argc; i++) {
+for (int i = optind; i argc; i++) {
ftw(argv[i], gather_shader_test, 100);
}
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] radeon/llvm: Improve codegen for KILL_IF
For the series:
Reviewed-by: Marek Olšák marek.ol...@amd.com
I assume you tested piglit, because I remember there had been some
crashes with the instruction combining pass and the kill instruction.
Marek
On Mon, Apr 13, 2015 at 8:21 PM, Tom Stellard thomas.stell...@amd.com wrote:
Rather than emitting one kill instruction per component of KILL_IF's src
reg, we now or the components of the src register together and use the
result as a condition for just one kill instruction.
shader-db stats (bonaire):
979 shaders
Totals:
SGPRS: 34872 - 34848 (-0.07 %)
VGPRS: 20696 - 20676 (-0.10 %)
Code Size: 749032 - 748452 (-0.08 %) bytes
LDS: 11 - 11 (0.00 %) blocks
Scratch: 12288 - 12288 (0.00 %) bytes per wave
Totals from affected shaders:
SGPRS: 1184 - 1160 (-2.03 %)
VGPRS: 600 - 580 (-3.33 %)
Code Size: 13200 - 12620 (-4.39 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
Increases:
SGPRS: 2 (0.00 %)
VGPRS: 0 (0.00 %)
Code Size: 0 (0.00 %)
LDS: 0 (0.00 %)
Scratch: 0 (0.00 %)
Decreases:
SGPRS: 5 (0.01 %)
VGPRS: 5 (0.01 %)
Code Size: 25 (0.03 %)
LDS: 0 (0.00 %)
Scratch: 0 (0.00 %)
*** BY PERCENTAGE ***
Max Increase:
SGPRS: 32 - 40 (25.00 %)
VGPRS: 0 - 0 (0.00 %)
Code Size: 0 - 0 (0.00 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
Max Decrease:
SGPRS: 32 - 24 (-25.00 %)
VGPRS: 16 - 12 (-25.00 %)
Code Size: 116 - 96 (-17.24 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
*** BY UNIT ***
Max Increase:
SGPRS: 64 - 72 (12.50 %)
VGPRS: 0 - 0 (0.00 %)
Code Size: 0 - 0 (0.00 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
Max Decrease:
SGPRS: 32 - 24 (-25.00 %)
VGPRS: 16 - 12 (-25.00 %)
Code Size: 424 - 356 (-16.04 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
---
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 29
++
1 file changed, 29 insertions(+)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 91c56a3..18afbcb 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -637,6 +637,34 @@ static void uif_emit(
if_cond_emit(action, bld_base, emit_data, cond);
}
+static void kill_if_fetch_args(
+ struct lp_build_tgsi_context * bld_base,
+ struct lp_build_emit_data * emit_data)
+{
+ const struct tgsi_full_instruction * inst = emit_data-inst;
+ struct gallivm_state *gallivm = bld_base-base.gallivm;
+ LLVMBuilderRef builder = gallivm-builder;
+ unsigned i;
+ LLVMValueRef conds[TGSI_NUM_CHANNELS];
+
+ for (i = 0; i TGSI_NUM_CHANNELS; i++) {
+ LLVMValueRef value = lp_build_emit_fetch(bld_base, inst, 0,
i);
+ conds[i] = LLVMBuildFCmp(builder, LLVMRealOLT, value,
+ bld_base-base.zero, );
+ }
+
+ /* Or the conditions together */
+ for (i = TGSI_NUM_CHANNELS - 1; i 0; i--) {
+ conds[i - 1] = LLVMBuildOr(builder, conds[i], conds[i - 1],
);
+ }
+
+ emit_data-dst_type = LLVMVoidTypeInContext(gallivm-context);
+ emit_data-arg_count = 1;
+ emit_data-args[0] = LLVMBuildSelect(builder, conds[0],
+ lp_build_const_float(gallivm, -1.0f),
+ bld_base-base.zero, );
+}
+
static void kil_emit(
const struct lp_build_tgsi_action * action,
struct lp_build_tgsi_context * bld_base,
@@ -1467,6 +1495,7 @@ void radeon_llvm_context_init(struct
radeon_llvm_context * ctx)
bld_base-op_actions[TGSI_OPCODE_ISLT].emit = emit_icmp;
bld_base-op_actions[TGSI_OPCODE_ISSG].emit = emit_ssg;
bld_base-op_actions[TGSI_OPCODE_I2F].emit = emit_i2f;
+ bld_base-op_actions[TGSI_OPCODE_KILL_IF].fetch_args =
kill_if_fetch_args;
bld_base-op_actions[TGSI_OPCODE_KILL_IF].emit = kil_emit;
bld_base-op_actions[TGSI_OPCODE_KILL_IF].intr_name =
llvm.AMDGPU.kill;
bld_base-op_actions[TGSI_OPCODE_KILL].emit = lp_build_tgsi_intrinsic;
--
2.0.4
___
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 3/3] util: Change util/set to use quadratic probing
On Mon, Apr 13, 2015 at 3:22 PM, Thomas Helland
thomashellan...@gmail.com wrote:
On 14 Apr 2015 00:05, Jason Ekstrand ja...@jlekstrand.net wrote:
On Sat, Apr 11, 2015 at 4:25 PM, Thomas Helland
thomashellan...@gmail.com wrote:
The same rationale applies here as for the hash table.
Power of two size should give better performance,
and using the algorithm hash = sh + i/2 + i*i/2
should result in only distinct hash values when hitting collisions.
Difference at 95.0% confidence
-7.9505 +/- 2.44011
-5.04357% +/- 1.54794%
V3: Feedback from Eric Anholt
- Don't change load factor and starting size.
V2: Feedback from Connor Abbott
- Don't set initial hash address before potential rehash
- Remove hash_sizes table
- Correct the quadratic hashing algorithm
- Use correct comment style
Feedback from Jason Ekstrand
- Use unreachable() to detect if we fail to insert
Signed-off-by: Thomas Helland thomashellan...@gmail.com
---
src/util/set.c | 118
-
src/util/set.h | 3 +-
2 files changed, 43 insertions(+), 78 deletions(-)
diff --git a/src/util/set.c b/src/util/set.c
index f01f869..7ff9520 100644
--- a/src/util/set.c
+++ b/src/util/set.c
@@ -32,6 +32,17 @@
*Keith Packard kei...@keithp.com
*/
+/**
+ * Implements an open-addressing, quadratic probing hash-set.
+ *
+ * We choose set sizes that's a power of two.
+ * This is computationally less expensive than primes.
+ * As a bonus the size and free space can be calculated instead of
looked up.
+ * FNV-1a has good avalanche properties, so collision is not an issue.
+ * These sets are sized to have an extra 10% free to avoid
+ * exponential performance degradation as the set fills.
+ */
+
#include stdlib.h
#include assert.h
@@ -39,51 +50,9 @@
#include ralloc.h
#include set.h
-/*
- * From Knuth -- a good choice for hash/rehash values is p, p-2 where
- * p and p-2 are both prime. These tables are sized to have an extra
10%
- * free to avoid exponential performance degradation as the hash table
fills
- */
-
uint32_t deleted_key_value;
const void *deleted_key = deleted_key_value;
-static const struct {
- uint32_t max_entries, size, rehash;
-} hash_sizes[] = {
- { 2,5,3},
- { 4,7,5},
- { 8,13, 11 },
- { 16, 19, 17 },
- { 32, 43, 41 },
- { 64, 73, 71 },
- { 128, 151, 149 },
- { 256, 283, 281 },
- { 512, 571, 569 },
- { 1024, 1153, 1151 },
- { 2048, 2269, 2267 },
- { 4096, 4519, 4517 },
- { 8192, 9013, 9011 },
- { 16384,18043,18041},
- { 32768,36109,36107},
- { 65536,72091,72089},
- { 131072, 144409, 144407 },
- { 262144, 288361, 288359 },
- { 524288, 576883, 576881 },
- { 1048576, 1153459, 1153457 },
- { 2097152, 2307163, 2307161 },
- { 4194304, 4613893, 4613891 },
- { 8388608, 9227641, 9227639 },
- { 16777216, 18455029, 18455027 },
- { 33554432, 36911011, 36911009 },
- { 67108864, 73819861, 73819859 },
- { 134217728,147639589,147639587},
- { 268435456,295279081,295279079},
- { 536870912,590559793,590559791},
- { 1073741824, 1181116273, 1181116271 },
- { 2147483648ul, 2362232233ul, 2362232231ul }
-};
-
static int
entry_is_free(struct set_entry *entry)
{
@@ -114,10 +83,9 @@ _mesa_set_create(void *mem_ctx,
if (ht == NULL)
return NULL;
- ht-size_index = 0;
- ht-size = hash_sizes[ht-size_index].size;
- ht-rehash = hash_sizes[ht-size_index].rehash;
- ht-max_entries = hash_sizes[ht-size_index].max_entries;
+ ht-size_iteration = 2;
+ ht-size = 1 ht-size_iteration;
+ ht-max_entries = ht-size * 0.9;
ht-key_hash_function = key_hash_function;
ht-key_equals_function = key_equals_function;
ht-table = rzalloc_array(ht, struct set_entry, ht-size);
@@ -163,12 +131,11 @@ _mesa_set_destroy(struct set *ht, void
(*delete_function)(struct set_entry *entr
static struct set_entry *
set_search(const struct set *ht, uint32_t hash, const void *key)
{
- uint32_t hash_address;
+ uint32_t start_hash_address = hash (ht-size - 1);
+ uint32_t hash_address = start_hash_address;
+ uint32_t quad_hash = 1;
-
Re: [Mesa-dev] [PATCH 3/3] radeon/llvm: Improve codegen for KILL_IF
Thank you very much, though I'm not familiar with that code to be able
to review it. :)
Marek
On Mon, Apr 13, 2015 at 10:55 PM, Tom Stellard t...@stellard.net wrote:
On Mon, Apr 13, 2015 at 10:52:52PM +0200, Marek Olšák wrote:
For the series:
Reviewed-by: Marek Olšák marek.ol...@amd.com
I assume you tested piglit, because I remember there had been some
crashes with the instruction combining pass and the kill instruction.
I sent out an llvm patch to fix the crashes:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150413/271018.html
-Tom
Marek
On Mon, Apr 13, 2015 at 8:21 PM, Tom Stellard thomas.stell...@amd.com
wrote:
Rather than emitting one kill instruction per component of KILL_IF's src
reg, we now or the components of the src register together and use the
result as a condition for just one kill instruction.
shader-db stats (bonaire):
979 shaders
Totals:
SGPRS: 34872 - 34848 (-0.07 %)
VGPRS: 20696 - 20676 (-0.10 %)
Code Size: 749032 - 748452 (-0.08 %) bytes
LDS: 11 - 11 (0.00 %) blocks
Scratch: 12288 - 12288 (0.00 %) bytes per wave
Totals from affected shaders:
SGPRS: 1184 - 1160 (-2.03 %)
VGPRS: 600 - 580 (-3.33 %)
Code Size: 13200 - 12620 (-4.39 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
Increases:
SGPRS: 2 (0.00 %)
VGPRS: 0 (0.00 %)
Code Size: 0 (0.00 %)
LDS: 0 (0.00 %)
Scratch: 0 (0.00 %)
Decreases:
SGPRS: 5 (0.01 %)
VGPRS: 5 (0.01 %)
Code Size: 25 (0.03 %)
LDS: 0 (0.00 %)
Scratch: 0 (0.00 %)
*** BY PERCENTAGE ***
Max Increase:
SGPRS: 32 - 40 (25.00 %)
VGPRS: 0 - 0 (0.00 %)
Code Size: 0 - 0 (0.00 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
Max Decrease:
SGPRS: 32 - 24 (-25.00 %)
VGPRS: 16 - 12 (-25.00 %)
Code Size: 116 - 96 (-17.24 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
*** BY UNIT ***
Max Increase:
SGPRS: 64 - 72 (12.50 %)
VGPRS: 0 - 0 (0.00 %)
Code Size: 0 - 0 (0.00 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
Max Decrease:
SGPRS: 32 - 24 (-25.00 %)
VGPRS: 16 - 12 (-25.00 %)
Code Size: 424 - 356 (-16.04 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
---
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 29
++
1 file changed, 29 insertions(+)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 91c56a3..18afbcb 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -637,6 +637,34 @@ static void uif_emit(
if_cond_emit(action, bld_base, emit_data, cond);
}
+static void kill_if_fetch_args(
+ struct lp_build_tgsi_context * bld_base,
+ struct lp_build_emit_data * emit_data)
+{
+ const struct tgsi_full_instruction * inst = emit_data-inst;
+ struct gallivm_state *gallivm = bld_base-base.gallivm;
+ LLVMBuilderRef builder = gallivm-builder;
+ unsigned i;
+ LLVMValueRef conds[TGSI_NUM_CHANNELS];
+
+ for (i = 0; i TGSI_NUM_CHANNELS; i++) {
+ LLVMValueRef value = lp_build_emit_fetch(bld_base, inst,
0, i);
+ conds[i] = LLVMBuildFCmp(builder, LLVMRealOLT, value,
+ bld_base-base.zero, );
+ }
+
+ /* Or the conditions together */
+ for (i = TGSI_NUM_CHANNELS - 1; i 0; i--) {
+ conds[i - 1] = LLVMBuildOr(builder, conds[i], conds[i -
1], );
+ }
+
+ emit_data-dst_type = LLVMVoidTypeInContext(gallivm-context);
+ emit_data-arg_count = 1;
+ emit_data-args[0] = LLVMBuildSelect(builder, conds[0],
+ lp_build_const_float(gallivm,
-1.0f),
+ bld_base-base.zero, );
+}
+
static void kil_emit(
const struct lp_build_tgsi_action * action,
struct lp_build_tgsi_context * bld_base,
@@ -1467,6 +1495,7 @@ void radeon_llvm_context_init(struct
radeon_llvm_context * ctx)
bld_base-op_actions[TGSI_OPCODE_ISLT].emit = emit_icmp;
bld_base-op_actions[TGSI_OPCODE_ISSG].emit = emit_ssg;
bld_base-op_actions[TGSI_OPCODE_I2F].emit = emit_i2f;
+ bld_base-op_actions[TGSI_OPCODE_KILL_IF].fetch_args =
kill_if_fetch_args;
bld_base-op_actions[TGSI_OPCODE_KILL_IF].emit = kil_emit;
bld_base-op_actions[TGSI_OPCODE_KILL_IF].intr_name =
llvm.AMDGPU.kill;
bld_base-op_actions[TGSI_OPCODE_KILL].emit =
lp_build_tgsi_intrinsic;
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89018] Civilization: Beyond Earth terrain section not rendered
https://bugs.freedesktop.org/show_bug.cgi?id=89018 --- Comment #16 from Sami Liedes sami.lie...@iki.fi --- I think this might be related to the color rendering weirdness: On fglrx, CivBE uses the GL_NV_half_float extension, which is not available on Mesa. Looking at interesting words or enums that are present in one of the traces but not the other (after apitrace dump): * The fglrx dump mentions GL_DEPTH, GL_DEPTH_COMPONENT, GL_DEPTH_COMPONENT16, GL_R16F, GL_RG, GL_RG16F, glColorMaski, while running under mesa does not. * I believe the pixel formats here are probably those half floats, and if that's unsupported by mesa, then it's no big wonder the color channels are off? * The mesa dump mentions nan in glUniform4fv calls. That cannot be good? :P -- You are receiving this mail because: You are the QA Contact for the bug. 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] st/mesa: align cube map arrays layers
Hi Dave, This patch fixes: https://bugs.freedesktop.org/show_bug.cgi?id=89957 And should also be marked cc stable. Tested-by: Tom Stellard thomas.stell...@amd.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx: Allow to create any OpenGL ES version.
On 04/10/2015 03:36 PM, Jose Fonseca wrote:
From: José Fonseca jfons...@vmware.com
The latest version of GLX_EXT_create_context_es2_profile states:
If the version requested is a valid and supported OpenGL-ES version,
and the GLX_CONTEXT_ES_PROFILE_BIT_EXT bit is set in the
GLX_CONTEXT_PROFILE_MASK_ARB attribute (see below), then the context
returned will implement the OpenGL ES version requested.
We must also export EXT_create_context_es_profile too, as
EXT_create_context_es2_profile specification is crystal clear:
NOTE: implementations of this extension must export BOTH extension
strings, for backwards compatibility with applications written
against version 1 of this extension.
Totally untested. (Just happened to noticed this while implementing
GLX_EXT_create_context_es2_profile for st/xlib.)
Reviewed-by: Brian Paul bri...@vmware.com
Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
v2: Replicate the drisw_glx.c to dri2_glx.c and dri3_glx.c as suggested
by Emil Velikov.
---
src/glx/dri2_glx.c | 5 -
src/glx/dri3_glx.c | 5 -
src/glx/dri_common.c | 32
src/glx/drisw_glx.c | 2 ++
4 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 462d560..8192c54 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -1102,9 +1102,12 @@ dri2BindExtensions(struct dri2_screen *psc, struct
glx_display * priv,
__glXEnableDirectExtension(psc-base, GLX_ARB_create_context);
__glXEnableDirectExtension(psc-base,
GLX_ARB_create_context_profile);
- if ((mask (1 __DRI_API_GLES2)) != 0)
+ if ((mask (1 __DRI_API_GLES2)) != 0) {
+ __glXEnableDirectExtension(psc-base,
+ GLX_EXT_create_context_es_profile);
__glXEnableDirectExtension(psc-base,
GLX_EXT_create_context_es2_profile);
+ }
}
for (i = 0; extensions[i]; i++) {
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 1ddc723..6973ad1 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -1825,9 +1825,12 @@ dri3_bind_extensions(struct dri3_screen *psc, struct
glx_display * priv,
__glXEnableDirectExtension(psc-base, GLX_ARB_create_context);
__glXEnableDirectExtension(psc-base, GLX_ARB_create_context_profile);
- if ((mask (1 __DRI_API_GLES2)) != 0)
+ if ((mask (1 __DRI_API_GLES2)) != 0) {
+ __glXEnableDirectExtension(psc-base,
+ GLX_EXT_create_context_es_profile);
__glXEnableDirectExtension(psc-base,
GLX_EXT_create_context_es2_profile);
+ }
for (i = 0; extensions[i]; i++) {
/* when on a different gpu than the server, the server pixmaps
diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index 63c8de3..541abbb 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -544,9 +544,22 @@ dri2_convert_glx_attribs(unsigned num_attribs, const
uint32_t *attribs,
case GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB:
*api = __DRI_API_OPENGL;
break;
- case GLX_CONTEXT_ES2_PROFILE_BIT_EXT:
- *api = __DRI_API_GLES2;
- break;
+ case GLX_CONTEXT_ES_PROFILE_BIT_EXT:
+ switch (*major_ver) {
+ case 3:
+*api = __DRI_API_GLES3;
+break;
+ case 2:
+*api = __DRI_API_GLES2;
+break;
+ case 1:
+*api = __DRI_API_GLES;
+break;
+ default:
+*error = __DRI_CTX_ERROR_BAD_API;
+return false;
+ }
+ break;
default:
*error = __DRI_CTX_ERROR_BAD_API;
return false;
@@ -577,19 +590,6 @@ dri2_convert_glx_attribs(unsigned num_attribs, const
uint32_t *attribs,
return false;
}
- /* The GLX_EXT_create_context_es2_profile spec says:
-*
-* ... If the version requested is 2.0, and the
-* GLX_CONTEXT_ES2_PROFILE_BIT_EXT bit is set in the
-* GLX_CONTEXT_PROFILE_MASK_ARB attribute (see below), then the
context
-* returned will implement OpenGL ES 2.0. This is the only way in
which
-* an implementation may request an OpenGL ES 2.0 context.
-*/
- if (*api == __DRI_API_GLES2 (*major_ver != 2 || *minor_ver != 0)) {
- *error = __DRI_CTX_ERROR_BAD_API;
- return false;
- }
I guess this text was removed from the extension spec, and now we rely
on some other layer detecting invalid versions (like 2.1)?
This patch combined with Chad's patch seems like it should work... I'm a
little confused why Waffle doesn't like it. :(
-
*error = __DRI_CTX_ERROR_SUCCESS;
return true;
}
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 749ceb0..b0be5d0 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -617,6 +617,8 @@
[Mesa-dev] [PATCH 3/3] util: Change util/set to use quadratic probing
On 14 Apr 2015 00:05, Jason Ekstrand ja...@jlekstrand.net wrote:
On Sat, Apr 11, 2015 at 4:25 PM, Thomas Helland
thomashellan...@gmail.com wrote:
The same rationale applies here as for the hash table.
Power of two size should give better performance,
and using the algorithm hash = sh + i/2 + i*i/2
should result in only distinct hash values when hitting collisions.
Difference at 95.0% confidence
-7.9505 +/- 2.44011
-5.04357% +/- 1.54794%
V3: Feedback from Eric Anholt
- Don't change load factor and starting size.
V2: Feedback from Connor Abbott
- Don't set initial hash address before potential rehash
- Remove hash_sizes table
- Correct the quadratic hashing algorithm
- Use correct comment style
Feedback from Jason Ekstrand
- Use unreachable() to detect if we fail to insert
Signed-off-by: Thomas Helland thomashellan...@gmail.com
---
src/util/set.c | 118
-
src/util/set.h | 3 +-
2 files changed, 43 insertions(+), 78 deletions(-)
diff --git a/src/util/set.c b/src/util/set.c
index f01f869..7ff9520 100644
--- a/src/util/set.c
+++ b/src/util/set.c
@@ -32,6 +32,17 @@
*Keith Packard kei...@keithp.com
*/
+/**
+ * Implements an open-addressing, quadratic probing hash-set.
+ *
+ * We choose set sizes that's a power of two.
+ * This is computationally less expensive than primes.
+ * As a bonus the size and free space can be calculated instead of
looked up.
+ * FNV-1a has good avalanche properties, so collision is not an issue.
+ * These sets are sized to have an extra 10% free to avoid
+ * exponential performance degradation as the set fills.
+ */
+
#include stdlib.h
#include assert.h
@@ -39,51 +50,9 @@
#include ralloc.h
#include set.h
-/*
- * From Knuth -- a good choice for hash/rehash values is p, p-2 where
- * p and p-2 are both prime. These tables are sized to have an extra
10%
- * free to avoid exponential performance degradation as the hash table
fills
- */
-
uint32_t deleted_key_value;
const void *deleted_key = deleted_key_value;
-static const struct {
- uint32_t max_entries, size, rehash;
-} hash_sizes[] = {
- { 2,5,3},
- { 4,7,5},
- { 8,13, 11 },
- { 16, 19, 17 },
- { 32, 43, 41 },
- { 64, 73, 71 },
- { 128, 151, 149 },
- { 256, 283, 281 },
- { 512, 571, 569 },
- { 1024, 1153, 1151 },
- { 2048, 2269, 2267 },
- { 4096, 4519, 4517 },
- { 8192, 9013, 9011 },
- { 16384,18043,18041},
- { 32768,36109,36107},
- { 65536,72091,72089},
- { 131072, 144409, 144407 },
- { 262144, 288361, 288359 },
- { 524288, 576883, 576881 },
- { 1048576, 1153459, 1153457 },
- { 2097152, 2307163, 2307161 },
- { 4194304, 4613893, 4613891 },
- { 8388608, 9227641, 9227639 },
- { 16777216, 18455029, 18455027 },
- { 33554432, 36911011, 36911009 },
- { 67108864, 73819861, 73819859 },
- { 134217728,147639589,147639587},
- { 268435456,295279081,295279079},
- { 536870912,590559793,590559791},
- { 1073741824, 1181116273, 1181116271 },
- { 2147483648ul, 2362232233ul, 2362232231ul }
-};
-
static int
entry_is_free(struct set_entry *entry)
{
@@ -114,10 +83,9 @@ _mesa_set_create(void *mem_ctx,
if (ht == NULL)
return NULL;
- ht-size_index = 0;
- ht-size = hash_sizes[ht-size_index].size;
- ht-rehash = hash_sizes[ht-size_index].rehash;
- ht-max_entries = hash_sizes[ht-size_index].max_entries;
+ ht-size_iteration = 2;
+ ht-size = 1 ht-size_iteration;
+ ht-max_entries = ht-size * 0.9;
ht-key_hash_function = key_hash_function;
ht-key_equals_function = key_equals_function;
ht-table = rzalloc_array(ht, struct set_entry, ht-size);
@@ -163,12 +131,11 @@ _mesa_set_destroy(struct set *ht, void
(*delete_function)(struct set_entry *entr
static struct set_entry *
set_search(const struct set *ht, uint32_t hash, const void *key)
{
- uint32_t hash_address;
+ uint32_t start_hash_address = hash (ht-size - 1);
+ uint32_t hash_address = start_hash_address;
+ uint32_t quad_hash = 1;
- hash_address = hash % ht-size;
do {
- uint32_t double_hash;
-
struct set_entry
Re: [Mesa-dev] [PATCH 1/2] configure.ac: print LLVM_LDFLAGS
On 04/13/2015 02:06 PM, Marek Olšák wrote: From: Marek Olšák marek.ol...@amd.com --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index 9e8c1d8..6ccf3b4 100644 --- a/configure.ac +++ b/configure.ac @@ -2543,6 +2543,7 @@ if test x$MESA_LLVM = x1; then echo LLVM_CFLAGS: $LLVM_CFLAGS echo LLVM_CXXFLAGS: $LLVM_CXXFLAGS echo LLVM_CPPFLAGS: $LLVM_CPPFLAGS +echo LLVM_LDFLAGS:$LLVM_LDFLAGS echo fi echo PYTHON2: $PYTHON2 Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89018] Civilization: Beyond Earth terrain section not rendered
https://bugs.freedesktop.org/show_bug.cgi?id=89018 --- Comment #15 from Brian Paul bri...@vmware.com --- If you want to temporarily disable an extension in mesa: export MESA_EXTENSION_OVERRIDE=-GL_NV_texture_rectangle for example. Note the leading - which means 'turn off this extension'. For the firegl driver, you could use apitrace with a gltrace.conf file to selectively disable extensions. -- You are receiving this mail because: You are the QA Contact for the bug. 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] i965/fs: Correct mistake in determining whether a MUL is negated.
On 04/13/2015 01:11 PM, Matt Turner wrote:
a * b is equivalent to -a * -b, and the previous code was failing at
that.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89961
---
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
index f2c4098..c1d0616 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
@@ -145,7 +145,7 @@ operands_match(const fs_inst *a, const fs_inst *b, bool
*negate)
xs[1].fixed_hw_reg.dw1.f = xs1_imm;
ys[1].fixed_hw_reg.dw1.f = ys1_imm;
- *negate = (xs0_negate + xs1_negate) != (ys0_negate + ys1_negate);
+ *negate = (xs0_negate != xs1_negate) != (ys0_negate != ys1_negate);
Any idea whether adding support for the double negation to the regular
operands_match path helps anything? When I tried it at the GLSL IR
level it didn't make any difference.
If you didn't already push this patch,
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
return ret;
} else if (!a-is_commutative()) {
bool match = true;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: extend GLSLSkipStrictMaxUniformLimitCheck to uniform block size
FWIW fsexceed crashes badly with llvmpipe (this is because we copy the
constants into scene data, and the block size there is 64kB). I've
actually wondered if it's the state tracker's job or that of the driver
to ensure nothing bad happens. It is however happening due to the actual
buffer being larger, the declaration in the shader is irrelevant for
this crash.
Roland
Am 13.04.2015 um 23:17 schrieb Ian Romanick:
On 04/11/2015 09:48 AM, Marcin Ślusarz wrote:
ARB_uniform_buffer_object spec says:
The total amount of buffer object storage available for any given uniform
block is subject to an implementation-dependent limit; the maximum amount
of available space, in basic machine units, can be queried by calling
GetIntegerv with the constant MAX_UNIFORM_BLOCK_SIZE. If the amount
of storage required for a uniform block exceeds this limit, a program may
fail to link.
Fixes these piglit tests:
spec@arb_uniform_buffer_object@maxuniformblocksize@fsexceed
spec@arb_uniform_buffer_object@maxuniformblocksize@vsexceed
on nouveau/gk107.
Can you elaborate on how this fixes the test? The fsexceed and vsexceed
tests are supposed to pass if linking fails.
---
src/glsl/linker.cpp | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 85830e6..88a4548 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2308,6 +2308,25 @@ check_resources(struct gl_context *ctx, struct
gl_shader_program *prog)
_mesa_shader_stage_to_string(i));
}
}
+
+ for (unsigned j = 0; j sh-NumUniformBlocks; ++j) {
+ if (sh-UniformBlocks[j].UniformBufferSize
+ ctx-Const.MaxUniformBlockSize) {
+if (ctx-Const.GLSLSkipStrictMaxUniformLimitCheck) {
+ linker_warning(prog,
+ %s shader uses uniform block whose size
exceeds
+ MAX_UNIFORM_BLOCK_SIZE, but the driver will
try
+ to optimize them out; this is non-portable
+ out-of-spec behaviour\n,
+ _mesa_shader_stage_to_string(i));
+} else {
+ linker_error(prog,
+%s shader uses uniform block whose size
exceeds
+MAX_UNIFORM_BLOCK_SIZE\n,
+_mesa_shader_stage_to_string(i));
+}
+ }
+ }
}
unsigned blocks[MESA_SHADER_STAGES] = {0};
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddevd=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_Im=5HuaYz6dkFzuFmgzCLGfhl8ulgIBgcm3sKgjUB1uirks=GkMQac6K3V4fguotgnoLPdtRKc9YHZyLTNurk1amtPoe=
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] util: Change util/set to use quadratic probing
On Sat, Apr 11, 2015 at 4:25 PM, Thomas Helland
thomashellan...@gmail.com wrote:
The same rationale applies here as for the hash table.
Power of two size should give better performance,
and using the algorithm hash = sh + i/2 + i*i/2
should result in only distinct hash values when hitting collisions.
Difference at 95.0% confidence
-7.9505 +/- 2.44011
-5.04357% +/- 1.54794%
V3: Feedback from Eric Anholt
- Don't change load factor and starting size.
V2: Feedback from Connor Abbott
- Don't set initial hash address before potential rehash
- Remove hash_sizes table
- Correct the quadratic hashing algorithm
- Use correct comment style
Feedback from Jason Ekstrand
- Use unreachable() to detect if we fail to insert
Signed-off-by: Thomas Helland thomashellan...@gmail.com
---
src/util/set.c | 118
-
src/util/set.h | 3 +-
2 files changed, 43 insertions(+), 78 deletions(-)
diff --git a/src/util/set.c b/src/util/set.c
index f01f869..7ff9520 100644
--- a/src/util/set.c
+++ b/src/util/set.c
@@ -32,6 +32,17 @@
*Keith Packard kei...@keithp.com
*/
+/**
+ * Implements an open-addressing, quadratic probing hash-set.
+ *
+ * We choose set sizes that's a power of two.
+ * This is computationally less expensive than primes.
+ * As a bonus the size and free space can be calculated instead of looked up.
+ * FNV-1a has good avalanche properties, so collision is not an issue.
+ * These sets are sized to have an extra 10% free to avoid
+ * exponential performance degradation as the set fills.
+ */
+
#include stdlib.h
#include assert.h
@@ -39,51 +50,9 @@
#include ralloc.h
#include set.h
-/*
- * From Knuth -- a good choice for hash/rehash values is p, p-2 where
- * p and p-2 are both prime. These tables are sized to have an extra 10%
- * free to avoid exponential performance degradation as the hash table fills
- */
-
uint32_t deleted_key_value;
const void *deleted_key = deleted_key_value;
-static const struct {
- uint32_t max_entries, size, rehash;
-} hash_sizes[] = {
- { 2,5,3},
- { 4,7,5},
- { 8,13, 11 },
- { 16, 19, 17 },
- { 32, 43, 41 },
- { 64, 73, 71 },
- { 128, 151, 149 },
- { 256, 283, 281 },
- { 512, 571, 569 },
- { 1024, 1153, 1151 },
- { 2048, 2269, 2267 },
- { 4096, 4519, 4517 },
- { 8192, 9013, 9011 },
- { 16384,18043,18041},
- { 32768,36109,36107},
- { 65536,72091,72089},
- { 131072, 144409, 144407 },
- { 262144, 288361, 288359 },
- { 524288, 576883, 576881 },
- { 1048576, 1153459, 1153457 },
- { 2097152, 2307163, 2307161 },
- { 4194304, 4613893, 4613891 },
- { 8388608, 9227641, 9227639 },
- { 16777216, 18455029, 18455027 },
- { 33554432, 36911011, 36911009 },
- { 67108864, 73819861, 73819859 },
- { 134217728,147639589,147639587},
- { 268435456,295279081,295279079},
- { 536870912,590559793,590559791},
- { 1073741824, 1181116273, 1181116271 },
- { 2147483648ul, 2362232233ul, 2362232231ul }
-};
-
static int
entry_is_free(struct set_entry *entry)
{
@@ -114,10 +83,9 @@ _mesa_set_create(void *mem_ctx,
if (ht == NULL)
return NULL;
- ht-size_index = 0;
- ht-size = hash_sizes[ht-size_index].size;
- ht-rehash = hash_sizes[ht-size_index].rehash;
- ht-max_entries = hash_sizes[ht-size_index].max_entries;
+ ht-size_iteration = 2;
+ ht-size = 1 ht-size_iteration;
+ ht-max_entries = ht-size * 0.9;
ht-key_hash_function = key_hash_function;
ht-key_equals_function = key_equals_function;
ht-table = rzalloc_array(ht, struct set_entry, ht-size);
@@ -163,12 +131,11 @@ _mesa_set_destroy(struct set *ht, void
(*delete_function)(struct set_entry *entr
static struct set_entry *
set_search(const struct set *ht, uint32_t hash, const void *key)
{
- uint32_t hash_address;
+ uint32_t start_hash_address = hash (ht-size - 1);
+ uint32_t hash_address = start_hash_address;
+ uint32_t quad_hash = 1;
- hash_address = hash % ht-size;
do {
- uint32_t double_hash;
-
struct set_entry *entry = ht-table + hash_address;
if (entry_is_free(entry)) {
@@ -179,10 +146,10 @@ set_search(const struct set *ht, uint32_t hash, const
void *key)
}
}
-
Re: [Mesa-dev] [PATCH] Fix 32bit compilation with -Werror=implicit-function-declaration
On 04/13/2015 01:49 PM, Pali Rohár wrote: On Monday 13 April 2015 21:26:32 Pali Rohár wrote: File glapi_entrypoint.c calls memcpy() function, but does not include string.h header. So compilation can fail at error: implicit declaration of function 'memcpy'. --- src/mapi/glapi/glapi_entrypoint.c 2015-04-13 21:11:09.0 +0200 +++ src/mapi/glapi/glapi_entrypoint.c 2015-04-13 21:11:55.284118513 +0200 @@ -33,6 +33,7 @@ #include glapi/glapi_priv.h #include u_execmem.h +#include string.h #ifdef USE_X86_ASM This problem is caused by commit: https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_mesa_mesa_commit_-3Fid-3D9fbbd60c1da4467683d93540c64164ad337ce454d=AwIFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8m=cHbB4rMFT3az-q-Y6KO11a04PyYTYhOCPMZ3PAFmydss=lvCbo4YTBIN15kh-3Wu1-rQAsyFcdKtCE-Ywc4u_muge= which removes #include string.h from glapi_priv.h file. What configure or autogen.sh options did you use? I haven't seen this on any of my systems. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] radeon/llvm: Improve codegen for KILL_IF
On Mon, Apr 13, 2015 at 10:52:52PM +0200, Marek Olšák wrote:
For the series:
Reviewed-by: Marek Olšák marek.ol...@amd.com
I assume you tested piglit, because I remember there had been some
crashes with the instruction combining pass and the kill instruction.
I sent out an llvm patch to fix the crashes:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150413/271018.html
-Tom
Marek
On Mon, Apr 13, 2015 at 8:21 PM, Tom Stellard thomas.stell...@amd.com wrote:
Rather than emitting one kill instruction per component of KILL_IF's src
reg, we now or the components of the src register together and use the
result as a condition for just one kill instruction.
shader-db stats (bonaire):
979 shaders
Totals:
SGPRS: 34872 - 34848 (-0.07 %)
VGPRS: 20696 - 20676 (-0.10 %)
Code Size: 749032 - 748452 (-0.08 %) bytes
LDS: 11 - 11 (0.00 %) blocks
Scratch: 12288 - 12288 (0.00 %) bytes per wave
Totals from affected shaders:
SGPRS: 1184 - 1160 (-2.03 %)
VGPRS: 600 - 580 (-3.33 %)
Code Size: 13200 - 12620 (-4.39 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
Increases:
SGPRS: 2 (0.00 %)
VGPRS: 0 (0.00 %)
Code Size: 0 (0.00 %)
LDS: 0 (0.00 %)
Scratch: 0 (0.00 %)
Decreases:
SGPRS: 5 (0.01 %)
VGPRS: 5 (0.01 %)
Code Size: 25 (0.03 %)
LDS: 0 (0.00 %)
Scratch: 0 (0.00 %)
*** BY PERCENTAGE ***
Max Increase:
SGPRS: 32 - 40 (25.00 %)
VGPRS: 0 - 0 (0.00 %)
Code Size: 0 - 0 (0.00 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
Max Decrease:
SGPRS: 32 - 24 (-25.00 %)
VGPRS: 16 - 12 (-25.00 %)
Code Size: 116 - 96 (-17.24 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
*** BY UNIT ***
Max Increase:
SGPRS: 64 - 72 (12.50 %)
VGPRS: 0 - 0 (0.00 %)
Code Size: 0 - 0 (0.00 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
Max Decrease:
SGPRS: 32 - 24 (-25.00 %)
VGPRS: 16 - 12 (-25.00 %)
Code Size: 424 - 356 (-16.04 %) bytes
LDS: 0 - 0 (0.00 %) blocks
Scratch: 0 - 0 (0.00 %) bytes per wave
---
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 29
++
1 file changed, 29 insertions(+)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 91c56a3..18afbcb 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -637,6 +637,34 @@ static void uif_emit(
if_cond_emit(action, bld_base, emit_data, cond);
}
+static void kill_if_fetch_args(
+ struct lp_build_tgsi_context * bld_base,
+ struct lp_build_emit_data * emit_data)
+{
+ const struct tgsi_full_instruction * inst = emit_data-inst;
+ struct gallivm_state *gallivm = bld_base-base.gallivm;
+ LLVMBuilderRef builder = gallivm-builder;
+ unsigned i;
+ LLVMValueRef conds[TGSI_NUM_CHANNELS];
+
+ for (i = 0; i TGSI_NUM_CHANNELS; i++) {
+ LLVMValueRef value = lp_build_emit_fetch(bld_base, inst, 0,
i);
+ conds[i] = LLVMBuildFCmp(builder, LLVMRealOLT, value,
+ bld_base-base.zero, );
+ }
+
+ /* Or the conditions together */
+ for (i = TGSI_NUM_CHANNELS - 1; i 0; i--) {
+ conds[i - 1] = LLVMBuildOr(builder, conds[i], conds[i - 1],
);
+ }
+
+ emit_data-dst_type = LLVMVoidTypeInContext(gallivm-context);
+ emit_data-arg_count = 1;
+ emit_data-args[0] = LLVMBuildSelect(builder, conds[0],
+ lp_build_const_float(gallivm,
-1.0f),
+ bld_base-base.zero, );
+}
+
static void kil_emit(
const struct lp_build_tgsi_action * action,
struct lp_build_tgsi_context * bld_base,
@@ -1467,6 +1495,7 @@ void radeon_llvm_context_init(struct
radeon_llvm_context * ctx)
bld_base-op_actions[TGSI_OPCODE_ISLT].emit = emit_icmp;
bld_base-op_actions[TGSI_OPCODE_ISSG].emit = emit_ssg;
bld_base-op_actions[TGSI_OPCODE_I2F].emit = emit_i2f;
+ bld_base-op_actions[TGSI_OPCODE_KILL_IF].fetch_args =
kill_if_fetch_args;
bld_base-op_actions[TGSI_OPCODE_KILL_IF].emit = kil_emit;
bld_base-op_actions[TGSI_OPCODE_KILL_IF].intr_name =
llvm.AMDGPU.kill;
bld_base-op_actions[TGSI_OPCODE_KILL].emit =
lp_build_tgsi_intrinsic;
--
2.0.4
___
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] glsl: extend GLSLSkipStrictMaxUniformLimitCheck to uniform block size
On 04/11/2015 09:48 AM, Marcin Ślusarz wrote:
ARB_uniform_buffer_object spec says:
The total amount of buffer object storage available for any given uniform
block is subject to an implementation-dependent limit; the maximum amount
of available space, in basic machine units, can be queried by calling
GetIntegerv with the constant MAX_UNIFORM_BLOCK_SIZE. If the amount
of storage required for a uniform block exceeds this limit, a program may
fail to link.
Fixes these piglit tests:
spec@arb_uniform_buffer_object@maxuniformblocksize@fsexceed
spec@arb_uniform_buffer_object@maxuniformblocksize@vsexceed
on nouveau/gk107.
Can you elaborate on how this fixes the test? The fsexceed and vsexceed
tests are supposed to pass if linking fails.
---
src/glsl/linker.cpp | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 85830e6..88a4548 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2308,6 +2308,25 @@ check_resources(struct gl_context *ctx, struct
gl_shader_program *prog)
_mesa_shader_stage_to_string(i));
}
}
+
+ for (unsigned j = 0; j sh-NumUniformBlocks; ++j) {
+ if (sh-UniformBlocks[j].UniformBufferSize
+ ctx-Const.MaxUniformBlockSize) {
+if (ctx-Const.GLSLSkipStrictMaxUniformLimitCheck) {
+ linker_warning(prog,
+ %s shader uses uniform block whose size
exceeds
+ MAX_UNIFORM_BLOCK_SIZE, but the driver will
try
+ to optimize them out; this is non-portable
+ out-of-spec behaviour\n,
+ _mesa_shader_stage_to_string(i));
+} else {
+ linker_error(prog,
+%s shader uses uniform block whose size exceeds
+MAX_UNIFORM_BLOCK_SIZE\n,
+_mesa_shader_stage_to_string(i));
+}
+ }
+ }
}
unsigned blocks[MESA_SHADER_STAGES] = {0};
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/18] i965/cs: Add support for the SEND message that terminates a CS thread.
On Sat, Mar 14, 2015 at 9:54 PM, Jordan Justen
jordan.l.jus...@intel.com wrote:
From: Paul Berry stereotype...@gmail.com
This message must be sent to the thread spawner unit.
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_eu.h | 4 +++
src/mesa/drivers/dri/i965/brw_eu_emit.c | 46
+
2 files changed, 50 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_eu.h
b/src/mesa/drivers/dri/i965/brw_eu.h
index d9ad5bd..708c216 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -349,6 +349,10 @@ brw_jump_scale(const struct brw_context *brw)
return 1;
}
+void brw_cs_terminate(struct brw_compile *p,
+ unsigned msg_reg_nr,
+ struct brw_reg src0);
+
/* If/else/endif. Works by manipulating the execution flags on each
* channel.
*/
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 43e5783..9c166a3 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -2895,3 +2895,49 @@ void brw_shader_time_add(struct brw_compile *p,
0 /* response length */,
false /* header present */);
}
+
+
+static void
+brw_set_cs_terminate_message(struct brw_context *brw,
+ struct brw_compile *p,
+ struct brw_inst *insn)
+{
+ /* Terminate a compute shader by sending a message to the thread spawner.
+* Note that even though the thread has a URB resource associated with it,
+* we set the do not dereference URB bit, because the URB resource is
+* managed by the fixed-function unit, so it will free it automatically.
+*/
+ brw_set_message_descriptor(p, insn, BRW_SFID_THREAD_SPAWNER,
+ 1 /* msg_length */,
+ 0 /* response_length */,
+ false /* header_present */,
+ true /* end_of_thread */);
+ brw_inst_set_ts_opcode(brw, insn, 0); /* Dereference resource */
+ brw_inst_set_ts_request_type(brw, insn, 0); /* Root thread */
+ brw_inst_set_ts_resource_select(brw, insn, 1); /* Do not dereference URB
*/
+}
+
+
+/**
+ * Emit the SEND message to terminate a compute shader.
+ */
+void
+brw_cs_terminate(struct brw_compile *p,
+ unsigned msg_reg_nr,
+ struct brw_reg src0)
+{
+ struct brw_context *brw = p-brw;
+ struct brw_inst *insn;
+
+ gen6_resolve_implied_move(p, src0, msg_reg_nr);
+ insn = next_insn(p, BRW_OPCODE_SEND);
+ brw_set_dest(p, insn, brw_null_reg());
+ brw_set_src0(p, insn, src0);
+ brw_set_src1(p, insn, brw_imm_d(0));
+
+ if (brw-gen 6)
+ brw_inst_set_cond_modifier(brw, insn, msg_reg_nr);
+
+ brw_set_cs_terminate_message(brw, p, insn);
+ brw_inst_set_mask_control(brw, insn, BRW_MASK_DISABLE);
+}
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] glsl: extend GLSLSkipStrictMaxUniformLimitCheck to uniform block size
ARB_uniform_buffer_object spec says:
The total amount of buffer object storage available for any given uniform
block is subject to an implementation-dependent limit; the maximum amount
of available space, in basic machine units, can be queried by calling
GetIntegerv with the constant MAX_UNIFORM_BLOCK_SIZE. If the amount
of storage required for a uniform block exceeds this limit, a program may
fail to link.
Currently spec@arb_uniform_buffer_object@maxuniformblocksize@*exceed tests
fail on nouveau because shader can't calculate expected values. With this
patch linking fails (GLSLSkipStrictMaxUniformLimitCheck is false on nouveau),
allowing tests to pass.
v2: tweak commit message
---
src/glsl/linker.cpp | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 85830e6..88a4548 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2308,6 +2308,25 @@ check_resources(struct gl_context *ctx, struct
gl_shader_program *prog)
_mesa_shader_stage_to_string(i));
}
}
+
+ for (unsigned j = 0; j sh-NumUniformBlocks; ++j) {
+ if (sh-UniformBlocks[j].UniformBufferSize
+ ctx-Const.MaxUniformBlockSize) {
+if (ctx-Const.GLSLSkipStrictMaxUniformLimitCheck) {
+ linker_warning(prog,
+ %s shader uses uniform block whose size exceeds
+ MAX_UNIFORM_BLOCK_SIZE, but the driver will try
+ to optimize them out; this is non-portable
+ out-of-spec behaviour\n,
+ _mesa_shader_stage_to_string(i));
+} else {
+ linker_error(prog,
+%s shader uses uniform block whose size exceeds
+MAX_UNIFORM_BLOCK_SIZE\n,
+_mesa_shader_stage_to_string(i));
+}
+ }
+ }
}
unsigned blocks[MESA_SHADER_STAGES] = {0};
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH shader-db 1/5] run.c: Use computed value of max_threads
Thanks Tom. I fixed a couple of whitespace mistakes and pushed these! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 12/18] i965/cache: Add support for CS in program state cache
On Sat, Mar 14, 2015 at 9:54 PM, Jordan Justen
jordan.l.jus...@intel.com wrote:
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_cs.cpp| 48
+
src/mesa/drivers/dri/i965/brw_cs.h | 2 ++
src/mesa/drivers/dri/i965/brw_state_cache.c | 3 ++
4 files changed, 54 insertions(+)
create mode 100644 src/mesa/drivers/dri/i965/brw_cs.cpp
diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
b/src/mesa/drivers/dri/i965/Makefile.sources
index c69441b..b2dccf8 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -19,6 +19,7 @@ i965_FILES = \
brw_clip_util.c \
brw_context.c \
brw_context.h \
+ brw_cs.cpp \
brw_cubemap_normalize.cpp \
brw_curbe.c \
brw_dead_control_flow.cpp \
diff --git a/src/mesa/drivers/dri/i965/brw_cs.cpp
b/src/mesa/drivers/dri/i965/brw_cs.cpp
new file mode 100644
index 000..8021147
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/brw_cs.cpp
@@ -0,0 +1,48 @@
+/*
+ * Copyright (c) 2014 - 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+
+#include brw_context.h
+#include brw_cs.h
+
+extern C
+bool
+brw_cs_prog_data_compare(const void *in_a, const void *in_b)
+{
+ const struct brw_cs_prog_data *a =
+ (const struct brw_cs_prog_data *)in_a;
+ const struct brw_cs_prog_data *b =
+ (const struct brw_cs_prog_data *)in_b;
+
+ /* Compare the base structure. */
+ if (!brw_stage_prog_data_compare(a-base, b-base))
+ return false;
+
+ /* Compare the rest of the structure. */
+ const unsigned offset = sizeof(struct brw_stage_prog_data);
+ if (memcmp(((char *) a) + offset, ((char *) b) + offset,
+ sizeof(struct brw_cs_prog_data) - offset))
+ return false;
+
+ return true;
+}
diff --git a/src/mesa/drivers/dri/i965/brw_cs.h
b/src/mesa/drivers/dri/i965/brw_cs.h
index 0e9e65a..e2c9779 100644
--- a/src/mesa/drivers/dri/i965/brw_cs.h
+++ b/src/mesa/drivers/dri/i965/brw_cs.h
@@ -36,6 +36,8 @@ struct brw_cs_prog_key {
extern C {
#endif
+bool brw_cs_prog_data_compare(const void *a, const void *b);
+
void
brw_upload_cs_prog(struct brw_context *brw);
diff --git a/src/mesa/drivers/dri/i965/brw_state_cache.c
b/src/mesa/drivers/dri/i965/brw_state_cache.c
index 3b9d6cc..ecad6fa 100644
--- a/src/mesa/drivers/dri/i965/brw_state_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_state_cache.c
@@ -50,6 +50,7 @@
#include brw_vs.h
#include brw_wm.h
#include brw_gs.h
+#include brw_cs.h
#define FILE_DEBUG_FLAG DEBUG_STATE
@@ -363,9 +364,11 @@ brw_init_caches(struct brw_context *brw)
cache-aux_compare[BRW_CACHE_VS_PROG] = brw_vs_prog_data_compare;
cache-aux_compare[BRW_CACHE_GS_PROG] = brw_gs_prog_data_compare;
cache-aux_compare[BRW_CACHE_FS_PROG] = brw_wm_prog_data_compare;
+ cache-aux_compare[BRW_CACHE_CS_PROG] = brw_cs_prog_data_compare;
cache-aux_free[BRW_CACHE_VS_PROG] = brw_stage_prog_data_free;
cache-aux_free[BRW_CACHE_GS_PROG] = brw_stage_prog_data_free;
cache-aux_free[BRW_CACHE_FS_PROG] = brw_stage_prog_data_free;
+ cache-aux_free[BRW_CACHE_CS_PROG] = brw_stage_prog_data_free;
}
static void
--
2.1.4
___
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 11/18] i965/cs: Add BRW_NEW_CS_PROG_DATA and BRW_CACHE_CS_PROG
On Sat, Mar 14, 2015 at 9:54 PM, Jordan Justen
jordan.l.jus...@intel.com wrote:
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_context.h | 2 ++
src/mesa/drivers/dri/i965/brw_state_dump.c | 3 +++
src/mesa/drivers/dri/i965/brw_state_upload.c | 1 +
3 files changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index bfcd911..fb24f0e 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -165,6 +165,7 @@ enum brw_cache_id {
BRW_CACHE_FF_GS_PROG,
BRW_CACHE_GS_PROG,
BRW_CACHE_CLIP_PROG,
+ BRW_CACHE_CS_PROG,
BRW_MAX_CACHE
};
@@ -246,6 +247,7 @@ enum brw_state_id {
#define BRW_NEW_FF_GS_PROG_DATA (1ull BRW_CACHE_FF_GS_PROG)
#define BRW_NEW_GS_PROG_DATA(1ull BRW_CACHE_GS_PROG)
#define BRW_NEW_CLIP_PROG_DATA (1ull BRW_CACHE_CLIP_PROG)
+#define BRW_NEW_CS_PROG_DATA(1ull BRW_CACHE_CS_PROG)
#define BRW_NEW_URB_FENCE (1ull BRW_STATE_URB_FENCE)
#define BRW_NEW_FRAGMENT_PROGRAM(1ull BRW_STATE_FRAGMENT_PROGRAM)
#define BRW_NEW_GEOMETRY_PROGRAM(1ull BRW_STATE_GEOMETRY_PROGRAM)
diff --git a/src/mesa/drivers/dri/i965/brw_state_dump.c
b/src/mesa/drivers/dri/i965/brw_state_dump.c
index 8b32810..3ebe1de 100644
--- a/src/mesa/drivers/dri/i965/brw_state_dump.c
+++ b/src/mesa/drivers/dri/i965/brw_state_dump.c
@@ -490,6 +490,9 @@ dump_prog_cache(struct brw_context *brw)
case BRW_CACHE_FS_PROG:
name = FS kernel;
break;
+ case BRW_CACHE_CS_PROG:
+name = CS kernel;
+break;
default:
name = unknown;
break;
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index 024e04a..25f2ff0 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -531,6 +531,7 @@ static struct dirty_bit_map brw_bits[] = {
DEFINE_BIT(BRW_NEW_FF_GS_PROG_DATA),
DEFINE_BIT(BRW_NEW_GS_PROG_DATA),
DEFINE_BIT(BRW_NEW_CLIP_PROG_DATA),
+ DEFINE_BIT(BRW_NEW_CS_PROG_DATA),
DEFINE_BIT(BRW_NEW_URB_FENCE),
DEFINE_BIT(BRW_NEW_FRAGMENT_PROGRAM),
DEFINE_BIT(BRW_NEW_GEOMETRY_PROGRAM),
--
2.1.4
___
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 10/18] i965/cs: Add brw_cs_prog_data, brw_cs_prog_key and brw_context::cs.
On Sat, Mar 14, 2015 at 9:54 PM, Jordan Justen
jordan.l.jus...@intel.com wrote:
From: Paul Berry stereotype...@gmail.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
jordan.l.jus...@intel.com:
* Added brw_cs_prog_key structure
* Added brw_cs_prog_data::dispatch_grf_start_reg_16
* Added brw_cs_prog_data::no_8
* Added brw_cs_prog_data::local_size
* Added brw_cs_prog_data::simd_size
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_context.h | 17
src/mesa/drivers/dri/i965/brw_cs.h | 46
+
2 files changed, 63 insertions(+)
create mode 100644 src/mesa/drivers/dri/i965/brw_cs.h
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 2d4a00f..bfcd911 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -148,6 +148,7 @@ struct brw_vs_prog_key;
struct brw_vue_prog_key;
struct brw_wm_prog_key;
struct brw_wm_prog_data;
+struct brw_cs_prog_data;
enum brw_pipeline {
BRW_RENDER_PIPELINE,
@@ -427,6 +428,18 @@ struct brw_wm_prog_data {
int urb_setup[VARYING_SLOT_MAX];
};
+/* Note: brw_cs_prog_data_compare() must be updated when adding fields to
this
+ * struct!
+ */
+struct brw_cs_prog_data {
+ struct brw_stage_prog_data base;
+
+ GLuint dispatch_grf_start_reg_16;
+ bool no_8;
+ unsigned local_size[3];
+ unsigned simd_size;
+};
+
/**
* Enum representing the i965-specific vertex results that don't correspond
* exactly to any element of gl_varying_slot. The values of this enum are
@@ -1347,6 +1360,10 @@ struct brw_context
uint32_t fast_clear_op;
} wm;
+ struct {
+ struct brw_stage_state base;
+ struct brw_cs_prog_data *prog_data;
+ } cs;
struct {
uint32_t state_offset;
diff --git a/src/mesa/drivers/dri/i965/brw_cs.h
b/src/mesa/drivers/dri/i965/brw_cs.h
new file mode 100644
index 000..0e9e65a
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/brw_cs.h
@@ -0,0 +1,46 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+
+#ifndef BRW_CS_H
+#define BRW_CS_H
+
+#include brw_program.h
+
+struct brw_cs_prog_key {
+ GLuint program_string_id:32;
+ struct brw_sampler_prog_key_data tex;
+};
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+void
+brw_upload_cs_prog(struct brw_context *brw);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* BRW_CS_H */
--
2.1.4
___
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] Building Mesa for Windows using Visual Studio
Hi, I tried to use Mesa (compiled with MSVC) to run OpenGL ES content on Windows . I ran into a few problems. I don't know if this is the right way of reporting issues, but thought people may be interested to know. Here's a piece of code in functions _mesa_dlopen(const char*, int) in src\mesa\main\dlopen.h (same problem happens with function _mesa_dlsym(void *, const char *) in the same file). The original code returns NULL and doesn't load the library if the code is compiled with Visual Studio. #if defined(HAVE_DLOPEN) flags = RTLD_LAZY | RTLD_GLOBAL; /* Overriding flags at this time */ return dlopen(libname, flags); #elif defined(__MINGW32__) return LoadLibraryA(libname); #else return NULL; #endif Adding the following lines to the code resolves the problem: #elif defined(_WIN32) return LoadLibraryA(libname); Thanks, Shervin On Fri, Apr 3, 2015 at 5:38 PM, Shervin Sharifi sherv...@gmail.com wrote: Thank you for useful information. I was able to build Mesa with VS 2013 with a similar scheme with scons. Thanks, Shervin On Fri, Apr 3, 2015 at 7:01 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 3 April 2015 at 14:43, Predut, Marius marius.pre...@intel.com wrote: Just a couple of small details - mesa has a fall-back for the mentioned functions (plus others) in $(top)/include/*h. That said, I believe that the overall consensus is that building mesa with MSVC 2008, is the bare minimum, with MSVC 2013 strongly recommended. Afaik, as the VMWare guys give us the go aheadwe'll drop all the workarounds for pre-2013 versions and bump the requirement. Cheers, Emil Hmm, nice to know, but in this case the build system have to take in consideration and this is a bug or , by hand we should copy headers? Not sure I fully understand your statement here. Currently there are two types of headers - A) provide official (like) implementation, and B) that wrap around existing ones. Example: A) include/c99/* provides stdint.h co for MSVC 2012 and older as they lack the headers. B) include/c99_math.h provides compat wrapper, as MSVC 2013's math.h is not in C99 land yet. About using those - everything is handled already. Where needed the extra include is added by the build (for A) and where the code is known to be build with MSVC a header from B is used rather than the system one. Hope that clears things up. Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/18] i965: Add an INTEL_DEBUG=cs option.
On Sat, Mar 14, 2015 at 9:54 PM, Jordan Justen
jordan.l.jus...@intel.com wrote:
From: Paul Berry stereotype...@gmail.com
At the moment it's not wired up to anything. Later patches will hook
it up to the compute shader back-end.
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/intel_debug.c | 1 +
src/mesa/drivers/dri/i965/intel_debug.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_debug.c
b/src/mesa/drivers/dri/i965/intel_debug.c
index 0cb7aef..f1b9290 100644
--- a/src/mesa/drivers/dri/i965/intel_debug.c
+++ b/src/mesa/drivers/dri/i965/intel_debug.c
@@ -69,6 +69,7 @@ static const struct dri_debug_control debug_control[] = {
{ ann, DEBUG_ANNOTATION },
{ no8, DEBUG_NO8 },
{ vec4vs, DEBUG_VEC4VS },
+ { cs, DEBUG_CS },
{ NULL,0 }
};
diff --git a/src/mesa/drivers/dri/i965/intel_debug.h
b/src/mesa/drivers/dri/i965/intel_debug.h
index ed879ab..4180166 100644
--- a/src/mesa/drivers/dri/i965/intel_debug.h
+++ b/src/mesa/drivers/dri/i965/intel_debug.h
@@ -64,6 +64,7 @@ extern uint64_t INTEL_DEBUG;
#define DEBUG_ANNOTATION (1 28)
#define DEBUG_NO8 (1 29)
#define DEBUG_VEC4VS (1 30)
+#define DEBUG_CS (1 31)
#ifdef HAVE_ANDROID_PLATFORM
#define LOG_TAG INTEL-MESA
--
2.1.4
___
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] glsl: extend GLSLSkipStrictMaxUniformLimitCheck to uniform block size
On Tue, Apr 14, 2015 at 12:05:25AM +0200, Roland Scheidegger wrote: FWIW fsexceed crashes badly with llvmpipe (this is because we copy the constants into scene data, and the block size there is 64kB). I've actually wondered if it's the state tracker's job or that of the driver to ensure nothing bad happens. It is however happening due to the actual buffer being larger, the declaration in the shader is irrelevant for this crash. For me, these tests pass on llvmpipe even without this patch, but I guess it's only by accident - if I patch fsexceed to test much bigger buffer, it fails with fireworks (corruption in glibc). However with this patch llvmpipe passes - as expected - by failing to link. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/18] i965/cs: Emit gen code for CS_OPCODE_CS_TERMINATE
On Sat, Mar 14, 2015 at 9:54 PM, Jordan Justen
jordan.l.jus...@intel.com wrote:
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 11 +++
2 files changed, 12 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index faf7893..b8b26a4 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -543,6 +543,7 @@ private:
GLuint nr);
void generate_fb_write(fs_inst *inst, struct brw_reg payload);
void generate_urb_write(fs_inst *inst, struct brw_reg payload);
+ void generate_cs_terminate(fs_inst *inst);
void generate_blorp_fb_write(fs_inst *inst);
void generate_pixel_xy(struct brw_reg dst, bool is_x);
void generate_linterp(fs_inst *inst, struct brw_reg dst,
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index e086266..f25c5b9 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -367,6 +367,13 @@ fs_generator::generate_urb_write(fs_inst *inst, struct
brw_reg payload)
}
void
+fs_generator::generate_cs_terminate(fs_inst *inst)
+{
+ struct brw_reg R0 = retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD);
+ brw_cs_terminate(p, inst-base_mrf, R0);
+}
+
+void
fs_generator::generate_blorp_fb_write(fs_inst *inst)
{
brw_fb_WRITE(p,
@@ -2070,6 +2077,10 @@ fs_generator::generate_code(const cfg_t *cfg, int
dispatch_width)
GEN7_PIXEL_INTERPOLATOR_LOC_PER_SLOT_OFFSET);
break;
+ case CS_OPCODE_CS_TERMINATE:
+generate_cs_terminate(inst);
+break;
+
default:
if (inst-opcode (int) ARRAY_SIZE(opcode_descs)) {
_mesa_problem(ctx, Unsupported opcode `%s' in %s,
--
2.1.4
___
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 04/18] mesa/cs: Add compute support to update_program().
On Sat, Mar 14, 2015 at 9:54 PM, Jordan Justen
jordan.l.jus...@intel.com wrote:
From: Paul Berry stereotype...@gmail.com
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/main/state.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index dadfb3c..5d5e94d 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -101,9 +101,12 @@ update_program(struct gl_context *ctx)
ctx-_Shader-CurrentProgram[MESA_SHADER_GEOMETRY];
struct gl_shader_program *fsProg =
ctx-_Shader-CurrentProgram[MESA_SHADER_FRAGMENT];
+ const struct gl_shader_program *csProg =
+ ctx-_Shader-CurrentProgram[MESA_SHADER_COMPUTE];
const struct gl_vertex_program *prevVP = ctx-VertexProgram._Current;
const struct gl_fragment_program *prevFP = ctx-FragmentProgram._Current;
const struct gl_geometry_program *prevGP = ctx-GeometryProgram._Current;
+ const struct gl_compute_program *prevCP = ctx-ComputeProgram._Current;
GLbitfield new_state = 0x0;
/*
@@ -199,6 +202,16 @@ update_program(struct gl_context *ctx)
_mesa_reference_vertprog(ctx, ctx-VertexProgram._Current, NULL);
}
+ if (csProg csProg-LinkStatus
+csProg-_LinkedShaders[MESA_SHADER_COMPUTE]) {
+ /* Use GLSL compute shader */
+ _mesa_reference_compprog(ctx, ctx-ComputeProgram._Current,
+
gl_compute_program(csProg-_LinkedShaders[MESA_SHADER_COMPUTE]-Program));
+ } else {
+ /* no compute program */
+ _mesa_reference_compprog(ctx, ctx-ComputeProgram._Current, NULL);
+ }
+
/* Let the driver know what's happening:
*/
if (ctx-FragmentProgram._Current != prevFP) {
@@ -225,6 +238,14 @@ update_program(struct gl_context *ctx)
}
}
+ if (ctx-ComputeProgram._Current != prevCP) {
+ new_state |= _NEW_PROGRAM;
+ if (ctx-Driver.BindProgram) {
+ ctx-Driver.BindProgram(ctx, GL_COMPUTE_PROGRAM_NV,
+ (struct gl_program *)
ctx-ComputeProgram._Current);
+ }
+ }
+
return new_state;
}
--
2.1.4
___
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 07/18] i965/cs: Support CS_OPCODE_CS_TERMINATE
On Sat, Mar 14, 2015 at 9:54 PM, Jordan Justen
jordan.l.jus...@intel.com wrote:
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_defines.h | 5 +
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 11 +++
src/mesa/drivers/dri/i965/brw_shader.cpp | 2 ++
4 files changed, 19 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index da6ed5b..9c7aafa 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1102,6 +1102,11 @@ enum opcode {
* and number of SO primitives needed.
*/
GS_OPCODE_FF_SYNC_SET_PRIMITIVES,
+
+ /**
+* Terminate the compute shader.
+*/
+ CS_OPCODE_CS_TERMINATE,
};
enum brw_urb_write_flags {
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 7716529..faf7893 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -378,6 +378,7 @@ public:
bool use_2nd_half = false);
void emit_fb_writes();
void emit_urb_writes();
+ void emit_cs_terminate();
void emit_shader_time_begin();
void emit_shader_time_end();
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 5d4b166..88df0a2 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -3962,6 +3962,17 @@ fs_visitor::resolve_ud_negate(fs_reg *reg)
* If we need a proper boolean value, we have to fix it up to be 0 or ~0.
*/
void
+fs_visitor::emit_cs_terminate()
+{
+ int base_mrf = 1;
+ fs_inst *inst = emit(CS_OPCODE_CS_TERMINATE);
+ inst-base_mrf = base_mrf;
+ inst-mlen = 0;
+ inst-eot = true;
+ inst-header_present = false;
+}
+
+void
fs_visitor::resolve_bool_comparison(ir_rvalue *rvalue, fs_reg *reg)
{
assert(brw-gen = 5);
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index ff0ef4b..499bd94 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -572,6 +572,8 @@ brw_instruction_name(enum opcode op)
return gs_svb_set_dst_index;
case GS_OPCODE_FF_SYNC_SET_PRIMITIVES:
return gs_ff_sync_set_primitives;
+ case CS_OPCODE_CS_TERMINATE:
+ return cs_terminate;
}
unreachable(not reached);
--
2.1.4
___
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] Fix 32bit compilation with -Werror=implicit-function-declaration
On Monday 13 April 2015 22:32:10 Brian Paul wrote: On 04/13/2015 01:49 PM, Pali Rohár wrote: On Monday 13 April 2015 21:26:32 Pali Rohár wrote: File glapi_entrypoint.c calls memcpy() function, but does not include string.h header. So compilation can fail at error: implicit declaration of function 'memcpy'. --- src/mapi/glapi/glapi_entrypoint.c 2015-04-13 21:11:09.0 +0200 +++ src/mapi/glapi/glapi_entrypoint.c 2015-04-13 21:11:55.284118513 +0200 @@ -33,6 +33,7 @@ #include glapi/glapi_priv.h #include u_execmem.h +#include string.h #ifdef USE_X86_ASM This problem is caused by commit: https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.fre edesktop.org_mesa_mesa_commit_-3Fid-3D9fbbd60c1da4467683d935 40c64164ad337ce454d=AwIFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw- YihVMNtXt-uEsr=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8 m=cHbB4rMFT3az-q-Y6KO11a04PyYTYhOCPMZ3PAFmydss=lvCbo4YTBIN1 5kh-3Wu1-rQAsyFcdKtCE-Ywc4u_muge= which removes #include string.h from glapi_priv.h file. What configure or autogen.sh options did you use? I haven't seen this on any of my systems. -Brian If it helps here is full build log with error message: https://launchpadlibrarian.net/203127592/buildlog_ubuntu-precise-i386.mesa_10.6.0-git201504131208.36ceda4~ubuntu12.04.1_BUILDING.txt.gz Its compiled on Ubuntu 12.04 Precise box. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/18] mesa/cs: Add inline functions for dealing with compute shaders.
On Sat, Mar 14, 2015 at 9:54 PM, Jordan Justen
jordan.l.jus...@intel.com wrote:
From: Paul Berry stereotype...@gmail.com
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/program/program.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/mesa/program/program.h b/src/mesa/program/program.h
index 0b0d1ac..2d92ab2 100644
--- a/src/mesa/program/program.h
+++ b/src/mesa/program/program.h
@@ -138,6 +138,15 @@ _mesa_reference_geomprog(struct gl_context *ctx,
(struct gl_program *) prog);
}
+static inline void
+_mesa_reference_compprog(struct gl_context *ctx,
+ struct gl_compute_program **ptr,
+ struct gl_compute_program *prog)
+{
+ _mesa_reference_program(ctx, (struct gl_program **) ptr,
+ (struct gl_program *) prog);
+}
+
extern struct gl_program *
_mesa_clone_program(struct gl_context *ctx, const struct gl_program *prog);
@@ -276,6 +285,19 @@ gl_geometry_program_const(const struct gl_program *prog)
}
+static inline struct gl_compute_program *
+gl_compute_program(struct gl_program *prog)
+{
+ return (struct gl_compute_program *) prog;
+}
+
+static inline const struct gl_compute_program *
+gl_compute_program_const(const struct gl_program *prog)
+{
+ return (const struct gl_compute_program *) prog;
+}
+
+
#ifdef __cplusplus
} /* extern C */
#endif
--
2.1.4
___
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 03/18] mesa/cs: Update program.c for compute shaders.
On Sat, Mar 14, 2015 at 9:54 PM, Jordan Justen
jordan.l.jus...@intel.com wrote:
From: Paul Berry stereotype...@gmail.com
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/program/program.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c
index 3c214d5..ba22a51 100644
--- a/src/mesa/program/program.c
+++ b/src/mesa/program/program.c
@@ -101,6 +101,8 @@ _mesa_init_program(struct gl_context *ctx)
_mesa_reference_geomprog(ctx, ctx-GeometryProgram.Current,
NULL);
+ _mesa_reference_compprog(ctx, ctx-ComputeProgram.Current, NULL);
+
/* XXX probably move this stuff */
ctx-ATIFragmentShader.Enabled = GL_FALSE;
ctx-ATIFragmentShader.Current = ctx-Shared-DefaultFragmentShader;
@@ -120,6 +122,7 @@ _mesa_free_program_data(struct gl_context *ctx)
_mesa_reference_fragprog(ctx, ctx-FragmentProgram.Current, NULL);
_mesa_delete_shader_cache(ctx, ctx-FragmentProgram.Cache);
_mesa_reference_geomprog(ctx, ctx-GeometryProgram.Current, NULL);
+ _mesa_reference_compprog(ctx, ctx-ComputeProgram.Current, NULL);
/* XXX probably move this stuff */
if (ctx-ATIFragmentShader.Current) {
--
2.1.4
___
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 v2 05/24] mesa: glGetProgramResourceIndex
On 04/13/2015 03:29 PM, Martin Peres wrote:
On 01/04/15 15:14, Tapani Pälli wrote:
Patch adds required helper functions to shaderapi.h and
the actual implementation.
v2: code cleanup (Ilia Mirkin)
corresponding Piglit test:
arb_program_interface_query-resource-index
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/program_resource.c | 85
-
src/mesa/main/shader_query.cpp | 91
src/mesa/main/shaderapi.h| 8
3 files changed, 183 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/program_resource.c
b/src/mesa/main/program_resource.c
index 0da934a..72cc558 100644
--- a/src/mesa/main/program_resource.c
+++ b/src/mesa/main/program_resource.c
@@ -150,11 +150,94 @@ _mesa_GetProgramInterfaceiv(GLuint program,
GLenum programInterface,
}
}
+static bool
+is_xfb_marker(const char *str)
+{
+ static const char *markers[] = {
+ gl_NextBuffer,
+ gl_SkipComponents1,
+ gl_SkipComponents2,
+ gl_SkipComponents3,
+ gl_SkipComponents4,
+ NULL
+ };
+ const char **m = markers;
+
+ if (strncmp(str, gl_, 3) != 0)
+ return false;
Is this is speed improvement? It makes sense, although the performance
of GetProgramResourceIndexis not critical.
Yep, this is only to speed things up a bit, proposed by Ilia. I think it
is good as it is simple and generic check.
+
+ for (; *m; m++)
+ if (strcmp(*m, str) == 0)
+ return true;
+
+ return false;
+}
+
+/**
+ * Checks if given name index is legal for GetProgramResourceIndex,
+ * check is written to be compatible with GL_ARB_array_of_arrays.
+ */
+static bool
+valid_program_resource_index_name(const GLchar *name)
+{
+ const char *array = strstr(name, [);
+ const char *close = strrchr(name, ']');
+
+ /* Not array, no need for the check. */
+ if (!array)
+ return true;
+
+ /* Last array index has to be zero. */
+ if (!close || *--close != '0')
+ return false;
+
+ return true;
+}
+
GLuint GLAPIENTRY
_mesa_GetProgramResourceIndex(GLuint program, GLenum programInterface,
const GLchar *name)
{
- return 0;
+ GET_CURRENT_CONTEXT(ctx);
+ struct gl_program_resource *res;
+ struct gl_shader_program *shProg =
+ _mesa_lookup_shader_program_err(ctx, program,
+ glGetProgramResourceIndex);
+ if (!shProg || !name)
+ return GL_INVALID_INDEX;
+
+ /*
+* For the interface TRANSFORM_FEEDBACK_VARYING, the value
INVALID_INDEX
+* should be returned when querying the index assigned to the
special names
+* gl_NextBuffer, gl_SkipComponents1, gl_SkipComponents2,
+* gl_SkipComponents3, and gl_SkipComponents4.
+*/
+ if (programInterface == GL_TRANSFORM_FEEDBACK_VARYING
+ is_xfb_marker(name))
+ return GL_INVALID_INDEX;
+
+ switch (programInterface) {
+ case GL_PROGRAM_INPUT:
+ case GL_PROGRAM_OUTPUT:
+ case GL_UNIFORM:
+ case GL_UNIFORM_BLOCK:
+ case GL_TRANSFORM_FEEDBACK_VARYING:
+ /* Validate name syntax for arrays. */
+ if (!valid_program_resource_index_name(name))
+ return GL_INVALID_INDEX;
+
+ res = _mesa_program_resource_find_name(shProg,
programInterface, name);
+ if (!res)
+ return GL_INVALID_INDEX;
+
+ return _mesa_program_resource_index(shProg, res);
+ case GL_ATOMIC_COUNTER_BUFFER:
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM, glGetProgramResourceIndex(%s),
+ _mesa_lookup_enum_by_nr(programInterface));
+ }
+
+ return GL_INVALID_INDEX;
}
void GLAPIENTRY
diff --git a/src/mesa/main/shader_query.cpp
b/src/mesa/main/shader_query.cpp
index 4e0247e..61eec68 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -557,3 +557,94 @@ _mesa_program_resource_array_size(struct
gl_program_resource *res)
}
return 0;
}
+
+static int
+array_index_of_resource(struct gl_program_resource *res,
+const char *name)
+{
+ assert(res-Data);
+
+ switch (res-Type) {
+ case GL_PROGRAM_INPUT:
+ case GL_PROGRAM_OUTPUT:
+ return get_matching_index(RESOURCE_VAR(res), name);
+ default:
+ assert(!support for resource type not implemented);
+ }
+}
+
+/* Find a program resource with specific name in given interface.
+ */
+struct gl_program_resource *
+_mesa_program_resource_find_name(struct gl_shader_program *shProg,
+ GLenum interface, const char *name)
+{
+ struct gl_program_resource *res = shProg-ProgramResourceList;
+ for (unsigned i = 0; i shProg-NumProgramResourceList; i++,
res++) {
+ if (res-Type != interface)
+ continue;
+
+ /* Resource basename. */
+ const char *rname = _mesa_program_resource_name(res);
+ unsigned baselen = strlen(rname);
+
+ switch (interface) {
+ case GL_TRANSFORM_FEEDBACK_VARYING:
+ case GL_UNIFORM_BLOCK:
+ case
Re: [Mesa-dev] [PATCH 1/4] gallium/ttn: add support for texture offsets
On Mon, Apr 13, 2015 at 1:34 PM, Eric Anholt e...@anholt.net wrote:
Rob Clark robdcl...@gmail.com writes:
From: Rob Clark robcl...@freedesktop.org
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 9d988b06..c9f9e03 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -982,7 +982,7 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
struct tgsi_full_instruction *tgsi_inst = c-token-FullInstruction;
nir_tex_instr *instr;
nir_texop op;
- unsigned num_srcs, samp = 1;
+ unsigned num_srcs, samp = 1, i;
switch (tgsi_inst-Instruction.Opcode) {
case TGSI_OPCODE_TEX:
@@ -1026,6 +1026,8 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
num_srcs++;
}
+ num_srcs += tgsi_inst-Texture.NumOffsets;
+
instr = nir_tex_instr_create(b-shader, num_srcs);
instr-op = op;
@@ -1103,6 +1105,32 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
src_number++;
}
+ for (i = 0; i tgsi_inst-Texture.NumOffsets; i++) {
+ struct tgsi_texture_offset *tex_offset = tgsi_inst-TexOffsets[i];
+ /* since TexOffset ins't using tgsi_full_src_register we get to
+ * do some extra gymnastics:
+ */
+ nir_alu_src src;
+
+ memset(src, 0, sizeof(src));
+
+ src.src = ttn_src_for_file_and_index(c,
+ tex_offset-File,
+ tex_offset-Index,
+ NULL);
+
+ src.swizzle[0] = tex_offset-SwizzleX;
+ src.swizzle[1] = tex_offset-SwizzleY;
+ src.swizzle[2] = tex_offset-SwizzleZ;
+ src.swizzle[3] = TGSI_SWIZZLE_W;
+
+ nir_ssa_def *off = nir_fmov_alu(b, src, instr-coord_components);
For a cubemap array, won't coord_components be 4, but you only want a
3-component value as the offset? I'm suspicious of this fixed SWIZZLE_W
here. If you move the .src_type setting above this, you could use
nir_tex_instr_src_size(instr, src_number) to get the right number of
components.
hmm, yeah I suppose offsets don't apply to array index..
BR,
-R
+
+ instr-src[src_number].src = nir_src_for_ssa(off);
+ instr-src[src_number].src_type = nir_tex_src_offset;
+ src_number++;
+ }
+
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 86701] [regression] weston-simple-egl not running anymore inside qemu
https://bugs.freedesktop.org/show_bug.cgi?id=86701 --- Comment #10 from Manuel Bachmann manuel.bachm...@open.eurogiciel.org --- This is a very important feature for us, too. Reading the upstream thread, it seems there were legitimate reasons to remove egl-gallium, but bringing egl_dri2 to feature parity before doing that was ignored. This needs insight from a proficient developer. Will try to help but have few experience personally. Distro-side, we will probably stick to an older Mesa until a solution is found. -- 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 86701] [regression] weston-simple-egl not running anymore inside qemu
https://bugs.freedesktop.org/show_bug.cgi?id=86701 --- Comment #11 from Marek Olšák mar...@gmail.com --- Is it the EGL_WL_bind_wayland_display extension that you'd like to have or something else? I'd like to understand exactly what is missing. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] gallium/ttn: add support for texture offsets
Rob Clark robdcl...@gmail.com writes:
From: Rob Clark robcl...@freedesktop.org
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 9d988b06..c9f9e03 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -982,7 +982,7 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
struct tgsi_full_instruction *tgsi_inst = c-token-FullInstruction;
nir_tex_instr *instr;
nir_texop op;
- unsigned num_srcs, samp = 1;
+ unsigned num_srcs, samp = 1, i;
switch (tgsi_inst-Instruction.Opcode) {
case TGSI_OPCODE_TEX:
@@ -1026,6 +1026,8 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
num_srcs++;
}
+ num_srcs += tgsi_inst-Texture.NumOffsets;
+
instr = nir_tex_instr_create(b-shader, num_srcs);
instr-op = op;
@@ -1103,6 +1105,32 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
src_number++;
}
+ for (i = 0; i tgsi_inst-Texture.NumOffsets; i++) {
+ struct tgsi_texture_offset *tex_offset = tgsi_inst-TexOffsets[i];
+ /* since TexOffset ins't using tgsi_full_src_register we get to
+ * do some extra gymnastics:
+ */
+ nir_alu_src src;
+
+ memset(src, 0, sizeof(src));
+
+ src.src = ttn_src_for_file_and_index(c,
+ tex_offset-File,
+ tex_offset-Index,
+ NULL);
+
+ src.swizzle[0] = tex_offset-SwizzleX;
+ src.swizzle[1] = tex_offset-SwizzleY;
+ src.swizzle[2] = tex_offset-SwizzleZ;
+ src.swizzle[3] = TGSI_SWIZZLE_W;
+
+ nir_ssa_def *off = nir_fmov_alu(b, src, instr-coord_components);
For a cubemap array, won't coord_components be 4, but you only want a
3-component value as the offset? I'm suspicious of this fixed SWIZZLE_W
here. If you move the .src_type setting above this, you could use
nir_tex_instr_src_size(instr, src_number) to get the right number of
components.
+
+ instr-src[src_number].src = nir_src_for_ssa(off);
+ instr-src[src_number].src_type = nir_tex_src_offset;
+ src_number++;
+ }
+
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 02/24] glapi: add GL_ARB_program_interface_query skeleton
On 01/04/15 15:14, Tapani Pälli wrote: v2: update dispatch_sanity test (Jason Ekstrand) + small code cleanups v3: xml and Makefile fixes (Ilia Mirkin, Matt Turner) Signed-off-by: Tapani Pälli tapani.pa...@intel.com Reviewed-by: Matt Turner matts...@gmail.com --- src/mapi/glapi/gen/ARB_program_interface_query.xml | 109 + src/mapi/glapi/gen/gl_API.xml | 4 +- src/mapi/glapi/gen/gl_genexec.py | 1 + src/mesa/Makefile.sources | 2 + src/mesa/main/program_resource.c | 68 + src/mesa/main/program_resource.h | 58 +++ src/mesa/main/tests/dispatch_sanity.cpp| 12 +-- 7 files changed, 247 insertions(+), 7 deletions(-) create mode 100644 src/mapi/glapi/gen/ARB_program_interface_query.xml create mode 100644 src/mesa/main/program_resource.c create mode 100644 src/mesa/main/program_resource.h diff --git a/src/mapi/glapi/gen/ARB_program_interface_query.xml b/src/mapi/glapi/gen/ARB_program_interface_query.xml new file mode 100644 index 000..59eb59c --- /dev/null +++ b/src/mapi/glapi/gen/ARB_program_interface_query.xml @@ -0,0 +1,109 @@ +?xml version=1.0? +!DOCTYPE OpenGLAPI SYSTEM gl_API.dtd + +OpenGLAPI + +category name=GL_ARB_program_interface_query number=134 + +enum name=UNIFORM value=0x92E1/ +enum name=UNIFORM_BLOCK value=0x92E2/ +enum name=PROGRAM_INPUT value=0x92E3/ +enum name=PROGRAM_OUTPUT value=0x92E4/ +enum name=BUFFER_VARIABLE value=0x92E5/ +enum name=SHADER_STORAGE_BLOCK value=0x92E6/ +enum name=ATOMIC_COUNTER_BUFFER value=0x92C0/ +enum name=VERTEX_SUBROUTINE value=0x92E8/ +enum name=TESS_CONTROL_SUBROUTINE value=0x92E9/ +enum name=TESS_EVALUATION_SUBROUTINE value=0x92EA/ +enum name=GEOMETRY_SUBROUTINE value=0x92EB/ +enum name=FRAGMENT_SUBROUTINE value=0x92EC/ +enum name=COMPUTE_SUBROUTINE value=0x92ED/ +enum name=VERTEX_SUBROUTINE_UNIFORM value=0x92EE/ +enum name=TESS_CONTROL_SUBROUTINE_UNIFORM value=0x92EF/ +enum name=TESS_EVALUATION_SUBROUTINE_UNIFORM value=0x92F0/ +enum name=GEOMETRY_SUBROUTINE_UNIFORM value=0x92F1/ +enum name=FRAGMENT_SUBROUTINE_UNIFORM value=0x92F2/ +enum name=COMPUTE_SUBROUTINE_UNIFORM value=0x92F3/ +enum name=TRANSFORM_FEEDBACK_VARYING value=0x92F4/ +enum name=ACTIVE_RESOURCES value=0x92F5/ +enum name=MAX_NAME_LENGTH value=0x92F6/ +enum name=MAX_NUM_ACTIVE_VARIABLES value=0x92F7/ +enum name=MAX_NUM_COMPATIBLE_SUBROUTINES value=0x92F8/ +enum name=NAME_LENGTH value=0x92F9/ +enum name=TYPE value=0x92FA/ +enum name=ARRAY_SIZE value=0x92FB/ +enum name=OFFSET value=0x92FC/ +enum name=BLOCK_INDEX value=0x92FD/ +enum name=ARRAY_STRIDE value=0x92FE/ +enum name=MATRIX_STRIDE value=0x92FF/ +enum name=IS_ROW_MAJOR value=0x9300/ +enum name=ATOMIC_COUNTER_BUFFER_INDEX value=0x9301/ +enum name=BUFFER_BINDING value=0x9302/ +enum name=BUFFER_DATA_SIZE value=0x9303/ +enum name=NUM_ACTIVE_VARIABLES value=0x9304/ +enum name=ACTIVE_VARIABLES value=0x9305/ +enum name=REFERENCED_BY_VERTEX_SHADER value=0x9306/ +enum name=REFERENCED_BY_TESS_CONTROL_SHADER value=0x9307/ +enum name=REFERENCED_BY_TESS_EVALUATION_SHADER value=0x9308/ +enum name=REFERENCED_BY_GEOMETRY_SHADER value=0x9309/ +enum name=REFERENCED_BY_FRAGMENT_SHADER value=0x930A/ +enum name=REFERENCED_BY_COMPUTE_SHADER value=0x930B/ +enum name=TOP_LEVEL_ARRAY_SIZE value=0x930C/ +enum name=TOP_LEVEL_ARRAY_STRIDE value=0x930D/ +enum name=LOCATION value=0x930E/ +enum name=LOCATION_INDEX
[Mesa-dev] [Bug 71591] Second Life shaders fail to compile (extension declared in middle of shader)
https://bugs.freedesktop.org/show_bug.cgi?id=71591 --- Comment #12 from Kenneth Graunke kenn...@whitecape.org --- http://lists.freedesktop.org/archives/mesa-dev/2015-April/081576.html -- 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 03/24] mesa/glsl: build list of program resources during linking
On 04/13/2015 12:15 PM, Martin Peres wrote:
On 01/04/15 15:14, Tapani Pälli wrote:
Patch adds ProgramResourceList to gl_shader_program structure.
List contains references to active program resources and is
constructed during linking phase.
This list will be used by follow-up patches to implement hooks
for GL_ARB_program_interface_query. It can be also used to
implement any of the older shader program query APIs.
v2: code cleanups + note for SSBO and subroutines (Ilia Mirkin)
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/linker.cpp | 179
++
src/mesa/main/mtypes.h| 14
src/mesa/main/shaderobj.c | 6 ++
3 files changed, 199 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 73432b2..a757425 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2492,6 +2492,181 @@ check_explicit_uniform_locations(struct
gl_context *ctx,
delete uniform_map;
}
+static bool
+add_program_resource(struct gl_shader_program *prog, GLenum type,
+ const void *data, uint8_t stages)
+{
+ assert(data);
+
+ /* If resource already exists, do not add it again. */
+ for (unsigned i = 0; i prog-NumProgramResourceList; i++)
+ if (prog-ProgramResourceList[i].Data == data)
+ return true;
+
+ prog-ProgramResourceList =
+ reralloc(prog,
+ prog-ProgramResourceList,
+ gl_program_resource,
+ prog-NumProgramResourceList + 1);
+
+ if (!prog-ProgramResourceList) {
+ linker_error(prog, Out of memory during linking.\n);
+ return false;
+ }
+
+ struct gl_program_resource *res =
+ prog-ProgramResourceList[prog-NumProgramResourceList];
+
+ res-Type = type;
+ res-Data = data;
+ res-StageReferences = stages;
+
+ prog-NumProgramResourceList++;
+
+ return true;
+}
+
+/**
+ * Function builds a stage reference bitmask from variable name.
+ */
+static uint8_t
Could this become a uint16_t? With both tessellation, compute and
geometry, we are getting close to a 8.
If it is a little tricky, then adding an assert somewhere to make sure
that MESA_SHADER_STAGES 8 would be great (along with a comment saying
what needs to be changed).
Sure, I'll add the assertion to be safe. Then if there will ever be new
shader stages the type can be revisited.
+build_stageref(struct gl_shader_program *shProg, const char *name)
+{
+ uint8_t stages = 0;
+ for (unsigned i = 0; i MESA_SHADER_STAGES; i++) {
+ struct gl_shader *sh = shProg-_LinkedShaders[i];
+ if (!sh)
+ continue;
+ ir_variable *var = sh-symbols-get_variable(name);
+ if (var)
+ stages |= (1 i);
+ }
+ return stages;
+}
+
+/**
+ * Builds up a list of program resources that point to existing
+ * resource data.
+ */
+static void
+build_program_resource_list(struct gl_context *ctx,
+struct gl_shader_program *shProg)
+{
+ /* Rebuild resource list. */
+ if (shProg-ProgramResourceList) {
+ ralloc_free(shProg-ProgramResourceList);
+ shProg-ProgramResourceList = NULL;
+ shProg-NumProgramResourceList = 0;
+ }
+
+ int input_stage = MESA_SHADER_STAGES, output_stage = 0;
+
+ /* Determine first input and final output stage. These are used to
+* detect which variables should be enumerated in the resource list
+* for GL_PROGRAM_INPUT and GL_PROGRAM_OUTPUT.
+*/
+ for (unsigned i = 0; i MESA_SHADER_STAGES; i++) {
+ struct gl_shader *sh = shProg-_LinkedShaders[i];
No need for this intermediate variable.
will remove
+ if (!sh)
+ continue;
+ if (input_stage == MESA_SHADER_STAGES)
+ input_stage = i;
+ output_stage = i;
+ }
+
+ for (int i = 0; i MESA_SHADER_STAGES; i++) {
+ struct gl_shader *sh = shProg-_LinkedShaders[i];
+
+ if (!sh || (i != input_stage i != output_stage))
This looks like an ugly way for not creating a function called once of
input_stage and once on output_stage. Given the length of the function,
this would not be a bad idea to move the following hunk to a separate
function anyway.
OK, I'll refactor this part.
+ continue;
+
+ /* Add inputs and outputs to the resource list. */
+ foreach_in_list(ir_instruction, node, sh-ir) {
+ ir_variable *var = node-as_variable();
+ GLenum iface;
+
+ if (!var)
+continue;
+
+ switch (var-data.mode) {
+ /* From GL 4.3 core spec, section 11.1.1 (Vertex Attributes):
+ * For GetActiveAttrib, all active vertex shader input
variables
+ * are enumerated, including the special built-in inputs
gl_VertexID
+ * and gl_InstanceID.
+ */
+ case ir_var_system_value:
+if (var-data.location != SYSTEM_VALUE_VERTEX_ID
+var-data.location !=
SYSTEM_VALUE_VERTEX_ID_ZERO_BASE
+var-data.location != SYSTEM_VALUE_INSTANCE_ID)
+
[Mesa-dev] [Bug 71591] Second Life shaders fail to compile (extension declared in middle of shader)
https://bugs.freedesktop.org/show_bug.cgi?id=71591 --- Comment #11 from Eero Tamminen eero.t.tammi...@intel.com --- How Second Life viewer can be identified by Mesa, does it have distinctive binary name? What about Photoshop? -- 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 01/24] linker: fix varying linking if SSO program has only gs and fs
On 13/04/15 11:08, Martin Peres wrote:
On 02/04/15 13:27, Tapani Pälli wrote:
On 04/02/2015 12:36 PM, Martin Peres wrote:
On 01/04/15 15:14, Tapani Pälli wrote:
Previously linker did not take in to account case where one would
have only gs and fs (with SSO), patch adds the case by refactoring
code around assign_varying_locations. This makes sure locations for
gs get populated correctly.
This was found with some of the SSO subtests of Martin's upcoming
GetProgramInterfaceiv Piglit test which passes with the patch, no
Piglit regressions.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/linker.cpp | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 85830e6..73432b2 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2726,10 +2726,19 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
goto done;
}
- unsigned first;
- for (first = 0; first = MESA_SHADER_FRAGMENT; first++) {
- if (prog-_LinkedShaders[first] != NULL)
- break;
+ unsigned first, last;
+
+ first = MESA_SHADER_STAGES;
+ last = 0;
+
+ /* Determine first and last stage. */
+ for (unsigned i = 0; i MESA_SHADER_STAGES; i++) {
+ struct gl_shader *sh = prog-_LinkedShaders[i];
Why create this variable?
True, it is not really needed, even in the place from where this loop
was copypasted from, see patch 3 in the series :)
Ok, please get rid of it then, to eliminate the possible confusion
with another local variable later on.
+ if (!sh)
+ continue;
+ if (first == MESA_SHADER_STAGES)
+ first = i;
+ last = i;
}
if (num_tfeedback_decls != 0) {
@@ -2758,13 +2767,9 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
* ensures that inter-shader outputs written to in an earlier
stage are
* eliminated if they are (transitively) not used in a later
stage.
*/
- int last, next;
- for (last = MESA_SHADER_FRAGMENT; last = 0; last--) {
- if (prog-_LinkedShaders[last] != NULL)
- break;
- }
+ int next;
So, the above is a cleanup for finding the first and last shader stage.
It is however not necessary.
Yes, it is only cleanup to make 2 for loops as just one, can be dropped.
Let's keep it.
- if (last = 0 last MESA_SHADER_FRAGMENT) {
+ if (first MESA_SHADER_FRAGMENT) {
gl_shader *const sh = prog-_LinkedShaders[last];
if (first == MESA_SHADER_GEOMETRY) {
@@ -2776,13 +2781,14 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
* MESA_SHADER_GEOMETRY.
*/
if (!assign_varying_locations(ctx, mem_ctx, prog,
- NULL, sh,
+ NULL,
prog-_LinkedShaders[first],
The above change should not change anything because first == last ==
MESA_SHADER_GEOMETRY. Please get rid of it if I am right.
You are not right. Here last can be either GS or FS. The point of
this locations assignment call is that we do not have VS but still
want to assign locations to GS. Then only in the very last loop in
this function, varyings between GS-FS are checked.
ACK.
num_tfeedback_decls,
tfeedback_decls,
prog-Geom.VerticesIn))
goto done;
}
- if (num_tfeedback_decls != 0 || prog-SeparateShader) {
+ if (last != MESA_SHADER_FRAGMENT
+ (num_tfeedback_decls != 0 || prog-SeparateShader)) {
/* There was no fragment shader, but we still have to
assign varying
* locations for use by transform feedback.
*/
@@ -2804,7 +2810,7 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
while (do_dead_code(sh-ir, false))
;
}
- else if (first == MESA_SHADER_FRAGMENT) {
+ else if (first == MESA_SHADER_FRAGMENT first == last) {
How could first != last since fragment is the last stage anyway? Why
did
you add this test?
This can be removed, I added only to emphasize that we really do only
have one but the comment below is enough. Will remove this.
Yes, please remove it.
Actually, the last stage is not FS, it is CS. So first == last does not
have to be true when compute shaders become available. You should keep
the condition.
With this, the patch is Reviewed-by: Martin Peres
martin.pe...@linux.intel.com
/* If the program only contains a fragment shader...
*/
gl_shader *const sh = prog-_LinkedShaders[first];
___
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 v2 04/24] mesa: glGetProgramInterfaceiv
On 04/13/2015 12:27 PM, Martin Peres wrote: On 01/04/15 15:14, Tapani Pälli wrote: Patch adds required helper functions to shaderapi.h and the actual implementation. v2: code cleanup (Ilia Mirkin) fix array size fo xfb varyings validate programInterface and throw error corresponding Piglit test: arb_program_interface_query-getprograminterfaceiv Signed-off-by: Tapani Pälli tapani.pa...@intel.com --- src/mesa/main/program_resource.c | 119 +++ src/mesa/main/shader_query.cpp | 59 +++ src/mesa/main/shaderapi.h| 7 +++ 3 files changed, 185 insertions(+) diff --git a/src/mesa/main/program_resource.c b/src/mesa/main/program_resource.c index b3b93aa..0da934a 100644 8 +} + } + break; + case GL_MAX_NUM_COMPATIBLE_SUBROUTINES: Why did you add GL_MAX_NUM_COMPATIBLE_SUBROUTINE here? That's just a placeholder helper for the guy who will implement subroutine support and grep for this enum in some distant future. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 03/24] mesa/glsl: build list of program resources during linking
On 01/04/15 15:14, Tapani Pälli wrote:
Patch adds ProgramResourceList to gl_shader_program structure.
List contains references to active program resources and is
constructed during linking phase.
This list will be used by follow-up patches to implement hooks
for GL_ARB_program_interface_query. It can be also used to
implement any of the older shader program query APIs.
v2: code cleanups + note for SSBO and subroutines (Ilia Mirkin)
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/linker.cpp | 179 ++
src/mesa/main/mtypes.h| 14
src/mesa/main/shaderobj.c | 6 ++
3 files changed, 199 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 73432b2..a757425 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2492,6 +2492,181 @@ check_explicit_uniform_locations(struct gl_context *ctx,
delete uniform_map;
}
+static bool
+add_program_resource(struct gl_shader_program *prog, GLenum type,
+ const void *data, uint8_t stages)
+{
+ assert(data);
+
+ /* If resource already exists, do not add it again. */
+ for (unsigned i = 0; i prog-NumProgramResourceList; i++)
+ if (prog-ProgramResourceList[i].Data == data)
+ return true;
+
+ prog-ProgramResourceList =
+ reralloc(prog,
+ prog-ProgramResourceList,
+ gl_program_resource,
+ prog-NumProgramResourceList + 1);
+
+ if (!prog-ProgramResourceList) {
+ linker_error(prog, Out of memory during linking.\n);
+ return false;
+ }
+
+ struct gl_program_resource *res =
+ prog-ProgramResourceList[prog-NumProgramResourceList];
+
+ res-Type = type;
+ res-Data = data;
+ res-StageReferences = stages;
+
+ prog-NumProgramResourceList++;
+
+ return true;
+}
+
+/**
+ * Function builds a stage reference bitmask from variable name.
+ */
+static uint8_t
Could this become a uint16_t? With both tessellation, compute and
geometry, we are getting close to a 8.
If it is a little tricky, then adding an assert somewhere to make sure
that MESA_SHADER_STAGES 8 would be great (along with a comment saying
what needs to be changed).
+build_stageref(struct gl_shader_program *shProg, const char *name)
+{
+ uint8_t stages = 0;
+ for (unsigned i = 0; i MESA_SHADER_STAGES; i++) {
+ struct gl_shader *sh = shProg-_LinkedShaders[i];
+ if (!sh)
+ continue;
+ ir_variable *var = sh-symbols-get_variable(name);
+ if (var)
+ stages |= (1 i);
+ }
+ return stages;
+}
+
+/**
+ * Builds up a list of program resources that point to existing
+ * resource data.
+ */
+static void
+build_program_resource_list(struct gl_context *ctx,
+struct gl_shader_program *shProg)
+{
+ /* Rebuild resource list. */
+ if (shProg-ProgramResourceList) {
+ ralloc_free(shProg-ProgramResourceList);
+ shProg-ProgramResourceList = NULL;
+ shProg-NumProgramResourceList = 0;
+ }
+
+ int input_stage = MESA_SHADER_STAGES, output_stage = 0;
+
+ /* Determine first input and final output stage. These are used to
+* detect which variables should be enumerated in the resource list
+* for GL_PROGRAM_INPUT and GL_PROGRAM_OUTPUT.
+*/
+ for (unsigned i = 0; i MESA_SHADER_STAGES; i++) {
+ struct gl_shader *sh = shProg-_LinkedShaders[i];
No need for this intermediate variable.
+ if (!sh)
+ continue;
+ if (input_stage == MESA_SHADER_STAGES)
+ input_stage = i;
+ output_stage = i;
+ }
+
+ for (int i = 0; i MESA_SHADER_STAGES; i++) {
+ struct gl_shader *sh = shProg-_LinkedShaders[i];
+
+ if (!sh || (i != input_stage i != output_stage))
This looks like an ugly way for not creating a function called once of
input_stage and once on output_stage. Given the length of the function,
this would not be a bad idea to move the following hunk to a separate
function anyway.
+ continue;
+
+ /* Add inputs and outputs to the resource list. */
+ foreach_in_list(ir_instruction, node, sh-ir) {
+ ir_variable *var = node-as_variable();
+ GLenum iface;
+
+ if (!var)
+continue;
+
+ switch (var-data.mode) {
+ /* From GL 4.3 core spec, section 11.1.1 (Vertex Attributes):
+ * For GetActiveAttrib, all active vertex shader input variables
+ * are enumerated, including the special built-in inputs gl_VertexID
+ * and gl_InstanceID.
+ */
+ case ir_var_system_value:
+if (var-data.location != SYSTEM_VALUE_VERTEX_ID
+var-data.location != SYSTEM_VALUE_VERTEX_ID_ZERO_BASE
+var-data.location != SYSTEM_VALUE_INSTANCE_ID)
+continue;
+ case ir_var_shader_in:
+if (i != input_stage)
+ continue;
+iface = GL_PROGRAM_INPUT;
+break;
+ case ir_var_shader_out:
+
Re: [Mesa-dev] [PATCH v2 04/24] mesa: glGetProgramInterfaceiv
On 01/04/15 15:14, Tapani Pälli wrote:
Patch adds required helper functions to shaderapi.h and
the actual implementation.
v2: code cleanup (Ilia Mirkin)
fix array size fo xfb varyings
validate programInterface and throw error
corresponding Piglit test:
arb_program_interface_query-getprograminterfaceiv
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/program_resource.c | 119 +++
src/mesa/main/shader_query.cpp | 59 +++
src/mesa/main/shaderapi.h| 7 +++
3 files changed, 185 insertions(+)
diff --git a/src/mesa/main/program_resource.c b/src/mesa/main/program_resource.c
index b3b93aa..0da934a 100644
--- a/src/mesa/main/program_resource.c
+++ b/src/mesa/main/program_resource.c
@@ -23,12 +23,131 @@
*
*/
+#include main/enums.h
+#include main/macros.h
+#include main/mtypes.h
+#include main/shaderapi.h
+#include main/shaderobj.h
#include program_resource.h
+static bool
+supported_interface_enum(GLenum iface)
+{
+ switch (iface) {
+ case GL_UNIFORM:
+ case GL_UNIFORM_BLOCK:
+ case GL_PROGRAM_INPUT:
+ case GL_PROGRAM_OUTPUT:
+ case GL_TRANSFORM_FEEDBACK_VARYING:
+ case GL_ATOMIC_COUNTER_BUFFER:
+ return true;
+ case GL_VERTEX_SUBROUTINE:
+ case GL_TESS_CONTROL_SUBROUTINE:
+ case GL_TESS_EVALUATION_SUBROUTINE:
+ case GL_GEOMETRY_SUBROUTINE:
+ case GL_FRAGMENT_SUBROUTINE:
+ case GL_COMPUTE_SUBROUTINE:
+ case GL_VERTEX_SUBROUTINE_UNIFORM:
+ case GL_TESS_CONTROL_SUBROUTINE_UNIFORM:
+ case GL_TESS_EVALUATION_SUBROUTINE_UNIFORM:
+ case GL_GEOMETRY_SUBROUTINE_UNIFORM:
+ case GL_FRAGMENT_SUBROUTINE_UNIFORM:
+ case GL_COMPUTE_SUBROUTINE_UNIFORM:
+ case GL_BUFFER_VARIABLE:
+ case GL_SHADER_STORAGE_BLOCK:
Thanks for doing this :)
+ default:
+ return false;
+ }
+}
+
void GLAPIENTRY
_mesa_GetProgramInterfaceiv(GLuint program, GLenum programInterface,
GLenum pname, GLint *params)
{
+ GET_CURRENT_CONTEXT(ctx);
+ unsigned i;
+ struct gl_shader_program *shProg =
+ _mesa_lookup_shader_program_err(ctx, program,
+ glGetProgramInterfaceiv);
+ if (!shProg)
+ return;
+
+ if (!params) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glGetProgramInterfaceiv(params NULL));
+ return;
+ }
+
+ /* Validate interface. */
+ if (!supported_interface_enum(programInterface)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION, glGetProgramInterfaceiv(%s),
+ _mesa_lookup_enum_by_nr(programInterface));
+ return;
+ }
+
+ /* Validate pname against interface. */
+ switch(pname) {
+ case GL_ACTIVE_RESOURCES:
+ for (i = 0, *params = 0; i shProg-NumProgramResourceList; i++)
+ if (shProg-ProgramResourceList[i].Type == programInterface)
+(*params)++;
+ break;
+ case GL_MAX_NAME_LENGTH:
+ if (programInterface == GL_ATOMIC_COUNTER_BUFFER) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glGetProgramInterfaceiv(%s pname %s),
+ _mesa_lookup_enum_by_nr(programInterface),
+ _mesa_lookup_enum_by_nr(pname));
+ return;
+ }
+ /* Name length consists of base name, 3 additional chars '[0]' if
+ * resource is an array and finally 1 char for string terminator.
+ */
+ for (i = 0, *params = 0; i shProg-NumProgramResourceList; i++) {
+ if (shProg-ProgramResourceList[i].Type != programInterface)
+continue;
+ const char *name =
+_mesa_program_resource_name(shProg-ProgramResourceList[i]);
+ unsigned array_size =
+_mesa_program_resource_array_size(shProg-ProgramResourceList[i]);
+ *params = MAX2(*params, strlen(name) + (array_size ? 3 : 0) + 1);
+ }
+ break;
+ case GL_MAX_NUM_ACTIVE_VARIABLES:
+ switch (programInterface) {
+ case GL_UNIFORM_BLOCK:
+ for (i = 0, *params = 0; i shProg-NumProgramResourceList; i++) {
+if (shProg-ProgramResourceList[i].Type == programInterface) {
+ struct gl_uniform_block *block =
+ (struct gl_uniform_block *)
+ shProg-ProgramResourceList[i].Data;
+ *params = MAX2(*params, block-NumUniforms);
+}
+ }
+ break;
+ case GL_ATOMIC_COUNTER_BUFFER:
+ for (i = 0, *params = 0; i shProg-NumProgramResourceList; i++) {
+if (shProg-ProgramResourceList[i].Type == programInterface) {
+ struct gl_active_atomic_buffer *buffer =
+ (struct gl_active_atomic_buffer *)
+ shProg-ProgramResourceList[i].Data;
+ *params = MAX2(*params, buffer-NumUniforms);
+}
+ }
+ break;
+ case GL_MAX_NUM_COMPATIBLE_SUBROUTINES:
Why did you add GL_MAX_NUM_COMPATIBLE_SUBROUTINE here?
+ default:
+
Re: [Mesa-dev] [PATCH v2 01/24] linker: fix varying linking if SSO program has only gs and fs
On 02/04/15 13:27, Tapani Pälli wrote:
On 04/02/2015 12:36 PM, Martin Peres wrote:
On 01/04/15 15:14, Tapani Pälli wrote:
Previously linker did not take in to account case where one would
have only gs and fs (with SSO), patch adds the case by refactoring
code around assign_varying_locations. This makes sure locations for
gs get populated correctly.
This was found with some of the SSO subtests of Martin's upcoming
GetProgramInterfaceiv Piglit test which passes with the patch, no
Piglit regressions.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/linker.cpp | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 85830e6..73432b2 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2726,10 +2726,19 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
goto done;
}
- unsigned first;
- for (first = 0; first = MESA_SHADER_FRAGMENT; first++) {
- if (prog-_LinkedShaders[first] != NULL)
- break;
+ unsigned first, last;
+
+ first = MESA_SHADER_STAGES;
+ last = 0;
+
+ /* Determine first and last stage. */
+ for (unsigned i = 0; i MESA_SHADER_STAGES; i++) {
+ struct gl_shader *sh = prog-_LinkedShaders[i];
Why create this variable?
True, it is not really needed, even in the place from where this loop
was copypasted from, see patch 3 in the series :)
Ok, please get rid of it then, to eliminate the possible confusion with
another local variable later on.
+ if (!sh)
+ continue;
+ if (first == MESA_SHADER_STAGES)
+ first = i;
+ last = i;
}
if (num_tfeedback_decls != 0) {
@@ -2758,13 +2767,9 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
* ensures that inter-shader outputs written to in an earlier
stage are
* eliminated if they are (transitively) not used in a later
stage.
*/
- int last, next;
- for (last = MESA_SHADER_FRAGMENT; last = 0; last--) {
- if (prog-_LinkedShaders[last] != NULL)
- break;
- }
+ int next;
So, the above is a cleanup for finding the first and last shader stage.
It is however not necessary.
Yes, it is only cleanup to make 2 for loops as just one, can be dropped.
Let's keep it.
- if (last = 0 last MESA_SHADER_FRAGMENT) {
+ if (first MESA_SHADER_FRAGMENT) {
gl_shader *const sh = prog-_LinkedShaders[last];
if (first == MESA_SHADER_GEOMETRY) {
@@ -2776,13 +2781,14 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
* MESA_SHADER_GEOMETRY.
*/
if (!assign_varying_locations(ctx, mem_ctx, prog,
- NULL, sh,
+ NULL,
prog-_LinkedShaders[first],
The above change should not change anything because first == last ==
MESA_SHADER_GEOMETRY. Please get rid of it if I am right.
You are not right. Here last can be either GS or FS. The point of this
locations assignment call is that we do not have VS but still want to
assign locations to GS. Then only in the very last loop in this
function, varyings between GS-FS are checked.
ACK.
num_tfeedback_decls,
tfeedback_decls,
prog-Geom.VerticesIn))
goto done;
}
- if (num_tfeedback_decls != 0 || prog-SeparateShader) {
+ if (last != MESA_SHADER_FRAGMENT
+ (num_tfeedback_decls != 0 || prog-SeparateShader)) {
/* There was no fragment shader, but we still have to
assign varying
* locations for use by transform feedback.
*/
@@ -2804,7 +2810,7 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
while (do_dead_code(sh-ir, false))
;
}
- else if (first == MESA_SHADER_FRAGMENT) {
+ else if (first == MESA_SHADER_FRAGMENT first == last) {
How could first != last since fragment is the last stage anyway? Why did
you add this test?
This can be removed, I added only to emphasize that we really do only
have one but the comment below is enough. Will remove this.
Yes, please remove it.
With this, the patch is Reviewed-by: Martin Peres
martin.pe...@linux.intel.com
/* If the program only contains a fragment shader...
*/
gl_shader *const sh = prog-_LinkedShaders[first];
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/11] i965: Fix textureSize for Lod 0 with non-mipmap filters
Hi Ben,
On Fri, 2015-04-10 at 15:34 -0700, Ben Widawsky wrote:
On Tue, Feb 10, 2015 at 04:40:48PM +0100, Eduardo Lima Mitev wrote:
From: Iago Toral Quiroga ito...@igalia.com
Currently, when the MinFilter is GL_LINEAR or GL_NEAREST we hide the
actual miplevel count from the hardware (and we avoid re-creating
the miptree structure with all the levels), since we don't expect
levels other than the base level to be needed. Unfortunately,
GLSL's textureSize() function is an exception to this rule. This
function takes a lod parameter that we need to use to return the
size of the appropriate miplevel (if it exists). The spec only
requires that the miplevel exists, so even if the sampler is
configured with a linear or nearest MinFilter, as far as the user
has uploaded miplevels for the texture, textureSize() should return
the appropriate sizes.
This patch fixes this by exposing the actual miplevel count for all
sampling engine textures while keeping the original implementation
for render targets (for render targets textures we do not provide
the miplevel count but the actual LOD we are wrting to, so we
want to make sure that we make this the base level).
Fixes 28 dEQP tests in the following category:
dEQP-GLES3.functional.shaders.texture_functions.texturesize.*
---
src/mesa/drivers/dri/i965/intel_tex_validate.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_tex_validate.c
b/src/mesa/drivers/dri/i965/intel_tex_validate.c
index 0bf0393..06aeca6 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_validate.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_validate.c
@@ -47,8 +47,10 @@ intel_update_max_level(struct intel_texture_object
*intelObj,
{
struct gl_texture_object *tObj = intelObj-base;
- if (sampler-MinFilter == GL_NEAREST ||
- sampler-MinFilter == GL_LINEAR) {
+ if (!tObj-_MipmapComplete ||
+ (tObj-_RenderToTexture
+(sampler-MinFilter == GL_NEAREST ||
+ sampler-MinFilter == GL_LINEAR))) {
intelObj-_MaxLevel = tObj-BaseLevel;
} else {
intelObj-_MaxLevel = tObj-_MaxLevel;
Forgive my ignorance on this subject in advance...
I don't know if _MipmapComplete is correct here. Looking at
_mesa_test_texobj_completeness, it /seems/ like almost all the cases which
would
mark the texture as !_MipmapComplete are errors, but reading the comments for
incomplete() suggests to me there are potentially valid cases where you could
use textureSize(), but have an incomplete mipmap. IN OTHER WORDS... it seems
to
me that you may want something other than tObj-BaseLevel even when
!tObj-_MipmapComplete. Clarification would be greatly appreciated.
That was necessary to fix a piglit test regression. I don't remember
what piglit test it was, sorry :(, but I do remember the problem:
The test uploaded a mipmap-complete texture first, did some tests with
it and then it would upload level 0 again with a _different_ texture
size (which would make the texture mipmap incomplete again because all
levels other than the base would be incorrect at this point). In this
scenario only the base level is valid and we want to make sure that we
only upload that. Not doing this would led to crash in the driver at
some point later on.
Looking at the comments in incomplete(), cases 1 and 3 seem like errors
to me, and case 2 is exactly the case triggered by the piglit test I
mention above (in which we want only the base level uploaded). I think
_MipmapComplete can only be TRUE when levels other than the base level
are valid.
Make sense?
I assume the use of _MipmapComplete was what required adding the bit about
tObj-_RenderToTexture (because certain textures are considered complete even
when they're not??). I don't know enough to assert correctness for that
though.
Would be nice if you could dumb this down for me as well.
Not really, the reason to add _RenderToTexture is different, it is
related to this paragraph from the commit log:
This patch fixes this by exposing the actual miplevel count for all
sampling engine textures while keeping the original implementation for
render targets (for render targets textures we do not provide
the miplevel count but the actual LOD we are wrting to, so we
want to make sure that we make this the base level).
So what I found is that for render targets the driver wouldn't use
_MaxLevel to set the miplevel count, it would use it to select the LOD
we write to. So in this case we wanted to preserve the original behavior
to make sure that we only write to the base level when linear filters
are enabled. If we don't do this there are regressions.
These are the relevant source code and PRM references:
File gen7_wm_surface_state.c, function gen7_update_texture_surface():
surf[5] = (SET_FIELD(GEN7_MOCS_L3, GEN7_SURFACE_MOCS) |
SET_FIELD(tObj-MinLevel + tObj-BaseLevel - mt-first_level,
[Mesa-dev] [PATCH] i965: Implement proper workaround for Gen4 GPU CONSTANT_BUFFER hangs.
I finally managed to dig up some information on our mysterious GPU hangs.
A wiki page from the Crestline validation team mentions that they found
a GPU hang in Serious Sam 2 (on Windows) with remarkably similar
conditions to the ones we've seen in Google Chrome and glmark2.
Apparently, if WM_STATE has PS Use Source Depth enabled, CC_STATE has
most depth state disabled, and you issue a CONSTANT_BUFFER command and
immediately draw, the depth interpolator makes a small mistake that
leads to hangs.
Most of the traces I looked at contained a CONSTANT_BUFFER packet
immediately followed by 3DPRIMITIVE, or at least very few packets.
It appears they also have PS Use Source Depth enabled - either at the
hang, or a little before it. So I think this is our bug.
The workaround is to emit a non-pipelined state packet after issuing a
CONSTANT_BUFFER packet. This is really similar to the workaround I
developed in commit c4fd0c9052dd391d6f2e9bb8e6da209dfc7ef35b.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_curbe.c | 39 +++
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_curbe.c
b/src/mesa/drivers/dri/i965/brw_curbe.c
index e45e2ab..a773a89 100644
--- a/src/mesa/drivers/dri/i965/brw_curbe.c
+++ b/src/mesa/drivers/dri/i965/brw_curbe.c
@@ -285,19 +285,6 @@ brw_upload_constant_buffer(struct brw_context *brw)
*/
emit:
- /* Work around mysterious 965 hangs that appear to happen if you do
-* two 3DPRIMITIVEs with only a CONSTANT_BUFFER inbetween. If we
-* haven't already flushed for some other reason, explicitly do so.
-*
-* We've found no documented reason why this should be necessary.
-*/
- if (brw-gen == 4 !brw-is_g4x
- (brw-ctx.NewDriverState (BRW_NEW_BATCH | BRW_NEW_PSP)) == 0) {
- BEGIN_BATCH(1);
- OUT_BATCH(MI_FLUSH);
- ADVANCE_BATCH();
- }
-
/* BRW_NEW_URB_FENCE: From the gen4 PRM, volume 1, section 3.9.8
* (CONSTANT_BUFFER (CURBE Load)):
*
@@ -317,6 +304,31 @@ emit:
(brw-curbe.total_size - 1) + brw-curbe.curbe_offset);
}
ADVANCE_BATCH();
+
+ /* Work around a Broadwater/Crestline depth interpolator bug. The following
+* sequence will cause GPU hangs:
+*
+* 1. Change state so that all depth related fields in CC_STATE are
disabled,
+*and in WM_STATE, only PS Use Source Depth is enabled.
+* 2. Emit a CONSTANT_BUFFER packet.
+* 3. Draw via 3DPRIMITIVE.
+*
+* The recommended workaround is to emit a non-pipelined state change after
+* emitting CONSTANT_BUFFER, in order to drain the windowizer pipeline.
+*
+* We arbitrarily choose 3DSTATE_GLOBAL_DEPTH_CLAMP_OFFSET (as it's small),
+* and always emit it when PS Use Source Depth is set. We could be more
+* precise, but the additional complexity is probably not worth it.
+*
+* BRW_NEW_FRAGMENT_PROGRAM
+*/
+ const struct gl_program *fp = brw-fragment_program-Base;
+ if (brw-gen == 4 !brw-is_g4x (fp-InputsRead (1
VARYING_SLOT_POS))) {
+ BEGIN_BATCH(2);
+ OUT_BATCH(_3DSTATE_GLOBAL_DEPTH_OFFSET_CLAMP 16 | (2 - 2));
+ OUT_BATCH(0);
+ ADVANCE_BATCH();
+ }
}
const struct brw_tracked_state brw_constant_buffer = {
@@ -324,6 +336,7 @@ const struct brw_tracked_state brw_constant_buffer = {
.mesa = _NEW_PROGRAM_CONSTANTS,
.brw = BRW_NEW_BATCH |
BRW_NEW_CURBE_OFFSETS |
+ BRW_NEW_FRAGMENT_PROGRAM |
BRW_NEW_FS_PROG_DATA |
BRW_NEW_PSP | /* Implicit - hardware requires this, not used
above */
BRW_NEW_URB_FENCE |
--
2.3.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89018] Civilization: Beyond Earth terrain section not rendered
https://bugs.freedesktop.org/show_bug.cgi?id=89018 --- Comment #12 from Tapani Pälli lem...@gmail.com --- The 'terrain section not rendered' does not feel like regression, I can reproduce them with trace (comment #6) with Mesa 10.3.7 on Haswell. -- You are receiving this mail because: You are the QA Contact for the bug. 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 04/24] mesa: glGetProgramInterfaceiv
On 13/04/15 12:34, Tapani Pälli wrote: On 04/13/2015 12:27 PM, Martin Peres wrote: On 01/04/15 15:14, Tapani Pälli wrote: Patch adds required helper functions to shaderapi.h and the actual implementation. v2: code cleanup (Ilia Mirkin) fix array size fo xfb varyings validate programInterface and throw error corresponding Piglit test: arb_program_interface_query-getprograminterfaceiv Signed-off-by: Tapani Pälli tapani.pa...@intel.com --- src/mesa/main/program_resource.c | 119 +++ src/mesa/main/shader_query.cpp | 59 +++ src/mesa/main/shaderapi.h| 7 +++ 3 files changed, 185 insertions(+) diff --git a/src/mesa/main/program_resource.c b/src/mesa/main/program_resource.c index b3b93aa..0da934a 100644 8 +} + } + break; + case GL_MAX_NUM_COMPATIBLE_SUBROUTINES: Why did you add GL_MAX_NUM_COMPATIBLE_SUBROUTINE here? That's just a placeholder helper for the guy who will implement subroutine support and grep for this enum in some distant future. Ack, but why this one only? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/20] i915: Pile of fixes and cleanups
On Mon, Mar 23, 2015 at 02:47:16PM +0200, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com I've had some of these i915 patches lying around for half a year or more, so I figured it's time to post them. This series fixes rendering problems in glxgears and supertuxkart. It also fixes a few piglit tests (provoking vertex, and a few crashers). No piglit regressions on 855. Summary of the changes: * provoking vertex fixes * gen2 user fbo culling fix * some buffer handling fixes ported over from i965 * gen3 fragment shader texcoord vs. varying fix (already posted before) * random point/line rendering stuff * a bit of polish here and there Doesn't look like many people are interested in reading through these. Let me put it the other way: Anyone opposed to me just pushing these? Ville Syrjälä (20): t_dd_dmatmp: Kill the paths rendering quads/quad strips via indexed vertices t_dd_dmatmp: Allow flat shaded polygons with tri fans t_dd_dmatmp: Disallow flat shading when rendering quad strips via tri strips t_dd_dmatmp: Check provoking vertex convention when rendering quads t_dd_dmatmp: Call render_tri_fan_elts from render_poly_elts t_dd_dmatmp: Fix render_quad_strip_elts t_dd_dmatmp: Make the render_tab[]s const i915: Fix collision between I830_UPLOAD_RASTER_RULES and I830_UPLOAD_TEX(0) i915: Handle provoking vertex in intelFastRenderClippedPoly() i915: Fix t_vb_rendertmp.h's provoking vertex handywork i915: Use _tnl_RenderClippedPolygon and _tnl_RenderClippedLine i915: Make hw_prim[] const i915: Use c99 initializers for primitive arrays i915: Use COPY_DWORDS for points i915: Enable intel_render path for points i915: Adjust line size limits i915: Remember to call intel_prepare_render() before blitting i915: Drop broken front_buffer_reading/drawing optimization i915: Fix culling with user fbos on gen2 i915: Fix texcoord vs. varying collision in fragment programs src/mesa/drivers/dri/i915/i830_context.h | 8 +- src/mesa/drivers/dri/i915/i830_state.c| 2 + src/mesa/drivers/dri/i915/i915_context.h | 14 +-- src/mesa/drivers/dri/i915/i915_fragprog.c | 86 ++--- src/mesa/drivers/dri/i915/intel_buffers.c | 47 --- src/mesa/drivers/dri/i915/intel_buffers.h | 3 + src/mesa/drivers/dri/i915/intel_context.c | 16 +-- src/mesa/drivers/dri/i915/intel_context.h | 16 --- src/mesa/drivers/dri/i915/intel_fbo.c | 5 + src/mesa/drivers/dri/i915/intel_render.c | 66 +- src/mesa/drivers/dri/i915/intel_tris.c| 114 ++--- src/mesa/tnl_dd/t_dd_dmatmp.h | 196 +++--- 12 files changed, 266 insertions(+), 307 deletions(-) -- 2.0.5 -- Ville Syrjälä Intel OTC ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 04/24] mesa: glGetProgramInterfaceiv
On 04/13/2015 12:55 PM, Martin Peres wrote: On 13/04/15 12:34, Tapani Pälli wrote: On 04/13/2015 12:27 PM, Martin Peres wrote: On 01/04/15 15:14, Tapani Pälli wrote: Patch adds required helper functions to shaderapi.h and the actual implementation. v2: code cleanup (Ilia Mirkin) fix array size fo xfb varyings validate programInterface and throw error corresponding Piglit test: arb_program_interface_query-getprograminterfaceiv Signed-off-by: Tapani Pälli tapani.pa...@intel.com --- src/mesa/main/program_resource.c | 119 +++ src/mesa/main/shader_query.cpp | 59 +++ src/mesa/main/shaderapi.h| 7 +++ 3 files changed, 185 insertions(+) diff --git a/src/mesa/main/program_resource.c b/src/mesa/main/program_resource.c index b3b93aa..0da934a 100644 8 +} + } + break; + case GL_MAX_NUM_COMPATIBLE_SUBROUTINES: Why did you add GL_MAX_NUM_COMPATIBLE_SUBROUTINE here? That's just a placeholder helper for the guy who will implement subroutine support and grep for this enum in some distant future. Ack, but why this one only? I see the confusion, it's in wrong place! It should be one level higher in the switch. There are 4 supported pname's for this function and this is only one missing. // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Implement proper workaround for Gen4 GPU CONSTANT_BUFFER hangs.
Kenneth Graunke kenn...@whitecape.org writes:
I finally managed to dig up some information on our mysterious GPU hangs.
A wiki page from the Crestline validation team mentions that they found
a GPU hang in Serious Sam 2 (on Windows) with remarkably similar
conditions to the ones we've seen in Google Chrome and glmark2.
Apparently, if WM_STATE has PS Use Source Depth enabled, CC_STATE has
most depth state disabled, and you issue a CONSTANT_BUFFER command and
immediately draw, the depth interpolator makes a small mistake that
leads to hangs.
Most of the traces I looked at contained a CONSTANT_BUFFER packet
immediately followed by 3DPRIMITIVE, or at least very few packets.
It appears they also have PS Use Source Depth enabled - either at the
hang, or a little before it. So I think this is our bug.
The workaround is to emit a non-pipelined state packet after issuing a
CONSTANT_BUFFER packet. This is really similar to the workaround I
developed in commit c4fd0c9052dd391d6f2e9bb8e6da209dfc7ef35b.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_curbe.c | 39
+++
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_curbe.c
b/src/mesa/drivers/dri/i965/brw_curbe.c
index e45e2ab..a773a89 100644
--- a/src/mesa/drivers/dri/i965/brw_curbe.c
+++ b/src/mesa/drivers/dri/i965/brw_curbe.c
@@ -285,19 +285,6 @@ brw_upload_constant_buffer(struct brw_context *brw)
*/
emit:
- /* Work around mysterious 965 hangs that appear to happen if you do
-* two 3DPRIMITIVEs with only a CONSTANT_BUFFER inbetween. If we
-* haven't already flushed for some other reason, explicitly do so.
-*
-* We've found no documented reason why this should be necessary.
-*/
- if (brw-gen == 4 !brw-is_g4x
- (brw-ctx.NewDriverState (BRW_NEW_BATCH | BRW_NEW_PSP)) == 0) {
- BEGIN_BATCH(1);
- OUT_BATCH(MI_FLUSH);
- ADVANCE_BATCH();
- }
-
/* BRW_NEW_URB_FENCE: From the gen4 PRM, volume 1, section 3.9.8
* (CONSTANT_BUFFER (CURBE Load)):
*
@@ -317,6 +304,31 @@ emit:
(brw-curbe.total_size - 1) + brw-curbe.curbe_offset);
}
ADVANCE_BATCH();
+
+ /* Work around a Broadwater/Crestline depth interpolator bug. The
following
+* sequence will cause GPU hangs:
+*
+* 1. Change state so that all depth related fields in CC_STATE are
disabled,
+*and in WM_STATE, only PS Use Source Depth is enabled.
+* 2. Emit a CONSTANT_BUFFER packet.
+* 3. Draw via 3DPRIMITIVE.
+*
+* The recommended workaround is to emit a non-pipelined state change
after
+* emitting CONSTANT_BUFFER, in order to drain the windowizer pipeline.
+*
+* We arbitrarily choose 3DSTATE_GLOBAL_DEPTH_CLAMP_OFFSET (as it's
small),
+* and always emit it when PS Use Source Depth is set. We could be more
+* precise, but the additional complexity is probably not worth it.
+*
+* BRW_NEW_FRAGMENT_PROGRAM
+*/
+ const struct gl_program *fp = brw-fragment_program-Base;
+ if (brw-gen == 4 !brw-is_g4x (fp-InputsRead (1
VARYING_SLOT_POS))) {
+ BEGIN_BATCH(2);
+ OUT_BATCH(_3DSTATE_GLOBAL_DEPTH_OFFSET_CLAMP 16 | (2 - 2));
+ OUT_BATCH(0);
+ ADVANCE_BATCH();
+ }
}
const struct brw_tracked_state brw_constant_buffer = {
@@ -324,6 +336,7 @@ const struct brw_tracked_state brw_constant_buffer = {
.mesa = _NEW_PROGRAM_CONSTANTS,
.brw = BRW_NEW_BATCH |
BRW_NEW_CURBE_OFFSETS |
+ BRW_NEW_FRAGMENT_PROGRAM |
BRW_NEW_FS_PROG_DATA |
BRW_NEW_PSP | /* Implicit - hardware requires this, not used
above */
BRW_NEW_URB_FENCE |
--
2.3.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Neat,
Reviewed-by: Francisco Jerez curroje...@riseup.net
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 01/24] linker: fix varying linking if SSO program has only gs and fs
On 04/13/2015 11:18 AM, Martin Peres wrote:
On 13/04/15 11:08, Martin Peres wrote:
On 02/04/15 13:27, Tapani Pälli wrote:
On 04/02/2015 12:36 PM, Martin Peres wrote:
On 01/04/15 15:14, Tapani Pälli wrote:
Previously linker did not take in to account case where one would
have only gs and fs (with SSO), patch adds the case by refactoring
code around assign_varying_locations. This makes sure locations for
gs get populated correctly.
This was found with some of the SSO subtests of Martin's upcoming
GetProgramInterfaceiv Piglit test which passes with the patch, no
Piglit regressions.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/linker.cpp | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 85830e6..73432b2 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2726,10 +2726,19 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
goto done;
}
- unsigned first;
- for (first = 0; first = MESA_SHADER_FRAGMENT; first++) {
- if (prog-_LinkedShaders[first] != NULL)
- break;
+ unsigned first, last;
+
+ first = MESA_SHADER_STAGES;
+ last = 0;
+
+ /* Determine first and last stage. */
+ for (unsigned i = 0; i MESA_SHADER_STAGES; i++) {
+ struct gl_shader *sh = prog-_LinkedShaders[i];
Why create this variable?
True, it is not really needed, even in the place from where this loop
was copypasted from, see patch 3 in the series :)
Ok, please get rid of it then, to eliminate the possible confusion
with another local variable later on.
+ if (!sh)
+ continue;
+ if (first == MESA_SHADER_STAGES)
+ first = i;
+ last = i;
}
if (num_tfeedback_decls != 0) {
@@ -2758,13 +2767,9 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
* ensures that inter-shader outputs written to in an earlier
stage are
* eliminated if they are (transitively) not used in a later
stage.
*/
- int last, next;
- for (last = MESA_SHADER_FRAGMENT; last = 0; last--) {
- if (prog-_LinkedShaders[last] != NULL)
- break;
- }
+ int next;
So, the above is a cleanup for finding the first and last shader stage.
It is however not necessary.
Yes, it is only cleanup to make 2 for loops as just one, can be dropped.
Let's keep it.
- if (last = 0 last MESA_SHADER_FRAGMENT) {
+ if (first MESA_SHADER_FRAGMENT) {
gl_shader *const sh = prog-_LinkedShaders[last];
if (first == MESA_SHADER_GEOMETRY) {
@@ -2776,13 +2781,14 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
* MESA_SHADER_GEOMETRY.
*/
if (!assign_varying_locations(ctx, mem_ctx, prog,
- NULL, sh,
+ NULL,
prog-_LinkedShaders[first],
The above change should not change anything because first == last ==
MESA_SHADER_GEOMETRY. Please get rid of it if I am right.
You are not right. Here last can be either GS or FS. The point of
this locations assignment call is that we do not have VS but still
want to assign locations to GS. Then only in the very last loop in
this function, varyings between GS-FS are checked.
ACK.
num_tfeedback_decls,
tfeedback_decls,
prog-Geom.VerticesIn))
goto done;
}
- if (num_tfeedback_decls != 0 || prog-SeparateShader) {
+ if (last != MESA_SHADER_FRAGMENT
+ (num_tfeedback_decls != 0 || prog-SeparateShader)) {
/* There was no fragment shader, but we still have to
assign varying
* locations for use by transform feedback.
*/
@@ -2804,7 +2810,7 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
while (do_dead_code(sh-ir, false))
;
}
- else if (first == MESA_SHADER_FRAGMENT) {
+ else if (first == MESA_SHADER_FRAGMENT first == last) {
How could first != last since fragment is the last stage anyway? Why
did
you add this test?
This can be removed, I added only to emphasize that we really do only
have one but the comment below is enough. Will remove this.
Yes, please remove it.
Actually, the last stage is not FS, it is CS. So first == last does not
have to be true when compute shaders become available. You should keep
the condition.
I'm OK with both keeping or removing it. For me it looks like this
function might need quite a bit of changes here and there with CS.
With this, the patch is Reviewed-by: Martin Peres
martin.pe...@linux.intel.com
/* If the program only contains a fragment shader...
*/
gl_shader *const sh = prog-_LinkedShaders[first];
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing
[Mesa-dev] [Bug 89018] Civilization: Beyond Earth terrain section not rendered
https://bugs.freedesktop.org/show_bug.cgi?id=89018 --- Comment #13 from Fredrik Höglund fred...@kde.org --- (In reply to Ilia Mirkin from comment #11) (In reply to Tapani Pälli from comment #10) (In reply to Sami Liedes from comment #9) Ok, interesting results. I managed to get an apitrace from an fglrx-enabled machine. From it I suspect that what's missing is at least something that CivBE uses to color the terrain. Perhaps that being missing makes it misbehave in other ways, causing the black patches? The captured trace plays on mesa, but the texture looks different. Still, the black patches themselves are not present when the captured trace is replayed on mesa. Frame 205 on fglrx: http://sliedes.kapsi.fi/mesa/civbe/CivBE-fglrx-frame-205.png Same frame, replayed on mesa from the trace captured on fglrx: http://sliedes.kapsi.fi/mesa/civbe/CivBE-frame-205-cap-fglrx-rep-free.png You can get the trace (CivBE-fglrx.trace.lz) here: https://drive.google.com/file/d/0BwgPzH1WFyIuR3pZdXE3SHJRaHc/view?usp=sharing With Intel (Haswelldesktop) the colors are correct in this trace (using Mesa git at commit 50e9fa2). I get the same bad colors with nouveau (GF108/nvc1). Probably some form of gallium fail... smells like a sRGB issue. The problem is that the green channel is replicated in the blue channel. -- You are receiving this mail because: You are the QA Contact for the bug. 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 13/24] mesa: refactor GetFragDataLocation
On 01/04/15 15:14, Tapani Pälli wrote:
Use program_resource_location to fetch location.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/shader_query.cpp | 38 --
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index cbdcc61..58f5a0e 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -484,31 +484,25 @@ _mesa_GetFragDataLocation(GLuint program, const GLchar
*name)
if (shProg-_LinkedShaders[MESA_SHADER_FRAGMENT] == NULL)
return -1;
- exec_list *ir = shProg-_LinkedShaders[MESA_SHADER_FRAGMENT]-ir;
- foreach_in_list(ir_instruction, node, ir) {
- const ir_variable *const var = node-as_variable();
-
- /* The extra check against FRAG_RESULT_DATA0 is because
- * glGetFragDataLocation cannot be used on conventional attributes.
- *
- * From page 95 of the OpenGL 3.0 spec:
- *
- * If name is not an active attribute, if name is a conventional
- * attribute, or if an error occurs, -1 will be returned.
- */
- if (var == NULL
- || var-data.mode != ir_var_shader_out
- || var-data.location == -1
- || var-data.location FRAG_RESULT_DATA0)
-continue;
+ struct gl_program_resource *res =
+ _mesa_program_resource_find_name(shProg, GL_PROGRAM_OUTPUT, name);
- int index = get_matching_index(var, (const char *) name);
+ if (!res)
+ return -1;
- if (index = 0)
- return var-data.location + index - FRAG_RESULT_DATA0;
- }
+ GLint loc = program_resource_location(shProg, res, name);
- return -1;
+ /* The extra check against against 0 is made because of builtin-attribute
+* locations that have offset applied. Function program_resource_location
+* can return built-in attribute locations 0 and glGetFragDataLocation
+* cannot be used on conventional attributes.
+*
+* From page 95 of the OpenGL 3.0 spec:
+*
+* If name is not an active attribute, if name is a conventional
+* attribute, or if an error occurs, -1 will be returned.
+*/
+ return (loc = 0) ? loc : -1;
}
const char*
Great code-deduplication again.
Reviewed-by: Martin Peres martin.pe...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 22/24] mesa: refactor GetUniformLocation
On 01/04/15 15:14, Tapani Pälli wrote:
Use _mesa_program_resource_location to get location.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/uniforms.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/src/mesa/main/uniforms.c b/src/mesa/main/uniforms.c
index 8872344..0c16641 100644
--- a/src/mesa/main/uniforms.c
+++ b/src/mesa/main/uniforms.c
@@ -911,7 +911,6 @@ GLint GLAPIENTRY
_mesa_GetUniformLocation(GLuint programObj, const GLcharARB *name)
{
struct gl_shader_program *shProg;
- GLuint index, offset;
GET_CURRENT_CONTEXT(ctx);
@@ -931,23 +930,7 @@ _mesa_GetUniformLocation(GLuint programObj, const GLcharARB *name)
return -1;
}
- index = _mesa_get_uniform_location(shProg, name, offset);
- if (index == GL_INVALID_INDEX)
- return -1;
-
- /* From the GL_ARB_uniform_buffer_object spec:
-*
-* The value -1 will be returned if name does not correspond to an
-* active uniform variable name in program, if name is associated
-* with a named uniform block, or if name starts with the reserved
-* prefix gl_.
-*/
- if (shProg-UniformStorage[index].block_index != -1 ||
- shProg-UniformStorage[index].atomic_buffer_index != -1)
- return -1;
-
- /* location in remap table + array element offset */
- return shProg-UniformStorage[index].remap_location + offset;
+ return _mesa_program_resource_location(shProg, GL_UNIFORM, name);
}
GLuint GLAPIENTRY
Reviewed-by: Martin Peres martin.pe...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Always use Y-tiled buffers on SKL+
On Sat, Apr 11, 2015 at 01:16:11PM -0700, Ben Widawsky wrote:
Starting with Skylake, the display engine is capable of scanning out from
Y-tiled buffers. As such, we can and should use Y-tiling for better
efficiency.
Note that the buffer allocation done for mipmaps will already never allocate
an
X-tiled buffer for GEN9.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
You need a recent enough ddx to make use of Y-tiled buffers, which atm
still doesn't yet exist. This would at least need some kind of handshake
with the compositor to make sure it understands this, presuming I didn't
miss something.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4
src/mesa/drivers/dri/i965/intel_screen.c | 21 ++---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index eb226d5..4408ac9 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -142,6 +142,10 @@ intel_get_non_msrt_mcs_alignment(struct brw_context *brw,
*height = 4;
break;
case I915_TILING_X:
+ /* The docs are somewhat confusing with the way the tables are
displayed.
+ * However, it does clearly state: MCS and Lossless compression is
+ * supported for TiledY/TileYs/TileYf non-MSRTs only. */
+ assert(brw-gen 9);
*width_px = 64 / mt-cpp;
*height = 2;
}
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index cb9710f..06f0a06 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -510,7 +510,11 @@ intel_create_image(__DRIscreen *screen,
int cpp;
unsigned long pitch;
- tiling = I915_TILING_X;
+ if (intelScreen-devinfo-gen = 9) {
+ tiling = I915_TILING_Y;
+ } else {
+ tiling = I915_TILING_X;
+ }
if (use __DRI_IMAGE_USE_CURSOR) {
if (width != 64 || height != 64)
return NULL;
@@ -1101,8 +1105,14 @@ intel_detect_swizzling(struct intel_screen *screen)
drm_intel_bo *buffer;
unsigned long flags = 0;
unsigned long aligned_pitch;
- uint32_t tiling = I915_TILING_X;
uint32_t swizzle_mode = 0;
+ uint32_t tiling;
+
+ if (screen-devinfo-gen = 9) {
+ tiling = I915_TILING_Y;
+ } else {
+ tiling = I915_TILING_X;
+ }
Unneeded change (swizzling doesn't change between X and Y tiled) and gen9+
is hardcoded to unswizzled in the hw anyway.
-Daniel
buffer = drm_intel_bo_alloc_tiled(screen-bufmgr, swizzle test,
64, 64, 4,
@@ -1409,7 +1419,12 @@ intelAllocateBuffer(__DRIscreen *screen,
return NULL;
/* The front and back buffers are color buffers, which are X tiled. */
- uint32_t tiling = I915_TILING_X;
+ uint32_t tiling;
+ if (intelScreen-devinfo-gen = 9) {
+ tiling = I915_TILING_Y;
+ } else {
+ tiling = I915_TILING_X;
+ }
unsigned long pitch;
int cpp = format / 8;
intelBuffer-bo = drm_intel_bo_alloc_tiled(intelScreen-bufmgr,
--
2.3.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 23/24] mesa: refactor GetUniformIndices
On 01/04/15 15:14, Tapani Pälli wrote:
Use _mesa_program_resource_index to get indices.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/uniforms.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/uniforms.c b/src/mesa/main/uniforms.c
index 0c16641..f4de1df 100644
--- a/src/mesa/main/uniforms.c
+++ b/src/mesa/main/uniforms.c
@@ -986,9 +986,9 @@ _mesa_GetUniformIndices(GLuint program,
}
for (i = 0; i uniformCount; i++) {
- unsigned offset;
- uniformIndices[i] = _mesa_get_uniform_location(shProg,
-uniformNames[i], offset);
+ struct gl_program_resource *res =
+ _mesa_program_resource_find_name(shProg, GL_UNIFORM, uniformNames[i]);
+ uniformIndices[i] = _mesa_program_resource_index(shProg, res);
}
}
This should indeed be faster
Reviewed-by: Martin Peres martin.pe...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/7] i965: Refactor brw_is_hiz_depth_format()
On Fri 10 Apr 2015, Pohjolainen, Topi wrote:
On Thu, Apr 09, 2015 at 08:57:04PM -0700, Chad Versace wrote:
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index a906460..492338b 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -403,7 +403,8 @@ intel_miptree_create_layout(struct brw_context *brw,
if (!for_bo
_mesa_get_format_base_format(format) == GL_DEPTH_STENCIL
(brw-must_use_separate_stencil ||
- (brw-has_separate_stencil brw_is_hiz_depth_format(brw, format {
+ (brw-has_separate_stencil
+ intel_miptree_wants_hiz_buffer(brw, mt {
I had to check that format == mt-format, and indeed that is the case. I
noticed that we probably want to make intel_miptree_create_layout() a little
more consistent - it uses randomly both the stack variable and the one in
miptree.
I agree. For large functions like intel_miptree_create_layout(), I like
to group together all assignments to the struct at the bottom of the
function, and use stack variables until then. Otherwise, it's too easy
to accidentally use an unitialized struct field in the middle of the
function.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 04/24] mesa: glGetProgramInterfaceiv
On 13/04/15 12:58, Tapani Pälli wrote: On 04/13/2015 12:55 PM, Martin Peres wrote: On 13/04/15 12:34, Tapani Pälli wrote: On 04/13/2015 12:27 PM, Martin Peres wrote: On 01/04/15 15:14, Tapani Pälli wrote: Patch adds required helper functions to shaderapi.h and the actual implementation. v2: code cleanup (Ilia Mirkin) fix array size fo xfb varyings validate programInterface and throw error corresponding Piglit test: arb_program_interface_query-getprograminterfaceiv Signed-off-by: Tapani Pälli tapani.pa...@intel.com --- src/mesa/main/program_resource.c | 119 +++ src/mesa/main/shader_query.cpp | 59 +++ src/mesa/main/shaderapi.h| 7 +++ 3 files changed, 185 insertions(+) diff --git a/src/mesa/main/program_resource.c b/src/mesa/main/program_resource.c index b3b93aa..0da934a 100644 8 +} + } + break; + case GL_MAX_NUM_COMPATIBLE_SUBROUTINES: Why did you add GL_MAX_NUM_COMPATIBLE_SUBROUTINE here? That's just a placeholder helper for the guy who will implement subroutine support and grep for this enum in some distant future. Ack, but why this one only? I see the confusion, it's in wrong place! It should be one level higher in the switch. There are 4 supported pname's for this function and this is only one missing. // Tapani OK, perfect. Thanks :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 86701] [regression] weston-simple-egl not running anymore inside qemu
https://bugs.freedesktop.org/show_bug.cgi?id=86701 --- Comment #9 from Marko Moberg marko.s.mob...@gmail.com --- SW rastering for EGL is really an important feature for us. We have an embedded device with no GPU and no display. We are planning on using Wayland/Weston with RDP protocol to display OpenGl graphics over network connection. Current MESA doesn't seem to support this functionality. -- 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] i965/skl: Use an exec size of 8 to initialise the message header
Ben Widawsky b...@bwidawsk.net writes:
Can you do me a favor since I am lazy? Can you send the generated asm
diff with this patch? I am admittedly rusty on the matter, but I
thought a mov is just a mov, and only the regioning is effected by the
retype. If it indeed does what you say, it really should fix
something. Does this happen to allow concurrent piglit to not die in a
fire?
Here is the diff when compiling the interface-name-basic.vert shader:
--- without-patch.txt 2015-04-13 13:53:56.834861036 +0100
+++ with-patch.txt 2015-04-13 13:53:56.836861036 +0100
@@ -35,19 +35,19 @@
mov(1) g111UD0x0008UD{ align1
WE_all compacted };
mov(1) g131UD0x000cUD{ align1
WE_all compacted };
mov(8) g1231UD g18,8,1UD { align1
WE_all 1Q compacted };
-mov(4) g61UD g04,4,1UD { align1
WE_all compacted };
+mov(8) g61UD g08,8,1UD { align1
WE_all 1Q compacted };
mov(1) g6.21UD 0x0040UD{ align1
WE_all };
send(4) g61F g64,4,1UD
sampler (0, 0, 7, 0) mlen 2 rlen 1 {
align1 WE_all };
-mov(4) g81UD g04,4,1UD { align1
WE_all compacted };
+mov(8) g81UD g08,8,1UD { align1
WE_all 1Q compacted };
mov(1) g8.21UD 0x0040UD{ align1
WE_all };
send(4) g71F g84,4,1UD
sampler (0, 0, 7, 0) mlen 2 rlen 1 {
align1 WE_all };
-mov(4) g101UDg04,4,1UD { align1
WE_all compacted };
+mov(8) g101UDg08,8,1UD { align1
WE_all 1Q compacted };
mov(1) g10.21UD 0x0040UD{ align1
WE_all };
send(4) g81F g104,4,1UD
sampler (0, 0, 7, 0) mlen 2 rlen 1 {
align1 WE_all };
-mov(4) g121UDg04,4,1UD { align1
WE_all compacted };
+mov(8) g121UDg08,8,1UD { align1
WE_all 1Q compacted };
mov(1) g12.21UD 0x0040UD{ align1
WE_all };
send(4) g91F g124,4,1UD
sampler (0, 0, 7, 0) mlen 2 rlen 1 {
align1 WE_all };
I think the intention of your original patch was just to change the
width of the source in the *send* instructions to 4 instead of 8. This
was required because the send instruction is using an exec size of 4.
However it also inadvertently changed the exec size of the mov
instruction above the send to 4. My patch just puts the exec size back
to 8.
I also wonder how you don't run into the original issue that my patch
fixed. Are you getting execsize=8 on this instruction now?
No, my patch only affects the mov instruction and leaves the send
instruction as it was. Your original patch is still used to fix the
problem with the send instruction.
Regards,
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 06/24] mesa: glGetProgramResourceName
On 01/04/15 15:14, Tapani Pälli wrote:
Patch adds required helper functions to shaderapi.h and
the actual implementation.
Name generation copied from '_mesa_get_uniform_name' which can
be removed later by refactoring functions to use resource list.
The added functionality can be tested by tests for following
functions that are refactored by later patches:
GetActiveUniformName
GetActiveUniformBlockName
v2: no index for geometry shader inputs (Ilia Mirkin)
add bufSize 0 check and error out
validate enum
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/program_resource.c | 23 +
src/mesa/main/shader_query.cpp | 106 +++
src/mesa/main/shaderapi.h| 10
3 files changed, 139 insertions(+)
diff --git a/src/mesa/main/program_resource.c b/src/mesa/main/program_resource.c
index 72cc558..638f5f2 100644
--- a/src/mesa/main/program_resource.c
+++ b/src/mesa/main/program_resource.c
@@ -245,6 +245,29 @@ _mesa_GetProgramResourceName(GLuint program, GLenum
programInterface,
GLuint index, GLsizei bufSize, GLsizei *length,
GLchar *name)
{
+ GET_CURRENT_CONTEXT(ctx);
+ struct gl_shader_program *shProg =
+ _mesa_lookup_shader_program_err(ctx, program,
+ glGetProgramResourceName);
+
+ /* Set user friendly return values in case of errors. */
+ if (name)
+ *name = '\0';
+ if (length)
+ *length = 0;
+
+ if (!shProg || !name)
+ return;
+
+ if (programInterface == GL_ATOMIC_COUNTER_BUFFER ||
+ !supported_interface_enum(programInterface)) {
+ _mesa_error(ctx, GL_INVALID_ENUM, glGetProgramResourceName(%s),
+ _mesa_lookup_enum_by_nr(programInterface));
+ return;
+ }
+
+ _mesa_get_program_resource_name(shProg, programInterface, index, bufSize,
+ length, name, glGetProgramResourceName);
}
void GLAPIENTRY
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index 61eec68..ab61be9 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -648,3 +648,109 @@ _mesa_program_resource_index(struct gl_shader_program
*shProg,
return calc_resource_index(shProg, res);
}
}
+
+/* Find a program resource with specific index in given interface.
+ */
+struct gl_program_resource *
+_mesa_program_resource_find_index(struct gl_shader_program *shProg,
+ GLenum interface, GLuint index)
+{
+ struct gl_program_resource *res = shProg-ProgramResourceList;
+ int idx = -1;
+
+ for (unsigned i = 0; i shProg-NumProgramResourceList; i++, res++) {
+ if (res-Type != interface)
+ continue;
+
+ switch (res-Type) {
+ case GL_UNIFORM_BLOCK:
+ case GL_ATOMIC_COUNTER_BUFFER:
+ if (_mesa_program_resource_index(shProg, res) == index)
+return res;
+
+ case GL_TRANSFORM_FEEDBACK_VARYING:
+ case GL_PROGRAM_INPUT:
+ case GL_PROGRAM_OUTPUT:
+ case GL_UNIFORM:
+ if (++idx == (int) index)
+return res;
+ break;
+ default:
+ assert(!not implemented for given interface);
+ }
+ }
+ return NULL;
+}
+
+/* Get full name of a program resource.
+ */
+bool
+_mesa_get_program_resource_name(struct gl_shader_program *shProg,
+GLenum interface, GLuint index,
+GLsizei bufSize, GLsizei *length,
+GLchar *name, const char *caller)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ /* Find resource with given interface and index. */
+ struct gl_program_resource *res =
+ _mesa_program_resource_find_index(shProg, interface, index);
+
+ /* The error INVALID_VALUE is generated if index is greater than
+ * or equal to the number of entries in the active resource list for
+ * programInterface.
+ */
+ if (!res) {
+ _mesa_error(ctx, GL_INVALID_VALUE, %s(index %u), caller, index);
+ return false;
+ }
+
+ if (bufSize 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE, %s(bufSize %d), caller, bufSize);
+ return false;
+ }
+
+ GLsizei localLength;
+
+ if (length == NULL)
+ length = localLength;
I would have done the opposite (write the length to a local variable and
then assigned it to length if it is non-null. I'm ok with this though.
+
+ _mesa_copy_string(name, bufSize, length, _mesa_program_resource_name(res));
+
+ /* Page 61 (page 73 of the PDF) in section 2.11 of the OpenGL ES 3.0
+* spec says:
+*
+* If the active uniform is an array, the uniform name returned in
+* name will always be the name of the uniform array appended with
+* [0].
+*
+* The same text also appears in the OpenGL 4.2 spec. It does not,
+* however, appear in any previous spec. Previous specifications are
+* ambiguous in
Re: [Mesa-dev] Valve games for Mesa/DRI developers
Hi Daniel, I'm not much of a gamer myself, but I imagine that these games would be useful, real-life tests and/or entertaining benchmarks. Given that I work mostly on ARM systems, do you know if there are any plans on making these games available on ARM? I know some of Valve's games have been ported to ARM for Android, but perhaps there isn't enough of an audience to make it beneficial to get them to run on regular Linux on ARM? Thierry On Thu, Apr 09, 2015 at 06:10:42PM +0100, Daniel Stone wrote: Hi, At Collabora (my lovely dayjob), we've been working with Valve on SteamOS. Valve are keen to give back to the community, and we've been discussing ways they can help do that, including providing free access to Valve games on Steam to Debian developers last year. We're happy to say that this has been extended to Mesa developers as well, to say thanks for all the great work. If you have 25 commits or more (an arbitrary number) to Mesa[0] in the past five years, please drop me an email (with 'Steam' in the subject) with your freedesktop username and Steam username. We can then get you access to all past and future Valve-produced games available on Steam[1]. Thanks for all the great work, and enjoy. Cheers, Daniel [0]: Or DRI-type stuff in the kernel too. [1]: Currently this looks like https://store.steampowered.com/search/?snr=1_4_4__12term=#category1=998publisher=Valvesort_order=ASCpage=1 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel pgpoAv1E7XAHx.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 v2 12/24] mesa: refactor GetAttribLocation
On 01/04/15 15:14, Tapani Pälli wrote:
Use program_resource_location to fetch location.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/shader_query.cpp | 42 --
1 file changed, 20 insertions(+), 22 deletions(-)
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index 0f7804c..cbdcc61 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -41,6 +41,10 @@ extern C {
#include shaderapi.h
}
+static GLint
+program_resource_location(struct gl_shader_program *shProg,
+ struct gl_program_resource *res, const char *name);
+
/**
* Declare convenience functions to return resource data in a given type.
* Warning! this is not type safe so be *very* careful when using these.
@@ -266,31 +270,25 @@ _mesa_GetAttribLocation(GLhandleARB program, const
GLcharARB * name)
if (shProg-_LinkedShaders[MESA_SHADER_VERTEX] == NULL)
return -1;
- exec_list *ir = shProg-_LinkedShaders[MESA_SHADER_VERTEX]-ir;
- foreach_in_list(ir_instruction, node, ir) {
- const ir_variable *const var = node-as_variable();
-
- /* The extra check against VERT_ATTRIB_GENERIC0 is because
- * glGetAttribLocation cannot be used on conventional attributes.
- *
- * From page 95 of the OpenGL 3.0 spec:
- *
- * If name is not an active attribute, if name is a conventional
- * attribute, or if an error occurs, -1 will be returned.
- */
- if (var == NULL
- || var-data.mode != ir_var_shader_in
- || var-data.location == -1
- || var-data.location VERT_ATTRIB_GENERIC0)
-continue;
+ struct gl_program_resource *res =
+ _mesa_program_resource_find_name(shProg, GL_PROGRAM_INPUT, name);
- int index = get_matching_index(var, (const char *) name);
+ if (!res)
+ return -1;
- if (index = 0)
- return var-data.location + index - VERT_ATTRIB_GENERIC0;
- }
+ GLint loc = program_resource_location(shProg, res, name);
- return -1;
+ /* The extra check against against 0 is made because of builtin-attribute
+* locations that have offset applied. Function program_resource_location
+* can return built-in attribute locations 0 and glGetAttribLocation
+* cannot be used on conventional attributes.
+*
+* From page 95 of the OpenGL 3.0 spec:
+*
+* If name is not an active attribute, if name is a conventional
+* attribute, or if an error occurs, -1 will be returned.
+*/
+ return (loc = 0) ? loc : -1;
}
Great code-deduplication.
Reviewed-by: Martin Peres martin.pe...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 21/24] mesa: refactor GetActiveUniformBlockName
On 01/04/15 15:14, Tapani Pälli wrote:
Use _mesa_get_program_resource_name to get name.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/uniforms.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/src/mesa/main/uniforms.c b/src/mesa/main/uniforms.c
index 078e433..8872344 100644
--- a/src/mesa/main/uniforms.c
+++ b/src/mesa/main/uniforms.c
@@ -1168,7 +1168,6 @@ _mesa_GetActiveUniformBlockName(GLuint program,
{
GET_CURRENT_CONTEXT(ctx);
struct gl_shader_program *shProg;
- struct gl_uniform_block *block;
if (!ctx-Extensions.ARB_uniform_buffer_object) {
_mesa_error(ctx, GL_INVALID_OPERATION, glGetActiveUniformBlockiv);
@@ -1187,18 +1186,11 @@ _mesa_GetActiveUniformBlockName(GLuint program,
if (!shProg)
return;
- if (uniformBlockIndex = shProg-NumUniformBlocks) {
- _mesa_error(ctx, GL_INVALID_VALUE,
- glGetActiveUniformBlockiv(block index %u = %u),
- uniformBlockIndex, shProg-NumUniformBlocks);
- return;
- }
-
- block = shProg-UniformBlocks[uniformBlockIndex];
-
- if (uniformBlockName) {
- _mesa_copy_string(uniformBlockName, bufSize, length, block-Name);
- }
+ if (uniformBlockName)
+ _mesa_get_program_resource_name(shProg, GL_UNIFORM_BLOCK,
+ uniformBlockIndex, bufSize, length,
+ uniformBlockName,
+ glGetActiveUniformBlockName);
}
void GLAPIENTRY
Reviewed-by: Martin Peres martin.pe...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 14/24] mesa: refactor GetFragDataIndex
On 01/04/15 15:14, Tapani Pälli wrote:
Use _mesa_program_resource_location_index to fetch index.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/main/shader_query.cpp | 25 ++---
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index 58f5a0e..185e95d 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -428,29 +428,8 @@ _mesa_GetFragDataIndex(GLuint program, const GLchar *name)
if (shProg-_LinkedShaders[MESA_SHADER_FRAGMENT] == NULL)
return -1;
- exec_list *ir = shProg-_LinkedShaders[MESA_SHADER_FRAGMENT]-ir;
- foreach_in_list(ir_instruction, node, ir) {
- const ir_variable *const var = node-as_variable();
-
- /* The extra check against FRAG_RESULT_DATA0 is because
- * glGetFragDataLocation cannot be used on conventional attributes.
- *
- * From page 95 of the OpenGL 3.0 spec:
- *
- * If name is not an active attribute, if name is a conventional
- * attribute, or if an error occurs, -1 will be returned.
- */
- if (var == NULL
- || var-data.mode != ir_var_shader_out
- || var-data.location == -1
- || var-data.location FRAG_RESULT_DATA0)
- continue;
-
- if (get_matching_index(var, (const char *) name) = 0)
- return var-data.index;
- }
-
- return -1;
+ return _mesa_program_resource_location_index(shProg, GL_PROGRAM_OUTPUT,
+name);
}
GLint GLAPIENTRY
Reviewed-by: Martin Peres martin.pe...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Valve games for Mesa/DRI developers
Hi, On 13 April 2015 at 15:06, Thierry Reding thierry.red...@gmail.com wrote: I'm not much of a gamer myself, but I imagine that these games would be useful, real-life tests and/or entertaining benchmarks. Given that I work mostly on ARM systems, do you know if there are any plans on making these games available on ARM? I know some of Valve's games have been ported to ARM for Android, but perhaps there isn't enough of an audience to make it beneficial to get them to run on regular Linux on ARM? I don't actually know myself, but even if I did, it wouldn't really be for me to pre-empt Valve saying so. I agree it would be nice though! Cheers, Daniel Thierry On Thu, Apr 09, 2015 at 06:10:42PM +0100, Daniel Stone wrote: Hi, At Collabora (my lovely dayjob), we've been working with Valve on SteamOS. Valve are keen to give back to the community, and we've been discussing ways they can help do that, including providing free access to Valve games on Steam to Debian developers last year. We're happy to say that this has been extended to Mesa developers as well, to say thanks for all the great work. If you have 25 commits or more (an arbitrary number) to Mesa[0] in the past five years, please drop me an email (with 'Steam' in the subject) with your freedesktop username and Steam username. We can then get you access to all past and future Valve-produced games available on Steam[1]. Thanks for all the great work, and enjoy. Cheers, Daniel [0]: Or DRI-type stuff in the kernel too. [1]: Currently this looks like https://store.steampowered.com/search/?snr=1_4_4__12term=#category1=998publisher=Valvesort_order=ASCpage=1 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
