Re: [Mesa-dev] [PATCH] st/mesa: fix handling of vertex array double inputs
On Sat, Aug 26, 2017 at 9:42 PM, Ilia Mirkin wrote: > The is_double_vertex_input needs to be set for arrays of doubles as > well. > > Fixes KHR-GL45.enhanced_layouts.varying_array_locations > > Signed-off-by: Ilia Mirkin > Cc: mesa-sta...@lists.freedesktop.org > --- > src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp > b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp > index 9f021962e40..49e97004703 100644 > --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp > +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp > @@ -2718,7 +2718,7 @@ glsl_to_tgsi_visitor::visit(ir_dereference_variable *ir) > > this->result = st_src_reg(entry->file, entry->index, var->type, > entry->component, entry->array_id); > - if (this->shader->Stage == MESA_SHADER_VERTEX && var->data.mode == > ir_var_shader_in && var->type->is_double()) > + if (this->shader->Stage == MESA_SHADER_VERTEX && var->data.mode == > ir_var_shader_in && var->type->without_array()->is_double()) Maybe fix up the style and line wrap this while you're changing it? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: fix handling of vertex array double inputs
The is_double_vertex_input needs to be set for arrays of doubles as well. Fixes KHR-GL45.enhanced_layouts.varying_array_locations Signed-off-by: Ilia Mirkin Cc: mesa-sta...@lists.freedesktop.org --- src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp index 9f021962e40..49e97004703 100644 --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp @@ -2718,7 +2718,7 @@ glsl_to_tgsi_visitor::visit(ir_dereference_variable *ir) this->result = st_src_reg(entry->file, entry->index, var->type, entry->component, entry->array_id); - if (this->shader->Stage == MESA_SHADER_VERTEX && var->data.mode == ir_var_shader_in && var->type->is_double()) + if (this->shader->Stage == MESA_SHADER_VERTEX && var->data.mode == ir_var_shader_in && var->type->without_array()->is_double()) this->result.is_double_vertex_input = true; if (!native_integers) this->result.type = GLSL_TYPE_FLOAT; -- 2.13.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: fix counting of vertex shader output slots used by explicit vars
The argument to count_attribute_slots should only be set to true for
vertex inputs, not for all vertex shader varyings.
Fixes KHR-GL45.enhanced_layouts.varying_locations
Signed-off-by: Ilia Mirkin
Cc: mesa-sta...@lists.freedesktop.org
---
src/compiler/glsl/link_varyings.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/compiler/glsl/link_varyings.cpp
b/src/compiler/glsl/link_varyings.cpp
index 6c9a3d12d1d..528506fd0eb 100644
--- a/src/compiler/glsl/link_varyings.cpp
+++ b/src/compiler/glsl/link_varyings.cpp
@@ -2072,7 +2072,8 @@ reserved_varying_slot(struct gl_linked_shader *stage,
var_slot = var->data.location - VARYING_SLOT_VAR0;
unsigned num_elements = get_varying_type(var, stage->Stage)
- ->count_attribute_slots(stage->Stage == MESA_SHADER_VERTEX);
+ ->count_attribute_slots(io_mode == ir_var_shader_in &&
+ stage->Stage == MESA_SHADER_VERTEX);
for (unsigned i = 0; i < num_elements; i++) {
if (var_slot >= 0 && var_slot < MAX_VARYINGS_INCL_PATCH)
slots |= UINT64_C(1) << var_slot;
--
2.13.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] util: add stringbuf library
Plowed through it a couple times, and it looks solid to me.
After thinking through it a couple times it seems like this
should be more performant than my modification of Vladislav's
original implementation. Would be nice to see a performance
comparison though. I'll try to get some numbers up for it.
In the meantime, you can have my:
Reviewed-by: Thomas Helland
2017-08-26 14:11 GMT+00:00 Nicolai Hähnle :
> From: Nicolai Hähnle
>
> For building long strings by successive append operations.
> ---
> src/util/Makefile.sources | 2 +
> src/util/stringbuf.c | 185
> ++
> src/util/stringbuf.h | 97
> 3 files changed, 284 insertions(+)
> create mode 100644 src/util/stringbuf.c
> create mode 100644 src/util/stringbuf.h
>
> diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
> index 3315285f05e..b7744fe8cb0 100644
> --- a/src/util/Makefile.sources
> +++ b/src/util/Makefile.sources
> @@ -32,20 +32,22 @@ MESA_UTIL_FILES := \
> rgtc.c \
> rgtc.h \
> rounding.h \
> set.c \
> set.h \
> simple_list.h \
> slab.c \
> slab.h \
> string_to_uint_map.cpp \
> string_to_uint_map.h \
> + stringbuf.c \
> + stringbuf.h \
> strndup.h \
> strtod.c \
> strtod.h \
> texcompress_rgtc_tmp.h \
> u_atomic.c \
> u_atomic.h \
> u_dynarray.h \
> u_endian.h \
> u_queue.c \
> u_queue.h \
> diff --git a/src/util/stringbuf.c b/src/util/stringbuf.c
> new file mode 100644
> index 000..b9a2a624fb5
> --- /dev/null
> +++ b/src/util/stringbuf.c
> @@ -0,0 +1,185 @@
> +/*
> + * Copyright 2017 Advanced Micro Devices, Inc.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * on the rights to use, copy, modify, merge, publish, distribute, sub
> + * license, 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 NON-INFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHOR(S) AND/OR THEIR SUPPLIERS 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 "stringbuf.h"
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ralloc.h"
> +#include "u_string.h"
> +
> +struct stringbuf_chunk {
> + struct stringbuf_chunk *next;
> + unsigned len, max;
> + char buf[];
> +};
> +
> +struct stringbuf {
> + struct stringbuf_chunk *head;
> + struct stringbuf_chunk *tail;
> + unsigned size;
> + bool error;
> +};
> +
> +
> +struct stringbuf *
> +stringbuf_new(void *parent)
> +{
> + static const unsigned initial_max = 512;
> + struct stringbuf *sb = rzalloc_size(parent, sizeof(*sb));
> + if (!sb)
> + return NULL;
> +
> + sb->head = sb->tail = ralloc_size(sb, sizeof(*sb->head) + initial_max);
> + if (!sb->head) {
> + ralloc_free(sb);
> + return NULL;
> + }
> + sb->head->next = NULL;
> + sb->head->len = 0;
> + sb->head->max = initial_max;
> + return sb;
> +}
> +
> +char *
> +stringbuf_build(struct stringbuf *sb)
> +{
> + if (sb->error)
> + return NULL;
> +
> + char *result = ralloc_size(ralloc_parent(sb), sb->size + 1);
> + char *p = result;
> +
> + for (struct stringbuf_chunk *chunk = sb->head; chunk; chunk =
> chunk->next) {
> + memcpy(p, chunk->buf, chunk->len);
> + p += chunk->len;
> + }
> + assert(p - result == sb->size);
> + *p = 0;
> +
> + return result;
> +}
> +
> +bool
> +stringbuf_error(struct stringbuf *sb)
> +{
> + return sb->error;
> +}
> +
> +static struct stringbuf_chunk *
> +stringbuf_new_chunk(struct stringbuf *sb, size_t min_size)
> +{
> + size_t size = MAX3(min_size, sb->tail->max, sb->size / 4);
> + if (UINT_MAX - sb->size < size) {
> + sb->error = true;
> + return NULL;
> + }
> +
> + struct stringbuf_chunk *chunk = ralloc_size(sb, sizeof(*chunk) + size);
> + if (!chunk) {
> + sb->error = true;
> + return NULL;
> + }
> +
> + chunk->next = NULL;
> + chunk->len = 0;
> + chunk->max = size;
> +
> + sb->tail->next = chunk;
> + sb->tail = chunk;
> + return chunk;
> +}
> +
> +bool
> +stringbuf_app
Re: [Mesa-dev] [PATCH 0/2] glsl: avoid quadratic behavior during preprocessing
Hi, I haven't looked to closely into this series yet. Just thought I'd point out this series I wrote back in May, in case you didn't see it, or remembered it. I haven't gotten around to finishing it (whats left is porting the tests to gtest). The implementation should be fine though; I've put it through quite some testing. At a quick glance it seems this solution is more involved. I'm not sure if my stringbuffer implementation has the same advantage of low memory usage when running through address sanitizer. It will likely help a bit, but not to the extent your implementation does. What do you think? Regards, Thomas 2017-08-26 14:11 GMT+00:00 Nicolai Hähnle : > Hi all, > > The GLSL preprocessor operates by successively appending preprocessed > pieces to a string via ralloc_str_append and friends. Each of these > functions calls realloc() every time it is used, which is potentially > quadratic behavior. > > This doesn't seem to be a problem usually because the system allocator > can avoid copies most of the time. But when building with the address > sanitizer, realloc actually copies the memory every single time, and > both time spent in memcpy() and total memory usage goes through the > roof (according to top, arb_shader_atomic_counters-max-counters uses a > cool 2.5GB of RAM when asan is enabled, which is how this came to my > attention in the first place). > > This series adds a simple stringbuf utility which implements appends > by internally keeping a linked list of buffers that are then concatenated > once at the end. > > It doesn't seem to be worth the effort to modify other users of the > ralloc append functions, since most of them only concatenate a small > number of pieces. > > Please review! > Thanks, > Nicolai > -- > src/compiler/glsl/glcpp/glcpp-parse.y | 99 + > src/compiler/glsl/glcpp/glcpp.h | 7 +- > src/compiler/glsl/glcpp/pp.c | 45 +++--- > src/util/Makefile.sources | 2 + > src/util/stringbuf.c | 185 > src/util/stringbuf.h | 97 + > 6 files changed, 343 insertions(+), 92 deletions(-) > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 12/47] i965/fs: Add brw_reg_type_from_bit_size utility method
On Thu, Aug 24, 2017 at 6:54 AM, Alejandro Piñeiro
wrote:
> Returns the brw_type for a given ssa.bit_size, and a reference type.
> So if bit_size is 64, and the reference type is BRW_REGISTER_TYPE_F,
> it returns BRW_REGISTER_TYPE_DF. The same applies if bit_size is 32
> and reference type is BRW_REGISTER_TYPE_HF it returns BRW_REGISTER_TYPE_F
>
> Signed-off-by: Jose Maria Casanova Crespo
> Signed-off-by: Alejandro Piñeiro ---
> src/intel/compiler/brw_fs_nir.cpp | 67 ++
> ++---
> 1 file changed, 62 insertions(+), 5 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index d760946e624..e4eba1401f8 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -214,6 +214,63 @@ fs_visitor::nir_emit_system_values()
> }
> }
>
> +/*
> + * Returns a type based on a reference_type (word, float, half-float) and
> a
> + * given bit_size.
> + *
> + * Reference BRW_REGISTER_TYPE are HF,F,DF,W,D,UW,UD.
> + *
> + * @FIXME: 64-bit return types are always DF on integer types to maintain
> + * compability with uses of DF previously to the introduction of int64
> + * support.
> + */
> +static brw_reg_type
> +brw_reg_type_from_bit_size(const unsigned bit_size,
> + const brw_reg_type reference_type)
> +{
> + switch(reference_type) {
> + case BRW_REGISTER_TYPE_HF:
> + case BRW_REGISTER_TYPE_F:
> + case BRW_REGISTER_TYPE_DF:
> + switch(bit_size) {
> + case 16:
> + return BRW_REGISTER_TYPE_HF;
> + case 32:
> + return BRW_REGISTER_TYPE_F;
> + case 64:
> + return BRW_REGISTER_TYPE_DF;
> + default:
> + unreachable("Not reached");
>
Please add something more descriptive here such as "Invalid bit size"
> + }
> + case BRW_REGISTER_TYPE_W:
> + case BRW_REGISTER_TYPE_D:
>
Please add the Q type
> + switch(bit_size) {
> + case 16:
> + return BRW_REGISTER_TYPE_W;
> + case 32:
> + return BRW_REGISTER_TYPE_D;
> + case 64:
> + return BRW_REGISTER_TYPE_DF;
> + default:
> + unreachable("Not reached");
>
Better message
> + }
> + case BRW_REGISTER_TYPE_UW:
> + case BRW_REGISTER_TYPE_UD:
>
Please add the UQ type
> + switch(bit_size) {
> + case 16:
> + return BRW_REGISTER_TYPE_UW;
> + case 32:
> + return BRW_REGISTER_TYPE_UD;
> + case 64:
> + return BRW_REGISTER_TYPE_DF;
> + default:
> + unreachable("Not reached");
>
better message
> + }
> + default:
> + unreachable("Not reached");
>
better message
I've got all those fixes in a version of this patch I pulled into my
subgroups tree.
> + }
> +}
> +
> void
> fs_visitor::nir_emit_impl(nir_function_impl *impl)
> {
> @@ -227,7 +284,7 @@ fs_visitor::nir_emit_impl(nir_function_impl *impl)
> reg->num_array_elems == 0 ? 1 : reg->num_array_elems;
>unsigned size = array_elems * reg->num_components;
>const brw_reg_type reg_type =
> - reg->bit_size == 32 ? BRW_REGISTER_TYPE_F : BRW_REGISTER_TYPE_DF;
> + brw_reg_type_from_bit_size(reg->bit_size, BRW_REGISTER_TYPE_F);
>nir_locals[reg->index] = bld.vgrf(reg_type, size);
> }
>
> @@ -1338,7 +1395,7 @@ fs_visitor::nir_emit_load_const(const fs_builder
> &bld,
> nir_load_const_instr *instr)
> {
> const brw_reg_type reg_type =
> - instr->def.bit_size == 32 ? BRW_REGISTER_TYPE_D :
> BRW_REGISTER_TYPE_DF;
> + brw_reg_type_from_bit_size(instr->def.bit_size,
> BRW_REGISTER_TYPE_D);
> fs_reg reg = bld.vgrf(reg_type, instr->def.num_components);
>
> switch (instr->def.bit_size) {
> @@ -1366,8 +1423,8 @@ fs_visitor::get_nir_src(const nir_src &src)
> fs_reg reg;
> if (src.is_ssa) {
>if (src.ssa->parent_instr->type == nir_instr_type_ssa_undef) {
> - const brw_reg_type reg_type = src.ssa->bit_size == 32 ?
> -BRW_REGISTER_TYPE_D : BRW_REGISTER_TYPE_DF;
> + const brw_reg_type reg_type =
> +brw_reg_type_from_bit_size(src.ssa->bit_size,
> BRW_REGISTER_TYPE_D);
> reg = bld.vgrf(reg_type, src.ssa->num_components);
>} else {
> reg = nir_ssa_values[src.ssa->index];
> @@ -1401,7 +1458,7 @@ fs_visitor::get_nir_dest(const nir_dest &dest)
> {
> if (dest.is_ssa) {
>const brw_reg_type reg_type =
> - dest.ssa.bit_size == 32 ? BRW_REGISTER_TYPE_F :
> BRW_REGISTER_TYPE_DF;
> + brw_reg_type_from_bit_size(dest.ssa.bit_size,
> BRW_REGISTER_TYPE_F);
>nir_ssa_values[dest.ssa.index] =
> bld.vgrf(reg_type, dest.ssa.num_components);
>return nir_ssa_values[dest.ssa.index];
> --
> 2.11.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
__
Re: [Mesa-dev] [PATCH] util: move string_to_uint_map to glsl
Reviewed-by: Jason Ekstrand
On Fri, Aug 25, 2017 at 7:10 PM, Jason Ekstrand
wrote:
> Ack. Not a review though.
>
>
>
> On August 25, 2017 6:38:46 PM Emil Velikov
> wrote:
>
> From: Emil Velikov
>>
>> The functionality is used by glsl and mesa. With the latter already
>> depending on the former.
>>
>> With this in place the src/util/ static library libmesautil.la no longer
>> has a C++ dependency. Thus objects which use it (like libEGL) don't need
>> the C++ link.
>>
>> Cc: Jason Ekstrand
>> Suggested-by: Jason Ekstrand
>> Cc: "17.2"
>> Fixes: 02cc35937277 ("egl/wayland: Use linux-dmabuf interface for
>> buffers")
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101851
>> Signed-off-by: Emil Velikov
>> ---
>> src/compiler/Makefile.sources | 4 +++-
>> src/compiler/glsl/link_uniform_initializers.cpp | 2 +-
>> src/compiler/glsl/link_uniforms.cpp | 2 +-
>> src/compiler/glsl/linker.cpp | 2 +-
>> src/compiler/glsl/shader_cache.cpp| 2 +-
>> src/compiler/glsl/standalone.cpp | 2 +-
>> src/{util => compiler/glsl}/string_to_uint_map.cpp| 0
>> src/{util => compiler/glsl}/string_to_uint_map.h | 0
>> src/compiler/glsl/tests/set_uniform_initializer_tests.cpp | 2 +-
>> src/mesa/main/shader_query.cpp| 2 +-
>> src/mesa/main/shaderobj.c | 2 +-
>> src/mesa/program/ir_to_mesa.cpp | 2 +-
>> src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
>> src/util/Makefile.sources | 2 --
>> 14 files changed, 13 insertions(+), 13 deletions(-)
>> rename src/{util => compiler/glsl}/string_to_uint_map.cpp (100%)
>> rename src/{util => compiler/glsl}/string_to_uint_map.h (100%)
>>
>> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.source
>> s
>> index 6e08dfb8448..a8309a1c592 100644
>> --- a/src/compiler/Makefile.sources
>> +++ b/src/compiler/Makefile.sources
>> @@ -140,7 +140,9 @@ LIBGLSL_FILES = \
>> glsl/program.h \
>> glsl/propagate_invariance.cpp \
>> glsl/s_expression.cpp \
>> - glsl/s_expression.h
>> + glsl/s_expression.h \
>> + glsl/string_to_uint_map.cpp \
>> + glsl/string_to_uint_map.h
>>
>> LIBGLSL_SHADER_CACHE_FILES = \
>> glsl/shader_cache.cpp \
>> diff --git a/src/compiler/glsl/link_uniform_initializers.cpp
>> b/src/compiler/glsl/link_uniform_initializers.cpp
>> index e7f9c9d8ac0..84a38793f64 100644
>> --- a/src/compiler/glsl/link_uniform_initializers.cpp
>> +++ b/src/compiler/glsl/link_uniform_initializers.cpp
>> @@ -25,7 +25,7 @@
>> #include "ir.h"
>> #include "linker.h"
>> #include "ir_uniform.h"
>> -#include "util/string_to_uint_map.h"
>> +#include "string_to_uint_map.h"
>>
>> /* These functions are put in a "private" namespace instead of being
>> marked
>> * static so that the unit tests can access them. See
>> diff --git a/src/compiler/glsl/link_uniforms.cpp
>> b/src/compiler/glsl/link_uniforms.cpp
>> index 1b87c5860b6..99b171d7881 100644
>> --- a/src/compiler/glsl/link_uniforms.cpp
>> +++ b/src/compiler/glsl/link_uniforms.cpp
>> @@ -27,7 +27,7 @@
>> #include "ir_uniform.h"
>> #include "glsl_symbol_table.h"
>> #include "program.h"
>> -#include "util/string_to_uint_map.h"
>> +#include "string_to_uint_map.h"
>> #include "ir_array_refcount.h"
>>
>> /**
>> diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
>> index b4784c51199..90c1084c50f 100644
>> --- a/src/compiler/glsl/linker.cpp
>> +++ b/src/compiler/glsl/linker.cpp
>> @@ -75,7 +75,7 @@
>> #include "program/program.h"
>> #include "util/mesa-sha1.h"
>> #include "util/set.h"
>> -#include "util/string_to_uint_map.h"
>> +#include "string_to_uint_map.h"
>> #include "linker.h"
>> #include "link_varyings.h"
>> #include "ir_optimization.h"
>> diff --git a/src/compiler/glsl/shader_cache.cpp
>> b/src/compiler/glsl/shader_cache.cpp
>> index cc4d24482d9..887b8954c51 100644
>> --- a/src/compiler/glsl/shader_cache.cpp
>> +++ b/src/compiler/glsl/shader_cache.cpp
>> @@ -59,7 +59,7 @@
>> #include "program.h"
>> #include "shader_cache.h"
>> #include "util/mesa-sha1.h"
>> -#include "util/string_to_uint_map.h"
>> +#include "string_to_uint_map.h"
>>
>> extern "C" {
>> #include "main/enums.h"
>> diff --git a/src/compiler/glsl/standalone.cpp
>> b/src/compiler/glsl/standalone.cpp
>> index 52554bb92a2..7a84ca72212 100644
>> --- a/src/compiler/glsl/standalone.cpp
>> +++ b/src/compiler/glsl/standalone.cpp
>> @@ -36,7 +36,7 @@
>> #include "loop_analysis.h"
>> #include "standalone_scaffolding.h"
>> #include "standalone.h"
>> -#include "util/string_to_uint_map.h"
>> +#include "string_to_uint_map.h"
>> #include "util/set.h"
>> #include "linker.h"
>> #include "glsl_parser_extras.h"
>> diff --git a/src/util/string_to_uint_map.cpp
>> b/src/compiler/glsl/string_to_ui
Re: [Mesa-dev] [PATCH] util: only use SCHED_IDLE in pthread_setschedparam() when it's defined
On 26/08/17 16:09, srol...@vmware.com wrote:
From: Roland Scheidegger
Fixes build error when it's not.
---
src/util/u_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/u_queue.c b/src/util/u_queue.c
index 49361c3..449da7d 100644
--- a/src/util/u_queue.c
+++ b/src/util/u_queue.c
@@ -246,7 +246,7 @@ util_queue_init(struct util_queue *queue,
}
if (flags & UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY) {
- #if defined(__linux__)
+ #if defined(__linux__) && defined(SCHED_IDLE)
struct sched_param sched_param = {0};
/* The nice() function can only set a maximum of 19.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] util: only use SCHED_IDLE in pthread_setschedparam() when it's defined
From: Roland Scheidegger
Fixes build error when it's not.
---
src/util/u_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/u_queue.c b/src/util/u_queue.c
index 49361c3..449da7d 100644
--- a/src/util/u_queue.c
+++ b/src/util/u_queue.c
@@ -246,7 +246,7 @@ util_queue_init(struct util_queue *queue,
}
if (flags & UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY) {
- #if defined(__linux__)
+ #if defined(__linux__) && defined(SCHED_IDLE)
struct sched_param sched_param = {0};
/* The nice() function can only set a maximum of 19.
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TGSI 16-bit support
On 26.08.2017 00:46, Timothy Arceri wrote: On 26/08/17 00:50, Nicolai Hähnle wrote: On 25.08.2017 13:58, Marek Olšák wrote: Nicolai, Have you thought about switching to NIR for radeonsi completely to get 16-bit support? We need NIR support anyway for spirv, right? Would be it be easier than adding 16-bit support into TGSI, glsl2tgsi, and tgsi2llvm? Well. What's missing from the NIR path is: (1) GS and tess (the ABI parts only) (2) re-adding some minor extensions (shader_group_vote?) (3) fixing all the bugs -- it's been a while since I've done a piglit comparison There's a bunch of unknowns, so it's hard to say, but once we're there 16-bit should be much easier, so may be worth it. Hi Nicolai, Do you have a branch somewhere with your latest work on this? Or is it all in Mesa currently? I tried to run master on shader-db to see if the NIR path gave us any big changes either way. However I had to stop it as it hit 11GB of mem and rising. Not sure yet if this was a memleak, or we got stuck in a loop somewhere. I currently have no pending NIR-only patches. There's a bunch of experimental SPIR-V stuff that needs rebasing, but nothing that should affect the standard GLSL-via-NIR path. Cheers, Nicolai Cheers, Nicolai -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/query: init result data with 0
On Sat, Aug 26, 2017 at 3:49 AM, Karol Herbst wrote: > On Sat, Aug 26, 2017 at 3:36 AM, Ilia Mirkin wrote: >> On Fri, Aug 25, 2017 at 8:23 PM, Karol Herbst wrote: >>> On Sat, Aug 26, 2017 at 1:38 AM, Ilia Mirkin wrote: On Fri, Aug 25, 2017 at 7:37 PM, Karol Herbst wrote: > On Sat, Aug 26, 2017 at 1:30 AM, Ilia Mirkin wrote: >> Why is this necessary? If data is not initialized, then presumably >> pipe->get_query_result will have returned false. >> > > but it didn't. It might be the drivers fault (in my case nouveau) that > it writes garbage or nothing into data. Where it is most likely the > latter. Sounds like a nouveau bug then. >>> >>> looks like nouveau never writes to >>> result->pipeline_statistics.cs_invocations, because it only writes >>> into the first 10 fields leaving out this 11th one. >> >> Right. We don't support CS invocations. Can't say I'm entirely sure >> how to implement it. And unfortunately mmt traces that involve compute >> don't always decode properly. >> >> I don't think there's a hw counter, so you have to do something >> clever. Like keep track of it in a scratch method for QBO and in a >> counter on the cpu side? >> > > Okay, but I would handle this as a separate issue. Returning 0 for > unsupported counters sounds better than returning random values and > even if a driver doesn't actually write into such a value, it either > means it is unsupported or it has a bug writing to it, which would be > caught debugging with the other tests. We could also require the > driver to do that, but I prefer to do this globally for all drivers. A driver that leaves the value uninitialized is a broken driver. st/mesa does not paper over brokenness. If it had, you'd never have noticed this issue in the first place, since it was valgrind that alerted you to it. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] util: add stringbuf library
From: Nicolai Hähnle
For building long strings by successive append operations.
---
src/util/Makefile.sources | 2 +
src/util/stringbuf.c | 185 ++
src/util/stringbuf.h | 97
3 files changed, 284 insertions(+)
create mode 100644 src/util/stringbuf.c
create mode 100644 src/util/stringbuf.h
diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
index 3315285f05e..b7744fe8cb0 100644
--- a/src/util/Makefile.sources
+++ b/src/util/Makefile.sources
@@ -32,20 +32,22 @@ MESA_UTIL_FILES := \
rgtc.c \
rgtc.h \
rounding.h \
set.c \
set.h \
simple_list.h \
slab.c \
slab.h \
string_to_uint_map.cpp \
string_to_uint_map.h \
+ stringbuf.c \
+ stringbuf.h \
strndup.h \
strtod.c \
strtod.h \
texcompress_rgtc_tmp.h \
u_atomic.c \
u_atomic.h \
u_dynarray.h \
u_endian.h \
u_queue.c \
u_queue.h \
diff --git a/src/util/stringbuf.c b/src/util/stringbuf.c
new file mode 100644
index 000..b9a2a624fb5
--- /dev/null
+++ b/src/util/stringbuf.c
@@ -0,0 +1,185 @@
+/*
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * on the rights to use, copy, modify, merge, publish, distribute, sub
+ * license, 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 NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHOR(S) AND/OR THEIR SUPPLIERS 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 "stringbuf.h"
+
+#include
+#include
+#include
+#include
+
+#include "ralloc.h"
+#include "u_string.h"
+
+struct stringbuf_chunk {
+ struct stringbuf_chunk *next;
+ unsigned len, max;
+ char buf[];
+};
+
+struct stringbuf {
+ struct stringbuf_chunk *head;
+ struct stringbuf_chunk *tail;
+ unsigned size;
+ bool error;
+};
+
+
+struct stringbuf *
+stringbuf_new(void *parent)
+{
+ static const unsigned initial_max = 512;
+ struct stringbuf *sb = rzalloc_size(parent, sizeof(*sb));
+ if (!sb)
+ return NULL;
+
+ sb->head = sb->tail = ralloc_size(sb, sizeof(*sb->head) + initial_max);
+ if (!sb->head) {
+ ralloc_free(sb);
+ return NULL;
+ }
+ sb->head->next = NULL;
+ sb->head->len = 0;
+ sb->head->max = initial_max;
+ return sb;
+}
+
+char *
+stringbuf_build(struct stringbuf *sb)
+{
+ if (sb->error)
+ return NULL;
+
+ char *result = ralloc_size(ralloc_parent(sb), sb->size + 1);
+ char *p = result;
+
+ for (struct stringbuf_chunk *chunk = sb->head; chunk; chunk = chunk->next) {
+ memcpy(p, chunk->buf, chunk->len);
+ p += chunk->len;
+ }
+ assert(p - result == sb->size);
+ *p = 0;
+
+ return result;
+}
+
+bool
+stringbuf_error(struct stringbuf *sb)
+{
+ return sb->error;
+}
+
+static struct stringbuf_chunk *
+stringbuf_new_chunk(struct stringbuf *sb, size_t min_size)
+{
+ size_t size = MAX3(min_size, sb->tail->max, sb->size / 4);
+ if (UINT_MAX - sb->size < size) {
+ sb->error = true;
+ return NULL;
+ }
+
+ struct stringbuf_chunk *chunk = ralloc_size(sb, sizeof(*chunk) + size);
+ if (!chunk) {
+ sb->error = true;
+ return NULL;
+ }
+
+ chunk->next = NULL;
+ chunk->len = 0;
+ chunk->max = size;
+
+ sb->tail->next = chunk;
+ sb->tail = chunk;
+ return chunk;
+}
+
+bool
+stringbuf_append(struct stringbuf *sb, const char *str, size_t str_size)
+{
+ struct stringbuf_chunk *chunk = sb->tail;
+
+ if (chunk->max - chunk->len < str_size) {
+ chunk = stringbuf_new_chunk(sb, str_size);
+ if (!chunk)
+ return false;
+ }
+
+ memcpy(chunk->buf + chunk->len, str, str_size);
+ chunk->len += str_size;
+ sb->size += str_size;
+ return true;
+}
+
+bool
+stringbuf_vprintf(struct stringbuf *sb, const char *fmt, va_list va)
+{
+ struct stringbuf_chunk *chunk = sb->tail;
+ va_list va_copy;
+ int ret, ret_retry;
+
+ va_copy(va_copy, va);
+
+ ret = util_vsnprintf(chunk->buf + chunk->len, chunk->max - chunk->len, fmt,
va);
+ if (ret < 0) {
+ sb->error = true;
+ return false
[Mesa-dev] [PATCH 2/2] glsl: use stringbuf in the preprocessor
From: Nicolai Hähnle
---
src/compiler/glsl/glcpp/glcpp-parse.y | 99 ++-
src/compiler/glsl/glcpp/glcpp.h | 7 ++-
src/compiler/glsl/glcpp/pp.c | 45 +++-
3 files changed, 59 insertions(+), 92 deletions(-)
diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y
b/src/compiler/glsl/glcpp/glcpp-parse.y
index 898a26044fa..70df98ff6e1 100644
--- a/src/compiler/glsl/glcpp/glcpp-parse.y
+++ b/src/compiler/glsl/glcpp/glcpp-parse.y
@@ -205,78 +205,72 @@ input:
;
line:
control_line
| SPACE control_line
| text_line {
_glcpp_parser_print_expanded_token_list (parser, $1);
const char *newline_str = "\n";
size_t size = strlen(newline_str);
- ralloc_str_append(&parser->output, newline_str,
- parser->output_length, size);
- parser->output_length += size;
+ stringbuf_append(parser->output, newline_str, size);
}
| expanded_line
;
expanded_line:
IF_EXPANDED expression NEWLINE {
if (parser->is_gles && $2.undefined_macro)
glcpp_error(& @1, parser, "undefined macro %s in
expression (illegal in GLES)", $2.undefined_macro);
_glcpp_parser_skip_stack_push_if (parser, & @1, $2.value);
}
| ELIF_EXPANDED expression NEWLINE {
if (parser->is_gles && $2.undefined_macro)
glcpp_error(& @1, parser, "undefined macro %s in
expression (illegal in GLES)", $2.undefined_macro);
_glcpp_parser_skip_stack_change_if (parser, & @1, "elif",
$2.value);
}
| LINE_EXPANDED integer_constant NEWLINE {
parser->has_new_line_number = 1;
parser->new_line_number = $2;
- ralloc_asprintf_rewrite_tail (&parser->output,
- &parser->output_length,
- "#line %" PRIiMAX "\n",
- $2);
+ stringbuf_printf(parser->output,
+ "#line %" PRIiMAX "\n",
+ $2);
}
| LINE_EXPANDED integer_constant integer_constant NEWLINE {
parser->has_new_line_number = 1;
parser->new_line_number = $2;
parser->has_new_source_number = 1;
parser->new_source_number = $3;
- ralloc_asprintf_rewrite_tail (&parser->output,
- &parser->output_length,
- "#line %" PRIiMAX " %" PRIiMAX
"\n",
- $2, $3);
+ stringbuf_printf(parser->output,
+ "#line %" PRIiMAX " %" PRIiMAX "\n",
+ $2, $3);
}
;
define:
OBJ_IDENTIFIER replacement_list NEWLINE {
_define_object_macro (parser, & @1, $1, $2);
}
| FUNC_IDENTIFIER '(' ')' replacement_list NEWLINE {
_define_function_macro (parser, & @1, $1, NULL, $4);
}
| FUNC_IDENTIFIER '(' identifier_list ')' replacement_list NEWLINE {
_define_function_macro (parser, & @1, $1, $3, $5);
}
;
control_line:
control_line_success {
const char *newline_str = "\n";
size_t size = strlen(newline_str);
- ralloc_str_append(&parser->output, newline_str,
- parser->output_length, size);
- parser->output_length += size;
+ stringbuf_append(parser->output, newline_str, size);
}
| control_line_error
| HASH_TOKEN LINE pp_tokens NEWLINE {
if (parser->skip_stack == NULL ||
parser->skip_stack->type == SKIP_NO_SKIP)
{
_glcpp_parser_expand_and_lex_from (parser,
LINE_EXPANDED, $3,
EXPANSION_MODE_IGNORE_DEFINED);
@@ -452,21 +446,21 @@ control_line_success:
| HASH_TOKEN VERSION_TOKEN version_constant IDENTIFIER NEWLINE {
if (parser->version_set) {
glcpp_error(& @1, parser, "#version must appear on the
first line");
}
_glcpp_parser_handle_version_declaration(parser, $3, $4, true);
}
| HASH_TOKEN NEWLINE {
glcpp_parser_resolve_implicit_version(parser);
}
| HASH_TOKEN PRAGMA NEWLINE {
- ralloc_asprintf_rewrite_tail (&parser->output,
&parser->output_length, "#%s", $2);
+ stringbuf_printf(parser->output, "#%s", $2);
}
;
control_line_error:
HASH_TOKEN ERROR_TOKEN NEWLINE {
glcpp_error(& @1,
[Mesa-dev] [PATCH 0/2] glsl: avoid quadratic behavior during preprocessing
Hi all, The GLSL preprocessor operates by successively appending preprocessed pieces to a string via ralloc_str_append and friends. Each of these functions calls realloc() every time it is used, which is potentially quadratic behavior. This doesn't seem to be a problem usually because the system allocator can avoid copies most of the time. But when building with the address sanitizer, realloc actually copies the memory every single time, and both time spent in memcpy() and total memory usage goes through the roof (according to top, arb_shader_atomic_counters-max-counters uses a cool 2.5GB of RAM when asan is enabled, which is how this came to my attention in the first place). This series adds a simple stringbuf utility which implements appends by internally keeping a linked list of buffers that are then concatenated once at the end. It doesn't seem to be worth the effort to modify other users of the ralloc append functions, since most of them only concatenate a small number of pieces. Please review! Thanks, Nicolai -- src/compiler/glsl/glcpp/glcpp-parse.y | 99 + src/compiler/glsl/glcpp/glcpp.h | 7 +- src/compiler/glsl/glcpp/pp.c | 45 +++--- src/util/Makefile.sources | 2 + src/util/stringbuf.c | 185 src/util/stringbuf.h | 97 + 6 files changed, 343 insertions(+), 92 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Question about implementing viewport transfer and const load in nir
Hi guys, When working on lima gp compiler, I come across two problems about inserting extra uniform and instructions in nir for the driver and don't know where's the right place to do it. So I'd like to hear your opinion and if there's other driver already did so. 1. viewport transfer lima gp needs embed viewport transfer into vertex shader, so need to insert a uniform which holds the scale and transfer and some instruction to apply the calculation to the gl_Position varying output. If do this in driver callback create_vs_state(), seems won't affect the state tracker to allocate uniform space for it, maybe add something in st_create_vp_variant()? 2. const load lima gp needs const be loaded just as uniform, so I have to allocate uniform space for them. Besides the same problem as 1 (where to do it), the const node may be eliminated after driver nir optimization and won't have a base filed as uniform. Seems some of these (space allocation) need be done in non-driver layer and some (instruction insertion and uniform base assign to const) can be done in driver. BTW. lima gp can only have one uniform buffer, so I can't just use a dedicated uniform buffer for viewport transfer and const uniform. Thanks, Qiang ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/47] WIP: fp64 support for r600g
Am Freitag, 25. August 2017, 11:25:02 CEST schrieb Marc Dietrich: > Am Donnerstag, 24. August 2017, 16:39:58 CEST schrieben Sie: > > On 24 August 2017 at 15:26, Marc Dietrich wrote: > > > Hi Elie, > > > > > > Am Mittwoch, 23. August 2017, 13:07:30 CEST schrieb Elie Tournier: > > >> From: Elie Tournier > > >> > > >> TL;DR > > >> This series is a "status update" of my work done for adding fp64 > > >> support > > >> on > > >> r600g. One of the biggest issue is due to a lake of accuracy on the rcp > > >> implementation. Divide relay on rcp. > > >> > > >> A branch is available on > > >> https://github.com/Hopetech/mesa/tree/glsl_arb_gpu_shader_fp64_v3 > > >> Comments > > >> and reviews are welcome. > > > > > > what are the hardware requirements for testing this? R600g is a wide > > > range > > > ... > > > > Hello Marc, > > > > My code targets all the cards who doesn't support double but who > > support GLSL 1.30: > > https://github.com/Hopetech/mesa/blob/glsl_arb_gpu_shader_fp64_v3/src/mesa > > /s tate_tracker/st_glsl_to_tgsi.cpp#L7059 > > > > So iirc, all r600g cards. > > sorry, I was confused by the glewinfo which shows > GL_ARB_gpu_shader_fp64: OK [MISSING] > with and without your patches, but glxinfo gets it right. > > This is on an RS780 (HD3200?) integrated gpu. > > running: > # ./piglit-run.py --dmesg --abort-on-monitored-error -s -l verbose -1 -t > arb_gpu_shader_fp64 all results/fp64 > > gives ~70% crashes until the system hard locks (or reboots) at some point. > > Maybe it had also problems before running some shaders, so it is not > necessary a result of your work. > > Because this is a very old platform which will never be able to see GL4, I > don't take this result too serious. > > I will redo the tests until it hard locks, so you can get at least a partial > result. not many results, lots of crash, too many gpu lockups ... http://goo.gl/dhEbEb signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 101851] [regression] libEGL_common.a undefined reference to '__gxx_personality_v0'
https://bugs.freedesktop.org/show_bug.cgi?id=101851 --- Comment #8 from James Harvey --- Hi Emil, I applied your patch against mesa-17.2.0_rc5 on gentoo, it fixed the build failure for me. I did a quick test with eglgears on both X11 and wayland and didn't see any problems. Thanks! -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 101851] [regression] libEGL_common.a undefined reference to '__gxx_personality_v0'
https://bugs.freedesktop.org/show_bug.cgi?id=101851 --- Comment #7 from Emil Velikov --- (In reply to Steve Arnold from comment #6) > I think one of the main problems is libtool failing to pass flags specified > by the user; note in the previous comment #5 it fails to pass > "-fuse-ld=bfd". Also, I'm assuming the upstream flag -Wl,--no-undefined is > recent otherwise this would be visible in previous versions. So I think the > real answer for now is g++ and -lstdc++ as needed, then long-term get rid of > libtool and use pkg-config instead. Just my $0.02... Most of this is off I'm afraid. I'm 99.9% sure that -fuse-ld... works correctly, since Mike uses Gentoo and they pull the following patch. http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=f9970d99293faf908fdc153a653fa5781095fb7a While the -Wl,--no-undefined flag has been around since 2014 with commit d187a150d45cbf5bd3476eab49be5057382c2c86. All, please try ti the following patch - it resolves the problem on my end. https://patchwork.freedesktop.org/patch/173778/ -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] util: inline u_vector.c within the header
On 25 August 2017 at 21:20, Emil Velikov wrote: > From: Emil Velikov > > Inlining the implementation does not cause additional overhead in > terms of build time while the binary is increased only marginally (~1k) > > At the same time the compiler should be able to optimise better, although > this is not a path where we'll notice much difference. > > Use a local u_is_power_of_two to avoid pulling u_math.h. Latter of > which would require updating 5+ locations to have an extra -I directive. > > Doing this will allow us to address a unrelated issue, as mentioned in > the report below. > > Cc: "17.2" > Cc: Daniel Stone > Cc: Jason Ekstrand > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101851 > Signed-off-by: Emil Velikov Note this patch and 2/2 are effectively superseded by the following. https://patchwork.freedesktop.org/patch/173778/ -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/docs: fix a typo
Signed-off-by: Mun Gwan-gyeong --- src/gallium/docs/source/context.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/docs/source/context.rst b/src/gallium/docs/source/context.rst index 7002802248..6ac45819a6 100644 --- a/src/gallium/docs/source/context.rst +++ b/src/gallium/docs/source/context.rst @@ -118,7 +118,7 @@ If texture format is different than template format, it is said the texture is being cast to another format. Casting can be done only between compatible formats, that is formats that have matching component order and sizes. -Swizzle fields specify they way in which fetched texel components are placed +Swizzle fields specify the way in which fetched texel components are placed in the result register. For example, ``swizzle_r`` specifies what is going to be placed in first component of result register. -- 2.14.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 102318] Mesa3D Scons build - LLVM 5.0 not supported
https://bugs.freedesktop.org/show_bug.cgi?id=102318 Alex Granni changed: What|Removed |Added CC||jfons...@vmware.com -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 102318] Mesa3D Scons build - LLVM 5.0 not supported
https://bugs.freedesktop.org/show_bug.cgi?id=102318 Alex Granni changed: What|Removed |Added CC||genpfa...@gmail.com -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/query: init result data with 0
On Sat, Aug 26, 2017 at 3:36 AM, Ilia Mirkin wrote: > On Fri, Aug 25, 2017 at 8:23 PM, Karol Herbst wrote: >> On Sat, Aug 26, 2017 at 1:38 AM, Ilia Mirkin wrote: >>> On Fri, Aug 25, 2017 at 7:37 PM, Karol Herbst wrote: On Sat, Aug 26, 2017 at 1:30 AM, Ilia Mirkin wrote: > Why is this necessary? If data is not initialized, then presumably > pipe->get_query_result will have returned false. > but it didn't. It might be the drivers fault (in my case nouveau) that it writes garbage or nothing into data. Where it is most likely the latter. >>> >>> Sounds like a nouveau bug then. >> >> looks like nouveau never writes to >> result->pipeline_statistics.cs_invocations, because it only writes >> into the first 10 fields leaving out this 11th one. > > Right. We don't support CS invocations. Can't say I'm entirely sure > how to implement it. And unfortunately mmt traces that involve compute > don't always decode properly. > > I don't think there's a hw counter, so you have to do something > clever. Like keep track of it in a scratch method for QBO and in a > counter on the cpu side? > Okay, but I would handle this as a separate issue. Returning 0 for unsupported counters sounds better than returning random values and even if a driver doesn't actually write into such a value, it either means it is unsupported or it has a bug writing to it, which would be caught debugging with the other tests. We could also require the driver to do that, but I prefer to do this globally for all drivers. > -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
