The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain
This confuses me. When is this ever a problem? I suspect that we're doing
something wing with alignments now.
--Jason
On February 18, 2019 09:02:39 Lionel Landwerlin
wrote:
On 15/02/2019 14:43, Samuel Iglesias Gonsálvez wrote:
Signed-off-by: Samuel Iglesias Gonsálvez
Hey Samuel,
CXXLDgallium_dri.la
duplicate symbol _compute_shader_video_buffer in:
../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor.o)
../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor_cs.o)
duplicate symbol
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 insertions(+)
diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf
Hi,
On Mon, 18 Feb 2019 at 18:58, Eric Engestrom wrote:
> On Monday, 2019-02-18 17:31:41 +, Daniel Stone wrote:
> > Two hours of end-to-end pipeline time is also obviously far too long.
> > Amongst other things, it practically precludes pre-merge CI: by the
> > time your build has finished,
Thanks for this. Sorry I'm just now seeing it. I'll try this out on the
armada+etnaviv configuration.
On Thu, Jan 24, 2019 at 5:35 PM Rob Herring wrote:
> This series aims to make supporting new platforms containing
> renderonly GPUs easier with less copy-n-paste. This hasn't been a big
>
On Monday, 2019-02-18 17:31:41 +, Daniel Stone wrote:
> Hi all,
> A few people have noted that Mesa's GitLab CI is just too slow, and
> not usable in day-to-day development, which is a massive shame.
Agreed :/
>
> I looked into it a bit this morning, and also discussed it with Emil,
>
Mesa 18.3.4 is now available.
In this release we have:
A fix in the XvMC state-tracker, which was causing some video attributes to
not take affect. On the video front the VAAPI state tracker has seen
improvements with VP9 streams while the amdgpu driver advertises all available
profiles.
On
On Mon, Feb 18, 2019 at 9:32 AM Daniel Stone wrote:
>
> Hi all,
> A few people have noted that Mesa's GitLab CI is just too slow, and
> not usable in day-to-day development, which is a massive shame.
>
> I looked into it a bit this morning, and also discussed it with Emil,
> though nothing in
https://bugs.freedesktop.org/show_bug.cgi?id=109443
Alex Granni changed:
What|Removed |Added
Attachment #143208|Mesa3D MSVC build fails |Mesa3D MSVC build fails
Hi all,
A few people have noted that Mesa's GitLab CI is just too slow, and
not usable in day-to-day development, which is a massive shame.
I looked into it a bit this morning, and also discussed it with Emil,
though nothing in this is speaking for him.
Taking one of the last runs as
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. There is no reason to carve
> out GPU memory, increasing the memory pressure on a device that could
>
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.
>
> Signed-off-by: Emil Velikov
> ---
>
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.
>
> Signed-off-by: Emil Velikov
> ---
>
On 18/02/2019 15:08, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-02-18 15:06:15)
On 15/02/2019 14:43, Samuel Iglesias Gonsálvez wrote:
There are formats which bpp are not aligned to a power-of-two and
that can cause problems in the checks we do.
The cacheline size was a requirement
Quoting Lionel Landwerlin (2019-02-18 15:06:15)
> On 15/02/2019 14:43, Samuel Iglesias Gonsálvez wrote:
> > There are formats which bpp are not aligned to a power-of-two and
> > that can cause problems in the checks we do.
> >
> > The cacheline size was a requirement for using the BLT engine,
On 15/02/2019 14:43, Samuel Iglesias Gonsálvez wrote:
There are formats which bpp are not aligned to a power-of-two and
that can cause problems in the checks we do.
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
On 15/02/2019 14:43, Samuel Iglesias Gonsálvez wrote:
Signed-off-by: Samuel Iglesias Gonsálvez
Hey Samuel,
Thanks for this change. Would you mind changing the align_u32 in the
if() branch too?
It won't fix anything but that's just to be consistent.
With that :
Reviewed-by: Lionel
The CTS is buggy because the input_output_float_64_to_16 tests are run
even though they shouldn't be run because they try to use a
unadvertised (and unimplemented) optional feature.
Some of them crash for unrelated reasons though: load_tess_varyings()
from ac_nir_to_llvm.c doesn't handle 64-bit
I don't see a 16-bit version of tbuffer.store in IntrinsicsAMDGPU.td
and simply changing "llvm.amdgcn.tbuffer.store.i32" to
"llvm.amdgcn.tbuffer.store.i16" and removing the zext doesn't seem to
work.
On Mon, 18 Feb 2019 at 08:55, Samuel Pitoiset wrote:
>
> Does this fix anything know? There is a
To make wedging even more likely, we use a new "no recovery" context
parameter that tells the kernel to not even attempt to replay any
batches in flight against the default context image, as experience shows
the HW is not always robust enough to cope with the conflicting state.
This allows us to
XXX Not in drm-next XXX
Pull i915_drm.h to include
commit ba4fda620a5f7db521aa9e0262cf49854c1b1d9c (HEAD -> drm-intel-next-queued,
drm-intel/drm-intel-next-queued)
Author: Chris Wilson
Date: Mon Feb 18 10:58:21 2019 +
drm/i915: Optionally disable automatic recovery after a GPU reset
If we hang the GPU and end up banning our context, we will no longer be
able to submit and abort with an error (exit(1) no less). As we submit
minimal incremental batches that rely on the logical context state of
previous batches, we can not rely on the kernel's recovery mechanism
which tries to
https://bugs.freedesktop.org/show_bug.cgi?id=108949
Connor Abbott changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=108949
--- Comment #3 from Samuel Pitoiset ---
Can this be closed now?
--
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
https://bugs.freedesktop.org/show_bug.cgi?id=109597
Samuel Pitoiset changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109647
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=109645
Michel Dänzer changed:
What|Removed |Added
CC||v...@freedesktop.org
--- Comment #1
Reviewed-by: Bas Nieuwenhuizen
for both.
On Thu, Feb 14, 2019 at 2:39 PM Samuel Pitoiset
wrote:
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/common/ac_llvm_build.c | 41 ++
> 1 file changed, 27 insertions(+), 14 deletions(-)
>
> diff --git
Reviewed-by: Bas Nieuwenhuizen
On Fri, Feb 15, 2019 at 6:00 PM Samuel Pitoiset
wrote:
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109597
> Cc: 18.3 19.0
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_pipeline.c | 8
> 1 file changed, 8 insertions(+)
>
>
FWIW, the is_partial_write() patch is not strictly required, so I think
it would be okay to not merge it until someone has a bit more time to
think about it if we are not sure that this is the right way to go. We
would lose copy propagation for SIMD8 dispatches, which is not great,
but it is
On Sat, 2019-02-16 at 09:42 -0600, Jason Ekstrand wrote:
> On Tue, Feb 12, 2019 at 5:56 AM Iago Toral Quiroga > wrote:
> > ---
> >
> > src/intel/compiler/brw_eu_validate.c| 10 +-
> >
> > src/intel/compiler/test_eu_validate.cpp | 46
> > +
> >
> > 2 files
On 2/13/19 10:29 PM, Eduardo Lima Mitev wrote:
> These intrinsics have the offset in dwords already computed in the last
> source, so the change here is basically using that instead of emitting
> the ir3_SHR to divide the byte-offset by 4.
>
> The improvement in shader stats is dramatic, of up to
https://bugs.freedesktop.org/show_bug.cgi?id=109659
Bug ID: 109659
Summary: Missing OpenGL symbols in OSMesa Gallium when building
with meson
Product: Mesa
Version: 18.3
Hardware: x86-64 (AMD64)
OS: Linux
On Sat, 2019-02-16 at 09:40 -0600, Jason Ekstrand wrote:
> On Tue, Feb 12, 2019 at 11:53 AM Iago Toral Quiroga <
> ito...@igalia.com> wrote:
> > ---
> >
> > src/intel/compiler/brw_eu_validate.c| 64 -
> >
> > src/intel/compiler/test_eu_validate.cpp | 122
> >
Reviewed-by: Samuel Pitoiset
On 2/16/19 1:22 AM, Rhys Perry wrote:
Signed-off-by: Rhys Perry
---
src/amd/vulkan/radv_shader.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 1dcb0606246..adba730ad8b 100644
---
Patches 14-17 are:
Reviewed-by: Samuel Pitoiset
On 2/16/19 1:22 AM, Rhys Perry wrote:
Signed-off-by: Rhys Perry
---
src/amd/common/ac_nir_to_llvm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
Reviewed-by: Samuel Pitoiset
On 2/16/19 1:22 AM, Rhys Perry wrote:
v2: don't use ac_get_zero(), ac_get_one() and ac_int_of_size()
Signed-off-by: Rhys Perry
---
src/amd/common/ac_llvm_build.c | 27 ---
1 file changed, 4 insertions(+), 23 deletions(-)
diff --git
We usually use 'name' instead of 'intr'.
With that renamed, patch is:
Reviewed-by: Samuel Pitoiset
On 2/16/19 1:21 AM, Rhys Perry wrote:
v2: don't use ac_get_zerof() and ac_get_onef()
Signed-off-by: Rhys Perry
---
src/amd/common/ac_llvm_build.c | 13 +
1 file changed, 9
Reviewed-by: Samuel Pitoiset
On 2/16/19 1:21 AM, Rhys Perry wrote:
Signed-off-by: Rhys Perry
---
src/amd/common/ac_nir_to_llvm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 691d444db05..741059b5f1a 100644
---
Reviewed-by: Samuel Pitoiset
On 2/16/19 1:21 AM, Rhys Perry wrote:
Signed-off-by: Rhys Perry
---
src/amd/common/ac_nir_to_llvm.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index b260142c177..f39232b91a1 100644
Does this fix anything know? There is a 16-bit version of tbuffer.store,
maybe we should use it?
On 2/16/19 1:21 AM, Rhys Perry wrote:
Signed-off-by: Rhys Perry
---
src/amd/common/ac_nir_to_llvm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c
On 2/16/19 1:21 AM, Rhys Perry wrote:
This series add support for:
- VK_KHR_shader_float16_int8
- VK_AMD_gpu_shader_half_float
- VK_AMD_gpu_shader_int16
- VK_KHR_8bit_storage
on VI+. Half floats are disabled on LLVM 7 because of a bug causing large
memory usage and long (or unbounded)
On Sat, 2019-02-16 at 09:29 -0600, Jason Ekstrand wrote:
> On Tue, Feb 12, 2019 at 5:57 AM Iago Toral Quiroga > wrote:
> > At the very least we need it to handle HF too, since we are doing
> >
> > constant propagation for MAD and LRP, which relies on this pass
> >
> > to promote the immediates
Patch 1-2 are:
Reviewed-by: Samuel Pitoiset
On 2/16/19 1:21 AM, Rhys Perry wrote:
So that the signature is correct and consistent, the inputs to a export
intrinsic should always be 32-bit floats.
This and the previous commit fixes a large amount crashes from
On Sat, 2019-02-16 at 09:02 -0600, Jason Ekstrand wrote:
> On Tue, Feb 12, 2019 at 5:56 AM Iago Toral Quiroga > wrote:
> > Empirical testing shows that gen8 has a bug where MAD instructions
> > with
> >
> > a half-float source starting at a non-zero offset fail to execute
> >
> > properly.
> >
46 matches
Mail list logo
