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
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:
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
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
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
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
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
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
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://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
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]
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
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
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
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
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
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 &
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
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
>
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
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
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.___
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
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
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
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
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|---
On Wednesday, 2019-05-08 12:38:51 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> ---
> src/gallium/targets/dri/meson.build | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/targets/dri/meson.build
> b/src/gallium/targets/dri/meson.build
> index
https://bugs.freedesktop.org/show_bug.cgi?id=110345
--- Comment #17 from Thomas Rohloff ---
(In reply to Samuel Pitoiset from comment #16)
> Are you still able to reproduce with latest mesa/llvm git?
Yes.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=110640
Bug ID: 110640
Summary: vlPostProc question
Product: Mesa
Version: 18.0
Hardware: ARM
OS: All
Status: NEW
Severity: normal
Priority: medium
On Tue, 7 May 2019 at 23:47, Alyssa Rosenzweig wrote:
>
> Tentative R-b, but I'm baffled what the flip-flops would be about. Could
> you link the list of failures introduced (we're maybe relying on buggy
> behaviour anyway)?
I was testing with
41 matches
Mail list logo
