From: Dave Airlie
This fixes piglit clearbuffer-mixed-format
---
src/gallium/drivers/softpipe/sp_clear.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/softpipe/sp_clear.c
b/src/gallium/drivers/softpipe/sp_clear.c
index ba04fd0aa87..d2626a24333 100644
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_SC
On Tue, Mar 26, 2019 at 11:00 AM Alyssa Rosenzweig wrote:
>
> > Seems Panfrost implementation does not take depth uniforms?
>
> That's a /* to-do */ for me; it should definitely be implemented before
> adding to common code.
>
> > we both use the viewport scale/transform vector as the uniform
> >
On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote:
> iris currently uses two distinct GEM contexts to have distinct logical
> HW contexts for the compute and render pipelines. However, using two
> distinct GEM contexts implies that they are distinct timelines, yet as
> they are a single G
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/helpers.h | 2 ++
src/gallium/drivers/panfrost/midgard/midgard.h | 4
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 1 +
3 files changed, 7 insertions(+)
diff --git a/src/gallium/drivers/pan
Fixes
dEQP-GLES2.functional.shaders.conversions.scalar_to_scalar.int_to_bool_fragment
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compi
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/helpers.h | 1 +
.../drivers/panfrost/midgard/midgard_compile.c | 14 +++---
.../panfrost/midgard/midgard_nir_algebraic.py | 3 ---
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/
In fact, the native "fpow" instruction only does half of it; more work
is needed for the actual instruction. For now, just lower.
Fixes: 1ea42894c ("panfrost/midgard: Implement fpow")
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/helpers.h | 2 +-
src/gallium
On 03/25/2019 06:47 PM, Dave Airlie wrote:
From: Dave Airlie
This gets the basevertex from the draw depending on whether
it's an indexed or non-indexed draw.
We still fail a transform feedback test for vertex id, as
the vertex id actually an index id, and isn't getting translated
properly to a
> + [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 (o
> Seems Panfrost implementation does not take depth uniforms?
That's a /* to-do */ for me; it should definitely be implemented before
adding to common code.
> we both use the viewport scale/transform vector as the uniform
> in this lower pass.
I think that's reasonable. I don't like wasting a ha
On Fri, Mar 22, 2019 at 11:25 PM Alyssa Rosenzweig wrote:
>
> > +
> > +static bool gpir_lower_viewport_transform(gpir_compiler *comp)
> > +{
> > + gpir_node *rcpw = NULL;
> > +
> > + /* rcpw = 1 / w */
> > + list_for_each_entry(gpir_block, block, &comp->block_list, list) {
> > + list_fo
From: Dave Airlie
This gets the basevertex from the draw depending on whether
it's an indexed or non-indexed draw.
We still fail a transform feedback test for vertex id, as
the vertex id actually an index id, and isn't getting translated
properly to a vertex id, suggestions on how/where to fix t
https://bugs.freedesktop.org/show_bug.cgi?id=110240
--- Comment #2 from james.dut...@gmail.com ---
the git checkout and cherry-pick are from the mesa git.
My graphics card is a AMD Vega 56.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=110240
james.dut...@gmail.com changed:
What|Removed |Added
CC||james.dut...@gmail.com
--- Comm
> Can you reuse u_vbuf_get_minmax_index()?
From a preliminary read, it didn't look like that did caching?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=110240
Bug ID: 110240
Summary: Assassins Creed Odyssey crashes with nir errors
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Alyssa Rosenzweig writes:
> This code is probably a wholesale duplication of the corresponding code
> in mesa/src/vbo/vbo_minmax_indices.c; we should investigate reusing
> that.
Can you reuse u_vbuf_get_minmax_index()?
signature.asc
Description: PGP signature
__
On 26/3/19 3:43 am, Emil Velikov wrote:
Hi Timothy,
On Fri, 1 Mar 2019 at 10:36, Timothy Arceri wrote:
This fixes a segfault when we try to access the array using a
-1 when the array wasn't allocated in the first place.
Before 7536af670b75 we would just access a pre-allocated array
that was
Build mesa 10540 completed
Commit 8ed583fe52 by Jason Ekstrand on 2/27/2019 9:59 PM:
spirv: Handle the NonUniformEXT decoration
Configure your notification preferences
___
mesa-dev mailing list
mesa-dev@lis
https://bugs.freedesktop.org/show_bug.cgi?id=109939
--- Comment #22 from Dylan Baker ---
There is a meson bug here, I've proposed a patch here:
https://github.com/mesonbuild/meson/pull/5143
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
Build mesa 10538 failed
Commit 3bd5457641 by Jason Ekstrand on 2/27/2019 8:36 PM:
nir: Add a lowering pass for non-uniform resource access\n\nReviewed-by: Bas Nieuwenhuizen
Configure your notification preferences
https://bugs.freedesktop.org/show_bug.cgi?id=109939
--- Comment #21 from mikhail.v.gavri...@gmail.com ---
Thanks, Alex.
I tested new mesa Fedora build (mesa-19.0.0-2.fc31)
I noted that "-Db_ndebug=true" also helps another games rinning by DXVK (steam
play):
- Dishonored series becomes playeble, ye
On Monday, March 25, 2019 4:46 AM, Felix Schwarz
wrote:
> Am 25.03.19 um 00:06 schrieb zegen...@protonmail.com:
>
> > To quote Uli Schlacher, who understands this stuff more than I do:
>
> "Schlachter"
Appears I can't spell if my life depended on it. Fixed.
___
From 05468bf625317e76adb43aa8ef20375cc179dd12 Mon Sep 17 00:00:00 2001
From: Hal Gentz
Date: Sun, 24 Mar 2019 16:52:39 -0600
Subject: [PATCH] Fixes assertion fail on startup in
`glXCreateContextAttribsARB`.
To quote Uli Schlachter, who understands this stuff more than I do:
> The function __g
Just figured that's broken for older LLVM, I will fix.
On 3/25/19 6:17 PM, Samuel Pitoiset wrote:
27670 shaders in 14347 tests
Totals:
SGPRS: 1231173 -> 1236757 (0.45 %)
VGPRS: 866056 -> 867488 (0.17 %)
Spilled SGPRs: 24201 -> 24169 (-0.13 %)
Code Size: 46134836 -> 46115944 (-0.04 %) bytes
Max W
27670 shaders in 14347 tests
Totals:
SGPRS: 1231173 -> 1236757 (0.45 %)
VGPRS: 866056 -> 867488 (0.17 %)
Spilled SGPRs: 24201 -> 24169 (-0.13 %)
Code Size: 46134836 -> 46115944 (-0.04 %) bytes
Max Waves: 232287 -> 232070 (-0.09 %)
Totals from affected shaders:
SGPRS: 247624 -> 253208 (2.26 %)
VGPR
Hi Timothy,
On Fri, 1 Mar 2019 at 10:36, Timothy Arceri wrote:
>
> This fixes a segfault when we try to access the array using a
> -1 when the array wasn't allocated in the first place.
>
> Before 7536af670b75 we would just access a pre-allocated array
> that was also load/stored to/from the shad
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
-
https://bugs.freedesktop.org/show_bug.cgi?id=109939
--- Comment #20 from Mike Lothian ---
Seems to be setting it with CFLAGS, though I guess that might need to change
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=109939
--- Comment #19 from Alex Smith ---
You have -Db_ndebug=true which I think is what Fedora is missing - their build
definitely does not have that as I see code in the binaries that is only
compiled when NDEBUG is not set.
However you don't get a
https://bugs.freedesktop.org/show_bug.cgi?id=109939
--- Comment #18 from Mike Lothian ---
Will --buildtype=plane cause any issues? It's the default here on Gentoo
meson --buildtype plain --libdir lib64 --localstatedir /var/lib --prefix /usr
--sysconfdir /etc --wrap-mode nodownload
-Dplatforms=x1
https://bugs.freedesktop.org/show_bug.cgi?id=109939
--- Comment #17 from Alex Smith ---
Reported: https://bugzilla.redhat.com/show_bug.cgi?id=1692426
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=110141
--- Comment #1 from Parker Reed ---
wlroots from sway is also affected.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev maili
On 03/23/2019 10:49 AM, Jose Fonseca wrote:
Looks good to me.
Reviewed-by: Jose Fonseca
Though I wonder if this could happen also when not destroying the
current context. (Ie, if we need zoombie textures too?)
If we're not destroying the thread's current context, this patch
temporarily bin
RADV doesn't have to lower 16-bits FMA.
Original patch from Rhys Perry.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_shader.c | 4 +++-
src/broadcom/compiler/nir_to_vir.c | 4 +++-
src/compiler/nir/nir.h | 4
The lowering needs to be disabled for sufficient precision to pass
deqp-vk's 16-bit fma test on radv.
Original patch from Rhys.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_shader.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_s
On 2019-03-21 8:10 p.m., Liu, Leo wrote:
> On 2019-03-20 1:56 p.m., Michel Dänzer wrote:
>> On 2019-03-20 4:42 p.m., Liu, Leo wrote:
>>> The wait here is unnecessary since we got a pool of back buffers,
>>> and the wait for swap buffer will happen before the present pixmap,
>>> at the same time the
On 25/03/2019 14:26, Brian Paul wrote:
> On 03/23/2019 10:49 AM, Jose Fonseca wrote:
>> Looks good to me.
>>
>> Reviewed-by: Jose Fonseca
>>
>> Though I wonder if this could happen also when not destroying the
>> current context. (Ie, if we need zoombie textures too?)
>
> If we're not destroying
https://bugs.freedesktop.org/show_bug.cgi?id=109939
--- Comment #16 from Alex Smith ---
I think I have an idea what's happening here. Pipeline compilation will be a
lot slower using debug builds of Mesa.
Mikhail, it looks from your backtraces like you're using a debug build you've
done yourself?
On 03/24/2019 11:14 PM, Dave Airlie wrote:
From: Dave Airlie
If the geom shader emits a point size we failed to find it here,
use the correct API to look it up.
Fixes:
tests/spec/glsl-1.50/execution/geometry/point-size-out.shader_test
---
src/gallium/auxiliary/draw/draw_pipe_wide_point.c | 9
To all X.Org Foundation Members:
We've had some problems with the previous ballot (i.e. I didn't create it
properly) that opened last Thursday. Apologies to the two people that already
voted.
We've re-created the ballot (v2). It will open on March 27 at 2am UTC and close
on April 11 at 2am UTC
On 03/24/2019 09:41 PM, Dave Airlie wrote:
From: Dave Airlie
With indirect rendering it's fine to set the instance count
parameter to 0, and expect the rendering to be ignored.
Fixes assert in KHR-GLES31.core.compute_shader.pipeline-gen-draw-commands
on softpipe
v2: return earlier before chan
https://bugs.freedesktop.org/show_bug.cgi?id=110230
--- Comment #8 from Laurent ---
Ok but there isn't any source documentation generated in the mesa folder when I
run doxygen command is it normal ? It seems it only point to links for reading
the documentation.
--
You are receiving this mail be
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/
Am 25.03.19 um 00:06 schrieb zegen...@protonmail.com:
> To quote Uli Schlacher, who understands this stuff more than I do:
"Schlachter"
> https://bugs.freedesktop.org/show_bug.cgi?id=99781
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99781
Felix
__
We want to opt out of the automatic GPU recovery and replay performed by
the kernel of a guilty context after a GPU reset as our incremental
batch construction very often implies that subsequent batches are a GPU
reset are incomplete and will trigger fresh GPU hangs. As we are aware
of how we need
For use in GPU recovery and pipeline construction.
---
include/drm-uapi/i915_drm.h | 389 +---
1 file changed, 317 insertions(+), 72 deletions(-)
diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
index d2792ab3640..59baacd265d 100644
--- a/incl
iris currently uses two distinct GEM contexts to have distinct logical
HW contexts for the compute and render pipelines. However, using two
distinct GEM contexts implies that they are distinct timelines, yet as
they are a single GL context that implies they belong to a single
timeline from the clie
https://bugs.freedesktop.org/show_bug.cgi?id=110230
Eric Engestrom changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
From: Sagar Ghuge
Print quad value same as unsigned quad so that we can distinguish in
between quater control disassembled values for e.g 1/2/3[Q] and
immediate quad value for e.g 1Q. This allows round-tripping through the
assembler/disassembler.
Signed-off-by: Sagar Ghuge
---
src/intel/compil
https://bugs.freedesktop.org/show_bug.cgi?id=106151
Samuel Pitoiset changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 106151, which changed state.
Bug 106151 Summary: [amdgpu][vulkan] GPU hang (Vega 56) while running game
(Rise of the Tomb Raider)
https://bugs.freedesktop.org/show_bug.cgi?id=106151
What|Removed
On Fri, 2019-03-22 at 10:06 -0500, Jason Ekstrand wrote:
> I'm confused. Don't we always have a NULL render target at location
> 0? Is the problem really that we need the NULL render target or is
> it that we can't throw away the alpha component of the RT write in
> the shader?
It is the latter.
On Fri, 2019-03-22 at 17:21 +0100, Samuel Pitoiset wrote:
> Does this fix anything known?
>
I am writing CTS tests for VK_EXT_host_query_reset extension and I
found this bug while testing them on RADV.
> Does that rule also apply for CmdCopyQueryPoolResults()? If so, we
> might
> need to fix it
55 matches
Mail list logo
