[Mesa-dev] [Bug 107991] RX580 ~ ring gfx timeout ~ particular shaders created by a dolphin-emu game can crash AMDGPU, with both RadeonSI and RADV ~ attached apitrace for RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=107991 Riikka changed: What|Removed |Added CC||princessrii...@gmail.com -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110345] Unrecoverable GPU crash with DiRT 4
https://bugs.freedesktop.org/show_bug.cgi?id=110345 Riikka changed: What|Removed |Added CC||princessrii...@gmail.com -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 98846] triangle clipping causes wrong vertex's attribute to be broadcasted for flat interpolation
https://bugs.freedesktop.org/show_bug.cgi?id=98846 Zebediah Figura changed: What|Removed |Added CC||z.figur...@gmail.com --- Comment #2 from Zebediah Figura --- This also affects softpipe and llvmpipe. I'm not familiar with mesa, but I think there are multiple places that do the wrong thing. For example, do_clip_tri() in src/gallium/auxiliary/draw/draw_pipe_clip.c gets passed the vertices in winding order, but it doesn't take that into account when determining provoking vertex. If this should be split off to a separate bug, then I'll do so. This causes failures in Wine's conformance test suite, since we use GL_FIRST_VERTEX_CONVENTION universally, and test flat shading with GL_TRIANGLESTRIP and some vertices slightly clipped outside of the viewport. Since our test suite is run in a virtual machine, it uses llvmpipe, and so is affected by this bug. -- 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] draw: fix building error in draw_gs_init()
Oops,
Reviewed-by: Dave Airlie
I can't push from here, but I'll do it tomorrow if nobody beats me.
Dave.
On Sun, 14 Apr 2019 at 02:35, Mauro Rossi wrote:
>
> Fixes the following building error happening with Android build system:
>
> external/mesa/src/gallium/auxiliary/draw/draw_gs.c:740:79:
> error: address of array 'draw->gs.tgsi.machine->PrimitiveOffsets' will always
> evaluate to 'true' [-Werror,-Wpointer-bool-conversion]
> if (!draw->gs.tgsi.machine->Primitives[i] ||
> !draw->gs.tgsi.machine->PrimitiveOffsets)
>
> ^~~~
> 1 error generated.
>
> Fixes: 7720ce3 ("draw: add support to tgsi paths for geometry streams. (v2)")
> Signed-off-by: Mauro Rossi
> ---
> src/gallium/auxiliary/draw/draw_gs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/draw/draw_gs.c
> b/src/gallium/auxiliary/draw/draw_gs.c
> index 1d6040993c..6420cfbb26 100644
> --- a/src/gallium/auxiliary/draw/draw_gs.c
> +++ b/src/gallium/auxiliary/draw/draw_gs.c
> @@ -737,7 +737,7 @@ draw_gs_init( struct draw_context *draw )
> MAX_PRIMITIVES * sizeof(struct tgsi_exec_vector), 16);
> draw->gs.tgsi.machine->PrimitiveOffsets[i] = align_malloc(
> MAX_PRIMITIVES * sizeof(struct tgsi_exec_vector), 16);
> - if (!draw->gs.tgsi.machine->Primitives[i] ||
> !draw->gs.tgsi.machine->PrimitiveOffsets)
> + if (!draw->gs.tgsi.machine->Primitives[i] ||
> !draw->gs.tgsi.machine->PrimitiveOffsets[i])
> return FALSE;
> memset(draw->gs.tgsi.machine->Primitives[i], 0,
> MAX_PRIMITIVES * sizeof(struct tgsi_exec_vector));
> --
> 2.20.1
>
> ___
> 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 00/40] intel: VK_KHR_shader_float16_int8 implementation
Jason Ekstrand writes: > Quick status check. Mesa 19.1 is supposed to branch in two weeks. Are we > about ready to land this? > Seems pretty close to ready to me... > On Mon, Mar 25, 2019 at 11:13 AM Juan A. Suarez Romero > wrote: > >> On Fri, 2019-03-22 at 17:53 +0100, Iago Toral wrote: >> > Yes, I think those should be fine to land now, they are very few >> > actually. Jason, any objections? >> > >> >> Pushed: >> - [PATCH v4 10/40] compiler/nir: add lowering option for 16-bit fmod >> - [PATCH v4 11/40] compiler/nir: add lowering for 16-bit flrp >> - [PATCH v4 12/40] compiler/nir: add lowering for 16-bit ldexp >> >> J.A. >> >> > Iago >> > >> > On Fri, 2019-03-22 at 17:26 +0100, Samuel Pitoiset wrote: >> > > Can you eventually merge all NIR patches now? We should be able to >> > > hook >> > > up that extension for RADV quite soon. >> > > >> > > On 2/12/19 12:55 PM, Iago Toral Quiroga wrote: >> > > > The changes in this version address review feedback to v3. The most >> > > > significant >> > > > changes include: >> > > > >> > > > 1. A more generic constant combining pass that can handle more >> > > > constant types (not just F and HF) requested by Jason. >> > > > >> > > > 2. The addition of assembly validation for half-float restrictions, >> > > > and also >> > > > for mixed float mode, requested by Curro. It should be noted that >> > > > this >> > > > implementation of VK_KHR_shader_float16_int8 does not emit any >> > > > mixed mode float >> > > > instructions at this moment so I have not empirically validated the >> > > > restictions >> > > > implemented here. >> > > > >> > > > As always, a branch with these patches is available for testing in >> > > > the >> > > > itoral/VK_KHR_shader_float16_int8 branch of the Igalia Mesa >> > > > repository at >> > > > https://github.com/Igalia/mesa. >> > > > >> > > > Iago Toral Quiroga (40): >> > > >compiler/nir: add an is_conversion field to nir_op_info >> > > >intel/compiler: add a NIR pass to lower conversions >> > > >intel/compiler: split float to 64-bit opcodes from int to 64-bit >> > > >intel/compiler: handle b2i/b2f with other integer conversion >> > > > opcodes >> > > >intel/compiler: assert restrictions on conversions to half-float >> > > >intel/compiler: lower some 16-bit float operations to 32-bit >> > > >intel/compiler: handle extended math restrictions for half-float >> > > >intel/compiler: implement 16-bit fsign >> > > >intel/compiler: drop unnecessary temporary from 32-bit fsign >> > > > implementation >> > > >compiler/nir: add lowering option for 16-bit fmod >> > > >compiler/nir: add lowering for 16-bit flrp >> > > >compiler/nir: add lowering for 16-bit ldexp >> > > >intel/compiler: add instruction setters for Src1Type and >> > > > Src2Type. >> > > >intel/compiler: add new half-float register type for 3-src >> > > > instructions >> > > >intel/compiler: don't compact 3-src instructions with Src1Type >> > > > or >> > > > Src2Type bits >> > > >intel/compiler: allow half-float on 3-source instructions since >> > > > gen8 >> > > >intel/compiler: set correct precision fields for 3-source float >> > > > instructions >> > > >intel/compiler: fix ddx and ddy for 16-bit float >> > > >intel/compiler: fix ddy for half-float in Broadwell >> > > >intel/compiler: workaround for SIMD8 half-float MAD in gen8 >> > > >intel/compiler: split is_partial_write() into two variants >> > > >intel/compiler: activate 16-bit bit-size lowerings also for 8- >> > > > bit >> > > >intel/compiler: rework conversion opcodes >> > > >intel/compiler: implement isign for int8 >> > > >intel/compiler: ask for an integer type if requesting an 8-bit >> > > > type >> > > >intel/eu: force stride of 2 on NULL register for Byte >> > > > instructions >> > > >intel/compiler: generalize the combine constants pass >> > > >intel/compiler: implement is_zero, is_one, is_negative_one for >> > > > 8-bit/16-bit >> > > >intel/compiler: add a brw_reg_type_is_integer helper >> > > >intel/compiler: fix cmod propagation for non 32-bit types >> > > >intel/compiler: remove inexact algebraic optimizations from the >> > > > backend >> > > >intel/compiler: skip MAD algebraic optimization for half-float >> > > > or >> > > > mixed mode >> > > >intel/compiler: also set F execution type for mixed float mode >> > > > in BDW >> > > >intel/compiler: validate region restrictions for half-float >> > > > conversions >> > > >intel/compiler: validate conversions between 64-bit and 8-bit >> > > > types >> > > >intel/compiler: skip validating restrictions on operand types >> > > > for >> > > > mixed float >> > > >intel/compiler: validate region restrictions for mixed float >> > > > mode >> > > >compiler/spirv: move the check for Int8 capability >> > > >anv/pipeline: support Float16 and Int8 SPIR-V capabilities in >> > >
Re: [Mesa-dev] [PATCH v6 32/35] intel/compiler: validate region restrictions for mixed float mode
"Juan A. Suarez Romero" writes:
> On Wed, 2019-04-10 at 17:13 -0700, Francisco Jerez wrote:
>> "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.
>> >
>> > v3 (Curro):
>> > - Check all the accummulators
>> > - Constify declarations
>> > - Do not check src1 type in single-source instructions.
>> > - Check for all instructions that read accumulator (either implicitly or
>> > explicitly)
>> > - Check restrictions in src1 too.
>> > - Merge conditional block
>> > - Add invalid test case.
>> > ---
>> > src/intel/compiler/brw_eu_validate.c| 290 +++
>> > src/intel/compiler/test_eu_validate.cpp | 631
>> > 2 files changed, 921 insertions(+)
>> >
>> > diff --git a/src/intel/compiler/brw_eu_validate.c
>> > b/src/intel/compiler/brw_eu_validate.c
>> > index cfaf126e2f5..4a735641c86 100644
>> > --- a/src/intel/compiler/brw_eu_validate.c
>> > +++ b/src/intel/compiler/brw_eu_validate.c
>> > @@ -170,6 +170,20 @@ 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) & 0xF0) ==
>> > BRW_ARF_ACCUMULATOR;
>> > +}
>> > +
>> > +static bool
>> > +src1_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
>> > +{
>> > + return brw_inst_src1_reg_file(devinfo, inst) ==
>> > BRW_ARCHITECTURE_REGISTER_FILE &&
>> > + (brw_inst_src1_da_reg_nr(devinfo, inst) & 0xF0) ==
>> > BRW_ARF_ACCUMULATOR;
>> > +}
>> > +
>> > static bool
>> > src0_is_grf(const struct gen_device_info *devinfo, const brw_inst *inst)
>> > {
>> > @@ -275,6 +289,27 @@ sources_not_null(const struct gen_device_info
>> > *devinfo,
>> > return error_msg;
>> > }
>> >
>> > +static bool
>> > +inst_uses_src_acc(const struct gen_device_info *devinfo, const brw_inst
>> > *inst)
>> > +{
>> > + /* Check instructions that use implicit accumulator sources */
>> > + switch (brw_inst_opcode(devinfo, inst)) {
>> > + case BRW_OPCODE_MAC:
>> > + case BRW_OPCODE_MACH:
>> > + case BRW_OPCODE_SADA2:
>> > + return true;
>> > + }
>> > +
>> > + /* Instructions with three source operands cannot use explicit
>> > accumulator
>> > +* operands.
>> > +*/
>>
>> They can on Gen10+. Yeah, I know, it's quite a pain to have to
>> special-case 3src instructions everywhere in the validator code...
>
>
> Checking other parts of code, I'll assume that srcN_is_acc() should return
> false
> for align16 mode; at least in them there're assertions that in this mode srcs
> can only be GRF.
>
Yes, only Align1 3-source instructions on Gen10 and greater can use the
accumulator explicitly.
> OTOH, is it worth to handle here the case for 3src instructions allowing
> explicit accumulator? If other parts of drive asume this is not possible, I
> understand it would be better to fix this in all the code in a separate
> patchset
> (not related with float16).
I think it's at least worth adding an assert(num_sources < 3) and a
FINISHME comment so whenever this function starts getting used to
validate 3-source instructions people notice it's incomplete.
Honestly it's kind of disturbing that 3-source instructions aren't being
validated at all for the most part in the EU validator. But that's not
really your fault.
[A bunch more comments below]
>
>
>>
>> > + const unsigned num_sources = num_sources_from_inst(devinfo, inst);
>> > + if (num_sources > 2)
>> > + return false;
>> > +
>> > + return src0_is_acc(devinfo, inst) || (num_sources > 1 &&
>> > src1_is_acc(devinfo, inst));
>> > +}
>> > +
>> > static struct string
>> > send_restrictions(const struct gen_device_info *devinfo,
>> >const brw_inst *inst)
>> > @@ -938,6 +973,260 @@ 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 };
>> > +
>> > + const unsigned opcode = brw_inst_opcode(devinfo, inst);
>> > + const 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;
>> >
[Mesa-dev] [Bug 109560] Sometimes VLC player process gets stuck in memory after closure if video output used is Auto or OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=109560 --- Comment #4 from Strangiato --- Bug persists with mesa 19.0.2 on Arch Linux. -- 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] android: fix LLVM version string related building errors
Hi,
On Sat, Apr 13, 2019 at 6:32 PM Eric Engestrom wrote:
>
> On 2019-04-13 at 01:36, Mauro Rossi wrote:
> > Just a message to Eric,
> >
> > as per our previous private thread,
>
> Sorry, I completely forgot to actually send the fix :facepalm:
No problem
>
> >
> > I've checked that the Android build works,
> > but we use libLLVM70 name in library dependency.
>
> I don't understand the second part is this sentence?
The patch I have submitted does not apply to mesa dev
because in android-x86 we build with libLLVM70.so shared dependency,
instead of libLLVM.so
AOSP has is own llvm, we had to do this to avoid library name
collision in Android build system
>
> >
> > Please adapt and apply the patch to mesa dev branch,
> > to fix the breakage
> >
> > \ prior to " in the LLVM version string value, just touching
> > Android.mk solves the problem for me
>
> Yes, this is the correct fix (because of the `eval`, if anyone's wondering).
>
> Reviewed-by: Eric Engestrom
>
> Unfortunately, I'm on holiday for a week now. Can you push the fix yourself?
> Otherwise, Tapani can :)
Ok, I'll proceed in the push
>
> >
> > Mauro
> >
> > On Sat, Apr 13, 2019 at 1:27 AM Mauro Rossi wrote:
> > >
> > > Fixes the following building errors:
> > >
> > > external/mesa/src/gallium/drivers/r600/r600_pipe_common.c:1290:14:
> > > error: expected ')'
> > > ", LLVM " MESA_LLVM_VERSION_STRING
> > >^
> > > :8:34: note: expanded from here
> > > ^
> > > external/mesa/src/gallium/drivers/r600/r600_pipe_common.c:1287:10:
> > > note: to match this '('
> > > snprintf(rscreen->renderer_string,
> > > sizeof(rscreen->renderer_string),
> > > ^
> > > 1 error generated.
> > >
> > > Fixes: 05b114e ("simplify LLVM version string printing")
> > > Signed-off-by: Mauro Rossi
> > > ---
> > > Android.mk | 8
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Android.mk b/Android.mk
> > > index 09139e86d1..b835eb64e9 100644
> > > --- a/Android.mk
> > > +++ b/Android.mk
> > > @@ -97,13 +97,13 @@ define mesa-build-with-llvm
> > >$(if $(filter $(MESA_ANDROID_MAJOR_VERSION), 4 5), \
> > > $(warning Unsupported LLVM version in Android
> > > $(MESA_ANDROID_MAJOR_VERSION)),) \
> > >$(if $(filter 6,$(MESA_ANDROID_MAJOR_VERSION)), \
> > > -$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0307
> > > -DMESA_LLVM_VERSION_STRING="3.7")) \
> > > +$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0307
> > > -DMESA_LLVM_VERSION_STRING=\"3.7\")) \
> > >$(if $(filter 7,$(MESA_ANDROID_MAJOR_VERSION)), \
> > > -$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0700
> > > -DMESA_LLVM_VERSION_STRING="7.0")) \
> > > +$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0700
> > > -DMESA_LLVM_VERSION_STRING=\"7.0\")) \
> > >$(if $(filter 8,$(MESA_ANDROID_MAJOR_VERSION)), \
> > > -$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0700
> > > -DMESA_LLVM_VERSION_STRING="7.0")) \
> > > +$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0700
> > > -DMESA_LLVM_VERSION_STRING=\"7.0\")) \
> > >$(if $(filter 9,$(MESA_ANDROID_MAJOR_VERSION)), \
> > > -$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0309
> > > -DMESA_LLVM_VERSION_STRING="3.9")) \
> > > +$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0309
> > > -DMESA_LLVM_VERSION_STRING=\"3.9\")) \
> > >$(eval LOCAL_SHARED_LIBRARIES += libLLVM70)
> > > endef
> > >
> > > --
> > > 2.20.1
> > >
> > ___
> > 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] draw: fix building error in draw_gs_init()
Fixes the following building error happening with Android build system:
external/mesa/src/gallium/auxiliary/draw/draw_gs.c:740:79:
error: address of array 'draw->gs.tgsi.machine->PrimitiveOffsets' will always
evaluate to 'true' [-Werror,-Wpointer-bool-conversion]
if (!draw->gs.tgsi.machine->Primitives[i] ||
!draw->gs.tgsi.machine->PrimitiveOffsets)
^~~~
1 error generated.
Fixes: 7720ce3 ("draw: add support to tgsi paths for geometry streams. (v2)")
Signed-off-by: Mauro Rossi
---
src/gallium/auxiliary/draw/draw_gs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/draw/draw_gs.c
b/src/gallium/auxiliary/draw/draw_gs.c
index 1d6040993c..6420cfbb26 100644
--- a/src/gallium/auxiliary/draw/draw_gs.c
+++ b/src/gallium/auxiliary/draw/draw_gs.c
@@ -737,7 +737,7 @@ draw_gs_init( struct draw_context *draw )
MAX_PRIMITIVES * sizeof(struct tgsi_exec_vector), 16);
draw->gs.tgsi.machine->PrimitiveOffsets[i] = align_malloc(
MAX_PRIMITIVES * sizeof(struct tgsi_exec_vector), 16);
- if (!draw->gs.tgsi.machine->Primitives[i] ||
!draw->gs.tgsi.machine->PrimitiveOffsets)
+ if (!draw->gs.tgsi.machine->Primitives[i] ||
!draw->gs.tgsi.machine->PrimitiveOffsets[i])
return FALSE;
memset(draw->gs.tgsi.machine->Primitives[i], 0,
MAX_PRIMITIVES * sizeof(struct tgsi_exec_vector));
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] android: fix LLVM version string related building errors
On 2019-04-13 at 01:36, Mauro Rossi wrote:
> Just a message to Eric,
>
> as per our previous private thread,
Sorry, I completely forgot to actually send the fix :facepalm:
>
> I've checked that the Android build works,
> but we use libLLVM70 name in library dependency.
I don't understand the second part is this sentence?
>
> Please adapt and apply the patch to mesa dev branch,
> to fix the breakage
>
> \ prior to " in the LLVM version string value, just touching
> Android.mk solves the problem for me
Yes, this is the correct fix (because of the `eval`, if anyone's wondering).
Reviewed-by: Eric Engestrom
Unfortunately, I'm on holiday for a week now. Can you push the fix yourself?
Otherwise, Tapani can :)
>
> Mauro
>
> On Sat, Apr 13, 2019 at 1:27 AM Mauro Rossi wrote:
> >
> > Fixes the following building errors:
> >
> > external/mesa/src/gallium/drivers/r600/r600_pipe_common.c:1290:14:
> > error: expected ')'
> > ", LLVM " MESA_LLVM_VERSION_STRING
> >^
> > :8:34: note: expanded from here
> > ^
> > external/mesa/src/gallium/drivers/r600/r600_pipe_common.c:1287:10:
> > note: to match this '('
> > snprintf(rscreen->renderer_string, sizeof(rscreen->renderer_string),
> > ^
> > 1 error generated.
> >
> > Fixes: 05b114e ("simplify LLVM version string printing")
> > Signed-off-by: Mauro Rossi
> > ---
> > Android.mk | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/Android.mk b/Android.mk
> > index 09139e86d1..b835eb64e9 100644
> > --- a/Android.mk
> > +++ b/Android.mk
> > @@ -97,13 +97,13 @@ define mesa-build-with-llvm
> >$(if $(filter $(MESA_ANDROID_MAJOR_VERSION), 4 5), \
> > $(warning Unsupported LLVM version in Android
> > $(MESA_ANDROID_MAJOR_VERSION)),) \
> >$(if $(filter 6,$(MESA_ANDROID_MAJOR_VERSION)), \
> > -$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0307
> > -DMESA_LLVM_VERSION_STRING="3.7")) \
> > +$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0307
> > -DMESA_LLVM_VERSION_STRING=\"3.7\")) \
> >$(if $(filter 7,$(MESA_ANDROID_MAJOR_VERSION)), \
> > -$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0700
> > -DMESA_LLVM_VERSION_STRING="7.0")) \
> > +$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0700
> > -DMESA_LLVM_VERSION_STRING=\"7.0\")) \
> >$(if $(filter 8,$(MESA_ANDROID_MAJOR_VERSION)), \
> > -$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0700
> > -DMESA_LLVM_VERSION_STRING="7.0")) \
> > +$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0700
> > -DMESA_LLVM_VERSION_STRING=\"7.0\")) \
> >$(if $(filter 9,$(MESA_ANDROID_MAJOR_VERSION)), \
> > -$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0309
> > -DMESA_LLVM_VERSION_STRING="3.9")) \
> > +$(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0309
> > -DMESA_LLVM_VERSION_STRING=\"3.9\")) \
> >$(eval LOCAL_SHARED_LIBRARIES += libLLVM70)
> > endef
> >
> > --
> > 2.20.1
> >
> ___
> 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 00/40] intel: VK_KHR_shader_float16_int8 implementation
Quick status check. Mesa 19.1 is supposed to branch in two weeks. Are we about ready to land this? On Mon, Mar 25, 2019 at 11:13 AM Juan A. Suarez Romero wrote: > On Fri, 2019-03-22 at 17:53 +0100, Iago Toral wrote: > > Yes, I think those should be fine to land now, they are very few > > actually. Jason, any objections? > > > > Pushed: > - [PATCH v4 10/40] compiler/nir: add lowering option for 16-bit fmod > - [PATCH v4 11/40] compiler/nir: add lowering for 16-bit flrp > - [PATCH v4 12/40] compiler/nir: add lowering for 16-bit ldexp > > J.A. > > > Iago > > > > On Fri, 2019-03-22 at 17:26 +0100, Samuel Pitoiset wrote: > > > Can you eventually merge all NIR patches now? We should be able to > > > hook > > > up that extension for RADV quite soon. > > > > > > On 2/12/19 12:55 PM, Iago Toral Quiroga wrote: > > > > The changes in this version address review feedback to v3. The most > > > > significant > > > > changes include: > > > > > > > > 1. A more generic constant combining pass that can handle more > > > > constant types (not just F and HF) requested by Jason. > > > > > > > > 2. The addition of assembly validation for half-float restrictions, > > > > and also > > > > for mixed float mode, requested by Curro. It should be noted that > > > > this > > > > implementation of VK_KHR_shader_float16_int8 does not emit any > > > > mixed mode float > > > > instructions at this moment so I have not empirically validated the > > > > restictions > > > > implemented here. > > > > > > > > As always, a branch with these patches is available for testing in > > > > the > > > > itoral/VK_KHR_shader_float16_int8 branch of the Igalia Mesa > > > > repository at > > > > https://github.com/Igalia/mesa. > > > > > > > > Iago Toral Quiroga (40): > > > >compiler/nir: add an is_conversion field to nir_op_info > > > >intel/compiler: add a NIR pass to lower conversions > > > >intel/compiler: split float to 64-bit opcodes from int to 64-bit > > > >intel/compiler: handle b2i/b2f with other integer conversion > > > > opcodes > > > >intel/compiler: assert restrictions on conversions to half-float > > > >intel/compiler: lower some 16-bit float operations to 32-bit > > > >intel/compiler: handle extended math restrictions for half-float > > > >intel/compiler: implement 16-bit fsign > > > >intel/compiler: drop unnecessary temporary from 32-bit fsign > > > > implementation > > > >compiler/nir: add lowering option for 16-bit fmod > > > >compiler/nir: add lowering for 16-bit flrp > > > >compiler/nir: add lowering for 16-bit ldexp > > > >intel/compiler: add instruction setters for Src1Type and > > > > Src2Type. > > > >intel/compiler: add new half-float register type for 3-src > > > > instructions > > > >intel/compiler: don't compact 3-src instructions with Src1Type > > > > or > > > > Src2Type bits > > > >intel/compiler: allow half-float on 3-source instructions since > > > > gen8 > > > >intel/compiler: set correct precision fields for 3-source float > > > > instructions > > > >intel/compiler: fix ddx and ddy for 16-bit float > > > >intel/compiler: fix ddy for half-float in Broadwell > > > >intel/compiler: workaround for SIMD8 half-float MAD in gen8 > > > >intel/compiler: split is_partial_write() into two variants > > > >intel/compiler: activate 16-bit bit-size lowerings also for 8- > > > > bit > > > >intel/compiler: rework conversion opcodes > > > >intel/compiler: implement isign for int8 > > > >intel/compiler: ask for an integer type if requesting an 8-bit > > > > type > > > >intel/eu: force stride of 2 on NULL register for Byte > > > > instructions > > > >intel/compiler: generalize the combine constants pass > > > >intel/compiler: implement is_zero, is_one, is_negative_one for > > > > 8-bit/16-bit > > > >intel/compiler: add a brw_reg_type_is_integer helper > > > >intel/compiler: fix cmod propagation for non 32-bit types > > > >intel/compiler: remove inexact algebraic optimizations from the > > > > backend > > > >intel/compiler: skip MAD algebraic optimization for half-float > > > > or > > > > mixed mode > > > >intel/compiler: also set F execution type for mixed float mode > > > > in BDW > > > >intel/compiler: validate region restrictions for half-float > > > > conversions > > > >intel/compiler: validate conversions between 64-bit and 8-bit > > > > types > > > >intel/compiler: skip validating restrictions on operand types > > > > for > > > > mixed float > > > >intel/compiler: validate region restrictions for mixed float > > > > mode > > > >compiler/spirv: move the check for Int8 capability > > > >anv/pipeline: support Float16 and Int8 SPIR-V capabilities in > > > > gen8+ > > > >anv/device: expose VK_KHR_shader_float16_int8 in gen8+ > > > > > > > > src/compiler/nir/nir.h| 5 + > > > > src/compiler/nir/nir_op
Re: [Mesa-dev] Move adriconf to mesa repositories
Any other mesa developer interested in seeing this move forward? Kind Regards, Jean Hertel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110345] Unrecoverable GPU crash with DiRT 4
https://bugs.freedesktop.org/show_bug.cgi?id=110345 --- Comment #12 from Thomas Rohloff --- The 4.19 and 4.20 series won't boot for me cause of other bugs. I could try 4.18.12 but the FPS is very low with it (so it might take longer to trigger the bug) and I can't bisect (cause, as told above, 4.19/4.20 won't boot for me). -- 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
