[Mesa-dev] [Bug 109548] Seeing visual corruption in totem after installing amdgpu 18.50 in Ubuntu 18.04.1

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109548

--- Comment #7 from Timothy Pearson  ---
Do you have a link to the list post?  So far I've identified Chromium and
MythTV both as being affected on Polaris GPUs, Chromium may be using gstreamer
but I'm not sure about MythTV.  Would like to follow the upstream discussion
and see what the resolution is.

Thanks!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109548] Seeing visual corruption in totem after installing amdgpu 18.50 in Ubuntu 18.04.1

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109548

--- Comment #8 from Michel Dänzer  ---
(In reply to Timothy Pearson from comment #7)
> Do you have a link to the list post?

https://lists.freedesktop.org/archives/gstreamer-devel/2019-February/070435.html
=> https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/136

> So far I've identified Chromium and MythTV both as being affected on Polaris
> GPUs, Chromium may be using gstreamer but I'm not sure about MythTV.

There are likely similar bugs in other code-bases. It's a bit of a trap in the
GLX specification.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [AppVeyor] mesa staging/19.1 #11950 completed

[AppVeyor]

Build mesa 11950 completed



Commit f17ff71f49 by Dave Airlie on 7/18/2019 12:44 AM:

radv: fix crash in shader tracing.\n\nEnabling tracing, and then having a vmfault, can leads to a segfault\nbefore we print out the traces, as if a meta shader is executing\nand we don't have the NIR for it.\n\nJust pass the stage and give back a default.\n\nFixes: 9b9ccee4d64 ("radv: take LDS into account for compute shader occupancy stats")\nReviewed-by: Samuel Pitoiset \n(cherry picked from commit 2ac2b987801c60e5e141354ee1759b63ca85bf4c)


Configure your notification preferences

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [AppVeyor] mesa master #11902 failed

[Michel Dänzer]

On 2019-07-19 1:47 a.m., Rob Clark wrote:
> On Thu, Jul 18, 2019 at 4:34 PM Roland Scheidegger  wrote:
>>
>> Am 16.07.19 um 20:55 schrieb AppVeyor:
>>>
>>>   Build mesa 11902 failed
>>> Commit 856e84083e by Rob Clark  on
>>> 7/15/2019 4:05 PM:
>>> mesa/st: add sampler uniforms\n\nAdd sampler uniforms for the UV
>>> plane(s), so driver can count the\nuniforms and get the correct sampler
>>> count.\n\nFixes lowered YUV on a6xx which actually wants to know # of
>>> samplers.\n\nSigned-off-by: Rob Clark
>>> \nReviewed-by: Kristian H. Kristensen
>>> \nReviewed-by: Eric Anholt 
>>>
>>
>> Apparently this commit broke windows builds...
>>
> 
> Hmm, really no asprintf() on windows?
> 
> Is there some place we can add an asprintf() in mesa for windows builds?

Looks like the CI pipeline scons-win64 job needs to be tightened up:

https://gitlab.freedesktop.org/mesa/mesa/-/jobs/425745

Maybe just make implicit function declarations errors in general? AFAICT
that's already the case with meson.

(At least this would need to be fixed first with scons:

src/gallium/winsys/svga/drm/vmw_screen.c: In function 'vmw_dev_compare':
src/gallium/winsys/svga/drm/vmw_screen.c:48:12: warning: implicit declaration 
of function 'major' [-Wimplicit-function-declaration]
return (major(*(dev_t *)key1) == major(*(dev_t *)key2) &&
^
src/gallium/winsys/svga/drm/vmw_screen.c:49:12: warning: implicit declaration 
of function 'minor'; did you mean 'mknod'? [-Wimplicit-function-declaration]
minor(*(dev_t *)key1) == minor(*(dev_t *)key2)) ? 0 : 1;
^
mknod
)


-- 
Earthling Michel Dänzer   |  https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [AppVeyor] mesa master #11951 failed

[AppVeyor]

Build mesa 11951 failed


Commit 32b72cbca5 by Yevhenii Kolesnikov on 7/18/2019 2:38 PM:

main: Destroy static hash table\n\nformat_array_format_table has a static lifetime - it will be destroyed\nby an atexit handler.\n\nSigned-off-by: Yevhenii Kolesnikov \nReviewed-by: Eric Engestrom \nReviewed-by: Eric Anholt 


Configure your notification preferences

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nvc0/ir: Fix assert accessing null pointer

[Mark Menzynski]

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111007
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=67
Signed-off-by: Mark Menzynski 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index aca3b0afb1e..1f702a987d8 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -51,12 +51,12 @@ NVC0LegalizeSSA::handleDIV(Instruction *i)
// Generate movs to the input regs for the call we want to generate
for (int s = 0; i->srcExists(s); ++s) {
   Instruction *ld = i->getSrc(s)->getInsn();
-  assert(ld->getSrc(0) != NULL);
   // check if we are moving an immediate, propagate it in that case
   if (!ld || ld->fixed || (ld->op != OP_LOAD && ld->op != OP_MOV) ||
 !(ld->src(0).getFile() == FILE_IMMEDIATE))
  bld.mkMovToReg(s, i->getSrc(s));
   else {
+ assert(ld->getSrc(0) != NULL);
  bld.mkMovToReg(s, ld->getSrc(0));
  // Clear the src, to make code elimination possible here before we
  // delete the instruction i later
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nvc0/ir: Fix assert accessing null pointer

[Eric Engestrom]

On Friday, 2019-07-19 13:56:30 +0200, Mark Menzynski wrote:
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111007
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=67

`Fixes:` is used to indicate the commit that introduced the code being
fixed, such as:
  Fixes: 1c4e6d7ca83578caf521 ("nvc0/ir: propagate immediates to CALL input 
MOVs")
This tag is used by our tools to backport fixes to the relevant stable
releases.

Bugzilla entries are referenced using the `Bugzilla:` prefix.

> Signed-off-by: Mark Menzynski 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> index aca3b0afb1e..1f702a987d8 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> @@ -51,12 +51,12 @@ NVC0LegalizeSSA::handleDIV(Instruction *i)
> // Generate movs to the input regs for the call we want to generate
> for (int s = 0; i->srcExists(s); ++s) {
>Instruction *ld = i->getSrc(s)->getInsn();
> -  assert(ld->getSrc(0) != NULL);

I'll admit I don't know anything about this code, but it looks like
this might be a better fix?
   assert(ld == NULL || ld->getSrc(0) != NULL)

I cc'ed Tobias who wrote this code as he'll probably know best.

>// check if we are moving an immediate, propagate it in that case
>if (!ld || ld->fixed || (ld->op != OP_LOAD && ld->op != OP_MOV) ||
>  !(ld->src(0).getFile() == FILE_IMMEDIATE))
>   bld.mkMovToReg(s, i->getSrc(s));
>else {
> + assert(ld->getSrc(0) != NULL);
>   bld.mkMovToReg(s, ld->getSrc(0));
>   // Clear the src, to make code elimination possible here before we
>   // delete the instruction i later
> -- 
> 2.21.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111169] libmesa_util.a(u_queue.c.o): undefined reference to symbol 'pthread_setname_np@@GLIBC_2.12'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=69

--- Comment #2 from Eric Engestrom  ---
What linker are you using to always see these undefined references to unused
symbols?

This MR should fix it:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1391

I'll make a proper fix replacing `libmesa_util` with `idep_mesautil` which
should avoid this ever happening again.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nvc0/ir: Fix assert accessing null pointer

[Ilia Mirkin]

The patch is correct as-is.

Reviewed-by: Ilia Mirkin 

On Fri, Jul 19, 2019 at 9:39 AM Eric Engestrom  wrote:
>
> On Friday, 2019-07-19 13:56:30 +0200, Mark Menzynski wrote:
> > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111007
> > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=67
>
> `Fixes:` is used to indicate the commit that introduced the code being
> fixed, such as:
>   Fixes: 1c4e6d7ca83578caf521 ("nvc0/ir: propagate immediates to CALL input 
> MOVs")
> This tag is used by our tools to backport fixes to the relevant stable
> releases.
>
> Bugzilla entries are referenced using the `Bugzilla:` prefix.
>
> > Signed-off-by: Mark Menzynski 
> > ---
> >  src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
> > b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> > index aca3b0afb1e..1f702a987d8 100644
> > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> > @@ -51,12 +51,12 @@ NVC0LegalizeSSA::handleDIV(Instruction *i)
> > // Generate movs to the input regs for the call we want to generate
> > for (int s = 0; i->srcExists(s); ++s) {
> >Instruction *ld = i->getSrc(s)->getInsn();
> > -  assert(ld->getSrc(0) != NULL);
>
> I'll admit I don't know anything about this code, but it looks like
> this might be a better fix?
>assert(ld == NULL || ld->getSrc(0) != NULL)
>
> I cc'ed Tobias who wrote this code as he'll probably know best.
>
> >// check if we are moving an immediate, propagate it in that case
> >if (!ld || ld->fixed || (ld->op != OP_LOAD && ld->op != OP_MOV) ||
> >  !(ld->src(0).getFile() == FILE_IMMEDIATE))
> >   bld.mkMovToReg(s, i->getSrc(s));
> >else {
> > + assert(ld->getSrc(0) != NULL);
> >   bld.mkMovToReg(s, ld->getSrc(0));
> >   // Clear the src, to make code elimination possible here before we
> >   // delete the instruction i later
> > --
> > 2.21.0
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gm107/ir: Add stg, ldg instructions and function for checking offset length

[Mark Menzynski]

Nvidia actively uses these instructions, maybe they are better in
something.
Long offset checking function was made because these functions only have 24 bit
address offsets.

Signed-off-by: Mark Menzynski 
---
 .../nouveau/codegen/nv50_ir_emit_gm107.cpp| 36 +++
 1 file changed, 36 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 6eefe8f0025..c01a3017ba9 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -87,6 +87,7 @@ private:
inline void emitADDR(int, int, int, int, const ValueRef &);
inline void emitCBUF(int, int, int, int, int, const ValueRef &);
inline bool longIMMD(const ValueRef &);
+   inline bool longOffset(const ValueRef &);
inline void emitIMMD(int, int, const ValueRef &);
 
void emitCond3(int, CondCode);
@@ -174,9 +175,11 @@ private:
void emitLDC();
void emitLDL();
void emitLDS();
+   void emitLDG();
void emitLD();
void emitSTL();
void emitSTS();
+   void emitSTG();
void emitST();
void emitALD();
void emitAST();
@@ -333,6 +336,17 @@ CodeEmitterGM107::longIMMD(const ValueRef &ref)
return false;
 }
 
+bool
+CodeEmitterGM107::longOffset(const ValueRef &ref)
+{
+   // TODO: check for other files as well?
+   if (ref.getFile() != FILE_MEMORY_GLOBAL)
+  return false;
+
+   int32_t offset = ref.get()->reg.data.offset;
+   return offset >  0x7f || offset < -0x80;
+}
+
 void
 CodeEmitterGM107::emitIMMD(int pos, int len, const ValueRef &ref)
 {
@@ -2414,6 +2428,17 @@ CodeEmitterGM107::emitLDS()
emitGPR  (0x00, insn->def(0));
 }
 
+void
+CodeEmitterGM107::emitLDG()
+{
+   emitInsn (0xeed0);
+   emitLDSTs(0x30, insn->dType);
+   emitLDSTc(0x2e);
+   emitField(0x2d, 1, insn->src(0).getIndirect(0)->getSize() == 8);
+   emitADDR (0x08, 0x14, 24, 0, insn->src(0));
+   emitGPR  (0x00, insn->def(0));
+}
+
 void
 CodeEmitterGM107::emitLD()
 {
@@ -2445,6 +2470,17 @@ CodeEmitterGM107::emitSTS()
emitGPR  (0x00, insn->src(1));
 }
 
+void
+CodeEmitterGM107::emitSTG()
+{
+   emitInsn (0xeed8);
+   emitLDSTs(0x30, insn->dType);
+   emitLDSTc(0x2e);
+   emitField(0x2d, 1, insn->src(0).getIndirect(0)->getSize() == 8);
+   emitADDR (0x08, 0x14, 24, 0, insn->src(0));
+   emitGPR  (0x00, insn->src(1));
+}
+
 void
 CodeEmitterGM107::emitST()
 {
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gm107/ir: Add stg, ldg instructions and function for checking offset length

[Ilia Mirkin]

On Fri, Jul 19, 2019 at 10:57 AM Mark Menzynski  wrote:
>
> Nvidia actively uses these instructions, maybe they are better in
> something.
> Long offset checking function was made because these functions only have 24 
> bit
> address offsets.
>
> Signed-off-by: Mark Menzynski 
> ---
>  .../nouveau/codegen/nv50_ir_emit_gm107.cpp| 36 +++
>  1 file changed, 36 insertions(+)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> index 6eefe8f0025..c01a3017ba9 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> @@ -87,6 +87,7 @@ private:
> inline void emitADDR(int, int, int, int, const ValueRef &);
> inline void emitCBUF(int, int, int, int, int, const ValueRef &);
> inline bool longIMMD(const ValueRef &);
> +   inline bool longOffset(const ValueRef &);
> inline void emitIMMD(int, int, const ValueRef &);
>
> void emitCond3(int, CondCode);
> @@ -174,9 +175,11 @@ private:
> void emitLDC();
> void emitLDL();
> void emitLDS();
> +   void emitLDG();
> void emitLD();
> void emitSTL();
> void emitSTS();
> +   void emitSTG();
> void emitST();
> void emitALD();
> void emitAST();
> @@ -333,6 +336,17 @@ CodeEmitterGM107::longIMMD(const ValueRef &ref)
> return false;
>  }
>
> +bool
> +CodeEmitterGM107::longOffset(const ValueRef &ref)
> +{
> +   // TODO: check for other files as well?
> +   if (ref.getFile() != FILE_MEMORY_GLOBAL)
> +  return false;

I haven't seen the uses (best to send stuff like this as a series),
but you're saying that if it's not global memory, then it's not a long
offset? I suspect in the caller it should be more like

assert(file == global || !long offset) or something.

> +
> +   int32_t offset = ref.get()->reg.data.offset;
> +   return offset >  0x7f || offset < -0x80;

You have two spaces after the >. Remove one of them.

> +}
> +
>  void
>  CodeEmitterGM107::emitIMMD(int pos, int len, const ValueRef &ref)
>  {
> @@ -2414,6 +2428,17 @@ CodeEmitterGM107::emitLDS()
> emitGPR  (0x00, insn->def(0));
>  }
>
> +void
> +CodeEmitterGM107::emitLDG()
> +{
> +   emitInsn (0xeed0);
> +   emitLDSTs(0x30, insn->dType);
> +   emitLDSTc(0x2e);
> +   emitField(0x2d, 1, insn->src(0).getIndirect(0)->getSize() == 8);

I didn't look, but we don't do something a bit more subtle on the
other ones, like checking if there's an indirect access in the first
place? With g[], it almost exclusively will be, but still...

> +   emitADDR (0x08, 0x14, 24, 0, insn->src(0));
> +   emitGPR  (0x00, insn->def(0));
> +}
> +
>  void
>  CodeEmitterGM107::emitLD()
>  {
> @@ -2445,6 +2470,17 @@ CodeEmitterGM107::emitSTS()
> emitGPR  (0x00, insn->src(1));
>  }
>
> +void
> +CodeEmitterGM107::emitSTG()
> +{
> +   emitInsn (0xeed8);
> +   emitLDSTs(0x30, insn->dType);
> +   emitLDSTc(0x2e);
> +   emitField(0x2d, 1, insn->src(0).getIndirect(0)->getSize() == 8);
> +   emitADDR (0x08, 0x14, 24, 0, insn->src(0));
> +   emitGPR  (0x00, insn->src(1));
> +}
> +
>  void
>  CodeEmitterGM107::emitST()
>  {
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111125] [RADV] Graphic glitches regression in The Witcher 3 with DXVK on AMD Radeon HD7850

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=25

--- Comment #3 from Rhys Perry  ---
ACO builds of Mesa hanging with LLVM-git should be fixed with latest versions.

Are you sure you were using ACO? Seems the Radeon HD7850 is a GCN 1 card, which
is currently unsupported and should fall back to using LLVM.

You can find out if ACO is used by looking at the DXVK HUD. It should show "AMD
RADV/ACO ... (LLVM ...)" instead of "AMD RADV ... (LLVM ...)" if ACO is used.

-- 
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
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gm107/ir: Add stg, ldg instructions and function for checking offset length

[Mark Menzynski]

On Fri, Jul 19, 2019 at 5:04 PM Ilia Mirkin  wrote:
>
> On Fri, Jul 19, 2019 at 10:57 AM Mark Menzynski  wrote:
> >
> > Nvidia actively uses these instructions, maybe they are better in
> > something.
> > Long offset checking function was made because these functions only have 24 
> > bit
> > address offsets.
> >
> > Signed-off-by: Mark Menzynski 
> > ---
> >  .../nouveau/codegen/nv50_ir_emit_gm107.cpp| 36 +++
> >  1 file changed, 36 insertions(+)
> >
> > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp 
> > b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> > index 6eefe8f0025..c01a3017ba9 100644
> > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> > @@ -87,6 +87,7 @@ private:
> > inline void emitADDR(int, int, int, int, const ValueRef &);
> > inline void emitCBUF(int, int, int, int, int, const ValueRef &);
> > inline bool longIMMD(const ValueRef &);
> > +   inline bool longOffset(const ValueRef &);
> > inline void emitIMMD(int, int, const ValueRef &);
> >
> > void emitCond3(int, CondCode);
> > @@ -174,9 +175,11 @@ private:
> > void emitLDC();
> > void emitLDL();
> > void emitLDS();
> > +   void emitLDG();
> > void emitLD();
> > void emitSTL();
> > void emitSTS();
> > +   void emitSTG();
> > void emitST();
> > void emitALD();
> > void emitAST();
> > @@ -333,6 +336,17 @@ CodeEmitterGM107::longIMMD(const ValueRef &ref)
> > return false;
> >  }
> >
> > +bool
> > +CodeEmitterGM107::longOffset(const ValueRef &ref)
> > +{
> > +   // TODO: check for other files as well?
> > +   if (ref.getFile() != FILE_MEMORY_GLOBAL)
> > +  return false;
>
> I haven't seen the uses (best to send stuff like this as a series),
> but you're saying that if it's not global memory, then it's not a long
> offset? I suspect in the caller it should be more like
>
> assert(file == global || !long offset) or something.
>
This is how I used it for Load. Store was used the same way. I have
not sent it because we didn't found any noticeable changes with that:

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index c01a3017ba9..f632178138b 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -3603,7 +3603,12 @@ CodeEmitterGM107::emitInstruction(Instruction *i)
   case FILE_MEMORY_CONST : emitLDC(); break;
   case FILE_MEMORY_LOCAL : emitLDL(); break;
   case FILE_MEMORY_SHARED: emitLDS(); break;
-  case FILE_MEMORY_GLOBAL: emitLD(); break;
+  case FILE_MEMORY_GLOBAL:
+ if (longOffset(insn->src(0)))
+emitLD();
+ else
+emitLDG();
+ break;
   default:
  assert(!"invalid load");
  emitNOP();
> > +
> > +   int32_t offset = ref.get()->reg.data.offset;
> > +   return offset >  0x7f || offset < -0x80;
>
> You have two spaces after the >. Remove one of them.
>
> > +}
> > +
> >  void
> >  CodeEmitterGM107::emitIMMD(int pos, int len, const ValueRef &ref)
> >  {
> > @@ -2414,6 +2428,17 @@ CodeEmitterGM107::emitLDS()
> > emitGPR  (0x00, insn->def(0));
> >  }
> >
> > +void
> > +CodeEmitterGM107::emitLDG()
> > +{
> > +   emitInsn (0xeed0);
> > +   emitLDSTs(0x30, insn->dType);
> > +   emitLDSTc(0x2e);
> > +   emitField(0x2d, 1, insn->src(0).getIndirect(0)->getSize() == 8);
>
> I didn't look, but we don't do something a bit more subtle on the
> other ones, like checking if there's an indirect access in the first
> place? With g[], it almost exclusively will be, but still...
>
> > +   emitADDR (0x08, 0x14, 24, 0, insn->src(0));
> > +   emitGPR  (0x00, insn->def(0));
> > +}
> > +
> >  void
> >  CodeEmitterGM107::emitLD()
> >  {
> > @@ -2445,6 +2470,17 @@ CodeEmitterGM107::emitSTS()
> > emitGPR  (0x00, insn->src(1));
> >  }
> >
> > +void
> > +CodeEmitterGM107::emitSTG()
> > +{
> > +   emitInsn (0xeed8);
> > +   emitLDSTs(0x30, insn->dType);
> > +   emitLDSTc(0x2e);
> > +   emitField(0x2d, 1, insn->src(0).getIndirect(0)->getSize() == 8);
> > +   emitADDR (0x08, 0x14, 24, 0, insn->src(0));
> > +   emitGPR  (0x00, insn->src(1));
> > +}
> > +
> >  void
> >  CodeEmitterGM107::emitST()
> >  {
> > --
> > 2.21.0
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: accelerate glCopyPixels(STENCIL)

[apinheiro]

On 11/7/19 20:12, Marek Olšák wrote:
The test passes here. I wouldn't push a commit that doesn't pass. It 
looks like v3d can't blit stencil.



FWIW, just in case you are curious: I was able to take a look today to 
this. This problem only affects the fbo-stencil case with 
GL_DEPTH32F_STENCIL8. So for example, the following ones:


./bin/fbo-stencil copypixels GL_DEPTH24_STENCIL8 -auto -fbo

./bin/fbo-depthstencil copypixels GL_DEPTH32F_STENCIL8 -auto -fbo

works fine, so I guess that we need to do something special with that 
format on v3d.





Marek

On Thu, Jul 11, 2019 at 6:29 AM apinheiro > wrote:


Hi, the following piglit test:

./bin/fbo-stencil copypixels GL_DEPTH32F_STENCIL8 -auto -fbo

regressed after this patch landed master with the v3d driver. So
Marek
and anyone reading this email, could you execute that test and
confirms
if only regress with v3d?

Thanks in advance.

On 25/6/19 2:12, Marek Olšák wrote:
> From: Marek Olšák mailto:marek.ol...@amd.com>>
>
> ---
>   src/mesa/state_tracker/st_cb_drawpixels.c | 58
+++
>   1 file changed, 38 insertions(+), 20 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
b/src/mesa/state_tracker/st_cb_drawpixels.c
> index 59868d3ff1d..26d3cc33e5c 100644
> --- a/src/mesa/state_tracker/st_cb_drawpixels.c
> +++ b/src/mesa/state_tracker/st_cb_drawpixels.c
> @@ -1508,35 +1508,35 @@ static GLboolean
>   blit_copy_pixels(struct gl_context *ctx, GLint srcx, GLint srcy,
>                    GLsizei width, GLsizei height,
>                    GLint dstx, GLint dsty, GLenum type)
>   {
>      struct st_context *st = st_context(ctx);
>      struct pipe_context *pipe = st->pipe;
>      struct pipe_screen *screen = pipe->screen;
>      struct gl_pixelstore_attrib pack, unpack;
>      GLint readX, readY, readW, readH, drawX, drawY, drawW, drawH;
>
> -   if (type == GL_COLOR &&
> -       ctx->Pixel.ZoomX == 1.0 &&
> +   if (ctx->Pixel.ZoomX == 1.0 &&
>          ctx->Pixel.ZoomY == 1.0 &&
> -       ctx->_ImageTransferState == 0x0 &&
> -       !ctx->Color.BlendEnabled &&
> -       !ctx->Color.AlphaEnabled &&
> -       (!ctx->Color.ColorLogicOpEnabled || ctx->Color.LogicOp
== GL_COPY) &&
> -       !ctx->Depth.Test &&
> -       !ctx->Fog.Enabled &&
> -       !ctx->Stencil.Enabled &&
> -       !ctx->FragmentProgram.Enabled &&
> -       !ctx->VertexProgram.Enabled &&
> -  !ctx->_Shader->CurrentProgram[MESA_SHADER_FRAGMENT] &&
> -       !_mesa_ati_fragment_shader_enabled(ctx) &&
> -       ctx->DrawBuffer->_NumColorDrawBuffers == 1 &&
> +       (type != GL_COLOR ||
> +        (ctx->_ImageTransferState == 0x0 &&
> +         !ctx->Color.BlendEnabled &&
> +         !ctx->Color.AlphaEnabled &&
> +         (!ctx->Color.ColorLogicOpEnabled || ctx->Color.LogicOp
== GL_COPY) &&
> +         !ctx->Depth.Test &&
> +         !ctx->Fog.Enabled &&
> +         !ctx->Stencil.Enabled &&
> +         !ctx->FragmentProgram.Enabled &&
> +         !ctx->VertexProgram.Enabled &&
> +  !ctx->_Shader->CurrentProgram[MESA_SHADER_FRAGMENT] &&
> +         !_mesa_ati_fragment_shader_enabled(ctx) &&
> +         ctx->DrawBuffer->_NumColorDrawBuffers == 1)) &&
>          !ctx->Query.CondRenderQuery &&
>          !ctx->Query.CurrentOcclusionObject) {
>         struct st_renderbuffer *rbRead, *rbDraw;
>
>         /*
>          * Clip the read region against the src buffer bounds.
>          * We'll still allocate a temporary buffer/texture for
the original
>          * src region size but we'll only read the region which
is on-screen.
>          * This may mean that we draw garbage pixels into the
dest region, but
>          * that's expected.
> @@ -1555,22 +1555,32 @@ blit_copy_pixels(struct gl_context *ctx,
GLint srcx, GLint srcy,
>         unpack = pack;
>         if (!_mesa_clip_drawpixels(ctx, &drawX, &drawY, &readW,
&readH, &unpack))
>            return GL_TRUE; /* all done */
>
>         readX = readX - pack.SkipPixels + unpack.SkipPixels;
>         readY = readY - pack.SkipRows + unpack.SkipRows;
>
>         drawW = readW;
>         drawH = readH;
>
> -      rbRead = st_get_color_read_renderbuffer(ctx);
> -      rbDraw =
st_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[0]);
> +      if (type == GL_COLOR) {
> +         rbRead = st_get_color_read_renderbuffer(ctx);
> +         rbDraw =
st_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[0]);
> +      } else if (type == GL_DEPTH || type == GL_DEPTH_STENCIL) {
> +         rbRead =
st_renderbuffer(ctx->ReadBuffer->Attachment[BUFFER_DEPTH].Renderbuffer);
> +         rbDraw =
st_renderbuffer(ctx

Re: [Mesa-dev] [PATCH] gm107/ir: Add stg, ldg instructions and function for checking offset length

[Ilia Mirkin]

On Fri, Jul 19, 2019 at 11:34 AM Mark Menzynski  wrote:
>
> On Fri, Jul 19, 2019 at 5:04 PM Ilia Mirkin  wrote:
> >
> > On Fri, Jul 19, 2019 at 10:57 AM Mark Menzynski  wrote:
> > >
> > > Nvidia actively uses these instructions, maybe they are better in
> > > something.
> > > Long offset checking function was made because these functions only have 
> > > 24 bit
> > > address offsets.
> > >
> > > Signed-off-by: Mark Menzynski 
> > > ---
> > >  .../nouveau/codegen/nv50_ir_emit_gm107.cpp| 36 +++
> > >  1 file changed, 36 insertions(+)
> > >
> > > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp 
> > > b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> > > index 6eefe8f0025..c01a3017ba9 100644
> > > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> > > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> > > @@ -87,6 +87,7 @@ private:
> > > inline void emitADDR(int, int, int, int, const ValueRef &);
> > > inline void emitCBUF(int, int, int, int, int, const ValueRef &);
> > > inline bool longIMMD(const ValueRef &);
> > > +   inline bool longOffset(const ValueRef &);
> > > inline void emitIMMD(int, int, const ValueRef &);
> > >
> > > void emitCond3(int, CondCode);
> > > @@ -174,9 +175,11 @@ private:
> > > void emitLDC();
> > > void emitLDL();
> > > void emitLDS();
> > > +   void emitLDG();
> > > void emitLD();
> > > void emitSTL();
> > > void emitSTS();
> > > +   void emitSTG();
> > > void emitST();
> > > void emitALD();
> > > void emitAST();
> > > @@ -333,6 +336,17 @@ CodeEmitterGM107::longIMMD(const ValueRef &ref)
> > > return false;
> > >  }
> > >
> > > +bool
> > > +CodeEmitterGM107::longOffset(const ValueRef &ref)
> > > +{
> > > +   // TODO: check for other files as well?
> > > +   if (ref.getFile() != FILE_MEMORY_GLOBAL)
> > > +  return false;
> >
> > I haven't seen the uses (best to send stuff like this as a series),
> > but you're saying that if it's not global memory, then it's not a long
> > offset? I suspect in the caller it should be more like
> >
> > assert(file == global || !long offset) or something.
> >
> This is how I used it for Load. Store was used the same way. I have
> not sent it because we didn't found any noticeable changes with that:
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> index c01a3017ba9..f632178138b 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> @@ -3603,7 +3603,12 @@ CodeEmitterGM107::emitInstruction(Instruction *i)
>case FILE_MEMORY_CONST : emitLDC(); break;
>case FILE_MEMORY_LOCAL : emitLDL(); break;
>case FILE_MEMORY_SHARED: emitLDS(); break;
> -  case FILE_MEMORY_GLOBAL: emitLD(); break;
> +  case FILE_MEMORY_GLOBAL:
> + if (longOffset(insn->src(0)))
> +emitLD();
> + else
> +emitLDG();
> + break;

OK. I'd dump the check from longOffset -- all it says is if an offset
is long. It just seems awkward as-is.

If people feel strongly though, I could be convinced otherwise.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nvc0/ir: Fix assert accessing null pointer

[Tobias Klausmann]

On 19.07.19 15:39, Eric Engestrom wrote:

On Friday, 2019-07-19 13:56:30 +0200, Mark Menzynski wrote:

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111007
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=67

`Fixes:` is used to indicate the commit that introduced the code being
fixed, such as:
   Fixes: 1c4e6d7ca83578caf521 ("nvc0/ir: propagate immediates to CALL input 
MOVs")
This tag is used by our tools to backport fixes to the relevant stable
releases.

Bugzilla entries are referenced using the `Bugzilla:` prefix.


Signed-off-by: Mark Menzynski 
---
  src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index aca3b0afb1e..1f702a987d8 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -51,12 +51,12 @@ NVC0LegalizeSSA::handleDIV(Instruction *i)
 // Generate movs to the input regs for the call we want to generate
 for (int s = 0; i->srcExists(s); ++s) {
Instruction *ld = i->getSrc(s)->getInsn();
-  assert(ld->getSrc(0) != NULL);

I'll admit I don't know anything about this code, but it looks like
this might be a better fix?
assert(ld == NULL || ld->getSrc(0) != NULL)

I cc'ed Tobias who wrote this code as he'll probably know best.


Thanks for letting me know, but i'm kind of out of the loop and sadly 
don't remember too much about this one.


Yet while having a look at the code i somehow wonder if there is a 
possibility to have


   if (!ld || ld->fixed || (ld->op != OP_LOAD && ld->op != OP_MOV) ||
 !(ld->src(0).getFile() == FILE_IMMEDIATE))

crash at ld->src(0), as this is only set when a value is added to the instruction. So 
in the case ld->src(0) is legal, ld->getSrc(0) should be as well and we would need 
the assert at the beginning...

PS: Did a functional change bring this to the light? (I ran piglit in front of 
every patch sumbission :/)

Greetings,
Tobias





// check if we are moving an immediate, propagate it in that case
if (!ld || ld->fixed || (ld->op != OP_LOAD && ld->op != OP_MOV) ||
  !(ld->src(0).getFile() == FILE_IMMEDIATE))
   bld.mkMovToReg(s, i->getSrc(s));
else {
+ assert(ld->getSrc(0) != NULL);
   bld.mkMovToReg(s, ld->getSrc(0));
   // Clear the src, to make code elimination possible here before we
   // delete the instruction i later
--
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nvc0/ir: Fix assert accessing null pointer

[Ilia Mirkin]

On Fri, Jul 19, 2019 at 12:07 PM Tobias Klausmann
 wrote:
> On 19.07.19 15:39, Eric Engestrom wrote:
> > On Friday, 2019-07-19 13:56:30 +0200, Mark Menzynski wrote:
> >> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111007
> >> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=67
> > `Fixes:` is used to indicate the commit that introduced the code being
> > fixed, such as:
> >Fixes: 1c4e6d7ca83578caf521 ("nvc0/ir: propagate immediates to CALL 
> > input MOVs")
> > This tag is used by our tools to backport fixes to the relevant stable
> > releases.
> >
> > Bugzilla entries are referenced using the `Bugzilla:` prefix.
> >
> >> Signed-off-by: Mark Menzynski 
> >> ---
> >>   src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
> >> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> >> index aca3b0afb1e..1f702a987d8 100644
> >> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> >> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> >> @@ -51,12 +51,12 @@ NVC0LegalizeSSA::handleDIV(Instruction *i)
> >>  // Generate movs to the input regs for the call we want to generate
> >>  for (int s = 0; i->srcExists(s); ++s) {
> >> Instruction *ld = i->getSrc(s)->getInsn();
> >> -  assert(ld->getSrc(0) != NULL);
> > I'll admit I don't know anything about this code, but it looks like
> > this might be a better fix?
> > assert(ld == NULL || ld->getSrc(0) != NULL)
> >
> > I cc'ed Tobias who wrote this code as he'll probably know best.
>
> Thanks for letting me know, but i'm kind of out of the loop and sadly
> don't remember too much about this one.
>
> Yet while having a look at the code i somehow wonder if there is a
> possibility to have
>
> if (!ld || ld->fixed || (ld->op != OP_LOAD && ld->op != OP_MOV) ||
>   !(ld->src(0).getFile() == FILE_IMMEDIATE))
>
> crash at ld->src(0), as this is only set when a value is added to the 
> instruction. So in the case ld->src(0) is legal, ld->getSrc(0) should be as 
> well and we would need the assert at the beginning...
>
> PS: Did a functional change bring this to the light? (I ran piglit in front 
> of every patch sumbission :/)

Nope. Just weird shaders that divide and/or mod 0 by a non-constant amount.

There's an argument to just remove that assert entirely - not sure
that it's adding a whole lot, except complication.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [ANNOUNCE] Mesa 19.1.3 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 19.1.3 is now available. Currently we have:
 - 42 queued
 - 0 nominated (outstanding)
 - and 0 rejected patch


The current queue consist mostly in fixes for ANV and RADV
drivers, as well as NIR backend fixes.

Several of those patches fixe actually crashes with the drivers,
and a couple of them fix memory leaks.

Take a look at section "Mesa stable queue" for more information


Testing reports/general approval

Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.

The plan is to have 19.1.3 this Tuesday (23th July), around or shortly after
10:00 GMT.

If you have any questions or suggestions - be that about the current patch queue
or otherwise, please go ahead.


Trivial merge conflicts
---
commit d86b14ecbb71bdbd4512c877c5acb34befd05f2c
Author: Samuel Pitoiset 

radv: fix VGT_GS_MODE if VS uses the primitive ID

(cherry picked from commit 63d670e350e5249ed91b4bebc59bd7920629eb6c)


commit b685e303f7488d10b37736af3ff0011afb4e649b
Author: Jason Ekstrand 

nir: Add some helpers for chasing SSA values properly

(cherry picked from commit 8f7405ed9d473c1729d48c5add4f0d9fe147c75a)


Cheers,
J.A.


Mesa stable queue
-

Nominated (0)
==

Queued (42)
===
Bas Nieuwenhuizen (3):
  radv: Handle cmask being disallowed by addrlib.
  anv: Add android dependencies on android.
  radv: Only save the descriptor set if we have one.

Caio Marcelo de Oliveira Filho (2):
  anv: Fix pool allocator when first alloc needs to grow
  spirv: Fix stride calculation when lowering Workgroup to offsets

Chia-I Wu (2):
  anv: fix VkExternalBufferProperties for unsupported handles
  anv: fix VkExternalBufferProperties for host allocation

Connor Abbott (1):
  nir: Add a helper to determine if an intrinsic can be reordered

Dave Airlie (1):
  radv: fix crash in shader tracing.

Eric Anholt (1):
  freedreno: Fix assertion failures in context setup in shader-db mode.

Gert Wollny (1):
  softpipe: Remove unused static function

Ian Romanick (4):
  intel/vec4: Reswizzle VF immediates too
  nir: Add unit tests for nir_opt_comparison_pre
  nir: Use nir_src_bit_size instead of alu1->dest.dest.ssa.bit_size
  mesa: Set minimum possible GLSL version

Jason Ekstrand (13):
  nir/instr_set: Expose nir_instrs_equal()
  nir/loop_analyze: Fix phi-of-identical-alu detection
  nir: Add more helpers for working with const values
  nir/loop_analyze: Handle bit sizes correctly in calculate_iterations
  nir/loop_analyze: Bail if we encounter swizzles
  anv: Set Stateless Data Port Access MOCS
  nir/opt_if: Clean up single-src phis in opt_if_loop_terminator
  nir,intel: Add support for lowering 64-bit nir_opt_extract_*
  anv: Account for dynamic stencil write disables in the PMA fix
  nir/regs_to_ssa: Handle regs in phi sources properly
  nir/loop_analyze: Refactor detection of limit vars
  nir: Add some helpers for chasing SSA values properly
  nir/loop_analyze: Properly handle swizzles in loop conditions

Lepton Wu (1):
  virgl: Set meta data for textures from handle.

Lionel Landwerlin (6):
  vulkan/overlay: fix command buffer stats
  vulkan/overlay: fix crash on freeing NULL command buffer
  anv: fix crash in vkCmdClearAttachments with unused attachment
  vulkan/wsi: update swapchain status on vkQueuePresent
  anv: report timestampComputeAndGraphics true
  anv: fix format mapping for depth/stencil formats

Marek Olšák (1):
  radeonsi: don't set READ_ONLY for const_uploader to fix bindless texture 
hangs

Samuel Iglesias Gonsálvez (1):
  anv: fix alphaToCoverage when there is no color attachment

Samuel Pitoiset (1):
  radv: fix VGT_GS_MODE if VS uses the primitive ID

Sergii Romantsov (1):
  meta: memory leak of CopyPixels usage

Timothy Arceri (1):
  mesa: save/restore SSO flag when using ARB_get_program_binary

Vinson Lee (1):
  meson: Add dep_thread dependency.

Yevhenii Kolesnikov (1):
  meta: leaking of BO with DrawPixels


Rejected (0)
=


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [AppVeyor] mesa 19.1 #11953 completed

[AppVeyor]

Build mesa 11953 completed



Commit f17ff71f49 by Dave Airlie on 7/18/2019 12:44 AM:

radv: fix crash in shader tracing.\n\nEnabling tracing, and then having a vmfault, can leads to a segfault\nbefore we print out the traces, as if a meta shader is executing\nand we don't have the NIR for it.\n\nJust pass the stage and give back a default.\n\nFixes: 9b9ccee4d64 ("radv: take LDS into account for compute shader occupancy stats")\nReviewed-by: Samuel Pitoiset \n(cherry picked from commit 2ac2b987801c60e5e141354ee1759b63ca85bf4c)


Configure your notification preferences

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [AppVeyor] mesa master #11954 failed

[AppVeyor]

Build mesa 11954 failed


Commit e8644122ed by Rhys Perry on 7/1/2019 2:49 PM:

nir/algebraic: mark a few comparison simplifications as precise\n\nNo vkpipeline-db changes found.\n\nSigned-off-by: Rhys Perry \nReveiewed-by: Alyssa Rosenzweig alyssa.rosenzw...@collabora.com\nReviewed-by: Connor Abbott 


Configure your notification preferences

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109560] Sometimes VLC player process gets stuck in memory after closure if video output used is Auto or OpenGL

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109560

Michel Dänzer  changed:

   What|Removed |Added

  Component|Mesa core   |GLX

--- Comment #8 from Michel Dänzer  ---
(In reply to Michel Dänzer from comment #7)
> > [...] maybe the X server failed to send an event when it should
> > (e.g. because the window was unmapped).

I've now confirmed this is what's happening. VLC has already destroyed the X11
window at this point, so the X server can't send any Present events for it
anymore.

It might be tricky to make Mesa robust against this... While the GLX spec says
this should be handled gracefully, I suspect it might be easier for VLC to
destroy the GLX context before the window.


> > Most likely not an XCB issue though.
> 
> I'm not sure about this anymore, since thread 6 (from Qt) is stuck in
> xcb_wait_for_event.

That's using a different XCB display handle, so unrelated.

-- 
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
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3] egl/android: Update color_buffers querying for buffer age

[Nataraj Deshpande]

color_buffers[] is currently hard coded to 3 for android which fails
in droid_window_dequeue_buffer when ANativeWindow creates color_buffers
>3 while querying buffer age during dEQP partial_update tests on chromeOS.

The patch removes static color_buffers[], queries for MIN_UNDEQUEUED_BUFFERS,
sets native window buffer count and allocates the correct number of
color_buffers as per android.

Fixes dEQP-EGL.functional.partial_update* tests on chromebooks with
enabling EGL_KHR_partial_update.

v2: update comment instead of removing (Eric Engestrom)
v3: change static array to dynamic allocated color_buffers
querying MIN_UNDEQUEUED_BUFFERS (Chia-I Wu o...@chromium.org)

Fixes: 2acc69da8ce "EGL/Android: Add EGL_EXT_buffer_age extension"
Signed-off-by: Nataraj Deshpande 
Acked-by: Eric Engestrom 
---
 src/egl/drivers/dri2/egl_dri2.h |  7 ---
 src/egl/drivers/dri2/platform_android.c | 30 +++---
 2 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index fa04e3b..3206d00 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -325,13 +325,14 @@ struct dri2_egl_surface
__DRIimage *dri_image_front;
 
/* Used to record all the buffers created by ANativeWindow and their ages.
-* Usually Android uses at most triple buffers in ANativeWindow
-* so hardcode the number of color_buffers to 3.
+* Allocate number of color_buffers based on query to android bufferqueue
+* and save color_buffers_count.
 */
+   int color_buffers_count;
struct {
   struct ANativeWindowBuffer *buffer;
   int age;
-   } color_buffers[3], *back;
+   } *color_buffers, *back;
 #endif
 
/* surfaceless and device */
diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index d949ed4..d37f6b8 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -237,7 +237,7 @@ droid_window_dequeue_buffer(struct dri2_egl_surface 
*dri2_surf)
 * for updating buffer's age in swap_buffers.
 */
EGLBoolean updated = EGL_FALSE;
-   for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
+   for (int i = 0; i < dri2_surf->color_buffers_count; i++) {
   if (!dri2_surf->color_buffers[i].buffer) {
  dri2_surf->color_buffers[i].buffer = dri2_surf->buffer;
   }
@@ -252,7 +252,7 @@ droid_window_dequeue_buffer(struct dri2_egl_surface 
*dri2_surf)
   /* In case of all the buffers were recreated by ANativeWindow, reset
* the color_buffers
*/
-  for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
+  for (int i = 0; i < dri2_surf->color_buffers_count; i++) {
  dri2_surf->color_buffers[i].buffer = NULL;
  dri2_surf->color_buffers[i].age = 0;
   }
@@ -367,6 +367,7 @@ droid_create_surface(_EGLDriver *drv, _EGLDisplay *disp, 
EGLint type,
 
if (type == EGL_WINDOW_BIT) {
   int format;
+  int buffer_count;
 
   if (window->common.magic != ANDROID_NATIVE_WINDOW_MAGIC) {
  _eglError(EGL_BAD_NATIVE_WINDOW, "droid_create_surface");
@@ -377,6 +378,26 @@ droid_create_surface(_EGLDriver *drv, _EGLDisplay *disp, 
EGLint type,
  goto cleanup_surface;
   }
 
+  /* Query ANativeWindow for MIN_UNDEQUEUED_BUFFER, set buffer count
+   * and allocate color_buffers.
+   */
+  if (window->query(window, NATIVE_WINDOW_MIN_UNDEQUEUED_BUFFERS,
+&buffer_count)) {
+ _eglError(EGL_BAD_NATIVE_WINDOW, "droid_create_surface");
+ goto cleanup_surface;
+  }
+  if (native_window_set_buffer_count(window, buffer_count+1)) {
+ _eglError(EGL_BAD_NATIVE_WINDOW, "droid_create_surface");
+ goto cleanup_surface;
+  }
+  dri2_surf->color_buffers = calloc(buffer_count+1,
+sizeof(*dri2_surf->color_buffers));
+  if (!dri2_surf->color_buffers) {
+ _eglError(EGL_BAD_ALLOC, "droid_create_surface");
+ goto cleanup_surface;
+  }
+  dri2_surf->color_buffers_count = buffer_count+1;
+
   if (format != dri2_conf->base.NativeVisualID) {
  _eglLog(_EGL_WARNING, "Native format mismatch: 0x%x != 0x%x",
format, dri2_conf->base.NativeVisualID);
@@ -404,6 +425,8 @@ droid_create_surface(_EGLDriver *drv, _EGLDisplay *disp, 
EGLint type,
return &dri2_surf->base;
 
 cleanup_surface:
+   if (dri2_surf->color_buffers_count)
+  free(dri2_surf->color_buffers);
free(dri2_surf);
 
return NULL;
@@ -456,6 +479,7 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *surf)
dri2_dpy->core->destroyDrawable(dri2_surf->dri_drawable);
 
dri2_fini_surface(surf);
+   free(dri2_surf->color_buffers);
free(dri2_surf);
 
return EGL_TRUE;
@@ -698,7 +722,7 @@ droid_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *draw)
 

[Mesa-dev] [Bug 111141] [REGRESSION] [BISECTED] [DXVK] 1-bit booleans and Elite Dangerous shader mis-optimization

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41

--- Comment #9 from Jason Ekstrand  ---
It's not nonsense at all.  I could see a few possible explanations of the
failure on AMD but not Intel:

 1. The shader depends on undefined behavior and the optimization change caused
that undefined behavior to be different and Intel just happens to work by luck.

 1. The optimization change caused NIR to turn a valid shader into something
which depends on undefined behavior and Intel just happens to work by luck.

 2. The optimization change caused NIR to generate a slightly different shader
which exposed a bug in the AMD LLVM back-end or the NIR -> LLVM translator.

I'd give the three even odds at this point.  I just finished looking quite a
bit at that shader in the context of
https://bugs.freedesktop.org/show_bug.cgi?id=52 and it has 23 undefined
values at the top of the shader.  Let me look at it a bit and see where some of
them are used.  They may be harmless.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111141] [REGRESSION] [BISECTED] [DXVK] 1-bit booleans and Elite Dangerous shader mis-optimization

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41

Jason Ekstrand  changed:

   What|Removed |Added

  Component|Mesa core   |Drivers/Vulkan/radeon

--- Comment #10 from Jason Ekstrand  ---
The undefined values appear harmless so I'm going to guess that this is
probably actually a RADV bug.  Not knowing too much about RADV, how I'd go
aboug debugging it next would be to try "bisecting" nir_opt_algebraic.py by
commenting out large chunks of it and seeing if you can narrow down which
optimization triggers the problem.  Fortunately, with a renderdoc trace, it's
pretty quick to test out changes (before/after shouldn't matter for the
renderdoc capture in this case) so it shouldn't take a terribly long time. 
Once you've figured out which optimization is the culpret, we can see if that
optimization is buggy for some reason.  If the NIR optimization looks sound,
you can try dumping the shaders out of RADV (again, I have no idea how to do
that), diff them, and see if you can figure out why it's a problem.

For the moment, I'm going to move it over to RADV so that those people get
notified.

-- 
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
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] ac/nir: fix txf_ms with an offset

[Rhys Perry]

Seems to fix some hair artifacts in Max Payne 3:
https://github.com/daniel-schuermann/mesa/issues/76

Signed-off-by: Rhys Perry 
Fixes: f4e499ec791 ('radv: add initial non-conformant radv vulkan driver')
---
 src/amd/common/ac_nir_to_llvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 96bf89a8bf9..549a26ea243 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3784,7 +3784,7 @@ static void visit_tex(struct ac_nir_context *ctx, 
nir_tex_instr *instr)
goto write_result;
}
 
-   if (args.offset && instr->op != nir_texop_txf) {
+   if (args.offset && instr->op != nir_texop_txf && instr->op != 
nir_texop_txf_ms) {
LLVMValueRef offset[3], pack;
for (unsigned chan = 0; chan < 3; ++chan)
offset[chan] = ctx->ac.i32_0;
@@ -3919,7 +3919,7 @@ static void visit_tex(struct ac_nir_context *ctx, 
nir_tex_instr *instr)
args.coords[sample_chan], fmask_ptr);
}
 
-   if (args.offset && instr->op == nir_texop_txf) {
+   if (args.offset && (instr->op == nir_texop_txf || instr->op == 
nir_texop_txf_ms)) {
int num_offsets = 
instr->src[offset_src].src.ssa->num_components;
num_offsets = MIN2(num_offsets, instr->coord_components);
for (unsigned i = 0; i < num_offsets; ++i) {
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nvc0/ir: Fix assert accessing null pointer

[Tobias Klausmann]

Am 19.07.19 um 18:18 schrieb Ilia Mirkin:

On Fri, Jul 19, 2019 at 12:07 PM Tobias Klausmann
 wrote:

On 19.07.19 15:39, Eric Engestrom wrote:

On Friday, 2019-07-19 13:56:30 +0200, Mark Menzynski wrote:

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111007
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=67

`Fixes:` is used to indicate the commit that introduced the code being
fixed, such as:
Fixes: 1c4e6d7ca83578caf521 ("nvc0/ir: propagate immediates to CALL input 
MOVs")
This tag is used by our tools to backport fixes to the relevant stable
releases.

Bugzilla entries are referenced using the `Bugzilla:` prefix.


Signed-off-by: Mark Menzynski 
---
   src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index aca3b0afb1e..1f702a987d8 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -51,12 +51,12 @@ NVC0LegalizeSSA::handleDIV(Instruction *i)
  // Generate movs to the input regs for the call we want to generate
  for (int s = 0; i->srcExists(s); ++s) {
 Instruction *ld = i->getSrc(s)->getInsn();
-  assert(ld->getSrc(0) != NULL);

I'll admit I don't know anything about this code, but it looks like
this might be a better fix?
 assert(ld == NULL || ld->getSrc(0) != NULL)

I cc'ed Tobias who wrote this code as he'll probably know best.

Thanks for letting me know, but i'm kind of out of the loop and sadly
don't remember too much about this one.

Yet while having a look at the code i somehow wonder if there is a
possibility to have

 if (!ld || ld->fixed || (ld->op != OP_LOAD && ld->op != OP_MOV) ||
   !(ld->src(0).getFile() == FILE_IMMEDIATE))

crash at ld->src(0), as this is only set when a value is added to the instruction. So 
in the case ld->src(0) is legal, ld->getSrc(0) should be as well and we would need 
the assert at the beginning...

PS: Did a functional change bring this to the light? (I ran piglit in front of 
every patch sumbission :/)

Nope. Just weird shaders that divide and/or mod 0 by a non-constant amount.

There's an argument to just remove that assert entirely - not sure
that it's adding a whole lot, except complication.


Ok,

in this case i'm happy with the patch, with the Bugzilla References and 
the proper Fixes tag added this is:


Reviewed-by: Tobias Klausmann
(yes this mail address is different, but my uni mail address won't exist for 
much longer)

Thanks,
Tobias

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] meson: make "auto" only choose buildable drivers

[Matt Turner]

On Thu, Jul 18, 2019 at 7:19 AM Alyssa Ross  wrote:
>
> "auto" pays attention to the OS and architecture of the target system,
> but not the available libraries. If, say, libdrm isn't available, "auto"
> won't work, and a manual list of drivers will be required anyway. It
> would also try building the virgl and svga gallium drivers, even when
> unsupported due to building with EGL and no compatible platform.

Today with "auto" you'll get some error message if a driver cannot be
built because of a missing library, right?

What happens after your patch? Is the user informed that some driver
included in the "auto" set is not going to be built because of a
missing library? It doesn't seem like it, unless I'm missing
something, and that seems potentially worse than giving an error.

I think automatic selection of build targets really breaks down when
you have as many options and dependencies as we have.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111169] libmesa_util.a(u_queue.c.o): undefined reference to symbol 'pthread_setname_np@@GLIBC_2.12'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=69

Eric Engestrom  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Eric Engestrom  ---
Fixed by:

commit 0e34e1a0ce4741797451648ccad6e634eb4e7a37
Author: Eric Engestrom 
Date:   Fri Jul 19 15:00:35 2019 +0100

mesa/tests: add missing dep_thread

Fixes: f8c27c277585141f2d27 ("state_tracker: Move the format test out to be
an actual unit test.")
Signed-off-by: Eric Engestrom 
Reviewed-by: Eric Anholt 
Tested-by: Vinson Lee 

-- 
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
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nvc0/ir: Fix assert accessing null pointer

[Eric Engestrom]

On Friday, 2019-07-19 21:23:24 +0200, Tobias Klausmann wrote:
> 
> Am 19.07.19 um 18:18 schrieb Ilia Mirkin:
> > On Fri, Jul 19, 2019 at 12:07 PM Tobias Klausmann
> >  wrote:
> > > On 19.07.19 15:39, Eric Engestrom wrote:
> > > > On Friday, 2019-07-19 13:56:30 +0200, Mark Menzynski wrote:
> > > > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111007
> > > > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=67
> > > > `Fixes:` is used to indicate the commit that introduced the code being
> > > > fixed, such as:
> > > > Fixes: 1c4e6d7ca83578caf521 ("nvc0/ir: propagate immediates to CALL 
> > > > input MOVs")
> > > > This tag is used by our tools to backport fixes to the relevant stable
> > > > releases.
> > > > 
> > > > Bugzilla entries are referenced using the `Bugzilla:` prefix.
> > > > 
> > > > > Signed-off-by: Mark Menzynski 
> > > > > ---
> > > > >src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 
> > > > > +-
> > > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git 
> > > > > a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
> > > > > b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> > > > > index aca3b0afb1e..1f702a987d8 100644
> > > > > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> > > > > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> > > > > @@ -51,12 +51,12 @@ NVC0LegalizeSSA::handleDIV(Instruction *i)
> > > > >   // Generate movs to the input regs for the call we want to 
> > > > > generate
> > > > >   for (int s = 0; i->srcExists(s); ++s) {
> > > > >  Instruction *ld = i->getSrc(s)->getInsn();
> > > > > -  assert(ld->getSrc(0) != NULL);
> > > > I'll admit I don't know anything about this code, but it looks like
> > > > this might be a better fix?
> > > >  assert(ld == NULL || ld->getSrc(0) != NULL)
> > > > 
> > > > I cc'ed Tobias who wrote this code as he'll probably know best.
> > > Thanks for letting me know, but i'm kind of out of the loop and sadly
> > > don't remember too much about this one.
> > > 
> > > Yet while having a look at the code i somehow wonder if there is a
> > > possibility to have
> > > 
> > >  if (!ld || ld->fixed || (ld->op != OP_LOAD && ld->op != OP_MOV) 
> > > ||
> > >!(ld->src(0).getFile() == FILE_IMMEDIATE))
> > > 
> > > crash at ld->src(0), as this is only set when a value is added to the 
> > > instruction. So in the case ld->src(0) is legal, ld->getSrc(0) should be 
> > > as well and we would need the assert at the beginning...
> > > 
> > > PS: Did a functional change bring this to the light? (I ran piglit in 
> > > front of every patch sumbission :/)
> > Nope. Just weird shaders that divide and/or mod 0 by a non-constant amount.
> > 
> > There's an argument to just remove that assert entirely - not sure
> > that it's adding a whole lot, except complication.
> 
> Ok,
> 
> in this case i'm happy with the patch, with the Bugzilla References and the
> proper Fixes tag added this is:
> 
> Reviewed-by: Tobias Klausmann
> (yes this mail address is different, but my uni mail address won't exist for 
> much longer)

You might want to add a line to the .mailmap then ;)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111175] meson.build:749:2: ERROR: ['/usr/bin/python3']> is not a valid python

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=75

Bug ID: 75
   Summary: meson.build:749:2: ERROR:  ['/usr/bin/python3']> is not a valid python
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: baker.dyla...@gmail.com

WARNING: Project targetting '>= 0.45' but tried to use feature introduced in
'0.46.0': Python Module
Program python3 found: YES (/usr/bin/python3)

meson.build:749:2: ERROR:  ['/usr/bin/python3']>
is not a valid python

$ meson --version
0.51.0

$ /usr/bin/python3 --version
Python 3.7.4

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111023] build regression: ERROR: ['/usr/bin/python3']> is not a valid python

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=111023

Eric Engestrom  changed:

   What|Removed |Added

 CC||v...@freedesktop.org

--- Comment #3 from Eric Engestrom  ---
*** Bug 75 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111175] meson.build:749:2: ERROR: ['/usr/bin/python3']> is not a valid python

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=75

Eric Engestrom  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Eric Engestrom  ---


*** This bug has been marked as a duplicate of bug 111023 ***

-- 
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
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] egl/android: Update color_buffers querying for buffer age

[Chia-I Wu]

On Fri, Jul 19, 2019 at 11:03 AM Nataraj Deshpande
 wrote:
>
> color_buffers[] is currently hard coded to 3 for android which fails
> in droid_window_dequeue_buffer when ANativeWindow creates color_buffers
> >3 while querying buffer age during dEQP partial_update tests on chromeOS.
>
> The patch removes static color_buffers[], queries for MIN_UNDEQUEUED_BUFFERS,
> sets native window buffer count and allocates the correct number of
> color_buffers as per android.
>
> Fixes dEQP-EGL.functional.partial_update* tests on chromebooks with
> enabling EGL_KHR_partial_update.
>
> v2: update comment instead of removing (Eric Engestrom)
> v3: change static array to dynamic allocated color_buffers
> querying MIN_UNDEQUEUED_BUFFERS (Chia-I Wu o...@chromium.org)
>
> Fixes: 2acc69da8ce "EGL/Android: Add EGL_EXT_buffer_age extension"
> Signed-off-by: Nataraj Deshpande 
> Acked-by: Eric Engestrom 
Reviewed-by: Chia-I Wu 

> ---
>  src/egl/drivers/dri2/egl_dri2.h |  7 ---
>  src/egl/drivers/dri2/platform_android.c | 30 +++---
>  2 files changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
> index fa04e3b..3206d00 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -325,13 +325,14 @@ struct dri2_egl_surface
> __DRIimage *dri_image_front;
>
> /* Used to record all the buffers created by ANativeWindow and their ages.
> -* Usually Android uses at most triple buffers in ANativeWindow
> -* so hardcode the number of color_buffers to 3.
> +* Allocate number of color_buffers based on query to android bufferqueue
> +* and save color_buffers_count.
>  */
> +   int color_buffers_count;
> struct {
>struct ANativeWindowBuffer *buffer;
>int age;
> -   } color_buffers[3], *back;
> +   } *color_buffers, *back;
>  #endif
>
> /* surfaceless and device */
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index d949ed4..d37f6b8 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -237,7 +237,7 @@ droid_window_dequeue_buffer(struct dri2_egl_surface 
> *dri2_surf)
>  * for updating buffer's age in swap_buffers.
>  */
> EGLBoolean updated = EGL_FALSE;
> -   for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
> +   for (int i = 0; i < dri2_surf->color_buffers_count; i++) {
>if (!dri2_surf->color_buffers[i].buffer) {
>   dri2_surf->color_buffers[i].buffer = dri2_surf->buffer;
>}
> @@ -252,7 +252,7 @@ droid_window_dequeue_buffer(struct dri2_egl_surface 
> *dri2_surf)
>/* In case of all the buffers were recreated by ANativeWindow, reset
> * the color_buffers
> */
> -  for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
> +  for (int i = 0; i < dri2_surf->color_buffers_count; i++) {
>   dri2_surf->color_buffers[i].buffer = NULL;
>   dri2_surf->color_buffers[i].age = 0;
>}
> @@ -367,6 +367,7 @@ droid_create_surface(_EGLDriver *drv, _EGLDisplay *disp, 
> EGLint type,
>
> if (type == EGL_WINDOW_BIT) {
>int format;
> +  int buffer_count;
>
>if (window->common.magic != ANDROID_NATIVE_WINDOW_MAGIC) {
>   _eglError(EGL_BAD_NATIVE_WINDOW, "droid_create_surface");
> @@ -377,6 +378,26 @@ droid_create_surface(_EGLDriver *drv, _EGLDisplay *disp, 
> EGLint type,
>   goto cleanup_surface;
>}
>
> +  /* Query ANativeWindow for MIN_UNDEQUEUED_BUFFER, set buffer count
> +   * and allocate color_buffers.
> +   */
> +  if (window->query(window, NATIVE_WINDOW_MIN_UNDEQUEUED_BUFFERS,
> +&buffer_count)) {
> + _eglError(EGL_BAD_NATIVE_WINDOW, "droid_create_surface");
> + goto cleanup_surface;
> +  }
> +  if (native_window_set_buffer_count(window, buffer_count+1)) {
> + _eglError(EGL_BAD_NATIVE_WINDOW, "droid_create_surface");
> + goto cleanup_surface;
> +  }
> +  dri2_surf->color_buffers = calloc(buffer_count+1,
> +sizeof(*dri2_surf->color_buffers));
> +  if (!dri2_surf->color_buffers) {
> + _eglError(EGL_BAD_ALLOC, "droid_create_surface");
> + goto cleanup_surface;
> +  }
> +  dri2_surf->color_buffers_count = buffer_count+1;
> +
>if (format != dri2_conf->base.NativeVisualID) {
>   _eglLog(_EGL_WARNING, "Native format mismatch: 0x%x != 0x%x",
> format, dri2_conf->base.NativeVisualID);
> @@ -404,6 +425,8 @@ droid_create_surface(_EGLDriver *drv, _EGLDisplay *disp, 
> EGLint type,
> return &dri2_surf->base;
>
>  cleanup_surface:
> +   if (dri2_surf->color_buffers_count)
> +  free(dri2_surf->color_buffers);
> free(dri2_surf);
>
> return NULL;
> @@ -456,6 +479,7 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDispl