Re: [Mesa-dev] [PATCH 1/2] android: anv: fix generated files depedencies
Mauro Rossi 於 2019年3月4日 週一 上午3:58寫道：
>
> Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
> Rename the variable labels according to targets and python scripts
> Align the building rules as per Automake for simplification
>
> Fixes building errors during rebuils due to missing dependencies
>
> Fixes: 9a508b7 ("android: anv/extensions: fix generated sources build")
> Fixes: dd088d4bec7 ("anv/extensions: Generate a header file with extension
> tables")
> Signed-off-by: Mauro Rossi
> Cc: "19.0"
> ---
> src/intel/Android.vulkan.mk | 38 +++--
> 1 file changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
> index 04c9d5b3e4..2e99ac6294 100644
> --- a/src/intel/Android.vulkan.mk
> +++ b/src/intel/Android.vulkan.mk
> @@ -23,9 +23,10 @@ LOCAL_PATH := $(call my-dir)
> include $(CLEAR_VARS)
> include $(LOCAL_PATH)/Makefile.sources
>
> -VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2)
> $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
> -
> -VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2)
> $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
> +ANV_ENTRYPOINTS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
> +ANV_EXTENSIONS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
> +ANV_EXTENSIONS_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions.py
> +VULKAN_API_XML := $(MESA_TOP)/src/vulkan/registry/vk.xml
>
> VULKAN_COMMON_INCLUDES := \
> $(MESA_TOP)/include \
> @@ -64,10 +65,13 @@ $(intermediates)/vulkan/dummy.c:
> @echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
> $(hide) touch $@
>
> -$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c
> - $(VK_ENTRYPOINTS_SCRIPT) \
> +$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c \
I know it was not introduced in this patch.
However, it makes no sense to let the header depend on a generated empty file.
This should be removed.
> + $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
> + $(ANV_EXTENSIONS_SCRIPT) \
> + $(VULKAN_API_XML)
> + $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
> --outdir $(dir $@) \
> - --xml $(MESA_TOP)/src/vulkan/registry/vk.xml
> + --xml $(VULKAN_API_XML)
>
> LOCAL_EXPORT_C_INCLUDE_DIRS := \
> $(intermediates)
> @@ -241,22 +245,28 @@ LOCAL_GENERATED_SOURCES +=
> $(intermediates)/vulkan/anv_entrypoints.c
> LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.c
> LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.h
>
> -$(intermediates)/vulkan/anv_entrypoints.c:
> +$(intermediates)/vulkan/anv_entrypoints.c: $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
> + $(ANV_EXTENSIONS_SCRIPT) \
> + $(VULKAN_API_XML)
> @mkdir -p $(dir $@)
> - $(VK_ENTRYPOINTS_SCRIPT) \
> + $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
> --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
> --outdir $(dir $@)
>
> -$(intermediates)/vulkan/anv_extensions.c:
> +$(intermediates)/vulkan/anv_extensions.c: $(ANV_EXTENSIONS_GEN_SCRIPT) \
> + $(ANV_EXTENSIONS_SCRIPT) \
> + $(VULKAN_API_XML)
> @mkdir -p $(dir $@)
> - $(VK_EXTENSIONS_SCRIPT) \
> - --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
> + $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
> + --xml $(VULKAN_API_XML) \
> --out-c $@
>
> -$(intermediates)/vulkan/anv_extensions.h:
> +$(intermediates)/vulkan/anv_extensions.h: $(ANV_EXTENSIONS_GEN_SCRIPT) \
> + $(ANV_EXTENSIONS_SCRIPT) \
> + $(VULKAN_API_XML)
> @mkdir -p $(dir $@)
> - $(VK_EXTENSIONS_SCRIPT) \
> - --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
> + $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
> + --xml $(VULKAN_API_XML) \
> --out-h $@
>
> LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
> --
--
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] panfrost: Add DRM backend
On 3/5/19 1:44 AM, Alyssa Rosenzweig wrote: I get roughly the same demos working with it as with Arm's driver, but there's lots of improvements to be made (mostly in the kernel) to how memory is managed and jobs are scheduled. Which demos have regressed, just so we can keep track? One is that with kbase I don't see any noticeable pauses during the very first scene in glmark2. Another is that with the DRM driver I don't see the wallpaper in GNOME Shell. But I haven't really tested much :) Cheers, Tomeu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver
On 3/5/19 3:29 AM, Dave Airlie wrote: On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg wrote: On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig wrote: Why aren't we using regular dma-buf fences here? The submit ioctl should be able to take a number of in fences to wait on and return an out fence if requested. Ah-ha, that sounds like the "proper" approach for mainline. Much of this was (incorrectly) inherited from the Arm driver. Thank you for the pointer. I'm not sure - I mean, the submit should take in/out fences, but the atom mechanism here sounds more like it's for declaring the dependencies between multiple batches in a renderpass/frame to allow the kernel to shcedule them? The sync fd may be a little to heavy handed for that, and if you want to express that kind of dependency to allow the kernel to reschedule, maybe we need both? You should more likely be using syncobjects, not fences. Yeah, so the dependency is currently expressed by the ID of the atom it depends on. This is needed in the current approach because at submit time we cannot have a fence yet for the dependency if both atoms are in the same submit. Alyssa: do you see any problem if we change to submit only one atom per ioctl? Then we would get a syncobj for the first atom that we could pass as an in-fence for any dependencies, in separate ioctls. You can convert syncobjs to fences, but fences consume an fd which you only really want if inter-device. Guess syncobj refs are akin to GEM handles and fences to dmabuf buffers from the userspace POV? Thanks, Tomeu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/8] panfrost: Fix BO import and export
On 3/5/19 1:25 AM, Alyssa Rosenzweig wrote: Reviewed-by: Alyssa Rosenzweig Out of curiosity, when would this code path be needed? Was this a problem on the non-DRM driver too, or just the new kernel which makes heavier use of real BOs? With non-DRM this code doesn't execute (at least on the workloads I tested with) because we don't support GEM handles for !scanout. Cheers, Tomeu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/8] panfrost: Free context BOs
On 3/4/19 8:52 PM, Rob Herring wrote:
On Mon, Mar 4, 2019 at 1:38 PM Alyssa Rosenzweig wrote:
unsigned transient_count =
ctx->transient_pools[ctx->cmdstream_i].entry_index*ctx->transient_pools[0].entry_size
+ ctx->transient_pools[ctx->cmdstream_i].entry_offset;
- printf("Uploaded transient %d bytes\n", transient_count);
+ //printf("Uploaded transient %d bytes\n", transient_count);
Sorry, this change slipped into this patch.
This will raised an unused variable warning for transient_count, better
comment both or neither.
Better yet, use a debug print so it can be enabled via an env var. Or
if it's not that useful, just remove it.
Yeah, I couldn't tell because I don't really know what's the purpose of
this printf.
Other than that, Reviewed-by: Alyssa Rosenzweig
I wonder if this will fix some of the memory leaks on non-DRM as well.
I think it should, though it may not be that acute because of some lazy
allocations that I think kbase does?
Cheers,
Tomeu
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 34/40] intel/compiler: validate region restrictions for half-float conversions
On Mon, 2019-03-04 at 15:36 -0800, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Fri, 2019-03-01 at 19:04 -0800, Francisco Jerez wrote:
> > > Iago Toral writes:
> > >
> > > > On Thu, 2019-02-28 at 09:54 -0800, Francisco Jerez wrote:
> > > > > Iago Toral writes:
> > > > >
> > > > > > On Wed, 2019-02-27 at 13:47 -0800, Francisco Jerez wrote:
> > > > > > > Iago Toral writes:
> > > > > > >
> > > > > > > > On Tue, 2019-02-26 at 14:54 -0800, Francisco Jerez
> > > > > > > > wrote:
> > > > > > > > > Iago Toral Quiroga writes:
> > > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > > src/intel/compiler/brw_eu_validate.c| 64
> > > > > > > > > > -
> > > > > > > > > > src/intel/compiler/test_eu_validate.cpp | 122
> > > > > > > > > >
> > > > > > > > > > 2 files changed, 185 insertions(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/src/intel/compiler/brw_eu_validate.c
> > > > > > > > > > b/src/intel/compiler/brw_eu_validate.c
> > > > > > > > > > index 000a05cb6ac..203641fecb9 100644
> > > > > > > > > > --- a/src/intel/compiler/brw_eu_validate.c
> > > > > > > > > > +++ b/src/intel/compiler/brw_eu_validate.c
> > > > > > > > > > @@ -531,7 +531,69 @@
> > > > > > > > > > general_restrictions_based_on_operand_types(const
> > > > > > > > > > struct
> > > > > > > > > > gen_device_info *devinf
> > > > > > > > > > exec_type_size == 8 && dst_type_size == 4)
> > > > > > > > > >dst_type_size = 8;
> > > > > > > > > >
> > > > > > > > > > - if (exec_type_size > dst_type_size) {
> > > > > > > > > > + /* From the BDW+ PRM:
> > > > > > > > > > +*
> > > > > > > > > > +*"There is no direct conversion from HF to
> > > > > > > > > > DF
> > > > > > > > > > or
> > > > > > > > > > DF to
> > > > > > > > > > HF.
> > > > > > > > > > +* There is no direct conversion from HF to
> > > > > > > > > > Q/UQ or
> > > > > > > > > > Q/UQ to
> > > > > > > > > > HF."
> > > > > > > > > > +*/
> > > > > > > > > > + enum brw_reg_type src0_type =
> > > > > > > > > > brw_inst_src0_type(devinfo,
> > > > > > > > > > inst);
> > > > > > > > > > + ERROR_IF(brw_inst_opcode(devinfo, inst) ==
> > > > > > > > > > BRW_OPCODE_MOV
> > > > > > > > > > &&
> > > > > > > > >
> > > > > > > > > Why is only the MOV instruction handled here and
> > > > > > > > > below? Aren't
> > > > > > > > > other
> > > > > > > > > instructions able to do implicit
> > > > > > > > > conversions? Probably
> > > > > > > > > means
> > > > > > > > > you
> > > > > > > > > need
> > > > > > > > > to deal with two sources rather than one.
> > > > > > > >
> > > > > > > > This comes from the programming notes of the MOV
> > > > > > > > instruction
> > > > > > > > (Volume
> > > > > > > > 2a, Command Reference - Instructions - MOV), so it is
> > > > > > > > described
> > > > > > > > specifically for the MOV instruction. I should probably
> > > > > > > > have
> > > > > > > > made
> > > > > > > > this
> > > > > > > > clear in the comment.
> > > > > > > >
> > > > > > >
> > > > > > > Maybe the one above is specified in the MOV page only,
> > > > > > > probably
> > > > > > > due
> > > > > > > to
> > > > > > > an oversight (If these restrictions were really specific
> > > > > > > to
> > > > > > > the
> > > > > > > MOV
> > > > > > > instruction, what would prevent you from implementing
> > > > > > > such
> > > > > > > conversions
> > > > > > > through a different instruction? E.g. "ADD dst:df,
> > > > > > > src:hf,
> > > > > > > 0"
> > > > > > > which
> > > > > > > would be substantially more efficient than what you're
> > > > > > > doing
> > > > > > > in
> > > > > > > PATCH
> > > > > > > 02)
> > > > > >
> > > > > > Instructions that take HF can only be strictly HF or mix F
> > > > > > and
> > > > > > HF
> > > > > > (mixed mode float), with MOV being the only exception. That
> > > > > > means
> > > > > > that
> > > > > > any instruction like the one you use above are invalid.
> > > > > > Maybe
> > > > > > we
> > > > > > should
> > > > > > validate explicitly that instructions that use HF are
> > > > > > strictly
> > > > > > HF
> > > > > > or
> > > > > > mixed-float mode only?
> > > > > >
> > > > >
> > > > > So you're acknowledging that the conversions checked above
> > > > > are
> > > > > illegal
> > > > > whether the instruction is a MOV or something else. Where
> > > > > are we
> > > > > preventing instructions other than MOV with such conversions
> > > > > from
> > > > > being
> > > > > accepted by the validator?
> > > >
> > > > We aren't, because the validator is not checking, in general,
> > > > for
> > > > accepted type combinations for specific instructions anywhere
> > > > as
> > > > far as
> > > > I can see.
> > >
> > > Luckily these type conversion restrictions aren't really specific
> > > to
> > > any
> > > instruction AFAICT, even though they only seem to be mentioned
> > > explicitly for the MOV instruction...
> > >
> > > > If we want to start doing this
[Mesa-dev] [PATCH 5/5] nir: rename glsl_type_is_struct() -> glsl_type_is_struct_or_ifc()
Replace done using:
find ./src -type f -exec sed -i -- \
's/glsl_type_is_struct(/glsl_type_is_struct_or_ifc(/g' {} \;
---
src/amd/common/ac_nir_to_llvm.c | 2 +-
src/amd/vulkan/radv_nir_to_llvm.c| 2 +-
src/compiler/glsl/gl_nir_link_uniform_initializers.c | 4 ++--
src/compiler/glsl/gl_nir_link_uniforms.c | 10 +-
src/compiler/glsl/gl_nir_link_xfb.c | 2 +-
src/compiler/nir/nir_builder.h | 4 ++--
src/compiler/nir/nir_deref.c | 2 +-
src/compiler/nir/nir_gather_info.c | 4 ++--
src/compiler/nir/nir_gather_xfb_info.c | 4 ++--
src/compiler/nir/nir_linking_helpers.c | 2 +-
src/compiler/nir/nir_lower_constant_initializers.c | 2 +-
src/compiler/nir/nir_lower_io_arrays_to_elements.c | 2 +-
src/compiler/nir/nir_lower_io_to_scalar.c| 2 +-
src/compiler/nir/nir_lower_vars_to_ssa.c | 2 +-
src/compiler/nir/nir_split_per_member_structs.c | 2 +-
src/compiler/nir/nir_split_var_copies.c | 2 +-
src/compiler/nir/nir_split_vars.c| 6 +++---
src/compiler/nir/nir_validate.c | 4 ++--
src/compiler/nir_types.cpp | 2 +-
src/compiler/nir_types.h | 2 +-
src/compiler/spirv/vtn_alu.c | 8
src/compiler/spirv/vtn_glsl450.c | 4 ++--
src/compiler/spirv/vtn_variables.c | 8
src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp | 4 ++--
src/mesa/state_tracker/st_glsl_to_nir.cpp| 4 ++--
25 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 96dd9c4b96c..4598eeccb20 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3975,7 +3975,7 @@ glsl_to_llvm_type(struct ac_llvm_context *ac,
glsl_get_length(type));
}
- assert(glsl_type_is_struct(type));
+ assert(glsl_type_is_struct_or_ifc(type));
LLVMTypeRef member_types[glsl_get_length(type)];
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index a589ff41559..20371759a97 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -2268,7 +2268,7 @@ static void mark_16bit_fs_input(struct
radv_shader_context *ctx,
mark_16bit_fs_input(ctx, glsl_get_array_element(type),
location + i * stride);
}
} else {
- assert(glsl_type_is_struct(type));
+ assert(glsl_type_is_struct_or_ifc(type));
for (unsigned i = 0; i < glsl_get_length(type); i++) {
mark_16bit_fs_input(ctx, glsl_get_struct_field(type,
i), location);
location +=
glsl_count_attribute_slots(glsl_get_struct_field(type, i), false);
diff --git a/src/compiler/glsl/gl_nir_link_uniform_initializers.c
b/src/compiler/glsl/gl_nir_link_uniform_initializers.c
index 8eefa71c885..6e38d01269e 100644
--- a/src/compiler/glsl/gl_nir_link_uniform_initializers.c
+++ b/src/compiler/glsl/gl_nir_link_uniform_initializers.c
@@ -184,7 +184,7 @@ set_uniform_initializer(struct
set_uniform_initializer_closure *data,
{
const struct glsl_type *t_without_array = glsl_without_array(type);
- if (glsl_type_is_struct(type)) {
+ if (glsl_type_is_struct_or_ifc(type)) {
for (unsigned int i = 0; i < glsl_get_length(type); i++) {
const struct glsl_type *field_type = glsl_get_struct_field(type, i);
set_uniform_initializer(data, field_type, val->elements[i]);
@@ -192,7 +192,7 @@ set_uniform_initializer(struct
set_uniform_initializer_closure *data,
return;
}
- if (glsl_type_is_struct(t_without_array) ||
+ if (glsl_type_is_struct_or_ifc(t_without_array) ||
(glsl_type_is_array(type) &&
glsl_type_is_array(glsl_get_array_element(type {
const struct glsl_type *element_type = glsl_get_array_element(type);
diff --git a/src/compiler/glsl/gl_nir_link_uniforms.c
b/src/compiler/glsl/gl_nir_link_uniforms.c
index 1a491dc2e5d..e4924df0d03 100644
--- a/src/compiler/glsl/gl_nir_link_uniforms.c
+++ b/src/compiler/glsl/gl_nir_link_uniforms.c
@@ -204,7 +204,7 @@ build_type_tree_for_type(const struct glsl_type *type)
entry->array_size = glsl_get_length(type);
entry->children = build_type_tree_for_type(glsl_get_array_element(type));
entry->children->parent = entry;
- } else if (glsl_type_is_struct(type)) {
+ } else if (glsl_type_is_struct_or_ifc(type)) {
struct type_tree_entry *last = NULL;
for (unsigned i = 0; i < glsl_get_length(type); i++) {
@@ -291,10 +291,10 @@ nir_link_uniform(struct gl_context *ctx,
* composite type or an array where each element occupies more than one
[Mesa-dev] [PATCH 3/5] glsl: rename record_location_offset() -> struct_location_offset()
Replace done using:
find ./src -type f -exec sed -i -- \
's/record_location_offset(/struct_location_offset(/g' {} \;
---
src/amd/common/ac_nir_to_llvm.c| 4 ++--
src/compiler/glsl/gl_nir_lower_samplers_as_deref.c | 2 +-
src/compiler/glsl_types.cpp| 4 ++--
src/compiler/glsl_types.h | 2 +-
src/compiler/nir_types.cpp | 4 ++--
src/compiler/nir_types.h | 2 +-
src/mesa/program/ir_to_mesa.cpp| 2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index af7a95137c2..96dd9c4b96c 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3050,7 +3050,7 @@ static LLVMValueRef visit_interp(struct ac_nir_context
*ctx,
LLVMValueRef offset;
unsigned sidx = deref_instr->strct.index;
deref_instr = nir_src_as_deref(deref_instr->parent);
- offset = LLVMConstInt(ctx->ac.i32,
glsl_get_record_location_offset(deref_instr->type, sidx), false);
+ offset = LLVMConstInt(ctx->ac.i32,
glsl_get_struct_location_offset(deref_instr->type, sidx), false);
attrib_idx = LLVMBuildAdd(ctx->ac.builder, attrib_idx,
offset, "");
} else {
unreachable("Unsupported deref type");
@@ -3471,7 +3471,7 @@ static LLVMValueRef get_sampler_desc(struct
ac_nir_context *ctx,
} else if (deref_instr->deref_type ==
nir_deref_type_struct) {
unsigned sidx = deref_instr->strct.index;
deref_instr =
nir_src_as_deref(deref_instr->parent);
- constant_index +=
glsl_get_record_location_offset(deref_instr->type, sidx);
+ constant_index +=
glsl_get_struct_location_offset(deref_instr->type, sidx);
} else {
unreachable("Unsupported deref type");
}
diff --git a/src/compiler/glsl/gl_nir_lower_samplers_as_deref.c
b/src/compiler/glsl/gl_nir_lower_samplers_as_deref.c
index ea32195d42f..27e2d780e70 100644
--- a/src/compiler/glsl/gl_nir_lower_samplers_as_deref.c
+++ b/src/compiler/glsl/gl_nir_lower_samplers_as_deref.c
@@ -104,7 +104,7 @@ remove_struct_derefs_prep(nir_deref_instr **p, char **name,
}
case nir_deref_type_struct: {
- *location += glsl_get_record_location_offset(cur->type,
next->strct.index);
+ *location += glsl_get_struct_location_offset(cur->type,
next->strct.index);
ralloc_asprintf_append(name, ".%s",
glsl_get_struct_elem_name(cur->type,
next->strct.index));
diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index 24f319dbde2..bc9bf1380b2 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -1425,7 +1425,7 @@ glsl_type::component_slots() const
}
unsigned
-glsl_type::record_location_offset(unsigned length) const
+glsl_type::struct_location_offset(unsigned length) const
{
unsigned offset = 0;
const glsl_type *t = this->without_array();
@@ -1436,7 +1436,7 @@ glsl_type::record_location_offset(unsigned length) const
const glsl_type *st = t->fields.structure[i].type;
const glsl_type *wa = st->without_array();
if (wa->is_struct()) {
-unsigned r_offset = wa->record_location_offset(wa->length);
+unsigned r_offset = wa->struct_location_offset(wa->length);
offset += st->is_array() ?
st->arrays_of_arrays_size() * r_offset : r_offset;
} else if (st->is_array() && st->fields.array->is_array()) {
diff --git a/src/compiler/glsl_types.h b/src/compiler/glsl_types.h
index 2e858bf4cd7..3c675112ec1 100644
--- a/src/compiler/glsl_types.h
+++ b/src/compiler/glsl_types.h
@@ -365,7 +365,7 @@ public:
* For the initial call, length is the index of the member to find the
* offset for.
*/
- unsigned record_location_offset(unsigned length) const;
+ unsigned struct_location_offset(unsigned length) const;
/**
* Calculate the number of unique values from glGetUniformLocation for the
diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
index 5e51dbc2d90..89028dcaf3d 100644
--- a/src/compiler/nir_types.cpp
+++ b/src/compiler/nir_types.cpp
@@ -192,10 +192,10 @@ glsl_get_sampler_coordinate_components(const struct
glsl_type *type)
}
unsigned
-glsl_get_record_location_offset(const struct glsl_type *type,
+glsl_get_struct_location_offset(const struct glsl_type *type,
unsigned length)
{
- return type->record_location_offset(length);
+ return type->struct_location_offset(length);
}
bool
[Mesa-dev] [PATCH 2/5] glsl: rename get_record_instance() -> get_struct_instance()
Replace done using:
find ./src -type f -exec sed -i -- \
's/get_record_instance(/get_struct_instance(/g' {} \;
---
src/compiler/glsl/ast_to_hir.cpp| 2 +-
src/compiler/glsl/tests/array_refcount_test.cpp | 2 +-
src/compiler/glsl_types.cpp | 6 +++---
src/compiler/glsl_types.h | 2 +-
src/compiler/nir_types.cpp | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 68acf2666cc..feea92258d3 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -7581,7 +7581,7 @@ ast_struct_specifier::hir(exec_list *instructions,
validate_identifier(this->name, loc, state);
- type = glsl_type::get_record_instance(fields, decl_count, this->name);
+ type = glsl_type::get_struct_instance(fields, decl_count, this->name);
if (!type->is_anonymous() && !state->symbols->add_type(name, type)) {
const glsl_type *match = state->symbols->get_type(name);
diff --git a/src/compiler/glsl/tests/array_refcount_test.cpp
b/src/compiler/glsl/tests/array_refcount_test.cpp
index 45c204dc2f8..edd9cf42a31 100644
--- a/src/compiler/glsl/tests/array_refcount_test.cpp
+++ b/src/compiler/glsl/tests/array_refcount_test.cpp
@@ -477,7 +477,7 @@ TEST_F(array_refcount_test,
do_not_process_array_inside_structure)
};
const glsl_type *const record_of_array_3_of_int =
- glsl_type::get_record_instance(fields, ARRAY_SIZE(fields), "S");
+ glsl_type::get_struct_instance(fields, ARRAY_SIZE(fields), "S");
ir_variable *var_a = new(mem_ctx) ir_variable(glsl_type::int_type,
"a",
diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index 260b07b67fe..24f319dbde2 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -434,7 +434,7 @@ const glsl_type *glsl_type::get_bare_type() const
bare_fields[i].name = this->fields.structure[i].name;
}
const glsl_type *bare_type =
- get_record_instance(bare_fields, this->length, this->name);
+ get_struct_instance(bare_fields, this->length, this->name);
delete[] bare_fields;
return bare_type;
}
@@ -1127,7 +1127,7 @@ glsl_type::record_key_hash(const void *a)
const glsl_type *
-glsl_type::get_record_instance(const glsl_struct_field *fields,
+glsl_type::get_struct_instance(const glsl_struct_field *fields,
unsigned num_fields,
const char *name)
{
@@ -2375,7 +2375,7 @@ decode_type_from_blob(struct blob_reader *blob)
t = glsl_type::get_interface_instance(fields, num_fields, packing,
row_major, name);
} else {
- t = glsl_type::get_record_instance(fields, num_fields, name);
+ t = glsl_type::get_struct_instance(fields, num_fields, name);
}
free(fields);
diff --git a/src/compiler/glsl_types.h b/src/compiler/glsl_types.h
index 8f9a69556eb..2e858bf4cd7 100644
--- a/src/compiler/glsl_types.h
+++ b/src/compiler/glsl_types.h
@@ -312,7 +312,7 @@ public:
/**
* Get the instance of a record type
*/
- static const glsl_type *get_record_instance(const glsl_struct_field *fields,
+ static const glsl_type *get_struct_instance(const glsl_struct_field *fields,
unsigned num_fields,
const char *name);
diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
index 32b47f2b60f..5e51dbc2d90 100644
--- a/src/compiler/nir_types.cpp
+++ b/src/compiler/nir_types.cpp
@@ -486,7 +486,7 @@ const glsl_type *
glsl_struct_type(const glsl_struct_field *fields,
unsigned num_fields, const char *name)
{
- return glsl_type::get_record_instance(fields, num_fields, name);
+ return glsl_type::get_struct_instance(fields, num_fields, name);
}
const glsl_type *
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] glsl: rename record_types -> struct_types
---
src/compiler/glsl_types.cpp | 16
src/compiler/glsl_types.h | 4 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index bc9bf1380b2..50320a46e98 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -32,7 +32,7 @@
mtx_t glsl_type::hash_mutex = _MTX_INITIALIZER_NP;
hash_table *glsl_type::explicit_matrix_types = NULL;
hash_table *glsl_type::array_types = NULL;
-hash_table *glsl_type::record_types = NULL;
+hash_table *glsl_type::struct_types = NULL;
hash_table *glsl_type::interface_types = NULL;
hash_table *glsl_type::function_types = NULL;
hash_table *glsl_type::subroutine_types = NULL;
@@ -486,9 +486,9 @@ _mesa_glsl_release_types(void)
glsl_type::array_types = NULL;
}
- if (glsl_type::record_types != NULL) {
- _mesa_hash_table_destroy(glsl_type::record_types,
hash_free_type_function);
- glsl_type::record_types = NULL;
+ if (glsl_type::struct_types != NULL) {
+ _mesa_hash_table_destroy(glsl_type::struct_types,
hash_free_type_function);
+ glsl_type::struct_types = NULL;
}
if (glsl_type::interface_types != NULL) {
@@ -1135,17 +1135,17 @@ glsl_type::get_struct_instance(const glsl_struct_field
*fields,
mtx_lock(_type::hash_mutex);
- if (record_types == NULL) {
- record_types = _mesa_hash_table_create(NULL, record_key_hash,
+ if (struct_types == NULL) {
+ struct_types = _mesa_hash_table_create(NULL, record_key_hash,
record_key_compare);
}
- const struct hash_entry *entry = _mesa_hash_table_search(record_types,
+ const struct hash_entry *entry = _mesa_hash_table_search(struct_types,
);
if (entry == NULL) {
const glsl_type *t = new glsl_type(fields, num_fields, name);
- entry = _mesa_hash_table_insert(record_types, t, (void *) t);
+ entry = _mesa_hash_table_insert(struct_types, t, (void *) t);
}
assert(((glsl_type *) entry->data)->base_type == GLSL_TYPE_STRUCT);
diff --git a/src/compiler/glsl_types.h b/src/compiler/glsl_types.h
index 3c675112ec1..56e5de7cd91 100644
--- a/src/compiler/glsl_types.h
+++ b/src/compiler/glsl_types.h
@@ -954,8 +954,8 @@ private:
/** Hash table containing the known array types. */
static struct hash_table *array_types;
- /** Hash table containing the known record types. */
- static struct hash_table *record_types;
+ /** Hash table containing the known struct types. */
+ static struct hash_table *struct_types;
/** Hash table containing the known interface types. */
static struct hash_table *interface_types;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] glsl: rename is_record() -> is_struct()
Replace was done using:
find ./src -type f -exec sed -i -- \
's/is_record(/is_struct(/g' {} \;
---
src/compiler/glsl/ast_function.cpp| 4 +--
src/compiler/glsl/ast_to_hir.cpp | 22 ++--
src/compiler/glsl/glsl_parser_extras.cpp | 2 +-
src/compiler/glsl/hir_field_selection.cpp | 2 +-
src/compiler/glsl/ir.cpp | 16 -
src/compiler/glsl/ir_print_visitor.cpp| 4 +--
src/compiler/glsl/link_uniform_blocks.cpp | 4 +--
.../glsl/link_uniform_initializers.cpp| 4 +--
src/compiler/glsl/link_uniforms.cpp | 30
src/compiler/glsl/link_varyings.cpp | 12 +++
src/compiler/glsl/linker.cpp | 2 +-
src/compiler/glsl/lower_buffer_access.cpp | 8 ++---
src/compiler/glsl/lower_packed_varyings.cpp | 4 +--
src/compiler/glsl/lower_ubo_reference.cpp | 2 +-
src/compiler/glsl/opt_structure_splitting.cpp | 4 +--
src/compiler/glsl_types.cpp | 36 +--
src/compiler/glsl_types.h | 2 +-
src/compiler/nir_types.cpp| 2 +-
src/intel/compiler/brw_vec4_visitor.cpp | 4 +--
src/mesa/main/shader_query.cpp| 2 +-
src/mesa/program/ir_to_mesa.cpp | 4 +--
src/mesa/state_tracker/st_glsl_to_tgsi.cpp| 10 +++---
22 files changed, 90 insertions(+), 90 deletions(-)
diff --git a/src/compiler/glsl/ast_function.cpp
b/src/compiler/glsl/ast_function.cpp
index 2be7a8c195d..6bd8987cd9b 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -2118,7 +2118,7 @@ ast_function_expression::hir(exec_list *instructions,
* must have the exact number of arguments with matching types in the
* correct order.
*/
- if (constructor_type->is_record()) {
+ if (constructor_type->is_struct()) {
return process_record_constructor(instructions, constructor_type,
, >expressions,
state);
@@ -2458,7 +2458,7 @@ ast_aggregate_initializer::hir(exec_list *instructions,
>expressions, state);
}
- if (constructor_type->is_record()) {
+ if (constructor_type->is_struct()) {
return process_record_constructor(instructions, constructor_type, ,
>expressions, state);
}
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 92a9650cc05..68acf2666cc 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -2389,7 +2389,7 @@ precision_qualifier_allowed(const glsl_type *type)
const glsl_type *const t = type->without_array();
return (t->is_float() || t->is_integer() || t->contains_opaque()) &&
- !t->is_record();
+ !t->is_struct();
}
const glsl_type *
@@ -2807,7 +2807,7 @@ validate_xfb_offset_qualifier(YYLTYPE *loc,
/* Make sure nested structs don't contain unsized arrays, and validate
* any xfb_offsets on interface members.
*/
- if (t_without_array->is_record() || t_without_array->is_interface())
+ if (t_without_array->is_struct() || t_without_array->is_interface())
for (unsigned int i = 0; i < t_without_array->length; i++) {
const glsl_type *member_t = t_without_array->fields.structure[i].type;
@@ -3691,7 +3691,7 @@ apply_layout_qualifier_to_variable(const struct
ast_type_qualifier *qual,
const glsl_type *type = var->type->without_array();
unsigned components = type->component_slots();
-if (type->is_matrix() || type->is_record()) {
+if (type->is_matrix() || type->is_struct()) {
_mesa_glsl_error(loc, state, "component layout qualifier "
"cannot be applied to a matrix, a structure, "
"a block, or an array containing any of "
@@ -5302,15 +5302,15 @@ ast_declarator_list::hir(exec_list *instructions,
_mesa_shader_stage_to_string(state->stage));
}
if (var->type->is_array() &&
- var->type->fields.array->is_record()) {
+ var->type->fields.array->is_struct()) {
_mesa_glsl_error(, state,
"fragment shader input "
"cannot have an array of structs");
}
- if (var->type->is_record()) {
+ if (var->type->is_struct()) {
for (unsigned i = 0; i < var->type->length; i++) {
if (var->type->fields.structure[i].type->is_array() ||
- var->type->fields.structure[i].type->is_record())
+ var->type->fields.structure[i].type->is_struct())
_mesa_glsl_error(, state,
Re: [Mesa-dev] [RFC] panfrost: Add DRM backend
> The patches in this MR are needed so the nondrm backend keeps working: > > https://gitlab.freedesktop.org/panfrost/nondrm/merge_requests/1 Oh, thank you! I didn't see this the first time around; ignore all the comments about nondrm regressions. Sorry for the confusion. -A ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver
> You should more likely be using syncobjects, not fences. ...I still don't know what either of them actually are...? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver
On Mon, Mar 4, 2019 at 6:29 PM Dave Airlie wrote: > > On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg wrote: > > > > On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig > > wrote: > > > > > > > Why aren't we using regular dma-buf fences here? The submit ioctl > > > > should be able to take a number of in fences to wait on and return an > > > > out fence if requested. > > > > > > Ah-ha, that sounds like the "proper" approach for mainline. Much of this > > > was (incorrectly) inherited from the Arm driver. Thank you for the > > > pointer. > > > > I'm not sure - I mean, the submit should take in/out fences, but the > > atom mechanism here sounds more like it's for declaring the > > dependencies between multiple batches in a renderpass/frame to allow > > the kernel to shcedule them? The sync fd may be a little to heavy > > handed for that, and if you want to express that kind of dependency to > > allow the kernel to reschedule, maybe we need both? > > You should more likely be using syncobjects, not fences. > > You can convert syncobjs to fences, but fences consume an fd which you > only really want if inter-device. Fence fd's are also required for passing through protocol for explicit synchronization. > > Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver
On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg wrote: > > On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig wrote: > > > > > Why aren't we using regular dma-buf fences here? The submit ioctl > > > should be able to take a number of in fences to wait on and return an > > > out fence if requested. > > > > Ah-ha, that sounds like the "proper" approach for mainline. Much of this > > was (incorrectly) inherited from the Arm driver. Thank you for the > > pointer. > > I'm not sure - I mean, the submit should take in/out fences, but the > atom mechanism here sounds more like it's for declaring the > dependencies between multiple batches in a renderpass/frame to allow > the kernel to shcedule them? The sync fd may be a little to heavy > handed for that, and if you want to express that kind of dependency to > allow the kernel to reschedule, maybe we need both? You should more likely be using syncobjects, not fences. You can convert syncobjs to fences, but fences consume an fd which you only really want if inter-device. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver
On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig wrote: > > > Why aren't we using regular dma-buf fences here? The submit ioctl > > should be able to take a number of in fences to wait on and return an > > out fence if requested. > > Ah-ha, that sounds like the "proper" approach for mainline. Much of this > was (incorrectly) inherited from the Arm driver. Thank you for the > pointer. I'm not sure - I mean, the submit should take in/out fences, but the atom mechanism here sounds more like it's for declaring the dependencies between multiple batches in a renderpass/frame to allow the kernel to shcedule them? The sync fd may be a little to heavy handed for that, and if you want to express that kind of dependency to allow the kernel to reschedule, maybe we need both? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver
> Why aren't we using regular dma-buf fences here? The submit ioctl > should be able to take a number of in fences to wait on and return an > out fence if requested. Ah-ha, that sounds like the "proper" approach for mainline. Much of this was (incorrectly) inherited from the Arm driver. Thank you for the pointer. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver
On Mon, Mar 4, 2019 at 4:43 PM Alyssa Rosenzweig wrote:
>
> Wooo!!!
>
> Seeing this patch in my inbox has been some of the best news all day!
>
> Without further ado, my (solicited?) comments:
>
> > +/* Copyright 2018, Linaro, Ltd., Rob Herring */
>
> Please triple check upstream that this license is okay; the other files
> in include/drm-uapi are BSDish.
>
> > +/* timeouts are specified in clock-monotonic absolute times (to simplify
> > + * restarting interrupted ioctls). The following struct is logically the
> > + * same as 'struct timespec' but 32/64b ABI safe.
> > + */
> > +struct drm_panfrost_timespec {
> > + __s64 tv_sec; /* seconds */
> > + __s64 tv_nsec; /* nanoseconds */
> > +};
>
> What's this for -- is there not a shared struct for this if it's
> necessary? (I'm assuming this was copied from etna..?)
>
> > + __u32 flags; /* in, mask of ETNA_BO_x */
>
> As Rob said, s/ETNA/PAN/g
>
> > + struct drm_panfrost_timespec timeout; /* in */
>
> (Presumably we just want a timeout in one of nanoseconds / milliseconds
> / second, not the full timespec... 64-bit time gives a pretty wide range
> even for high-precision timeouts, which I don't know that we need. Also,
> it's signed for some reason...?)
>
> > + struct drm_panfrost_gem_submit_atom_dep deps[2];
>
> I'm concerned about hardcoding deps to 2 here. I know the Arm driver
> does it, but I'm super uncomfortable by them doing it too. Keep in mind,
> when they have complex dependencies they insert dummy "dependency-only"
> jobs into the graph, though I concede I haven't seen this yet.
Why aren't we using regular dma-buf fences here? The submit ioctl
should be able to take a number of in fences to wait on and return an
out fence if requested. See I915_EXEC_FENCE_OUT and
I915_EXEC_FENCE_ARRAY in
https://cgit.freedesktop.org/~airlied/linux/tree/include/uapi/drm/i915_drm.h?h=drm-next
or MSM_SUBMIT_FENCE_FD_IN/OUT in
https://cgit.freedesktop.org/~airlied/linux/tree/include/uapi/drm/msm_drm.h?h=drm-next
> I'm not at all sure what the right number is, especially since the new
> kernel interface seems to support waiting on BOs? Or am I
> misinterpreting this?
>
> Regardless, this will start to matter when we implement support for more
> complex FBOs (where various FBOs samples from various other FBOs), which
> I think can have arbitrarily complicated dependency graphs. So
> hardcoding to [2] is inappropriate if we want to use deps for waiting on
> FBOs. On the other hand, if we use a kernel-side BO wait or fences or
> something to resolve dependencies, do we even need two deps, or just
> one?
>
> > + // TODO cache allocations
> > + // TODO properly handle errors
> > + // TODO take into account extra_flags
>
> Not a blocker at all for merge, but these should be taken care of before
> we drop support for the non-DRM stuff (since at least the
> lack of GROWABLE support represents a regression compared to the Arm
> driver).
>
> > + // TODO map and unmap on demand?
>
> I don't know if this matters too much...? Usually if we're allocating a
> slab, that means we want it mapped immediately, unless we set the
> INVISIBLE flag which means we odn't want it mapped at all.
>
> Maybe we'll have fancier scenarios in the future, but at the moment I
> think we can safely cross off at least the first half of the TODO.
>
> As you know I'm not a believer in unmapping/freeing resources ever, so I
> don't get an opinion there ;)
>
> > + gem_info.handle = gem_new.handle;
> > + ret = drmIoctl(drm->fd, DRM_IOCTL_PANFROST_GEM_INFO, _info);
> > + if (ret) {
> > +fprintf(stderr, "DRM_IOCTL_PANFROST_GEM_INFO failed:
> > %d\n", ret);
> > + assert(0);
> > + }
>
> Maybe a question for Rob, but why isn't this info passed along with the
> allocate in the first place? I guess the extra roundtrip to the kernel
> isn't a huge deal, but it seems a little odd...?
>
> > +static uint8_t
> > +allocate_atom()
> > +{
> > + /* Use to allocate atom numbers for jobs. We probably want to
> > overhaul this in kernel space at some point. */
> > + static uint8_t atom_counter = 0;
> > +
> > +atom_counter++;
> > +
> > +/* Workaround quirk where atoms must be strictly positive */
> > +
> > +if (atom_counter == 0)
> > +atom_counter++;
> > +
> > +return atom_counter;
> > +}
>
> So, this routine (which is copied straight from the non-DRM code) is
> specifically to workaround a quirk in the Arm driver where atom numbers
> must be non-zero u8's. I'm skeptical the DRM interface needs this.
>
> > + idx++;
>
> Nice one, no idea why I didn't think of doing it this way :)
>
> > +panfrost_fence_create(struct panfrost_context *ctx)
>
> I'd appreciate a link to documentation about mainline fences, since I
> have no idea what's happening here :)
>
> > +static void
> > +panfrost_drm_enable_counters(struct panfrost_screen *screen)
> > +{
> > +
Re: [Mesa-dev] [RFC] panfrost: Add DRM backend
> I get roughly the same demos working with it as with Arm's driver, but > there's lots of improvements to be made (mostly in the kernel) to how > memory is managed and jobs are scheduled. Which demos have regressed, just so we can keep track? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver
Wooo!!!
Seeing this patch in my inbox has been some of the best news all day!
Without further ado, my (solicited?) comments:
> +/* Copyright 2018, Linaro, Ltd., Rob Herring */
Please triple check upstream that this license is okay; the other files
in include/drm-uapi are BSDish.
> +/* timeouts are specified in clock-monotonic absolute times (to simplify
> + * restarting interrupted ioctls). The following struct is logically the
> + * same as 'struct timespec' but 32/64b ABI safe.
> + */
> +struct drm_panfrost_timespec {
> + __s64 tv_sec; /* seconds */
> + __s64 tv_nsec; /* nanoseconds */
> +};
What's this for -- is there not a shared struct for this if it's
necessary? (I'm assuming this was copied from etna..?)
> + __u32 flags; /* in, mask of ETNA_BO_x */
As Rob said, s/ETNA/PAN/g
> + struct drm_panfrost_timespec timeout; /* in */
(Presumably we just want a timeout in one of nanoseconds / milliseconds
/ second, not the full timespec... 64-bit time gives a pretty wide range
even for high-precision timeouts, which I don't know that we need. Also,
it's signed for some reason...?)
> + struct drm_panfrost_gem_submit_atom_dep deps[2];
I'm concerned about hardcoding deps to 2 here. I know the Arm driver
does it, but I'm super uncomfortable by them doing it too. Keep in mind,
when they have complex dependencies they insert dummy "dependency-only"
jobs into the graph, though I concede I haven't seen this yet.
I'm not at all sure what the right number is, especially since the new
kernel interface seems to support waiting on BOs? Or am I
misinterpreting this?
Regardless, this will start to matter when we implement support for more
complex FBOs (where various FBOs samples from various other FBOs), which
I think can have arbitrarily complicated dependency graphs. So
hardcoding to [2] is inappropriate if we want to use deps for waiting on
FBOs. On the other hand, if we use a kernel-side BO wait or fences or
something to resolve dependencies, do we even need two deps, or just
one?
> + // TODO cache allocations
> + // TODO properly handle errors
> + // TODO take into account extra_flags
Not a blocker at all for merge, but these should be taken care of before
we drop support for the non-DRM stuff (since at least the
lack of GROWABLE support represents a regression compared to the Arm
driver).
> + // TODO map and unmap on demand?
I don't know if this matters too much...? Usually if we're allocating a
slab, that means we want it mapped immediately, unless we set the
INVISIBLE flag which means we odn't want it mapped at all.
Maybe we'll have fancier scenarios in the future, but at the moment I
think we can safely cross off at least the first half of the TODO.
As you know I'm not a believer in unmapping/freeing resources ever, so I
don't get an opinion there ;)
> + gem_info.handle = gem_new.handle;
> + ret = drmIoctl(drm->fd, DRM_IOCTL_PANFROST_GEM_INFO, _info);
> + if (ret) {
> +fprintf(stderr, "DRM_IOCTL_PANFROST_GEM_INFO failed: %d\n",
> ret);
> + assert(0);
> + }
Maybe a question for Rob, but why isn't this info passed along with the
allocate in the first place? I guess the extra roundtrip to the kernel
isn't a huge deal, but it seems a little odd...?
> +static uint8_t
> +allocate_atom()
> +{
> + /* Use to allocate atom numbers for jobs. We probably want to overhaul
> this in kernel space at some point. */
> + static uint8_t atom_counter = 0;
> +
> +atom_counter++;
> +
> +/* Workaround quirk where atoms must be strictly positive */
> +
> +if (atom_counter == 0)
> +atom_counter++;
> +
> +return atom_counter;
> +}
So, this routine (which is copied straight from the non-DRM code) is
specifically to workaround a quirk in the Arm driver where atom numbers
must be non-zero u8's. I'm skeptical the DRM interface needs this.
> + idx++;
Nice one, no idea why I didn't think of doing it this way :)
> +panfrost_fence_create(struct panfrost_context *ctx)
I'd appreciate a link to documentation about mainline fences, since I
have no idea what's happening here :)
> +static void
> +panfrost_drm_enable_counters(struct panfrost_screen *screen)
> +{
> + fprintf(stderr, "unimplemented: %s\n", __func__);
> +}
If nobody else is taking it, would anyone mind if I play with adding
performance counters to the kernel? I want to at least dip my feet into
the other side of the stack, and that seems like a nice low-hanging
fruit (especially since I actually grok the performance counters, more
or less) :)
> +return drmSyncobjCreate(drm->fd, DRM_SYNCOBJ_CREATE_SIGNALED,
(See fence question)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/8] panfrost: Fix BO import and export
Reviewed-by: Alyssa Rosenzweig Out of curiosity, when would this code path be needed? Was this a problem on the non-DRM driver too, or just the new kernel which makes heavier use of real BOs? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] android, autotools: st/mesa: fix location of float64_glsl.h
On 2019-03-04 15:21:26, Mauro Rossi wrote:
> Hi,
> On Mon, Mar 4, 2019 at 7:50 PM Mauro Rossi wrote:
> >
> > Il lun 4 mar 2019, 18:59 Dylan Baker ha scritto:
> >>
> >> I wrote c812, and I'd be very happy to revert it. The problem that I ran
> >> into
> >> was putting it in a place that android, meson, and the autotools dist
> >> tarball
> >> were happy with. I'm hoping that we can remove autotools in the very near
> >> future
> >> and just revert c812 at that time. Does that seem like a reasonable
> >> solution?
> >>
> >> Dylan
>
> Hi Dylan,
> I have checked on Android.mk and reverting you commit c812c740e6
> would be very complex.
>
> The best way is to proceed now is with my patch to un-break the Android build
>
> Then as a reference, the future solution may require chages to sources:
>
> #include "compiler/glsl/{header}.h"
> to become
> #include "glsl/{header}.h"
>
> in order to reach the Android generated files with
> $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_glsl,,)
> as equivalent of -I$(top_builddir)/src/compiler
Just wanted to point out that Jason is moving this under glsl in:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/371
So, either that will fix this, or else cause it to break in a new,
different way. :)
-Jordan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] RFC: Workaround for pthread_setaffinity_np() seccomp filtering
Hi Drew
On Mon, Mar 4, 2019 at 8:01 PM Drew Davenport wrote:
>
> We ran into a similar issue with this syscall in Chrome OS. This patch
> addressed the issue:
> https://lists.freedesktop.org/archives/mesa-dev/2019-February/215721.html
>
> Does it help in this case as well?
That doesn't work, since the default SIGSYS handler will core dump.
Furthermore, qemu will start using SCMP_ACT_KILL_PROCESS, which will
kill the entire process immediately.
>
> On Wed, Feb 27, 2019 at 4:13 PM wrote:
> >
> > From: Marc-André Lureau
> >
> > Since commit d877451b48a59ab0f9a4210fc736f51da5851c9a ("util/u_queue:
> > add UTIL_QUEUE_INIT_SET_FULL_THREAD_AFFINITY"), mesa calls
> > sched_setaffinity syscall. Unfortunately, qemu crashes with SIGSYS
> > when sandboxing is enabled (by default with libvirt), as this syscall
> > is filtered.
> >
> > There doesn't seem to be a way to check for the seccomp rule other
> > than doing a call, which may result in various behaviour depending on
> > seccomp actions. There is a PTRACE_SECCOMP_GET_FILTER, but it is
> > low-level and a priviledged operation (but there might be a way to use
> > it?). A safe way would be to try the call in a subprocess,
> > unfortunately, qemu also prohibits fork(). Also this could be subject
> > to TOCTOU.
> >
> > There seems to be few solutions, but the issue can be considered a
> > regression for various libvirt/Boxes users.
> >
> > Introduce MESA_NO_THREAD_AFFINITY environment variable to prevent the
> > offending call. Wrap pthread_setaffinity_np() in a utility function
> > u_pthread_setaffinity_np(), returning a EACCESS error if the variable
> > is set.
> >
> > Note: one call is left with a FIXME, as I didn't investigate how to
> > build and test it, help welcome!
> >
> > See also:
> > https://bugs.freedesktop.org/show_bug.cgi?id=109695
> >
> > Signed-off-by: Marc-André Lureau
> > ---
> > .../drivers/swr/rasterizer/core/threads.cpp | 1 +
> > src/util/u_queue.c| 2 +-
> > src/util/u_thread.h | 15 ++-
> > 3 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> > b/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> > index e30c1170568..d10c79512a1 100644
> > --- a/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> > +++ b/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> > @@ -364,6 +364,7 @@ void bindThread(SWR_CONTEXT* pContext,
> > CPU_ZERO();
> > CPU_SET(threadId, );
> >
> > +/* FIXME: use u_pthread_setaffinity_np() if possible */
> > int err = pthread_setaffinity_np(thread, sizeof(cpu_set_t), );
> > if (err != 0)
> > {
> > diff --git a/src/util/u_queue.c b/src/util/u_queue.c
> > index 3812c824b6d..dea8d2bb4ae 100644
> > --- a/src/util/u_queue.c
> > +++ b/src/util/u_queue.c
> > @@ -249,7 +249,7 @@ util_queue_thread_func(void *input)
> >for (unsigned i = 0; i < CPU_SETSIZE; i++)
> > CPU_SET(i, );
> >
> > - pthread_setaffinity_np(pthread_self(), sizeof(cpuset), );
> > + u_pthread_setaffinity_np(pthread_self(), sizeof(cpuset), );
> > }
> > #endif
> >
> > diff --git a/src/util/u_thread.h b/src/util/u_thread.h
> > index a46c18d3db2..a4e6dbae5d7 100644
> > --- a/src/util/u_thread.h
> > +++ b/src/util/u_thread.h
> > @@ -70,6 +70,19 @@ static inline void u_thread_setname( const char *name )
> > (void)name;
> > }
> >
> > +#if defined(HAVE_PTHREAD_SETAFFINITY)
> > +static inline int u_pthread_setaffinity_np(pthread_t thread, size_t
> > cpusetsize,
> > + const cpu_set_t *cpuset)
> > +{
> > + if (getenv("MESA_NO_THREAD_AFFINITY")) {
> > + errno = EACCES;
> > + return -1;
> > + }
> > +
> > + return pthread_setaffinity_np(thread, cpusetsize, cpuset);
> > +}
> > +#endif
> > +
> > /**
> > * An AMD Zen CPU consists of multiple modules where each module has its
> > own L3
> > * cache. Inter-thread communication such as locks and atomics between
> > modules
> > @@ -89,7 +102,7 @@ util_pin_thread_to_L3(thrd_t thread, unsigned L3_index,
> > unsigned cores_per_L3)
> > CPU_ZERO();
> > for (unsigned i = 0; i < cores_per_L3; i++)
> >CPU_SET(L3_index * cores_per_L3 + i, );
> > - pthread_setaffinity_np(thread, sizeof(cpuset), );
> > + u_pthread_setaffinity_np(thread, sizeof(cpuset), );
> > #endif
> > }
> >
> > --
> > 2.21.0
> >
> > ___
> > 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 v4 34/40] intel/compiler: validate region restrictions for half-float conversions
Iago Toral writes:
> On Fri, 2019-03-01 at 19:04 -0800, Francisco Jerez wrote:
>> Iago Toral writes:
>>
>> > On Thu, 2019-02-28 at 09:54 -0800, Francisco Jerez wrote:
>> > > Iago Toral writes:
>> > >
>> > > > On Wed, 2019-02-27 at 13:47 -0800, Francisco Jerez wrote:
>> > > > > Iago Toral writes:
>> > > > >
>> > > > > > On Tue, 2019-02-26 at 14:54 -0800, Francisco Jerez wrote:
>> > > > > > > Iago Toral Quiroga writes:
>> > > > > > >
>> > > > > > > > ---
>> > > > > > > > src/intel/compiler/brw_eu_validate.c| 64
>> > > > > > > > -
>> > > > > > > > src/intel/compiler/test_eu_validate.cpp | 122
>> > > > > > > >
>> > > > > > > > 2 files changed, 185 insertions(+), 1 deletion(-)
>> > > > > > > >
>> > > > > > > > diff --git a/src/intel/compiler/brw_eu_validate.c
>> > > > > > > > b/src/intel/compiler/brw_eu_validate.c
>> > > > > > > > index 000a05cb6ac..203641fecb9 100644
>> > > > > > > > --- a/src/intel/compiler/brw_eu_validate.c
>> > > > > > > > +++ b/src/intel/compiler/brw_eu_validate.c
>> > > > > > > > @@ -531,7 +531,69 @@
>> > > > > > > > general_restrictions_based_on_operand_types(const
>> > > > > > > > struct
>> > > > > > > > gen_device_info *devinf
>> > > > > > > > exec_type_size == 8 && dst_type_size == 4)
>> > > > > > > >dst_type_size = 8;
>> > > > > > > >
>> > > > > > > > - if (exec_type_size > dst_type_size) {
>> > > > > > > > + /* From the BDW+ PRM:
>> > > > > > > > +*
>> > > > > > > > +*"There is no direct conversion from HF to DF
>> > > > > > > > or
>> > > > > > > > DF to
>> > > > > > > > HF.
>> > > > > > > > +* There is no direct conversion from HF to
>> > > > > > > > Q/UQ or
>> > > > > > > > Q/UQ to
>> > > > > > > > HF."
>> > > > > > > > +*/
>> > > > > > > > + enum brw_reg_type src0_type =
>> > > > > > > > brw_inst_src0_type(devinfo,
>> > > > > > > > inst);
>> > > > > > > > + ERROR_IF(brw_inst_opcode(devinfo, inst) ==
>> > > > > > > > BRW_OPCODE_MOV
>> > > > > > > > &&
>> > > > > > >
>> > > > > > > Why is only the MOV instruction handled here and
>> > > > > > > below? Aren't
>> > > > > > > other
>> > > > > > > instructions able to do implicit conversions? Probably
>> > > > > > > means
>> > > > > > > you
>> > > > > > > need
>> > > > > > > to deal with two sources rather than one.
>> > > > > >
>> > > > > > This comes from the programming notes of the MOV
>> > > > > > instruction
>> > > > > > (Volume
>> > > > > > 2a, Command Reference - Instructions - MOV), so it is
>> > > > > > described
>> > > > > > specifically for the MOV instruction. I should probably
>> > > > > > have
>> > > > > > made
>> > > > > > this
>> > > > > > clear in the comment.
>> > > > > >
>> > > > >
>> > > > > Maybe the one above is specified in the MOV page only,
>> > > > > probably
>> > > > > due
>> > > > > to
>> > > > > an oversight (If these restrictions were really specific to
>> > > > > the
>> > > > > MOV
>> > > > > instruction, what would prevent you from implementing such
>> > > > > conversions
>> > > > > through a different instruction? E.g. "ADD dst:df, src:hf,
>> > > > > 0"
>> > > > > which
>> > > > > would be substantially more efficient than what you're doing
>> > > > > in
>> > > > > PATCH
>> > > > > 02)
>> > > >
>> > > > Instructions that take HF can only be strictly HF or mix F and
>> > > > HF
>> > > > (mixed mode float), with MOV being the only exception. That
>> > > > means
>> > > > that
>> > > > any instruction like the one you use above are invalid. Maybe
>> > > > we
>> > > > should
>> > > > validate explicitly that instructions that use HF are strictly
>> > > > HF
>> > > > or
>> > > > mixed-float mode only?
>> > > >
>> > >
>> > > So you're acknowledging that the conversions checked above are
>> > > illegal
>> > > whether the instruction is a MOV or something else. Where are we
>> > > preventing instructions other than MOV with such conversions from
>> > > being
>> > > accepted by the validator?
>> >
>> > We aren't, because the validator is not checking, in general, for
>> > accepted type combinations for specific instructions anywhere as
>> > far as
>> > I can see.
>>
>> Luckily these type conversion restrictions aren't really specific to
>> any
>> instruction AFAICT, even though they only seem to be mentioned
>> explicitly for the MOV instruction...
>>
>> > If we want to start doing this with HF conversions specifically, I
>> > guess it is fine, but in case it is not clear, I think it won't
>> > bring
>> > any immediate benefits with the VK_KHR_shader_float16_int8
>> > implementation since this series only ever emits conversions
>> > involving
>> > HF operands via MOV instructions,
>>
>> Yes, I can see that's the intention of this series, but how can you
>> make
>> sure that nothing in the optimizer is breaking your assumption if you
>> don't add some validator code to verify the claim of your last
>> paragraph?
>>
>> > which is why I thought that validating that no direct MOV
>> >
Re: [Mesa-dev] [PATCH] android, autotools: st/mesa: fix location of float64_glsl.h
Hi,
On Mon, Mar 4, 2019 at 7:50 PM Mauro Rossi wrote:
>
> Hi,
> Sounds good to me.
>
> The way it could have been prevented was to avoid having fp64 generated file
> as the only one with with different path in sources.
>
> Could you just confirm that inc_compiler is not needed in
> src/mesa/meson.build, and provide R-b so that I will proceed with push?
>
> I've tried to build with meson and it's ok
>
> Il lun 4 mar 2019, 18:59 Dylan Baker ha scritto:
>>
>> Quoting Mauro Rossi (2019-03-04 01:21:05)
>> > Hi Tapani,
>> > On Mon, Mar 4, 2019 at 6:51 AM Tapani Pälli wrote:
>> > >
>> > > Hi;
>> > >
>> > > On 3/3/19 10:10 PM, Mauro Rossi wrote:
>> > > > Necessary to avoid building error in Android,
>> > > > due to 'compiler/glsl/float64_glsl.h' file not found
>> > > >
>> > > > Fixes: cb4e3e3 ("st/mesa: add support for lowering fp64/int64 for nir
>> > > > drivers")
>> > > > Signed-off-by: Mauro Rossi
>> > > > ---
>> > > > src/mesa/Android.libmesa_st_mesa.mk | 1 +
>> > > > src/mesa/Makefile.sources | 1 +
>> > > > src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
>> > > > 3 files changed, 3 insertions(+), 1 deletion(-)
>> > > >
>> > > > diff --git a/src/mesa/Android.libmesa_st_mesa.mk
>> > > > b/src/mesa/Android.libmesa_st_mesa.mk
>> > > > index ddfd03059c..c5b16cad34 100644
>> > > > --- a/src/mesa/Android.libmesa_st_mesa.mk
>> > > > +++ b/src/mesa/Android.libmesa_st_mesa.mk
>> > > > @@ -58,6 +58,7 @@ endif
>> > > > LOCAL_C_INCLUDES := \
>> > > > $(MESA_TOP)/src/mapi \
>> > > > $(MESA_TOP)/src/mesa/main \
>> > > > + $(call
>> > > > generated-sources-dir-for,STATIC_LIBRARIES,libmesa_glsl,,) \
>> > > > $(MESA_TOP)/src/compiler/nir \
>> > > > $(MESA_TOP)/src/gallium/auxiliary \
>> > > > $(MESA_TOP)/src/gallium/include
>> > > > diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
>> > > > index 1e25f47e50..69f32c6adf 100644
>> > > > --- a/src/mesa/Makefile.sources
>> > > > +++ b/src/mesa/Makefile.sources
>> > > > @@ -689,6 +689,7 @@ INCLUDE_DIRS = \
>> > > > -I$(top_srcdir)/include \
>> > > > -I$(top_builddir)/src \
>> > > > -I$(top_srcdir)/src \
>> > > > + -I$(top_builddir)/src/compiler \
>> > > > -I$(top_builddir)/src/compiler/glsl \
>> > > > -I$(top_builddir)/src/compiler/nir \
>> > > > -I$(top_builddir)/src/mesa \
>> > > > diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
>> > > > b/src/mesa/state_tracker/st_glsl_to_nir.cpp
>> > > > index a1e3b6233c..ad77b746ab 100644
>> > > > --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
>> > > > +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
>> > > > @@ -48,7 +48,7 @@
>> > > > #include "compiler/glsl/ir.h"
>> > > > #include "compiler/glsl/ir_optimization.h"
>> > > > #include "compiler/glsl/string_to_uint_map.h"
>> > > > -#include "compiler/glsl/float64_glsl.h"
>> > > > +#include "glsl/float64_glsl.h"
>> > >
>> > > Looks familiar :)
>> > >
>> > > https://github.com/tpalli/external-mesa/commit/ebd8581ad133206ec2b1b818e98dc4f8401af8de
>> > >
>> > > Before going further though, I'd like to understand why do we have both
>> > > 'compiler/glsl/' and 'glsl/' going on. Should we rather put the
>> > > 'compiler' back in the header generation? I can't remember the full
>> > > story behind commit c812c740e60 but that one changed this .. perhaps we
>> > > should pull it back and have the 'compiler/', any objections to that?
>> > >
>> >
>> > I agree that simply continue to have include "compiler/glsl/float64_glsl.h"
>> > in all sources places would be simpler
>> > and should not break neither autotools nor meson,
>> > which may continue to have glsl/float64_glsl.h in their generators
>> >
>> > Mauro
>>
>> I wrote c812, and I'd be very happy to revert it. The problem that I ran into
>> was putting it in a place that android, meson, and the autotools dist tarball
>> were happy with. I'm hoping that we can remove autotools in the very near
>> future
>> and just revert c812 at that time. Does that seem like a reasonable solution?
>>
>> Dylan
Hi Dylan,
I have checked on Android.mk and reverting you commit c812c740e6
would be very complex.
The best way is to proceed now is with my patch to un-break the Android build
Then as a reference, the future solution may require chages to sources:
#include "compiler/glsl/{header}.h"
to become
#include "glsl/{header}.h"
in order to reach the Android generated files with
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_glsl,,)
as equivalent of -I$(top_builddir)/src/compiler
Mauro
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109818] wrong color rendering in SOULCALIBUR 6 using dxvk
https://bugs.freedesktop.org/show_bug.cgi?id=109818 --- Comment #2 from farmboy0+freedesk...@googlemail.com --- a03101c717846f2f0d548dc5c713528329234e6d is the first bad commit commit a03101c717846f2f0d548dc5c713528329234e6d Author: Bas Nieuwenhuizen Date: Fri Feb 22 14:24:28 2019 +0100 radv: Allow interpolation on non-float types. In particular structs containing floats and 16-bit floating point types. Fixes: 62024fa7750 "radv: enable VK_KHR_16bit_storage extension / 16bit storage features" Fixes: da295946361 "spirv: Only split blocks" Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109735 Reviewed-by: Samuel Pitoiset (cherry picked from commit f3247841040a202faffe4709c07da9bd41693580) :04 04 75aa9536ae8f8fe89e4af1818c1c3ff5a58ed59b 5a21ae9a7aa5987b9a32d095eea066df2793a995 M src -- 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 2/8] panfrost: Detect GPU version at runtime
> "is_t6xx" is not going to scale. We need to do feature and issues. > Doesn't have to be in this series though. Indeed, that's not my concern for this particular series. On that note, I suppose it doesn't matter right now; we only advertise out-of-the-box support for T860 so it doesn't matter if the earlier devices "regress" temporarily; it's not worse than it is now. > Most of midgard has a number in hex matching the marketing number, but > there's some oddballs. This one is T760 which doesn't match is_t6xx. > The other oddball is T604 which has 0x6???. Then Bifrost has a > different scheme. Lovely. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/8] panfrost: Free context BOs
On Mon, Mar 4, 2019 at 1:38 PM Alyssa Rosenzweig wrote:
>
> > unsigned transient_count =
> > ctx->transient_pools[ctx->cmdstream_i].entry_index*ctx->transient_pools[0].entry_size
> > + ctx->transient_pools[ctx->cmdstream_i].entry_offset;
> > - printf("Uploaded transient %d bytes\n", transient_count);
> > + //printf("Uploaded transient %d bytes\n", transient_count);
>
> This will raised an unused variable warning for transient_count, better
> comment both or neither.
Better yet, use a debug print so it can be enabled via an env var. Or
if it's not that useful, just remove it.
>
> Other than that, Reviewed-by: Alyssa Rosenzweig
>
> I wonder if this will fix some of the memory leaks on non-DRM as well.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver
On Mon, Mar 4, 2019 at 10:12 AM Tomeu Vizoso wrote:
>
> This backend interacts with the new DRM driver for Midgard GPUs which is
> currently in development.
>
> When using this backend, Panfrost has roughly on-par functionality as
> when using the non-DRM driver from Arm.
>
> Signed-off-by: Tomeu Vizoso
> ---
> include/drm-uapi/panfrost_drm.h| 128 +
> src/gallium/drivers/panfrost/pan_drm.c | 362 +
> 2 files changed, 490 insertions(+)
> create mode 100644 include/drm-uapi/panfrost_drm.h
>
> diff --git a/include/drm-uapi/panfrost_drm.h b/include/drm-uapi/panfrost_drm.h
> new file mode 100644
> index ..d4d271e37206
> --- /dev/null
> +++ b/include/drm-uapi/panfrost_drm.h
> @@ -0,0 +1,128 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/* Copyright 2018, Linaro, Ltd., Rob Herring */
> +
> +#ifndef __PANFROST_DRM_H__
> +#define __PANFROST_DRM_H__
> +
> +#include "drm.h"
> +
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +
> +/* timeouts are specified in clock-monotonic absolute times (to simplify
> + * restarting interrupted ioctls). The following struct is logically the
> + * same as 'struct timespec' but 32/64b ABI safe.
> + */
> +struct drm_panfrost_timespec {
> + __s64 tv_sec; /* seconds */
> + __s64 tv_nsec; /* nanoseconds */
> +};
> +
> +#define PANFROST_PARAM_GPU_ID 0x01
> +
> +struct drm_panfrost_get_param {
> + __u32 param;/* in */
> + __u32 pad;
> + __u64 value;/* out */
> +};
> +
> +struct drm_panfrost_gem_new {
> + __u64 size; /* in */
> + __u32 flags; /* in, mask of ETNA_BO_x */
> + __u32 handle; /* out */
> + /**
> +* Returned offset for the BO in the GPU address space. This offset
> +* is private to the DRM fd and is valid for the lifetime of the GEM
> +* handle.
> +*
> +* This offset value will always be nonzero, since various HW
> +* units treat 0 specially.
> +*/
> + __u64 offset;
> +};
> +struct drm_panfrost_gem_info {
> + __u32 handle; /* in */
> + __u32 pad;
> + __u64 offset; /* out, offset to pass to mmap() */
> +};
> +
> +/**
> + * Returns the offset for the BO in the GPU address space for this DRM fd.
> + * This is the same value returned by drm_panfrost_gem_new, if that was
> called
> + * from this DRM fd.
> + */
> +struct drm_panfrost_get_bo_offset {
> + __u32 handle;
> + __u32 pad;
> + __u64 offset;
> +};
> +
> +
> +#define ETNA_PREP_READ0x01
> +#define ETNA_PREP_WRITE 0x02
> +#define ETNA_PREP_NOSYNC 0x04
Guess we need to rename or delete these and a few other spots with
'ETNA'. I'd hoped to keep some alignment with other drivers, but I
don't think that's going to happen.
> +
> +struct drm_panfrost_gem_cpu_prep {
> + __u32 handle; /* in */
> + __u32 op; /* in, mask of ETNA_PREP_x */
> + struct drm_panfrost_timespec timeout; /* in */
> +};
> +
> +struct drm_panfrost_gem_cpu_fini {
> + __u32 handle; /* in */
> + __u32 flags; /* in, placeholder for now, no defined values */
> +};
> +
> +/*
> + * Cmdstream Submission:
> + */
> +
> +#define PANFROST_JD_REQ_FS (1 << 0)
> +
> +#define PANFROST_DEP_TYPE_ORDER0x01
> +#define PANFROST_DEP_TYPE_DATA 0x02
> +
> +struct drm_panfrost_gem_submit_atom_dep {
> + __u32 atom_nr; /* job ID of dependency */
> + __u32 type; /* one of PANFROST_DEP_TYPE_* */
> +};
> +
> +struct drm_panfrost_gem_submit_atom {
> + __u64 jc; /* in, address to GPU mapping of job descriptor */
> + __u32 atom_nr; /* in, job ID */
> + __u32 requirements; /* in, a combination of PANFROST_JD_REQ_* */
> + __u64 bo_handles;
> + __u32 bo_handle_count;
> + struct drm_panfrost_gem_submit_atom_dep deps[2];
> +};
> +
> +struct drm_panfrost_gem_submit {
> + __u32 nr_atoms; /* in, number of submit_atom */
> + __u32 pad;
> + __u64 atoms;/* in, ptr to array of submit_atom */
> +};
> +
> +
> +
> +#define DRM_PANFROST_GET_PARAM 0x00
> +#define DRM_PANFROST_GEM_NEW 0x01
> +#define DRM_PANFROST_GEM_INFO 0x02
> +#define DRM_PANFROST_GEM_CPU_PREP 0x03
> +#define DRM_PANFROST_GEM_CPU_FINI 0x04
> +#define DRM_PANFROST_GEM_SUBMIT0x05
> +#define DRM_PANFROST_GET_BO_OFFSET 0x06
> +
> +#define DRM_IOCTL_PANFROST_GET_PARAM DRM_IOWR(DRM_COMMAND_BASE +
> DRM_PANFROST_GET_PARAM, struct drm_panfrost_get_param)
> +#define DRM_IOCTL_PANFROST_GEM_NEW DRM_IOWR(DRM_COMMAND_BASE +
> DRM_PANFROST_GEM_NEW, struct drm_panfrost_gem_new)
> +#define DRM_IOCTL_PANFROST_GEM_INFODRM_IOWR(DRM_COMMAND_BASE +
> DRM_PANFROST_GEM_INFO, struct drm_panfrost_gem_info)
> +#define DRM_IOCTL_PANFROST_GEM_CPU_PREPDRM_IOW(DRM_COMMAND_BASE +
>
Re: [Mesa-dev] [PATCH 2/8] panfrost: Detect GPU version at runtime
On Mon, Mar 4, 2019 at 1:35 PM Alyssa Rosenzweig wrote: > > > /* If set, we'll require the use of single render-target framebuffer > > * descriptors (SFBD), for older hardware -- specifically, > If > > This require_sfbd field should also be set at the same time. In > particular, we'll want a (kernel-agnostic) routine to determine whether > a given chip version supports MFBD, so we know to use it or not. > > In kernel-space, this corresponds to the "FEATURE_MRT" flag. We'll want > to import this to userspace, but tl;dr "T760+ is MFBD, T6XX/T720 is > SFBD". +1 "is_t6xx" is not going to scale. We need to do feature and issues. Doesn't have to be in this series though. > > +ctx->is_t6xx = pscreen->driver->query_gpu_version(pscreen) == > > 0x0750; > > Where did this magic number come from? Is that for T760 or actually T600 > or something else or...? For Midgard only, I suppose <= 0x0750 is > probably what you want but we'll see. Most of midgard has a number in hex matching the marketing number, but there's some oddballs. This one is T760 which doesn't match is_t6xx. The other oddball is T604 which has 0x6???. Then Bifrost has a different scheme. > > + unsigned (*query_gpu_version) (struct panfrost_screen *screen); > > I'll implement this in the non-DRM module as well (tonight, if I get > time for it), but that's needed for merging to avoid regressing. Just > making a mental note to self -- nothing for you to worry about here :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/8] panfrost: Free context BOs
> unsigned transient_count =
> ctx->transient_pools[ctx->cmdstream_i].entry_index*ctx->transient_pools[0].entry_size
> + ctx->transient_pools[ctx->cmdstream_i].entry_offset;
> - printf("Uploaded transient %d bytes\n", transient_count);
> + //printf("Uploaded transient %d bytes\n", transient_count);
This will raised an unused variable warning for transient_count, better
comment both or neither.
Other than that, Reviewed-by: Alyssa Rosenzweig
I wonder if this will fix some of the memory leaks on non-DRM as well.
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/8] panfrost: Pass the fence down when flushing
> + __u32 out_sync; Why __u32 instead of u32 or uint32_t? I don't think we use the prefixed types anywhere else. > + int (*init_context) (struct panfrost_context *ctx); > + void (*fence_reference) (struct pipe_screen *screen, > + struct pipe_fence_handle **ptr, > + struct pipe_fence_handle *fence); > + boolean (*fence_finish) (struct pipe_screen *screen, > + struct pipe_context *ctx, > + struct pipe_fence_handle *fence, > + uint64_t timeout); How should these be implemented on the non-DRM backend? If I just stub out the corresponding routines, should everything work alright? (If that's the case, then I'll do that; nothing you need to worry about. But I'm not up to date on how fencing works on mainline.) signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/8] panfrost: Store GEM handle of AFBC BOs
Reveiewed-by: Alyssa Rosenzweig signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/8] panfrost: remove use of duplicate function panfrost_screen
Reviewed-by: Alyssa Rosenzweig signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/8] panfrost: Detect GPU version at runtime
> /* If set, we'll require the use of single render-target framebuffer > * descriptors (SFBD), for older hardware -- specifically, +ctx->is_t6xx = pscreen->driver->query_gpu_version(pscreen) == 0x0750; Where did this magic number come from? Is that for T760 or actually T600 or something else or...? For Midgard only, I suppose <= 0x0750 is probably what you want but we'll see. > + unsigned (*query_gpu_version) (struct panfrost_screen *screen); I'll implement this in the non-DRM module as well (tonight, if I get time for it), but that's needed for merging to avoid regressing. Just making a mental note to self -- nothing for you to worry about here :) signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/8] panfrost: Add gem_handle to panfrost_memory and panfrost_bo
Reviewed-by: Alyssa Rosenzweig signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] RFC: Workaround for pthread_setaffinity_np() seccomp filtering
We ran into a similar issue with this syscall in Chrome OS. This patch
addressed the issue:
https://lists.freedesktop.org/archives/mesa-dev/2019-February/215721.html
Does it help in this case as well?
On Wed, Feb 27, 2019 at 4:13 PM wrote:
>
> From: Marc-André Lureau
>
> Since commit d877451b48a59ab0f9a4210fc736f51da5851c9a ("util/u_queue:
> add UTIL_QUEUE_INIT_SET_FULL_THREAD_AFFINITY"), mesa calls
> sched_setaffinity syscall. Unfortunately, qemu crashes with SIGSYS
> when sandboxing is enabled (by default with libvirt), as this syscall
> is filtered.
>
> There doesn't seem to be a way to check for the seccomp rule other
> than doing a call, which may result in various behaviour depending on
> seccomp actions. There is a PTRACE_SECCOMP_GET_FILTER, but it is
> low-level and a priviledged operation (but there might be a way to use
> it?). A safe way would be to try the call in a subprocess,
> unfortunately, qemu also prohibits fork(). Also this could be subject
> to TOCTOU.
>
> There seems to be few solutions, but the issue can be considered a
> regression for various libvirt/Boxes users.
>
> Introduce MESA_NO_THREAD_AFFINITY environment variable to prevent the
> offending call. Wrap pthread_setaffinity_np() in a utility function
> u_pthread_setaffinity_np(), returning a EACCESS error if the variable
> is set.
>
> Note: one call is left with a FIXME, as I didn't investigate how to
> build and test it, help welcome!
>
> See also:
> https://bugs.freedesktop.org/show_bug.cgi?id=109695
>
> Signed-off-by: Marc-André Lureau
> ---
> .../drivers/swr/rasterizer/core/threads.cpp | 1 +
> src/util/u_queue.c| 2 +-
> src/util/u_thread.h | 15 ++-
> 3 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> b/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> index e30c1170568..d10c79512a1 100644
> --- a/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> +++ b/src/gallium/drivers/swr/rasterizer/core/threads.cpp
> @@ -364,6 +364,7 @@ void bindThread(SWR_CONTEXT* pContext,
> CPU_ZERO();
> CPU_SET(threadId, );
>
> +/* FIXME: use u_pthread_setaffinity_np() if possible */
> int err = pthread_setaffinity_np(thread, sizeof(cpu_set_t), );
> if (err != 0)
> {
> diff --git a/src/util/u_queue.c b/src/util/u_queue.c
> index 3812c824b6d..dea8d2bb4ae 100644
> --- a/src/util/u_queue.c
> +++ b/src/util/u_queue.c
> @@ -249,7 +249,7 @@ util_queue_thread_func(void *input)
>for (unsigned i = 0; i < CPU_SETSIZE; i++)
> CPU_SET(i, );
>
> - pthread_setaffinity_np(pthread_self(), sizeof(cpuset), );
> + u_pthread_setaffinity_np(pthread_self(), sizeof(cpuset), );
> }
> #endif
>
> diff --git a/src/util/u_thread.h b/src/util/u_thread.h
> index a46c18d3db2..a4e6dbae5d7 100644
> --- a/src/util/u_thread.h
> +++ b/src/util/u_thread.h
> @@ -70,6 +70,19 @@ static inline void u_thread_setname( const char *name )
> (void)name;
> }
>
> +#if defined(HAVE_PTHREAD_SETAFFINITY)
> +static inline int u_pthread_setaffinity_np(pthread_t thread, size_t
> cpusetsize,
> + const cpu_set_t *cpuset)
> +{
> + if (getenv("MESA_NO_THREAD_AFFINITY")) {
> + errno = EACCES;
> + return -1;
> + }
> +
> + return pthread_setaffinity_np(thread, cpusetsize, cpuset);
> +}
> +#endif
> +
> /**
> * An AMD Zen CPU consists of multiple modules where each module has its own
> L3
> * cache. Inter-thread communication such as locks and atomics between
> modules
> @@ -89,7 +102,7 @@ util_pin_thread_to_L3(thrd_t thread, unsigned L3_index,
> unsigned cores_per_L3)
> CPU_ZERO();
> for (unsigned i = 0; i < cores_per_L3; i++)
>CPU_SET(L3_index * cores_per_L3 + i, );
> - pthread_setaffinity_np(thread, sizeof(cpuset), );
> + u_pthread_setaffinity_np(thread, sizeof(cpuset), );
> #endif
> }
>
> --
> 2.21.0
>
> ___
> 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
[Mesa-dev] [PATCH] svga: only free sampler views from the context which created it
Some applications, like google-chrome, cause the state tracker to
destroy sampler/resource views from a context other than the one
which was used to create it. Previously, we just leaked the view.
Now, when we're in this situation we declare the view a zombie and
add it to a list of zombie views associated with the context which
created the context.
VMware bug 2274734.
---
src/gallium/drivers/svga/svga_context.c | 69
src/gallium/drivers/svga/svga_context.h | 21 +
src/gallium/drivers/svga/svga_pipe_sampler.c | 8 ++--
3 files changed, 93 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_context.c
b/src/gallium/drivers/svga/svga_context.c
index 7b3e9e8..2c51fa0 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -54,12 +54,74 @@ DEBUG_GET_ONCE_BOOL_OPTION(no_line_width,
"SVGA_NO_LINE_WIDTH", FALSE);
DEBUG_GET_ONCE_BOOL_OPTION(force_hw_line_stipple,
"SVGA_FORCE_HW_LINE_STIPPLE", FALSE);
+/*
+ * In some circumstances (such as running google-chrome) the state
+ * tracker may try to delete a resource view from a context different
+ * than when it was created. We don't want to do that.
+ * In that situation, svga_sampler_view_destroy() calls this function
+ * to save the view for later deletion. The context here is expected
+ * to be the context which created the view.
+ */
+void
+svga_save_zombie_view(struct pipe_context *pipe,
+ struct pipe_sampler_view *view)
+{
+ struct svga_context *svga = svga_context(pipe);
+ struct svga_pipe_sampler_view *sv = svga_pipe_sampler_view(view);
+ struct svga_zombie_view_list *entry;
+
+ assert(view->context == pipe);
+
+ entry = MALLOC_STRUCT(svga_zombie_view_list);
+ if (!entry)
+ return;
+
+ entry->view = sv;
+
+ /* We need a mutex since this function may be called from one thread
+* while free_zombie_resource_views() is called from another.
+*/
+ mtx_lock(>zombie_view_mutex);
+ LIST_ADDTAIL(>node, >zombie_views);
+ mtx_unlock(>zombie_view_mutex);
+}
+
+
+/*
+ * This function is called periodically (currently from svga_surfaces_flush)
+ * to free any resource views which the state tracker tried to free earlier,
+ * but did so from the wrong context.
+ */
+static void
+free_zombie_resource_views(struct svga_context *svga)
+{
+ struct pipe_context *pipe = >pipe;
+ struct svga_zombie_view_list *entry, *next;
+
+ mtx_lock(>zombie_view_mutex);
+
+ LIST_FOR_EACH_ENTRY_SAFE(entry, next, >zombie_views, node) {
+ assert(entry->view->base.context == pipe);
+ pipe->sampler_view_destroy(pipe, >view->base);
+ free(entry);
+ LIST_DEL(>node);
+ }
+
+ assert(LIST_IS_EMPTY(>zombie_views));
+
+ mtx_unlock(>zombie_view_mutex);
+}
+
+
static void
svga_destroy(struct pipe_context *pipe)
{
struct svga_context *svga = svga_context(pipe);
unsigned shader, i;
+ free_zombie_resource_views(svga);
+ mtx_destroy(>zombie_view_mutex);
+
/* free any alternate rasterizer states used for point sprite */
for (i = 0; i < ARRAY_SIZE(svga->rasterizer_no_cull); i++) {
if (svga->rasterizer_no_cull[i]) {
@@ -137,6 +199,8 @@ svga_context_create(struct pipe_screen *screen, void *priv,
unsigned flags)
goto done;
LIST_INITHEAD(>dirty_buffers);
+ LIST_INITHEAD(>zombie_views);
+ mtx_init(>zombie_view_mutex, mtx_plain);
svga->pipe.screen = screen;
svga->pipe.priv = priv;
@@ -482,6 +546,11 @@ svga_surfaces_flush(struct svga_context *svga)
svga_propagate_rendertargets(svga);
SVGA_STATS_TIME_POP(svga_sws(svga));
+
+ /* We want to call this function periodically. This seems to
+* be a reasonable place to do so.
+*/
+ free_zombie_resource_views(svga);
}
diff --git a/src/gallium/drivers/svga/svga_context.h
b/src/gallium/drivers/svga/svga_context.h
index fc63ec3..4de81ac 100644
--- a/src/gallium/drivers/svga/svga_context.h
+++ b/src/gallium/drivers/svga/svga_context.h
@@ -231,6 +231,18 @@ svga_pipe_sampler_view(struct pipe_sampler_view *v)
}
+/*
+ * For keeping a list of zombie sampler views. A zombie sampler view is
+ * one that is supposed to be deleted, but the view's parent context is not
+ * the context passed to pipe_context::sampler_view_destroy().
+ */
+struct svga_zombie_view_list
+{
+ struct svga_pipe_sampler_view *view;
+ struct list_head node; // there's a linked list of these structs
+};
+
+
struct svga_velems_state {
unsigned count;
struct pipe_vertex_element velem[PIPE_MAX_ATTRIBS];
@@ -536,6 +548,10 @@ struct svga_context
/** List of buffers with queued transfers */
struct list_head dirty_buffers;
+ /** List of zombie resource views */
+ struct list_head zombie_views;
+ mtx_t zombie_view_mutex;
+
/** performance / info queries for HUD */
struct {
uint64_t num_draw_calls; /**< SVGA_QUERY_DRAW_CALLS */
@@ -683,6 +699,11 @@ void
Re: [Mesa-dev] [PATCH] android, autotools: st/mesa: fix location of float64_glsl.h
Hi,
Sounds good to me.
The way it could have been prevented was to avoid having fp64 generated
file as the only one with with different path in sources.
Could you just confirm that inc_compiler is not needed in
src/mesa/meson.build, and provide R-b so that I will proceed with push?
I've tried to build with meson and it's ok
Il lun 4 mar 2019, 18:59 Dylan Baker ha scritto:
> Quoting Mauro Rossi (2019-03-04 01:21:05)
> > Hi Tapani,
> > On Mon, Mar 4, 2019 at 6:51 AM Tapani Pälli
> wrote:
> > >
> > > Hi;
> > >
> > > On 3/3/19 10:10 PM, Mauro Rossi wrote:
> > > > Necessary to avoid building error in Android,
> > > > due to 'compiler/glsl/float64_glsl.h' file not found
> > > >
> > > > Fixes: cb4e3e3 ("st/mesa: add support for lowering fp64/int64 for
> nir drivers")
> > > > Signed-off-by: Mauro Rossi
> > > > ---
> > > > src/mesa/Android.libmesa_st_mesa.mk | 1 +
> > > > src/mesa/Makefile.sources | 1 +
> > > > src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
> > > > 3 files changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/src/mesa/Android.libmesa_st_mesa.mk b/src/mesa/
> Android.libmesa_st_mesa.mk
> > > > index ddfd03059c..c5b16cad34 100644
> > > > --- a/src/mesa/Android.libmesa_st_mesa.mk
> > > > +++ b/src/mesa/Android.libmesa_st_mesa.mk
> > > > @@ -58,6 +58,7 @@ endif
> > > > LOCAL_C_INCLUDES := \
> > > > $(MESA_TOP)/src/mapi \
> > > > $(MESA_TOP)/src/mesa/main \
> > > > + $(call
> generated-sources-dir-for,STATIC_LIBRARIES,libmesa_glsl,,) \
> > > > $(MESA_TOP)/src/compiler/nir \
> > > > $(MESA_TOP)/src/gallium/auxiliary \
> > > > $(MESA_TOP)/src/gallium/include
> > > > diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
> > > > index 1e25f47e50..69f32c6adf 100644
> > > > --- a/src/mesa/Makefile.sources
> > > > +++ b/src/mesa/Makefile.sources
> > > > @@ -689,6 +689,7 @@ INCLUDE_DIRS = \
> > > > -I$(top_srcdir)/include \
> > > > -I$(top_builddir)/src \
> > > > -I$(top_srcdir)/src \
> > > > + -I$(top_builddir)/src/compiler \
> > > > -I$(top_builddir)/src/compiler/glsl \
> > > > -I$(top_builddir)/src/compiler/nir \
> > > > -I$(top_builddir)/src/mesa \
> > > > diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> b/src/mesa/state_tracker/st_glsl_to_nir.cpp
> > > > index a1e3b6233c..ad77b746ab 100644
> > > > --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> > > > +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
> > > > @@ -48,7 +48,7 @@
> > > > #include "compiler/glsl/ir.h"
> > > > #include "compiler/glsl/ir_optimization.h"
> > > > #include "compiler/glsl/string_to_uint_map.h"
> > > > -#include "compiler/glsl/float64_glsl.h"
> > > > +#include "glsl/float64_glsl.h"
> > >
> > > Looks familiar :)
> > >
> > >
> https://github.com/tpalli/external-mesa/commit/ebd8581ad133206ec2b1b818e98dc4f8401af8de
> > >
> > > Before going further though, I'd like to understand why do we have both
> > > 'compiler/glsl/' and 'glsl/' going on. Should we rather put the
> > > 'compiler' back in the header generation? I can't remember the full
> > > story behind commit c812c740e60 but that one changed this .. perhaps we
> > > should pull it back and have the 'compiler/', any objections to that?
> > >
> >
> > I agree that simply continue to have include
> "compiler/glsl/float64_glsl.h"
> > in all sources places would be simpler
> > and should not break neither autotools nor meson,
> > which may continue to have glsl/float64_glsl.h in their generators
> >
> > Mauro
>
> I wrote c812, and I'd be very happy to revert it. The problem that I ran
> into
> was putting it in a place that android, meson, and the autotools dist
> tarball
> were happy with. I'm hoping that we can remove autotools in the very near
> future
> and just revert c812 at that time. Does that seem like a reasonable
> solution?
>
> Dylan
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] android, autotools: st/mesa: fix location of float64_glsl.h
Quoting Mauro Rossi (2019-03-04 01:21:05)
> Hi Tapani,
> On Mon, Mar 4, 2019 at 6:51 AM Tapani Pälli wrote:
> >
> > Hi;
> >
> > On 3/3/19 10:10 PM, Mauro Rossi wrote:
> > > Necessary to avoid building error in Android,
> > > due to 'compiler/glsl/float64_glsl.h' file not found
> > >
> > > Fixes: cb4e3e3 ("st/mesa: add support for lowering fp64/int64 for nir
> > > drivers")
> > > Signed-off-by: Mauro Rossi
> > > ---
> > > src/mesa/Android.libmesa_st_mesa.mk | 1 +
> > > src/mesa/Makefile.sources | 1 +
> > > src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
> > > 3 files changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/mesa/Android.libmesa_st_mesa.mk
> > > b/src/mesa/Android.libmesa_st_mesa.mk
> > > index ddfd03059c..c5b16cad34 100644
> > > --- a/src/mesa/Android.libmesa_st_mesa.mk
> > > +++ b/src/mesa/Android.libmesa_st_mesa.mk
> > > @@ -58,6 +58,7 @@ endif
> > > LOCAL_C_INCLUDES := \
> > > $(MESA_TOP)/src/mapi \
> > > $(MESA_TOP)/src/mesa/main \
> > > + $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_glsl,,) \
> > > $(MESA_TOP)/src/compiler/nir \
> > > $(MESA_TOP)/src/gallium/auxiliary \
> > > $(MESA_TOP)/src/gallium/include
> > > diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
> > > index 1e25f47e50..69f32c6adf 100644
> > > --- a/src/mesa/Makefile.sources
> > > +++ b/src/mesa/Makefile.sources
> > > @@ -689,6 +689,7 @@ INCLUDE_DIRS = \
> > > -I$(top_srcdir)/include \
> > > -I$(top_builddir)/src \
> > > -I$(top_srcdir)/src \
> > > + -I$(top_builddir)/src/compiler \
> > > -I$(top_builddir)/src/compiler/glsl \
> > > -I$(top_builddir)/src/compiler/nir \
> > > -I$(top_builddir)/src/mesa \
> > > diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> > > b/src/mesa/state_tracker/st_glsl_to_nir.cpp
> > > index a1e3b6233c..ad77b746ab 100644
> > > --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> > > +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
> > > @@ -48,7 +48,7 @@
> > > #include "compiler/glsl/ir.h"
> > > #include "compiler/glsl/ir_optimization.h"
> > > #include "compiler/glsl/string_to_uint_map.h"
> > > -#include "compiler/glsl/float64_glsl.h"
> > > +#include "glsl/float64_glsl.h"
> >
> > Looks familiar :)
> >
> > https://github.com/tpalli/external-mesa/commit/ebd8581ad133206ec2b1b818e98dc4f8401af8de
> >
> > Before going further though, I'd like to understand why do we have both
> > 'compiler/glsl/' and 'glsl/' going on. Should we rather put the
> > 'compiler' back in the header generation? I can't remember the full
> > story behind commit c812c740e60 but that one changed this .. perhaps we
> > should pull it back and have the 'compiler/', any objections to that?
> >
>
> I agree that simply continue to have include "compiler/glsl/float64_glsl.h"
> in all sources places would be simpler
> and should not break neither autotools nor meson,
> which may continue to have glsl/float64_glsl.h in their generators
>
> Mauro
I wrote c812, and I'd be very happy to revert it. The problem that I ran into
was putting it in a place that android, meson, and the autotools dist tarball
were happy with. I'm hoping that we can remove autotools in the very near future
and just revert c812 at that time. Does that seem like a reasonable solution?
Dylan
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] svga: silence array out of bounds warning
For the series,
Reviewed-by: Neha Bhende
Regards,
Neha
From: Brian Paul
Sent: Monday, March 4, 2019 9:20 AM
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende
Subject: [PATCH 2/2] svga: silence array out of bounds warning
MinGW release build complains about a possible out-of-bounds
array access. Test i < 4 to silence it.
---
src/gallium/drivers/svga/svga_tgsi_insn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi_insn.c
b/src/gallium/drivers/svga/svga_tgsi_insn.c
index c7804b2..1392a3c 100644
--- a/src/gallium/drivers/svga/svga_tgsi_insn.c
+++ b/src/gallium/drivers/svga/svga_tgsi_insn.c
@@ -2951,7 +2951,7 @@ svga_emit_immediate(struct svga_shader_emitter *emit,
unsigned i;
assert(1 <= imm->Immediate.NrTokens && imm->Immediate.NrTokens <= 5);
- for (i = 0; i < imm->Immediate.NrTokens - 1; i++) {
+ for (i = 0; i < 4 && i < imm->Immediate.NrTokens - 1; i++) {
float f = imm->u[i].Float;
value[i] = util_is_inf_or_nan(f) ? 0.0f : f;
}
--
1.8.5.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] svga: init fill variable to avoid compiler warning
Hi Brian,
For both, if you need:
Reviewed-by: Mathias Fröhlich
best
Mathias
On Monday, 4 March 2019 18:20:57 CET Brian Paul wrote:
> MinGW release builds warns about use of a possbily uninitialized
> variable here.
> ---
> src/gallium/drivers/svga/svga_pipe_rasterizer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/svga/svga_pipe_rasterizer.c
> b/src/gallium/drivers/svga/svga_pipe_rasterizer.c
> index 1dbf5b6..7d5936f 100644
> --- a/src/gallium/drivers/svga/svga_pipe_rasterizer.c
> +++ b/src/gallium/drivers/svga/svga_pipe_rasterizer.c
> @@ -257,7 +257,7 @@ svga_create_rasterizer_state(struct pipe_context *pipe,
> {
>int fill_front = templ->fill_front;
>int fill_back = templ->fill_back;
> - int fill;
> + int fill = PIPE_POLYGON_MODE_FILL;
>boolean offset_front = util_get_offset(templ, fill_front);
>boolean offset_back = util_get_offset(templ, fill_back);
>boolean offset = FALSE;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] svga: silence array out of bounds warning
MinGW release build complains about a possible out-of-bounds
array access. Test i < 4 to silence it.
---
src/gallium/drivers/svga/svga_tgsi_insn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi_insn.c
b/src/gallium/drivers/svga/svga_tgsi_insn.c
index c7804b2..1392a3c 100644
--- a/src/gallium/drivers/svga/svga_tgsi_insn.c
+++ b/src/gallium/drivers/svga/svga_tgsi_insn.c
@@ -2951,7 +2951,7 @@ svga_emit_immediate(struct svga_shader_emitter *emit,
unsigned i;
assert(1 <= imm->Immediate.NrTokens && imm->Immediate.NrTokens <= 5);
- for (i = 0; i < imm->Immediate.NrTokens - 1; i++) {
+ for (i = 0; i < 4 && i < imm->Immediate.NrTokens - 1; i++) {
float f = imm->u[i].Float;
value[i] = util_is_inf_or_nan(f) ? 0.0f : f;
}
--
1.8.5.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] svga: init fill variable to avoid compiler warning
MinGW release builds warns about use of a possbily uninitialized
variable here.
---
src/gallium/drivers/svga/svga_pipe_rasterizer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/svga/svga_pipe_rasterizer.c
b/src/gallium/drivers/svga/svga_pipe_rasterizer.c
index 1dbf5b6..7d5936f 100644
--- a/src/gallium/drivers/svga/svga_pipe_rasterizer.c
+++ b/src/gallium/drivers/svga/svga_pipe_rasterizer.c
@@ -257,7 +257,7 @@ svga_create_rasterizer_state(struct pipe_context *pipe,
{
int fill_front = templ->fill_front;
int fill_back = templ->fill_back;
- int fill;
+ int fill = PIPE_POLYGON_MODE_FILL;
boolean offset_front = util_get_offset(templ, fill_front);
boolean offset_back = util_get_offset(templ, fill_back);
boolean offset = FALSE;
--
1.8.5.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/mesa: Invalidate the gallium array atom only if needed.
Hi, On Friday, 1 March 2019 16:50:13 CET Brian Paul wrote: > The series looks OK to me. > > Reviewed-by: Brian Paul Thanks! Pushed! Mathias > > On 02/28/2019 11:18 PM, mathias.froehl...@gmx.net wrote: > > From: Mathias Fröhlich > > > > Now that the buffer object usage history tracks if it is > > being used as vertex buffer object, we can restrict setting > > the ST_NEW_VERTEX_ARRAYS bit to dirty on glBufferData calls to > > buffers that are potentially used as vertex buffer object. > > Also put a note that the same could be done for index arrays > > used in indexed draws. > > > > Signed-off-by: Mathias Fröhlich > > --- > > src/mesa/state_tracker/st_cb_bufferobjects.c | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c > > b/src/mesa/state_tracker/st_cb_bufferobjects.c > > index 5ebe94f4545..b05f2516980 100644 > > --- a/src/mesa/state_tracker/st_cb_bufferobjects.c > > +++ b/src/mesa/state_tracker/st_cb_bufferobjects.c > > @@ -357,8 +357,10 @@ bufferobj_data(struct gl_context *ctx, > > /* The current buffer may be bound, so we have to revalidate all atoms > > that > > * might be using it. > > */ > > - /* TODO: Add arrays to usage history */ > > - ctx->NewDriverState |= ST_NEW_VERTEX_ARRAYS; > > + if (st_obj->Base.UsageHistory & USAGE_ARRAY_BUFFER) > > + ctx->NewDriverState |= ST_NEW_VERTEX_ARRAYS; > > + /* if (st_obj->Base.UsageHistory & USAGE_ELEMENT_ARRAY_BUFFER) */ > > + /*ctx->NewDriverState |= TODO: Handle indices as gallium state; */ > > if (st_obj->Base.UsageHistory & USAGE_UNIFORM_BUFFER) > > ctx->NewDriverState |= ST_NEW_UNIFORM_BUFFER; > > if (st_obj->Base.UsageHistory & USAGE_SHADER_STORAGE_BUFFER) > > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC] panfrost: Add DRM backend
Hi, the patches in this series get Panfrost working with the DRM driver that Rob Herring and I have been working on lately: https://gitlab.freedesktop.org/panfrost/linux/tree/panfrost-5.0-rc4 I get roughly the same demos working with it as with Arm's driver, but there's lots of improvements to be made (mostly in the kernel) to how memory is managed and jobs are scheduled. The priority right now is to gain some confidence that the UABI is right, and that's why I thought to send the code at this stage. The patches in this MR are needed so the nondrm backend keeps working: https://gitlab.freedesktop.org/panfrost/nondrm/merge_requests/1 Thanks, Tomeu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/8] panfrost: Fix BO import and export
Implement resource_get_handle for non-scanout cases.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_resource.c | 37 +++--
src/gallium/drivers/panfrost/pan_screen.h | 1 +
2 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index a64814902573..abef927ada55 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -68,6 +68,12 @@ panfrost_resource_from_handle(struct pipe_screen *pscreen,
rsc->bo = screen->driver->import_bo(screen, whandle);
+ if (screen->ro) {
+ rsc->scanout =
+ renderonly_create_gpu_import_for_resource(prsc,
screen->ro, NULL);
+ /* failure is expected in some cases.. */
+ }
+
return prsc;
}
@@ -87,17 +93,15 @@ panfrost_resource_get_handle(struct pipe_screen *pscreen,
handle->stride = stride;
handle->modifier = DRM_FORMAT_MOD_INVALID;
-if (handle->type == WINSYS_HANDLE_TYPE_SHARED) {
-printf("Missed shared handle\n");
-return FALSE;
-} else if (handle->type == WINSYS_HANDLE_TYPE_KMS) {
-if (renderonly_get_handle(scanout, handle)) {
-return TRUE;
-} else {
-printf("Missed nonrenderonly KMS handle for resource
%p with scanout %p\n", pt, scanout);
-return FALSE;
-}
-} else if (handle->type == WINSYS_HANDLE_TYPE_FD) {
+ if (handle->type == WINSYS_HANDLE_TYPE_SHARED) {
+ return FALSE;
+ } else if (handle->type == WINSYS_HANDLE_TYPE_KMS) {
+ if (renderonly_get_handle(scanout, handle))
+ return TRUE;
+
+ handle->handle = rsrc->bo->gem_handle;
+ return TRUE;
+ } else if (handle->type == WINSYS_HANDLE_TYPE_FD) {
if (scanout) {
struct drm_prime_handle args = {
.handle = scanout->handle,
@@ -111,14 +115,11 @@ panfrost_resource_get_handle(struct pipe_screen *pscreen,
handle->handle = args.fd;
return TRUE;
-} else {
-printf("Missed nonscanout FD handle\n");
-assert(0);
-return FALSE;
-}
-}
+} else
+ return screen->driver->export_bo(screen,
rsrc->bo->gem_handle, handle);
+ }
-return FALSE;
+ return FALSE;
}
static void
diff --git a/src/gallium/drivers/panfrost/pan_screen.h
b/src/gallium/drivers/panfrost/pan_screen.h
index f109df857c7b..882611e93e3e 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -49,6 +49,7 @@ struct panfrost_screen;
struct panfrost_driver {
struct panfrost_bo * (*import_bo) (struct panfrost_screen *screen,
struct winsys_handle *whandle);
+ int (*export_bo) (struct panfrost_screen *screen, int gem_handle,
struct winsys_handle *whandle);
int (*submit_vs_fs_job) (struct panfrost_context *ctx, bool has_draws,
bool is_scanout);
void (*force_flush_fragment) (struct panfrost_context *ctx,
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/8] panfrost: Free context BOs
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 776469c3e411..ac58411b265d 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -606,7 +606,7 @@ static void
panfrost_invalidate_frame(struct panfrost_context *ctx)
{
unsigned transient_count =
ctx->transient_pools[ctx->cmdstream_i].entry_index*ctx->transient_pools[0].entry_size
+ ctx->transient_pools[ctx->cmdstream_i].entry_offset;
- printf("Uploaded transient %d bytes\n", transient_count);
+ //printf("Uploaded transient %d bytes\n", transient_count);
/* Rotate cmdstream */
if ((++ctx->cmdstream_i) == (sizeof(ctx->transient_pools) /
sizeof(ctx->transient_pools[0])))
@@ -2594,9 +2594,16 @@ static void
panfrost_destroy(struct pipe_context *pipe)
{
struct panfrost_context *panfrost = pan_context(pipe);
+struct panfrost_screen *screen = pan_screen(pipe->screen);
if (panfrost->blitter)
util_blitter_destroy(panfrost->blitter);
+
+screen->driver->free_slab(screen, >scratchpad);
+screen->driver->free_slab(screen, >varying_mem);
+screen->driver->free_slab(screen, >shaders);
+screen->driver->free_slab(screen, >tiler_heap);
+screen->driver->free_slab(screen, >misc_0);
}
static struct pipe_query *
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/8] panfrost: Detect GPU version at runtime
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 19 +--
src/gallium/drivers/panfrost/pan_context.h | 3 +++
src/gallium/drivers/panfrost/pan_screen.h | 1 +
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 4c41969fd051..cfcd4b13f592 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -57,11 +57,6 @@ extern const char *pan_counters_base;
/* TODO: Sample size, etc */
-/* True for t6XX, false for t8xx. TODO: Run-time settable for automatic
- * hardware configuration. */
-
-static bool is_t6xx = false;
-
/* If set, we'll require the use of single render-target framebuffer
* descriptors (SFBD), for older hardware -- specifically, is_t6xx ? 0 : 0x2),
};
memcpy(>payload_vertex, , sizeof(payload));
@@ -847,7 +842,7 @@ panfrost_default_shader_backend(struct panfrost_context
*ctx)
.unknown2_4 = MALI_NO_MSAA | 0x4e0,
};
- if (is_t6xx) {
+ if (ctx->is_t6xx) {
shader.unknown2_4 |= 0x10;
}
@@ -1360,7 +1355,7 @@ panfrost_emit_for_draw(struct panfrost_context *ctx, bool
with_vertex_data)
int s =
ctx->sampler_views[t][i]->hw.nr_mipmap_levels;
if (!rsrc->bo->is_mipmap) {
-if (is_t6xx) {
+if (ctx->is_t6xx) {
/* HW ERRATA, not needed after
t6XX */
ctx->sampler_views[t][i]->hw.swizzled_bitmaps[1] = rsrc->bo->gpu[0];
@@ -1375,7 +1370,7 @@ panfrost_emit_for_draw(struct panfrost_context *ctx, bool
with_vertex_data)
/* Restore */
ctx->sampler_views[t][i]->hw.nr_mipmap_levels
= s;
- if (is_t6xx) {
+ if (ctx->is_t6xx) {
ctx->sampler_views[t][i]->hw.unknown3A
= 0;
}
}
@@ -1827,12 +1822,13 @@ panfrost_create_rasterizer_state(
struct pipe_context *pctx,
const struct pipe_rasterizer_state *cso)
{
+struct panfrost_context *ctx = pan_context(pctx);
struct panfrost_rasterizer *so = CALLOC_STRUCT(panfrost_rasterizer);
so->base = *cso;
/* Bitmask, unknown meaning of the start value */
-so->tiler_gl_enables = is_t6xx ? 0x105 : 0x7;
+so->tiler_gl_enables = ctx->is_t6xx ? 0x105 : 0x7;
so->tiler_gl_enables |= MALI_FRONT_FACE(
cso->front_ccw ? MALI_CCW : MALI_CW);
@@ -2724,9 +2720,12 @@ struct pipe_context *
panfrost_create_context(struct pipe_screen *screen, void *priv, unsigned flags)
{
struct panfrost_context *ctx = CALLOC_STRUCT(panfrost_context);
+struct panfrost_screen *pscreen = pan_screen(screen);
memset(ctx, 0, sizeof(*ctx));
struct pipe_context *gallium = (struct pipe_context *) ctx;
+ctx->is_t6xx = pscreen->driver->query_gpu_version(pscreen) == 0x0750;
+
gallium->screen = screen;
gallium->destroy = panfrost_destroy;
diff --git a/src/gallium/drivers/panfrost/pan_context.h
b/src/gallium/drivers/panfrost/pan_context.h
index b1a0a09146da..a809f207d46b 100644
--- a/src/gallium/drivers/panfrost/pan_context.h
+++ b/src/gallium/drivers/panfrost/pan_context.h
@@ -208,6 +208,9 @@ struct panfrost_context {
struct pipe_blend_color blend_color;
struct pipe_depth_stencil_alpha_state *depth_stencil;
struct pipe_stencil_ref stencil_ref;
+
+/* True for t6XX, false for t8xx. */
+bool is_t6xx;
};
/* Corresponds to the CSO */
diff --git a/src/gallium/drivers/panfrost/pan_screen.h
b/src/gallium/drivers/panfrost/pan_screen.h
index 0005b2feb156..002c430cacbc 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -65,6 +65,7 @@ struct panfrost_driver {
struct panfrost_bo *bo);
void (*enable_counters) (struct panfrost_screen *screen);
void (*dump_counters) (struct panfrost_screen *screen);
+ unsigned (*query_gpu_version) (struct panfrost_screen *screen);
};
struct panfrost_screen {
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/8] panfrost: Add gem_handle to panfrost_memory and panfrost_bo
It will be used by the DRM backend to store GEM handles from the kernel.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_allocate.h | 1 +
src/gallium/drivers/panfrost/pan_resource.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_allocate.h
b/src/gallium/drivers/panfrost/pan_allocate.h
index 2084a3395521..5bbb1e4b078d 100644
--- a/src/gallium/drivers/panfrost/pan_allocate.h
+++ b/src/gallium/drivers/panfrost/pan_allocate.h
@@ -67,6 +67,7 @@ struct panfrost_memory {
mali_ptr gpu;
int stack_bottom;
size_t size;
+int gem_handle;
};
/* Slab entry sizes range from 2^min to 2^max. In this case, we range from 1k
diff --git a/src/gallium/drivers/panfrost/pan_resource.h
b/src/gallium/drivers/panfrost/pan_resource.h
index b0b5cc15a0c5..633f185ab5b9 100644
--- a/src/gallium/drivers/panfrost/pan_resource.h
+++ b/src/gallium/drivers/panfrost/pan_resource.h
@@ -69,6 +69,8 @@ struct panfrost_bo {
bool has_checksum;
struct panfrost_memory checksum_slab;
int checksum_stride;
+
+int gem_handle;
};
struct panfrost_resource {
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver
This backend interacts with the new DRM driver for Midgard GPUs which is
currently in development.
When using this backend, Panfrost has roughly on-par functionality as
when using the non-DRM driver from Arm.
Signed-off-by: Tomeu Vizoso
---
include/drm-uapi/panfrost_drm.h| 128 +
src/gallium/drivers/panfrost/pan_drm.c | 362 +
2 files changed, 490 insertions(+)
create mode 100644 include/drm-uapi/panfrost_drm.h
diff --git a/include/drm-uapi/panfrost_drm.h b/include/drm-uapi/panfrost_drm.h
new file mode 100644
index ..d4d271e37206
--- /dev/null
+++ b/include/drm-uapi/panfrost_drm.h
@@ -0,0 +1,128 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/* Copyright 2018, Linaro, Ltd., Rob Herring */
+
+#ifndef __PANFROST_DRM_H__
+#define __PANFROST_DRM_H__
+
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+/* timeouts are specified in clock-monotonic absolute times (to simplify
+ * restarting interrupted ioctls). The following struct is logically the
+ * same as 'struct timespec' but 32/64b ABI safe.
+ */
+struct drm_panfrost_timespec {
+ __s64 tv_sec; /* seconds */
+ __s64 tv_nsec; /* nanoseconds */
+};
+
+#define PANFROST_PARAM_GPU_ID 0x01
+
+struct drm_panfrost_get_param {
+ __u32 param;/* in */
+ __u32 pad;
+ __u64 value;/* out */
+};
+
+struct drm_panfrost_gem_new {
+ __u64 size; /* in */
+ __u32 flags; /* in, mask of ETNA_BO_x */
+ __u32 handle; /* out */
+ /**
+* Returned offset for the BO in the GPU address space. This offset
+* is private to the DRM fd and is valid for the lifetime of the GEM
+* handle.
+*
+* This offset value will always be nonzero, since various HW
+* units treat 0 specially.
+*/
+ __u64 offset;
+};
+struct drm_panfrost_gem_info {
+ __u32 handle; /* in */
+ __u32 pad;
+ __u64 offset; /* out, offset to pass to mmap() */
+};
+
+/**
+ * Returns the offset for the BO in the GPU address space for this DRM fd.
+ * This is the same value returned by drm_panfrost_gem_new, if that was called
+ * from this DRM fd.
+ */
+struct drm_panfrost_get_bo_offset {
+ __u32 handle;
+ __u32 pad;
+ __u64 offset;
+};
+
+
+#define ETNA_PREP_READ0x01
+#define ETNA_PREP_WRITE 0x02
+#define ETNA_PREP_NOSYNC 0x04
+
+struct drm_panfrost_gem_cpu_prep {
+ __u32 handle; /* in */
+ __u32 op; /* in, mask of ETNA_PREP_x */
+ struct drm_panfrost_timespec timeout; /* in */
+};
+
+struct drm_panfrost_gem_cpu_fini {
+ __u32 handle; /* in */
+ __u32 flags; /* in, placeholder for now, no defined values */
+};
+
+/*
+ * Cmdstream Submission:
+ */
+
+#define PANFROST_JD_REQ_FS (1 << 0)
+
+#define PANFROST_DEP_TYPE_ORDER0x01
+#define PANFROST_DEP_TYPE_DATA 0x02
+
+struct drm_panfrost_gem_submit_atom_dep {
+ __u32 atom_nr; /* job ID of dependency */
+ __u32 type; /* one of PANFROST_DEP_TYPE_* */
+};
+
+struct drm_panfrost_gem_submit_atom {
+ __u64 jc; /* in, address to GPU mapping of job descriptor */
+ __u32 atom_nr; /* in, job ID */
+ __u32 requirements; /* in, a combination of PANFROST_JD_REQ_* */
+ __u64 bo_handles;
+ __u32 bo_handle_count;
+ struct drm_panfrost_gem_submit_atom_dep deps[2];
+};
+
+struct drm_panfrost_gem_submit {
+ __u32 nr_atoms; /* in, number of submit_atom */
+ __u32 pad;
+ __u64 atoms;/* in, ptr to array of submit_atom */
+};
+
+
+
+#define DRM_PANFROST_GET_PARAM 0x00
+#define DRM_PANFROST_GEM_NEW 0x01
+#define DRM_PANFROST_GEM_INFO 0x02
+#define DRM_PANFROST_GEM_CPU_PREP 0x03
+#define DRM_PANFROST_GEM_CPU_FINI 0x04
+#define DRM_PANFROST_GEM_SUBMIT0x05
+#define DRM_PANFROST_GET_BO_OFFSET 0x06
+
+#define DRM_IOCTL_PANFROST_GET_PARAM DRM_IOWR(DRM_COMMAND_BASE +
DRM_PANFROST_GET_PARAM, struct drm_panfrost_get_param)
+#define DRM_IOCTL_PANFROST_GEM_NEW DRM_IOWR(DRM_COMMAND_BASE +
DRM_PANFROST_GEM_NEW, struct drm_panfrost_gem_new)
+#define DRM_IOCTL_PANFROST_GEM_INFODRM_IOWR(DRM_COMMAND_BASE +
DRM_PANFROST_GEM_INFO, struct drm_panfrost_gem_info)
+#define DRM_IOCTL_PANFROST_GEM_CPU_PREPDRM_IOW(DRM_COMMAND_BASE +
DRM_PANFROST_GEM_CPU_PREP, struct drm_panfrost_gem_cpu_prep)
+#define DRM_IOCTL_PANFROST_GEM_CPU_FINIDRM_IOW(DRM_COMMAND_BASE +
DRM_PANFROST_GEM_CPU_FINI, struct drm_panfrost_gem_cpu_fini)
+#define DRM_IOCTL_PANFROST_GEM_SUBMIT DRM_IOW(DRM_COMMAND_BASE +
DRM_PANFROST_GEM_SUBMIT, struct drm_panfrost_gem_submit)
+#define DRM_IOCTL_PANFROST_GET_BO_OFFSET DRM_IOWR(DRM_COMMAND_BASE +
DRM_PANFROST_GET_BO_OFFSET, struct drm_panfrost_get_bo_offset)
+
+#if defined(__cplusplus)
+}
+#endif
+
+#endif /*
[Mesa-dev] [PATCH 3/8] panfrost: remove use of duplicate function panfrost_screen
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_allocate.c | 4 ++--
src/gallium/drivers/panfrost/pan_resource.c | 2 +-
src/gallium/drivers/panfrost/pan_screen.h| 6 --
src/gallium/drivers/panfrost/pan_wallpaper.c | 2 +-
4 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_allocate.c
b/src/gallium/drivers/panfrost/pan_allocate.c
index 3732d253978a..91ace74d0e43 100644
--- a/src/gallium/drivers/panfrost/pan_allocate.c
+++ b/src/gallium/drivers/panfrost/pan_allocate.c
@@ -41,7 +41,7 @@ panfrost_allocate_chunk(struct panfrost_context *ctx, size_t
size, unsigned heap
size = ALIGN(size, ALIGNMENT);
struct pipe_context *gallium = (struct pipe_context *) ctx;
-struct panfrost_screen *screen = panfrost_screen(gallium->screen);
+struct panfrost_screen *screen = pan_screen(gallium->screen);
struct pb_slab_entry *entry = pb_slab_alloc(>slabs, size,
heap_id);
struct panfrost_memory_entry *p_entry = (struct panfrost_memory_entry
*) entry;
@@ -81,7 +81,7 @@ panfrost_allocate_transient(struct panfrost_context *ctx,
size_t sz)
if (pool->entry_index >= pool->entry_count) {
/* Don't overflow the pool -- allocate a new one */
struct pipe_context *gallium = (struct pipe_context *)
ctx;
-struct panfrost_screen *screen =
panfrost_screen(gallium->screen);
+struct panfrost_screen *screen =
pan_screen(gallium->screen);
struct pb_slab_entry *entry =
pb_slab_alloc(>slabs, pool->entry_size, HEAP_TRANSIENT);
pool->entry_count++;
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index f26f33db96b6..a64814902573 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -322,7 +322,7 @@ static void
panfrost_resource_destroy(struct pipe_screen *screen,
struct pipe_resource *pt)
{
-struct panfrost_screen *pscreen = panfrost_screen(screen);
+struct panfrost_screen *pscreen = pan_screen(screen);
struct panfrost_resource *rsrc = (struct panfrost_resource *) pt;
if (rsrc->scanout)
diff --git a/src/gallium/drivers/panfrost/pan_screen.h
b/src/gallium/drivers/panfrost/pan_screen.h
index 002c430cacbc..576dca11dc7b 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -86,10 +86,4 @@ struct panfrost_screen {
int last_fragment_flushed;
};
-static inline struct panfrost_screen *
-panfrost_screen( struct pipe_screen *pipe )
-{
-return (struct panfrost_screen *)pipe;
-}
-
#endif /* PAN_SCREEN_H */
diff --git a/src/gallium/drivers/panfrost/pan_wallpaper.c
b/src/gallium/drivers/panfrost/pan_wallpaper.c
index 735524a49c9c..48418012fe84 100644
--- a/src/gallium/drivers/panfrost/pan_wallpaper.c
+++ b/src/gallium/drivers/panfrost/pan_wallpaper.c
@@ -181,7 +181,7 @@ panfrost_draw_wallpaper(struct pipe_context *pipe)
.normalized_coords = 1
};
-struct pipe_resource *rsrc =
panfrost_screen(pipe->screen)->display_target;
+struct pipe_resource *rsrc = pan_screen(pipe->screen)->display_target;
struct pipe_sampler_state *sampler_state =
pipe->create_sampler_state(pipe, );
struct pipe_sampler_view *sampler_view =
pipe->create_sampler_view(pipe, rsrc, );
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/8] panfrost: Pass the fence down when flushing
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 11 +++
src/gallium/drivers/panfrost/pan_context.h | 7 +++
src/gallium/drivers/panfrost/pan_screen.c | 11 ++-
src/gallium/drivers/panfrost/pan_screen.h | 11 ++-
4 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index cfcd4b13f592..b419f25224f2 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1529,7 +1529,8 @@ panfrost_link_jobs(struct panfrost_context *ctx)
/* The entire frame is in memory -- send it off to the kernel! */
static void
-panfrost_submit_frame(struct panfrost_context *ctx, bool flush_immediate)
+panfrost_submit_frame(struct panfrost_context *ctx, bool flush_immediate,
+ struct pipe_fence_handle **fence)
{
struct pipe_context *gallium = (struct pipe_context *) ctx;
struct panfrost_screen *screen = pan_screen(gallium->screen);
@@ -1556,14 +1557,14 @@ panfrost_submit_frame(struct panfrost_context *ctx,
bool flush_immediate)
/* If visual, we can stall a frame */
if (!flush_immediate)
-screen->driver->force_flush_fragment(ctx);
+screen->driver->force_flush_fragment(ctx, fence);
screen->last_fragment_id = fragment_id;
screen->last_fragment_flushed = false;
/* If readback, flush now (hurts the pipelined performance) */
if (flush_immediate)
-screen->driver->force_flush_fragment(ctx);
+screen->driver->force_flush_fragment(ctx, fence);
if (screen->driver->dump_counters && pan_counters_base) {
screen->driver->dump_counters(screen);
@@ -1594,7 +1595,7 @@ panfrost_flush(
bool flush_immediate = flags & PIPE_FLUSH_END_OF_FRAME;
/* Submit the frame itself */
-panfrost_submit_frame(ctx, flush_immediate);
+panfrost_submit_frame(ctx, flush_immediate, fence);
/* Prepare for the next frame */
panfrost_invalidate_frame(ctx);
@@ -2791,6 +2792,8 @@ panfrost_create_context(struct pipe_screen *screen, void
*priv, unsigned flags)
panfrost_resource_context_init(gallium);
+pscreen->driver->init_context(ctx);
+
panfrost_setup_hardware(ctx);
/* XXX: leaks */
diff --git a/src/gallium/drivers/panfrost/pan_context.h
b/src/gallium/drivers/panfrost/pan_context.h
index a809f207d46b..adc53a3bfae4 100644
--- a/src/gallium/drivers/panfrost/pan_context.h
+++ b/src/gallium/drivers/panfrost/pan_context.h
@@ -74,6 +74,11 @@ struct panfrost_query {
struct panfrost_transfer transfer;
};
+struct panfrost_fence {
+struct pipe_reference reference;
+int fd;
+};
+
#define PANFROST_MAX_TRANSIENT_ENTRIES 64
struct panfrost_transient_pool {
@@ -211,6 +216,8 @@ struct panfrost_context {
/* True for t6XX, false for t8xx. */
bool is_t6xx;
+
+ __u32 out_sync;
};
/* Corresponds to the CSO */
diff --git a/src/gallium/drivers/panfrost/pan_screen.c
b/src/gallium/drivers/panfrost/pan_screen.c
index f77bb11ffda4..3d13c3e924d2 100644
--- a/src/gallium/drivers/panfrost/pan_screen.c
+++ b/src/gallium/drivers/panfrost/pan_screen.c
@@ -503,21 +503,22 @@ panfrost_get_timestamp(struct pipe_screen *_screen)
}
static void
-panfrost_fence_reference(struct pipe_screen *screen,
+panfrost_fence_reference(struct pipe_screen *pscreen,
struct pipe_fence_handle **ptr,
struct pipe_fence_handle *fence)
{
-*ptr = fence;
+struct panfrost_screen *screen = pan_screen(pscreen);
+screen->driver->fence_reference(pscreen, ptr, fence);
}
static boolean
-panfrost_fence_finish(struct pipe_screen *screen,
+panfrost_fence_finish(struct pipe_screen *pscreen,
struct pipe_context *ctx,
struct pipe_fence_handle *fence,
uint64_t timeout)
{
-assert(fence);
-return TRUE;
+struct panfrost_screen *screen = pan_screen(pscreen);
+return screen->driver->fence_finish(pscreen, ctx, fence, timeout);
}
static const void *
diff --git a/src/gallium/drivers/panfrost/pan_screen.h
b/src/gallium/drivers/panfrost/pan_screen.h
index 576dca11dc7b..f109df857c7b 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -51,7 +51,8 @@ struct panfrost_driver {
struct panfrost_bo * (*import_bo) (struct panfrost_screen *screen,
struct winsys_handle *whandle);
int (*submit_vs_fs_job) (struct panfrost_context *ctx, bool has_draws,
bool is_scanout);
- void (*force_flush_fragment) (struct panfrost_context *ctx);
+ void (*force_flush_fragment) (struct panfrost_context *ctx,
+ struct
[Mesa-dev] [PATCH 5/8] panfrost: Store GEM handle of AFBC BOs
Signed-off-by: Tomeu Vizoso --- src/gallium/drivers/panfrost/pan_context.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/panfrost/pan_context.c b/src/gallium/drivers/panfrost/pan_context.c index b419f25224f2..776469c3e411 100644 --- a/src/gallium/drivers/panfrost/pan_context.c +++ b/src/gallium/drivers/panfrost/pan_context.c @@ -115,6 +115,7 @@ panfrost_enable_afbc(struct panfrost_context *ctx, struct panfrost_resource *rsr true, 0, 0, 0); rsrc->bo->has_afbc = true; +rsrc->bo->gem_handle = rsrc->bo->afbc_slab.gem_handle; /* Compressed textured reads use a tagged pointer to the metadata */ -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] radv: properly align the fence and EOP bug VA on GFX9
If alignement is 0, offets returned by
radv_cmd_buffer_upload_alloc() are always 0. These two
virtual addresses were pointing at the same location.
v2: - add an asertion that checks if alignment is power of two
Cc: 18.3 19.0
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index ad0b934ddfc..7cc7b3b9195 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -338,14 +338,15 @@ radv_reset_cmd_buffer(struct radv_cmd_buffer *cmd_buffer)
unsigned fence_offset, eop_bug_offset;
void *fence_ptr;
- radv_cmd_buffer_upload_alloc(cmd_buffer, 8, 0, _offset,
+ radv_cmd_buffer_upload_alloc(cmd_buffer, 8, 8, _offset,
_ptr);
+
cmd_buffer->gfx9_fence_va =
radv_buffer_get_va(cmd_buffer->upload.upload_bo);
cmd_buffer->gfx9_fence_va += fence_offset;
/* Allocate a buffer for the EOP bug on GFX9. */
- radv_cmd_buffer_upload_alloc(cmd_buffer, 16 * num_db, 0,
+ radv_cmd_buffer_upload_alloc(cmd_buffer, 16 * num_db, 8,
_bug_offset, _ptr);
cmd_buffer->gfx9_eop_bug_va =
radv_buffer_get_va(cmd_buffer->upload.upload_bo);
@@ -416,6 +417,8 @@ radv_cmd_buffer_upload_alloc(struct radv_cmd_buffer
*cmd_buffer,
unsigned *out_offset,
void **ptr)
{
+ assert(util_is_power_of_two_nonzero(alignment));
+
uint64_t offset = align(cmd_buffer->upload.offset, alignment);
if (offset + size > cmd_buffer->upload.size) {
if (!radv_cmd_buffer_resize_upload_buf(cmd_buffer, size))
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] android: anv: fix generated files depedencies (v2)
Reviewed-by: Tapani Pälli
On 3/4/19 2:45 PM, Mauro Rossi wrote:
Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and python scripts
Align the building rules as per Automake for simplification
Fixes building errors during rebuils due to missing dependencies
(v2) Fixed a missing $(VULKAN_API_XML) reference
Fixes: 9a508b7 ("android: anv/extensions: fix generated sources build")
Fixes: dd088d4bec7 ("anv/extensions: Generate a header file with extension
tables")
Signed-off-by: Mauro Rossi
Cc: "19.0"
---
src/intel/Android.vulkan.mk | 40 +++--
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 04c9d5b3e4..9fdb8debf2 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -23,9 +23,10 @@ LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
include $(LOCAL_PATH)/Makefile.sources
-VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
-
-VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2)
$(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_ENTRYPOINTS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
+ANV_EXTENSIONS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_EXTENSIONS_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions.py
+VULKAN_API_XML := $(MESA_TOP)/src/vulkan/registry/vk.xml
VULKAN_COMMON_INCLUDES := \
$(MESA_TOP)/include \
@@ -64,10 +65,13 @@ $(intermediates)/vulkan/dummy.c:
@echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
$(hide) touch $@
-$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c
- $(VK_ENTRYPOINTS_SCRIPT) \
+$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c \
+ $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
+ $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
--outdir $(dir $@) \
- --xml $(MESA_TOP)/src/vulkan/registry/vk.xml
+ --xml $(VULKAN_API_XML)
LOCAL_EXPORT_C_INCLUDE_DIRS := \
$(intermediates)
@@ -241,22 +245,28 @@ LOCAL_GENERATED_SOURCES +=
$(intermediates)/vulkan/anv_entrypoints.c
LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.c
LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.h
-$(intermediates)/vulkan/anv_entrypoints.c:
+$(intermediates)/vulkan/anv_entrypoints.c: $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
@mkdir -p $(dir $@)
- $(VK_ENTRYPOINTS_SCRIPT) \
- --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+ $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+ --xml $(VULKAN_API_XML) \
--outdir $(dir $@)
-$(intermediates)/vulkan/anv_extensions.c:
+$(intermediates)/vulkan/anv_extensions.c: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
@mkdir -p $(dir $@)
- $(VK_EXTENSIONS_SCRIPT) \
- --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+ $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ --xml $(VULKAN_API_XML) \
--out-c $@
-$(intermediates)/vulkan/anv_extensions.h:
+$(intermediates)/vulkan/anv_extensions.h: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
@mkdir -p $(dir $@)
- $(VK_EXTENSIONS_SCRIPT) \
- --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+ $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ --xml $(VULKAN_API_XML) \
--out-h $@
LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] android: anv: fix generated files depedencies (v2)
Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and python scripts
Align the building rules as per Automake for simplification
Fixes building errors during rebuils due to missing dependencies
(v2) Fixed a missing $(VULKAN_API_XML) reference
Fixes: 9a508b7 ("android: anv/extensions: fix generated sources build")
Fixes: dd088d4bec7 ("anv/extensions: Generate a header file with extension
tables")
Signed-off-by: Mauro Rossi
Cc: "19.0"
---
src/intel/Android.vulkan.mk | 40 +++--
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 04c9d5b3e4..9fdb8debf2 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -23,9 +23,10 @@ LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
include $(LOCAL_PATH)/Makefile.sources
-VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2)
$(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
-
-VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2)
$(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_ENTRYPOINTS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
+ANV_EXTENSIONS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_EXTENSIONS_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions.py
+VULKAN_API_XML := $(MESA_TOP)/src/vulkan/registry/vk.xml
VULKAN_COMMON_INCLUDES := \
$(MESA_TOP)/include \
@@ -64,10 +65,13 @@ $(intermediates)/vulkan/dummy.c:
@echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
$(hide) touch $@
-$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c
- $(VK_ENTRYPOINTS_SCRIPT) \
+$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c \
+ $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
+ $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
--outdir $(dir $@) \
- --xml $(MESA_TOP)/src/vulkan/registry/vk.xml
+ --xml $(VULKAN_API_XML)
LOCAL_EXPORT_C_INCLUDE_DIRS := \
$(intermediates)
@@ -241,22 +245,28 @@ LOCAL_GENERATED_SOURCES +=
$(intermediates)/vulkan/anv_entrypoints.c
LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.c
LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.h
-$(intermediates)/vulkan/anv_entrypoints.c:
+$(intermediates)/vulkan/anv_entrypoints.c: $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
@mkdir -p $(dir $@)
- $(VK_ENTRYPOINTS_SCRIPT) \
- --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+ $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+ --xml $(VULKAN_API_XML) \
--outdir $(dir $@)
-$(intermediates)/vulkan/anv_extensions.c:
+$(intermediates)/vulkan/anv_extensions.c: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
@mkdir -p $(dir $@)
- $(VK_EXTENSIONS_SCRIPT) \
- --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+ $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ --xml $(VULKAN_API_XML) \
--out-c $@
-$(intermediates)/vulkan/anv_extensions.h:
+$(intermediates)/vulkan/anv_extensions.h: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
@mkdir -p $(dir $@)
- $(VK_EXTENSIONS_SCRIPT) \
- --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+ $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ --xml $(VULKAN_API_XML) \
--out-h $@
LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 3/3] intel/compiler: implement more algebraic optimizations
Now that we propagate constants to the first source of 2src instructions we
see more opportunities of constant folding in the backend.
v2:
- The hardware only uses 5 bits (or 6 bits for Q/UQ) from the shift
count parameter in SHL/SHR instructions, so do the same in constant
propagation (Ian)
---
src/intel/compiler/brw_fs.cpp | 203 --
1 file changed, 195 insertions(+), 8 deletions(-)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index bd588b55bde..f09320b4127 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -2583,9 +2583,55 @@ fs_visitor::opt_algebraic()
break;
case BRW_OPCODE_MUL:
- if (inst->src[1].file != IMM)
+ if (inst->src[0].file != IMM && inst->src[1].file != IMM)
continue;
+ /* Constant folding */
+ if (inst->src[0].file == IMM && inst->src[1].file == IMM) {
+assert(inst->src[0].type == inst->src[1].type);
+bool local_progress = true;
+switch (inst->src[0].type) {
+case BRW_REGISTER_TYPE_HF: {
+ float v1 = _mesa_half_to_float(inst->src[0].ud & 0xu);
+ float v2 = _mesa_half_to_float(inst->src[1].ud & 0xu);
+ inst->src[0] = brw_imm_w(_mesa_float_to_half(v1 * v2));
+ break;
+}
+case BRW_REGISTER_TYPE_W: {
+ int16_t v1 = inst->src[0].ud & 0xu;
+ int16_t v2 = inst->src[1].ud & 0xu;
+ inst->src[0] = brw_imm_w(v1 * v2);
+ break;
+}
+case BRW_REGISTER_TYPE_UW: {
+ uint16_t v1 = inst->src[0].ud & 0xu;
+ uint16_t v2 = inst->src[1].ud & 0xu;
+ inst->src[0] = brw_imm_uw(v1 * v2);
+ break;
+}
+case BRW_REGISTER_TYPE_F:
+ inst->src[0].f *= inst->src[1].f;
+ break;
+case BRW_REGISTER_TYPE_D:
+ inst->src[0].d *= inst->src[1].d;
+ break;
+case BRW_REGISTER_TYPE_UD:
+ inst->src[0].ud *= inst->src[1].ud;
+ break;
+default:
+ local_progress = false;
+ break;
+};
+
+if (local_progress) {
+ inst->opcode = BRW_OPCODE_MOV;
+ inst->src[1] = reg_undef;
+ progress = true;
+ break;
+}
+ }
+
+
/* a * 1.0 = a */
if (inst->src[1].is_one()) {
inst->opcode = BRW_OPCODE_MOV;
@@ -2594,6 +2640,14 @@ fs_visitor::opt_algebraic()
break;
}
+ if (inst->src[0].is_one()) {
+inst->opcode = BRW_OPCODE_MOV;
+inst->src[0] = inst->src[1];
+inst->src[1] = reg_undef;
+progress = true;
+break;
+ }
+
/* a * -1.0 = -a */
if (inst->src[1].is_negative_one()) {
inst->opcode = BRW_OPCODE_MOV;
@@ -2603,27 +2657,160 @@ fs_visitor::opt_algebraic()
break;
}
- if (inst->src[0].file == IMM &&
- inst->src[0].type == BRW_REGISTER_TYPE_F) {
+ if (inst->src[0].is_negative_one()) {
+inst->opcode = BRW_OPCODE_MOV;
+inst->src[0] = inst->src[1];
+inst->src[0].negate = !inst->src[1].negate;
+inst->src[1] = reg_undef;
+progress = true;
+break;
+ }
+
+ /* a * 0 = 0 (this is not exact for floating point) */
+ if (inst->src[1].is_zero() &&
+ brw_reg_type_is_integer(inst->src[1].type)) {
+inst->opcode = BRW_OPCODE_MOV;
+inst->src[0] = inst->src[1];
+inst->src[1] = reg_undef;
+progress = true;
+break;
+ }
+
+ if (inst->src[0].is_zero() &&
+ brw_reg_type_is_integer(inst->src[0].type)) {
inst->opcode = BRW_OPCODE_MOV;
-inst->src[0].f *= inst->src[1].f;
inst->src[1] = reg_undef;
progress = true;
break;
}
break;
case BRW_OPCODE_ADD:
- if (inst->src[1].file != IMM)
+ if (inst->src[0].file != IMM && inst->src[1].file != IMM)
continue;
- if (inst->src[0].file == IMM &&
- inst->src[0].type == BRW_REGISTER_TYPE_F) {
+ /* Constant folding */
+ if (inst->src[0].file == IMM && inst->src[1].file == IMM) {
+assert(inst->src[0].type == inst->src[1].type);
+bool local_progress = true;
+switch (inst->src[0].type) {
+case BRW_REGISTER_TYPE_HF: {
+ float v1 = _mesa_half_to_float(inst->src[0].ud & 0xu);
+ float v2 = _mesa_half_to_float(inst->src[1].ud & 0xu);
+ inst->src[0] = brw_imm_w(_mesa_float_to_half(v1 + v2));
+
[Mesa-dev] [PATCH v2 1/3] intel/compiler: allow constant propagation for int quotient and reminder
And let combine constants promote the constants if needed.
---
src/intel/compiler/brw_fs_combine_constants.cpp | 2 ++
src/intel/compiler/brw_fs_copy_propagation.cpp | 4
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/intel/compiler/brw_fs_combine_constants.cpp
b/src/intel/compiler/brw_fs_combine_constants.cpp
index db7b14a8312..a26eb67a00a 100644
--- a/src/intel/compiler/brw_fs_combine_constants.cpp
+++ b/src/intel/compiler/brw_fs_combine_constants.cpp
@@ -69,6 +69,8 @@ static bool
must_promote_imm(const struct gen_device_info *devinfo, const fs_inst *inst)
{
switch (inst->opcode) {
+ case SHADER_OPCODE_INT_QUOTIENT:
+ case SHADER_OPCODE_INT_REMAINDER:
case SHADER_OPCODE_POW:
return devinfo->gen < 8;
case BRW_OPCODE_MAD:
diff --git a/src/intel/compiler/brw_fs_copy_propagation.cpp
b/src/intel/compiler/brw_fs_copy_propagation.cpp
index 8b904ab356b..c11b05b128a 100644
--- a/src/intel/compiler/brw_fs_copy_propagation.cpp
+++ b/src/intel/compiler/brw_fs_copy_propagation.cpp
@@ -611,10 +611,6 @@ fs_visitor::try_constant_propagate(fs_inst *inst,
acp_entry *entry)
case SHADER_OPCODE_INT_QUOTIENT:
case SHADER_OPCODE_INT_REMAINDER:
- /* FINISHME: Promote non-float constants and remove this. */
- if (devinfo->gen < 8)
-break;
- /* fallthrough */
case SHADER_OPCODE_POW:
/* Allow constant propagation into src1 (except on Gen 6 which
* doesn't support scalar source math), and let constant combining
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/3] intel/compiler: allow constant propagation to first source of 2src instructions
Even if it is not supported by the hardware, we will fix it up
in the combine constants pass.
v2:
- This will enable new constant folding opportunities in the algebraic pass
for MUL or ADD with types other than F, so do not assert on that type.
For now we just skip anything that is not float and a later patch will
expand the algebraic pass to support more constant folding scenarios.
---
src/intel/compiler/brw_fs.cpp | 8 +--
.../compiler/brw_fs_combine_constants.cpp | 37 ++---
.../compiler/brw_fs_copy_propagation.cpp | 55 +--
3 files changed, 60 insertions(+), 40 deletions(-)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 2358acbeb59..bd588b55bde 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -2603,8 +2603,8 @@ fs_visitor::opt_algebraic()
break;
}
- if (inst->src[0].file == IMM) {
-assert(inst->src[0].type == BRW_REGISTER_TYPE_F);
+ if (inst->src[0].file == IMM &&
+ inst->src[0].type == BRW_REGISTER_TYPE_F) {
inst->opcode = BRW_OPCODE_MOV;
inst->src[0].f *= inst->src[1].f;
inst->src[1] = reg_undef;
@@ -2616,8 +2616,8 @@ fs_visitor::opt_algebraic()
if (inst->src[1].file != IMM)
continue;
- if (inst->src[0].file == IMM) {
-assert(inst->src[0].type == BRW_REGISTER_TYPE_F);
+ if (inst->src[0].file == IMM &&
+ inst->src[0].type == BRW_REGISTER_TYPE_F) {
inst->opcode = BRW_OPCODE_MOV;
inst->src[0].f += inst->src[1].f;
inst->src[1] = reg_undef;
diff --git a/src/intel/compiler/brw_fs_combine_constants.cpp
b/src/intel/compiler/brw_fs_combine_constants.cpp
index a26eb67a00a..bb155caeccf 100644
--- a/src/intel/compiler/brw_fs_combine_constants.cpp
+++ b/src/intel/compiler/brw_fs_combine_constants.cpp
@@ -66,13 +66,31 @@ could_coissue(const struct gen_device_info *devinfo, const
fs_inst *inst)
* Returns true for instructions that don't support immediate sources.
*/
static bool
-must_promote_imm(const struct gen_device_info *devinfo, const fs_inst *inst)
+must_promote_imm(const struct gen_device_info *devinfo,
+ const fs_inst *inst, const int src_idx)
{
switch (inst->opcode) {
case SHADER_OPCODE_INT_QUOTIENT:
case SHADER_OPCODE_INT_REMAINDER:
case SHADER_OPCODE_POW:
- return devinfo->gen < 8;
+ return src_idx != 1 || devinfo->gen < 8;
+ case BRW_OPCODE_BFI1:
+ case BRW_OPCODE_ASR:
+ case BRW_OPCODE_SHL:
+ case BRW_OPCODE_SHR:
+ case BRW_OPCODE_SUBB:
+ case BRW_OPCODE_MACH:
+ case BRW_OPCODE_MUL:
+ case SHADER_OPCODE_MULH:
+ case BRW_OPCODE_ADD:
+ case BRW_OPCODE_OR:
+ case BRW_OPCODE_AND:
+ case BRW_OPCODE_XOR:
+ case BRW_OPCODE_ADDC:
+ case BRW_OPCODE_CMP:
+ case BRW_OPCODE_IF:
+ case BRW_OPCODE_SEL:
+ return src_idx != 1;
case BRW_OPCODE_MAD:
case BRW_OPCODE_LRP:
return true;
@@ -335,13 +353,18 @@ fs_visitor::opt_combine_constants()
foreach_block_and_inst(block, fs_inst, inst, cfg) {
ip++;
- if (!could_coissue(devinfo, inst) && !must_promote_imm(devinfo, inst))
+ const bool is_coissue_candidate = could_coissue(devinfo, inst);
+ if (!is_coissue_candidate && !must_promote_imm(devinfo, inst, -1))
continue;
for (int i = 0; i < inst->sources; i++) {
if (inst->src[i].file != IMM)
continue;
+ const bool must_promote = must_promote_imm(devinfo, inst, i);
+ if (!is_coissue_candidate && !must_promote)
+continue;
+
char data[8];
brw_reg_type type;
if (!get_constant_value(devinfo, inst, i, data, ))
@@ -357,8 +380,8 @@ fs_visitor::opt_combine_constants()
imm->inst = NULL;
imm->block = intersection;
imm->uses->push_tail(link(const_ctx, >src[i]));
-imm->uses_by_coissue += could_coissue(devinfo, inst);
-imm->must_promote = imm->must_promote || must_promote_imm(devinfo,
inst);
+imm->uses_by_coissue += is_coissue_candidate;
+imm->must_promote = imm->must_promote || must_promote;
imm->last_use_ip = ip;
if (type == BRW_REGISTER_TYPE_HF)
imm->is_half_float = true;
@@ -371,8 +394,8 @@ fs_visitor::opt_combine_constants()
memcpy(imm->bytes, data, size);
imm->size = size;
imm->is_half_float = type == BRW_REGISTER_TYPE_HF;
-imm->uses_by_coissue = could_coissue(devinfo, inst);
-imm->must_promote = must_promote_imm(devinfo, inst);
+imm->uses_by_coissue = is_coissue_candidate;
+imm->must_promote = must_promote;
imm->first_use_ip = ip;
imm->last_use_ip = ip;
}
diff --git a/src/intel/compiler/brw_fs_copy_propagation.cpp
[Mesa-dev] [PATCH v2 0/3] intel: propagate constants to first source of 2-src instructions
This v2 addresses comments to v1, specifically constant folding of SHR/SHL instructions now only take up to 5-bits from the shift count parameter, just like the hardware does. Also, patch 2 has been fixed to avoid hitting assertions that would then be fixed by patch 3. I sent the series up to patch 2 to Jenkins and verified that it came back green. Iago Toral Quiroga (3): intel/compiler: allow constant propagation for int quotient and reminder intel/compiler: allow constant propagation to first source of 2src instructions intel/compiler: implement more algebraic optimizations src/intel/compiler/brw_fs.cpp | 203 +- .../compiler/brw_fs_combine_constants.cpp | 39 +++- .../compiler/brw_fs_copy_propagation.cpp | 59 +++-- 3 files changed, 253 insertions(+), 48 deletions(-) -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: properly align the fence and EOP bug VA on GFX9
If alignement is 0, offets returned by radv_cmd_buffer_upload_alloc() are always 0. These two virtual addresses were pointing at the same location. Cc: 18.3 19.0 Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_cmd_buffer.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c index ad0b934ddfc..6db44915811 100644 --- a/src/amd/vulkan/radv_cmd_buffer.c +++ b/src/amd/vulkan/radv_cmd_buffer.c @@ -338,14 +338,15 @@ radv_reset_cmd_buffer(struct radv_cmd_buffer *cmd_buffer) unsigned fence_offset, eop_bug_offset; void *fence_ptr; - radv_cmd_buffer_upload_alloc(cmd_buffer, 8, 0, _offset, + radv_cmd_buffer_upload_alloc(cmd_buffer, 8, 8, _offset, _ptr); + cmd_buffer->gfx9_fence_va = radv_buffer_get_va(cmd_buffer->upload.upload_bo); cmd_buffer->gfx9_fence_va += fence_offset; /* Allocate a buffer for the EOP bug on GFX9. */ - radv_cmd_buffer_upload_alloc(cmd_buffer, 16 * num_db, 0, + radv_cmd_buffer_upload_alloc(cmd_buffer, 16 * num_db, 8, _bug_offset, _ptr); cmd_buffer->gfx9_eop_bug_va = radv_buffer_get_va(cmd_buffer->upload.upload_bo); -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109807] Add more granular multiarch usage for Mesa Vulkan overlay JSON manifest
https://bugs.freedesktop.org/show_bug.cgi?id=109807 --- Comment #2 from Lionel Landwerlin --- https://gitlab.freedesktop.org/mesa/mesa/merge_requests/374 -- 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] anv: fix alphaToCoverage when there is no color attachment
Still unreviewed.
Sam
On Thu, 2019-02-21 at 12:08 +0100, Samuel Iglesias Gonsálvez wrote:
> CL#3532 added a test for alpha to coverage without a color
> attachment.
> First the test draws a primitive with alpha 0 and a subpass with only
> a depth buffer. No writes to a depth buffer are expected. Then a
> second draw with a color buffer and the same depth buffer is done to
> verify the depth buffer still has the original clear values.
>
> This behavior is not explicitly forbidden by the Vulkan spec, so
> it seems it is allowed.
>
> When there is no color attachment for a given output, we discard it
> so at the end we have an FS assembly like:
>
> Native code for unnamed fragment shader (null)
> SIMD16 shader: 1 instructions. 0 loops. 4 cycles. 0:0 spills:fills.
> Promoted 0 constants. Compacted 16 to 16 bytes (0%)
>START B0 (4 cycles)
> sendc(16) null<1>UW g120<0,1,0>F0x90031000
>
> render MsgDesc: RT write SIMD16 LastRT Surface = 0 mlen 8 rlen 0 {
> align1 1H EOT };
>
> As g120 is not initialized, we see random writes to the depth buffer
> due to the alphaToCoverage enablement. This commit fixes that by
> keeping the output and creating a null render target for it.
>
> Fixes tests:
>
> dEQP-VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.*
>
> Signed-off-by: Samuel Iglesias Gonsálvez
> ---
> src/intel/vulkan/anv_pipeline.c | 35 +
>
> 1 file changed, 27 insertions(+), 8 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_pipeline.c
> b/src/intel/vulkan/anv_pipeline.c
> index e2024212bd9..70a958bf3a8 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -792,7 +792,9 @@ anv_pipeline_compile_gs(const struct brw_compiler
> *compiler,
>
> static void
> anv_pipeline_link_fs(const struct brw_compiler *compiler,
> - struct anv_pipeline_stage *stage)
> + struct anv_pipeline_stage *stage,
> + const struct anv_subpass *subpass,
> + const VkPipelineMultisampleStateCreateInfo
> *ms_info)
> {
> unsigned num_rts = 0;
> const int max_rt = FRAG_RESULT_DATA7 - FRAG_RESULT_DATA0 + 1;
> @@ -843,12 +845,28 @@ anv_pipeline_link_fs(const struct brw_compiler
> *compiler,
>const unsigned rt = var->data.location - FRAG_RESULT_DATA0;
>if (rt >= MAX_RTS ||
>!(stage->key.wm.color_outputs_valid & (1 << rt))) {
> - /* Unused or out-of-bounds, throw it away */
> - deleted_output = true;
> - var->data.mode = nir_var_function_temp;
> - exec_node_remove(>node);
> - exec_list_push_tail(>locals, >node);
> - continue;
> + if (rt == 0 && ms_info && ms_info->alphaToCoverageEnable &&
> + subpass->depth_stencil_attachment && rt_to_bindings[rt]
> == -1) {
> +/* Don't throw away the unused output, because we needed
> it for
> + * calculate correctly the alpha to coverage samples
> when there
> + * is no color buffer attached at location 0.
> + */
> +rt_to_bindings[rt] = num_rts;
> +/* We need a null render target */
> +rt_bindings[rt_to_bindings[rt]] = (struct
> anv_pipeline_binding) {
> + .set = ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS,
> + .binding = 0,
> + .index = UINT32_MAX,
> +};
> +num_rts++;
> + } else {
> +/* Unused or out-of-bounds, throw it away */
> +deleted_output = true;
> +var->data.mode = nir_var_function_temp;
> +exec_node_remove(>node);
> +exec_list_push_tail(>locals, >node);
> +continue;
> + }
>}
>
>/* Give it the new location */
> @@ -1075,7 +1093,8 @@ anv_pipeline_compile_graphics(struct
> anv_pipeline *pipeline,
> anv_pipeline_link_gs(compiler, [s], next_stage);
> break;
>case MESA_SHADER_FRAGMENT:
> - anv_pipeline_link_fs(compiler, [s]);
> + anv_pipeline_link_fs(compiler, [s],
> + pipeline->subpass, info-
> >pMultisampleState);
> break;
>default:
> unreachable("Invalid graphics shader stage");
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
Re: [Mesa-dev] [PATCH] rav: use 32_AR instead of 32_ABGR when alpha coverage is required
Reviewed-by: Bas Nieuwenhuizen On Fri, Mar 1, 2019 at 6:25 PM Samuel Pitoiset wrote: > > This export format is faster. Seems to improve performance in > Wreckfest. > > Signed-off-by: Samuel Pitoiset > --- > src/amd/vulkan/radv_pipeline.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c > index 30c3f60790e..7f2f96c540a 100644 > --- a/src/amd/vulkan/radv_pipeline.c > +++ b/src/amd/vulkan/radv_pipeline.c > @@ -529,7 +529,7 @@ radv_pipeline_compute_spi_color_formats(struct > radv_pipeline *pipeline, > * alpha channel of MRT0 when alpha coverage is enabled > because > * the depth attachment needs it. > */ > - col_format |= V_028714_SPI_SHADER_32_ABGR; > + col_format |= V_028714_SPI_SHADER_32_AR; > } > > /* If the i-th target format is set, all previous target formats must > -- > 2.21.0 > > ___ > 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] android, autotools: st/mesa: fix location of float64_glsl.h
Hi Tapani,
On Mon, Mar 4, 2019 at 6:51 AM Tapani Pälli wrote:
>
> Hi;
>
> On 3/3/19 10:10 PM, Mauro Rossi wrote:
> > Necessary to avoid building error in Android,
> > due to 'compiler/glsl/float64_glsl.h' file not found
> >
> > Fixes: cb4e3e3 ("st/mesa: add support for lowering fp64/int64 for nir
> > drivers")
> > Signed-off-by: Mauro Rossi
> > ---
> > src/mesa/Android.libmesa_st_mesa.mk | 1 +
> > src/mesa/Makefile.sources | 1 +
> > src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
> > 3 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/Android.libmesa_st_mesa.mk
> > b/src/mesa/Android.libmesa_st_mesa.mk
> > index ddfd03059c..c5b16cad34 100644
> > --- a/src/mesa/Android.libmesa_st_mesa.mk
> > +++ b/src/mesa/Android.libmesa_st_mesa.mk
> > @@ -58,6 +58,7 @@ endif
> > LOCAL_C_INCLUDES := \
> > $(MESA_TOP)/src/mapi \
> > $(MESA_TOP)/src/mesa/main \
> > + $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_glsl,,) \
> > $(MESA_TOP)/src/compiler/nir \
> > $(MESA_TOP)/src/gallium/auxiliary \
> > $(MESA_TOP)/src/gallium/include
> > diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
> > index 1e25f47e50..69f32c6adf 100644
> > --- a/src/mesa/Makefile.sources
> > +++ b/src/mesa/Makefile.sources
> > @@ -689,6 +689,7 @@ INCLUDE_DIRS = \
> > -I$(top_srcdir)/include \
> > -I$(top_builddir)/src \
> > -I$(top_srcdir)/src \
> > + -I$(top_builddir)/src/compiler \
> > -I$(top_builddir)/src/compiler/glsl \
> > -I$(top_builddir)/src/compiler/nir \
> > -I$(top_builddir)/src/mesa \
> > diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> > b/src/mesa/state_tracker/st_glsl_to_nir.cpp
> > index a1e3b6233c..ad77b746ab 100644
> > --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> > +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
> > @@ -48,7 +48,7 @@
> > #include "compiler/glsl/ir.h"
> > #include "compiler/glsl/ir_optimization.h"
> > #include "compiler/glsl/string_to_uint_map.h"
> > -#include "compiler/glsl/float64_glsl.h"
> > +#include "glsl/float64_glsl.h"
>
> Looks familiar :)
>
> https://github.com/tpalli/external-mesa/commit/ebd8581ad133206ec2b1b818e98dc4f8401af8de
>
> Before going further though, I'd like to understand why do we have both
> 'compiler/glsl/' and 'glsl/' going on. Should we rather put the
> 'compiler' back in the header generation? I can't remember the full
> story behind commit c812c740e60 but that one changed this .. perhaps we
> should pull it back and have the 'compiler/', any objections to that?
>
I agree that simply continue to have include "compiler/glsl/float64_glsl.h"
in all sources places would be simpler
and should not break neither autotools nor meson,
which may continue to have glsl/float64_glsl.h in their generators
Mauro
> Thanks;
>
> // Tapani
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109805] GPU hangs with error VM_CONTEXT1_PROTECTION_FAULT_STATUS
https://bugs.freedesktop.org/show_bug.cgi?id=109805 --- Comment #7 from Samuel Pitoiset --- Can you try to boot your kernel with amdgpu.vm_debug=1? Does the VM faults happen more often with that option? -- 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
[Mesa-dev] [Bug 109818] wrong color rendering in SOULCALIBUR 6 using dxvk
https://bugs.freedesktop.org/show_bug.cgi?id=109818 --- Comment #1 from Samuel Pitoiset --- Can you upload a renderdoc capture and eventually bisect the problem? -- 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
