As the functions operate on 16-byte blocks.
Fixes this Valgrind error:
Invalid read of size 4
at 0x5857568: swizzle_bpp1_align16 (pan_swizzle.c:85)
by 0x585780F: panfrost_texture_swizzle (pan_swizzle.c:171)
by 0x584F587: panfrost_tile_texture (pan_resource.c:489)
by 0x584F641: panfros
This matches the current state of things on both RK3288 and RK3399.
Hopefully, from now on we'll only remove stuff from this list.
Signed-off-by: Tomeu Vizoso
---
.../drivers/panfrost/ci/expected-failures.txt | 86 ++-
1 file changed, 7 insertions(+), 79 deletions(-)
diff --git
There doesn't seem to actually be any noticeably memory leaks on Weston
when running dEQP. We do seem to leak quiet a bit in the client, so we
still have to run the dEQP runner in batches.
This removes the risk of Weston not restarting properly and introducing
spurious failures.
Signed-off-by: To
These tests aren't giving reliable results. Mask them for now.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/gitlab-ci.yml | 53 +--
1 file changed, 48 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/ci/gitlab-ci.yml
b/src/gallium/drive
Valgrind was complaining of those.
NIR_PASS only sets progress to TRUE if there was progress.
nir_const_load_to_arr() only sets as many constants as components has
the instruction.
This was causing some dEQP tests to flip-flop, such as:
dEQP-GLES2.functional.fragment_ops.blend.equation_src_func
NIR_PASS will only set lower_flrp_progress if there's progress, and if
there isn't its value will be undefined.
Fixes this Valgrind error:
==6589== Conditional jump or move depends on uninitialised value(s)
==6589==at 0x55CA7E6: st_nir_opts (st_glsl_to_nir.cpp:347)
==6589==by 0x55CC1DD: s
Build artifacts for armhf and schedule them on a Veyron Chromebook with
RK3288.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/Dockerfile| 97 +---
src/gallium/drivers/panfrost/ci/arm.config| 45
.../drivers/panfrost/ci/deqp-runner.sh| 4
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/deqp-runner.sh | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/ci/deqp-runner.sh
b/src/gallium/drivers/panfrost/ci/deqp-runner.sh
index a2133b489d6a..992560f8cd40 100644
--
To improve robustness, check that we got the expected number of results.
Right now we hard-code the expected number of tests run, but with some
effort we may be able to infer it.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/gitlab-ci.yml | 1 +
1 file changed, 1 insertion(+)
Hi,
these patches take the current CI for Panfrost to a more useful
stage.
Results should be much more stable now and we also run the tests on a
machine with a different SoC and a different Midgard IP (RK3288 with
T760).
Some tests that are unstable have been added to a list of flip-flops to
be
These tests add too much time to the total run time, and some of them
even hang the DUTs, even if I haven't been able to reproduce it locally.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/deqp-runner.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/
Make sure we have only test case names in the list, excluding names of
test groups.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/deqp-runner.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/ci/deqp-runner.sh
b/src/gallium
Hi Emil,
The patches 1-7 are as well:
Reviewed-by: Mathias Fröhlich
plenty thanks and best
Mathias
On Monday, 6 May 2019 17:01:30 CEST Emil Velikov wrote:
> From: Emil Velikov
>
> By default, the user is likely to pick the first device so it should
> not be the least performant (aka softwa
On Wed, May 8, 2019 at 1:29 PM Matt Turner wrote:
> Whoops/Nice!
>
> Are there any shader-db changes as a result?
>
total instructions in shared programs: 15311103 -> 15311100 (<.01%)
instructions in affected programs: 1554 -> 1551 (-0.19%)
helped: 3
HURT: 0
total cycles in shared programs: 355
https://bugs.freedesktop.org/show_bug.cgi?id=78700
--- Comment #3 from Kenneth Graunke ---
Also the "unreleased game" was Witcher 2, but I think they reworked their
shader compilation considerably since the build I was using, so I doubt this
affects it still.
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=78700
Kenneth Graunke changed:
What|Removed |Added
Assignee|kenn...@whitecape.org |mesa-dev@lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=33797
Timothy Arceri changed:
What|Removed |Added
Component|Mesa core |Drivers/Gallium/llvmpipe
--
You are re
Hi Emil,
>This is the tricky part - wish I could find my notes they have better
>brain-dump.
>It's OK to have the library as both front (config tool) and backend
>(used by mesa) although:
> - special care on splitting and annotating the API is needed
> - handling this "extra" dependency would be f
Whoops/Nice!
Are there any shader-db changes as a result?
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
We only have one node per VGRF so this was adding way too much
interference. No idea how we didn't catch this before.
Fixes: 014edff0d20d "intel/fs: Add interference between SENDS sources"
---
src/intel/compiler/brw_fs_reg_allocate.cpp | 11 +++
1 file changed, 3 insertions(+), 8 deletio
I sent an MR for this and the other cases earlier this morning.
On May 8, 2019 9:20:16 AM Brian Paul wrote:
The 'progress' variable is initialized to false in other locations.
This fixes a new Coverity warning.
---
src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
1 file changed, 1 insertion(+)
The 'progress' variable is initialized to false in other locations.
This fixes a new Coverity warning.
---
src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
b/src/mesa/state_tracker/st_glsl_to_ni
Total membership 84; total votes 65; which makes for a 77.4% voter
turnout. Here are the results:
Board Members:
Name 1 2 3 4 5 6 Score
Daniel Vetter 27 10 14 6 2 6 296
Samuel Iglesias Gonsálvez 11 10 13 15 10 6 239
Lyude
https://bugs.freedesktop.org/show_bug.cgi?id=99781
--- Comment #20 from Uli Schlachter ---
Random guess for where the regression comes from:
X11DRV_expect_error() is used to say "I expect that the next request might
fail":
https://github.com/wine-mirror/wine/blob/6d801377055911d914226a3c6af8d863
https://bugs.freedesktop.org/show_bug.cgi?id=109599
--- Comment #28 from tempel.jul...@gmail.com ---
Would it be possible to ship this with one of the 19.1-rcs?
--
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=110636
--- Comment #6 from Samuel Pitoiset ---
a12681683a5de5b433ad99212e860c13a3478ebf is the first bad commit
commit a12681683a5de5b433ad99212e860c13a3478ebf
Author: Alexander Timofeev
Date: Fri Sep 21 10:31:22 2018 +
[AMDGPU] Diverge
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote:
>
> Due to the lack of
> controversy about the candidates [...]
Such a statement, when talking about election results, very much sounds
like "the election committees favourite candidates won anyway, so..."
p.
Luc Verhaegen.
__
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote:
>
> It should also be noted that even though our election process as
> outlined at https://www.x.org/wiki/BoardOfDirectors/Elections/ allows
> denying candidates any points our website didn't take this into account
> and forced vot
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote:
>
> In the interest of transparency I should mention that one person
> accidentally signed up twice and voted twice. Luckily this doesn't
> change the results of the election since there is more than a 6-point
> gap between 4th and
Reviewed-by: Bas Nieuwenhuizen for then,
because the Mesa code indeed prevents AMDGPU_CHUNK_ID_FENCE in
submissions.
On Wed, May 8, 2019 at 3:24 PM Christian König
wrote:
>
> Am 08.05.19 um 15:23 schrieb Liu, Leo:
> > On 5/8/19 9:19 AM, Koenig, Christian wrote:
> >> Am 08.05.19 um 15:14 schrieb
On Wed, May 8, 2019 at 10:06 AM Harry Wentland wrote:
>Trevor Woerner 4 14 10 10 8 19 199
>
I'd like to truly thank the other 3 people who chose me as their 1st pick,
and the 14 (:-O !!) who chose me as their first 2nd-place pick!
Considering I'm not an active contributor
Oh, I have a hunch what could be happening. I'll take a look before
merging :)
___
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=110645
Michel Dänzer changed:
What|Removed |Added
QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=110645
Bug ID: 110645
Summary: Blender EEVEE World Volumetric flickering
Product: Mesa
Version: 19.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severi
Am 08.05.19 um 15:23 schrieb Liu, Leo:
On 5/8/19 9:19 AM, Koenig, Christian wrote:
Am 08.05.19 um 15:14 schrieb Liu, Leo:
On 5/8/19 9:02 AM, Christian König wrote:
[CAUTION: External Email]
Am 08.05.19 um 14:56 schrieb Liu, Leo:
There is no user fence for JPEG, the bug triggering
kernel WARN
On 5/8/19 9:19 AM, Koenig, Christian wrote:
> Am 08.05.19 um 15:14 schrieb Liu, Leo:
>> On 5/8/19 9:02 AM, Christian König wrote:
>>> [CAUTION: External Email]
>>>
>>> Am 08.05.19 um 14:56 schrieb Liu, Leo:
There is no user fence for JPEG, the bug triggering
kernel WARN_ON(flags & AMDGPU
Am 08.05.19 um 15:14 schrieb Liu, Leo:
> On 5/8/19 9:02 AM, Christian König wrote:
>> [CAUTION: External Email]
>>
>> Am 08.05.19 um 14:56 schrieb Liu, Leo:
>>> There is no user fence for JPEG, the bug triggering
>>> kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)
>> Oh, we are probably going to ne
On 5/8/19 9:02 AM, Christian König wrote:
> [CAUTION: External Email]
>
> Am 08.05.19 um 14:56 schrieb Liu, Leo:
>> There is no user fence for JPEG, the bug triggering
>> kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)
>
> Oh, we are probably going to need to check for this in the kernel as
> wel
Am 08.05.19 um 14:56 schrieb Liu, Leo:
There is no user fence for JPEG, the bug triggering
kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)
Oh, we are probably going to need to check for this in the kernel as well.
Currently we only check for UVD and VCE there, do you want to take a
look Leo o
There is no user fence for JPEG, the bug triggering
kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)
Signed-off-by: Leo Liu
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/
https://bugs.freedesktop.org/show_bug.cgi?id=110636
--- Comment #4 from Samuel Pitoiset ---
This looks like a LLVM 8 regression to me.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mes
https://bugs.freedesktop.org/show_bug.cgi?id=110636
--- Comment #3 from Samuel Pitoiset ---
Can you try with LLVM 7 please?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev maili
Because the new raw/struct intrinsics are buggy with LLVM 8
(they weren't marked as source of divergence), we fallback to the
old instrinsics for atomic buffer operations only. This means we need
to apply the indexing workaround for GFX9. The load/store
operations still use the new LLVM 8 intrinsic
Err no, my mistake.
I will write a backport.
On 5/8/19 10:54 AM, Samuel Pitoiset wrote:
You mean 19.1?
On 5/7/19 8:29 PM, Dylan Baker wrote:
Hi Samuel,
This doesn't apply cleanly on 19.0, and I'm not sure how to resolve
the diff.
Could you provide a packport please?
Thanks,
Dylan
Quoting
You mean 19.1?
On 5/7/19 8:29 PM, Dylan Baker wrote:
Hi Samuel,
This doesn't apply cleanly on 19.0, and I'm not sure how to resolve the diff.
Could you provide a packport please?
Thanks,
Dylan
Quoting Samuel Pitoiset (2019-05-03 02:45:34)
Because the new raw/struct intrinsics are buggy with
LGTM.
Thanks for double checking Tim!
On 5/8/19 1:27 AM, Timothy Arceri wrote:
On 8/5/19 1:51 am, Samuel Pitoiset wrote:
What games are affected btw?
PERCENTAGE DELTAS Shaders SGPRs VGPRs SpillSGPR CodeSize
MaxWaves
batman-arkham-city 2581 . . . .
https://bugs.freedesktop.org/show_bug.cgi?id=110636
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #2 from Timothy A
https://bugs.freedesktop.org/show_bug.cgi?id=110636
Samuel Pitoiset changed:
What|Removed |Added
QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=107511
Eric Engestrom changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
49 matches
Mail list logo
