Re: [Mesa-dev] Android build targets
On Tue, 14 Jan 2014 00:19:04 -0600 Tom Gall wrote: > Hi, > > Been experimenting with building mesa on android specifically for ARM. > I was curious if there is a wiki page that covers building mesa on > android somewhere. Didn't see anything with the source or on > mesa3d.org. > > As a start I'm building with BOARD_GPU_DRIVERS := swrast > > libGLES_mesa.so is built but I don't seem to end up with like a > libGLESv2.so for instance from mesa which I was expecting. Guessing it > looks like libGLES_mesa.so goes into /system/lib/egl and then mesa > would be put into egl.conf but that's a guess on my part. Hi, from my very vague memory of fiddling with android, yes, the Android itself provides the libs that apps link to, e.g. libGLESv2.so, and those are trampolines to the real implementations, which is what you would build from Mesa. Your guess sounds right to me, FWIW. The last time I looked, a year(?) ago, Android's libEGL multiplexes into at least two different gfx stacks: Android's own sw-based, and the vendor's hw stack. You should find the app-facing EGL and GLES libs in Android's (platform)/frameworks/base/opengl/libs or around there. Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [libdrm PATCH] intel: Create a new drm_intel_bo offset64 field.
Kenneth Graunke writes: > The existing 'offset' field is unfortunately typed as 'unsigned long', > which is unfortunately only 4 bytes with a 32-bit userspace. > > Traditionally, the hardware has only supported 32-bit virtual addresses, > so even though the kernel uses a __u64, the value would always fit. > > However, Broadwell supports 48-bit addressing. So with a 64-bit kernel, > the card virtual address may be too large to fit in the 'offset' field. > > Ideally, we would change the type of 'offset' to be a uint64_t---but > this would break the libdrm ABI. Instead, we create a new 'offset64' > field to hold the full 64-bit value from the kernel, and store the > 32-bit truncation in the existing 'offset' field, for compatibility. > > Cc: Eric Anholt > Cc: Daniel Vetter > Cc: Ben Widawsky > Signed-off-by: Kenneth Graunke > --- > intel/intel_bufmgr.h | 12 +--- > intel/intel_bufmgr_gem.c | 16 ++-- > 2 files changed, 19 insertions(+), 9 deletions(-) > > I didn't update the bufmgr_fake stuff. Do I need to...? Nope. Also, this was less patch than I was originally imagining it would be. Sweet. Reviewed-by: Eric Anholt Maybe some day we'll do a symbol-versioned fork of the code without all the compatibility insanity, and with other 4G limits fixed. I don't think we have any instances of sharing drm_intel_bos across build-system boundaries. Anyone want to correct me on that? pgp1LlTxnSBk6.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4] opencl: improved auto-gen .icd
>From 8c47b170c1f6152e337bf333662a3e561853a171 Mon Sep 17 00:00:00 2001 From: Igor Gnatenko Date: Sun, 12 Jan 2014 02:09:16 +0400 Subject: [PATCH] opencl: improved auto-gen .icd v2: Use @OPENCL_VERSION@:0 for library replace /etc with @sysconfdir@ macros v3: Drop libdir from icd, because libMesaOpenCL isn't private v4: install ocl vendor always to /etc Reported-by: Fabian Deutsch Reference: https://bugs.freedesktop.org/show_bug.cgi?id=73512 Signed-off-by: Igor Gnatenko --- configure.ac | 3 +++ src/gallium/targets/opencl/Makefile.am | 2 +- src/gallium/targets/opencl/mesa.icd| 1 - src/gallium/targets/opencl/mesa.icd.in | 1 + 4 files changed, 5 insertions(+), 2 deletions(-) delete mode 100644 src/gallium/targets/opencl/mesa.icd create mode 100644 src/gallium/targets/opencl/mesa.icd.in diff --git a/configure.ac b/configure.ac index 4b55140..3452e15 100644 --- a/configure.ac +++ b/configure.ac @@ -25,6 +25,8 @@ m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) dnl Set internal versions OSMESA_VERSION=8 AC_SUBST([OSMESA_VERSION]) +OPENCL_VERSION=1 +AC_SUBST([OPENCL_VERSION]) dnl Versions for external dependencies LIBDRM_REQUIRED=2.4.24 @@ -2023,6 +2025,7 @@ AC_CONFIG_FILES([Makefile src/gallium/targets/egl-static/Makefile src/gallium/targets/gbm/Makefile src/gallium/targets/opencl/Makefile + src/gallium/targets/opencl/mesa.icd src/gallium/targets/osmesa/Makefile src/gallium/targets/osmesa/osmesa.pc src/gallium/targets/pipe-loader/Makefile diff --git a/src/gallium/targets/opencl/Makefile.am b/src/gallium/targets/opencl/Makefile.am index 653302c..3b257ca 100644 --- a/src/gallium/targets/opencl/Makefile.am +++ b/src/gallium/targets/opencl/Makefile.am @@ -4,7 +4,7 @@ lib_LTLIBRARIES = lib@OPENCL_LIBNAME@.la lib@OPENCL_LIBNAME@_la_LDFLAGS = \ $(LLVM_LDFLAGS) \ - -version-number 1:0 + -version-number @OPENCL_VERSION@:0 lib@OPENCL_LIBNAME@_la_LIBADD = \ $(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader.la \ diff --git a/src/gallium/targets/opencl/mesa.icd b/src/gallium/targets/opencl/mesa.icd deleted file mode 100644 index 6a6a870..000 --- a/src/gallium/targets/opencl/mesa.icd +++ /dev/null @@ -1 +0,0 @@ -libMesaOpenCL.so diff --git a/src/gallium/targets/opencl/mesa.icd.in b/src/gallium/targets/opencl/mesa.icd.in new file mode 100644 index 000..1b77b4e --- /dev/null +++ b/src/gallium/targets/opencl/mesa.icd.in @@ -0,0 +1 @@ +lib@OPENCL_LIBNAME@.so.@OPENCL_VERSION@ -- 1.8.4.2 -- -Igor Gnatenko ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] opencl: improved auto-gen .icd
On Mon, 2014-01-13 at 15:17 -0800, Matt Turner wrote: > On Mon, Jan 13, 2014 at 11:12 AM, Tom Stellard wrote: > > On Sun, Jan 12, 2014 at 03:08:56AM +0400, Igor Gnatenko wrote: > >> From 5b2bf87f1238e44150492a39f5db0ae90d59459b Mon Sep 17 00:00:00 2001 > >> From: Igor Gnatenko > >> Date: Sun, 12 Jan 2014 02:09:16 +0400 > >> Subject: [PATCH] opencl: improved auto-gen .icd > >> > >> v2: Use @OPENCL_VERSION@:0 for library > >> replace /etc with @sysconfdir@ macros > >> > >> Reported-by: Fabian Deutsch > >> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=73512 > >> Signed-off-by: Igor Gnatenko > >> --- > >> configure.ac | 3 +++ > >> src/gallium/targets/opencl/Makefile.am | 4 ++-- > >> src/gallium/targets/opencl/mesa.icd| 1 - > >> src/gallium/targets/opencl/mesa.icd.in | 1 + > >> 4 files changed, 6 insertions(+), 3 deletions(-) > >> delete mode 100644 src/gallium/targets/opencl/mesa.icd > >> create mode 100644 src/gallium/targets/opencl/mesa.icd.in > >> > >> diff --git a/configure.ac b/configure.ac > >> index 4b55140..3452e15 100644 > >> --- a/configure.ac > >> +++ b/configure.ac > >> @@ -25,6 +25,8 @@ m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) > >> dnl Set internal versions > >> OSMESA_VERSION=8 > >> AC_SUBST([OSMESA_VERSION]) > >> +OPENCL_VERSION=1 > >> +AC_SUBST([OPENCL_VERSION]) > >> > >> dnl Versions for external dependencies > >> LIBDRM_REQUIRED=2.4.24 > >> @@ -2023,6 +2025,7 @@ AC_CONFIG_FILES([Makefile > >> src/gallium/targets/egl-static/Makefile > >> src/gallium/targets/gbm/Makefile > >> src/gallium/targets/opencl/Makefile > >> + src/gallium/targets/opencl/mesa.icd > >> src/gallium/targets/osmesa/Makefile > >> src/gallium/targets/osmesa/osmesa.pc > >> src/gallium/targets/pipe-loader/Makefile > >> diff --git a/src/gallium/targets/opencl/Makefile.am > >> b/src/gallium/targets/opencl/Makefile.am > >> index 653302c..923316c 100644 > >> --- a/src/gallium/targets/opencl/Makefile.am > >> +++ b/src/gallium/targets/opencl/Makefile.am > >> @@ -4,7 +4,7 @@ lib_LTLIBRARIES = lib@OPENCL_LIBNAME@.la > >> > >> lib@OPENCL_LIBNAME@_la_LDFLAGS = \ > >> $(LLVM_LDFLAGS) \ > >> - -version-number 1:0 > >> + -version-number @OPENCL_VERSION@:0 > >> > >> lib@OPENCL_LIBNAME@_la_LIBADD = \ > >> $(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader.la \ > >> @@ -34,7 +34,7 @@ lib@OPENCL_LIBNAME@_la_SOURCES = > >> nodist_EXTRA_lib@OPENCL_LIBNAME@_la_SOURCES = dummy.cpp > >> > >> if HAVE_CLOVER_ICD > >> -icddir = /etc/OpenCL/vendors/ > >> +icddir = @sysconfdir@/OpenCL/vendors/ > > > > As I mentioned in the bug report, the ICD spec says that OpenCL/vendors/ > > should be in /etc/ I don't think we can change this and still be spec > > compliant. Why do you want to install the *.icd files in sysconfdir? > > sysconfdir basically is etc. This hunk would allow you to install into > a prefix and not have this file installed into /etc outside of your > prefix. Unfortunately ocl-icd HARDLY defined /etc. Resending new patch. -- -Igor Gnatenko ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Stop doing our optimization on a copy of the GLSL IR.
The original intent was that we'd keep a driver-private copy, and there
would be the normal copy for swrast to make use of without the tuning (or
anything more invasive we might do) specific to i965. Only, we don't
generate swrast code any more, because swrast can't render current shaders
anyway. Thus, our private copy is rather a waste, and we can just do our
backend-specific operations on the linked shader.
---
src/mesa/drivers/dri/i965/brw_context.h | 3 --
src/mesa/drivers/dri/i965/brw_fs.cpp | 4 +-
src/mesa/drivers/dri/i965/brw_shader.cpp | 55 ++-
src/mesa/drivers/dri/i965/brw_vec4.cpp| 4 +-
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 2 +-
5 files changed, 28 insertions(+), 40 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 63dd4a0..099f2f6 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -320,9 +320,6 @@ struct brw_shader {
struct gl_shader base;
bool compiled_once;
-
- /** Shader IR transformed for native compile, at link time. */
- struct exec_list *ir;
};
/* Note: If adding fields that need anything besides a normal memcmp() for
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index baf9220..3536cbe 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3156,7 +3156,7 @@ fs_visitor::run()
* functions called "main").
*/
if (shader) {
- foreach_list(node, &*shader->ir) {
+ foreach_list(node, &*shader->base.ir) {
ir_instruction *ir = (ir_instruction *)node;
base_ir = ir;
this->result = reg_undef;
@@ -3305,7 +3305,7 @@ brw_wm_fs_emit(struct brw_context *brw, struct
brw_wm_compile *c,
if (unlikely(INTEL_DEBUG & DEBUG_WM)) {
if (prog) {
printf("GLSL IR for native fragment shader %d:\n", prog->Name);
- _mesa_print_ir(shader->ir, NULL);
+ _mesa_print_ir(shader->base.ir, NULL);
printf("\n\n");
} else {
printf("ARB_fragment_program %d ir for native fragment shader\n",
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index cf9ca4b..5752348 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -135,24 +135,18 @@ brw_link_shader(struct gl_context *ctx, struct
gl_shader_program *shProg)
_mesa_copy_linked_program_data((gl_shader_stage) stage, shProg, prog);
- void *mem_ctx = ralloc_context(NULL);
bool progress;
- if (shader->ir)
-ralloc_free(shader->ir);
- shader->ir = new(shader) exec_list;
- clone_ir_list(mem_ctx, shader->ir, shader->base.ir);
-
/* lower_packing_builtins() inserts arithmetic instructions, so it
* must precede lower_instructions().
*/
- brw_lower_packing_builtins(brw, (gl_shader_stage) stage, shader->ir);
- do_mat_op_to_vec(shader->ir);
+ brw_lower_packing_builtins(brw, (gl_shader_stage) stage,
shader->base.ir);
+ do_mat_op_to_vec(shader->base.ir);
const int bitfield_insert = brw->gen >= 7
? BITFIELD_INSERT_TO_BFM_BFI
: 0;
const int lrp_to_arith = brw->gen < 6 ? LRP_TO_ARITH : 0;
- lower_instructions(shader->ir,
+ lower_instructions(shader->base.ir,
MOD_TO_FRACT |
DIV_TO_MUL_RCP |
SUB_TO_ADD_NEG |
@@ -166,17 +160,17 @@ brw_link_shader(struct gl_context *ctx, struct
gl_shader_program *shProg)
* if-statements need to be flattened.
*/
if (brw->gen < 6)
-lower_if_to_cond_assign(shader->ir, 16);
-
- do_lower_texture_projection(shader->ir);
- brw_lower_texture_gradients(brw, shader->ir);
- do_vec_index_to_cond_assign(shader->ir);
- lower_vector_insert(shader->ir, true);
- brw_do_cubemap_normalize(shader->ir);
- brw_do_lower_offset_arrays(shader->ir);
- brw_do_lower_unnormalized_offset(shader->ir);
- lower_noise(shader->ir);
- lower_quadop_vector(shader->ir, false);
+lower_if_to_cond_assign(shader->base.ir, 16);
+
+ do_lower_texture_projection(shader->base.ir);
+ brw_lower_texture_gradients(brw, shader->base.ir);
+ do_vec_index_to_cond_assign(shader->base.ir);
+ lower_vector_insert(shader->base.ir, true);
+ brw_do_cubemap_normalize(shader->base.ir);
+ brw_do_lower_offset_arrays(shader->base.ir);
+ brw_do_lower_unnormalized_offset(shader->base.ir);
+ lower_noise(shader->base.ir);
+ lower_quadop_vector(shader->base.ir, false);
bool input = true;
bool output = stage == MESA_SHADER_FRAGMENT;
@@ -184,7 +178,7 @@ brw_link_shader(struct gl_context *ctx, struct
gl_shader_
[Mesa-dev] [PATCH 2/2] i965: Replace 8-wide and 16-wide with SIMD8 and SIMD16.
Those are the terms used in the docs, and think "n-wide" was something I
just happened to say. Note that shader-db needs updating for the
INTEL_DEBUG=fs parsing.
---
src/mesa/drivers/dri/i965/brw_eu.c | 8 +++---
src/mesa/drivers/dri/i965/brw_fs.cpp | 30 +++---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 14 +-
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 8 +++---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 22
.../drivers/dri/i965/brw_schedule_instructions.cpp | 6 ++---
6 files changed, 44 insertions(+), 44 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu.c
b/src/mesa/drivers/dri/i965/brw_eu.c
index 9d0c856..5e3730f 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.c
+++ b/src/mesa/drivers/dri/i965/brw_eu.c
@@ -112,7 +112,7 @@ brw_set_compression_control(struct brw_compile *p,
p->compressed = (compression_control == BRW_COMPRESSION_COMPRESSED);
if (p->brw->gen >= 6) {
- /* Since we don't use the 32-wide support in gen6, we translate
+ /* Since we don't use the SIMD32 support in gen6, we translate
* the pre-gen6 compression control here.
*/
switch (compression_control) {
@@ -123,12 +123,12 @@ brw_set_compression_control(struct brw_compile *p,
p->current->header.compression_control = GEN6_COMPRESSION_1Q;
break;
case BRW_COMPRESSION_2NDHALF:
-/* For 8-wide, this is "use the second set of 8 bits." */
+/* For SIMD8, this is "use the second set of 8 bits." */
p->current->header.compression_control = GEN6_COMPRESSION_2Q;
break;
case BRW_COMPRESSION_COMPRESSED:
-/* For 16-wide instruction compression, use the first set of 16 bits
- * since we don't do 32-wide dispatch.
+/* For SIMD16 instruction compression, use the first set of 16 bits
+ * since we don't do SIMD32 dispatch.
*/
p->current->header.compression_control = GEN6_COMPRESSION_1H;
break;
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 3536cbe..37329b9 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -856,7 +856,7 @@ import_uniforms_callback(const void *key,
hash_table_insert(dst_ht, data, key);
}
-/* For 16-wide, we need to follow from the uniform setup of 8-wide dispatch.
+/* For SIMD16, we need to follow from the uniform setup of SIMD8 dispatch.
* This brings in those uniform definitions
*/
void
@@ -1340,7 +1340,7 @@ fs_visitor::emit_math(enum opcode opcode, fs_reg dst,
fs_reg src0, fs_reg src1)
case SHADER_OPCODE_INT_QUOTIENT:
case SHADER_OPCODE_INT_REMAINDER:
if (brw->gen >= 7 && dispatch_width == 16)
-fail("16-wide INTDIV unsupported\n");
+fail("SIMD16 INTDIV unsupported\n");
break;
case SHADER_OPCODE_POW:
break;
@@ -1764,7 +1764,7 @@ fs_visitor::remove_dead_constants()
c->prog_data.nr_params = new_nr_params;
} else {
- /* This should have been generated in the 8-wide pass already. */
+ /* This should have been generated in the SIMD8 pass already. */
assert(this->params_remap);
}
@@ -1883,7 +1883,7 @@ fs_visitor::setup_pull_constants()
return;
if (dispatch_width == 16) {
- fail("Pull constants not supported in 16-wide\n");
+ fail("Pull constants not supported in SIMD16\n");
return;
}
@@ -2557,7 +2557,7 @@ static void
clear_deps_for_inst_src(fs_inst *inst, int dispatch_width, bool *deps,
int first_grf, int grf_len)
{
- bool inst_16wide = (dispatch_width > 8 &&
+ bool inst_simd16 = (dispatch_width > 8 &&
!inst->force_uncompressed &&
!inst->force_sechalf);
@@ -2576,7 +2576,7 @@ clear_deps_for_inst_src(fs_inst *inst, int
dispatch_width, bool *deps,
if (grf >= first_grf &&
grf < first_grf + grf_len) {
deps[grf - first_grf] = false;
- if (inst_16wide)
+ if (inst_simd16)
deps[grf - first_grf + 1] = false;
}
}
@@ -2634,7 +2634,7 @@
fs_visitor::insert_gen4_pre_send_dependency_workarounds(fs_inst *inst)
return;
}
- bool scan_inst_16wide = (dispatch_width > 8 &&
+ bool scan_inst_simd16 = (dispatch_width > 8 &&
!scan_inst->force_uncompressed &&
!scan_inst->force_sechalf);
@@ -2651,7 +2651,7 @@
fs_visitor::insert_gen4_pre_send_dependency_workarounds(fs_inst *inst)
needs_dep[reg - first_write_grf]) {
inst->insert_before(DEP_RESOLVE_MOV(reg));
needs_dep[reg - first_write_grf] = false;
- if (scan_inst_16wide)
+ if (scan_inst_simd16)
needs_dep[reg - first_write_grf + 1] = false;
}
}
@@ -3062,7 +3062,7 @@ fs
[Mesa-dev] Android build targets
Hi, Been experimenting with building mesa on android specifically for ARM. I was curious if there is a wiki page that covers building mesa on android somewhere. Didn't see anything with the source or on mesa3d.org. As a start I'm building with BOARD_GPU_DRIVERS := swrast libGLES_mesa.so is built but I don't seem to end up with like a libGLESv2.so for instance from mesa which I was expecting. Guessing it looks like libGLES_mesa.so goes into /system/lib/egl and then mesa would be put into egl.conf but that's a guess on my part. Thanks! -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Tech Lead, Graphics Working Group | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org h) tom_gall att mac.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] radeonsi: handle R600_CONTEXT_PS_PARTIAL_FLUSH in si_emit_cache_flush
On Mon, 2014-01-13 at 14:13 +0100, Marek Olšák wrote: > From: Marek Olšák > > For consistency only, This unused by radeonsi currently. The radeonsi changes are Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Use sample barycentric coordinates with per sample shading
I would have expected explicit qualifiers to trump everything. I wonder why that was removed -- Ian? It seems there's a clear precedent established by the other drivers, though -- so I think we should stick to it. Bonus for us: since our centroid support is a bit bogus and requires workarounds, we get to emit slightly better code this way :) -- Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Use sample barycentric coordinates with per sample shading
On Mon, Jan 13, 2014 at 1:06 PM, Anuj Phogat wrote: > > On Fri, Jan 10, 2014 at 5:25 PM, Anuj Phogat wrote: > > On Thu, Jan 9, 2014 at 4:34 PM, Chris Forbes wrote: > >> Hi Anuj, > >> > >> There's one fiddly interaction that I don't think this handles quite > >> right, although I think it does conform. > >> > >> Suppose we have this fragment shader: > >> > >>#version 330 > >>#extension ARB_gpu_shader5: require > >> > >>sample in vec4 a; > >>in vec4 b; > >> > >>... > >> > >> Then `b` is being evaluated at the sample position as well. This is > >> allowed by my reading of the spec, but probably not what the author > >> expected. > > Good catch. > >> > >> From the ARB_gpu_shader5 spec, emphasis mine: > >> > >> (11) Should we support per-sample interpolation of attributes? If so, > >> how? > >> > >> RESOLVED. Yes. When multisample rasterization is enabled, > >> qualifying > >> one or more fragment shader inputs with "sample" will force > >> per-sample > >> interpolation of those attributes. If the same shader includes other > >> fragment inputs not qualified with sample, those attributes _may_ be > >> interpolated per-pixel (i.e., all samples get the same values, likely > >> evaluated at the pixel center). > >> > >> What do you think? > > I agree with your interpretation. Spec seems to be flexible about it. I'll > > check > > what NVIDIA does in this case. This should be easy to fix if we need to. > I verified that NVIDIA doesn't evaluate variable 'b' at sample position. > I'll send out an updated patch to match this behavior. > Chris, I identified another case not very well defined by OpenGL specs: /* Enable sample shading using OpenGL API */ glEnable(GL_SAMPLE_SHADING); glMinSampleShading(1.0); fragment shader: #version 130 in vec4 a; centroid in vec4 b; ... Variable 'a' will be interpolated at sample location. What interpolation should we use for variable 'b' ? ARB_sample_shading says: " Should there be an option to specify that all fragment shader inputs be interpolated at per-sample frequency? If so, how? RESOLVED: Yes. Via the enable" " When the sample shading fraction is 1.0, a separate set of colors and other associated data are evaluated for each sample, each set of values are evaluated at the sample location." If we follow ARB_sample_shading 'b' should be interpolated at sample position. But GLSL 400 (and previous versions) spec says that: "When an interpolation qualifier is used, it overrides settings established through the OpenGL API." This text got deleted in later versions of GLSL. If we follow GLSL 400 (or earlier) 'b' should use centroid interpolation. For later versions of GLSL 'b' should be interpolated at sample position. NVIDIA's and AMD's proprietary linux drivers (at OpenGL 4.3) interpolates at sample position. I think we should also stick to this behavior. Any views? > > >> > >> -- Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Bug 73578] egl_pipe.c:46:38: fatal error: radeonsi/radeonsi_public.h: No such file or directory
Sorry, I did apparently not compile-check some part. And thanks for fixing it. On Tuesday 14 January 2014 00:06:05 bugzilla-dae...@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=73578 > > Vinson Lee changed: > >What|Removed |Added > > Status|NEW |RESOLVED > Resolution|--- |FIXED > > --- Comment #2 from Vinson Lee --- > commit 8f9b70fa3c41418bc2b28551642ea786ed0c2e79 > Author: Vinson Lee > Date: Mon Jan 13 15:51:50 2014 -0800 > > egl-static: Fix build error. > > Fix build regression introduced with commit > 786af2f963925df2c2a6fb60b29a83e8340f03c7. > > egl_pipe.c:46:38: fatal error: radeonsi/radeonsi_public.h: No such file > or directory > #include "radeonsi/radeonsi_public.h" > ^ > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73578 > Signed-off-by: Vinson Lee > vinson@vinson-ubuntu:~/workspace/mesa$ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] How to contribute a translation?
Alex Henrie writes: > Hi, > > I'd like to translate the DRI driver options > (src/mesa/drivers/dri/common/xmlpool) to the Catalan language. What is > the procedure for adding new translations? What tool should I use to > generate ca.po, and how do I submit the file for review? I don't know how the .po files get generated, and there hasn't been much activity on them in a long time. But if you figure out how to generate them in the first place: git add src/mesa/drivers/dri/common/xmlpool/my.po git commit -m "driconf: Add Catalan translations" (or just git commit and add some information about how you generated them as well -- that way someone else may find translation easier in the future). git format-patch HEAD~1 (make sure your git commit shows your real name and email address) git send-email --to mesa-dev@lists.freedesktop.org 0001-driconf-Add-Catalan-translations.patch pgp7pfA6bz4O4.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] glx: Add missing null check in glXCreateContextAttribsARB
On 01/13/2014 05:35 AM, Juha-Pekka Heikkila wrote: Signed-off-by: Juha-Pekka Heikkila --- src/glx/create_context.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/glx/create_context.c b/src/glx/create_context.c index 38e949a..b15921f 100644 --- a/src/glx/create_context.c +++ b/src/glx/create_context.c @@ -90,6 +90,9 @@ glXCreateContextAttribsARB(Display *dpy, GLXFBConfig config, #endif } + if (gc == NULL) + return NULL; + gc->xid = xcb_generate_id(c); gc->share_xid = (share != NULL) ? share->xid : 0; I think this new check could be moved up into the previous if (gc == NULL) block. As-is, we're testing the same condition twice all the time. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa-demos: Fixes a bug in demo2 application
On 01/13/2014 05:31 AM, Yasir Khan wrote: From: Yasir-Khan Vertices array is being passed to glColorPointer whereas its supposed to pass the color array Signed-off-by: Yasir-Khan diff --git a/src/egl/opengl/demo2.c b/src/egl/opengl/demo2.c index 71a1a31..505b474 100644 --- a/src/egl/opengl/demo2.c +++ b/src/egl/opengl/demo2.c @@ -35,7 +35,7 @@ static void _subset_Rectf(GLfloat x1, GLfloat y1, GLfloat x2, GLfloat y2, } glVertexPointer(2, GL_FLOAT, 0, v); - glColorPointer(4, GL_FLOAT, 0, v); + glColorPointer(4, GL_FLOAT, 0, c); glEnableClientState(GL_VERTEX_ARRAY); glEnableClientState(GL_COLOR_ARRAY); Reviewed-by: Brian Paul I presume you need someone to push this for you? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [libdrm PATCH] intel: Create a new drm_intel_bo offset64 field.
On 01/13/2014 03:56 PM, Kenneth Graunke wrote: > The existing 'offset' field is unfortunately typed as 'unsigned long', > which is unfortunately only 4 bytes with a 32-bit userspace. > > Traditionally, the hardware has only supported 32-bit virtual addresses, > so even though the kernel uses a __u64, the value would always fit. > > However, Broadwell supports 48-bit addressing. So with a 64-bit kernel, > the card virtual address may be too large to fit in the 'offset' field. > > Ideally, we would change the type of 'offset' to be a uint64_t---but > this would break the libdrm ABI. Instead, we create a new 'offset64' > field to hold the full 64-bit value from the kernel, and store the > 32-bit truncation in the existing 'offset' field, for compatibility. > > Cc: Eric Anholt > Cc: Daniel Vetter > Cc: Ben Widawsky > Signed-off-by: Kenneth Graunke > --- > intel/intel_bufmgr.h | 12 +--- > intel/intel_bufmgr_gem.c | 16 ++-- > 2 files changed, 19 insertions(+), 9 deletions(-) > > I didn't update the bufmgr_fake stuff. Do I need to...? Here's the testing I've done: - Piglit with old libdrm and old Mesa - Piglit with libdrm patch, but old Mesa (proves offset still works) - Piglit with libdrm patch and Mesa patches (proves offset64 also works) I have not tested the Broadwell patch because the kernel doesn't actually ever put objects > 4G today. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Mesa PATCH 1/3] i965: Delete intel_batchbuffer_emit_reloc_fenced.
Nothing in i965 uses it.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 25 -
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 5 -
2 files changed, 30 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index d9b6c15..cee76d5 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -397,31 +397,6 @@ intel_batchbuffer_emit_reloc(struct brw_context *brw,
return true;
}
-bool
-intel_batchbuffer_emit_reloc_fenced(struct brw_context *brw,
- drm_intel_bo *buffer,
- uint32_t read_domains,
- uint32_t write_domain,
- uint32_t delta)
-{
- int ret;
-
- ret = drm_intel_bo_emit_reloc_fence(brw->batch.bo, 4*brw->batch.used,
- buffer, delta,
- read_domains, write_domain);
- assert(ret == 0);
- (void)ret;
-
- /*
-* Using the old buffer offset, write in what the right data would
-* be, in case the buffer doesn't move and we can short-circuit the
-* relocation processing in the kernel
-*/
- intel_batchbuffer_emit_dword(brw, buffer->offset + delta);
-
- return true;
-}
-
void
intel_batchbuffer_data(struct brw_context *brw,
const void *data, GLuint bytes, enum brw_gpu_ring ring)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
index 80cd571..2a3c6ed 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
@@ -59,11 +59,6 @@ bool intel_batchbuffer_emit_reloc(struct brw_context *brw,
uint32_t read_domains,
uint32_t write_domain,
uint32_t offset);
-bool intel_batchbuffer_emit_reloc_fenced(struct brw_context *brw,
- drm_intel_bo *buffer,
- uint32_t read_domains,
- uint32_t write_domain,
- uint32_t offset);
void intel_batchbuffer_emit_mi_flush(struct brw_context *brw);
void intel_emit_post_sync_nonzero_flush(struct brw_context *brw);
void intel_emit_depth_stall_flushes(struct brw_context *brw);
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Mesa PATCH 2/3] i965: Use the new drm_intel_bo offset64 field.
libdrm 2.4.52 introduces a new 'uint64_t offset64' field, intended to
replace the old 'unsigned long offset' field. To preserve ABI, libdrm
continues to store the presumed offset in both locations.
On Broadwell, a 64-bit kernel may place BOs at "high" (> 4G) addresses.
However, with a 32-bit userspace, the 'unsigned long offset' field will
only be 32-bit, which is not large enough to hold this value. We need
to use a proper uint64_t (like the kernel does).
Technically, a lot of this code doesn't affect Broadwell, so we could
leave it using the old field. But it makes sense to just switch to the
new, properly typed field.
Signed-off-by: Kenneth Graunke
---
configure.ac | 2 +-
src/mesa/drivers/dri/i965/brw_cc.c| 2 +-
src/mesa/drivers/dri/i965/brw_clip_state.c| 2 +-
src/mesa/drivers/dri/i965/brw_context.h | 2 +-
src/mesa/drivers/dri/i965/brw_sf_state.c | 2 +-
src/mesa/drivers/dri/i965/brw_vs_state.c | 4 ++--
src/mesa/drivers/dri/i965/brw_wm_sampler_state.c | 2 +-
src/mesa/drivers/dri/i965/brw_wm_state.c | 4 ++--
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 14 +++---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 4 ++--
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 4 ++--
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 14 +++---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 6 +++---
13 files changed, 31 insertions(+), 31 deletions(-)
This was generated by temporarily removing the 'offset' field from libdrm
and fixing all the compile errors. Obviously, we can't actually delete the
field, but you can at least have some confidence that I caught all the
existing uses.
diff --git a/configure.ac b/configure.ac
index 4b55140..fd189ea 100644
--- a/configure.ac
+++ b/configure.ac
@@ -29,7 +29,7 @@ AC_SUBST([OSMESA_VERSION])
dnl Versions for external dependencies
LIBDRM_REQUIRED=2.4.24
LIBDRM_RADEON_REQUIRED=2.4.50
-LIBDRM_INTEL_REQUIRED=2.4.49
+LIBDRM_INTEL_REQUIRED=2.4.52
LIBDRM_NVVIEUX_REQUIRED=2.4.33
LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
LIBDRM_FREEDRENO_REQUIRED=2.4.51
diff --git a/src/mesa/drivers/dri/i965/brw_cc.c
b/src/mesa/drivers/dri/i965/brw_cc.c
index 4bc3b23..497d91a 100644
--- a/src/mesa/drivers/dri/i965/brw_cc.c
+++ b/src/mesa/drivers/dri/i965/brw_cc.c
@@ -215,7 +215,7 @@ static void upload_cc_unit(struct brw_context *brw)
cc->cc5.statistics_enable = 1;
/* CACHE_NEW_CC_VP */
- cc->cc4.cc_viewport_state_offset = (brw->batch.bo->offset +
+ cc->cc4.cc_viewport_state_offset = (brw->batch.bo->offset64 +
brw->cc.vp_offset) >> 5; /* reloc */
brw->state.dirty.cache |= CACHE_NEW_CC_UNIT;
diff --git a/src/mesa/drivers/dri/i965/brw_clip_state.c
b/src/mesa/drivers/dri/i965/brw_clip_state.c
index 66b3229..8647b0d 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_state.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_state.c
@@ -132,7 +132,7 @@ brw_upload_clip_unit(struct brw_context *brw)
{
clip->clip5.guard_band_enable = 1;
clip->clip6.clipper_viewport_state_ptr =
- (brw->batch.bo->offset + brw->clip.vp_offset) >> 5;
+ (brw->batch.bo->offset64 + brw->clip.vp_offset) >> 5;
/* emit clip viewport relocation */
drm_intel_bo_emit_reloc(brw->batch.bo,
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 63dd4a0..77c4c3e 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1809,7 +1809,7 @@ brw_program_reloc(struct brw_context *brw, uint32_t
state_offset,
prog_offset,
I915_GEM_DOMAIN_INSTRUCTION, 0);
- return brw->cache.bo->offset + prog_offset;
+ return brw->cache.bo->offset64 + prog_offset;
}
bool brw_do_cubemap_normalize(struct exec_list *instructions);
diff --git a/src/mesa/drivers/dri/i965/brw_sf_state.c
b/src/mesa/drivers/dri/i965/brw_sf_state.c
index 69093f2..9bc0cd3 100644
--- a/src/mesa/drivers/dri/i965/brw_sf_state.c
+++ b/src/mesa/drivers/dri/i965/brw_sf_state.c
@@ -173,7 +173,7 @@ static void upload_sf_unit( struct brw_context *brw )
sf->thread4.stats_enable = 1;
/* CACHE_NEW_SF_VP */
- sf->sf5.sf_viewport_state_offset = (brw->batch.bo->offset +
+ sf->sf5.sf_viewport_state_offset = (brw->batch.bo->offset64 +
brw->sf.vp_offset) >> 5; /* reloc */
sf->sf5.viewport_transform = 1;
diff --git a/src/mesa/drivers/dri/i965/brw_vs_state.c
b/src/mesa/drivers/dri/i965/brw_vs_state.c
index 015abf1..a3ea62d 100644
--- a/src/mesa/drivers/dri/i965/brw_vs_state.c
+++ b/src/mesa/drivers/dri/i965/brw_vs_state.c
@@ -84,7 +84,7 @@ brw_upload_vs_unit(struct brw_context *brw)
if (brw->vs.prog_data->base.total_scratch != 0) {
vs->thread2.scratch_space_base_pointer =
-stage_state->scratch_bo->off
[Mesa-dev] Nominations for X.Org Foundation Board of Directors are OPEN
We are seeking nominations for candidates for election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2014 election are now open and will remain open until 23.59 GMT on 12 February 2013. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2013 were Alan Coopersmith, Martin Peres, Peter Hutterer and Stuart Kreitman. They will continue to serve until their term ends in 2015. Current directors whose term expires in 2014 are Matthias Hopf, Keith Packard, Matt Dew, and Alex Deucher. A director is expected to participate in the bi-weekly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the members account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23.59 GMT on 12 February 2014. The slate of candidates will be published 13 February 2014 and candidate Q&A will begin then. The deadline for Xorg membership applications and renewals is 18 February 2014. The Election Committee X.Org Foundation ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73578] egl_pipe.c:46:38: fatal error: radeonsi/radeonsi_public.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=73578 Vinson Lee changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Vinson Lee --- commit 8f9b70fa3c41418bc2b28551642ea786ed0c2e79 Author: Vinson Lee Date: Mon Jan 13 15:51:50 2014 -0800 egl-static: Fix build error. Fix build regression introduced with commit 786af2f963925df2c2a6fb60b29a83e8340f03c7. egl_pipe.c:46:38: fatal error: radeonsi/radeonsi_public.h: No such file or directory #include "radeonsi/radeonsi_public.h" ^ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73578 Signed-off-by: Vinson Lee vinson@vinson-ubuntu:~/workspace/mesa$ -- 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] Use AC_PATH_TOOL instead of AC_PATH_PROG for llvm-config.
Dnia 2014-01-13, o godz. 08:59:22 Tom Stellard napisał(a): > On Sat, Dec 28, 2013 at 03:22:09PM +0100, Michał Górny wrote: > > This should help with cross-compiling and multilib when $CHOST-specific > > llvm-config is expected rather than build host default one. > > > > It will help us a bit in Gentoo where we've started using > > i686-pc-linux-gnu-llvm-config for 32-bit multilib LLVM. > > > Reviewed-by: Tom Stellard > > Should we CC stable on this patch? I have no strong opinion here. It would be a bit helpful though it's not a killer feature for us (yet :)). > Do you have commit access? No, I don't. -- Best regards, Michał Górny 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] FOSDEM14: Graphics DevRoom: Deadline approaching fast.
On Tue, Jan 07, 2014 at 02:22:00AM +0100, Luc Verhaegen wrote: > Hi, > > There are still 5 slots open for the FOSDEM graphics DevRoom, and the > deadline is this friday, the 10th. Get a move on. > > If you have requested an account reset with me before, but if you then > haven't bothered filing a talk, you do NOT have a slot. Please file a > talk ASAP to still secure a place. > > For more information on how to file for a devroom, read the email sent > back in october: > http://lists.x.org/archives/xorg-devel/2013-October/038185.html > > Luc Verhaegen. There are still 3 slots open. This is your final chance to get a talk in the FOSDEM 2014 graphics DevRoom. Monday night (13th), the schedule will be locked down and no further talks or events will be accepted. Luc Verhaegen. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Mesa PATCH 3/3] i965: Introduce an OUT_RELOC64 macro.
Broadwell uses 48-bit addresses. The first DWord is the low 32 bits,
and the second DWord is the high 16 bits.
Cc: Eric Anholt
Cc: Daniel Vetter
Cc: Ben Widawsky
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 24
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 10 ++
2 files changed, 34 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 966b95b..88540f0 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -397,6 +397,30 @@ intel_batchbuffer_emit_reloc(struct brw_context *brw,
return true;
}
+bool
+intel_batchbuffer_emit_reloc64(struct brw_context *brw,
+ drm_intel_bo *buffer,
+ uint32_t read_domains, uint32_t write_domain,
+ uint32_t delta)
+{
+ int ret = drm_intel_bo_emit_reloc(brw->batch.bo, 4*brw->batch.used,
+ buffer, delta,
+ read_domains, write_domain);
+ assert(ret == 0);
+ (void) ret;
+
+ /* Using the old buffer offset, write in what the right data would be, in
+* case the buffer doesn't move and we can short-circuit the relocation
+* processing in the kernel
+*/
+ uint64_t offset = buffer->offset64 + delta;
+ intel_batchbuffer_emit_dword(brw, offset);
+ intel_batchbuffer_emit_dword(brw, offset >> 32);
+
+ return true;
+}
+
+
void
intel_batchbuffer_data(struct brw_context *brw,
const void *data, GLuint bytes, enum brw_gpu_ring ring)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
index 2a3c6ed..86923e4 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
@@ -59,6 +59,11 @@ bool intel_batchbuffer_emit_reloc(struct brw_context *brw,
uint32_t read_domains,
uint32_t write_domain,
uint32_t offset);
+bool intel_batchbuffer_emit_reloc64(struct brw_context *brw,
+drm_intel_bo *buffer,
+uint32_t read_domains,
+uint32_t write_domain,
+uint32_t offset);
void intel_batchbuffer_emit_mi_flush(struct brw_context *brw);
void intel_emit_post_sync_nonzero_flush(struct brw_context *brw);
void intel_emit_depth_stall_flushes(struct brw_context *brw);
@@ -169,6 +174,11 @@ void intel_batchbuffer_cached_advance(struct brw_context
*brw);
read_domains, write_domain, delta); \
} while (0)
+/* Handle 48-bit address relocations for Gen8+ */
+#define OUT_RELOC64(buf, read_domains, write_domain, delta) do { \
+ intel_batchbuffer_emit_reloc64(brw, buf, read_domains, write_domain,
delta);\
+} while (0)
+
#define ADVANCE_BATCH() intel_batchbuffer_advance(brw);
#define CACHED_BATCH() intel_batchbuffer_cached_advance(brw);
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [libdrm PATCH] intel: Create a new drm_intel_bo offset64 field.
The existing 'offset' field is unfortunately typed as 'unsigned long',
which is unfortunately only 4 bytes with a 32-bit userspace.
Traditionally, the hardware has only supported 32-bit virtual addresses,
so even though the kernel uses a __u64, the value would always fit.
However, Broadwell supports 48-bit addressing. So with a 64-bit kernel,
the card virtual address may be too large to fit in the 'offset' field.
Ideally, we would change the type of 'offset' to be a uint64_t---but
this would break the libdrm ABI. Instead, we create a new 'offset64'
field to hold the full 64-bit value from the kernel, and store the
32-bit truncation in the existing 'offset' field, for compatibility.
Cc: Eric Anholt
Cc: Daniel Vetter
Cc: Ben Widawsky
Signed-off-by: Kenneth Graunke
---
intel/intel_bufmgr.h | 12 +---
intel/intel_bufmgr_gem.c | 16 ++--
2 files changed, 19 insertions(+), 9 deletions(-)
I didn't update the bufmgr_fake stuff. Do I need to...?
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 2eb9742..9383c72 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -61,9 +61,8 @@ struct _drm_intel_bo {
unsigned long align;
/**
-* Last seen card virtual address (offset from the beginning of the
-* aperture) for the object. This should be used to fill relocation
-* entries when calling drm_intel_bo_emit_reloc()
+* Deprecated field containing (possibly the low 32-bits of) the last
+* seen virtual card address. Use offset64 instead.
*/
unsigned long offset;
@@ -84,6 +83,13 @@ struct _drm_intel_bo {
* MM-specific handle for accessing object
*/
int handle;
+
+ /**
+* Last seen card virtual address (offset from the beginning of the
+* aperture) for the object. This should be used to fill relocation
+* entries when calling drm_intel_bo_emit_reloc()
+*/
+ uint64_t offset64;
};
enum aub_dump_bmp_format {
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index ad722dd..f4db1a6 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -382,7 +382,7 @@ drm_intel_gem_dump_validation_list(drm_intel_bufmgr_gem
*bufmgr_gem)
(unsigned long long)bo_gem->relocs[j].offset,
target_gem->gem_handle,
target_gem->name,
- target_bo->offset,
+ target_bo->offset64,
bo_gem->relocs[j].delta);
}
}
@@ -894,6 +894,7 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr *bufmgr,
bo_gem->bo.size = open_arg.size;
bo_gem->bo.offset = 0;
+ bo_gem->bo.offset64 = 0;
bo_gem->bo.virtual = NULL;
bo_gem->bo.bufmgr = bufmgr;
bo_gem->name = name;
@@ -1689,7 +1690,7 @@ do_bo_emit_reloc(drm_intel_bo *bo, uint32_t offset,
target_bo_gem->gem_handle;
bo_gem->relocs[bo_gem->reloc_count].read_domains = read_domains;
bo_gem->relocs[bo_gem->reloc_count].write_domain = write_domain;
- bo_gem->relocs[bo_gem->reloc_count].presumed_offset = target_bo->offset;
+ bo_gem->relocs[bo_gem->reloc_count].presumed_offset =
target_bo->offset64;
bo_gem->reloc_target_info[bo_gem->reloc_count].bo = target_bo;
if (target_bo != bo)
@@ -1840,11 +1841,12 @@ drm_intel_update_buffer_offsets(drm_intel_bufmgr_gem
*bufmgr_gem)
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
/* Update the buffer offset */
- if (bufmgr_gem->exec_objects[i].offset != bo->offset) {
+ if (bufmgr_gem->exec_objects[i].offset != bo->offset64) {
DBG("BO %d (%s) migrated: 0x%08lx -> 0x%08llx\n",
- bo_gem->gem_handle, bo_gem->name, bo->offset,
+ bo_gem->gem_handle, bo_gem->name, bo->offset64,
(unsigned long long)bufmgr_gem->exec_objects[i].
offset);
+ bo->offset64 = bufmgr_gem->exec_objects[i].offset;
bo->offset = bufmgr_gem->exec_objects[i].offset;
}
}
@@ -1860,10 +1862,11 @@ drm_intel_update_buffer_offsets2 (drm_intel_bufmgr_gem
*bufmgr_gem)
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *)bo;
/* Update the buffer offset */
- if (bufmgr_gem->exec2_objects[i].offset != bo->offset) {
+ if (bufmgr_gem->exec2_objects[i].offset != bo->offset64) {
DBG("BO %d (%s) migrated: 0x%08lx -> 0x%08llx\n",
- bo_gem->gem_handle, bo_gem->name, bo->offset,
+ bo_gem->gem_handle, bo_gem->name, bo->offset64,
(unsigned long
long)bufmgr_gem->exec2_objects[i].offset);
+
[Mesa-dev] [Bug 73578] egl_pipe.c:46:38: fatal error: radeonsi/radeonsi_public.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=73578 --- Comment #1 from Vinson Lee --- 786af2f963925df2c2a6fb60b29a83e8340f03c7 is the first bad commit commit 786af2f963925df2c2a6fb60b29a83e8340f03c7 Author: Andreas Hartmetz Date: Sat Jan 4 18:44:33 2014 +0100 radeonsi: Apply si_* file naming scheme. Reviewed-by: Marek Olšák :04 04 d05e480d033201d725c16b7cb392b536538837ed 864adcad0405ebe443285fd74c24612fa4ae287d Msrc bisect run success -- 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 73578] New: egl_pipe.c:46:38: fatal error: radeonsi/radeonsi_public.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=73578 Priority: medium Bug ID: 73578 Keywords: regression CC: ahartm...@gmail.com, mar...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: egl_pipe.c:46:38: fatal error: radeonsi/radeonsi_public.h: No such file or directory Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa mesa: aa7ae4fd6e24ba7f2b687e3f3c4301919830750b (master) $ scons [...] Compiling src/gallium/targets/egl-static/egl_pipe.c ... src/gallium/targets/egl-static/egl_pipe.c:46:38: fatal error: radeonsi/radeonsi_public.h: No such file or directory #include "radeonsi/radeonsi_public.h" ^ compilation terminated. -- 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] [wip 6/9] glsl: ir_deserializer class for the binary shader cache
On 2 January 2014 03:58, Tapani Pälli wrote:
> +
> +
> +/**
> + * Reads header part of the binary blob. Main purpose of this header is to
> + * validate that cached shader was produced with same Mesa driver version.
> + */
> +int
> +ir_deserializer::read_header(struct gl_shader *shader)
> +{
> + char *cache_magic_id = map->read_string();
> + char *driver_vendor = map->read_string();
> + char *driver_renderer = map->read_string();
> +
> + /* only used or debug output, silence compiler warning */
> + (void) driver_vendor;
> + (void) driver_renderer;
>
A single version of Mesa potentially supports many different hardware
types, and those different hardware types may define different values of
GLSL built-in constants. They also may require core Mesa to do different
sets of lowering passes during compilation. So we can't just ignore
driver_vendor and driver_renderer. We need to reject the binary blob if
they don't match.
> +
> + shader->Version = map->read_uint32_t();
> + shader->Type = map->read_uint32_t();
> + shader->IsES = map->read_uint8_t();
> +
> + CACHE_DEBUG("%s: version %d, type 0x%x, %s (mesa %s)\n[%s %s]\n",
> + __func__, shader->Version, shader->Type,
> + (shader->IsES) ? "glsl es" : "desktop glsl",
> + cache_magic_id, driver_vendor, driver_renderer);
> +
> + const char *magic = mesa_get_shader_cache_magic();
> +
> + if (memcmp(cache_magic_id, magic, strlen(magic)))
> + return DIFFERENT_MESA_VER;
>
If cache_magic_id is "foobar" and magic is "foo", this will erroneusly
consider them equal. The correct way to do this is to use strcmp().
> +
> + /* post-link data */
> + shader->num_samplers = map->read_uint32_t();
> + shader->active_samplers = map->read_uint32_t();
> + shader->shadow_samplers = map->read_uint32_t();
> + shader->num_uniform_components = map->read_uint32_t();
> + shader->num_combined_uniform_components = map->read_uint32_t();
> + shader->uses_builtin_functions = map->read_uint8_t();
> +
> + map->read(&shader->Geom, sizeof(shader->Geom));
> +
> + for (unsigned i = 0; i < MAX_SAMPLERS; i++)
> + shader->SamplerUnits[i] = map->read_uint8_t();
> +
> + for (unsigned i = 0; i < MAX_SAMPLERS; i++)
> + shader->SamplerTargets[i] = (gl_texture_index) map->read_int32_t();
> +
> + return 0;
> +}
> +
> +
> +const glsl_type *
> +ir_deserializer::read_glsl_type()
> +{
> + char *name = map->read_string();
> + uint32_t type_size = map->read_uint32_t();
> +
> + const glsl_type *existing_type =
> + state->symbols->get_type(name);
> +
> + /* if type exists, move read pointer forward and return type */
> + if (existing_type) {
> + map->ffwd(type_size);
> + return existing_type;
> + }
> +
> + uint8_t base_type = map->read_uint8_t();
> + uint32_t length = map->read_uint32_t();
> + uint8_t vector_elms = map->read_uint8_t();
> + uint8_t matrix_cols = map->read_uint8_t();
> + uint8_t interface_packing = map->read_uint8_t();
> +
> + /* array type has additional element_type information */
> + if (base_type == GLSL_TYPE_ARRAY) {
> + const glsl_type *element_type = read_glsl_type();
> + if (!element_type) {
> + CACHE_DEBUG("error reading array element type\n");
> + return NULL;
> + }
> + return glsl_type::get_array_instance(element_type, length);
> + }
> +
> + /* structures have fields containing of names and types */
> + else if (base_type == GLSL_TYPE_STRUCT ||
> + base_type == GLSL_TYPE_INTERFACE) {
> + glsl_struct_field *fields = ralloc_array(mem_ctx,
> + glsl_struct_field, length);
> +
> + if (!fields)
> + return glsl_type::error_type;
> +
> + for (unsigned k = 0; k < length; k++) {
> + uint8_t row_major, interpolation, centroid;
> + int32_t location;
> + char *field_name = map->read_string();
> + fields[k].name = _mesa_strdup(field_name);
> + fields[k].type = read_glsl_type();
> + row_major = map->read_uint8_t();
> + location = map->read_int32_t();
> + interpolation = map->read_uint8_t();
> + centroid = map->read_uint8_t();
> + fields[k].row_major = row_major;
> + fields[k].location = location;
> + fields[k].interpolation = interpolation;
> + fields[k].centroid = centroid;
>
Another security issue: if the binary blob is corrupted, length may be
outrageously large (e.g. 0x). We need a way for this loop to bail
out and exit if it tries to read past the end of the binary blob.
> + }
> +
> + const glsl_type *ret_type = NULL;
> +
> + if (base_type == GLSL_TYPE_STRUCT)
> + ret_type = glsl_type::get_record_instance(fields, length, name);
> + else if (base_type == GLSL_TYPE_INTERFACE)
> + ret_type = glsl_type::get_interface_instance(fields,
> +length, (glsl_interface_packing) interface_packing, name);
> +
> + /* free allo
Re: [Mesa-dev] gallium endianness and hw drivers
I think the format conversion functions should look like: #ifdef BIG_ENDIAN case PIPE_FORMAT_A8B8G8R8_UNORM: return hw_format_for_R8G8B8A8_UNORM; ... #else case PIPE_FORMAT_R8G8B8A8_UNORM: return hw_format_for_R8G8B8A8_UNORM; #endif which can be simplified to: case PIPE_FORMAT_RGBA_UNORM: return hw_format_for_R8G8B8A8_UNORM; So that the GPU can see the same formats, but they are different for the CPU. What do you think? Marek On Mon, Jan 6, 2014 at 10:00 AM, Michel Dänzer wrote: > On Fre, 2013-12-27 at 19:41 +0100, Marek Olšák wrote: >> Okay. Using Axxx for transfers only is a good idea, just please make >> sure the formats are not advertised to the state tracker. > > Advertising the format to the state tracker is the whole point :), as > it's the format that matches the X11 semantics on big endian hosts. > > > -- > Earthling Michel Dänzer| http://www.amd.com > Libre software enthusiast |Mesa and X developer > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Naming everything in src/gallium/drivers/radeonsi si_*
Pushed, thanks. Marek On Mon, Jan 13, 2014 at 10:00 PM, Andreas Hartmetz wrote: > I don't have an fdo account or push rights. Can somebody else push it > for me please? I've added the Reviewed-by: lines so the patches only > need to be pushed now. > > On Monday 13 January 2014 11:22:07 Marek Olšák wrote: >> For the series: >> >> Reviewed-by: Marek Olšák >> >> Feel free to push this. >> >> Marek >> >> On Sat, Jan 11, 2014 at 4:20 PM, Andreas Hartmetz > wrote: >> > Continuing here because the threads had diverged... >> > >> > I've updated the patch series under the same URL and applied all the >> > suggested improvements. The variable renames are still in, but at the >> > very end so they are trivial to omit. >> > >> > On Tuesday 07 January 2014 17:27:56 Andreas Hartmetz wrote: >> >> We have talked on IRC meanwhile: >> >> "Everywhere" was supposed to mean file names and data structures. >> >> >> >> I have made a patch series (git link because file renames produce huge >> >> diffs) that renames *everything* away from r600 (and also radeonsi) >> >> to si, where it is actually about SI. In the such modified code it is >> >> then clear at first glance that only resources, textures and some >> >> other low-level interface code from R600 / generic Radeon are actually >> >> used in SI code. >> >> >> >> The patch series is ordered by increasing controversy potential due >> >> to destruction of git blame history, so the last parts can be omitted >> >> if they are deemed too destructive to history. In my opinion, it is >> >> better to have code that is readable now than code that is less >> >> readable but with the possibility to look up how it became like that. >> >> >> >> Michel said on IRC that he'd prefer to keep the name radeonsi_pipe.h/c, >> >> I disagree: If the library name is to be kept, there must be a break >> >> between radeonsi and si *somewhere*, and it is normal for library names >> >> to not correspond to any file name in the library. The same scheme is >> >> used in llvmpipe, llvmpipe lib / directory versus lp_* file names. >> >> >> >> Here's the repository (branch is master): >> >> git git://anongit.kde.org/scratch/ahartmetz/mesa.git >> >> web http://quickgit.kde.org/?p=scratch%2Fahartmetz%2Fmesa.git >> >> >> >> On Monday 06 January 2014 15:50:05 Marek Olšák wrote: >> >> > It sounds good, but I'd like the prefix to be si_ everywhere. >> >> > >> >> > Marek >> >> > >> >> > On Mon, Jan 6, 2014 at 2:47 PM, Andreas Hartmetz >> >> >> >> wrote: >> >> > > Hello, >> >> > > >> >> > > many of the files in radeonsi originally came from other places where >> >> > > they had different names and were never renamed. >> >> > > Most of them now have names that don't tell what the files are for >> >> > > (r600 is not actually the first hardware supported by them, they >> >> > > start >> >> > > at radeonsi), and even those with radeonsi are split between >> >> > > radeonsi_ and si_. >> >> > > si_ is shorter than radeonsi_, but inconsistent with the directory >> >> > > and >> >> > > library name. I still think it's the best option, but no strong >> >> > > opinion >> >> > > from me. If and when the files are renamed, the next step would be >> >> > > doing the same with the r600_ struct and function names. >> >> > > Does that sound good? I'll send the patches shortly if so. >> >> > > >> >> > > Cheers, >> >> > > Andreas >> >> > > ___ >> >> > > 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] opencl: improved auto-gen .icd
On Mon, Jan 13, 2014 at 11:12 AM, Tom Stellard wrote: > On Sun, Jan 12, 2014 at 03:08:56AM +0400, Igor Gnatenko wrote: >> From 5b2bf87f1238e44150492a39f5db0ae90d59459b Mon Sep 17 00:00:00 2001 >> From: Igor Gnatenko >> Date: Sun, 12 Jan 2014 02:09:16 +0400 >> Subject: [PATCH] opencl: improved auto-gen .icd >> >> v2: Use @OPENCL_VERSION@:0 for library >> replace /etc with @sysconfdir@ macros >> >> Reported-by: Fabian Deutsch >> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=73512 >> Signed-off-by: Igor Gnatenko >> --- >> configure.ac | 3 +++ >> src/gallium/targets/opencl/Makefile.am | 4 ++-- >> src/gallium/targets/opencl/mesa.icd| 1 - >> src/gallium/targets/opencl/mesa.icd.in | 1 + >> 4 files changed, 6 insertions(+), 3 deletions(-) >> delete mode 100644 src/gallium/targets/opencl/mesa.icd >> create mode 100644 src/gallium/targets/opencl/mesa.icd.in >> >> diff --git a/configure.ac b/configure.ac >> index 4b55140..3452e15 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -25,6 +25,8 @@ m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) >> dnl Set internal versions >> OSMESA_VERSION=8 >> AC_SUBST([OSMESA_VERSION]) >> +OPENCL_VERSION=1 >> +AC_SUBST([OPENCL_VERSION]) >> >> dnl Versions for external dependencies >> LIBDRM_REQUIRED=2.4.24 >> @@ -2023,6 +2025,7 @@ AC_CONFIG_FILES([Makefile >> src/gallium/targets/egl-static/Makefile >> src/gallium/targets/gbm/Makefile >> src/gallium/targets/opencl/Makefile >> + src/gallium/targets/opencl/mesa.icd >> src/gallium/targets/osmesa/Makefile >> src/gallium/targets/osmesa/osmesa.pc >> src/gallium/targets/pipe-loader/Makefile >> diff --git a/src/gallium/targets/opencl/Makefile.am >> b/src/gallium/targets/opencl/Makefile.am >> index 653302c..923316c 100644 >> --- a/src/gallium/targets/opencl/Makefile.am >> +++ b/src/gallium/targets/opencl/Makefile.am >> @@ -4,7 +4,7 @@ lib_LTLIBRARIES = lib@OPENCL_LIBNAME@.la >> >> lib@OPENCL_LIBNAME@_la_LDFLAGS = \ >> $(LLVM_LDFLAGS) \ >> - -version-number 1:0 >> + -version-number @OPENCL_VERSION@:0 >> >> lib@OPENCL_LIBNAME@_la_LIBADD = \ >> $(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader.la \ >> @@ -34,7 +34,7 @@ lib@OPENCL_LIBNAME@_la_SOURCES = >> nodist_EXTRA_lib@OPENCL_LIBNAME@_la_SOURCES = dummy.cpp >> >> if HAVE_CLOVER_ICD >> -icddir = /etc/OpenCL/vendors/ >> +icddir = @sysconfdir@/OpenCL/vendors/ > > As I mentioned in the bug report, the ICD spec says that OpenCL/vendors/ > should be in /etc/ I don't think we can change this and still be spec > compliant. Why do you want to install the *.icd files in sysconfdir? sysconfdir basically is etc. This hunk would allow you to install into a prefix and not have this file installed into /etc outside of your prefix. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73512] [clover] mesa.icd. should contain full path
https://bugs.freedesktop.org/show_bug.cgi?id=73512 --- Comment #11 from Igor Gnatenko --- (In reply to comment #8) > (In reply to comment #7) > > Created attachment 91973 [details] [review] [review] > > [PATCH v3] opencl: improved auto-gen .icd > > > > v2: Use @OPENCL_VERSION@:0 for library > > replace /etc with @sysconfdir@ macros > > > > v3: Drop libdir from icd, because libMesaOpenCL isn't private > > If we install the *.icd file to @sysconfdir@ and not /etc then standards > compliant ICD loaders will not work with clover. The way I interpret the > spec, we have no choice, but to install it to /etc . Why is it necessary to > use @sysconfdir@ ? Yes. I'm sorry. https://forge.imag.fr/plugins/scmgit/cgi-bin/gitweb.cgi?p=ocl-icd/ocl-icd.git;a=blob;f=ocl_icd_loader.c;h=ab419b2dccb82db6d632cae6dc86e5151a320c07;hb=HEAD#l52 Only /etc will work. Fixed. Patch here. -- 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 73571] [clover] Add support for NULL global memory object arguments
https://bugs.freedesktop.org/show_bug.cgi?id=73571 Jan Vesely changed: What|Removed |Added Summary|[clover] OpenCL segfault in |[clover] Add support for |gegl 'clones' test |NULL global memory object ||arguments -- 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 73571] [clover] OpenCL segfault in gegl 'clones' test
https://bugs.freedesktop.org/show_bug.cgi?id=73571 --- Comment #3 from Jan Vesely --- Created attachment 92006 --> https://bugs.freedesktop.org/attachment.cgi?id=92006&action=edit Don't crash on NULL global mem objects The attached patch fixes the original issue (bt in #c2), and adds prelimnary support for NULL global mem objects. -- 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 72926] Memory corruption (crash) in draw/draw_pt_fetch_shade_pipeline_llvm.c:435
https://bugs.freedesktop.org/show_bug.cgi?id=72926 Peter Wu changed: What|Removed |Added CC||za...@vmware.com -- 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] Use AC_PATH_TOOL instead of AC_PATH_PROG for llvm-config.
On Mon, Jan 13, 2014 at 07:04:44PM +0100, Michał Górny wrote: > Dnia 2014-01-13, o godz. 08:59:22 > Tom Stellard napisał(a): > > > On Sat, Dec 28, 2013 at 03:22:09PM +0100, Michał Górny wrote: > > > This should help with cross-compiling and multilib when $CHOST-specific > > > llvm-config is expected rather than build host default one. > > > > > > It will help us a bit in Gentoo where we've started using > > > i686-pc-linux-gnu-llvm-config for 32-bit multilib LLVM. > > > > > Reviewed-by: Tom Stellard > > > > Should we CC stable on this patch? > > I have no strong opinion here. It would be a bit helpful though it's > not a killer feature for us (yet :)). > > > Do you have commit access? > > No, I don't. > I've pushed this patch and added CC: Stable. Thanks! -Tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 72926] Memory corruption (crash) in draw/draw_pt_fetch_shade_pipeline_llvm.c:435
https://bugs.freedesktop.org/show_bug.cgi?id=72926 Peter Wu changed: What|Removed |Added CC||lekenst...@gmail.com --- Comment #8 from Peter Wu --- bisecting with the small program (via glretrace) and ASN + -O0 and -g still points to the same faulty commit: a3ae5dc7dd5c2f8893f86a920247e690e550ebd4 is the first bad commit commit a3ae5dc7dd5c2f8893f86a920247e690e550ebd4 Author: Zack Rusin Date: Fri Aug 9 10:11:31 2013 -0400 draw: make sure that the stages setup outputs Calling the prepare outputs cleans up the slot assignments for outputs, unfortunately aapoint and aaline didn't have code to reset their slots after the initial setup, this was messing up our slot assignments. The unfilled stage was just missing the initial assignment of the face slot. This fixes all of the reported piglit failures. Signed-off-by: Zack Rusin Reviewed-by: Roland Scheidegger :04 04 fb87dfd2039663da7ff0fa6f12a5b0668fecee7f fc98438608d4df5bd64ff651bf9098aaabc5a262 M src git bisect log: git bisect start # bad: [277dbf08b0e78fe6cff0fc751768a6f3d33e61f7] glsl: Remove exec_list iterators now that nothing uses them. git bisect bad 277dbf08b0e78fe6cff0fc751768a6f3d33e61f7 # skip: [3e385d1bc314a50c9572b04210c4d6ac1b0a7381] docs: Add release notes for the 9.2.4 release. git bisect skip 3e385d1bc314a50c9572b04210c4d6ac1b0a7381 # good: [3e385d1bc314a50c9572b04210c4d6ac1b0a7381] docs: Add release notes for the 9.2.4 release. git bisect good 3e385d1bc314a50c9572b04210c4d6ac1b0a7381 # skip: [9f07ca11c1797ac12de1e1c6aef13cf58824b5f5] mesa: Dispatch ARB_framebuffer_object and EXT_framebuffer_object differently git bisect skip 9f07ca11c1797ac12de1e1c6aef13cf58824b5f5 # skip: [9f07ca11c1797ac12de1e1c6aef13cf58824b5f5] mesa: Dispatch ARB_framebuffer_object and EXT_framebuffer_object differently git bisect skip 9f07ca11c1797ac12de1e1c6aef13cf58824b5f5 # bad: [8d4ecbccd6a5608005b5c8f473d9a44dbde0b08d] i965: Remove #define name from PCI ID table. git bisect bad 8d4ecbccd6a5608005b5c8f473d9a44dbde0b08d # bad: [7086636358b611a2bb124253e1fe870107e1cecb] nvc0/ir: fix use after free in texture barrier insertion pass git bisect bad 7086636358b611a2bb124253e1fe870107e1cecb # bad: [e858921d527bfcbbda27760f781c25cab469e852] ilo: implement new float comparison instructions git bisect bad e858921d527bfcbbda27760f781c25cab469e852 # bad: [e858921d527bfcbbda27760f781c25cab469e852] ilo: implement new float comparison instructions git bisect bad e858921d527bfcbbda27760f781c25cab469e852 # good: [6065a87bce0c3fb0d9694c381c5a31b63e1f0300] glsl: Cross-validate GS layout qualifiers while intrastage linking. git bisect good 6065a87bce0c3fb0d9694c381c5a31b63e1f0300 # good: [6065a87bce0c3fb0d9694c381c5a31b63e1f0300] glsl: Cross-validate GS layout qualifiers while intrastage linking. git bisect good 6065a87bce0c3fb0d9694c381c5a31b63e1f0300 # good: [331a8fa41d174c74afe58f43a5943627398eac6b] gallium-egl: Simplify native_wayland_drm_bufmgr_helper interface git bisect good 331a8fa41d174c74afe58f43a5943627398eac6b # good: [2c32c3985ca6232a81d21feb9ac6443145b42d0e] i965/fs: Consider predicated SEL instructions as whole variable writes. git bisect good 2c32c3985ca6232a81d21feb9ac6443145b42d0e # good: [438cc6bc49d109f9ddeed6a741c4f0b8f1c4ffe2] mesa: Make detach_renderbuffer available outside fbobject.c git bisect good 438cc6bc49d109f9ddeed6a741c4f0b8f1c4ffe2 # good: [336351e971d6232bbed11d9812ebf05341b6aa36] glsl/ast: Check that geometry shader interface block inputs are arrays. git bisect good 336351e971d6232bbed11d9812ebf05341b6aa36 # good: [98d2498404ba69a3efc1c765b1a1885d151181ed] glsl: Fix incorrect pattern matching in ir_set_program_inouts git bisect good 98d2498404ba69a3efc1c765b1a1885d151181ed # bad: [c6c55ad3e967f3d151c24795a99634b297c13fde] gallivm: fix border color with normalized texture formats git bisect bad c6c55ad3e967f3d151c24795a99634b297c13fde # bad: [27cedd8aecccea808a35ef297477cac5fe87e476] llvmpipe: fix pipeline statistics with a null ps git bisect bad 27cedd8aecccea808a35ef297477cac5fe87e476 # bad: [a3ae5dc7dd5c2f8893f86a920247e690e550ebd4] draw: make sure that the stages setup outputs git bisect bad a3ae5dc7dd5c2f8893f86a920247e690e550ebd4 # first bad commit: [a3ae5dc7dd5c2f8893f86a920247e690e550ebd4] draw: make sure that the stages setup outputs -- 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] Mesa 10.1 release plan strawman
Fast forwarding 3 months from the 10.0 release (November 30th) is February 28th. I'd like to propose the following set of dates: January 31st: Feature freeze / 10.1 branch created. I promise to not let anyone on my team (myself included) dump any giant commit series the day of the freeze. I'll be traveling to FOSDEM, so this may be delayed by a day (or someone else may make the branch). February 7th: RC1 February 14th: RC2, with chocolates and flowers February 21st: RC3 February 28th: 10.1 final release Does this plan sound reasonable to all? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [wip 3/9] glsl: memory_map helper class for data deserialization
On 2 January 2014 03:58, Tapani Pälli wrote:
> Class will be used by the shader binary cache implementation.
>
> Signed-off-by: Tapani Pälli
> ---
> src/glsl/memory_map.h | 174
> ++
> 1 file changed, 174 insertions(+)
> create mode 100644 src/glsl/memory_map.h
>
> diff --git a/src/glsl/memory_map.h b/src/glsl/memory_map.h
> new file mode 100644
> index 000..1b68b72
> --- /dev/null
> +++ b/src/glsl/memory_map.h
> @@ -0,0 +1,174 @@
> +/* -*- c++ -*- */
> +/*
> + * Copyright © 2013 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.
> + */
> +
> +#pragma once
> +#ifndef MEMORY_MAP_H
> +#define MEMORY_MAP_H
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#ifdef __cplusplus
> +
> +/**
> + * Helper class to read data
> + *
> + * Class can read either from user given memory or from a file. On Linux
> + * file reading wraps around the Posix functions for mapping a file into
> + * the process's address space. Other OS may need different
> implementation.
> + */
> +class memory_map
> +{
> +public:
> + memory_map() :
> + mode(memory_map::READ_MEM),
> + fd(0),
> + cache_size(0),
> + cache_mmap(NULL),
> + cache_mmap_p(NULL)
> + {
> + /* only used by read_string() */
> + mem_ctx = ralloc_context(NULL);
> + }
> +
> + /* read from disk */
> + int map(const char *path)
> + {
> + struct stat stat_info;
> + if (stat(path, &stat_info) != 0)
> + return -1;
>
As before, I'm not thrilled with the use of -1 to mean failure and 0 to
mean success, because it forces the caller to use counterintuitive if
statements. I'd prefer for map() to return a bool with true meaning
success and false meaning failure.
> +
> + mode = memory_map::READ_MAP;
> + cache_size = stat_info.st_size;
> +
> + fd = open(path, O_RDONLY);
> + if (fd) {
> + cache_mmap_p = cache_mmap = (char *)
> +mmap(NULL, cache_size, PROT_READ, MAP_PRIVATE, fd, 0);
> + return (cache_mmap == MAP_FAILED) ? -1 : 0;
>
MAP_FAILED is a nonzero value, so if this error condition ever occurs, the
destructor will errneously try to call munmap().
What I'd recommend doing instead is:
void *mmap_result = mmap(...);
if (mmap_result == MAP_FAILED) {
close(fd);
return -1;
}
cache_mmap_p = cache_mmap = (char *) mmap_result;
return 0;
>
> + }
> + return -1;
> + }
> +
> + /* read from memory */
> + int map(const void *memory, size_t size)
> + {
> + cache_mmap_p = cache_mmap = (char *) memory;
> + cache_size = size;
> + return 0;
> + }
>
IMHO, functions that cannot fail should return void.
> +
> + /* wrap a portion from another map */
> + int map(memory_map &map, size_t size)
> + {
> + cache_mmap_p = cache_mmap = map.cache_mmap_p;
> + cache_size = size;
> + map.ffwd(size);
> + return 0;
> + }
> +
> + ~memory_map() {
> + if (cache_mmap && mode == READ_MAP) {
> + munmap(cache_mmap, cache_size);
> + close(fd);
> + }
> + ralloc_free(mem_ctx);
> + }
> +
> + /* move read pointer forward */
> + inline void ffwd(int len)
> + {
> + cache_mmap_p += len;
> + }
> +
> + inline void jump(unsigned pos)
> + {
> + cache_mmap_p = cache_mmap + pos;
> + }
> +
> +
> + /* position of read pointer */
> + inline uint32_t position()
> + {
> + return cache_mmap_p - cache_mmap;
> + }
> +
> + inline char *read_string()
> + {
> + char *str = ralloc_strdup(mem_ctx, cache_mmap_p);
> + ffwd(strlen(str)+1);
> + return str;
>
This is problematic from a security perspective. If the client provides
corrupted data that ends in a truncated string (lacking a null terminator)
that could cause ralloc_strdup() to try to read beyond the end of the
file. We
Re: [Mesa-dev] [PATCH 3/7] mesa: implement glBindTextures()
On 01/07/2014 12:05 AM, Fredrik Höglund wrote:
> On Friday 03 January 2014, Marek Olšák wrote:
>> On Fri, Jan 3, 2014 at 2:04 PM, Marek Olšák wrote:
>>> On Fri, Jan 3, 2014 at 1:27 AM, Maxence Le Doré
>>> wrote:
---
src/mesa/main/texobj.c | 52
++
src/mesa/main/texobj.h | 3 +++
2 files changed, 55 insertions(+)
diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index bddbc50..66e2fb0 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -1686,4 +1686,56 @@ _mesa_InvalidateTexImage(GLuint texture, GLint
level)
return;
}
+/** ARB_multi_bind / OpenGL 4.4 */
+
+void GLAPIENTRY
+_mesa_BindTextures(GLuint first, GLsizei count, const GLuint *textures)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ struct GLuint currentTexUnit = 0;
+ int i = 0;
+
+ currentTexUnit = ctx->Texture.CurrentUnit;
+
+ if(first + count > ctx->Const.MaxCombinedTextureImageUnits) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
"glBindTextures(first+count)");
+ return;
+ }
+
+ for(i = 0 ; i < count ; i++) {
+ GLuint texture;
+ struct gl_texture_object *texObj;
+ GLenum texTarget;
+ int j = 0;
+
+ if(textures == NULL)
+texture = 0;
+ else
+texture = textures[i];
+
+ _mesa_ActiveTexture(GL_TEXTURE0 + first + i);
+ if(texture != 0) {
+texObj = _mesa_lookup_texture(ctx, texture);
+if(texObj) {
+ texTarget = texObj->Target;
+ _mesa_BindTexture(texTarget, texture);
+}
+else
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glBindTextures(textures[%i])", i);
>>>
>>> This error is set too late. It should be done before changing textures.
>>
>> Note that you make the same mistake in the other patches too. Also
>> please double-check that none of the _mesa_ functions generate errors.
>
> This is actually not the case with the ARB_multi_bind functions:
>
> (11) Typically, OpenGL specifies that if an error is generated by a
> command, that command has no effect. This is somewhat unfortunate
> for multi-bind commands, because it would require a first pass to
> scan the entire list of bound objects for errors and then a second
> pass to actually perform the bindings. Should we have different
> error semantics?
>
> RESOLVED: Yes. In this specification, when the parameters for one of
> the binding points are invalid, that binding point is not
> updated and an error will be generated. However, other binding points
> in the same command will be updated if their parameters are valid and no
> other error occurs.
The code should reference this spec text. Otherwise someone will come
along later and try to "fix" it.
> The code is still wrong for a different reason though; when a texture has
> has never been bound, it doesn't have a target. That case needs to be
> handled correctly.
>
> Fredrik
>
> ___
> 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] automake: include the git sha in the opengl version string for oot builds
On Mon, Jan 13, 2014 at 02:02:12AM +, Emil Velikov wrote: > Because it's a great feature and we should not penalise people > for doing out-of-tree builds. > > Signed-off-by: Emil Velikov > --- > src/mesa/Makefile.am | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) Please. Acked-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73512] [clover] mesa.icd. should contain full path
https://bugs.freedesktop.org/show_bug.cgi?id=73512 Igor Gnatenko changed: What|Removed |Added Attachment #91973|0 |1 is obsolete|| --- Comment #10 from Igor Gnatenko --- Created attachment 92004 --> https://bugs.freedesktop.org/attachment.cgi?id=92004&action=edit [PATCH v4] opencl: improved auto-gen .icd v2: Use @OPENCL_VERSION@:0 for library replace /etc with @sysconfdir@ macros v3: Drop libdir from icd, because libMesaOpenCL isn't private v4: install ocl vendor always to /etc -- 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] [wip 2/9] glsl: serialize methods for IR instructions
On 2 January 2014 03:58, Tapani Pälli wrote:
> diff --git a/src/glsl/ir_serialize.cpp b/src/glsl/ir_serialize.cpp
> new file mode 100644
> index 000..30ca018
> --- /dev/null
> +++ b/src/glsl/ir_serialize.cpp
> @@ -0,0 +1,392 @@
> +/* -*- c++ -*- */
> +/*
> + * Copyright © 2013 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 "ir_serialize.h"
> +
> +
> +/**
> + * Wraps serialization of an ir instruction, writes ir_type
> + * and length of each instruction package as a header for it
> + */
> +void
> +ir_instruction::serialize(memory_writer &mem)
> +{
> + uint32_t data_len = 0;
> + uint8_t ir_type = this->ir_type;
> + mem.write_uint8_t(ir_type);
> +
> + int32_t start_pos = mem.position();
> + mem.write_uint32_t(data_len);
> +
> + this->serialize_data(mem);
> +
> + data_len = mem.position() - start_pos - sizeof(data_len);
> + mem.overwrite(&data_len, sizeof(data_len), start_pos);
>
This function isn't checking the return values from mem.write_*(), so
there's no way for it to detect failure. Also, since this function returns
void, there's no way for it to notify the caller of failure. A similar
comment applies to all of the other serialize*() functions in this patch.
(Of course, considering our previous discussion about potentially removing
these int return values, this issue may be moot).
> +}
> +
> +
> +
> +
> +static void
> +serialize_glsl_type(const glsl_type *type, memory_writer &mem)
>
The last time I reviewed this series, I mentioned the idea of making a
hashtable that maps each glsl_type to a small integer, so that we could
serialize each type just once (see
http://lists.freedesktop.org/archives/mesa-dev/2013-November/047740.html).
At the time, it sounded like you liked that idea. Have you made that
change? It looks to me like you've stopped serializing the built-in types,
but user-defined types are still serialized each time they occur.
With those two issues addressed, the patch is:
Reviewed-by: Paul Berry
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 72926] Memory corruption (crash) in draw/draw_pt_fetch_shade_pipeline_llvm.c:435
https://bugs.freedesktop.org/show_bug.cgi?id=72926 Peter Wu changed: What|Removed |Added Attachment #91216|0 |1 is obsolete|| --- Comment #7 from Peter Wu --- Created attachment 92001 --> https://bugs.freedesktop.org/attachment.cgi?id=92001&action=edit smaller apitrace output for "robot" program This is a smaller test case, the previous gdb output was generated using Mesa 10.0.2 + LLVM 3.4. ./configure line: LDFLAGS='-fsanitize=address -lasan' CFLAGS='-g -O0 -fsanitize=address -fno-omit-frame-pointer' \ CXXFLAGS="$CFLAGS" \ ./configure --enable-debug --prefix=/tmp/mesa-root \ --with-gallium-drivers=swrast --with-llvm-shared-libs \ --enable-gallium-llvm --enable-shared-glapi --enable-dri \ --enable-glx --with-dri-drivers= -- 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 73512] [clover] mesa.icd. should contain full path
https://bugs.freedesktop.org/show_bug.cgi?id=73512 --- Comment #9 from Igor Gnatenko --- (In reply to comment #8) > (In reply to comment #7) > > Created attachment 91973 [details] [review] [review] > > [PATCH v3] opencl: improved auto-gen .icd > > > > v2: Use @OPENCL_VERSION@:0 for library > > replace /etc with @sysconfdir@ macros > > > > v3: Drop libdir from icd, because libMesaOpenCL isn't private > > If we install the *.icd file to @sysconfdir@ and not /etc then standards > compliant ICD loaders will not work with clover. The way I interpret the > spec, we have no choice, but to install it to /etc . Why is it necessary to > use @sysconfdir@ ? why I can't install mesa in /usr/local or in /opt ? I think no problems there.. Should I update patch w/o/ this macros ? -- 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 72926] Memory corruption (crash) in draw/draw_pt_fetch_shade_pipeline_llvm.c:435
https://bugs.freedesktop.org/show_bug.cgi?id=72926 Peter Wu changed: What|Removed |Added Attachment #91053|0 |1 is obsolete|| --- Comment #6 from Peter Wu --- Created attachment 92000 --> https://bugs.freedesktop.org/attachment.cgi?id=92000&action=edit gdb bt full for smaller C program "robot" -- 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 08/10] i965: Introduce an OUT_RELOC64 macro.
On 01/13/2014 01:04 PM, Eric Anholt wrote: > Kenneth Graunke writes: > >> On 01/09/2014 09:31 PM, Eric Anholt wrote: >>> Kenneth Graunke writes: >>> On 12/13/2013 09:28 AM, Daniel Vetter wrote: > On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote: >> Broadwell uses 48-bit addresses. The first DWord is the low 32 bits, >> and the second DWord is the high 16 bits. >> >> Since individual buffers shouldn't be larger than 4GB in size, any >> offsets into those buffers (buffer->offset + delta) should fit in the >> low 32 bits. So I believe we can simply emit 0 for the high 16-bits, >> and drm_intel_bo_emit_reloc() should patch it up. >> >> Signed-off-by: Kenneth Graunke >> --- >> src/mesa/drivers/dri/i965/intel_batchbuffer.h | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h >> b/src/mesa/drivers/dri/i965/intel_batchbuffer.h >> index 159f928..128eed9 100644 >> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h >> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h >> @@ -178,6 +178,11 @@ void intel_batchbuffer_cached_advance(struct >> brw_context *brw); >> read_domains, write_domain, delta); >> \ >> } while (0) >> >> +/* Handle 48-bit address relocations for Gen8+ */ >> +#define OUT_RELOC64(buf, read_domains, write_domain, delta) \ >> + OUT_RELOC(buf, read_domains, write_domain, delta); \ >> + OUT_BATCH(0); > > Please not. The presumed_offset that libdrm uses is 64bits, and you need > to emit the full presumed address (and correctly shifted). Atm the kernel > never gives you a presumed reloc offset with the high bits set so it > doesn't matter. But I'd prefer if we don't need to make this opt-in > behaviour once we enable address spaces with more than 4G. > > i-g-t gets away with the cheap hack since we're allowed to break igt. > Let me check ddx and libva whether I've lost this fight already ... > -Daniel I'm more than happy to do the right thing, I just don't know what that is. I don't see any uint64_t values in the interface we use at all: OUT_RELOC becomes ret = drm_intel_bo_emit_reloc(brw->batch.bo, 4*brw->batch.used, buffer, delta, read_domains, write_domain); >>> >>> The libdrm ABI is a disaster. bo->offset is a long, so we're keeping 32 >>> bits of the kernel's returned value on 32 bit userspace, and 64 bits on >>> 64 bit userspace. This means that on 32-bit we'll write in an >>> expected-incorrect offset in the presumed offset for a >4g-located BO, >>> which the kernel will map and fix up at exec time. On 64-bit, your >>> patch would write an expected-incorrect 32-bit value into the batch, but >>> libdrm would tell the kernel the full expected 64 bit value in the >>> presumed_offset field, and you'll get brokenness for >4g buffers. >>> >>> So, I think you do need a drm_intel_bo_emit_reloc64 that returns a >>> uint64_t value that the kernel wrote into the presumed offset, which you >>> then plug into your batchbuffer. >>> >>> (In other news, while thinking about this, there are some obscure races >>> with buffer migration due to presumed_offset being read at a separate >>> time from when we look up bo->offset to actually write the offset into >>> the batch, in the presence of context sharing in GL). >> >> I'd really like to land this patch as-is, since I need it to land the >> rest of my Broadwell code. I would update the commit message to note >> that it's broken for >4G currently. > > I don't like landing known-broken code that will give you mysterious > hangs under memory pressure. I could possibly ack this if there was a > WARN_ON_ONCE or just having it be a stub or something, but "kind of > works except when you start running a big app or run something for a > long time" is not cool. Well, hooray for double standards, given that every other userspace component has landed this code, but didn't bother to even consolidate it into one easily fixable place... It's been over a year since I wrote most of this code, and I would REALLY like to actually land some things. But fine, I'll go write some libdrm patches... --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] How to contribute a translation?
Hi, I'd like to translate the DRI driver options (src/mesa/drivers/dri/common/xmlpool) to the Catalan language. What is the procedure for adding new translations? What tool should I use to generate ca.po, and how do I submit the file for review? -Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73512] [clover] mesa.icd. should contain full path
https://bugs.freedesktop.org/show_bug.cgi?id=73512 --- Comment #8 from Tom Stellard --- (In reply to comment #7) > Created attachment 91973 [details] [review] > [PATCH v3] opencl: improved auto-gen .icd > > v2: Use @OPENCL_VERSION@:0 for library > replace /etc with @sysconfdir@ macros > > v3: Drop libdir from icd, because libMesaOpenCL isn't private If we install the *.icd file to @sysconfdir@ and not /etc then standards compliant ICD loaders will not work with clover. The way I interpret the spec, we have no choice, but to install it to /etc . Why is it necessary to use @sysconfdir@ ? -- 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] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
On Mon, Jan 13, 2014 at 06:44:15PM +, Dorrington, Albert wrote: > Tom, > > Thanks for your response. I am very interested in implementing this, so any > pointers you can provide would be greatly appreciated. I'm cc'ing Fransisco since he may also have some feedback. The first step is to build a clover::module object from the binary code. When we compile OpenCL C, we use the build_module_llvm() function in llvm/invocation.cpp to do this. This function takes LLVM IR as input (stored in the LLVM:Module object) and produces a clover::module as output. With clCreateProgramFromBinary() we build a clover::module by deserializing the binary code using the module::deserialize function declared in module.cpp. This function expects the binary code to use a specific format, the code that is output from Clang/LLVM is not in the expected format which is probably why this is crashing for you. I don't think this format is documented anywhere, but you should be able to deduce it by looking through the code in core/module.cpp. The challenge is to get Clang/LLVM to produce code in the correct format. I think the correct way to do this would be to add a new triple, something like r600-clover-unknown, and then have the code emitter produce clover formatted code when it is passed this triple. However, I would recommend not worrying about the triple for now and just change the code emitter to emit clover's format. Once this is working, then we can go back and add the new triple. Once LLVM is producing the correct format, you will need to find a way for clover to communicate to the drivers that the code being passed is binary and not whatever its preferred IR is. One way to do this is to add the enum pipe_shader_ir ir_type; field to struct pipe_compute_state and use this to tell the drivers what kind of IR it has. You will also need to add the PIPE_SHADER_IR_BINARY type to enum pipe_hsader_ir. Then you will need to implement support for PIPE_SHADER_IR_BINARY in r600g. The code for doing this is already their you will just need to add a code path which skips over all of the LLVM compilation stages. Hopefully, this will help get you started. When it comes to generating a binary from clang and llvm. Here is the clang invocation I use: clang -o test.o -target r600-unknown-unknown -mcpu=redwood -integrated-as -c test.cl Note that this will work only if you uses non-vector types and don't use any builtin functions. To cover all use cases you can use the attached shell script to compile the code. -Tom > I don't have access to IRC at work (at least I doubt I do) due to firewalls - > but I can use the mailing list. > > I wasn't entirely sure about the proper clang command line, so I wrote > another program which does the online compile, then saves the output away. > I think I can produce an appropriate binary now. > > I am currently using a Radeon 6670; so I assume it will be: -mcpu=turks > > It looks like the LLVM output from clang is identical with either -mcpu=turks > or -mcpu=r600. > I can't seem to make clang output a binary file. (I figure I'm not using > clang correctly) > Since I can capture the binary with another C program (I think) I'm not too > worried about using clang/llvm directly yet. > > Thanks! > -Al > > -Original Message- > From: Tom Stellard [mailto:t...@stellard.net] > Sent: Monday, January 13, 2014 1:12 PM > To: Dorrington, Albert > Cc: mesa-dev@lists.freedesktop.org > Subject: EXTERNAL: Re: [Mesa-dev] OpenCL Clang/Clover Offline Compilation > issue > > On Thu, Jan 09, 2014 at 12:49:51PM +, Dorrington, Albert wrote: > > I am not sure if this is the appropriate list on which to ask this > > question, if not hopefully someone can suggest an alternative. > > > > Under Linux, I am attempting to perform an offline compile of an OpenCL > > kernel example using Clang, and then load that binary using the > > clCreateProgramWithBinary() function. > > > > Unfortunately, while clover is loading the binary, I end up getting a > > segmentation fault: > > > > Program received signal SIGSEGV, Segmentation fault. > > proc (v=..., is=...) at core/module.cpp:50 > > 50T x; > > > > I have pasted the source code I am using below, for both the kernel and the > > host code. > > > > I am compiling with the following commands: > > clang -target r600-unknown-unknown -x cl -S -emit-llvm -mcpu=r600 > > kernel.cl -o kernel.clbin > > I'm surprised that this works, since the r600 GPU does not support OpenCL > (Note that R600 is the name of the target and also one of the individual GPUs > supported by the compiler). The argument of -mcpu= needs to be GPU you are > compiling the code for. So if you have a redwood GPU you would need to pass > -mcpu=redwood. > > However, the main issue here is that clover does not support > clCreateProgramWithBinary() yet. If you are interested in implementing this, > I can give you some pointers. Just send an email to the li
Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
Tom, Thanks for your response. I am very interested in implementing this, so any pointers you can provide would be greatly appreciated. I don't have access to IRC at work (at least I doubt I do) due to firewalls - but I can use the mailing list. I wasn't entirely sure about the proper clang command line, so I wrote another program which does the online compile, then saves the output away. I think I can produce an appropriate binary now. I am currently using a Radeon 6670; so I assume it will be: -mcpu=turks It looks like the LLVM output from clang is identical with either -mcpu=turks or -mcpu=r600. I can't seem to make clang output a binary file. (I figure I'm not using clang correctly) Since I can capture the binary with another C program (I think) I'm not too worried about using clang/llvm directly yet. Thanks! -Al -Original Message- From: Tom Stellard [mailto:t...@stellard.net] Sent: Monday, January 13, 2014 1:12 PM To: Dorrington, Albert Cc: mesa-dev@lists.freedesktop.org Subject: EXTERNAL: Re: [Mesa-dev] OpenCL Clang/Clover Offline Compilation issue On Thu, Jan 09, 2014 at 12:49:51PM +, Dorrington, Albert wrote: > I am not sure if this is the appropriate list on which to ask this question, > if not hopefully someone can suggest an alternative. > > Under Linux, I am attempting to perform an offline compile of an OpenCL > kernel example using Clang, and then load that binary using the > clCreateProgramWithBinary() function. > > Unfortunately, while clover is loading the binary, I end up getting a > segmentation fault: > > Program received signal SIGSEGV, Segmentation fault. > proc (v=..., is=...) at core/module.cpp:50 > 50T x; > > I have pasted the source code I am using below, for both the kernel and the > host code. > > I am compiling with the following commands: > clang -target r600-unknown-unknown -x cl -S -emit-llvm -mcpu=r600 > kernel.cl -o kernel.clbin I'm surprised that this works, since the r600 GPU does not support OpenCL (Note that R600 is the name of the target and also one of the individual GPUs supported by the compiler). The argument of -mcpu= needs to be GPU you are compiling the code for. So if you have a redwood GPU you would need to pass -mcpu=redwood. However, the main issue here is that clover does not support clCreateProgramWithBinary() yet. If you are interested in implementing this, I can give you some pointers. Just send an email to the list or ping me on irc (nick: tstellar on #radeon @ irc.freednode.net). -Tom > clang -g -L/usr/local/lib -lOpenCL offline_host.c -o offline_host > > I have LLVM/Clang 3.4RC3 installed and Mesa 10.0.1. > > If anyone has suggestions, or can point me to the appropriate mailing list or > documentation, I'd appreciate it. > > Thanks! > -Al ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Use sample barycentric coordinates with per sample shading
On Fri, Jan 10, 2014 at 5:25 PM, Anuj Phogat wrote: > On Thu, Jan 9, 2014 at 4:34 PM, Chris Forbes wrote: >> Hi Anuj, >> >> There's one fiddly interaction that I don't think this handles quite >> right, although I think it does conform. >> >> Suppose we have this fragment shader: >> >>#version 330 >>#extension ARB_gpu_shader5: require >> >>sample in vec4 a; >>in vec4 b; >> >>... >> >> Then `b` is being evaluated at the sample position as well. This is >> allowed by my reading of the spec, but probably not what the author >> expected. > Good catch. >> >> From the ARB_gpu_shader5 spec, emphasis mine: >> >> (11) Should we support per-sample interpolation of attributes? If so, >> how? >> >> RESOLVED. Yes. When multisample rasterization is enabled, qualifying >> one or more fragment shader inputs with "sample" will force per-sample >> interpolation of those attributes. If the same shader includes other >> fragment inputs not qualified with sample, those attributes _may_ be >> interpolated per-pixel (i.e., all samples get the same values, likely >> evaluated at the pixel center). >> >> What do you think? > I agree with your interpretation. Spec seems to be flexible about it. I'll > check > what NVIDIA does in this case. This should be easy to fix if we need to. I verified that NVIDIA doesn't evaluate variable 'b' at sample position. I'll send out an updated patch to match this behavior. >> >> -- Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73571] [clover] OpenCL segfault in gegl 'clones' test
https://bugs.freedesktop.org/show_bug.cgi?id=73571 --- Comment #2 from Jan Vesely --- I should have noted that my llvm git includes http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131216/199497.html. Without these patches the backtrace in clones.xml test looks like this: Program received signal SIGSEGV, Segmentation fault. 0x7fffee163705 in clover::kernel::global_argument::set (this=0xfee690, size=8, value=0x0) at core/kernel.cpp:330 330 buf = &obj(*(cl_mem *)value); (gdb) bt #0 0x7fffee163705 in clover::kernel::global_argument::set (this=0xfee690, size=8, value=0x0) at core/kernel.cpp:330 #1 0x7fffee1af9d6 in clSetKernelArg (d_kern=0x115e658, idx=1, size=8, value=0x0) at api/kernel.cpp:98 #2 0x77db32c2 in gegl_operation_point_composer_cl_process (level=0, result=0xc7f1d0, output=0x106b4b0, aux=0x0, input=0xe152f0, operation=0x9dd010) at gegl-operation-point-composer.c:195 #3 gegl_operation_point_composer_process (operation=0x9dd010, input=0xe152f0, aux=0x0, output=0x106b4b0, result=0xc7f1d0, level=0) at gegl-operation-point-composer.c:246 #4 0x77db2bc4 in gegl_operation_composer_process2 ( operation=0x9dd010, context=, output_prop=, result=0xc7f1d0, level=0) at gegl-operation-point-composer.c:117 #5 0x77dbbe46 in gegl_graph_process (path=0xcc1020) at gegl-graph-traversal.c:418 #6 0x77dbb268 in gegl_eval_manager_apply (self=self@entry=0x81df40, roi=roi@entry=0xb89140) at gegl-eval-manager.c:133 #7 0x77db67ed in gegl_node_apply_roi (self=self@entry=0xf8d030, roi=roi@entry=0xb89140) at gegl-node.c:887 #8 0x77db6c53 in gegl_node_blit (self=0xf8d030, scale=scale@entry=1, roi=roi@entry=0xb89140, format=0x63ee60, destination_buf=destination_buf@entry=0x1284530, rowstride=rowstride@entry=0, flags=flags@entry=GEGL_BLIT_DEFAULT) ---Type to continue, or q to quit--- at gegl-node.c:948 #9 0x77dbd0be in render_rectangle (processor=0xd7a560) at gegl-processor.c:502 #10 gegl_processor_render (progress=0x0, rectangle=0xd7a580, processor=0xd7a560) at gegl-processor.c:642 #11 gegl_processor_work (processor=processor@entry=0xd7a560, progress=progress@entry=0x0) at gegl-processor.c:777 #12 0x77db68b2 in gegl_node_process (self=) at gegl-node.c:1610 #13 0x00401d27 in main (argc=6, argv=0x7fffe008) at gegl.c:232 -- 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 08/10] i965: Introduce an OUT_RELOC64 macro.
Kenneth Graunke writes: > On 01/09/2014 09:31 PM, Eric Anholt wrote: >> Kenneth Graunke writes: >> >>> On 12/13/2013 09:28 AM, Daniel Vetter wrote: On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote: > Broadwell uses 48-bit addresses. The first DWord is the low 32 bits, > and the second DWord is the high 16 bits. > > Since individual buffers shouldn't be larger than 4GB in size, any > offsets into those buffers (buffer->offset + delta) should fit in the > low 32 bits. So I believe we can simply emit 0 for the high 16-bits, > and drm_intel_bo_emit_reloc() should patch it up. > > Signed-off-by: Kenneth Graunke > --- > src/mesa/drivers/dri/i965/intel_batchbuffer.h | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h > b/src/mesa/drivers/dri/i965/intel_batchbuffer.h > index 159f928..128eed9 100644 > --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h > +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h > @@ -178,6 +178,11 @@ void intel_batchbuffer_cached_advance(struct > brw_context *brw); > read_domains, write_domain, delta); \ > } while (0) > > +/* Handle 48-bit address relocations for Gen8+ */ > +#define OUT_RELOC64(buf, read_domains, write_domain, delta) \ > + OUT_RELOC(buf, read_domains, write_domain, delta); \ > + OUT_BATCH(0); Please not. The presumed_offset that libdrm uses is 64bits, and you need to emit the full presumed address (and correctly shifted). Atm the kernel never gives you a presumed reloc offset with the high bits set so it doesn't matter. But I'd prefer if we don't need to make this opt-in behaviour once we enable address spaces with more than 4G. i-g-t gets away with the cheap hack since we're allowed to break igt. Let me check ddx and libva whether I've lost this fight already ... -Daniel >>> >>> I'm more than happy to do the right thing, I just don't know what that >>> is. I don't see any uint64_t values in the interface we use at all: >>> >>> OUT_RELOC becomes >>>ret = drm_intel_bo_emit_reloc(brw->batch.bo, 4*brw->batch.used, >>> buffer, delta, >>> read_domains, write_domain); >> >> The libdrm ABI is a disaster. bo->offset is a long, so we're keeping 32 >> bits of the kernel's returned value on 32 bit userspace, and 64 bits on >> 64 bit userspace. This means that on 32-bit we'll write in an >> expected-incorrect offset in the presumed offset for a >4g-located BO, >> which the kernel will map and fix up at exec time. On 64-bit, your >> patch would write an expected-incorrect 32-bit value into the batch, but >> libdrm would tell the kernel the full expected 64 bit value in the >> presumed_offset field, and you'll get brokenness for >4g buffers. >> >> So, I think you do need a drm_intel_bo_emit_reloc64 that returns a >> uint64_t value that the kernel wrote into the presumed offset, which you >> then plug into your batchbuffer. >> >> (In other news, while thinking about this, there are some obscure races >> with buffer migration due to presumed_offset being read at a separate >> time from when we look up bo->offset to actually write the offset into >> the batch, in the presence of context sharing in GL). > > I'd really like to land this patch as-is, since I need it to land the > rest of my Broadwell code. I would update the commit message to note > that it's broken for >4G currently. I don't like landing known-broken code that will give you mysterious hangs under memory pressure. I could possibly ack this if there was a WARN_ON_ONCE or just having it be a stub or something, but "kind of works except when you start running a big app or run something for a long time" is not cool. pgpFRf2zYI20f.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/10] i965: Use Global GTT for Sandybridge post-sync non-zero workaround.
Kenneth Graunke writes: > On 01/09/2014 10:03 PM, Eric Anholt wrote: >> Eric Anholt writes: >> >>> Kenneth Graunke writes: >>> The kernel doesn't even set up the aliasing PPGTT on Sandybridge, so any writes marked as PPGTT will likely just get dropped on the floor. >>> >>> The hardware bug is that writes not marked as GTT are still looked up in >>> the GTT anyway. >>> >>> The kernel does set up the PPGTT, which is how we found we needed to put >>> in the kernel workaround based on DOMAIN_INSTRUCTION (of binding the >>> target buffer to the gtt as well as the ppgtt, since the writes landed >>> in the wrong place) >>> >>> I don't think this patch will change anything, but it seems reasonable >>> if the commit message is updated. >> >> Actually, thinking about it more, I'd rather not explicitly use global >> GTT, unless the function is also renamed to >> gen6_emit_post_sync_nonzero_workaround, since now this function on >> non-gen6 would reference GTT memory in its instruction, but the kernel >> wouldn't put anything in the GTT. >> >> (I'd rather just leave the workaround as is, myself). > > Okay, sounds like this is unnecessary. But...the next patch (helper > function for writes) causes this to use PIPE_CONTROL_GLOBAL_GTT_WRITE on > SNB only, and PPGTT on Gen7+. Oh, right. I'm fine with this as-is, then (r-b). pgpScCjmeJVuJ.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73571] [clover] OpenCL segfault in gegl 'clones' test
https://bugs.freedesktop.org/show_bug.cgi?id=73571 --- Comment #1 from Jan Vesely --- There are 4 more tests that were failing for different reason, but after applying http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131216/199497.html segfault in the same way: contrast-curve, pixelize, posterize, weighted blend. Note that all of these test use conversion kernels from (gegl)/opencl/colors.cl. patching gegl to not use opencl makes the tests pass. -- 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] Naming everything in src/gallium/drivers/radeonsi si_*
I don't have an fdo account or push rights. Can somebody else push it for me please? I've added the Reviewed-by: lines so the patches only need to be pushed now. On Monday 13 January 2014 11:22:07 Marek Olšák wrote: > For the series: > > Reviewed-by: Marek Olšák > > Feel free to push this. > > Marek > > On Sat, Jan 11, 2014 at 4:20 PM, Andreas Hartmetz wrote: > > Continuing here because the threads had diverged... > > > > I've updated the patch series under the same URL and applied all the > > suggested improvements. The variable renames are still in, but at the > > very end so they are trivial to omit. > > > > On Tuesday 07 January 2014 17:27:56 Andreas Hartmetz wrote: > >> We have talked on IRC meanwhile: > >> "Everywhere" was supposed to mean file names and data structures. > >> > >> I have made a patch series (git link because file renames produce huge > >> diffs) that renames *everything* away from r600 (and also radeonsi) > >> to si, where it is actually about SI. In the such modified code it is > >> then clear at first glance that only resources, textures and some > >> other low-level interface code from R600 / generic Radeon are actually > >> used in SI code. > >> > >> The patch series is ordered by increasing controversy potential due > >> to destruction of git blame history, so the last parts can be omitted > >> if they are deemed too destructive to history. In my opinion, it is > >> better to have code that is readable now than code that is less > >> readable but with the possibility to look up how it became like that. > >> > >> Michel said on IRC that he'd prefer to keep the name radeonsi_pipe.h/c, > >> I disagree: If the library name is to be kept, there must be a break > >> between radeonsi and si *somewhere*, and it is normal for library names > >> to not correspond to any file name in the library. The same scheme is > >> used in llvmpipe, llvmpipe lib / directory versus lp_* file names. > >> > >> Here's the repository (branch is master): > >> git git://anongit.kde.org/scratch/ahartmetz/mesa.git > >> web http://quickgit.kde.org/?p=scratch%2Fahartmetz%2Fmesa.git > >> > >> On Monday 06 January 2014 15:50:05 Marek Olšák wrote: > >> > It sounds good, but I'd like the prefix to be si_ everywhere. > >> > > >> > Marek > >> > > >> > On Mon, Jan 6, 2014 at 2:47 PM, Andreas Hartmetz > >> > >> wrote: > >> > > Hello, > >> > > > >> > > many of the files in radeonsi originally came from other places where > >> > > they had different names and were never renamed. > >> > > Most of them now have names that don't tell what the files are for > >> > > (r600 is not actually the first hardware supported by them, they > >> > > start > >> > > at radeonsi), and even those with radeonsi are split between > >> > > radeonsi_ and si_. > >> > > si_ is shorter than radeonsi_, but inconsistent with the directory > >> > > and > >> > > library name. I still think it's the best option, but no strong > >> > > opinion > >> > > from me. If and when the files are renamed, the next step would be > >> > > doing the same with the r600_ struct and function names. > >> > > Does that sound good? I'll send the patches shortly if so. > >> > > > >> > > Cheers, > >> > > Andreas > >> > > ___ > >> > > mesa-dev mailing list > >> > > mesa-dev@lists.freedesktop.org > >> > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73571] New: [clover] OpenCL segfault in gegl 'clones' test
https://bugs.freedesktop.org/show_bug.cgi?id=73571 Priority: medium Bug ID: 73571 Assignee: mesa-dev@lists.freedesktop.org Summary: [clover] OpenCL segfault in gegl 'clones' test Severity: normal Classification: Unclassified OS: Linux (All) Reporter: jano.ves...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa Created attachment 91998 --> https://bugs.freedesktop.org/attachment.cgi?id=91998&action=edit gegl don't askfor cl/gl extensions The tests/compositions/clones.xml from gegl test suite segfaults when using mesa OpenCL on Radeon HD 7570 (AMD Turks). I tired running it in gdb, here's the backtrace: [New Thread 0x7fffca312700 (LWP 8187)] Program received signal SIGSEGV, Segmentation fault. 0x7fffc8b0 in ?? () (gdb) bt #0 0x7fffc8b0 in ?? () #1 0x7fffc960 in ?? () #2 0x7fffe6238202 in (anonymous namespace)::InlineSpiller::insertSpill(unsigned int, bool, llvm::MachineBasicBlock::bundle_iterator >) () from /home/vesely/.local/lib/libLLVMCodeGen.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) llvm, clang, mesa, libclc, gegl, babl are all latest git as of today. Note that I had to patch gegl in order to use OpenCL on mesa at all (it requires some GL/CL extensions). The patch is attached. Note that the same test crashes when using intel-ocl too. -- 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 v3] opencl: improved auto-gen .icd
>From 91796da9c00c0756b90b9e09d404a5357ff32ec6 Mon Sep 17 00:00:00 2001 From: Igor Gnatenko Date: Sun, 12 Jan 2014 02:09:16 +0400 Subject: [PATCH] opencl: improved auto-gen .icd v2: Use @OPENCL_VERSION@:0 for library replace /etc with @sysconfdir@ macros v3: Drop libdir from icd, because libMesaOpenCL isn't private Reported-by: Fabian Deutsch Reference: https://bugs.freedesktop.org/show_bug.cgi?id=73512 Signed-off-by: Igor Gnatenko --- configure.ac | 3 +++ src/gallium/targets/opencl/Makefile.am | 4 ++-- src/gallium/targets/opencl/mesa.icd| 1 - src/gallium/targets/opencl/mesa.icd.in | 1 + 4 files changed, 6 insertions(+), 3 deletions(-) delete mode 100644 src/gallium/targets/opencl/mesa.icd create mode 100644 src/gallium/targets/opencl/mesa.icd.in diff --git a/configure.ac b/configure.ac index 4b55140..3452e15 100644 --- a/configure.ac +++ b/configure.ac @@ -25,6 +25,8 @@ m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) dnl Set internal versions OSMESA_VERSION=8 AC_SUBST([OSMESA_VERSION]) +OPENCL_VERSION=1 +AC_SUBST([OPENCL_VERSION]) dnl Versions for external dependencies LIBDRM_REQUIRED=2.4.24 @@ -2023,6 +2025,7 @@ AC_CONFIG_FILES([Makefile src/gallium/targets/egl-static/Makefile src/gallium/targets/gbm/Makefile src/gallium/targets/opencl/Makefile + src/gallium/targets/opencl/mesa.icd src/gallium/targets/osmesa/Makefile src/gallium/targets/osmesa/osmesa.pc src/gallium/targets/pipe-loader/Makefile diff --git a/src/gallium/targets/opencl/Makefile.am b/src/gallium/targets/opencl/Makefile.am index 653302c..923316c 100644 --- a/src/gallium/targets/opencl/Makefile.am +++ b/src/gallium/targets/opencl/Makefile.am @@ -4,7 +4,7 @@ lib_LTLIBRARIES = lib@OPENCL_LIBNAME@.la lib@OPENCL_LIBNAME@_la_LDFLAGS = \ $(LLVM_LDFLAGS) \ - -version-number 1:0 + -version-number @OPENCL_VERSION@:0 lib@OPENCL_LIBNAME@_la_LIBADD = \ $(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader.la \ @@ -34,7 +34,7 @@ lib@OPENCL_LIBNAME@_la_SOURCES = nodist_EXTRA_lib@OPENCL_LIBNAME@_la_SOURCES = dummy.cpp if HAVE_CLOVER_ICD -icddir = /etc/OpenCL/vendors/ +icddir = @sysconfdir@/OpenCL/vendors/ icd_DATA = mesa.icd endif diff --git a/src/gallium/targets/opencl/mesa.icd b/src/gallium/targets/opencl/mesa.icd deleted file mode 100644 index 6a6a870..000 --- a/src/gallium/targets/opencl/mesa.icd +++ /dev/null @@ -1 +0,0 @@ -libMesaOpenCL.so diff --git a/src/gallium/targets/opencl/mesa.icd.in b/src/gallium/targets/opencl/mesa.icd.in new file mode 100644 index 000..1b77b4e --- /dev/null +++ b/src/gallium/targets/opencl/mesa.icd.in @@ -0,0 +1 @@ +lib@OPENCL_LIBNAME@.so.@OPENCL_VERSION@ -- 1.8.4.2 -- -Igor Gnatenko ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/8] glsl: Use a new foreach_list2 macro for walking two lists at once.
On 01/13/2014 09:58 AM, Ian Romanick wrote:
> On 01/11/2014 02:37 AM, Kenneth Graunke wrote:
>> When handling function calls, we often want to walk through the list of
>> formal parameters and list of actual parameters at the same time.
>> (Both are guaranteed to be the same length.)
>>
>> Previously, we used a pattern of:
>>
>>exec_list_iterator 1st_iter = <1st list>.iterator();
>>foreach_iter(exec_list_iterator, 2nd_iter, <2nd list>) {
>> ...
>> 1st_iter.next();
>>}
>>
>> This was a bit awkward, since you had to manually iterate through one of
>> the two lists.
>
> "a bit" lol.
>
>> This patch introduces a foreach_list2 macro which safely walks through
>> two lists at the same time, so you can simply do:
>>
>>foreach_list2(1st_node, <1st list>, 2nd_node, <2nd list>) {
>> ...
>>}
>
> My only suggestion might be to change the name to foreach_two_lists. I
> think it's more obvious to someone reading the header file looking for
> utility macros.
Yeah, that is better. Renamed in v2. Thanks!
>> Signed-off-by: Kenneth Graunke
>> ---
>> src/glsl/ast_function.cpp | 16 --
>> src/glsl/ir.cpp| 12 +++---
>> src/glsl/linker.cpp| 9
>> src/glsl/list.h| 16 ++
>> src/glsl/opt_constant_folding.cpp | 9
>> src/glsl/opt_constant_propagation.cpp | 9
>> src/glsl/opt_constant_variable.cpp | 9
>> src/glsl/opt_copy_propagation.cpp | 9
>> src/glsl/opt_copy_propagation_elements.cpp | 9
>> src/glsl/opt_function_inlining.cpp | 35
>> --
>> src/glsl/opt_tree_grafting.cpp | 10 -
>> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 22 +++
>> 12 files changed, 73 insertions(+), 92 deletions(-)
>>
>> diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
>> index e4c0fd1..9a9bb74 100644
>> --- a/src/glsl/ast_function.cpp
>> +++ b/src/glsl/ast_function.cpp
>> @@ -293,15 +293,10 @@ generate_call(exec_list *instructions,
>> ir_function_signature *sig,
>> * call takes place. Since we haven't emitted the call yet, we'll place
>> * the post-call conversions in a temporary exec_list, and emit them
>> later.
>> */
>> - exec_list_iterator actual_iter = actual_parameters->iterator();
>> - exec_list_iterator formal_iter = sig->parameters.iterator();
>> -
>> - while (actual_iter.has_next()) {
>> - ir_rvalue *actual = (ir_rvalue *) actual_iter.get();
>> - ir_variable *formal = (ir_variable *) formal_iter.get();
>> -
>> - assert(actual != NULL);
>> - assert(formal != NULL);
>> + foreach_list2(formal_node, &sig->parameters,
>> + actual_node, actual_parameters) {
>> + ir_rvalue *actual = (ir_rvalue *) actual_node;
>> + ir_variable *formal = (ir_variable *) formal_node;
>
> The old code asserts when the lists aren't the same length... or at
> least when sig->parameters is shorter than actual_parameters. As do the
> loops in st_glsl_to_tgsi.cpp. I think a debug-build version of
> foreach_list2 could do the same... I'm just waffling whether there's
> sufficient value to make it worth doing. Opinions?
I'd rather not. These lists are always the same length. It might be
worth checking that when creating them, but making every code site that
walks them assert seems like overkill.
Plus, it seems tricky to shoehorn assertions into a macro that only
defines a for loop (without the body). And right now, it has the
defined behavior that it stops at the shorter of the two lists, which
could be useful someday.
--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/8] glsl: Replace iterators in ir_reader.cpp with ad-hoc list walking.
On 01/13/2014 09:49 AM, Ian Romanick wrote:
> On 01/11/2014 02:37 AM, Kenneth Graunke wrote:
>> These can't use foreach_list since they want to skip over the first few
>> list elements. Just doing the ad-hoc list walking isn't too bad.
>>
>> Signed-off-by: Kenneth Graunke
>> ---
>> src/glsl/ir_reader.cpp | 18 ++
>> 1 file changed, 10 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/glsl/ir_reader.cpp b/src/glsl/ir_reader.cpp
>> index f5185d2..28923f3 100644
>> --- a/src/glsl/ir_reader.cpp
>> +++ b/src/glsl/ir_reader.cpp
>> @@ -205,11 +205,12 @@ ir_reader::read_function(s_expression *expr, bool
>> skip_body)
>>assert(added);
>> }
>>
>> - exec_list_iterator it = ((s_list *) expr)->subexpressions.iterator();
>> - it.next(); // skip "function" tag
>> - it.next(); // skip function name
>> - for (/* nothing */; it.has_next(); it.next()) {
>> - s_expression *s_sig = (s_expression *) it.get();
>> + /* Skip over "function" tag and function name (which are guaranteed to be
>> +* present by the above PARTIAL_MATCH call).
>> +*/
>> + exec_node *node = ((s_list *) expr)->subexpressions.head->next->next;
>> + for (/* nothing */; !node->is_tail_sentinel(); node = node->next) {
>> + s_expression *s_sig = (s_expression *) node;
>
> This won't behave the same in the (bug) case that the list has too few
> elements. If the list is empty or as only one element, there will be a
> NULL deref here somewhere. I believe the iterator version was safe
> against this.
>
> Do we have some pre-existing guarantee that the list has enough elements?
Yes. Above:
s_pattern pat[] = { "function", name };
if (!PARTIAL_MATCH(expr, pat)) {
ir_read_error(expr, "Expected (function (signature ...) ...)");
return NULL;
}
If the list doesn't match the (partial) S-Expression
(function ...)
we would have bailed by now. So the list is guaranteed to have at least
two elements.
>>read_function_sig(f, s_sig, skip_body);
>> }
>> return added ? f : NULL;
>> @@ -249,9 +250,10 @@ ir_reader::read_function_sig(ir_function *f,
>> s_expression *expr, bool skip_body)
>> exec_list hir_parameters;
>> state->symbols->push_scope();
>>
>> - exec_list_iterator it = paramlist->subexpressions.iterator();
>> - for (it.next() /* skip "parameters" */; it.has_next(); it.next()) {
>> - ir_variable *var = read_declaration((s_expression *) it.get());
>> + /* Skip over the "parameters" tag. */
>> + exec_node *node = paramlist->subexpressions.head->next;
>> + for (/* nothing */; !node->is_tail_sentinel(); node = node->next) {
>> + ir_variable *var = read_declaration((s_expression *) node);
>>if (var == NULL)
>> return;
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/19] nv50/ir: disallow predicates on emit/restart ops
---
src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
index ade9be0..52257a8 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
@@ -130,7 +130,8 @@ void TargetNV50::initOpInfo()
};
static const operation noPredList[] =
{
- OP_CALL, OP_PREBREAK, OP_PRERET, OP_QUADON, OP_QUADPOP, OP_JOINAT
+ OP_CALL, OP_PREBREAK, OP_PRERET, OP_QUADON, OP_QUADPOP, OP_JOINAT,
+ OP_EMIT, OP_RESTART
};
for (i = 0; i < DATA_FILE_COUNT; ++i)
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/19] nv50: GP_REG_ALLOC_RESULT must be positive
Set max_out to 1 when there are no outputs. Signed-off-by: Ilia Mirkin --- src/gallium/drivers/nouveau/nv50/nv50_program.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.c b/src/gallium/drivers/nouveau/nv50/nv50_program.c index f46f240..813795f 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_program.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_program.c @@ -118,6 +118,8 @@ nv50_vertprog_assign_slots(struct nv50_ir_prog_info *info) } prog->out_nr = info->numOutputs; prog->max_out = n; + if (!prog->max_out) + prog->max_out = 1; if (prog->vp.psiz < info->numOutputs) prog->vp.psiz = prog->out[prog->vp.psiz].hw; -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/19] nv50: allocate an extra code bo to avoid dmesg spam
Each code BO is a heap that allocates at the end first, and so GPs are
allocated at the very end of the allocated space. When executing, we see
PAGE_NOT_PRESENT errors for the next page. Just over-allocate to make
sure that there's something there.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 43e0f50..82b0207 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -739,8 +739,12 @@ nv50_screen_create(struct nouveau_device *dev)
goto fail;
}
+ /* This over-allocates by a whole code BO. The GP, which would execute at
+* the end of the last page, would trigger faults. The going theory is that
+* it prefetches up to a certain amount. This avoids dmesg spam.
+*/
ret = nouveau_bo_new(dev, NOUVEAU_BO_VRAM, 1 << 16,
-3 << NV50_CODE_BO_SIZE_LOG2, NULL, &screen->code);
+4 << NV50_CODE_BO_SIZE_LOG2, NULL, &screen->code);
if (ret) {
NOUVEAU_ERR("Failed to allocate code bo: %d\n", ret);
goto fail;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/19] nv50: add comments about CB_AUX contents
Updates a few inconsistencies as well, like the size of the buffer,
location of the runout, etc.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_context.h| 10 ++
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 8
src/gallium/drivers/nouveau/nv50/nv50_state_validate.c | 2 +-
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_context.h
b/src/gallium/drivers/nouveau/nv50/nv50_context.h
index ee6eb0e..7bf4ce3 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_context.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_context.h
@@ -70,7 +70,17 @@
#define NV50_CB_PVP 124
#define NV50_CB_PGP 126
#define NV50_CB_PFP 125
+/* constant buffer permanently mapped in as c15[] */
#define NV50_CB_AUX 127
+/* size of the buffer: 64k. not all taken up, can be reduced if needed. */
+#define NV50_CB_AUX_SIZE (1 << 16)
+/* 8 user clip planes, at 4 32-bit floats each */
+#define NV50_CB_AUX_UCP_OFFSET0x0
+/* 256 textures, each with 2 16-bit integers specifying the x/y MS shift */
+#define NV50_CB_AUX_MS_OFFSET 0x80
+/* 4 32-bit floats for the vertex runout, put at the end */
+#define NV50_CB_AUX_RUNOUT_OFFSET (NV50_CB_AUX_SIZE - 0x10)
+
struct nv50_blitctx;
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 82b0207..9ed2d01 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -472,7 +472,7 @@ nv50_screen_init_hwctx(struct nv50_screen *screen)
BEGIN_NV04(push, NV50_3D(CB_DEF_ADDRESS_HIGH), 3);
PUSH_DATAh(push, screen->uniforms->offset + (3 << 16));
PUSH_DATA (push, screen->uniforms->offset + (3 << 16));
- PUSH_DATA (push, (NV50_CB_AUX << 16) | 0x0200);
+ PUSH_DATA (push, (NV50_CB_AUX << 16) | (NV50_CB_AUX_SIZE & 0x));
BEGIN_NI04(push, NV50_3D(SET_PROGRAM_CB), 3);
PUSH_DATA (push, (NV50_CB_AUX << 12) | 0xf01);
@@ -481,15 +481,15 @@ nv50_screen_init_hwctx(struct nv50_screen *screen)
/* return { 0.0, 0.0, 0.0, 0.0 } on out-of-bounds vtxbuf access */
BEGIN_NV04(push, NV50_3D(CB_ADDR), 1);
- PUSH_DATA (push, ((1 << 9) << 6) | NV50_CB_AUX);
+ PUSH_DATA (push, (NV50_CB_AUX_RUNOUT_OFFSET << 6) | NV50_CB_AUX);
BEGIN_NI04(push, NV50_3D(CB_DATA(0)), 4);
PUSH_DATAf(push, 0.0f);
PUSH_DATAf(push, 0.0f);
PUSH_DATAf(push, 0.0f);
PUSH_DATAf(push, 0.0f);
BEGIN_NV04(push, NV50_3D(VERTEX_RUNOUT_ADDRESS_HIGH), 2);
- PUSH_DATAh(push, screen->uniforms->offset + (3 << 16) + (1 << 9));
- PUSH_DATA (push, screen->uniforms->offset + (3 << 16) + (1 << 9));
+ PUSH_DATAh(push, screen->uniforms->offset + (3 << 16) +
NV50_CB_AUX_RUNOUT_OFFSET);
+ PUSH_DATA (push, screen->uniforms->offset + (3 << 16) +
NV50_CB_AUX_RUNOUT_OFFSET);
/* max TIC (bits 4:8) & TSC bindings, per program type */
for (i = 0; i < 3; ++i) {
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
b/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
index 86b9a23..3d99b73 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
@@ -238,7 +238,7 @@ nv50_validate_clip(struct nv50_context *nv50)
if (nv50->dirty & NV50_NEW_CLIP) {
BEGIN_NV04(push, NV50_3D(CB_ADDR), 1);
- PUSH_DATA (push, (0 << 8) | NV50_CB_AUX);
+ PUSH_DATA (push, (NV50_CB_AUX_UCP_OFFSET << 8) | NV50_CB_AUX);
BEGIN_NI04(push, NV50_3D(CB_DATA(0)), PIPE_MAX_CLIP_PLANES * 4);
PUSH_DATAp(push, &nv50->clip.ucp[0][0], PIPE_MAX_CLIP_PLANES * 4);
}
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/19] nv50: don't forget to also clear additional layers
Fixes most of the tests/spec/gl-3.2/layered-rendering/* piglits.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_surface.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
index 358f57a..16a4369 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
@@ -395,7 +395,7 @@ nv50_clear(struct pipe_context *pipe, unsigned buffers,
struct nv50_context *nv50 = nv50_context(pipe);
struct nouveau_pushbuf *push = nv50->base.pushbuf;
struct pipe_framebuffer_state *fb = &nv50->framebuffer;
- unsigned i;
+ unsigned i, j;
uint32_t mode = 0;
/* don't need NEW_BLEND, COLOR_MASK doesn't affect CLEAR_BUFFERS */
@@ -408,9 +408,6 @@ nv50_clear(struct pipe_context *pipe, unsigned buffers,
PUSH_DATAf(push, color->f[1]);
PUSH_DATAf(push, color->f[2]);
PUSH_DATAf(push, color->f[3]);
- mode =
- NV50_3D_CLEAR_BUFFERS_R | NV50_3D_CLEAR_BUFFERS_G |
- NV50_3D_CLEAR_BUFFERS_B | NV50_3D_CLEAR_BUFFERS_A;
}
if (buffers & PIPE_CLEAR_DEPTH) {
@@ -425,12 +422,22 @@ nv50_clear(struct pipe_context *pipe, unsigned buffers,
mode |= NV50_3D_CLEAR_BUFFERS_S;
}
- BEGIN_NV04(push, NV50_3D(CLEAR_BUFFERS), 1);
- PUSH_DATA (push, mode);
+ if ((buffers & PIPE_CLEAR_DEPTH) || (buffers & PIPE_CLEAR_STENCIL)) {
+ for (j = fb->zsbuf->u.tex.first_layer; j <= fb->zsbuf->u.tex.last_layer;
j++) {
+ BEGIN_NV04(push, NV50_3D(CLEAR_BUFFERS), 1);
+ PUSH_DATA(push, mode | (j << NV50_3D_CLEAR_BUFFERS_LAYER__SHIFT));
+ }
+ }
- for (i = 1; i < fb->nr_cbufs; i++) {
- BEGIN_NV04(push, NV50_3D(CLEAR_BUFFERS), 1);
- PUSH_DATA (push, (i << 6) | 0x3c);
+ if (buffers & PIPE_CLEAR_COLOR) {
+ for (i = 0; i < fb->nr_cbufs; i++) {
+ struct pipe_surface *sf = fb->cbufs[i];
+ for (j = sf->u.tex.first_layer; j <= sf->u.tex.last_layer; j++) {
+BEGIN_NV04(push, NV50_3D(CLEAR_BUFFERS), 1);
+PUSH_DATA (push, (i << 6) | 0x3c |
+ (j << NV50_3D_CLEAR_BUFFERS_LAYER__SHIFT));
+ }
+ }
}
}
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/19] nv50: allow vert_count to be >255
---
src/gallium/drivers/nouveau/nv50/nv50_program.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.h
b/src/gallium/drivers/nouveau/nv50/nv50_program.h
index 13b9516..f63352f 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_program.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_program.h
@@ -88,7 +88,7 @@ struct nv50_program {
struct {
ubyte primid; /* primitive id output register */
- uint8_t vert_count;
+ uint32_t vert_count;
uint8_t prim_type; /* point, line strip or tri strip */
} gp;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/19] nv50/ir: disallow shader input propagation for gp
For some reason, shader input accesses don't work correctly in non-ld
instructions. Disallow those loads from being propagated.
Signed-off-by: Ilia Mirkin
---
I'm not particularly happy with this patch. Some investigation needs to happen
as to what's going on here. NVIDIA's shaders include p[] accesses in various
instructions just fine. Perhaps this is just masking some other bug. However
this works for now for all the piglit tests in the repo.
src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
index 52257a8..18fa069 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
@@ -297,14 +297,19 @@ TargetNV50::insnCanLoad(const Instruction *i, int s,
switch (mode) {
case 0x00:
- case 0x01:
case 0x03:
case 0x08:
- case 0x09:
case 0x0c:
case 0x20:
case 0x21:
break;
+ case 0x01:
+ case 0x09:
+ // TODO: Figure out why a[] accesses can't be propagated into non-ld
+ // instructions. Something to do with vstride maybe?
+ if (ld->bb->getProgram()->getType() == Program::TYPE_GEOMETRY)
+ return false;
+ break;
case 0x0d:
if (ld->bb->getProgram()->getType() != Program::TYPE_GEOMETRY)
return false;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/19] nv50: VP_RESULT_MAP_SIZE has to be positive
Make sure that we never try to use a 0-sized map. This can happen when using a gp, so add a dummy mapping when computing vp_gp_mapping in that case. Signed-off-by: Ilia Mirkin --- src/gallium/drivers/nouveau/nv50/nv50_shader_state.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_shader_state.c b/src/gallium/drivers/nouveau/nv50/nv50_shader_state.c index ba4f592..265ef20 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_shader_state.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_shader_state.c @@ -457,6 +457,7 @@ nv50_fp_linkage_validate(struct nv50_context *nv50) BEGIN_NV04(push, NV50_3D(SEMANTIC_PRIM_ID), 1); PUSH_DATA (push, primid); + assert(m > 0); BEGIN_NV04(push, NV50_3D(VP_RESULT_MAP_SIZE), 1); PUSH_DATA (push, m); BEGIN_NV04(push, NV50_3D(VP_RESULT_MAP(0)), n); @@ -516,6 +517,8 @@ nv50_vp_gp_mapping(uint8_t *map, int m, oid += mv & 1; } } + if (!m) + map[m++] = 0; return m; } @@ -540,6 +543,7 @@ nv50_gp_linkage_validate(struct nv50_context *nv50) BEGIN_NV04(push, NV50_3D(VP_GP_BUILTIN_ATTR_EN), 1); PUSH_DATA (push, vp->vp.attrs[2] | gp->vp.attrs[2]); + assert(m > 0); BEGIN_NV04(push, NV50_3D(VP_RESULT_MAP_SIZE), 1); PUSH_DATA (push, m); BEGIN_NV04(push, NV50_3D(VP_RESULT_MAP(0)), n); -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 16/19] nv50: copy nvc0's get_sample_position implementation
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_context.c | 46 +
1 file changed, 46 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_context.c
b/src/gallium/drivers/nouveau/nv50/nv50_context.c
index 11afc48..db3bd3a 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_context.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_context.c
@@ -196,6 +196,10 @@ nv50_invalidate_resource_storage(struct nouveau_context
*ctx,
return ref;
}
+static void
+nv50_context_get_sample_position(struct pipe_context *, unsigned, unsigned,
+ float *);
+
struct pipe_context *
nv50_create(struct pipe_screen *pscreen, void *priv)
{
@@ -239,6 +243,7 @@ nv50_create(struct pipe_screen *pscreen, void *priv)
pipe->flush = nv50_flush;
pipe->texture_barrier = nv50_texture_barrier;
+ pipe->get_sample_position = nv50_context_get_sample_position;
if (!screen->cur_ctx) {
screen->cur_ctx = nv50;
@@ -317,3 +322,44 @@ nv50_bufctx_fence(struct nouveau_bufctx *bufctx, boolean
on_flush)
nv50_resource_validate(res, (unsigned)ref->priv_data);
}
}
+
+static void
+nv50_context_get_sample_position(struct pipe_context *pipe,
+ unsigned sample_count, unsigned sample_index,
+ float *xy)
+{
+ static const uint8_t ms1[1][2] = { { 0x8, 0x8 } };
+ static const uint8_t ms2[2][2] = {
+ { 0x4, 0x4 }, { 0xc, 0xc } }; /* surface coords (0,0), (1,0) */
+ static const uint8_t ms4[4][2] = {
+ { 0x6, 0x2 }, { 0xe, 0x6 }, /* (0,0), (1,0) */
+ { 0x2, 0xa }, { 0xa, 0xe } }; /* (0,1), (1,1) */
+ static const uint8_t ms8[8][2] = {
+ { 0x1, 0x7 }, { 0x5, 0x3 }, /* (0,0), (1,0) */
+ { 0x3, 0xd }, { 0x7, 0xb }, /* (0,1), (1,1) */
+ { 0x9, 0x5 }, { 0xf, 0x1 }, /* (2,0), (3,0) */
+ { 0xb, 0xf }, { 0xd, 0x9 } }; /* (2,1), (3,1) */
+#if 0
+ /* NOTE: there are alternative modes for MS2 and MS8, currently not used */
+ static const uint8_t ms8_alt[8][2] = {
+ { 0x9, 0x5 }, { 0x7, 0xb }, /* (2,0), (1,1) */
+ { 0xd, 0x9 }, { 0x5, 0x3 }, /* (3,1), (1,0) */
+ { 0x3, 0xd }, { 0x1, 0x7 }, /* (0,1), (0,0) */
+ { 0xb, 0xf }, { 0xf, 0x1 } }; /* (2,1), (3,0) */
+#endif
+
+ const uint8_t (*ptr)[2];
+
+ switch (sample_count) {
+ case 0:
+ case 1: ptr = ms1; break;
+ case 2: ptr = ms2; break;
+ case 4: ptr = ms4; break;
+ case 8: ptr = ms8; break;
+ default:
+ assert(0);
+ return; /* bad sample count -> undefined locations */
+ }
+ xy[0] = ptr[sample_index][0] * 0.0625f;
+ xy[1] = ptr[sample_index][1] * 0.0625f;
+}
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/19] nv50/ir: comment out code to allow input/immed loads
This code was missing a break which made it ineffective. But since shader input loads have been disallowed, define the code out. Signed-off-by: Ilia Mirkin --- src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp index 18fa069..a84a54a 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp @@ -310,9 +310,12 @@ TargetNV50::insnCanLoad(const Instruction *i, int s, if (ld->bb->getProgram()->getType() == Program::TYPE_GEOMETRY) return false; break; +#if 0 case 0x0d: if (ld->bb->getProgram()->getType() != Program::TYPE_GEOMETRY) return false; + break; +#endif default: return false; } -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 17/19] nv50: add support for textureFetch'ing MS textures, ARB_texture_multisample
Creates two areas in the AUX constbuf:
- Sample offsets for MS textures
- Per-texture MS settings
When executing a textureFetch with a MS sampler, looks up that texture's
settings and adjusts the parameters given to the texfetch instruction.
With this change, all the ARB_texture_multisample piglits pass, so turn
on PIPE_CAP_TEXTURE_MULTISAMPLE.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 8 +++
.../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 1 +
.../nouveau/codegen/nv50_ir_lowering_nv50.cpp | 60 +
src/gallium/drivers/nouveau/nv50/nv50_context.h| 13 +++-
src/gallium/drivers/nouveau/nv50/nv50_program.c| 7 +-
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 7 +-
src/gallium/drivers/nouveau/nv50/nv50_tex.c| 75 +-
7 files changed, 164 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index 6a001d3..857980d 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -827,6 +827,14 @@ public:
int isShadow() const { return descTable[target].shadow ? 1 : 0; }
int isMS() const {
return target == TEX_TARGET_2D_MS || target == TEX_TARGET_2D_MS_ARRAY;
}
+ void clearMS() {
+ if (isMS()) {
+if (isArray())
+ target = TEX_TARGET_2D_ARRAY;
+else
+ target = TEX_TARGET_2D;
+ }
+ }
Target& operator=(TexTarget targ)
{
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
index a6ed4b0..8f9b7de 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
@@ -1221,6 +1221,7 @@ CodeEmitterNV50::emitCVT(const Instruction *i)
case TYPE_S32: code[1] = 0x44014000; break;
case TYPE_U32: code[1] = 0x44004000; break;
case TYPE_F16: code[1] = 0xc400; break;
+ case TYPE_U16: code[1] = 0x4400; break;
default:
assert(0);
break;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
index 1d13aea..984a8ca 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
@@ -549,6 +549,8 @@ private:
bool handleCONT(Instruction *);
void checkPredicate(Instruction *);
+ void loadTexMsInfo(uint32_t off, Value **ms, Value **ms_x, Value **ms_y);
+ void loadMsInfo(Value *ms, Value *s, Value **dx, Value **dy);
private:
const Target *const targ;
@@ -582,6 +584,41 @@ NV50LoweringPreSSA::visit(Function *f)
return true;
}
+void NV50LoweringPreSSA::loadTexMsInfo(uint32_t off, Value **ms,
+ Value **ms_x, Value **ms_y) {
+ // This loads the texture-indexed ms setting from the constant buffer
+ Value *tmp = new_LValue(func, FILE_GPR);
+ uint8_t b = prog->driver->io.resInfoCBSlot;
+ off += prog->driver->io.suInfoBase;
+ *ms_x = bld.mkLoadv(TYPE_U32, bld.mkSymbol(
+ FILE_MEMORY_CONST, b, TYPE_U32, off + 0), NULL);
+ *ms_y = bld.mkLoadv(TYPE_U32, bld.mkSymbol(
+ FILE_MEMORY_CONST, b, TYPE_U32, off + 4), NULL);
+ *ms = bld.mkOp2v(OP_ADD, TYPE_U32, tmp, *ms_x, *ms_y);
+}
+
+void NV50LoweringPreSSA::loadMsInfo(Value *ms, Value *s, Value **dx, Value
**dy) {
+ // Given a MS level, and a sample id, compute the delta x/y
+ uint8_t b = prog->driver->io.msInfoCBSlot;
+ Value *off = new_LValue(func, FILE_ADDRESS), *t = new_LValue(func,
FILE_GPR);
+
+ // The required information is at mslevel * 16 * 4 + sample * 8
+ // = (mslevel * 8 + sample) * 8
+ bld.mkOp2(OP_SHL,
+ TYPE_U32,
+ off,
+ bld.mkOp2v(OP_ADD, TYPE_U32, t,
+bld.mkOp2v(OP_SHL, TYPE_U32, t, ms, bld.mkImm(3)),
+s),
+ bld.mkImm(3));
+ *dx = bld.mkLoadv(TYPE_U32, bld.mkSymbol(
+ FILE_MEMORY_CONST, b, TYPE_U32,
+ prog->driver->io.msInfoBase), off);
+ *dy = bld.mkLoadv(TYPE_U32, bld.mkSymbol(
+ FILE_MEMORY_CONST, b, TYPE_U32,
+ prog->driver->io.msInfoBase + 4), off);
+}
+
bool
NV50LoweringPreSSA::handleTEX(TexInstruction *i)
{
@@ -589,6 +626,29 @@ NV50LoweringPreSSA::handleTEX(TexInstruction *i)
const int dref = arg;
const int lod = i->tex.target.isShadow() ? (arg + 1) : arg;
+ // handle MS, which means looking up the MS params for this texture, and
+ // adjusting the input coordinates to point at the right sample.
+ if (i->tex.target.isMS()) {
+ Value *x = i->getSrc(0);
+ Value *y = i->getSrc(1)
[Mesa-dev] [RFC PATCH 19/19] nv50: enable seamless cube maps on all hw for OpenGL 3.2
Some of the hardware support is missing. The NVIDIA-provided driver, which claims 3.3 support fails a slew of the relevant tests as well. This allows us to expose geometry shaders without doing the additional work involved in supporting ARB_geometry_shader4. Signed-off-by: Ilia Mirkin --- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c b/src/gallium/drivers/nouveau/nv50/nv50_screen.c index 123bdab..a108ece 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c @@ -111,7 +111,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE: return 65536; case PIPE_CAP_SEAMLESS_CUBE_MAP: - return nv50_screen(pscreen)->tesla->oclass >= NVA0_3D_CLASS; + return 1; //nv50_screen(pscreen)->tesla->oclass >= NVA0_3D_CLASS; case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE: return 0; case PIPE_CAP_CUBE_MAP_ARRAY: -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/19] nv50: add sampler2DMS/GP support to get OpenGL 3.2
OK, so there's a bunch of stuff in here. The geometry stuff is based on the work started by Bryan Cain and Christoph Bumiller. Patches 01-12: Add support for geometry shaders and fix related issues Patches 13-14: Make it possible for fb clears to operate on texture attachments with an explicit layer set (as is allowed in gl 3.2). Patches 15-17: Make ARB_texture_multisample work Patch 18: Enable GLSL 1.50 Patch 19: Turn on ARB_seamless_cube_map irrespective of HW support so that all nv50 cards can get OpenGL 3.2 and geometry shaders (which are otherwise unsupported) There are still a few geometry-related piglits that fail -- specifically: primitive-id-no-gs gl-3.2-layered-rendering-gl-layer* I need to trace the blob to figure out exactly how to configure the HW for those situations, but I suspect that the fixes will be fairly small and self-contained. Note that there are also a bunch of EXT_framebuffer_multisample tests that are failing, but that has nothing to do with these changes. There's something wrong with the blit_3d function, at the very least to do with depth/stencil, but also some color tests fail as well. These patches are available at https://github.com/imirkin/mesa.git nv50-gs or https://github.com/imirkin/mesa/commits/nv50-gs for those who prefer a web ui. Bryan Cain (2): nv50/ir: delay calculation of indirect addresses nv50: add support for geometry shaders Christoph Bumiller (1): nv50/ir: fix PFETCH and add RDSV to get VSTRIDE for GPs Ilia Mirkin (16): nv50: allow vert_count to be >255 nv50/ir: disallow predicates on emit/restart ops nv50/ir: disallow shader input propagation for gp nv50/ir: comment out code to allow input/immed loads nv50/ir: add support for gl_PrimitiveIDIn nv50: properly set the PRIMITIVE_ID enable flag when it is a gp input. nv50: VP_RESULT_MAP_SIZE has to be positive nv50: GP_REG_ALLOC_RESULT must be positive nv50: allocate an extra code bo to avoid dmesg spam nv50: don't forget to also clear additional layers nvc0: don't forget to also clear additional layers nv50: add comments about CB_AUX contents nv50: copy nvc0's get_sample_position implementation nv50: add support for textureFetch'ing MS textures, ARB_texture_multisample nv50: report glsl 1.50 now that gp tests pass nv50: enable seamless cube maps on all hw for OpenGL 3.2 src/gallium/drivers/nouveau/codegen/nv50_ir.h | 9 ++ .../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 92 ++-- .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 41 -- .../nouveau/codegen/nv50_ir_lowering_nv50.cpp | 164 - .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 7 + .../drivers/nouveau/codegen/nv50_ir_print.cpp | 1 + .../nouveau/codegen/nv50_ir_target_nv50.cpp| 18 ++- src/gallium/drivers/nouveau/nv50/nv50_context.c| 46 ++ src/gallium/drivers/nouveau/nv50/nv50_context.h| 17 +++ src/gallium/drivers/nouveau/nv50/nv50_program.c| 30 +++- src/gallium/drivers/nouveau/nv50/nv50_program.h| 2 +- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 23 ++- .../drivers/nouveau/nv50/nv50_shader_state.c | 6 + .../drivers/nouveau/nv50/nv50_state_validate.c | 2 +- src/gallium/drivers/nouveau/nv50/nv50_surface.c| 25 ++-- src/gallium/drivers/nouveau/nv50/nv50_tex.c| 77 +- src/gallium/drivers/nouveau/nvc0/nvc0_surface.c| 22 ++- 17 files changed, 526 insertions(+), 56 deletions(-) -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/19] nv50/ir: delay calculation of indirect addresses
From: Bryan Cain
Instead of emitting an SHL 4 io an address register on the TGSI ARL and UARL
instructions, emit the shift when the loaded address is actually used. This
is necessary because input vertex and attribute indices in geometry shaders on
nv50 need to be shifted left by 2 instead of 4.
Signed-off-by: Bryan Cain
[calim: various updates to the indirect address logic]
Signed-off-by: Christoph Bumiller
[imirkin: remove OP_MAD change that calim made, add OP_RESTART handling
same as OP_EMIT for code flow analysis]
Signed-off-by: Ilia Mirkin
---
.../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 38 ++--
.../nouveau/codegen/nv50_ir_lowering_nv50.cpp | 104 -
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 7 ++
3 files changed, 136 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index 49a45f8..3c790cf 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -1126,6 +1126,7 @@ private:
ValueMap values;
};
+ Value *shiftAddress(Value *);
Value *getVertexBase(int s);
DataArray *getArrayForFile(unsigned file, int idx);
Value *fetchSrc(int s, int c);
@@ -1344,7 +1345,8 @@ Converter::getVertexBase(int s)
if (tgsi.getSrc(s).isIndirect(1))
rel = fetchSrc(tgsi.getSrc(s).getIndirect(1), 0, NULL);
vtxBaseValid |= 1 << s;
- vtxBase[s] = mkOp2v(OP_PFETCH, TYPE_U32, getSSA(), mkImm(index), rel);
+ vtxBase[s] = mkOp2v(OP_PFETCH, TYPE_U32, getSSA(4, FILE_ADDRESS),
+ mkImm(index), rel);
}
return vtxBase[s];
}
@@ -1403,6 +1405,14 @@ Converter::getArrayForFile(unsigned file, int idx)
}
Value *
+Converter::shiftAddress(Value *index)
+{
+ if (!index)
+ return NULL;
+ return mkOp2v(OP_SHL, TYPE_U32, getSSA(4, FILE_ADDRESS), index, mkImm(4));
+}
+
+Value *
Converter::fetchSrc(tgsi::Instruction::SrcRegister src, int c, Value *ptr)
{
const int idx2d = src.is2D() ? src.getIndex(1) : 0;
@@ -1414,7 +1424,7 @@ Converter::fetchSrc(tgsi::Instruction::SrcRegister src,
int c, Value *ptr)
assert(!ptr);
return loadImm(NULL, info->immd.data[idx * 4 + swz]);
case TGSI_FILE_CONSTANT:
- return mkLoadv(TYPE_U32, srcToSym(src, c), ptr);
+ return mkLoadv(TYPE_U32, srcToSym(src, c), shiftAddress(ptr));
case TGSI_FILE_INPUT:
if (prog->getType() == Program::TYPE_FRAGMENT) {
// don't load masked inputs, won't be assigned a slot
@@ -1422,9 +1432,17 @@ Converter::fetchSrc(tgsi::Instruction::SrcRegister src,
int c, Value *ptr)
return loadImm(NULL, swz == TGSI_SWIZZLE_W ? 1.0f : 0.0f);
if (!ptr && info->in[idx].sn == TGSI_SEMANTIC_FACE)
return mkOp1v(OP_RDSV, TYPE_F32, getSSA(), mkSysVal(SV_FACE, 0));
- return interpolate(src, c, ptr);
+ return interpolate(src, c, shiftAddress(ptr));
+ } else
+ if (ptr && prog->getType() == Program::TYPE_GEOMETRY) {
+ // XXX: This is going to be a problem with scalar arrays, i.e. when
+ // we cannot assume that the address is given in units of vec4.
+ //
+ // nv50 and nvc0 need different things here, so let the lowering
+ // passes decide what to do with the address
+ return mkLoadv(TYPE_U32, srcToSym(src, c), ptr);
}
- return mkLoadv(TYPE_U32, srcToSym(src, c), ptr);
+ return mkLoadv(TYPE_U32, srcToSym(src, c), shiftAddress(ptr));
case TGSI_FILE_OUTPUT:
assert(!"load from output file");
return NULL;
@@ -1433,7 +1451,7 @@ Converter::fetchSrc(tgsi::Instruction::SrcRegister src,
int c, Value *ptr)
return mkOp1v(OP_RDSV, TYPE_U32, getSSA(), srcToSym(src, c));
default:
return getArrayForFile(src.getFile(), idx2d)->load(
- sub.cur->values, idx, swz, ptr);
+ sub.cur->values, idx, swz, shiftAddress(ptr));
}
}
@@ -1476,8 +1494,9 @@ Converter::storeDst(int d, int c, Value *val)
break;
}
- Value *ptr = dst.isIndirect(0) ?
- fetchSrc(dst.getIndirect(0), 0, NULL) : NULL;
+ Value *ptr = NULL;
+ if (dst.isIndirect(0))
+ ptr = shiftAddress(fetchSrc(dst.getIndirect(0), 0, NULL));
if (info->io.genUserClip > 0 &&
dst.getFile() == TGSI_FILE_OUTPUT &&
@@ -2179,12 +2198,11 @@ Converter::handleInstruction(const struct
tgsi_full_instruction *insn)
FOR_EACH_DST_ENABLED_CHANNEL(0, c, tgsi) {
src0 = fetchSrc(0, c);
mkCvt(OP_CVT, TYPE_S32, dst0[c], TYPE_F32, src0)->rnd = ROUND_M;
- mkOp2(OP_SHL, TYPE_U32, dst0[c], dst0[c], mkImm(4));
}
break;
case TGSI_OPCODE_UARL:
FOR_EACH_DST_ENABLED_CHANNEL(0, c, tgsi)
- mkOp2(OP_SHL, TYPE_U32, dst0[c], fetchSrc(0, c), mkImm(4));
+ mkOp1(OP_MOV, TYPE_U32, dst0[c], fetchSrc(0, c));
break;
[Mesa-dev] [PATCH 08/19] nv50/ir: add support for gl_PrimitiveIDIn
Note that the primitive id is stored in a[0x18], while usually the
geometry instructions are of the form a[$a1 + 0x4] which gets mapped to
p[] space. We need to avoid the change from a[] to p[] here, so it's
keyed on whether the access is indirect or not.
Note that there's also a use-case for accessing e.g. a[$r1], however
that's not supported for now. (Could be added by checking the register
file of the indirect parameter.)
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 6 +++---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 7 +--
src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp | 3 +++
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
index f4db2ed..a6ed4b0 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
@@ -381,7 +381,7 @@ CodeEmitterNV50::setSrcFileBits(const Instruction *i, int
enc)
case 0x00: // rrr
break;
case 0x01: // arr/grr
- if (progType == Program::TYPE_GEOMETRY) {
+ if (progType == Program::TYPE_GEOMETRY && i->src(0).isIndirect(0)) {
code[0] |= 0x0180;
if (enc == NV50_OP_ENC_LONG || enc == NV50_OP_ENC_LONG_ALT)
code[1] |= 0x0020;
@@ -407,7 +407,7 @@ CodeEmitterNV50::setSrcFileBits(const Instruction *i, int
enc)
code[1] |= (i->getSrc(1)->reg.fileIndex << 22);
break;
case 0x09: // acr/gcr
- if (progType == Program::TYPE_GEOMETRY) {
+ if (progType == Program::TYPE_GEOMETRY && i->src(0).isIndirect(0)) {
code[0] |= 0x0180;
} else {
code[0] |= (enc == NV50_OP_ENC_LONG_ALT) ? 0x0100 : 0x0080;
@@ -612,7 +612,7 @@ CodeEmitterNV50::emitLOAD(const Instruction *i)
switch (sf) {
case FILE_SHADER_INPUT:
- if (progType == Program::TYPE_GEOMETRY)
+ if (progType == Program::TYPE_GEOMETRY && i->src(0).isIndirect(0))
code[0] = 0x1181;
else
// use 'mov' where we can
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index 3c790cf..321410e 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -1434,13 +1434,16 @@ Converter::fetchSrc(tgsi::Instruction::SrcRegister src,
int c, Value *ptr)
return mkOp1v(OP_RDSV, TYPE_F32, getSSA(), mkSysVal(SV_FACE, 0));
return interpolate(src, c, shiftAddress(ptr));
} else
- if (ptr && prog->getType() == Program::TYPE_GEOMETRY) {
+ if (prog->getType() == Program::TYPE_GEOMETRY) {
+ if (!ptr && info->in[idx].sn == TGSI_SEMANTIC_PRIMID)
+return mkOp1v(OP_RDSV, TYPE_U32, getSSA(),
mkSysVal(SV_PRIMITIVE_ID, 0));
// XXX: This is going to be a problem with scalar arrays, i.e. when
// we cannot assume that the address is given in units of vec4.
//
// nv50 and nvc0 need different things here, so let the lowering
// passes decide what to do with the address
- return mkLoadv(TYPE_U32, srcToSym(src, c), ptr);
+ if (ptr)
+return mkLoadv(TYPE_U32, srcToSym(src, c), ptr);
}
return mkLoadv(TYPE_U32, srcToSym(src, c), shiftAddress(ptr));
case TGSI_FILE_OUTPUT:
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
index a84a54a..1925c09 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
@@ -238,6 +238,9 @@ TargetNV50::getSVAddress(DataFile shaderFile, const Symbol
*sym) const
addr += 4;
return addr;
}
+ case SV_PRIMITIVE_ID:
+ return shaderFile == FILE_SHADER_INPUT ? 0x18 :
+ sysvalLocation[sym->reg.data.sv.sv];
case SV_NCTAID:
return 0x8 + 2 * sym->reg.data.sv.index;
case SV_CTAID:
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/19] nv50: add support for geometry shaders
From: Bryan Cain
Layer output probably doesn't work yet, but other than that everything seems
to be working.
Signed-off-by: Bryan Cain
[calim: fix up minor bugs, code formatting]
Signed-off-by: Christoph Bumiller
Signed-off-by: Ilia Mirkin
---
.../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 25 --
src/gallium/drivers/nouveau/nv50/nv50_program.c| 16 ++
.../drivers/nouveau/nv50/nv50_shader_state.c | 2 ++
src/gallium/drivers/nouveau/nv50/nv50_tex.c| 2 ++
4 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
index cf82e2f..f4db2ed 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
@@ -493,7 +493,12 @@ CodeEmitterNV50::emitForm_MAD(const Instruction *i)
setSrc(i, 1, 1);
setSrc(i, 2, 2);
- setAReg16(i, 1);
+ if (i->getIndirect(0, 0)) {
+ assert(!i->getIndirect(1, 0));
+ setAReg16(i, 0);
+ } else {
+ setAReg16(i, 1);
+ }
}
// like default form, but 2nd source in slot 2, and no 3rd source
@@ -512,7 +517,12 @@ CodeEmitterNV50::emitForm_ADD(const Instruction *i)
setSrc(i, 0, 0);
setSrc(i, 1, 2);
- setAReg16(i, 1);
+ if (i->getIndirect(0, 0)) {
+ assert(!i->getIndirect(1, 0));
+ setAReg16(i, 0);
+ } else {
+ setAReg16(i, 1);
+ }
}
// default short form (rr, ar, rc, gr)
@@ -602,8 +612,11 @@ CodeEmitterNV50::emitLOAD(const Instruction *i)
switch (sf) {
case FILE_SHADER_INPUT:
- // use 'mov' where we can
- code[0] = i->src(0).isIndirect(0) ? 0x0001 : 0x1001;
+ if (progType == Program::TYPE_GEOMETRY)
+ code[0] = 0x1181;
+ else
+ // use 'mov' where we can
+ code[0] = i->src(0).isIndirect(0) ? 0x0001 : 0x1001;
code[1] = 0x0020 | (i->lanes << 14);
if (typeSizeof(i->dType) == 4)
code[1] |= 0x0400;
@@ -1399,8 +1412,8 @@ CodeEmitterNV50::emitShift(const Instruction *i)
void
CodeEmitterNV50::emitOUT(const Instruction *i)
{
- code[0] = (i->op == OP_EMIT) ? 0xf200 : 0xf400;
- code[1] = 0xc001;
+ code[0] = (i->op == OP_EMIT) ? 0xf201 : 0xf401;
+ code[1] = 0xc000;
emitFlagsRd(i);
}
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.c
b/src/gallium/drivers/nouveau/nv50/nv50_program.c
index 97857d7..78a12e3 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_program.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_program.c
@@ -358,6 +358,22 @@ nv50_program_translate(struct nv50_program *prog, uint16_t
chipset)
}
if (info->prop.fp.usesDiscard)
prog->fp.flags[0] |= NV50_3D_FP_CONTROL_USES_KIL;
+ } else
+ if (prog->type == PIPE_SHADER_GEOMETRY) {
+ switch (info->prop.gp.outputPrim) {
+ case PIPE_PRIM_LINE_STRIP:
+ prog->gp.prim_type = NV50_3D_GP_OUTPUT_PRIMITIVE_TYPE_LINE_STRIP;
+ break;
+ case PIPE_PRIM_TRIANGLE_STRIP:
+ prog->gp.prim_type = NV50_3D_GP_OUTPUT_PRIMITIVE_TYPE_TRIANGLE_STRIP;
+ break;
+ case PIPE_PRIM_POINTS:
+ default:
+ assert(info->prop.gp.outputPrim == PIPE_PRIM_POINTS);
+ prog->gp.prim_type = NV50_3D_GP_OUTPUT_PRIMITIVE_TYPE_POINTS;
+ break;
+ }
+ prog->gp.vert_count = info->prop.gp.maxVertices;
}
if (prog->pipe.stream_output.num_outputs)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_shader_state.c
b/src/gallium/drivers/nouveau/nv50/nv50_shader_state.c
index 9144fc4..ba4f592 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_shader_state.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_shader_state.c
@@ -193,6 +193,8 @@ nv50_gmtyprog_validate(struct nv50_context *nv50)
struct nv50_program *gp = nv50->gmtyprog;
if (gp) {
+ if (!nv50_program_validate(nv50, gp))
+ return;
BEGIN_NV04(push, NV50_3D(GP_REG_ALLOC_TEMP), 1);
PUSH_DATA (push, gp->max_gpr);
BEGIN_NV04(push, NV50_3D(GP_REG_ALLOC_RESULT), 1);
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_tex.c
b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
index f7284fa..6663a61 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_tex.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
@@ -293,6 +293,7 @@ void nv50_validate_textures(struct nv50_context *nv50)
boolean need_flush;
need_flush = nv50_validate_tic(nv50, 0);
+ need_flush |= nv50_validate_tic(nv50, 1);
need_flush |= nv50_validate_tic(nv50, 2);
if (need_flush) {
@@ -343,6 +344,7 @@ void nv50_validate_samplers(struct nv50_context *nv50)
boolean need_flush;
need_flush = nv50_validate_tsc(nv50, 0);
+ need_flush |= nv50_validate_tsc(nv50, 1);
need_flush |= nv50_validate_tsc(nv50, 2);
if (need_flush) {
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freede
[Mesa-dev] [RFC PATCH 18/19] nv50: report glsl 1.50 now that gp tests pass
Signed-off-by: Ilia Mirkin --- There are still some things that fail -- mostly gl_Layer stuff, and also using gl_PositionID without a gp. src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c b/src/gallium/drivers/nouveau/nv50/nv50_screen.c index 5732b21..123bdab 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c @@ -126,7 +126,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_SM3: return 1; case PIPE_CAP_GLSL_FEATURE_LEVEL: - return 140; + return 150; case PIPE_CAP_MAX_RENDER_TARGETS: return 8; case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS: -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 14/19] nvc0: don't forget to also clear additional layers
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_program.c | 2 ++
src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 22 --
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.c
b/src/gallium/drivers/nouveau/nv50/nv50_program.c
index 813795f..e7609fa 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_program.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_program.c
@@ -166,6 +166,8 @@ nv50_fragprog_assign_slots(struct nv50_ir_prog_info *info)
if (info->in[i].sn == TGSI_SEMANTIC_COLOR)
prog->vp.bfc[info->in[i].si] = j;
+ if (info->in[i].sn == TGSI_SEMANTIC_PRIMID)
+prog->vp.attrs[2] |= NV50_3D_VP_GP_BUILTIN_ATTR_EN_PRIMITIVE_ID;
prog->in[j].id = i;
prog->in[j].mask = info->in[i].mask;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
index 5375bd4..8cc7021 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
@@ -414,7 +414,7 @@ nvc0_clear(struct pipe_context *pipe, unsigned buffers,
struct nvc0_context *nvc0 = nvc0_context(pipe);
struct nouveau_pushbuf *push = nvc0->base.pushbuf;
struct pipe_framebuffer_state *fb = &nvc0->framebuffer;
- unsigned i;
+ unsigned i, j;
uint32_t mode = 0;
/* don't need NEW_BLEND, COLOR_MASK doesn't affect CLEAR_BUFFERS */
@@ -444,12 +444,22 @@ nvc0_clear(struct pipe_context *pipe, unsigned buffers,
mode |= NVC0_3D_CLEAR_BUFFERS_S;
}
- BEGIN_NVC0(push, NVC0_3D(CLEAR_BUFFERS), 1);
- PUSH_DATA (push, mode);
+ if ((buffers & PIPE_CLEAR_DEPTH) || (buffers & PIPE_CLEAR_STENCIL)) {
+ for (j = fb->zsbuf->u.tex.first_layer; j <= fb->zsbuf->u.tex.last_layer;
j++) {
+ BEGIN_NVC0(push, NVC0_3D(CLEAR_BUFFERS), 1);
+ PUSH_DATA(push, mode | (j << NVC0_3D_CLEAR_BUFFERS_LAYER__SHIFT));
+ }
+ }
- for (i = 1; i < fb->nr_cbufs; i++) {
- BEGIN_NVC0(push, NVC0_3D(CLEAR_BUFFERS), 1);
- PUSH_DATA (push, (i << 6) | 0x3c);
+ if (buffers & PIPE_CLEAR_COLOR) {
+ for (i = 0; i < fb->nr_cbufs; i++) {
+ struct pipe_surface *sf = fb->cbufs[i];
+ for (j = sf->u.tex.first_layer; j <= sf->u.tex.last_layer; j++) {
+BEGIN_NVC0(push, NVC0_3D(CLEAR_BUFFERS), 1);
+PUSH_DATA (push, (i << 6) | 0x3c |
+ (j << NVC0_3D_CLEAR_BUFFERS_LAYER__SHIFT));
+ }
+ }
}
}
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/19] nv50: properly set the PRIMITIVE_ID enable flag when it is a gp input.
Signed-off-by: Ilia Mirkin --- src/gallium/drivers/nouveau/nv50/nv50_program.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.c b/src/gallium/drivers/nouveau/nv50/nv50_program.c index 78a12e3..f46f240 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_program.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_program.c @@ -52,6 +52,9 @@ nv50_vertprog_assign_slots(struct nv50_ir_prog_info *info) for (c = 0; c < 4; ++c) if (info->in[i].mask & (1 << c)) info->in[i].slot[c] = n++; + + if (info->in[i].sn == TGSI_SEMANTIC_PRIMID) + prog->vp.attrs[2] |= NV50_3D_VP_GP_BUILTIN_ATTR_EN_PRIMITIVE_ID; } prog->in_nr = info->numInputs; -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/19] nv50/ir: fix PFETCH and add RDSV to get VSTRIDE for GPs
From: Christoph Bumiller
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 +
.../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 62 --
.../drivers/nouveau/codegen/nv50_ir_print.cpp | 1 +
3 files changed, 59 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index 68c76e5..6a001d3 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -366,6 +366,7 @@ enum SVSemantic
SV_CLOCK,
SV_LBASE,
SV_SBASE,
+ SV_VERTEX_STRIDE,
SV_UNDEFINED,
SV_LAST
};
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
index 3eca27d..cf82e2f 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
@@ -87,6 +87,7 @@ private:
void emitLOAD(const Instruction *);
void emitSTORE(const Instruction *);
void emitMOV(const Instruction *);
+ void emitRDSV(const Instruction *);
void emitNOP();
void emitINTERP(const Instruction *);
void emitPFETCH(const Instruction *);
@@ -772,6 +773,29 @@ CodeEmitterNV50::emitMOV(const Instruction *i)
}
}
+static inline uint8_t getSRegEncoding(const ValueRef &ref)
+{
+ switch (SDATA(ref).sv.sv) {
+ case SV_PHYSID:return 0;
+ case SV_CLOCK: return 1;
+ case SV_VERTEX_STRIDE: return 3;
+// case SV_PM_COUNTER:return 4 + SDATA(ref).sv.index;
+ case SV_SAMPLE_INDEX: return 8;
+ default:
+ assert(!"no sreg for system value");
+ return 0;
+ }
+}
+
+void
+CodeEmitterNV50::emitRDSV(const Instruction *i)
+{
+ code[0] = 0x0001;
+ code[1] = 0x6000 | (getSRegEncoding(i->src(0)) << 14);
+ defId(i->def(0), 2);
+ emitFlagsRd(i);
+}
+
void
CodeEmitterNV50::emitNOP()
{
@@ -794,15 +818,40 @@ CodeEmitterNV50::emitQUADOP(const Instruction *i, uint8_t
lane, uint8_t quOp)
srcId(i->src(0), 32 + 14);
}
+/* NOTE: This returns the base address of a vertex inside the primitive.
+ * src0 is an immediate, the index (not offset) of the vertex
+ * inside the primitive. XXX: signed or unsigned ?
+ * src1 (may be NULL) should use whatever units the hardware requires
+ * (on nv50 this is bytes, so, relative index * 4; signed 16 bit value).
+ */
void
CodeEmitterNV50::emitPFETCH(const Instruction *i)
{
- code[0] = 0x1181;
- code[1] = 0x0420 | (0xf << 14);
+ const uint32_t prim = i->src(0).get()->reg.data.u32;
+ assert(prim <= 127);
- defId(i->def(0), 2);
- srcAddr8(i->src(0), 9);
- setAReg16(i, 0);
+ if (i->def(0).getFile() == FILE_ADDRESS) {
+ // shl $aX a[] 0
+ code[0] = 0x0001 | ((DDATA(i->def(0)).id + 1) << 2);
+ code[1] = 0xc020;
+ code[0] |= prim << 9;
+ assert(!i->srcExists(1));
+ } else
+ if (i->srcExists(1)) {
+ // ld b32 $rX a[$aX+base]
+ code[0] = 0x0001;
+ code[1] = 0x0420 | (0xf << 14);
+ defId(i->def(0), 2);
+ code[0] |= prim << 9;
+ setARegBits(SDATA(i->src(1)).id + 1);
+ } else {
+ // mov b32 $rX a[]
+ code[0] = 0x1001;
+ code[1] = 0x0420 | (0xf << 14);
+ defId(i->def(0), 2);
+ code[0] |= prim << 9;
+ }
+ emitFlagsRd(i);
}
void
@@ -1620,6 +1669,9 @@ CodeEmitterNV50::emitInstruction(Instruction *insn)
case OP_PFETCH:
emitPFETCH(insn);
break;
+ case OP_RDSV:
+ emitRDSV(insn);
+ break;
case OP_LINTERP:
case OP_PINTERP:
emitINTERP(insn);
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
index ee39b3c..ae42d03 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
@@ -265,6 +265,7 @@ static const char *SemanticStr[SV_LAST + 1] =
"CLOCK",
"LBASE",
"SBASE",
+ "VERTEX_STRIDE",
"?",
"(INVALID)"
};
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73512] [clover] mesa.icd. should contain full path
https://bugs.freedesktop.org/show_bug.cgi?id=73512 Igor Gnatenko changed: What|Removed |Added Attachment #91886|0 |1 is obsolete|| --- Comment #7 from Igor Gnatenko --- Created attachment 91973 --> https://bugs.freedesktop.org/attachment.cgi?id=91973&action=edit [PATCH v3] opencl: improved auto-gen .icd v2: Use @OPENCL_VERSION@:0 for library replace /etc with @sysconfdir@ macros v3: Drop libdir from icd, because libMesaOpenCL isn't private -- 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] opencl: improved auto-gen .icd
On Sun, Jan 12, 2014 at 03:08:56AM +0400, Igor Gnatenko wrote: > From 5b2bf87f1238e44150492a39f5db0ae90d59459b Mon Sep 17 00:00:00 2001 > From: Igor Gnatenko > Date: Sun, 12 Jan 2014 02:09:16 +0400 > Subject: [PATCH] opencl: improved auto-gen .icd > > v2: Use @OPENCL_VERSION@:0 for library > replace /etc with @sysconfdir@ macros > > Reported-by: Fabian Deutsch > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=73512 > Signed-off-by: Igor Gnatenko > --- > configure.ac | 3 +++ > src/gallium/targets/opencl/Makefile.am | 4 ++-- > src/gallium/targets/opencl/mesa.icd| 1 - > src/gallium/targets/opencl/mesa.icd.in | 1 + > 4 files changed, 6 insertions(+), 3 deletions(-) > delete mode 100644 src/gallium/targets/opencl/mesa.icd > create mode 100644 src/gallium/targets/opencl/mesa.icd.in > > diff --git a/configure.ac b/configure.ac > index 4b55140..3452e15 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -25,6 +25,8 @@ m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) > dnl Set internal versions > OSMESA_VERSION=8 > AC_SUBST([OSMESA_VERSION]) > +OPENCL_VERSION=1 > +AC_SUBST([OPENCL_VERSION]) > > dnl Versions for external dependencies > LIBDRM_REQUIRED=2.4.24 > @@ -2023,6 +2025,7 @@ AC_CONFIG_FILES([Makefile > src/gallium/targets/egl-static/Makefile > src/gallium/targets/gbm/Makefile > src/gallium/targets/opencl/Makefile > + src/gallium/targets/opencl/mesa.icd > src/gallium/targets/osmesa/Makefile > src/gallium/targets/osmesa/osmesa.pc > src/gallium/targets/pipe-loader/Makefile > diff --git a/src/gallium/targets/opencl/Makefile.am > b/src/gallium/targets/opencl/Makefile.am > index 653302c..923316c 100644 > --- a/src/gallium/targets/opencl/Makefile.am > +++ b/src/gallium/targets/opencl/Makefile.am > @@ -4,7 +4,7 @@ lib_LTLIBRARIES = lib@OPENCL_LIBNAME@.la > > lib@OPENCL_LIBNAME@_la_LDFLAGS = \ > $(LLVM_LDFLAGS) \ > - -version-number 1:0 > + -version-number @OPENCL_VERSION@:0 > > lib@OPENCL_LIBNAME@_la_LIBADD = \ > $(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader.la \ > @@ -34,7 +34,7 @@ lib@OPENCL_LIBNAME@_la_SOURCES = > nodist_EXTRA_lib@OPENCL_LIBNAME@_la_SOURCES = dummy.cpp > > if HAVE_CLOVER_ICD > -icddir = /etc/OpenCL/vendors/ > +icddir = @sysconfdir@/OpenCL/vendors/ As I mentioned in the bug report, the ICD spec says that OpenCL/vendors/ should be in /etc/ I don't think we can change this and still be spec compliant. Why do you want to install the *.icd files in sysconfdir? > icd_DATA = mesa.icd > endif > > diff --git a/src/gallium/targets/opencl/mesa.icd > b/src/gallium/targets/opencl/mesa.icd > deleted file mode 100644 > index 6a6a870..000 > --- a/src/gallium/targets/opencl/mesa.icd > +++ /dev/null > @@ -1 +0,0 @@ > -libMesaOpenCL.so > diff --git a/src/gallium/targets/opencl/mesa.icd.in > b/src/gallium/targets/opencl/mesa.icd.in > new file mode 100644 > index 000..a0b6489 > --- /dev/null > +++ b/src/gallium/targets/opencl/mesa.icd.in > @@ -0,0 +1 @@ > +@libdir@/lib@OPENCL_LIBNAME@.so.@OPENCL_VERSION@ Again, the spec says only the library name should go here and not the full path. -Tom > -- > 1.8.4.2 > > -- > -Igor Gnatenko > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73512] [clover] mesa.icd. should contain full path
https://bugs.freedesktop.org/show_bug.cgi?id=73512 --- Comment #6 from Fabian Deutsch --- Hey, this can all be a result of me being uninformed (not knowing that only the library name is contained in the .icd file). But I think that the .icd file is still not corect, as it contains only the unversioned library name libMesaOpenCL.so - which is - as Igor metions - not packaged in the main packages (only in devel subpackages). So I'm not sure if the original icd file should contain the versioned library, or if we should do this downstream in Fedora. -- 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] [RFC] Build testing, wine style
On Sat, Jan 11, 2014 at 03:53:58PM +, Emil Velikov wrote: > Hello list, > > While going though mesa's build systems I was wondering what it would > take to improve the overall experience of build testing. > > The only thing I can think of is a more centralised solution similar to > the one used by wine [1]. Having buildbots test every patch what is send > to the ML [2] :) > > I'm sure that some companies/organisations may have similar > infrastructure but I was thinking what is the possibility of having a > more open/shared experience, thus one does not need to test the same > environment/setup across multiple bots. > > Here are a couple of nice words for each build system that mesa has: > > * automake - tons of many build variations, most of which handled by > debian/ubuntu, fedora and suse build systems. > > * scons - less build variations, mainly used for non-public > state-trackers and/or drivers > > * android - possibly the most painful one out there (IMHO), 10GiB code > cloned a ton of libraries build and alot more that fair rather randomly :\ > > Kind of wondering what it would take to have such a feature and if > people will see benefits from it. Hi Emil, I've been playing around with buildbot, and I even had a local one doing Mesa builds a few weeks ago. I just need to find a dedicated machine so I can have it running full-time. For me, I'm mostly interested in using buildbot for piglit testing, but I think it would also be useful to catch build breakages for the various configurations people care about. I still don't understand the whole master/slave relationship of buildbot, so I'm not sure what kind of centralized resources would be needed, but maybe if someone would volunteer to maintain it we could use some of the fdo resources for hosting buildbot. You also may want to take a look at tinderbox.x.org, which already does some build testing. I prefer buildbot mainly because I was unable to find very much documentation for tinderbox, but it might be worth looking at. -Tom > > Cheers, > Emil > > [1] http://wiki.winehq.org/BuildBot > [2] http://source.winehq.org/patches/ > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73512] [clover] mesa.icd. should contain full path
https://bugs.freedesktop.org/show_bug.cgi?id=73512 --- Comment #5 from Igor Gnatenko --- (In reply to comment #4) > According to the icd spec: > http://www.khronos.org/registry/cl/extensions/khr/cl_khr_icd.txt > > The vendors directory must go in /etc/OpenCL and also only the library name > is included in the *.icd file, not the full path, so I don't think this > patch is correct. > > What problem does this patch fix? 1. we're not installing .so to main package. we are installing it to -devel subpackage. So .icd should contain like .so.@LIBVER@ 2. Fabian, Can you try to use liMesaOpenCL.so.1 in .icd file. What clinfo will do say ? -- 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] [wip 1/9] glsl: memory_writer helper class for data serialization
On 01/02/2014 03:58 AM, Tapani Pälli wrote:
> Class will be used by the shader binary cache implementation.
>
> Signed-off-by: Tapani Pälli
> ---
> src/glsl/memory_writer.h | 147
> +++
> 1 file changed, 147 insertions(+)
> create mode 100644 src/glsl/memory_writer.h
>
> diff --git a/src/glsl/memory_writer.h b/src/glsl/memory_writer.h
> new file mode 100644
> index 000..a6c6b55
> --- /dev/null
> +++ b/src/glsl/memory_writer.h
> @@ -0,0 +1,147 @@
> +/* -*- c++ -*- */
> +/*
> + * Copyright © 2013 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.
> + */
> +
> +#pragma once
> +#ifndef MEMORY_WRITER_H
> +#define MEMORY_WRITER_H
> +
> +#include
> +#include
> +#include
> +
> +#ifdef __cplusplus
> +/**
> + * Helper class for writing data to memory
> + *
> + * This class maintains a dynamically-sized memory buffer and allows
> + * for data to be efficiently appended to it with automatic resizing.
> + */
> +class memory_writer
> +{
> +public:
> + memory_writer() :
> + memory(NULL),
> + curr_size(0),
> + pos(0) {}
> +
> + ~memory_writer()
> + {
> + free(memory);
> + }
> +
> + /* user wants to claim the memory */
> + char *release_memory(size_t *size)
> + {
> + /* final realloc to free allocated but unused memory */
> + char *result = (char *) realloc(memory, pos);
> + *size = pos;
> + memory = NULL;
> + curr_size = 0;
> + pos = 0;
> + return result;
> + }
> +
> +/**
> + * write functions per type
> + */
> +#define DECL_WRITER(type) int write_ ##type (const type data) {\
> + return write(&data, sizeof(type));\
> +}
> +
> + DECL_WRITER(int32_t);
> + DECL_WRITER(int64_t);
> + DECL_WRITER(uint8_t);
> + DECL_WRITER(uint32_t);
> +
> + int write_bool(bool data)
I agree with Paul's previous comments about the return values.
http://lists.freedesktop.org/archives/mesa-dev/2013-November/047740.html
It looks like the only errors tested are either memory allocation or bad
parameters. The bad parameter checks should just be assertions.
> + {
> + uint8_t val = data;
> + return write_uint8_t(val);
> + }
> +
> + /* write function that reallocates more memory if required */
> + int write(const void *data, int32_t size)
> + {
> + if (!memory || pos > (int32_t)(curr_size - size))
> + if (grow(size))
> +return -1;
> +
> + memcpy(memory + pos, data, size);
> +
> + pos += size;
> + return 0;
> + }
> +
> + int overwrite(const void *data, int32_t size, int32_t offset)
> + {
> + if (offset < 0 || offset + size > pos)
> + return -1;
> + memcpy(memory + offset, data, size);
> + return 0;
> + }
> +
> + int write_string(const char *str)
> + {
> + if (!str)
> + return -1;
> + char terminator = '\0';
> + write(str, strlen(str));
> + write(&terminator, 1);
This should just be
write(str, strlen(str) + 1);
> + return 0;
> + }
> +
> + inline int32_t position() { return pos; }
> +
> +
> +private:
> +
> + /* reallocate more memory */
> + int grow(int32_t size)
> + {
> + int32_t new_size = 2 * (curr_size + size);
> + char *more_mem = (char *) realloc(memory, new_size);
> + if (more_mem == NULL) {
> + free(memory);
> + memory = NULL;
> + return -1;
> + } else {
> + memory = more_mem;
> + curr_size = new_size;
> + return 0;
> + }
> + }
> +
> + /* allocated memory */
> + char *memory;
> +
> + /* current size of the whole allocation */
> + int32_t curr_size;
Is there a reason to specifically make this int32_t instead of just int?
Or even unsigned?
> +
> + /* write position / size of the data written */
> + int32_t pos;
> +};
> +
> +#endif /* ifdef __cplusplus */
> +
> +#e
Re: [Mesa-dev] [wip 1/9] glsl: memory_writer helper class for data serialization
On 2 January 2014 03:58, Tapani Pälli wrote:
> Class will be used by the shader binary cache implementation.
>
> Signed-off-by: Tapani Pälli
> ---
> src/glsl/memory_writer.h | 147
> +++
> 1 file changed, 147 insertions(+)
> create mode 100644 src/glsl/memory_writer.h
>
> diff --git a/src/glsl/memory_writer.h b/src/glsl/memory_writer.h
> new file mode 100644
> index 000..a6c6b55
> --- /dev/null
> +++ b/src/glsl/memory_writer.h
> @@ -0,0 +1,147 @@
> +/* -*- c++ -*- */
> +/*
> + * Copyright © 2013 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.
> + */
> +
> +#pragma once
> +#ifndef MEMORY_WRITER_H
> +#define MEMORY_WRITER_H
> +
> +#include
> +#include
> +#include
> +
> +#ifdef __cplusplus
> +/**
> + * Helper class for writing data to memory
> + *
> + * This class maintains a dynamically-sized memory buffer and allows
> + * for data to be efficiently appended to it with automatic resizing.
> + */
> +class memory_writer
> +{
> +public:
> + memory_writer() :
> + memory(NULL),
> + curr_size(0),
> + pos(0) {}
> +
> + ~memory_writer()
> + {
> + free(memory);
> + }
> +
> + /* user wants to claim the memory */
> + char *release_memory(size_t *size)
> + {
> + /* final realloc to free allocated but unused memory */
> + char *result = (char *) realloc(memory, pos);
> + *size = pos;
> + memory = NULL;
> + curr_size = 0;
> + pos = 0;
> + return result;
> + }
> +
> +/**
> + * write functions per type
> + */
> +#define DECL_WRITER(type) int write_ ##type (const type data) {\
> + return write(&data, sizeof(type));\
> +}
> +
> + DECL_WRITER(int32_t);
> + DECL_WRITER(int64_t);
> + DECL_WRITER(uint8_t);
> + DECL_WRITER(uint32_t);
> +
> + int write_bool(bool data)
> + {
> + uint8_t val = data;
> + return write_uint8_t(val);
> + }
> +
> + /* write function that reallocates more memory if required */
> + int write(const void *data, int32_t size)
> + {
> + if (!memory || pos > (int32_t)(curr_size - size))
> + if (grow(size))
> +return -1;
> +
> + memcpy(memory + pos, data, size);
> +
> + pos += size;
> + return 0;
> + }
> +
> + int overwrite(const void *data, int32_t size, int32_t offset)
> + {
> + if (offset < 0 || offset + size > pos)
> + return -1;
> + memcpy(memory + offset, data, size);
> + return 0;
> + }
> +
> + int write_string(const char *str)
> + {
> + if (!str)
> + return -1;
> + char terminator = '\0';
> + write(str, strlen(str));
> + write(&terminator, 1);
>
C strings include a terminator, so there's no reason to write out the
string contents and the terminator separtely. You can just do:
write(str, strlen(str) + 1);
Also, don't forget to propagate the return code to the caller:
return write(str, strlen(str) + 1);
> + return 0;
> + }
> +
> + inline int32_t position() { return pos; }
> +
> +
> +private:
> +
> + /* reallocate more memory */
> + int grow(int32_t size)
> + {
> + int32_t new_size = 2 * (curr_size + size);
> + char *more_mem = (char *) realloc(memory, new_size);
> + if (more_mem == NULL) {
> + free(memory);
> + memory = NULL;
> + return -1;
> + } else {
> + memory = more_mem;
> + curr_size = new_size;
> + return 0;
> + }
> + }
> +
> + /* allocated memory */
> + char *memory;
> +
> + /* current size of the whole allocation */
> + int32_t curr_size;
> +
> + /* write position / size of the data written */
> + int32_t pos;
> +};
> +
> +#endif /* ifdef __cplusplus */
> +
> +#endif /* MEMORY_WRITER_H */
> --
> 1.8.3.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop
[Mesa-dev] [Bug 70410] egl-static/Makefile: linking fails with llvm >= 3.4
https://bugs.freedesktop.org/show_bug.cgi?id=70410 --- Comment #18 from Krzysztof A. Sobiecki --- (In reply to comment #17) > I've tested attachment 91725 [details] and it works with LLVM 3.5 (r198682) > in a clean build enviroment (LLVM packages for Debian from llvm.org/apt). > > I couldn't use attachment 91764 [details] [review], since apparently the > patch from attachment 91751 [details] [review] hasn't landed in LLVM's tree > yet (at least not before r198682). > > You can have my > Tested-by: Kai Wasserbäch > for attachment 91725 [details]. > > Stack: > LLVM: SVN:trunk/r198682 > Mesa: Git:master/532b1fecd9 > libdrm: 2.4.50-1 (Debian package) Thank You for Your help, I will wait for LLVM to fix newline problem, before sending this patch to mesa-dev -- 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] Mark debug_print with __attribute__ ((format(__printf__, 1, 0)))
Ian Romanick writes: > Reviewed-by: Ian Romanick Thanks. Pushed. 8279c8f..cb4bc8e master -> master -- keith.pack...@intel.com pgpkKf6zSEV5v.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenCL Clang/Clover Offline Compilation issue
On Thu, Jan 09, 2014 at 12:49:51PM +, Dorrington, Albert wrote:
> I am not sure if this is the appropriate list on which to ask this question,
> if not hopefully someone can suggest an alternative.
>
> Under Linux, I am attempting to perform an offline compile of an OpenCL
> kernel example using Clang, and then load that binary using the
> clCreateProgramWithBinary() function.
>
> Unfortunately, while clover is loading the binary, I end up getting a
> segmentation fault:
>
> Program received signal SIGSEGV, Segmentation fault.
> proc (v=..., is=...) at core/module.cpp:50
> 50T x;
>
> I have pasted the source code I am using below, for both the kernel and the
> host code.
>
> I am compiling with the following commands:
> clang -target r600-unknown-unknown -x cl -S -emit-llvm -mcpu=r600 kernel.cl
> -o kernel.clbin
I'm surprised that this works, since the r600 GPU does not support OpenCL
(Note that R600 is the name of the target and also one of the individual
GPUs supported by the compiler). The argument of -mcpu= needs to be
GPU you are compiling the code for. So if you have a redwood GPU you
would need to pass -mcpu=redwood.
However, the main issue here is that clover does not support
clCreateProgramWithBinary() yet. If you are interested in implementing
this, I can give you some pointers. Just send an email to the list or
ping me on irc (nick: tstellar on #radeon @ irc.freednode.net).
-Tom
> clang -g -L/usr/local/lib -lOpenCL offline_host.c -o offline_host
>
> I have LLVM/Clang 3.4RC3 installed and Mesa 10.0.1.
>
> If anyone has suggestions, or can point me to the appropriate mailing list or
> documentation, I'd appreciate it.
>
> Thanks!
> -Al
>
>
> Source code for "kernel.cl"
>
> __kernel void vecAdd(__global float* a)
> {
> int gid = get_global_id(0);
> a[gid] += a[gid];
> }
>
>
> Source code for "offline_host.c"
> ==
> #include
> #include
>
> #ifdef __APPLE__
> #include
> #else
> #include
> #endif
>
> #define MEM_SIZE (128)
> #define MAX_BINARY_SIZE (0x10)
>
> int main()
> {
> cl_platform_id platform_id = NULL;
> cl_device_id device_id = NULL;
> cl_context context = NULL;
> cl_command_queue command_queue = NULL;
> cl_mem memobj = NULL;
> cl_program program = NULL;
> cl_kernel kernel = NULL;
> cl_uint ret_num_devices;
> cl_uint ret_num_platforms;
> cl_int ret;
>
> float mem[MEM_SIZE];
>
> FILE *fp;
> char fileName[] = "kernel.clbin";
> size_t binary_size;
> char *binary_buf;
> cl_int binary_status;
> cl_int i;
>
> /* Load kernel binary */
> fp = fopen(fileName, "r");
> if (!fp) {
> fprintf(stderr, "Failed to load kernel.\n");
> exit(1);
> }
> binary_buf = (char *)malloc(MAX_BINARY_SIZE);
> binary_size = fread(binary_buf, 1, MAX_BINARY_SIZE, fp);
> fclose(fp);
>
> /* Initialize input data */
> for (i = 0; i < MEM_SIZE; i++) {
> mem[i] = i;
> }
>
> /* Get platform/device information */
> ret = clGetPlatformIDs(1, &platform_id, &ret_num_platforms);
> ret = clGetDeviceIDs(platform_id, CL_DEVICE_TYPE_GPU, 1, &device_id,
> &ret_num_devices);
>
> /* Create OpenCL context*/
> context = clCreateContext(NULL, 1, &device_id, NULL, NULL, &ret);
>
> /* Create command queue */
> command_queue = clCreateCommandQueue(context, device_id, 0, &ret);
>
> /* Create memory buffer */
> memobj = clCreateBuffer(context, CL_MEM_READ_WRITE, MEM_SIZE *
> sizeof(float), NULL, &ret);
>
> /* Transfer data over to the memory buffer */
> ret = clEnqueueWriteBuffer(command_queue, memobj, CL_TRUE, 0, MEM_SIZE *
> sizeof(float), mem, 0, NULL, NULL);
>
> /* Create kernel program from the kernel binary */
> program = clCreateProgramWithBinary(context, 1, &device_id, (const size_t
> *)&binary_size,
> (const unsigned char **)&binary_buf, &binary_status, &ret);
>
> /* Create OpenCL kernel */
> kernel = clCreateKernel(program, "vecAdd", &ret);
> printf("err:%d\n", ret);
>
> /* Set OpenCL kernel arguments */
> ret = clSetKernelArg(kernel, 0, sizeof(cl_mem), (void *)&memobj);
>
> size_t global_work_size[3] = {MEM_SIZE, 0, 0};
> size_t local_work_size[3] = {MEM_SIZE, 0, 0};
>
> /* Execute OpenCL kernel */
> ret = clEnqueueNDRangeKernel(command_queue, kernel, 1, NULL,
> global_work_size, local_work_size, 0, NULL, NULL);
>
> /* Copy result from the memory buffer */
> ret = clEnqueueReadBuffer(command_queue, memobj, CL_TRUE, 0, MEM_SIZE *
> sizeof(float), mem, 0, NULL, NULL);
>
> /* Display results */
> for (i=0; i < MEM_SIZE; i++) {
> printf("mem[%d] : $f\n", i, mem[i]);
> }
>
> /* Finalization */
> ret = clFlush(command_queue);
> ret = clFinish(command_queue);
> ret = clReleaseKernel(kernel);
> ret = clReleaseProgram(program);
> ret = clReleaseMemObject(memobj);
> ret = clReleaseCommandQueue(command_queue);
> ret = clReleaseContext(context);
>
> free(binary_buf);
>
> return 0
Re: [Mesa-dev] [PATCH] Mark debug_print with __attribute__ ((format(__printf__, 1, 0)))
Reviewed-by: Ian Romanick
On 01/12/2014 10:34 AM, Keith Packard wrote:
> the drmServerInfo member, debug_print, takes a printf format string
> and varargs list. Tell the compiler about it.
>
> Signed-off-by: Keith Packard
> ---
> xf86drm.h | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/xf86drm.h b/xf86drm.h
> index 1e763a3..5e170f8 100644
> --- a/xf86drm.h
> +++ b/xf86drm.h
> @@ -92,8 +92,14 @@ extern "C" {
> typedef unsigned int drmSize, *drmSizePtr; /**< For mapped
> regions */
> typedef void *drmAddress, **drmAddressPtr; /**< For mapped regions
> */
>
> +#if (__GNUC__ >= 3)
> +#define DRM_PRINTFLIKE(f, a) __attribute__ ((format(__printf__, f, a)))
> +#else
> +#define DRM_PRINTFLIKE(f, a)
> +#endif
> +
> typedef struct _drmServerInfo {
> - int (*debug_print)(const char *format, va_list ap);
> + int (*debug_print)(const char *format, va_list ap) DRM_PRINTFLIKE(1,0);
>int (*load_module)(const char *name);
>void (*get_perms)(gid_t *, mode_t *);
> } drmServerInfo, *drmServerInfoPtr;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GPU lockup CP stall when calling clBuildProgram on Cayman
On Thu, Jan 09, 2014 at 02:57:20PM +, christophe choquet wrote: > Hi, > > I am using kernel 3.12.6-gentoo, Mesa 10.0.1 and once every two calls to > clBuildProgram, the GPU goes to reset after 10 seconds. > This also happens on Debian unstable with Mesa 9.2. First hello_world works, > the next one hangs, third works, and so on. > > Despite this hang on this particular OpenCL call, every thing is just fine. I > tried to comment out DMA flushing code in r600/r600_hw_context.c, but this > issue does not look the one that what was discovered on R600 HW. > > After the hang, opencl_examples/hello_world returns the correct value (when > the machine does not hang completely which happens sometimes). Same behaviour > for get-global-id test program. > This is likely the same issues as https://bugs.freedesktop.org/show_bug.cgi?id=73418 Are you running the OpenCL programs with or without X? Can you reply in the comments of the bug. Thanks, Tom > Here is my config & logs: > lscpi: > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Cayman PRO [Radeon HD 6950] > > dmesg: > [ 826.250105] radeon :01:00.0: GPU lockup CP stall for more than > 1msec > [ 826.250110] radeon :01:00.0: GPU lockup (waiting for > 0x37bc last fence id 0x37ba) > [ 826.250118] [drm] Disabling audio 0 support > [ 826.257466] radeon :01:00.0: Saved 111 dwords of commands on ring 0. > [ 826.257496] radeon :01:00.0: GPU softreset: 0x0008 > [ 826.257498] radeon :01:00.0: GRBM_STATUS = 0xB0001828 > [ 826.257500] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0003 > [ 826.257502] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0003 > [ 826.257504] radeon :01:00.0: SRBM_STATUS = 0x20C0 > [ 826.257526] radeon :01:00.0: SRBM_STATUS2 = 0x > [ 826.257528] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x > [ 826.257529] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x4000 > [ 826.257531] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x00010006 > [ 826.257533] radeon :01:00.0: R_008680_CP_STAT = 0x80228647 > [ 826.257535] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 > [ 826.257537] radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 > [ 826.257539] radeon :01:00.0: VM_CONTEXT0_PROTECTION_FAULT_ADDR > 0x > [ 826.257541] radeon :01:00.0: VM_CONTEXT0_PROTECTION_FAULT_STATUS > 0x > [ 826.257542] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 826.257544] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 826.264350] radeon :01:00.0: GRBM_SOFT_RESET=0x4001 > [ 826.264403] radeon :01:00.0: SRBM_SOFT_RESET=0x0100 > [ 826.265558] radeon :01:00.0: GRBM_STATUS = 0x1828 > [ 826.265560] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0003 > [ 826.265561] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0003 > [ 826.265563] radeon :01:00.0: SRBM_STATUS = 0x20C0 > [ 826.265585] radeon :01:00.0: SRBM_STATUS2 = 0x > [ 826.265587] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x > [ 826.265589] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x > [ 826.265590] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x > [ 826.265592] radeon :01:00.0: R_008680_CP_STAT = 0x > [ 826.265594] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 > [ 826.265596] radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 > [ 826.265623] radeon :01:00.0: GPU reset succeeded, trying to resume > [ 826.283559] [drm] PCIE gen 2 link speeds already enabled > [ 826.285981] [drm] PCIE GART of 1024M enabled (table at 0x00273000). > [ 826.286049] radeon :01:00.0: WB enabled > [ 826.286051] radeon :01:00.0: fence driver on ring 0 use gpu addr > 0x8c00 and cpu addr 0x8800cbaa3c00 > .. > > > On hello_world.c program hangs every two calls at line: > error = clBuildProgram(program, > 1, /* Number of devices */ > &device_id, > NULL, /* options */ > NULL, /* callback function when compile is complete > */ > NULL); /* user data for callback */ > > > Thanks for your help, > Regards > > ___ > 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 6/8] glsl: Use a new foreach_list2 macro for walking two lists at once.
On 01/11/2014 02:37 AM, Kenneth Graunke wrote:
> When handling function calls, we often want to walk through the list of
> formal parameters and list of actual parameters at the same time.
> (Both are guaranteed to be the same length.)
>
> Previously, we used a pattern of:
>
>exec_list_iterator 1st_iter = <1st list>.iterator();
>foreach_iter(exec_list_iterator, 2nd_iter, <2nd list>) {
> ...
> 1st_iter.next();
>}
>
> This was a bit awkward, since you had to manually iterate through one of
> the two lists.
"a bit" lol.
> This patch introduces a foreach_list2 macro which safely walks through
> two lists at the same time, so you can simply do:
>
>foreach_list2(1st_node, <1st list>, 2nd_node, <2nd list>) {
> ...
>}
My only suggestion might be to change the name to foreach_two_lists. I
think it's more obvious to someone reading the header file looking for
utility macros.
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/ast_function.cpp | 16 --
> src/glsl/ir.cpp| 12 +++---
> src/glsl/linker.cpp| 9
> src/glsl/list.h| 16 ++
> src/glsl/opt_constant_folding.cpp | 9
> src/glsl/opt_constant_propagation.cpp | 9
> src/glsl/opt_constant_variable.cpp | 9
> src/glsl/opt_copy_propagation.cpp | 9
> src/glsl/opt_copy_propagation_elements.cpp | 9
> src/glsl/opt_function_inlining.cpp | 35
> --
> src/glsl/opt_tree_grafting.cpp | 10 -
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 22 +++
> 12 files changed, 73 insertions(+), 92 deletions(-)
>
> diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
> index e4c0fd1..9a9bb74 100644
> --- a/src/glsl/ast_function.cpp
> +++ b/src/glsl/ast_function.cpp
> @@ -293,15 +293,10 @@ generate_call(exec_list *instructions,
> ir_function_signature *sig,
> * call takes place. Since we haven't emitted the call yet, we'll place
> * the post-call conversions in a temporary exec_list, and emit them
> later.
> */
> - exec_list_iterator actual_iter = actual_parameters->iterator();
> - exec_list_iterator formal_iter = sig->parameters.iterator();
> -
> - while (actual_iter.has_next()) {
> - ir_rvalue *actual = (ir_rvalue *) actual_iter.get();
> - ir_variable *formal = (ir_variable *) formal_iter.get();
> -
> - assert(actual != NULL);
> - assert(formal != NULL);
> + foreach_list2(formal_node, &sig->parameters,
> + actual_node, actual_parameters) {
> + ir_rvalue *actual = (ir_rvalue *) actual_node;
> + ir_variable *formal = (ir_variable *) formal_node;
The old code asserts when the lists aren't the same length... or at
least when sig->parameters is shorter than actual_parameters. As do the
loops in st_glsl_to_tgsi.cpp. I think a debug-build version of
foreach_list2 could do the same... I'm just waffling whether there's
sufficient value to make it worth doing. Opinions?
>if (formal->type->is_numeric() || formal->type->is_boolean()) {
>switch (formal->data.mode) {
> @@ -323,9 +318,6 @@ generate_call(exec_list *instructions,
> ir_function_signature *sig,
> break;
>}
>}
> -
> - actual_iter.next();
> - formal_iter.next();
> }
>
> /* If the function call is a constant expression, don't generate any
> diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
> index 6ffa987..dcde631 100644
> --- a/src/glsl/ir.cpp
> +++ b/src/glsl/ir.cpp
> @@ -1649,13 +1649,10 @@ modes_match(unsigned a, unsigned b)
> const char *
> ir_function_signature::qualifiers_match(exec_list *params)
> {
> - exec_list_iterator iter_a = parameters.iterator();
> - exec_list_iterator iter_b = params->iterator();
> -
> /* check that the qualifiers match. */
> - while (iter_a.has_next()) {
> - ir_variable *a = (ir_variable *)iter_a.get();
> - ir_variable *b = (ir_variable *)iter_b.get();
> + foreach_list2(a_node, &this->parameters, b_node, params) {
> + ir_variable *a = (ir_variable *) a_node;
> + ir_variable *b = (ir_variable *) b_node;
>
>if (a->data.read_only != b->data.read_only ||
> !modes_match(a->data.mode, b->data.mode) ||
> @@ -1666,9 +1663,6 @@ ir_function_signature::qualifiers_match(exec_list
> *params)
>/* parameter a's qualifiers don't match */
>return a->name;
>}
> -
> - iter_a.next();
> - iter_b.next();
> }
> return NULL;
> }
> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> index 14e2ff6..7c25031 100644
> --- a/src/glsl/linker.cpp
> +++ b/src/glsl/linker.cpp
> @@ -109,10 +109,10 @@ public:
>
> virtual ir_visitor_status visit_enter(ir_call *ir)
> {
> - exec_list_iterator sig_iter = ir->callee->parameters.iterator();
> - fore
Re: [Mesa-dev] Removing exec_list iterators
On 01/11/2014 02:37 AM, Kenneth Graunke wrote: > Hello, > > Here's a long overdue cleanup: removing exec_list_iterator and such. > Should be fairly easy to review. I ran Piglit on i965, swrast (which > uses ir_to_mesa), and softpipe (which uses st_glsl_to_tgsi). Nothing > changed. Patches 1 - 5 and 8 are, as-is, Reviewed-by: Ian Romanick I sent some feedback on 6 and 7. > --Ken > > ___ > 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 7/8] glsl: Replace iterators in ir_reader.cpp with ad-hoc list walking.
On 01/11/2014 02:37 AM, Kenneth Graunke wrote:
> These can't use foreach_list since they want to skip over the first few
> list elements. Just doing the ad-hoc list walking isn't too bad.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/ir_reader.cpp | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/src/glsl/ir_reader.cpp b/src/glsl/ir_reader.cpp
> index f5185d2..28923f3 100644
> --- a/src/glsl/ir_reader.cpp
> +++ b/src/glsl/ir_reader.cpp
> @@ -205,11 +205,12 @@ ir_reader::read_function(s_expression *expr, bool
> skip_body)
>assert(added);
> }
>
> - exec_list_iterator it = ((s_list *) expr)->subexpressions.iterator();
> - it.next(); // skip "function" tag
> - it.next(); // skip function name
> - for (/* nothing */; it.has_next(); it.next()) {
> - s_expression *s_sig = (s_expression *) it.get();
> + /* Skip over "function" tag and function name (which are guaranteed to be
> +* present by the above PARTIAL_MATCH call).
> +*/
> + exec_node *node = ((s_list *) expr)->subexpressions.head->next->next;
> + for (/* nothing */; !node->is_tail_sentinel(); node = node->next) {
> + s_expression *s_sig = (s_expression *) node;
This won't behave the same in the (bug) case that the list has too few
elements. If the list is empty or as only one element, there will be a
NULL deref here somewhere. I believe the iterator version was safe
against this.
Do we have some pre-existing guarantee that the list has enough elements?
>read_function_sig(f, s_sig, skip_body);
> }
> return added ? f : NULL;
> @@ -249,9 +250,10 @@ ir_reader::read_function_sig(ir_function *f,
> s_expression *expr, bool skip_body)
> exec_list hir_parameters;
> state->symbols->push_scope();
>
> - exec_list_iterator it = paramlist->subexpressions.iterator();
> - for (it.next() /* skip "parameters" */; it.has_next(); it.next()) {
> - ir_variable *var = read_declaration((s_expression *) it.get());
> + /* Skip over the "parameters" tag. */
> + exec_node *node = paramlist->subexpressions.head->next;
> + for (/* nothing */; !node->is_tail_sentinel(); node = node->next) {
> + ir_variable *var = read_declaration((s_expression *) node);
>if (var == NULL)
>return;
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73512] [clover] mesa.icd. should contain full path
https://bugs.freedesktop.org/show_bug.cgi?id=73512 --- Comment #4 from Tom Stellard --- According to the icd spec: http://www.khronos.org/registry/cl/extensions/khr/cl_khr_icd.txt The vendors directory must go in /etc/OpenCL and also only the library name is included in the *.icd file, not the full path, so I don't think this patch is correct. What problem does this patch fix? -- 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 5/8] glsl: Statically cast parameter exec_node to ir_variable.
On 01/11/2014 02:37 AM, Kenneth Graunke wrote:
> Formal function parameters are always ir_variable objects, not an
> arbitrary ir_instruction. So there's no need to dynamically cast here.
...especially since we never bother to check that as_variable doesn't
return NULL.
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/builtin_functions.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
> index 5b8463a..662ff4c 100644
> --- a/src/glsl/builtin_functions.cpp
> +++ b/src/glsl/builtin_functions.cpp
> @@ -2399,7 +2399,7 @@ builtin_builder::call(ir_function *f, ir_variable *ret,
> exec_list params)
> exec_list actual_params;
>
> foreach_list(node, ¶ms) {
> - ir_variable *var = ((ir_instruction *) node)->as_variable();
> + ir_variable *var = (ir_variable *) node;
>actual_params.push_tail(var_ref(var));
> }
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] r300g/compiler/tests: Remove an unused variable
On Mon, Jan 06, 2014 at 11:47:39AM +0200, Lauri Kasanen wrote: > On Sun, 5 Jan 2014 18:51:18 -0800 > Tom Stellard wrote: > > > struct rc_test_file test_file; > > + struct rc_instruction *inst; > > unsigned optimizations = 1; > > unsigned do_full_regalloc = 1; > > - struct rc_instruction *inst; > > unsigned pass = 1; > > This doesn't do what the title says. > Thanks for spotting this I will drop the patch. -Tom > - Lauri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Use AC_PATH_TOOL instead of AC_PATH_PROG for llvm-config.
On Sat, Dec 28, 2013 at 03:22:09PM +0100, Michał Górny wrote: > This should help with cross-compiling and multilib when $CHOST-specific > llvm-config is expected rather than build host default one. > > It will help us a bit in Gentoo where we've started using > i686-pc-linux-gnu-llvm-config for 32-bit multilib LLVM. > Reviewed-by: Tom Stellard Should we CC stable on this patch? Do you have commit access? -Tom > Signed-off-by: Michał Górny > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73100 > --- > configure.ac | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/configure.ac b/configure.ac > index f75325d..1d68547 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1567,9 +1567,9 @@ if test "x$enable_gallium_llvm" = xauto; then > fi > if test "x$enable_gallium_llvm" = xyes; then > if test "x$llvm_prefix" != x; then > -AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no], > ["$llvm_prefix/bin"]) > +AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no], > ["$llvm_prefix/bin"]) > else > -AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no]) > +AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no]) > fi > > if test "x$LLVM_CONFIG" != xno; then > -- > 1.8.5.2 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 72895] Missing trees in flightgear 2.12.1 with r600 driver and mesa 10.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=72895 Igor Gnatenko changed: What|Removed |Added CC||i.gnatenko.br...@gmail.com -- 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 72895] Missing trees in flightgear 2.12.1 with r600 driver and mesa 10.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=72895 Alex Deucher changed: What|Removed |Added CC||e...@anholt.net -- 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
