https://bugs.freedesktop.org/show_bug.cgi?id=110884
--- Comment #3 from Thiago Macieira ---
This patch appears to fix the problem:
>From 49607f0524539cb836065b626bb3d3946061c486 Mon Sep 17 00:00:00 2001
From: Thiago Macieira
Date: Mon, 10 Jun 2019 19:13:12 -0700
Subject: [PATCH] Attempt at fixi
On Mon, Jun 10, 2019 at 10:00:01PM -0400, Jonathan Marek wrote:
> On 6/10/19 10:00 PM, Brian Masney wrote:
> > On Mon, Jun 10, 2019 at 09:53:25PM -0400, Jonathan Marek wrote:
> > > > > > This error doesn't happen on X11 using the mesa master branch.
> > > > > > Instead,
> > > > > > I get the follo
On Mon, Jun 10, 2019 at 6:52 PM Brian Masney wrote:
>
> Hi Rob,
>
> On Mon, Jun 10, 2019 at 05:10:45PM -0700, Rob Clark wrote:
> > On Mon, Jun 10, 2019 at 3:54 PM Brian Masney wrote:
> > >
> > > On Mon, Jun 10, 2019 at 06:58:30AM -0700, Rob Clark wrote:
> > > > On Mon, Jun 10, 2019 at 6:53 AM Rob
On 6/10/19 10:00 PM, Brian Masney wrote:
On Mon, Jun 10, 2019 at 09:53:25PM -0400, Jonathan Marek wrote:
This error doesn't happen on X11 using the mesa master branch. Instead,
I get the following error on that branch:
../src/gallium/drivers/freedreno/freedreno_batch.c:424:fd_batch_add_dep:
As
On Mon, Jun 10, 2019 at 09:53:25PM -0400, Jonathan Marek wrote:
> > > > This error doesn't happen on X11 using the mesa master branch. Instead,
> > > > I get the following error on that branch:
> > > >
> > > > ../src/gallium/drivers/freedreno/freedreno_batch.c:424:fd_batch_add_dep:
> > > > Assert
On 6/10/19 9:52 PM, Brian Masney wrote:
Hi Rob,
On Mon, Jun 10, 2019 at 05:10:45PM -0700, Rob Clark wrote:
On Mon, Jun 10, 2019 at 3:54 PM Brian Masney wrote:
On Mon, Jun 10, 2019 at 06:58:30AM -0700, Rob Clark wrote:
On Mon, Jun 10, 2019 at 6:53 AM Rob Clark wrote:
On Sat, Jun 8, 2019 a
https://bugs.freedesktop.org/show_bug.cgi?id=110884
--- Comment #2 from Thiago Macieira ---
Disassembly:
0x724cc389 <+489>: xor%edi,%edi
0x724cc38b <+491>: movq $0x0,0x10(%r12)
0x724cc394 <+500>: callq 0x724a5b00
That's a constant null pointer
Hi Rob,
On Mon, Jun 10, 2019 at 05:10:45PM -0700, Rob Clark wrote:
> On Mon, Jun 10, 2019 at 3:54 PM Brian Masney wrote:
> >
> > On Mon, Jun 10, 2019 at 06:58:30AM -0700, Rob Clark wrote:
> > > On Mon, Jun 10, 2019 at 6:53 AM Rob Clark wrote:
> > > >
> > > > On Sat, Jun 8, 2019 at 6:08 PM Brian
On Mon, Jun 10, 2019 at 3:54 PM Brian Masney wrote:
>
> On Mon, Jun 10, 2019 at 06:58:30AM -0700, Rob Clark wrote:
> > On Mon, Jun 10, 2019 at 6:53 AM Rob Clark wrote:
> > >
> > > On Sat, Jun 8, 2019 at 6:08 PM Brian Masney wrote:
> > > >
> > > > Hi,
> > > >
> > > > I'm trying to get the GPU wor
https://bugs.freedesktop.org/show_bug.cgi?id=110884
Caio Marcelo de Oliveira Filho changed:
What|Removed |Added
CC||caio.olive...@intel.com
https://bugs.freedesktop.org/show_bug.cgi?id=108647
magist3r changed:
What|Removed |Added
CC||magis...@gmail.com
--
You are receiving thi
https://bugs.freedesktop.org/show_bug.cgi?id=110884
--- Comment #1 from Thiago Macieira ---
As the backtrace shows, scene=0x0, which shouldn't happen. The scene pointer is
obtained in thread_function(), in:
lp_rast_begin( rast,
lp_scene_dequeue( rast->full_scene
r-b
On Mon, Jun 10, 2019 at 5:42 PM Samuel Pitoiset
wrote:
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta_resolve_fs.c | 41 +++
> 1 file changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta_resolve_fs.c
> b/src/amd/v
r-b
On Mon, Jun 10, 2019 at 5:42 PM Samuel Pitoiset
wrote:
>
> When decompressing resolve source images, we should rely on the
> framebuffer layer count instead of resolving all images layers.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta_resolve.c | 12 +---
> 1 f
r-b
On Mon, Jun 10, 2019 at 5:42 PM Samuel Pitoiset
wrote:
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta_resolve.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/amd/vulkan/radv_meta_resolve.c
> b/src/amd/vulkan/radv_meta_resolve.c
> index 817182e17d9..0a7af
r-b
On Mon, Jun 10, 2019 at 5:42 PM Samuel Pitoiset
wrote:
>
> When resolving inside a subpass, we should rely on the framebuffer
> layer count instead of resolving all images layers. This should
> improve performance of layered resolves a bit.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd
r-b
On Mon, Jun 10, 2019 at 5:42 PM Samuel Pitoiset
wrote:
>
> Use an explicit pipeline barrier for doing layout transitions
> instead of duplicating some code.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta_resolve.c | 38 +++---
> 1 file changed, 1
https://bugs.freedesktop.org/show_bug.cgi?id=110884
Marcos Simental changed:
What|Removed |Added
CC||mrkzm...@gmail.com
--
You are receiv
https://bugs.freedesktop.org/show_bug.cgi?id=110884
Bug ID: 110884
Summary: can't start GDM when building mesa master branch with
LTO
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
This is clear for texelFetch, hence the confusion with Bifrost's filter
field, but it's much more general in reality.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/disassemble.c | 5 +
src/gallium/drivers/panfrost/midgard/midgard.h | 4 +---
src/galliu
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/disassemble.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index 4ef82140b7f..bada8974396 100644
--- a/src
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c| 19 +++
.../drivers/panfrost/midgard/midgard.h| 2 +-
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/dri
Its encoding differs slightly from the LOD used in normal texture calls.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/disassemble.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard.h | 6 --
src/gallium/drivers/panfrost/midgard/midgard_ops.c | 3 ++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard.h
b/src/gallium/drivers/panf
This allows us to show a call to textureLod in a reasonable way.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/disassemble.c | 11 ---
src/gallium/drivers/panfrost/midgard/midgard.h | 5 +++--
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/disassemble.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index 6be262f7ba0..c12b2f24e70
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c| 32 +++
.../drivers/panfrost/midgard/midgard.h| 5 ++-
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/d
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/disassemble.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index fc5b4ebfec6..3c59119e523 100
With an extra flag, we're able to do a perspective division "for free"
while loading a varying.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c | 13 ++---
src/gallium/drivers/panfrost/midgard/midgard.h | 16 +++-
2 files changed, 25 in
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/disassemble.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index 10729ca122b..5f553ba27a0 1
It's not at all clear why this work for texelFetch but not texture.
Maybe the top bits are dual-purpose on other texturing ops...?
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c| 20 +++
.../drivers/panfrost/midgard/midgard.h| 16 +
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c| 21 ++-
.../drivers/panfrost/midgard/midgard.h| 13 ++--
2 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/disassemble.c | 8 ++--
src/gallium/drivers/panfrost/midgard/midgard.h | 8 +++-
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/
We decode most of the GLES3 texture ops here, prompted by the need to
support textureLod on GLES2 and also because texture ops are massive but
this tames them *considerably*. Except for the last patch, that's some
weird end-of-day stuff.
Alyssa Rosenzweig (18):
panfrost/midgard: Expand texture t
...on the load/store unit, not the ALUs. Looks goofy but hey.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard.h | 5 +
src/gallium/drivers/panfrost/midgard/midgard_ops.c | 1 +
2 files changed, 6 insertions(+)
diff --git a/src/gallium/drivers/panfrost/m
Turns out this modifier field is the same as Utgard-PP.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/disassemble.c | 6 --
src/gallium/drivers/panfrost/midgard/midgard.h | 5 +++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/gallium/dri
This patch identifies the two modes of offsets in a texture instruction
(immediate and register, disambiguated by the bit-once-known-as
"has_offset") and implements disassembly for both.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c| 68 +++
This eliminates some unknowns, clarifies 3D textures, and will maybe
help with array/shadow textures?
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c | 7 ++-
src/gallium/drivers/panfrost/midgard/midgard.h | 8 ++--
.../drivers/panfrost/midgard/m
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/amd/vulkan/radv_meta_resolve.c
b/src/amd/vulkan/radv_meta_resolve.c
index 817182e17d9..0a7affb2f11 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/ra
When resolving inside a subpass, we should rely on the framebuffer
layer count instead of resolving all images layers. This should
improve performance of layered resolves a bit.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve_cs.c | 12
1 file changed, 8 insertio
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve_fs.c | 41 +++
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_resolve_fs.c
b/src/amd/vulkan/radv_meta_resolve_fs.c
index 9f20f6753e2..d059760edf1 100644
--- a/src
When decompressing resolve source images, we should rely on the
framebuffer layer count instead of resolving all images layers.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/amd/vulkan/ra
Use an explicit pipeline barrier for doing layout transitions
instead of duplicating some code.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_reso
This seems to be a performance win, but more rigorous testing is
necessary to figure out the exact circumstances when this is good/bad.
Incidentally, this fixes non-aligned ZS.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_afbc.c | 4 +++-
src/gallium/drivers/panfros
We might render to it.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index bce3426fd67..0c45e258b96
On Sun, Jun 9, 2019 at 7:43 AM Jonathan Marek wrote:
>
> On 6/9/19 8:41 AM, Brian Masney wrote:
> > On Sat, Jun 08, 2019 at 10:58:11PM -0400, Jonathan Marek wrote:
> >> Hi,
> >>
> >> It's possible 19.1 has another issue, I only tested the master branch with
> >> my fix. I would suggest trying 19.0
On Mon, Jun 10, 2019 at 6:53 AM Rob Clark wrote:
>
> On Sat, Jun 8, 2019 at 6:08 PM Brian Masney wrote:
> >
> > Hi,
> >
> > I'm trying to get the GPU working using the Freedreno driver (A330) on
> > the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree patches
> > related to the GPU [1
On Sat, Jun 8, 2019 at 3:36 PM Alex Smith wrote:
>
> On Mon, 3 Jun 2019 at 13:27, Koenig, Christian
> wrote:
>>
>> Am 03.06.19 um 14:21 schrieb Alex Smith:
>>
>> On Mon, 3 Jun 2019 at 11:57, Koenig, Christian
>> wrote:
>>>
>>> Am 02.06.19 um 12:32 schrieb Alex Smith:
>>> > Put the uncached GTT
On Sat, Jun 8, 2019 at 6:08 PM Brian Masney wrote:
>
> Hi,
>
> I'm trying to get the GPU working using the Freedreno driver (A330) on
> the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree patches
> related to the GPU [1] and mesa 19.1.0-rc5 on postmarketOS. When I run
> glxgears, I se
https://bugs.freedesktop.org/show_bug.cgi?id=110625
Bug 110625 depends on bug 110302, which changed state.
Bug 110302 Summary: [bisected][regression] piglit egl-create-pbuffer-surface
and egl-gl-colorspace regressions
https://bugs.freedesktop.org/show_bug.cgi?id=110302
What|Remove
From: Ville Syrjälä
Modern DXVK requires event support [1], but looks like it only
uses vkCmdSetEvent() + vkGetEventStatus(). So we can just
borrow the relevant code from gen8, leaving CmdWaitEvents still
unimplemented.
[1]
https://github.com/doitsujin/dxvk/commit/8c3900c533d83d12c970b905183d17
On Monday, 10 June 2019 12:11:40 CEST Mathias Fröhlich wrote:
> Hi Emil,
>
> On Friday, 7 June 2019 15:43:48 CEST Emil Velikov wrote:
> > On Thu, 6 Jun 2019 at 12:10, wrote:
> > >
> > > From: Mathias Fröhlich
> > >
> > > Do not offer a hardware drm backed egl device if no render node
> > > is av
This looks good;
Reviewed-by: Tapani Pälli
Note that there is ongoing work to get rid of the whole libexpat
dependency for Android. But until that happens, let's do this.
On 4/24/19 4:44 PM, Mauro Rossi wrote:
Fixes building errors due to missing libmesa_util generated files include
and lib
https://bugs.freedesktop.org/show_bug.cgi?id=110872
--- Comment #2 from Steinar H. Gunderson ---
Well, at the very least, the re-linking should check the return value of the
compilation. That could fail for pretty much any reason, no?
--
You are receiving this mail because:
You are the assignee
Hi Emil,
On Friday, 7 June 2019 15:43:48 CEST Emil Velikov wrote:
> On Thu, 6 Jun 2019 at 12:10, wrote:
> >
> > From: Mathias Fröhlich
> >
> > Do not offer a hardware drm backed egl device if no render node
> > is available.
> As far as I can see current implementation does _not_ add the DRM
> d
https://bugs.freedesktop.org/show_bug.cgi?id=110872
--- Comment #1 from Timothy Arceri ---
(In reply to Steinar H. Gunderson from comment #0)
> It's unclear from the spec what should happen, but given that 1 and 2 were
> compiled in the context of A, I would say that linking them in B should be
>
https://bugs.freedesktop.org/show_bug.cgi?id=110872
Bug ID: 110872
Summary: Shader cache gives spurious linking errors on sharing
between contexts of different versions
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
On Sat, 8 Jun 2019 at 02:15, Alyssa Rosenzweig
wrote:
>
> Now that we support custom strides on mipmapped lines textures
> (theoretically, at least), extend the stride check to support mipmaps.
> Fixes incorrect strides of linear windows in Weston.
>
> Signed-off-by: Alyssa Rosenzweig
Looks good
58 matches
Mail list logo
