[Mesa-dev] [Bug 110268] enable storageBuffer16BitAccess feature in radv for SI and CIK
https://bugs.freedesktop.org/show_bug.cgi?id=110268
Bug ID: 110268
Summary: enable storageBuffer16BitAccess feature in radv for SI
and CIK
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Vulkan/radeon
Assignee: mesa-dev@lists.freedesktop.org
Reporter: shuizhuyuan...@126.com
QA Contact: mesa-dev@lists.freedesktop.org
the VK_KHR_16bit_storage extension is enabled but all features are reported as
FALSE for SI and CIK.
I found those features are only enabled with VI+ in
mesa/src/amd/vulkan/radv_device.c
as contrast, the amdvlk driver support them.
16bit storage support is important for reducing shader bandwidth and gaining
speed boost. (found 20%~50% speedup with the ncnn vulkan nerual network
benchmark)
please consider implementing storageBuffer16BitAccess feature for SI and CIK.
Thanks!
case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES:
{
VkPhysicalDevice16BitStorageFeatures *features =
(VkPhysicalDevice16BitStorageFeatures*)ext;
bool enabled = pdevice->rad_info.chip_class >= VI;
features->storageBuffer16BitAccess = enabled;
features->uniformAndStorageBuffer16BitAccess = enabled;
features->storagePushConstant16 = enabled;
features->storageInputOutput16 = enabled && HAVE_LLVM
>= 0x900;
break;
}
--
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 110266] gpu error
https://bugs.freedesktop.org/show_bug.cgi?id=110266 Bug ID: 110266 Summary: gpu error Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: anku7...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org gup is not ditecting -- 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 110261] Segmentation fault when using vulkaninfo on Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=110261 Kenneth Endfinger changed: What|Removed |Added Hardware|x86 (IA32) |x86-64 (AMD64) -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110261] Segmentation fault when using vulkaninfo on Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=110261 Bug ID: 110261 Summary: Segmentation fault when using vulkaninfo on Radeon Product: Mesa Version: 19.0 Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: kaendfin...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org Created attachment 143799 --> https://bugs.freedesktop.org/attachment.cgi?id=143799=edit GDB session when running vulkaninfo. When running vulkaninfo, it exits with a segmentation fault. Running on Arch Linux: mesa 19.0.1-2 vulkan-radeon 19.0.1-2 libxcb 1.13.1-1 xorg-server 1.20.4-1 vulkan-tools 1.1.101-1 Thread 1 "vulkaninfo" received signal SIGSEGV, Segmentation fault. 0x7543a0f7 in XGetXCBConnection () from /usr/lib/libX11-xcb.so.1 (gdb) info stack #0 0x7543a0f7 in XGetXCBConnection () from /usr/lib/libX11-xcb.so.1 #1 0x74ca58d1 in x11_surface_get_connection (icd_surface=0x55972610) at ../mesa-19.0.1/src/vulkan/wsi/wsi_common_x11.c:404 #2 x11_surface_get_connection (icd_surface=0x55972610) at ../mesa-19.0.1/src/vulkan/wsi/wsi_common_x11.c:401 I have attached the full GDB log. -- 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
Re: [Mesa-dev] [PATCH v2 6/8] gallium: add lima driver
V3 driver could be reviewed at:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/465
Regards,
Qiang
On Tue, Mar 26, 2019 at 2:38 PM Qiang Yu wrote:
>
> On Tue, Mar 26, 2019 at 11:33 AM Alyssa Rosenzweig
> wrote:
> >
> > > + [PPIR_INSTR_SLOT_ALU_VEC_MUL] = ppir_codegen_encode_vec_mul,
> > > + [PPIR_INSTR_SLOT_ALU_SCL_MUL] = ppir_codegen_encode_scl_mul,
> > > + [PPIR_INSTR_SLOT_ALU_VEC_ADD] = ppir_codegen_encode_vec_add,
> > > + [PPIR_INSTR_SLOT_ALU_SCL_ADD] = ppir_codegen_encode_scl_add,
> >
> > vmul/smul/vadd/sadd are the (official?) names for this on Midgard, fwiw.
> >
> > > +static const int ppir_codegen_field_size[] = {
> > > + 34, 62, 41, 43, 30, 44, 31, 30, 41, 73
> > > +};
> >
> > What is this?
> PP instruction field (i.e. vadd part length) length in bit.
>
> >
> > > +static inline int align_to_word(int size)
> > > +{
> > > + return ((size + 0x1f) >> 5);
> > > +}
> >
> > Maybe use the align() macro (it's in mesa/src/util/) for clarity?
> >
> > > + ppir_codegen_combine_scalar_op_atan = 8, /* Arc Tangent Part 1 */
> > > + ppir_codegen_combine_scalar_op_atan2 = 9, /* Arc Tangent 2 Part 1 */
> >
> > Any plan to use these ops? Midgard has them too, but inverse trig gets
> > lowered away anyway...
> >
> Not yet.
>
> > > +if (node->op == ppir_op_neg)
> > > + src->negate = !src->negate;
> > > +else if (node->op == ppir_op_abs)
> > > + src->absolute = true;
> >
> > I'm confused. NIR has neg/abs modifiers natively. You can get all
> > fneg/fabs instructions lowered in NIR to these modifiers via
> > the lower_source_mods pass. If you don't want them, you'll never have
> > neg/abs ops at all; they'll all be modifiers. Why duplicate this in
> > ppir?
>
> Didn't know this pass, I can use it, thanks.
>
> >
> > > + uint32_t va;
> >
> > I don't know the Utgard MMU, but will this work on 64-bit?
> >
> It's fine as Utgard MMU only support 32bit address.
>
> >
> > > + uint32_t dubya;
> >
> > ???
> Don't know for me either, just copy from lima-ng.
>
> >
> > > + uint32_t mrt_bits;
> > > + uint32_t mrt_pitch;
> >
> > Utgard supports MRT?!
> >
> Utgard can render to 3 FB (WB0~2) in one pass.
>
> >
> > > + uint32_t width = fui(fb->width);
> > > + uint32_t height = fui(fb->height);
> > > + uint32_t reload_gl_pos[] = {
> > > + width, 0x, 0x, 0x3f80, /* 0x */
> > > + 0x, 0x, 0x, 0x3f80, /* 0x0010 */
> > > + 0x, height, 0x, 0x3f80, /* 0x0020 */
> > > + };
> > > + memcpy(cpu + lima_reload_gl_pos_offset, reload_gl_pos,
> > > + sizeof(reload_gl_pos));
> > > +
> > > + uint32_t reload_varying[] = {
> > > + width, 0x, 0x, 0x, /* 0x */
> > > + 0x, height, 0x, 0x, /* 0x0010 */
> > > + };
> > > + memcpy(cpu + lima_reload_varying_offset, reload_varying,
> > > + sizeof(reload_varying));
> > > +
> >
> > Why not actual float arrays?
> >
> Right.
>
> >
> > > + uint32_t clear_shader[] = {
> > > + 0x00021025, 0x000c,
> > > + (ctx->clear.color_16pc << 12) | 0x07cf,
> > > + ctx->clear.color_16pc >> 12,
> > > + ctx->clear.color_16pc >> 44,
> > > + };
> >
> > Please don't include shader blobs. This should maybe be generated
> > from NIR, but at minimum, please include the corresponding annotated
> > assembly.
> >
> I think no need to compile this kind of util shader, will add some
> comments about it.
>
> > > + clear->color_16pc =
> > > + ((uint64_t)float_to_ushort(color->f[3]) << 48) |
> > > + ((uint64_t)float_to_ushort(color->f[2]) << 32) |
> > > + ((uint64_t)float_to_ushort(color->f[1]) << 16) |
> > > + float_to_ubyte(color->f[0]);
> >
> > Should that last line be float_to_ushort?
> >
> Right, will fix it.
>
> >
> > > +enum lima_attrib_type {
> > > + LIMA_ATTRIB_FLOAT = 0x000,
> > > + /* todo: find out what lives here. */
> >
> > LIMA_ATTRIB_FP16 maybe.
> > LIMA_ATTRIB_I32/LIMA_ATTRIB_U32?.
> >
> >
> > > +static bool
> > > +is_modifier_ok(const uint64_t *modifiers, int count, uint64_t mod)
> >
> > drm_find_modifier in util/u_drm.h
> >
> > > + /* fs program for clear buffer? */
> > > + static const uint32_t pp_clear_program[] = {
> > > + 0x00020425, 0x000c, 0x01e007cf, 0xb000, /* 0x */
> > > + 0x05f5, 0x, 0x, 0x, /* 0x0010 */
> > > + };
> > > + memcpy(lima_bo_map(screen->pp_buffer) + pp_clear_program_offset,
> > > + pp_clear_program, sizeof(pp_clear_program));
> > > +
> > > + /* copy texture to framebuffer, used to reload gpu tile buffer */
> > > + static const uint32_t pp_reload_program[] = {
> > > + 0x05e6, 0xf1003c20, 0x, 0x39001000, /* 0x */
> > > + 0x0e4e, 0x07cf, 0x, 0x, /* 0x0010 */
> > > + };
> > > +
Re: [Mesa-dev] [PATCH v5 35/38] intel/compiler: validate region restrictions for mixed float mode
"Juan A. Suarez Romero" writes:
> From: Iago Toral Quiroga
>
> v2:
> - Adapted unit tests to make them consistent with the changes done
>to the validation of half-float conversions.
> ---
> src/intel/compiler/brw_eu_validate.c| 256 ++
> src/intel/compiler/test_eu_validate.cpp | 620
> 2 files changed, 876 insertions(+)
>
> diff --git a/src/intel/compiler/brw_eu_validate.c
> b/src/intel/compiler/brw_eu_validate.c
> index 18c95efb05b..5eea02f5c94 100644
> --- a/src/intel/compiler/brw_eu_validate.c
> +++ b/src/intel/compiler/brw_eu_validate.c
> @@ -170,6 +170,13 @@ src1_is_null(const struct gen_device_info *devinfo,
> const brw_inst *inst)
>brw_inst_src1_da_reg_nr(devinfo, inst) == BRW_ARF_NULL;
> }
>
> +static bool
> +src0_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
> +{
> + return brw_inst_src0_reg_file(devinfo, inst) ==
> BRW_ARCHITECTURE_REGISTER_FILE &&
> + brw_inst_src0_da_reg_nr(devinfo, inst) == BRW_ARF_ACCUMULATOR;
> +}
> +
There are multiple accumulator registers. The above only checks for
acc0.
> static bool
> src0_is_grf(const struct gen_device_info *devinfo, const brw_inst *inst)
> {
> @@ -937,6 +944,254 @@ general_restrictions_on_region_parameters(const struct
> gen_device_info *devinfo,
> return error_msg;
> }
>
> +static struct string
> +special_restrictions_for_mixed_float_mode(const struct gen_device_info
> *devinfo,
> + const brw_inst *inst)
> +{
> + struct string error_msg = { .str = NULL, .len = 0 };
> +
> + unsigned opcode = brw_inst_opcode(devinfo, inst);
Constify this and the declarations below.
> + unsigned num_sources = num_sources_from_inst(devinfo, inst);
> + if (num_sources >= 3)
> + return error_msg;
> +
> + if (!is_mixed_float(devinfo, inst))
> + return error_msg;
> +
> + unsigned exec_size = 1 << brw_inst_exec_size(devinfo, inst);
> + bool is_align16 = brw_inst_access_mode(devinfo, inst) == BRW_ALIGN_16;
> +
> + enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
> + enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
Same comment as in the previous patch, this can possibly blow up for
instructions with less than two sources.
> + enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
> +
> + unsigned dst_stride = STRIDE(brw_inst_dst_hstride(devinfo, inst));
> + bool dst_is_packed = is_packed(exec_size * dst_stride, exec_size,
> dst_stride);
> +
> + /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
> +* Float Operations:
> +*
> +*"Indirect addressing on source is not supported when source and
> +* destination data types are mixed float."
> +*
> +* Indirect addressing is only supported on the first source, so we only
> +* check that.
I don't think that's true. The hardware spec has the following example
of a valid but kind of funky instruction with indirect regioning:
| add (16) r[a0.0]:f r[a0.2]:f r[a0.4]:f
> +*/
> + ERROR_IF(types_are_mixed_float(dst_type, src0_type) &&
I doubt that it makes a difference whether there is a mismatch between
the type of src0 and the type of the destination for indirect addressing
to be disallowed. Things are likely to blow up with indirect addressing
in src0 even if the instruction is mixed-mode due to the effect of the
type of src1 alone. But it's hard to tell for sure, spec wording seems
fairly ambiguous...
> +brw_inst_src0_address_mode(devinfo, inst) != BRW_ADDRESS_DIRECT,
> +"Indirect addressing on source is not supported when source and "
> +"destination data types are mixed float");
> +
> + /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
> +* Float Operations:
> +*
> +*"No SIMD16 in mixed mode when destination is f32. Instruction
> +* execution size must be no more than 8."
> +*/
> + ERROR_IF(exec_size > 8 && dst_type == BRW_REGISTER_TYPE_F,
> +"Mixed float mode with 32-bit float destination is limited "
> +"to SIMD8");
> +
> + if (is_align16) {
> + /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
> + * Float Operations:
> + *
> + * "In Align16 mode, when half float and float data types are mixed
> + *between source operands OR between source and destination
> operands,
> + *the register content are assumed to be packed."
> + *
> + * Since Align16 doesn't have a concept of horizontal stride (or
> width),
> + * it means that vertical stride must always be 4, since 0 and 2 would
> + * lead to replicated data, and any other value is disallowed in
> Align16.
> + * However, the PRM also says:
> + *
> + * "In Align16, vertical stride can never be zero for f16"
> + *
> + * Which is oddly redundant and specific considering the
Re: [Mesa-dev] [PATCH v5 33/38] intel/compiler: validate region restrictions for half-float conversions
"Juan A. Suarez Romero" writes:
> From: Iago Toral Quiroga
>
> v2:
> - Consider implicit conversions in 2-src instructions too (Curro)
> - For restrictions that involve destination stride requirements
>only validate them for Align1, since Align16 always requires
>packed data.
> - Skip general rule for the dst/execution type size ratio for
>mixed float instructions on CHV and SKL+, these have their own
>set of rules that we'll be validated separately.
> ---
> src/intel/compiler/brw_eu_validate.c| 156 +++-
> src/intel/compiler/test_eu_validate.cpp | 117 ++
> 2 files changed, 272 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/compiler/brw_eu_validate.c
> b/src/intel/compiler/brw_eu_validate.c
> index bd0e48a5e5c..cad50469c65 100644
> --- a/src/intel/compiler/brw_eu_validate.c
> +++ b/src/intel/compiler/brw_eu_validate.c
> @@ -469,6 +469,66 @@ is_packed(unsigned vstride, unsigned width, unsigned
> hstride)
> return false;
> }
>
> +/**
> + * Returns whether an instruction is an explicit or implicit conversion
> + * to/from half-float.
> + */
> +static bool
> +is_half_float_conversion(const struct gen_device_info *devinfo,
> + const brw_inst *inst)
> +{
> + enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
> +
> + unsigned num_sources = num_sources_from_inst(devinfo, inst);
> + enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
> +
> + if (dst_type != src0_type &&
> + (dst_type == BRW_REGISTER_TYPE_HF || src0_type ==
> BRW_REGISTER_TYPE_HF)) {
> + return true;
> + } else if (num_sources > 1) {
> + enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
> + return dst_type != src1_type &&
> +(dst_type == BRW_REGISTER_TYPE_HF ||
> + src1_type == BRW_REGISTER_TYPE_HF);
> + }
> +
> + return false;
> +}
> +
> +/*
> + * Returns whether an instruction is using mixed float operation mode
> + */
> +static bool
> +is_mixed_float(const struct gen_device_info *devinfo, const brw_inst *inst)
> +{
> + if (devinfo->gen < 8)
> + return false;
> +
> + if (inst_is_send(devinfo, inst))
> + return false;
> +
> + unsigned opcode = brw_inst_opcode(devinfo, inst);
> + const struct opcode_desc *desc = brw_opcode_desc(devinfo, opcode);
> + if (desc->ndst == 0)
> + return false;
> +
> + /* FIXME: support 3-src instructions */
> + unsigned num_sources = num_sources_from_inst(devinfo, inst);
> + assert(num_sources < 3);
> +
> + enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
> + enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
> +
> + if (num_sources == 1)
> + return types_are_mixed_float(src0_type, dst_type);
> +
> + enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
> +
> + return types_are_mixed_float(src0_type, src1_type) ||
> + types_are_mixed_float(src0_type, dst_type) ||
> + types_are_mixed_float(src1_type, dst_type);
> +}
> +
> /**
> * Checks restrictions listed in "General Restrictions Based on Operand
> Types"
> * in the "Register Region Restrictions" section.
> @@ -539,7 +599,101 @@ 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) {
> + if (is_half_float_conversion(devinfo, inst)) {
> + /**
> + * A helper to validate used in the validation of the following
> restriction
> + * from the BDW+ PRM, Volume 2a, Command Reference, Instructions - MOV:
> + *
> + *"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."
> + *
> + * Even if these restrictions are listed for the MOV instruction, we
> + * validate this more generally, since there is the possibility
> + * of implicit conversions from other instructions, such us implicit
> + * conversion from integer to HF with the ADD instruction in SKL+.
> + */
> + enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
> + enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
I think the evaluation of brw_inst_src1_type() above can blow up if the
instruction has a single source and the src1 type field happens to
overlap with something else (e.g. an immediate).
> + ERROR_IF(dst_type == BRW_REGISTER_TYPE_HF &&
> + (type_sz(src0_type) == 8 ||
> +(num_sources > 1 && type_sz(src1_type) == 8)),
> + "There are no direct conversions between 64-bit types and
> HF");
> +
> + ERROR_IF(type_sz(dst_type) == 8 &&
> + (src0_type == BRW_REGISTER_TYPE_HF ||
> +(num_sources > 1 && src1_type == BRW_REGISTER_TYPE_HF)),
> + "There are no direct conversions
[Mesa-dev] [Bug 109929] tgsi_to_nir.c:2111: undefined reference to `gl_nir_lower_samplers_as_deref'
https://bugs.freedesktop.org/show_bug.cgi?id=109929 --- Comment #10 from Vinson Lee --- The diff fixes the entire build for me. diff --git a/src/gallium/targets/pipe-loader/Makefile.am b/src/gallium/targets/pipe-loader/Makefile.am index db515e3097b7..807a100a7d0a 100644 --- a/src/gallium/targets/pipe-loader/Makefile.am +++ b/src/gallium/targets/pipe-loader/Makefile.am @@ -53,16 +53,14 @@ endif PIPE_LIBS += \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ - $(top_builddir)/src/compiler/nir/libnir.la \ - $(top_builddir)/src/util/libmesautil.la \ + $(top_builddir)/src/compiler/glsl/libglsl.la \ $(GALLIUM_COMMON_LIB_DEPS) AM_LDFLAGS = \ -module \ -no-undefined \ -avoid-version \ - $(GC_SECTIONS) \ - $(LD_NO_UNDEFINED) + $(GC_SECTIONS) if HAVE_LD_VERSION_SCRIPT AM_LDFLAGS += \ diff --git a/src/gallium/targets/xa/Makefile.am b/src/gallium/targets/xa/Makefile.am index 7b0e9006e06d..2238a7ea81f6 100644 --- a/src/gallium/targets/xa/Makefile.am +++ b/src/gallium/targets/xa/Makefile.am @@ -37,16 +37,14 @@ libxatracker_la_LIBADD = \ $(top_builddir)/src/gallium/state_trackers/xa/libxatracker.la \ $(top_builddir)/src/gallium/auxiliary/libgalliumvl_stub.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ - $(top_builddir)/src/compiler/nir/libnir.la \ - $(top_builddir)/src/util/libmesautil.la \ + $(top_builddir)/src/compiler/glsl/libglsl.la \ $(LIBDRM_LIBS) \ $(GALLIUM_COMMON_LIB_DEPS) libxatracker_la_LDFLAGS = \ -no-undefined \ -version-number $(XA_MAJOR):$(XA_MINOR):$(XA_PATCH) \ - $(GC_SECTIONS) \ - $(LD_NO_UNDEFINED) + $(GC_SECTIONS) if HAVE_LD_VERSION_SCRIPT libxatracker_la_LDFLAGS += \ -- 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
Re: [Mesa-dev] [PATCH v6 31/38] intel/compiler: implement SIMD16 restrictions for mixed-float instructions
"Juan A. Suarez Romero" writes:
> From: Iago Toral Quiroga
>
> ---
> src/intel/compiler/brw_fs.cpp | 65 +++
> 1 file changed, 65 insertions(+)
>
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 2fc7793709b..3616a7afc31 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -5607,6 +5607,42 @@ fs_visitor::lower_logical_sends()
> return progress;
> }
>
> +static bool
> +is_mixed_float_with_fp32_dst(const fs_inst *inst)
> +{
> + /* FIXME: This opcode sometimes uses :W type on the source
> +* for some reason even if the operand is a half-float, we
> +* should probably fix it to use the correct type.
> +*/
> + if (inst->opcode == BRW_OPCODE_F16TO32)
> + return true;
> +
> + if (inst->dst.type != BRW_REGISTER_TYPE_F)
> + return false;
> +
> + for (int i = 0; i < inst->sources; i++) {
> + if (inst->src[i].type == BRW_REGISTER_TYPE_HF)
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static bool
> +is_mixed_float_with_packed_fp16_dst(const fs_inst *inst)
> +{
F32TO16 is also sometimes used with a W type as destination IIRC (since
it's a Gen7 instruction that predates HF types). Not sure if it's ever
packed, but it might be sensible to return true here if that's ever the
case.
Other than that looks okay to me.
> + if (inst->dst.type != BRW_REGISTER_TYPE_HF ||
> + inst->dst.stride != 1)
> + return false;
> +
> + for (int i = 0; i < inst->sources; i++) {
> + if (inst->src[i].type == BRW_REGISTER_TYPE_F)
> + return true;
> + }
> +
> + return false;
> +}
> +
> /**
> * Get the closest allowed SIMD width for instruction \p inst accounting for
> * some common regioning and execution control restrictions that apply to FPU
> @@ -5769,6 +5805,35 @@ get_fpu_lowered_simd_width(const struct
> gen_device_info *devinfo,
> max_width = MIN2(max_width, 4);
> }
>
> + /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
> +* Float Operations:
> +*
> +*"No SIMD16 in mixed mode when destination is f32. Instruction
> +* execution size must be no more than 8."
> +*
> +* FIXME: the simulator doesn't seem to complain if we don't do this and
> +* empirical testing with existing CTS tests show that they pass just fine
> +* without implementing this, however, since our interpretation of the PRM
> +* is that conversion MOVs between HF and F are still mixed-float
> +* instructions (and therefore subject to this restriction) we decided to
> +* split them to be safe. Might be useful to do additional investigation
> to
> +* lift the restriction if we can ensure that it is safe though, since
> these
> +* conversions are common when half-float types are involved since many
> +* instructions do not support HF types and conversions from/to F are
> +* required.
> +*/
> + if (is_mixed_float_with_fp32_dst(inst))
> + max_width = MIN2(max_width, 8);
> +
> + /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
> +* Float Operations:
> +*
> +*"No SIMD16 in mixed mode when destination is packed f16 for both
> +* Align1 and Align16."
> +*/
> + if (is_mixed_float_with_packed_fp16_dst(inst))
> + max_width = MIN2(max_width, 8);
> +
> /* Only power-of-two execution sizes are representable in the instruction
> * control fields.
> */
> --
> 2.20.1
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel/disasm: Disassemble JIP offset for while
Signed-off-by: Sagar Ghuge
---
src/intel/compiler/brw_disasm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_disasm.c b/src/intel/compiler/brw_disasm.c
index efca3e2ce7d..440e51faa61 100644
--- a/src/intel/compiler/brw_disasm.c
+++ b/src/intel/compiler/brw_disasm.c
@@ -1661,7 +1661,8 @@ brw_disassemble_inst(FILE *file, const struct
gen_device_info *devinfo,
format(file, "Pop: %"PRIu64, brw_inst_gen4_pop_count(devinfo, inst));
} else if (devinfo->gen < 6 && (opcode == BRW_OPCODE_IF ||
opcode == BRW_OPCODE_IFF ||
- opcode == BRW_OPCODE_HALT)) {
+ opcode == BRW_OPCODE_HALT ||
+ opcode == BRW_OPCODE_WHILE)) {
pad(file, 16);
format(file, "Jump: %d", brw_inst_gen4_jump_count(devinfo, inst));
} else if (devinfo->gen < 6 && opcode == BRW_OPCODE_ENDIF) {
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] softpipe/draw: fix vertex id in soft paths.
Am 27.03.19 um 20:47 schrieb Dave Airlie:
> From: Dave Airlie
>
> This fixes the vertex id fetch in the non-llvm drawing paths.
>
> This vertex id in elt mode comes from the elts not just a linear
> value.
>
> Note we don't bad
add?
> basevertex in the elts case as it's already included
> in the elts by the looks of it (at least tests fail if I add it)
Yes, the vsplit code is responsible for this, so that the elts you'll
get in draw later actually represent the indices you have to fetch.
I'm not entirely sure this is still the best design today but I think
this evolved naturally from before base index actually existed in the
APIs. (More below.)
>
> Fixes piglit end-primitive tests and some others.
> ---
> .../auxiliary/draw/draw_pt_fetch_shade_pipeline.c | 13 +
> src/gallium/auxiliary/draw/draw_vs.h| 3 ++-
> src/gallium/auxiliary/draw/draw_vs_exec.c | 7 ---
> src/gallium/auxiliary/draw/draw_vs_llvm.c | 3 ++-
> src/gallium/auxiliary/draw/draw_vs_variant.c| 4 ++--
> 5 files changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
> b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
> index f76e022994a..3207932c601 100644
> --- a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
> +++ b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
> @@ -205,6 +205,7 @@ static void
> draw_vertex_shader_run(struct draw_vertex_shader *vshader,
> const void *constants[PIPE_MAX_CONSTANT_BUFFERS],
> unsigned const_size[PIPE_MAX_CONSTANT_BUFFERS],
> + const struct draw_fetch_info *fetch_info,
> const struct draw_vertex_info *input_verts,
> struct draw_vertex_info *output_verts)
> {
> @@ -222,7 +223,8 @@ draw_vertex_shader_run(struct draw_vertex_shader *vshader,
> const_size,
> input_verts->count,
> input_verts->vertex_size,
> - input_verts->vertex_size);
> + input_verts->vertex_size,
> + fetch_info->elts);
> }
>
>
> @@ -267,18 +269,17 @@ fetch_pipeline_generic(struct draw_pt_middle_end
> *middle,
> */
> fetch( fpme->fetch, fetch_info, (char *)fetched_vert_info.verts );
>
> - /* Finished with fetch:
> -*/
> - fetch_info = NULL;
> vert_info = _vert_info;
>
> /* Run the shader, note that this overwrites the data[] parts of
> * the pipeline verts.
> +* Need fetch info to get vertex id correct.
> */
> if (fpme->opt & PT_SHADE) {
>draw_vertex_shader_run(vshader,
> draw->pt.user.vs_constants,
> draw->pt.user.vs_constants_size,
> + fetch_info,
> vert_info,
> _vert_info);
>
> @@ -286,6 +287,10 @@ fetch_pipeline_generic(struct draw_pt_middle_end *middle,
>vert_info = _vert_info;
> }
>
> + /* Finished with fetch:
> +*/
> + fetch_info = NULL;
> +
> if ((fpme->opt & PT_SHADE) && gshader) {
>draw_geometry_shader_run(gshader,
> draw->pt.user.gs_constants,
> diff --git a/src/gallium/auxiliary/draw/draw_vs.h
> b/src/gallium/auxiliary/draw/draw_vs.h
> index 6a900224c11..65520ea6e7a 100644
> --- a/src/gallium/auxiliary/draw/draw_vs.h
> +++ b/src/gallium/auxiliary/draw/draw_vs.h
> @@ -140,7 +140,8 @@ struct draw_vertex_shader {
> const unsigned const_size[PIPE_MAX_CONSTANT_BUFFERS],
> unsigned count,
> unsigned input_stride,
> -unsigned output_stride );
> +unsigned output_stride,
> +const unsigned *fetch_elts);
>
>
> void (*delete)( struct draw_vertex_shader * );
> diff --git a/src/gallium/auxiliary/draw/draw_vs_exec.c
> b/src/gallium/auxiliary/draw/draw_vs_exec.c
> index dbd7aa551eb..c1f8edaae69 100644
> --- a/src/gallium/auxiliary/draw/draw_vs_exec.c
> +++ b/src/gallium/auxiliary/draw/draw_vs_exec.c
> @@ -93,7 +93,8 @@ vs_exec_run_linear(struct draw_vertex_shader *shader,
> const unsigned const_size[PIPE_MAX_CONSTANT_BUFFERS],
> unsigned count,
> unsigned input_stride,
> - unsigned output_stride)
> + unsigned output_stride,
> + const unsigned *fetch_elts)
> {
> struct exec_vertex_shader *evs = exec_vertex_shader(shader);
> struct tgsi_exec_machine *machine = evs->machine;
> @@ -133,7 +134,7 @@ vs_exec_run_linear(struct draw_vertex_shader *shader,
> if (shader->info.uses_vertexid) {
> unsigned vid =
> machine->SysSemanticToIndex[TGSI_SEMANTIC_VERTEXID];
> assert(vid
[Mesa-dev] [PATCH] intel/compiler: Set flag reg/subreg number properly
If predicate control is set to None, then in that case we can simply set
flag reg/subreg number to zero. This allows round-tripping through the
assembler/disassembler
Signed-off-by: Sagar Ghuge
---
src/intel/compiler/brw_eu_emit.c| 7 +++
src/intel/compiler/brw_fs_generator.cpp | 1 +
2 files changed, 8 insertions(+)
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 94e247e1a39..f59543db8df 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -2267,6 +2267,13 @@ brw_fb_WRITE(struct brw_codegen *p,
brw_inst_set_sfid(devinfo, insn, target_cache);
brw_inst_set_compression(devinfo, insn, false);
+ if (brw_inst_pred_control(devinfo, insn) == BRW_PREDICATE_NONE) {
+ brw_inst_set_flag_subreg_nr(devinfo, insn, 0);
+ if (devinfo->gen >= 7) {
+ brw_inst_set_flag_reg_nr(devinfo, insn, 0);
+ }
+ }
+
if (devinfo->gen >= 6) {
/* headerless version, just submit color payload */
src0 = payload;
diff --git a/src/intel/compiler/brw_fs_generator.cpp
b/src/intel/compiler/brw_fs_generator.cpp
index c24d4eb7cab..242450c605e 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -307,6 +307,7 @@ fs_generator::fire_fb_write(fs_inst *inst,
brw_set_default_mask_control(p, BRW_MASK_DISABLE);
brw_set_default_predicate_control(p, BRW_PREDICATE_NONE);
brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
+ brw_set_default_flag_reg(p, 0, 0);
brw_MOV(p, offset(retype(payload, BRW_REGISTER_TYPE_UD), 1),
offset(retype(implied_header, BRW_REGISTER_TYPE_UD), 1));
brw_pop_insn_state(p);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: Lock around validation fail shader dumping
Reviewed-by: Timothy Arceri
On 28/3/19 3:22 am, Jason Ekstrand wrote:
---
src/compiler/nir/nir_validate.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/compiler/nir/nir_validate.c b/src/compiler/nir/nir_validate.c
index ef2e2b62783..f8327c0dd45 100644
--- a/src/compiler/nir/nir_validate.c
+++ b/src/compiler/nir/nir_validate.c
@@ -26,6 +26,7 @@
*/
#include "nir.h"
+#include "c11/threads.h"
#include
/*
@@ -1169,11 +1170,18 @@ destroy_validate_state(validate_state *state)
_mesa_hash_table_destroy(state->errors, NULL);
}
+mtx_t fail_dump_mutex = _MTX_INITIALIZER_NP;
+
static void
dump_errors(validate_state *state, const char *when)
{
struct hash_table *errors = state->errors;
+ /* Lock around dumping so that we get clean dumps in a multi-threaded
+* scenario
+*/
+ mtx_lock(_dump_mutex);
+
if (when) {
fprintf(stderr, "NIR validation failed %s\n", when);
fprintf(stderr, "%d errors:\n", _mesa_hash_table_num_entries(errors));
@@ -1192,6 +1200,8 @@ dump_errors(validate_state *state, const char *when)
}
}
+ mtx_unlock(_dump_mutex);
+
abort();
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110240] Assassins Creed Odyssey crashes with nir errors
https://bugs.freedesktop.org/show_bug.cgi?id=110240 --- Comment #10 from Jason Ekstrand --- Fixed by the following commit in master: commit ce47999ceed7efe010a1b6cc592780514803670a (public/master) Author: Jason Ekstrand Date: Wed Mar 27 11:16:15 2019 -0500 Revert "anv/radv: release memory allocated by glsl types during spirv_to_nir" This reverts commit 4e1bbb000cdfe4ba01bee5a6868c54fed7285dae. It turns out that some DXVK apps due to some implementation detail of DXVK or other create and destroy instances in an interleaved way. Freeing the glsl_type memory without being a bit more careful causes use-after-free issues. Looks like we need to try again. -- 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] [PATCH 2/2] softpipe: add indirect store buffer/image unit
From: Dave Airlie
The code to handle image unit indirect was missing
Fixes piglit
tests/spec/arb_arrays_of_arrays/execution/image_store/basic-imageStore-mixed-const-non-const-uniform-index.shader_test
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 36 --
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index a03dfe6aebc..a6a4d556abf 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -3942,6 +3942,38 @@ exec_load(struct tgsi_exec_machine *mach,
exec_load_mem(mach, inst);
}
+static uint
+fetch_store_img_unit(struct tgsi_exec_machine *mach,
+ const struct tgsi_full_dst_register *dst)
+{
+ uint unit = 0;
+ int i;
+ if (dst->Register.Indirect) {
+ union tgsi_exec_channel indir_index, index2;
+ const uint execmask = mach->ExecMask;
+ index2.i[0] =
+ index2.i[1] =
+ index2.i[2] =
+ index2.i[3] = dst->Indirect.Index;
+
+ fetch_src_file_channel(mach,
+ dst->Indirect.File,
+ dst->Indirect.Swizzle,
+ ,
+ ,
+ _index);
+ for (i = 0; i < TGSI_QUAD_SIZE; i++) {
+ if (execmask & (1 << i)) {
+unit = dst->Register.Index + indir_index.i[i];
+break;
+ }
+ }
+ } else {
+ unit = dst->Register.Index;
+ }
+ return unit;
+}
+
static void
exec_store_img(struct tgsi_exec_machine *mach,
const struct tgsi_full_instruction *inst)
@@ -3955,7 +3987,7 @@ exec_store_img(struct tgsi_exec_machine *mach,
int i, j;
uint unit;
int kilmask = mach->Temps[TEMP_KILMASK_I].xyzw[TEMP_KILMASK_C].u[0];
- unit = inst->Dst[0].Register.Index;
+ unit = fetch_store_img_unit(mach, >Dst[0]);
dim = get_image_coord_dim(inst->Memory.Texture);
sample = get_image_coord_sample(inst->Memory.Texture);
assert(dim <= 3);
@@ -3999,7 +4031,7 @@ exec_store_buf(struct tgsi_exec_machine *mach,
uint unit;
int kilmask = mach->Temps[TEMP_KILMASK_I].xyzw[TEMP_KILMASK_C].u[0];
- unit = inst->Dst[0].Register.Index;
+ unit = fetch_store_img_unit(mach, >Dst[0]);
params.execmask = mach->ExecMask & mach->NonHelperMask & ~kilmask;
params.unit = unit;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] softpipe/draw: fix vertex id in soft paths.
From: Dave Airlie
This fixes the vertex id fetch in the non-llvm drawing paths.
This vertex id in elt mode comes from the elts not just a linear
value.
Note we don't bad basevertex in the elts case as it's already included
in the elts by the looks of it (at least tests fail if I add it)
Fixes piglit end-primitive tests and some others.
---
.../auxiliary/draw/draw_pt_fetch_shade_pipeline.c | 13 +
src/gallium/auxiliary/draw/draw_vs.h| 3 ++-
src/gallium/auxiliary/draw/draw_vs_exec.c | 7 ---
src/gallium/auxiliary/draw/draw_vs_llvm.c | 3 ++-
src/gallium/auxiliary/draw/draw_vs_variant.c| 4 ++--
5 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
index f76e022994a..3207932c601 100644
--- a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
+++ b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
@@ -205,6 +205,7 @@ static void
draw_vertex_shader_run(struct draw_vertex_shader *vshader,
const void *constants[PIPE_MAX_CONSTANT_BUFFERS],
unsigned const_size[PIPE_MAX_CONSTANT_BUFFERS],
+ const struct draw_fetch_info *fetch_info,
const struct draw_vertex_info *input_verts,
struct draw_vertex_info *output_verts)
{
@@ -222,7 +223,8 @@ draw_vertex_shader_run(struct draw_vertex_shader *vshader,
const_size,
input_verts->count,
input_verts->vertex_size,
- input_verts->vertex_size);
+ input_verts->vertex_size,
+ fetch_info->elts);
}
@@ -267,18 +269,17 @@ fetch_pipeline_generic(struct draw_pt_middle_end *middle,
*/
fetch( fpme->fetch, fetch_info, (char *)fetched_vert_info.verts );
- /* Finished with fetch:
-*/
- fetch_info = NULL;
vert_info = _vert_info;
/* Run the shader, note that this overwrites the data[] parts of
* the pipeline verts.
+* Need fetch info to get vertex id correct.
*/
if (fpme->opt & PT_SHADE) {
draw_vertex_shader_run(vshader,
draw->pt.user.vs_constants,
draw->pt.user.vs_constants_size,
+ fetch_info,
vert_info,
_vert_info);
@@ -286,6 +287,10 @@ fetch_pipeline_generic(struct draw_pt_middle_end *middle,
vert_info = _vert_info;
}
+ /* Finished with fetch:
+*/
+ fetch_info = NULL;
+
if ((fpme->opt & PT_SHADE) && gshader) {
draw_geometry_shader_run(gshader,
draw->pt.user.gs_constants,
diff --git a/src/gallium/auxiliary/draw/draw_vs.h
b/src/gallium/auxiliary/draw/draw_vs.h
index 6a900224c11..65520ea6e7a 100644
--- a/src/gallium/auxiliary/draw/draw_vs.h
+++ b/src/gallium/auxiliary/draw/draw_vs.h
@@ -140,7 +140,8 @@ struct draw_vertex_shader {
const unsigned const_size[PIPE_MAX_CONSTANT_BUFFERS],
unsigned count,
unsigned input_stride,
- unsigned output_stride );
+ unsigned output_stride,
+ const unsigned *fetch_elts);
void (*delete)( struct draw_vertex_shader * );
diff --git a/src/gallium/auxiliary/draw/draw_vs_exec.c
b/src/gallium/auxiliary/draw/draw_vs_exec.c
index dbd7aa551eb..c1f8edaae69 100644
--- a/src/gallium/auxiliary/draw/draw_vs_exec.c
+++ b/src/gallium/auxiliary/draw/draw_vs_exec.c
@@ -93,7 +93,8 @@ vs_exec_run_linear(struct draw_vertex_shader *shader,
const unsigned const_size[PIPE_MAX_CONSTANT_BUFFERS],
unsigned count,
unsigned input_stride,
- unsigned output_stride)
+ unsigned output_stride,
+ const unsigned *fetch_elts)
{
struct exec_vertex_shader *evs = exec_vertex_shader(shader);
struct tgsi_exec_machine *machine = evs->machine;
@@ -133,7 +134,7 @@ vs_exec_run_linear(struct draw_vertex_shader *shader,
if (shader->info.uses_vertexid) {
unsigned vid = machine->SysSemanticToIndex[TGSI_SEMANTIC_VERTEXID];
assert(vid < ARRAY_SIZE(machine->SystemValue));
-machine->SystemValue[vid].xyzw[0].i[j] = i + j + basevertex;
+machine->SystemValue[vid].xyzw[0].i[j] = fetch_elts ? fetch_elts[i
+ j] : (i + j + basevertex);
}
if (shader->info.uses_basevertex) {
unsigned vid =
machine->SysSemanticToIndex[TGSI_SEMANTIC_BASEVERTEX];
@@ -143,7 +144,7 @@ vs_exec_run_linear(struct draw_vertex_shader *shader,
if (shader->info.uses_vertexid_nobase) {
unsigned vid =
[Mesa-dev] [Bug 110240] Assassins Creed Odyssey crashes with nir errors
https://bugs.freedesktop.org/show_bug.cgi?id=110240 james.dut...@gmail.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from james.dut...@gmail.com --- Fixed in git master. -- 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 110240] Assassins Creed Odyssey crashes with nir errors
https://bugs.freedesktop.org/show_bug.cgi?id=110240 --- Comment #8 from james.dut...@gmail.com --- git checkout master at point: git checkout 15f131b7b7fdb9baca69e19eedf16b4568ab32c8 is Good. The ACO benchmark test passes. -- 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] [ANNOUNCE] mesa 19.0.1
Hi List,
I'd like to announce the availability of mesa 19.0.1.
This is the first bug fix release of the 19.0 branch. It's been a
pretty calm cycle, and there's not too much here. I think things are
looking pretty good overall.
Dylan
shortlog:
Andres Gomez (4):
glsl: correctly validate component layout qualifier for dvec{3,4}
glsl/linker: don't fail non static used inputs without matching outputs
glsl/linker: simplify xfb_offset vs xfb_stride overflow check
Revert "glsl: relax input->output validation for SSO programs"
Bas Nieuwenhuizen (2):
radv: Use correct image view comparison for fast clears.
ac/nir: Return frag_coord as integer.
Danylo Piliaiev (2):
anv: Treat zero size XFB buffer as disabled
glsl: Cross validate variable's invariance by explicit invariance only
Dave Airlie (1):
softpipe: fix texture view crashes
Dylan Baker (6):
docs: Add SHA256 sums for 19.0.0
cherry-ignore: Add commit that doesn't apply
bin/install_megadrivers.py: Correctly handle DESTDIR=''
bin/install_megadrivers.py: Fix regression for set DESTDIR
bump version for 19.0.1
Add release notes for 19.0.1
Eric Anholt (1):
v3d: Fix leak of the renderonly struct on screen destruction.
Jason Ekstrand (6):
glsl/lower_vector_derefs: Don't use a temporary for TCS outputs
glsl/list: Add a list variant of insert_after
anv/pass: Flag the need for a RT flush for resolve attachments
nir/builder: Add a vector extract helper
nir: Add a new pass to lower array dereferences on vectors
intel/nir: Lower array-deref-of-vector UBO and SSBO loads
Józef Kucia (2):
radv: Fix driverUUID
mesa: Fix GL_NUM_DEVICE_UUIDS_EXT
Kenneth Graunke (1):
intel/fs: Fix opt_peephole_csel to not throw away saturates.
Kevin Strasser (1):
egl/dri: Avoid out of bounds array access
Mark Janes (1):
mesa: properly report the length of truncated log messages
Plamena Manolova (1):
i965: Disable ARB_fragment_shader_interlock for platforms prior to GEN9
Samuel Pitoiset (3):
radv: set the maximum number of IBs per submit to 192
radv: always initialize HTILE when the src layout is UNDEFINED
radv: fix binding transform feedback buffers
Sergii Romantsov (1):
d3d: meson: do not prefix user provided d3d-drivers-path
Tapani Pälli (2):
isl: fix automake build when sse41 is not supported
anv/radv: release memory allocated by glsl types during spirv_to_nir
git tag: mesa-19.0.1
https://mesa.freedesktop.org/archive/mesa-19.0.1.tar.gz
MD5: 0eaf26c82f3ebf0820a8fecba0925077 mesa-19.0.1.tar.gz
SHA1: 0a03191e75cc7da2492e245ae7c5aac023298d2d mesa-19.0.1.tar.gz
SHA256: f1dd1980ed628edea3935eed7974fbc5d8353e9578c562728b880d63ac613dbd
mesa-19.0.1.tar.gz
SHA512:
2af0f72df866c7bd2dfec655735f6c435dd5dde680461e8f5a774d67cd45f013551660100d7d0c2d2aec55f88913ec25e6ed1c6c0ebdcba606e00ef4578e6d70
mesa-19.0.1.tar.gz
PGP: https://mesa.freedesktop.org/archive/mesa-19.0.1.tar.gz.sig
https://mesa.freedesktop.org/archive/mesa-19.0.1.tar.xz
MD5: 19636bb3da35c21f43040d31e575d5ce mesa-19.0.1.tar.xz
SHA1: 41e825653b29c847912d51a37ff4cff4bab3d878 mesa-19.0.1.tar.xz
SHA256: 6884163c0ea9e4c98378ab8fecd72fe7b5f437713a14471beda378df247999d4
mesa-19.0.1.tar.xz
SHA512:
13afade840dfc44198b08298c9ebeb24c626c98bfff3ec6d08daaaea690ea9d47af466c877146f9afa3b45035e02c1e21fdc4b53a79c99e38dfc6126efe8ece5
mesa-19.0.1.tar.xz
PGP: https://mesa.freedesktop.org/archive/mesa-19.0.1.tar.xz.sig
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel/compiler/icl: Use tcs barrier id bits 24:30 instead of 24:27
Similarly to 1cc17fb731466c68586915acbb916586457b19bc
Fixes gpu hangs with dEQP-VK.tessellation.shader_input_output.barrier
CC: Anuj Phogat
CC: Clayton Craft
Signed-off-by: Topi Pohjolainen
---
src/intel/compiler/brw_fs_nir.cpp | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 747529e72d8..ee8274de65a 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -2458,15 +2458,24 @@ fs_visitor::nir_emit_tcs_intrinsic(const fs_builder
,
bld.exec_all().MOV(m0, brw_imm_ud(0u));
/* Copy "Barrier ID" from r0.2, bits 16:13 */
- chanbld.AND(m0_2, retype(brw_vec1_grf(0, 2), BRW_REGISTER_TYPE_UD),
- brw_imm_ud(INTEL_MASK(16, 13)));
+ if (devinfo->gen < 11) {
+ chanbld.AND(m0_2, retype(brw_vec1_grf(0, 2), BRW_REGISTER_TYPE_UD),
+ brw_imm_ud(INTEL_MASK(16, 13)));
- /* Shift it up to bits 27:24. */
- chanbld.SHL(m0_2, m0_2, brw_imm_ud(11));
+ /* Shift it up to bits 27:24. */
+ chanbld.SHL(m0_2, m0_2, brw_imm_ud(11));
+ } else {
+ chanbld.AND(m0_2, retype(brw_vec1_grf(0, 2), BRW_REGISTER_TYPE_UD),
+ brw_imm_ud(INTEL_MASK(30, 24)));
+ }
/* Set the Barrier Count and the enable bit */
- chanbld.OR(m0_2, m0_2,
- brw_imm_ud(tcs_prog_data->instances << 9 | (1 << 15)));
+ if (devinfo->gen < 11)
+ chanbld.OR(m0_2, m0_2,
+brw_imm_ud(tcs_prog_data->instances << 9 | (1 << 15)));
+ else
+ chanbld.OR(m0_2, m0_2,
+brw_imm_ud(tcs_prog_data->instances << 8 | (1 << 15)));
bld.emit(SHADER_OPCODE_BARRIER, bld.null_reg_ud(), m0);
break;
--
2.13.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110240] Assassins Creed Odyssey crashes with nir errors
https://bugs.freedesktop.org/show_bug.cgi?id=110240 --- Comment #7 from Jason Ekstrand --- Got a proper bisect: commit 4e1bbb000cdfe4ba01bee5a6868c54fed7285dae Author: Tapani Pälli Date: Tue Mar 19 11:01:53 2019 +0200 anv/radv: release memory allocated by glsl types during spirv_to_nir Fixes leaks for each glsl_type generated: ==32470== 384 bytes in 3 blocks are possibly lost in loss record 18 of 18 ==32470==at 0x483880B: malloc (vg_replace_malloc.c:309) ==32470==by 0x4C43F4A: ralloc_size (ralloc.c:119) ==32470==by 0x4C44014: rzalloc_size (ralloc.c:151) ==32470==by 0x4C44258: rzalloc_array_size (ralloc.c:215) ==32470==by 0x4D38957: glsl_type::glsl_type(glsl_struct_field const*, unsigned int, char const*) (glsl_types.cpp:114) ==32470==by 0x4D3BEED: glsl_type::get_struct_instance(glsl_struct_field const*, unsigned int, char const*) (glsl_types.cpp:1146) ==32470==by 0x4D42ECC: glsl_struct_type (nir_types.cpp:501) ==32470==by 0x4CDB5A1: vtn_handle_type (spirv_to_nir.c:1269) ==32470==by 0x4CE53DD: vtn_handle_variable_or_type_instruction (spirv_to_nir.c:4018) ==32470==by 0x4CD8CFF: vtn_foreach_instruction (spirv_to_nir.c:365) ==32470==by 0x4CE5E6B: spirv_to_nir (spirv_to_nir.c:4490) ==32470==by 0x497AF10: anv_shader_compile_to_nir (anv_pipeline.c:173) v2: move release call to vkDestroyInstance v3: apply fix also to radv driver Signed-off-by: Tapani Pälli Cc: mesa-sta...@lists.freedesktop.org Reviewed-by: Jason Ekstrand I've reverted that patch on master and it's now playing properly. -- 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] [PATCH] nir: Lock around validation fail shader dumping
---
src/compiler/nir/nir_validate.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/compiler/nir/nir_validate.c b/src/compiler/nir/nir_validate.c
index ef2e2b62783..f8327c0dd45 100644
--- a/src/compiler/nir/nir_validate.c
+++ b/src/compiler/nir/nir_validate.c
@@ -26,6 +26,7 @@
*/
#include "nir.h"
+#include "c11/threads.h"
#include
/*
@@ -1169,11 +1170,18 @@ destroy_validate_state(validate_state *state)
_mesa_hash_table_destroy(state->errors, NULL);
}
+mtx_t fail_dump_mutex = _MTX_INITIALIZER_NP;
+
static void
dump_errors(validate_state *state, const char *when)
{
struct hash_table *errors = state->errors;
+ /* Lock around dumping so that we get clean dumps in a multi-threaded
+* scenario
+*/
+ mtx_lock(_dump_mutex);
+
if (when) {
fprintf(stderr, "NIR validation failed %s\n", when);
fprintf(stderr, "%d errors:\n", _mesa_hash_table_num_entries(errors));
@@ -1192,6 +1200,8 @@ dump_errors(validate_state *state, const char *when)
}
}
+ mtx_unlock(_dump_mutex);
+
abort();
}
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110141] glesv1_cm.pc and glesv2.pc missing after b01524fff05eef66e8cd24f1c5aacefed4209f03
https://bugs.freedesktop.org/show_bug.cgi?id=110141 Eric Engestrom changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEEDINFO|RESOLVED --- Comment #8 from Eric Engestrom --- OK, closing this. Ajax provided NVIDIA with a fix for GLVND 3 years ago (I wasn't aware, thanks! :), but they haven't done anything yet. Everyone who Cc'ed yourself here, I'm assuming you have a stake in this issue. I recommend you go on https://github.com/NVIDIA/libglvnd/pull/86 and put pressure on NVIDIA to accept the fix (or come up with something else if they prefer) :) -- 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 5/5] panfrost: Wait for last job to finish in force_flush_fragment
Reviewed-by: Alyssa Rosenzweig Nice one :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] panfrost: Pass the context BOs to the kernel so they aren't unmapped while in use
Reviewed-by: Alyssa Rosenzweig I concede when it's laid out like this, the number of scratchbuffers is a _little_ excessive. varying_mem is interesting since in the ES2 sense, it's purple internal scratch, but in ES3, it's a plain old CPU-usable buffer (which is how they implement transform feedback with 0 silicon). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] panfrost: Also tell the kernel about the checksum_slab
Reviewed-by: Alyssa Rosenzweig Good catch, thank you! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] panfrost: Set the GEM handle for AFBC buffers
Reviewed-by: Alyssa Rosenzweig ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] panfrost: Fix sscanf format options
Should be "%" PRIx64, I think? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] panfrost: Fix sscanf format options
Signed-off-by: Tomeu Vizoso --- src/gallium/drivers/panfrost/pandecode/cmdline.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/panfrost/pandecode/cmdline.c b/src/gallium/drivers/panfrost/pandecode/cmdline.c index b2ba21cfe414..07bffdb5c493 100644 --- a/src/gallium/drivers/panfrost/pandecode/cmdline.c +++ b/src/gallium/drivers/panfrost/pandecode/cmdline.c @@ -126,7 +126,7 @@ pandecode_read_mmap(const char *base, const char *line) mali_ptr addr; char name[512]; -sscanf(line, "MMAP %lx %s", , name); +sscanf(line, "MMAP %llx %s", , name); pandecode_read_memory(base, name, addr); } @@ -137,7 +137,7 @@ pandecode_read_job_submit(const char *base, const char *line) unsigned core_req; unsigned is_bifrost; -sscanf(line, "JS %lx %x %x", , _req, _bifrost); +sscanf(line, "JS %llx %x %x", , _req, _bifrost); pandecode_replay_jc(addr, is_bifrost); } -- 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] panfrost: Pass the context BOs to the kernel so they aren't unmapped while in use
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_drm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_drm.c
b/src/gallium/drivers/panfrost/pan_drm.c
index 0a7cf47c6a36..887bf19148e7 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -206,7 +206,7 @@ panfrost_drm_submit_job(struct panfrost_context *ctx, u64
job_desc, int reqs, st
struct panfrost_screen *screen = pan_screen(gallium->screen);
struct panfrost_drm *drm = (struct panfrost_drm *)screen->driver;
struct drm_panfrost_submit submit = {0,};
-int bo_handles[2];
+int bo_handles[7];
submit.in_syncs = (u64) (uintptr_t) >out_sync;
submit.in_sync_count = 1;
@@ -216,8 +216,6 @@ panfrost_drm_submit_job(struct panfrost_context *ctx, u64
job_desc, int reqs, st
submit.jc = job_desc;
submit.requirements = reqs;
- /* TODO: We should be passing the transient data as a BO, so the kernel
doesn't unmap while in use */
-
if (surf) {
struct panfrost_resource *res = pan_resource(surf->texture);
assert(res->bo->gem_handle > 0);
@@ -227,6 +225,14 @@ panfrost_drm_submit_job(struct panfrost_context *ctx, u64
job_desc, int reqs, st
bo_handles[submit.bo_handle_count++] =
res->bo->checksum_slab.gem_handle;
}
+ /* TODO: Add here the transient pools */
+ bo_handles[submit.bo_handle_count++] = ctx->shaders.gem_handle;
+ bo_handles[submit.bo_handle_count++] = ctx->scratchpad.gem_handle;
+ bo_handles[submit.bo_handle_count++] = ctx->tiler_heap.gem_handle;
+ bo_handles[submit.bo_handle_count++] = ctx->varying_mem.gem_handle;
+ bo_handles[submit.bo_handle_count++] = ctx->misc_0.gem_handle;
+ submit.bo_handles = (u64)bo_handles;
+
/* Dump memory _before_ submitting so we're not corrupted with actual
GPU results */
pantrace_dump_memory();
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] panfrost: Wait for last job to finish in force_flush_fragment
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_drm.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_drm.c
b/src/gallium/drivers/panfrost/pan_drm.c
index 887bf19148e7..c30beaf2b500 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -296,6 +296,14 @@ panfrost_drm_force_flush_fragment(struct panfrost_context
*ctx,
struct pipe_fence_handle **fence)
{
struct pipe_context *gallium = (struct pipe_context *) ctx;
+struct panfrost_screen *screen = pan_screen(gallium->screen);
+struct panfrost_drm *drm = (struct panfrost_drm *)screen->driver;
+int ret;
+
+if (!screen->last_fragment_flushed) {
+ drmSyncobjWait(drm->fd, >out_sync, 1, INT64_MAX, 0, NULL);
+screen->last_fragment_flushed = true;
+ }
if (fence) {
struct panfrost_fence *f = panfrost_fence_create(ctx);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] panfrost: Also tell the kernel about the checksum_slab
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_drm.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_drm.c
b/src/gallium/drivers/panfrost/pan_drm.c
index f4580da9f509..0a7cf47c6a36 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -206,6 +206,7 @@ panfrost_drm_submit_job(struct panfrost_context *ctx, u64
job_desc, int reqs, st
struct panfrost_screen *screen = pan_screen(gallium->screen);
struct panfrost_drm *drm = (struct panfrost_drm *)screen->driver;
struct drm_panfrost_submit submit = {0,};
+int bo_handles[2];
submit.in_syncs = (u64) (uintptr_t) >out_sync;
submit.in_sync_count = 1;
@@ -215,10 +216,15 @@ panfrost_drm_submit_job(struct panfrost_context *ctx, u64
job_desc, int reqs, st
submit.jc = job_desc;
submit.requirements = reqs;
+ /* TODO: We should be passing the transient data as a BO, so the kernel
doesn't unmap while in use */
+
if (surf) {
struct panfrost_resource *res = pan_resource(surf->texture);
- submit.bo_handles = (u64) >bo->gem_handle;
- submit.bo_handle_count = 1;
+ assert(res->bo->gem_handle > 0);
+ bo_handles[submit.bo_handle_count++] = res->bo->gem_handle;
+
+ if (res->bo->checksum_slab.gem_handle)
+ bo_handles[submit.bo_handle_count++] =
res->bo->checksum_slab.gem_handle;
}
/* Dump memory _before_ submitting so we're not corrupted with actual
GPU results */
@@ -248,9 +254,8 @@ panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx,
bool has_draws, bool
}
ret = panfrost_drm_submit_job(ctx, panfrost_fragment_job(ctx),
PANFROST_JD_REQ_FS, surf);
- assert(!ret);
-return 0;
+return ret;
}
static struct panfrost_fence *
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] panfrost: Set the GEM handle for AFBC buffers
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 d242c3f90cea..c513791615ea 100644 --- a/src/gallium/drivers/panfrost/pan_context.c +++ b/src/gallium/drivers/panfrost/pan_context.c @@ -87,6 +87,7 @@ panfrost_enable_afbc(struct panfrost_context *ctx, struct panfrost_resource *rsr rsrc->bo->gpu = rsrc->bo->afbc_slab.gpu | (ds ? 0 : 1); rsrc->bo->cpu = rsrc->bo->afbc_slab.cpu; +rsrc->bo->gem_handle = rsrc->bo->afbc_slab.gem_handle; } static void -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110240] Assassins Creed Odyssey crashes with nir errors
https://bugs.freedesktop.org/show_bug.cgi?id=110240 --- Comment #6 from Jason Ekstrand --- This bug appears to be some sort of memory corruption in the type system. In particular, type names show up garbled in most of the validation fail dumps. I'm still working on where the corruption could be coming from. This seems to be related to this commit: commit 9d0ae777dd68dad682dcc7768726996639ae2684 Author: Caio Marcelo de Oliveira Filho Date: Thu Mar 21 13:26:48 2019 -0700 spirv: Use interface type for block and buffer block Also handle GLSL_TYPE_INTERFACE the same way we do GLSL_TYPE_STRUCT in various places. Motivated by ARB_gl_spirv work, that will take advantage of the interface types when handling NIR coming from SPIR-V. Reviewed-by: Jason Ekstrand Though I have no idea why this is causing problems.:-( -- 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
Re: [Mesa-dev] [PATCH] etnaviv: shrink struct etna_3d_state
Am Mittwoch, den 27.03.2019, 14:58 +0100 schrieb Christian Gmeiner:
> Drop struct members which are only written to but never read from.
>
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> src/gallium/drivers/etnaviv/etnaviv_emit.c | 17 -
> src/gallium/drivers/etnaviv/etnaviv_internal.h | 6 --
> 2 files changed, 23 deletions(-)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c
> b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> index f788896dd8..ed7b7ee3cb 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> @@ -250,21 +250,6 @@ etna_emit_state(struct etna_context *ctx)
> etna_set_state(stream, VIVS_TS_FLUSH_CACHE, VIVS_TS_FLUSH_CACHE_FLUSH);
> }
>
> - /* If MULTI_SAMPLE_CONFIG.MSAA_SAMPLES changed, clobber affected shader
> -* state to make sure it is always rewritten. */
> - if (unlikely(dirty & (ETNA_DIRTY_FRAMEBUFFER))) {
> - if ((ctx->gpu3d.GL_MULTI_SAMPLE_CONFIG &
> VIVS_GL_MULTI_SAMPLE_CONFIG_MSAA_SAMPLES__MASK) !=
> - (ctx->framebuffer.GL_MULTI_SAMPLE_CONFIG &
> VIVS_GL_MULTI_SAMPLE_CONFIG_MSAA_SAMPLES__MASK)) {
> - /* XXX what does the GPU set these states to on MSAA samples change?
> - * Does it do the right thing?
> - * (increase/decrease as necessary) or something else? Just set some
> - * invalid value until we know for
> - * sure. */
> - ctx->gpu3d.PS_INPUT_COUNT = 0x;
> - ctx->gpu3d.PS_TEMP_REGISTER_CONTROL = 0x;
> - }
> - }
> -
> /* Update vertex elements. This is different from any of the other
> states, in that
> * a) the number of vertex elements written matters: so write only active
> ones
> * b) the vertex element states must all be written: do not skip entries
> that stay the same */
> @@ -693,8 +678,6 @@ etna_emit_state(struct etna_context *ctx)
> /* Copy uniforms to gpu3d, so that incremental updates to uniforms are
> * possible as long as the
> * same shader remains bound */
> - ctx->gpu3d.vs_uniforms_size = ctx->shader_state.vs_uniforms_size;
> - ctx->gpu3d.ps_uniforms_size = ctx->shader_state.ps_uniforms_size;
> memcpy(ctx->gpu3d.VS_UNIFORMS, ctx->shader_state.VS_UNIFORMS,
> ctx->shader_state.vs_uniforms_size * 4);
> memcpy(ctx->gpu3d.PS_UNIFORMS, ctx->shader_state.PS_UNIFORMS,
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_internal.h
> b/src/gallium/drivers/etnaviv/etnaviv_internal.h
> index 77214d9ccb..29566dbd5e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_internal.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_internal.h
> @@ -270,12 +270,6 @@ struct compiled_shader_state {
>
> /* state of some 3d and common registers relevant to etna driver */
> struct etna_3d_state {
> - unsigned vs_uniforms_size;
> - unsigned ps_uniforms_size;
> -
> - uint32_t /*01008*/ PS_INPUT_COUNT;
> - uint32_t /*0100C*/ PS_TEMP_REGISTER_CONTROL;
> - uint32_t /*03818*/ GL_MULTI_SAMPLE_CONFIG;
> uint32_t /*05000*/ VS_UNIFORMS[VIVS_VS_UNIFORMS__LEN];
> uint32_t /*07000*/ PS_UNIFORMS[VIVS_PS_UNIFORMS__LEN];
> };
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] etnaviv: flush all pending contexts when accessing a resource with the CPU
Am Mi., 27. März 2019 um 12:23 Uhr schrieb Lucas Stach :
>
> When setting up a transfer to a resource, all contexts where the resource
> is pending must be flushed. Otherwise a write transfer might be started
> in the current context before all contexts that access the resource in
> shared (read) mode have been executed.
>
> Fixes: 64813541d575 (etnaviv: fix resource usage tracking across
> different pipe_context's)
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_transfer.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 45cd31207f70..d875803bde26 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -360,8 +360,14 @@ etna_transfer_map(struct pipe_context *pctx, struct
> pipe_resource *prsc,
>if ((trans->rsc && (etna_resource(trans->rsc)->status &
> ETNA_PENDING_WRITE)) ||
>(!trans->rsc &&
> (((usage & PIPE_TRANSFER_READ) && (rsc->status &
> ETNA_PENDING_WRITE)) ||
> - ((usage & PIPE_TRANSFER_WRITE) && rsc->status
> - pctx->flush(pctx, NULL, 0);
> + ((usage & PIPE_TRANSFER_WRITE) && rsc->status {
> + set_foreach(rsc->pending_ctx, entry) {
> +struct etna_context *pend_ctx = (struct etna_context
> *)entry->key;
> +struct pipe_context *pend_pctx = _ctx->base;
> +
> +pend_pctx->flush(pend_pctx, NULL, 0);
> + }
> + }
>
>mtx_unlock(>lock);
>
> --
> 2.20.1
>
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] etnaviv: don't flush own context when updating resource use
Am Mi., 27. März 2019 um 12:23 Uhr schrieb Lucas Stach : > > The context is self synchronizing at the GPU side, as commands are > executed in order. We must not flush our own context when updating the > resource use, as that leads to excessive flushing on effectively every > draw call, causing huge CPU overhead. > > Fixes: 64813541d575 (etnaviv: fix resource usage tracking across > different pipe_context's) > Signed-off-by: Lucas Stach Reviewed-by: Christian Gmeiner > --- > src/gallium/drivers/etnaviv/etnaviv_resource.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c > b/src/gallium/drivers/etnaviv/etnaviv_resource.c > index ab40414fbe2c..c7eedab74187 100644 > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c > @@ -666,9 +666,18 @@ etna_resource_used(struct etna_context *ctx, struct > pipe_resource *prsc, > struct etna_context *extctx = (struct etna_context *)entry->key; > struct pipe_context *pctx = >base; > > + if (extctx == ctx) > +continue; > + > pctx->flush(pctx, NULL, 0); > + /* It's safe to clear the status here. If we need to flush it means > + * either another context had the resource in exclusive (write) use, > + * or we transition the resource to exclusive use in our context. > + * In both cases the new status accurately reflects the resource use > + * after the flush. > + */ > + rsc->status = 0; >} > - rsc->status = 0; > } > > rsc->status |= status; > -- > 2.20.1 > -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] etnaviv: only try to construct scanout resource when on KMS winsys
Am Mi., 27. März 2019 um 12:25 Uhr schrieb Lucas Stach :
>
> Trying to construct a scanout capable buffer will only ever work when
> when we are on top of a KMS winsys, as the render node isn't capable
> of allocating contiguous buffers.
>
> Tested-by: Marius Vlad
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_resource.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index c7eedab74187..83179d3cd088 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -238,7 +238,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, unsigned
> layout,
> if (!screen->specs.use_blt && templat->target != PIPE_BUFFER)
>etna_adjust_rs_align(screen->specs.pixel_pipes, NULL, );
>
> - if (templat->bind & PIPE_BIND_SCANOUT) {
> + if (templat->bind & PIPE_BIND_SCANOUT && screen->ro->kms_fd >= 0) {
>struct pipe_resource scanout_templat = *templat;
>struct renderonly_scanout *scanout;
>struct winsys_handle handle;
> --
> 2.20.1
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] etnaviv: shrink struct etna_3d_state
Drop struct members which are only written to but never read from.
Signed-off-by: Christian Gmeiner
---
src/gallium/drivers/etnaviv/etnaviv_emit.c | 17 -
src/gallium/drivers/etnaviv/etnaviv_internal.h | 6 --
2 files changed, 23 deletions(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c
b/src/gallium/drivers/etnaviv/etnaviv_emit.c
index f788896dd8..ed7b7ee3cb 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
@@ -250,21 +250,6 @@ etna_emit_state(struct etna_context *ctx)
etna_set_state(stream, VIVS_TS_FLUSH_CACHE, VIVS_TS_FLUSH_CACHE_FLUSH);
}
- /* If MULTI_SAMPLE_CONFIG.MSAA_SAMPLES changed, clobber affected shader
-* state to make sure it is always rewritten. */
- if (unlikely(dirty & (ETNA_DIRTY_FRAMEBUFFER))) {
- if ((ctx->gpu3d.GL_MULTI_SAMPLE_CONFIG &
VIVS_GL_MULTI_SAMPLE_CONFIG_MSAA_SAMPLES__MASK) !=
- (ctx->framebuffer.GL_MULTI_SAMPLE_CONFIG &
VIVS_GL_MULTI_SAMPLE_CONFIG_MSAA_SAMPLES__MASK)) {
- /* XXX what does the GPU set these states to on MSAA samples change?
- * Does it do the right thing?
- * (increase/decrease as necessary) or something else? Just set some
- * invalid value until we know for
- * sure. */
- ctx->gpu3d.PS_INPUT_COUNT = 0x;
- ctx->gpu3d.PS_TEMP_REGISTER_CONTROL = 0x;
- }
- }
-
/* Update vertex elements. This is different from any of the other states,
in that
* a) the number of vertex elements written matters: so write only active
ones
* b) the vertex element states must all be written: do not skip entries
that stay the same */
@@ -693,8 +678,6 @@ etna_emit_state(struct etna_context *ctx)
/* Copy uniforms to gpu3d, so that incremental updates to uniforms are
* possible as long as the
* same shader remains bound */
- ctx->gpu3d.vs_uniforms_size = ctx->shader_state.vs_uniforms_size;
- ctx->gpu3d.ps_uniforms_size = ctx->shader_state.ps_uniforms_size;
memcpy(ctx->gpu3d.VS_UNIFORMS, ctx->shader_state.VS_UNIFORMS,
ctx->shader_state.vs_uniforms_size * 4);
memcpy(ctx->gpu3d.PS_UNIFORMS, ctx->shader_state.PS_UNIFORMS,
diff --git a/src/gallium/drivers/etnaviv/etnaviv_internal.h
b/src/gallium/drivers/etnaviv/etnaviv_internal.h
index 77214d9ccb..29566dbd5e 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_internal.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_internal.h
@@ -270,12 +270,6 @@ struct compiled_shader_state {
/* state of some 3d and common registers relevant to etna driver */
struct etna_3d_state {
- unsigned vs_uniforms_size;
- unsigned ps_uniforms_size;
-
- uint32_t /*01008*/ PS_INPUT_COUNT;
- uint32_t /*0100C*/ PS_TEMP_REGISTER_CONTROL;
- uint32_t /*03818*/ GL_MULTI_SAMPLE_CONFIG;
uint32_t /*05000*/ VS_UNIFORMS[VIVS_VS_UNIFORMS__LEN];
uint32_t /*07000*/ PS_UNIFORMS[VIVS_PS_UNIFORMS__LEN];
};
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110259] radv: Sampling depth-stencil image in GENERAL layout returns nothing but zero (regression, bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=110259 Bug ID: 110259 Summary: radv: Sampling depth-stencil image in GENERAL layout returns nothing but zero (regression, bisected) Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: philip.rebo...@tu-dortmund.de QA Contact: mesa-dev@lists.freedesktop.org Hello, in some cases, DXVK creates depth-stencil images that are never transitioned out of VK_IMAGE_LAYOUT_GENERAL. From a D3D11 point of view, these images are only ever used for data transfers, and some of those transfers are implemented via compute shaders, so the usage flags are (TRANSFER_SRC | TRANSFER_DST | SAMPLED). The problem is that the compute shaders in question read nothing but zeroes when using the GENERAL layout for sampling. It does work correctly when using SHADER_READ_ONLY_OPTIMAL, and it also works fine when setting RADV_DEBUG=nohiz. Here's a renderdoc capture illustrating the issue: https://mega.nz/#!5DAn3IhB!5Z7LWX0phZc3GBmYV86YpbYouueU-C342MbqYHjy_PU The bookmarked dispatch call reads the image and packs its contents into a buffer. All buffer values should be 0x00FF if things work correctly, but are 0x right now. The commit which introduced the issue is: commit 3a2e93147f7fa4a6fd17313353113a33291c5ce0 (refs/bisect/bad) Author: Samuel Pitoiset Date: Thu Mar 14 14:27:03 2019 +0100 radv: always initialize HTILE when the src layout is UNDEFINED This issue currently breaks the games Lords of the Fallen and The Surge. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] Mesa 18.3.6 release candidate
Hello list,
The candidate for the Mesa 18.3.6 is now available. Currently we have:
- 19 queued
- 0 nominated (outstanding)
- and 0 rejected patches
Note: this is the final anticipated release in the 18.3 series. Users are
encouraged to migrate to the 19.0 series in order to obtain future fixes.
The current queue consists mainly of GLSL improvements. We also have a few
UUID fixes in for both GL and Vulkan drivers.
The i965 driver has been addressed to correctly advertise the extension
ARB_fragment_shader_interlock - platforms prior to GEN9 lack this feature.
The Vulkan RADV driver and GL softpipe one have also received some fixes.
On the meson build side - a missing dependency tracking was fixed, while
improving support when using DESTDIR.
Take a look at section "Mesa stable queue" for more information.
Testing reports/general approval
Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.
The plan is to have 18.3.6 this Thursday (28 March 2019), around or shortly
after 12:00 GMT.
If you have any questions or suggestions - be that about the current patch
queue or otherwise, please let me know.
Trivial merge conflicts
---
commit 8e909034639207e5dee8abb03e1537d4680398da
Author: Tobias Klausmann
vulkan/util: meson build - add wayland client include
(cherry picked from commit 29179f58c6ba8099859ea25900214dbbd3814a92)
Cheers,
Emil
Mesa stable queue
-
Queued (19)
===
Andres Gomez (4):
glsl: correctly validate component layout qualifier for dvec{3,4}
glsl/linker: don't fail non static used inputs without matching outputs
glsl/linker: simplify xfb_offset vs xfb_stride overflow check
Revert "glsl: relax input->output validation for SSO programs"
Bas Nieuwenhuizen (2):
radv: Use correct image view comparison for fast clears.
ac/nir: Return frag_coord as integer.
Danylo Piliaiev (1):
glsl: Cross validate variable's invariance by explicit invariance only
Dave Airlie (1):
softpipe: fix texture view crashes
Dylan Baker (1):
bin/install_megadrivers.py: Correctly handle DESTDIR=''
Squashed with:
bin/install_megadrivers.py: Fix regression for set DESTDIR
Emil Velikov (1):
docs: add sha256 checksums for 18.3.5
Jason Ekstrand (1):
anv/pass: Flag the need for a RT flush for resolve attachments
Józef Kucia (2):
mesa: Fix GL_NUM_DEVICE_UUIDS_EXT
radv: Fix driverUUID
Mark Janes (1):
mesa: properly report the length of truncated log messages
Plamena Manolova (1):
i965: Disable ARB_fragment_shader_interlock for platforms prior to GEN9
Samuel Pitoiset (1):
radv: fix binding transform feedback buffers
Tapani Pälli (1):
anv/radv: release memory allocated by glsl types during spirv_to_nir
Timothy Arceri (1):
st/glsl_to_nir: fix incorrect arrary access
Tobias Klausmann (1):
vulkan/util: meson build - add wayland client include
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] etnaviv: only try to construct scanout resource when on KMS winsys
Trying to construct a scanout capable buffer will only ever work when
when we are on top of a KMS winsys, as the render node isn't capable
of allocating contiguous buffers.
Tested-by: Marius Vlad
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index c7eedab74187..83179d3cd088 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -238,7 +238,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, unsigned
layout,
if (!screen->specs.use_blt && templat->target != PIPE_BUFFER)
etna_adjust_rs_align(screen->specs.pixel_pipes, NULL, );
- if (templat->bind & PIPE_BIND_SCANOUT) {
+ if (templat->bind & PIPE_BIND_SCANOUT && screen->ro->kms_fd >= 0) {
struct pipe_resource scanout_templat = *templat;
struct renderonly_scanout *scanout;
struct winsys_handle handle;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] etnaviv: flush all pending contexts when accessing a resource with the CPU
When setting up a transfer to a resource, all contexts where the resource
is pending must be flushed. Otherwise a write transfer might be started
in the current context before all contexts that access the resource in
shared (read) mode have been executed.
Fixes: 64813541d575 (etnaviv: fix resource usage tracking across
different pipe_context's)
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_transfer.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
index 45cd31207f70..d875803bde26 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
@@ -360,8 +360,14 @@ etna_transfer_map(struct pipe_context *pctx, struct
pipe_resource *prsc,
if ((trans->rsc && (etna_resource(trans->rsc)->status &
ETNA_PENDING_WRITE)) ||
(!trans->rsc &&
(((usage & PIPE_TRANSFER_READ) && (rsc->status &
ETNA_PENDING_WRITE)) ||
- ((usage & PIPE_TRANSFER_WRITE) && rsc->status
- pctx->flush(pctx, NULL, 0);
+ ((usage & PIPE_TRANSFER_WRITE) && rsc->status {
+ set_foreach(rsc->pending_ctx, entry) {
+struct etna_context *pend_ctx = (struct etna_context *)entry->key;
+struct pipe_context *pend_pctx = _ctx->base;
+
+pend_pctx->flush(pend_pctx, NULL, 0);
+ }
+ }
mtx_unlock(>lock);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] etnaviv: don't flush own context when updating resource use
The context is self synchronizing at the GPU side, as commands are executed in order. We must not flush our own context when updating the resource use, as that leads to excessive flushing on effectively every draw call, causing huge CPU overhead. Fixes: 64813541d575 (etnaviv: fix resource usage tracking across different pipe_context's) Signed-off-by: Lucas Stach --- src/gallium/drivers/etnaviv/etnaviv_resource.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c b/src/gallium/drivers/etnaviv/etnaviv_resource.c index ab40414fbe2c..c7eedab74187 100644 --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c @@ -666,9 +666,18 @@ etna_resource_used(struct etna_context *ctx, struct pipe_resource *prsc, struct etna_context *extctx = (struct etna_context *)entry->key; struct pipe_context *pctx = >base; + if (extctx == ctx) +continue; + pctx->flush(pctx, NULL, 0); + /* It's safe to clear the status here. If we need to flush it means + * either another context had the resource in exclusive (write) use, + * or we transition the resource to exclusive use in our context. + * In both cases the new status accurately reflects the resource use + * after the flush. + */ + rsc->status = 0; } - rsc->status = 0; } rsc->status |= status; -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac: use llvm.amdgcn.fmed3 intrinsic for nir_op_fmed3
r-b
On Mon, Mar 25, 2019 at 1:34 PM Samuel Pitoiset
wrote:
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/common/ac_llvm_build.c | 27 +++
> src/amd/common/ac_llvm_build.h | 4
> src/amd/common/ac_nir_to_llvm.c | 13 +
> 3 files changed, 36 insertions(+), 8 deletions(-)
>
> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
> index 1123dce2cc8..04d4b377fd1 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -2430,6 +2430,33 @@ void ac_build_waitcnt(struct ac_llvm_context *ctx,
> unsigned simm16)
>ctx->voidt, args, 1, 0);
> }
>
> +LLVMValueRef ac_build_fmed3(struct ac_llvm_context *ctx, LLVMValueRef src0,
> + LLVMValueRef src1, LLVMValueRef src2,
> + unsigned bitsize)
> +{
> + LLVMTypeRef type;
> + char *intr;
> +
> + if (bitsize == 16) {
> + intr = "llvm.amdgcn.fmed3.f16";
> + type = ctx->f16;
> + } else if (bitsize == 32) {
> + intr = "llvm.amdgcn.fmed3.f32";
> + type = ctx->f32;
> + } else {
> + intr = "llvm.amdgcn.fmed3.f64";
> + type = ctx->f64;
> + }
> +
> + LLVMValueRef params[] = {
> + src0,
> + src1,
> + src2,
> + };
> + return ac_build_intrinsic(ctx, intr, type, params, 3,
> + AC_FUNC_ATTR_READNONE);
> +}
> +
> LLVMValueRef ac_build_fract(struct ac_llvm_context *ctx, LLVMValueRef src0,
> unsigned bitsize)
> {
> diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
> index 9151c743bed..14c1c56522b 100644
> --- a/src/amd/common/ac_llvm_build.h
> +++ b/src/amd/common/ac_llvm_build.h
> @@ -549,6 +549,10 @@ void ac_build_waitcnt(struct ac_llvm_context *ctx,
> unsigned simm16);
> LLVMValueRef ac_build_fract(struct ac_llvm_context *ctx, LLVMValueRef src0,
>unsigned bitsize);
>
> +LLVMValueRef ac_build_fmed3(struct ac_llvm_context *ctx, LLVMValueRef src0,
> + LLVMValueRef src1, LLVMValueRef src2,
> + unsigned bitsize);
> +
> LLVMValueRef ac_build_isign(struct ac_llvm_context *ctx, LLVMValueRef src0,
> unsigned bitsize);
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 675623cbfeb..7fd6437049a 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -,14 +,11 @@ static void visit_alu(struct ac_nir_context *ctx,
> const nir_alu_instr *instr)
> result = emit_minmax_int(>ac, LLVMIntSGT, result,
> src[2]);
> break;
> case nir_op_fmed3: {
> - LLVMValueRef tmp1 = emit_intrin_2f_param(>ac,
> "llvm.minnum",
> - ac_to_float_type(>ac,
> def_type), src[0], src[1]);
> - LLVMValueRef tmp2 = emit_intrin_2f_param(>ac,
> "llvm.maxnum",
> - ac_to_float_type(>ac,
> def_type), src[0], src[1]);
> - tmp2 = emit_intrin_2f_param(>ac, "llvm.minnum",
> - ac_to_float_type(>ac,
> def_type), tmp2, src[2]);
> - result = emit_intrin_2f_param(>ac, "llvm.maxnum",
> - ac_to_float_type(>ac,
> def_type), tmp1, tmp2);
> + src[0] = ac_to_float(>ac, src[0]);
> + src[1] = ac_to_float(>ac, src[1]);
> + src[2] = ac_to_float(>ac, src[2]);
> + result = ac_build_fmed3(>ac, src[0], src[1], src[2],
> + instr->dest.dest.ssa.bit_size);
> break;
> }
> case nir_op_imed3: {
> --
> 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] [Bug 109159] [KBL-G][vulkan] dEQP-VK.api.version_check.entry_points test failed.
https://bugs.freedesktop.org/show_bug.cgi?id=109159 Samuel Pitoiset changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #5 from Samuel Pitoiset --- Closing. Feel free to re-open if the problem happens again. As I said I have never seen that test failed. -- 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 109805] GPU hangs with error VM_CONTEXT1_PROTECTION_FAULT_STATUS
https://bugs.freedesktop.org/show_bug.cgi?id=109805 --- Comment #13 from Samuel Pitoiset --- Are you able to reproduce the VM faults with mesa 19.0? -- 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] [PATCH] radv: do not lower UBO/SSBO access to offsets
This helps few compute shaders, mostly for F12017.
27670 shaders in 14347 tests
Totals:
SGPRS: 1231173 -> 1231173 (0.00 %)
VGPRS: 866056 -> 865928 (-0.01 %)
Spilled SGPRs: 24201 -> 24201 (0.00 %)
Code Size: 46137040 -> 46144868 (0.02 %) bytes
Max Waves: 232287 -> 232302 (0.01 %)
Totals from affected shaders:
SGPRS: 24624 -> 24624 (0.00 %)
VGPRS: 25960 -> 25832 (-0.49 %)
Spilled SGPRs: 0 -> 0 (0.00 %)
Code Size: 2922632 -> 2930460 (0.27 %) bytes
Max Waves: 1216 -> 1231 (1.23 %)
Suggested-by:
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 8
src/amd/vulkan/radv_shader.c| 5 -
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index b25cc6a0a84..c46d98e6dd9 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3275,6 +3275,14 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
case nir_intrinsic_vulkan_resource_reindex:
result = visit_vulkan_resource_reindex(ctx, instr);
break;
+ case nir_intrinsic_load_vulkan_descriptor: {
+ LLVMValueRef values[2] = {
+ get_src(ctx, instr->src[0]),
+ ctx->ac.i32_0,
+ };
+ result = ac_build_gather_values(>ac, values, 2);
+ break;
+ }
case nir_intrinsic_store_ssbo:
visit_store_ssbo(ctx, instr);
break;
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 19a807df199..2751302e8b9 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -220,7 +220,6 @@ radv_shader_compile_to_nir(struct radv_device *device,
}
}
const struct spirv_to_nir_options spirv_options = {
- .lower_ubo_ssbo_access_to_offsets = true,
.caps = {
.descriptor_array_dynamic_indexing = true,
.device_group = true,
@@ -306,6 +305,10 @@ radv_shader_compile_to_nir(struct radv_device *device,
NIR_PASS_V(nir, nir_lower_system_values);
NIR_PASS_V(nir, nir_lower_clip_cull_distance_arrays);
NIR_PASS_V(nir, nir_lower_frexp);
+
+ NIR_PASS_V(nir, nir_lower_explicit_io,
+ nir_var_mem_ubo | nir_var_mem_ssbo,
+ nir_address_format_32bit_index_offset);
}
/* Vulkan uses the separate-shader linking model */
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110240] Assassins Creed Odyssey crashes with nir errors
https://bugs.freedesktop.org/show_bug.cgi?id=110240 --- Comment #5 from james.dut...@gmail.com --- Created attachment 143786 --> https://bugs.freedesktop.org/attachment.cgi?id=143786=edit Log of wine output from "wine ACOdyssey.exe" after trying revert -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] nir: add nir_{load, store}_deref_with_access() helpers
On 3/27/19 1:25 AM, Jason Ekstrand wrote:
You could make the old ones call these. It'd make for a smaller diff
and less code to maintain.
Pushed with the suggested change.
Thanks for the reviews.
On March 26, 2019 17:10:52 Samuel Pitoiset
wrote:
Signed-off-by: Samuel Pitoiset
---
src/compiler/nir/nir_builder.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/src/compiler/nir/nir_builder.h
b/src/compiler/nir/nir_builder.h
index bcf03957bc7..9f9a05cbd09 100644
--- a/src/compiler/nir/nir_builder.h
+++ b/src/compiler/nir/nir_builder.h
@@ -1070,6 +1070,36 @@ nir_store_deref(nir_builder *build,
nir_deref_instr *deref,
nir_builder_instr_insert(build, >instr);
}
+static inline nir_ssa_def *
+nir_load_deref_with_access(nir_builder *build, nir_deref_instr *deref,
+ enum gl_access_qualifier access)
+{
+ nir_intrinsic_instr *load =
+ nir_intrinsic_instr_create(build->shader,
nir_intrinsic_load_deref);
+ load->num_components = glsl_get_vector_elements(deref->type);
+ load->src[0] = nir_src_for_ssa(>dest.ssa);
+ nir_ssa_dest_init(>instr, >dest, load->num_components,
+ glsl_get_bit_size(deref->type), NULL);
+ nir_intrinsic_set_access(load, access);
+ nir_builder_instr_insert(build, >instr);
+ return >dest.ssa;
+}
+
+static inline void
+nir_store_deref_with_access(nir_builder *build, nir_deref_instr *deref,
+ nir_ssa_def *value, unsigned writemask,
+ enum gl_access_qualifier access)
+{
+ nir_intrinsic_instr *store =
+ nir_intrinsic_instr_create(build->shader,
nir_intrinsic_store_deref);
+ store->num_components = glsl_get_vector_elements(deref->type);
+ store->src[0] = nir_src_for_ssa(>dest.ssa);
+ store->src[1] = nir_src_for_ssa(value);
+ nir_intrinsic_set_write_mask(store,
+ writemask & ((1 <<
store->num_components) - 1));
+ nir_intrinsic_set_access(store, access);
+ nir_builder_instr_insert(build, >instr);
+}
static inline void
nir_copy_deref(nir_builder *build, nir_deref_instr *dest,
nir_deref_instr *src)
{
--
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] [Bug 110240] Assassins Creed Odyssey crashes with nir errors
https://bugs.freedesktop.org/show_bug.cgi?id=110240 --- Comment #4 from james.dut...@gmail.com --- git checkout 39da1deb497af55496308c0867b5ce5a0e9df56e git revert 3b3653c4cfbedf55a00cbddd0f341ebd1de81665 The game ACO still fails to work, with a NIR compile error. Although, it might be crashing at a different point now. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110253] glBlitFramebuffer fails on MSAA fbo source.
https://bugs.freedesktop.org/show_bug.cgi?id=110253 Bug ID: 110253 Summary: glBlitFramebuffer fails on MSAA fbo source. Product: Mesa Version: 19.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/swr Assignee: mesa-dev@lists.freedesktop.org Reporter: wanghaipen...@baidu.com QA Contact: mesa-dev@lists.freedesktop.org https://github.com/mesa3d/mesa/blob/master/src/gallium/drivers/swr/swr_screen.cpp#L908 https://github.com/mesa3d/mesa/blob/master/src/gallium/drivers/swr/swr_screen.cpp#L105 when using MSAA fbo as read source, and OSMesa framebuffer as target, glBlitFramebuffer fails。 swr_blit: color resolve : 8 -> 0 swr: blit unsupported r8g8b8a8_unorm -> r8g8b8a8_unorm I think it may be solved by setting nr_storage_samples to 0 in src/gallium/drivers/swr/swr_screen.cpp swr_create_resolve_resource /* Create a single-sample copy of the resource. Copy the original * resource parameters and set flag to prevent recursion when re-calling * resource_create */ struct pipe_resource alt_template = msaa_res->base; alt_template.nr_samples = 0; alt_template.nr_storage_samples = 0; alt_template.flags |= SWR_RESOURCE_FLAG_ALT_SURFACE; -- 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 110252] swr software rasterizer fall back to OpenGL 2.1
https://bugs.freedesktop.org/show_bug.cgi?id=110252
Bug ID: 110252
Summary: swr software rasterizer fall back to OpenGL 2.1
Product: Mesa
Version: 19.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/swr
Assignee: mesa-dev@lists.freedesktop.org
Reporter: wanghaipen...@baidu.com
QA Contact: mesa-dev@lists.freedesktop.org
glGetString(GL_EXTENSIONS) returns no GL_EXT_framebuffer_sRGB, which is
required by OpenGL 3.0 (src/mesa/main/version.c compute_version)。so
glGetString(GL_VERSION) fall back to OpenGL 2.1。
#include
#include
#define GL_GLEXT_PROTOTYPES
#include
//#include
// settings
const unsigned int SCR_WIDTH = 960;
const unsigned int SCR_HEIGHT = 562;
int main(void) {
OSMesaContext ctx;
ctx = OSMesaCreateContextExt(OSMESA_RGBA, 16, 0, 0, NULL);
GLubyte *buffer = malloc(SCR_WIDTH * SCR_HEIGHT * 4 * sizeof(GLubyte));
OSMesaMakeCurrent(ctx, buffer, GL_UNSIGNED_BYTE, SCR_WIDTH, SCR_HEIGHT);
printf("GL_RENDERER = %s\n", (char*)glGetString(GL_RENDERER));
printf("GL_VERSION = %s\n", (char*)glGetString(GL_VERSION));
printf("GL_VENDOR = %s\n", (char*)glGetString(GL_VENDOR));
printf("GL_SHADING_LANGUAGE_VERSION = %s\n",
(char*)glGetString(GL_SHADING_LANGUAGE_VERSION));
printf("GL_EXTESIONS = %s\n", (char*)glGetString(GL_EXTENSIONS));
return 0;
}
--
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
