On Wed, Feb 20, 2019 at 4:29 AM Marek Olšák wrote:
> On Tue, Feb 19, 2019 at 7:57 PM Rob Clark wrote:
>
>> On Tue, Feb 19, 2019 at 6:49 PM Marek Olšák wrote:
>> >
>> > st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.
>> >
>> > nir_validate_shader 49%
>> >
>> >
Even in a very basic shader this reduces the time spent in
nir_copy_prop() by ~17%.
No shader-db changes for radeonsi NIR or i965.
---
src/compiler/nir/nir_opt_copy_propagate.c | 41 +++
1 file changed, 5 insertions(+), 36 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=104376
Anjala changed:
What|Removed |Added
CC||anjala.thulasi...@sjsu.edu
--
You are
Historically, Panfrost debugging entailed the use of the LD_PRELOADable
`panwrap` tool. This setup is a tad fragile; Panfrost can be traced
directly without the intermediate layer. pantrace implements the
quivalent functionality of panwrap into Panfrost proper, allowing dumps
to work regardless of
On Tue, Feb 19, 2019 at 7:57 PM Rob Clark wrote:
> On Tue, Feb 19, 2019 at 6:49 PM Marek Olšák wrote:
> >
> > st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.
> >
> > nir_validate_shader 49%
> >
> > nir_validate_shader is overused. It doesn't make sense even in debug
> builds.
>
This reduces the time spent in nir_opt_cse() by almost a half.
---
src/compiler/nir/nir_opt_cse.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/compiler/nir/nir_opt_cse.c b/src/compiler/nir/nir_opt_cse.c
index bf42a6a33dc..3c3617d852a 100644
---
I'll remove the env var.
Additionally, I'm amending this:
diff --git a/src/gallium/drivers/radeonsi/si_buffer.c
b/src/gallium/drivers/radeonsi/si_buffer.c
index 3f8db7cf4f0..4936eb5a5b1 100644
--- a/src/gallium/drivers/radeonsi/si_buffer.c
+++ b/src/gallium/drivers/radeonsi/si_buffer.c
@@
Yeah, u_threaded_context is broken.
Marek
On Thu, Feb 14, 2019 at 8:06 PM Dieter Nützel wrote:
> Am 12.02.2019 05:10, schrieb Dieter Nützel:
> > Am 12.02.2019 03:22, schrieb Dieter Nützel:
> >> Am 12.02.2019 00:40, schrieb Dieter Nützel:
> >>> Sorry that I step in so late, but the whole family
From: Dave Airlie
This was hardcoded to 32, use the physical bit size we setup.
Signed-off-by: Dave Airlie
---
src/compiler/spirv/vtn_cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index
Fixes: 4bb6c49375e "radv: Allow ETC2 on RAVEN and VEGA10 instead of all GFX9."
---
src/amd/vulkan/radv_device.c | 3 +--
src/amd/vulkan/radv_formats.c | 12 +---
src/amd/vulkan/radv_private.h | 1 +
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git
On Tue, Feb 19, 2019 at 6:49 PM Marek Olšák wrote:
>
> st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.
>
> nir_validate_shader 49%
>
> nir_validate_shader is overused. It doesn't make sense even in debug builds.
tbh, I like nir_validate enabled when I do piglit/deqp runs.. and I
Commit 9baacf3f is: "radeonsi: Refuse to accept code with unhandled
relocations".
This has broken ImageMagick for many people using AMD graphics cards.
See https://github.com/ImageMagick/ImageMagick/issues/1366
ImageMagick responded: "It looks like this error message is created by
the mesa
On Mon, Dec 10, 2018 at 12:42:40PM +0200, Eleni Maria Stea wrote:
> Calculating the scissor rectangle fields with the y flipped (0 on top)
> can generate negative values that will cause assertion failure later on
> as the scissor fields are all unsigned. We must clamp the bbox values
> again to
On 20/2/19 10:59 am, Timothy Arceri wrote:
On 20/2/19 10:49 am, Marek Olšák wrote:
st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.
nir_validate_shader 49%
nir_validate_shader is overused. It doesn't make sense even in debug
builds.
It's used to validate the IR between
On 20/2/19 10:49 am, Marek Olšák wrote:
st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.
nir_validate_shader 49%
nir_validate_shader is overused. It doesn't make sense even in debug builds.
It's used to validate the IR between optimisation/lowering passes. For
debug builds
https://bugs.freedesktop.org/show_bug.cgi?id=109615
--- Comment #4 from erhar...@mailbox.org ---
(In reply to Dylan Baker from comment #3)
> Do these tests pass on 18.3?
Mesa 18.3.x passes all tests on ppc64 BE. The failing tests in question are not
part of 18.3 as far as I've seen.
--
You are
st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.
nir_validate_shader 49%
nir_validate_shader is overused. It doesn't make sense even in debug builds.
Marek
On Wed, Feb 13, 2019 at 4:26 AM Connor Abbott wrote:
> Reviewed-by: Connor Abbott
>
> I'm a bit surprised it's that
Reviewed-by: Marek Olšák
Marek
On Mon, Feb 11, 2019 at 10:46 PM Timothy Arceri
wrote:
> ---
> src/gallium/drivers/radeonsi/si_shader_nir.c | 32 ++--
> 1 file changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
>
For the series:
Reviewed-by: Marek Olšák
Marek
On Mon, Feb 11, 2019 at 7:15 PM Timothy Arceri
wrote:
> shader-db results for VEGA64:
>
> Totals from affected shaders:
> SGPRS: 1976 -> 1976 (0.00 %)
> VGPRS: 1240 -> 1144 (-7.74 %)
> Spilled SGPRs: 145 -> 145 (0.00 %)
> Spilled VGPRs: 0 -> 0
Pushed, thanks!
Marek
On Mon, Feb 18, 2019 at 10:01 PM Mario Kleiner
wrote:
> This is the sddm login screen.
>
> Fixes: a9c36dbf9c56 ("drirc: Initial blacklist for adaptive sync")
> Signed-off-by: Mario Kleiner
> Cc: 19.0
> ---
> src/util/00-mesa-defaults.conf | 3 +++
> 1 file changed, 3
Series:
Reviewed-by: Timothy Arceri
We might want to tag this for stable too? NIR should work fine with this
game with the current stable releases.
On 20/2/19 9:31 am, Marek Olšák wrote:
From: Marek Olšák
I'm getting Civ6Sub instead of Civ6.
---
src/util/00-mesa-defaults.conf | 6
Hi List,
Hot off the press is mesa 19.0-rc5. Due to a number of still opened bugs in the
release tracker this will not be the final release, and I predict at least one
more release candidate before the final release happens.
Just an FYI, I will not be working Thursday or Friday this week, so if
https://bugs.freedesktop.org/show_bug.cgi?id=109615
--- Comment #3 from Dylan Baker ---
Do these tests pass on 18.3?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing
From: Marek Olšák
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104602
---
src/util/00-mesa-defaults.conf | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf
index cb0e6e659e2..81f23c97941 100644
---
From: Marek Olšák
I'm getting Civ6Sub instead of Civ6.
---
src/util/00-mesa-defaults.conf | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf
index 81f23c97941..8abc50c9f26 100644
--- a/src/util/00-mesa-defaults.conf
+++
From: Marek Olšák
---
src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 1 +
src/gallium/drivers/radeonsi/si_pipe.c | 3 ++-
src/util/xmlpool/t_options.h| 5 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git
On Tuesday, February 19, 2019 10:08:13 AM PST Ville Syrjälä wrote:
> On Tue, Feb 19, 2019 at 09:36:14AM -0800, Rodrigo Vivi wrote:
> > On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> > > Compared to linux and libdrm Mesa is missing a VLV and ICL id.
> > >
> > > 0x0f30
> > >
On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> Compared to linux and libdrm Mesa is missing a VLV and ICL id.
>
> 0x0f30
> ff049b6ce21d2814451afd4a116d001712e0116b
> drm/i915: bind driver to ValleyView chipsets
>
> 0x8A70
> d55cb4fa2cf0105bfb16b60a2846737b91fdc173
>
On Mon, 18 Feb 2019 at 19:06, Kyle Russell wrote:
>
> Thanks for this. Sorry I'm just now seeing it. I'll try this out on the
> armada+etnaviv configuration.
>
Considering the driver name (as returned by drmGetVersion()::name) is
"armada", all you need is:
-
Hi all,
The GitLab CI translated from Travis is really resource-hungry (see the
discussion DanielS started [1]).
Efforts are ongoing to make it nicer to its runners, but as
a (hopefully) temporary measure, the CI is now opt-in to avoid wasting
cycles if the dev pushing commits didn't want to run
On Tue, Feb 19, 2019 at 5:33 PM Emil Velikov
wrote:
> On Fri, 15 Feb 2019 at 21:39, Alyssa Rosenzweig
> wrote:
> >
> > > - about 1/5 of the patch seems to be white space changes
> >
> > ...Oops. Any tips for avoiding this type of diff churn in the future? I
> > suppose it's not inherently
https://bugs.freedesktop.org/show_bug.cgi?id=109443
Alex Granni changed:
What|Removed |Added
Attachment #143412|scons-bisect-finish.txt |scons-bisect.txt
filename|
https://bugs.freedesktop.org/show_bug.cgi?id=109443
--- Comment #1 from Alex Granni ---
Created attachment 143412
--> https://bugs.freedesktop.org/attachment.cgi?id=143412=edit
Scons source code bisect to determine when this became an issue.
--
You are receiving this mail because:
You are
On Fri, 15 Feb 2019 at 21:39, Alyssa Rosenzweig wrote:
>
> > - about 1/5 of the patch seems to be white space changes
>
> ...Oops. Any tips for avoiding this type of diff churn in the future? I
> suppose it's not inherently harmful, but maybe it could make merging
> more difficult than strictly
On Tuesday, 2019-02-19 15:30:39 +, Emil Velikov wrote:
> From: Emil Velikov
>
> Some platforms lack O_CLOEXEC. The loader_open_device() handles those
> appropriately, so use the helper.
>
> Signed-off-by: Emil Velikov
I'll review 1 & 3 later, but 2 & 4 are:
Reviewed-by: Eric Engestrom
>
On Tue, 19 Feb 2019 at 03:32, Vinson Lee wrote:
>
> CXXLDgallium_dri.la
> duplicate symbol _compute_shader_video_buffer in:
>
> ../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor.o)
>
>
On Tuesday, 2019-02-19 14:08:08 +, Emil Velikov wrote:
> From: Emil Velikov
>
> VGEM and kms_swrast were introduced to work with one another.
>
> All we do is CPU rendering to dumb buffers. There is no reason to carve
> out GPU memory, increasing the memory pressure on a device that could
>
https://bugs.freedesktop.org/show_bug.cgi?id=109190
Gert Wollny changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
From: Emil Velikov
Some platforms lack O_CLOEXEC. The loader_open_device() handles those
appropriately, so use the helper.
Signed-off-by: Emil Velikov
---
src/loader/loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/loader/loader.c b/src/loader/loader.c
index
From: Emil Velikov
It's the current maximum supported by the kernel. Stay consistent with
the rest of Mesa and use the same number.
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/platform_android.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Emil Velikov
Reoder the function a bit to make the code-flow more obvious and short.
Signed-off-by: Emil Velikov
---
git show -w produces a nicer diff
---
src/loader/loader.c | 42 --
1 file changed, 16 insertions(+), 26 deletions(-)
diff --git
From: Emil Velikov
Currently that's the hard-coded maximum in the kernel, even though the
libdrm API allows for more. Latter is done with extendability in mind.
Allocate 64 pointers^Wdevices on stack for now. Making for shorter and
ever-so-slightly faster code.
Signed-off-by: Emil Velikov
---
https://bugs.freedesktop.org/show_bug.cgi?id=109659
Dylan Baker changed:
What|Removed |Added
CC||baker.dyla...@gmail.com,
Hi,
The following MR fixes an issue we've discovered while working on NIR
support for Gallium Nine. When there are NIR uniform variables whose
location is explicitly set, radeonsi did not take that into account
when calculating const_file_max, resulting in rendering glitches in
some games. This
Hi,
I've polished the MR according to feedback, and also added some
additional fixes. Also removed the WIP tag. With these changes, most
nine games we tested can work flawlessly on radeonsi with NIR.
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/225
Code reviews are very welcome.
https://bugs.freedesktop.org/show_bug.cgi?id=109645
Fabio Pedretti changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--
You are receiving this
Rb
On February 19, 2019 06:06:41 Samuel Iglesias Gonsálvez
wrote:
The cacheline size was a requirement for using the BLT engine, which
we don't use anymore except for a few things on old HW, so we drop it.
Fixes CTS's CL#3500 test:
From: Emil Velikov
Make the code a bit easier to read.
As a bonus point this makes it obvious that we forgot to call
_eglAddDevice() for the device - do so.
v2:
- s/dpy/disp/ (Eric)
- free(driver_name) on dri2_load_driver_swrast() failure (Eric)
Signed-off-by: Emil Velikov
Reviewed-by:
From: Emil Velikov
VGEM and kms_swrast were introduced to work with one another.
All we do is CPU rendering to dumb buffers. There is no reason to carve
out GPU memory, increasing the memory pressure on a device that could
make a better use of it.
Note:
- The original code did not work out of
From: Emil Velikov
This provides for a more comprehensive iteration and slightly more
straight-forward codebase.
v2:
- s/dpy/disp/
- keep original 64 devices (Eric)
Signed-off-by: Emil Velikov
Reviewed-by: Eric Engestrom
Reviewed-by: Mathias Fröhlich
---
https://bugs.freedesktop.org/show_bug.cgi?id=109646
--- Comment #6 from jam...@amd.com ---
Sorry, https://www.youtube.com/watch?v=LXb3EKWsInQ is the clip. James
--
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=109646
--- Comment #5 from jam...@amd.com ---
Thanks so much! By the way, can you provide me the source to reproduce the
jagginess issue at my side?
James
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the
On Mon, 18 Feb 2019 at 16:50, Eric Engestrom wrote:
>
> On Tuesday, 2019-02-05 15:31:07 +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > This provides for a more comprehensive iteration and a more
> > straight-forward codebase, while minimising the platform specifics.
> >
> >
https://bugs.freedesktop.org/show_bug.cgi?id=109645
Eric Engestrom changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=109647
Eric Engestrom changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #3 from Eric
On Wed, 6 Feb 2019 at 12:38, Eric Engestrom wrote:
>
> On Tuesday, 2019-02-05 15:19:46 +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > The difference between the tree functions is the list of mandatory
> > driver extensions. Pass that as an argument to the common helper.
> >
> >
On Fri, 15 Feb 2019 at 22:12, Alyssa Rosenzweig wrote:
>
> > Am I reading this correctly, that now we free a slab [for a tiled
> > texture] before allocating new one? The commit message seems rather
> > cryptic.
>
> Yeah, it's a super minor fix. Rather than allocating a new slab for the
> texture
On Mon, 18 Feb 2019 at 16:07, Eric Engestrom wrote:
>
> On Tuesday, 2019-02-05 15:31:06 +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Make the code a bit easier to read.
> >
> > As a bonus point this makes it obvious that we forgot to call
> > _eglAddDevice() for the device - do so.
On Fri, 15 Feb 2019 at 21:42, Alyssa Rosenzweig wrote:
>
> > Nit: staying consistent with "foo != NULL" vs "foo" checks helps a
> > lot.
>
> Which form is preferred?
>
I think that varies across parts of mesa. I'd pick one and use it
through panfrost.
> > free(NULL); is perfectly valid.
>
> Huh,
On Fri, 15 Feb 2019 at 21:33, Alyssa Rosenzweig wrote:
>
> > Feel free to reuse:
> > meson: panfrost: add missing libdrm dependency
>
> Hmm?
Was a minor wording suggestion. Personally the "Fix build" phase is quite meh.
Doesn't matter though - fix has landed.
-Emil
The cacheline size was a requirement for using the BLT engine, which
we don't use anymore except for a few things on old HW, so we drop it.
Fixes CTS's CL#3500 test:
dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.single_layer.r8g8b8_unorm
Signed-off-by: Samuel Iglesias Gonsálvez
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/isl/isl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index 5c34efb9a13..7fb469687fa 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1519,6 +1519,9 @@ isl_surf_init_s(const
Hi Eric,
Thanks for having a look!
On Mon, 18 Feb 2019 at 17:05, Eric Engestrom wrote:
>
> On Tuesday, 2019-02-05 15:31:08 +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > VGEM and kms_swrast were introduced to work with one another.
> >
> > All we do is CPU rendering to dumb buffers.
https://bugs.freedesktop.org/show_bug.cgi?id=109645
--- Comment #4 from Eric Engestrom ---
Instead of testing a copy/pasted patch, you can test the branch in this MR:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/270
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=109647
--- Comment #2 from Eric Engestrom ---
Actually not really a duplicate; although the issue was shown by the same
commit (f1374805a86d0), this bug report is for the bug that was there in the
autotools config and the other is for the bug that was
https://bugs.freedesktop.org/show_bug.cgi?id=109645
--- Comment #3 from Eric Engestrom ---
Sorry, I broke two libdrm things within a few days and I got confused between
the issues. Looking at this one now, but at first glance it looks like
src/gallium/drivers/tegra/meson.build is just missing
https://bugs.freedesktop.org/show_bug.cgi?id=109645
--- Comment #2 from Fabio Pedretti ---
@Eric Engestrom: any news on this build issue?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
We are now lowering isign in NIR so this patch is no longer needed.
Iago
On Tue, 2019-02-12 at 12:55 +0100, Iago Toral Quiroga wrote:
> Reviewed-by: Jason Ekstrand
> ---
> src/intel/compiler/brw_fs_nir.cpp | 25 +
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
>
68 matches
Mail list logo
