Re: [Mesa-dev] [PATCH] egl/android: remove HAL_PIXEL_FORMAT_BGRA_8888 support

2019-08-13 Thread Lepton Wu 
Any concern for this CL? I think it's pretty safe to merge this since
any way android egl wrapper
doesn't like HAL_PIXEL_FORMAT_BGRA_ and won't return it for native
window format
and then won't set it as native window format.

https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/opengl/libs/EGL/eglApi.cpp#608

On Wed, Jul 31, 2019 at 3:50 PM Lepton Wu  wrote:
>
> From: Emil Velikov 
>
> As said in the EGL_KHR_platform_android extensions
>
> For each EGLConfig that belongs to the Android platform, the
> EGL_NATIVE_VISUAL_ID attribute is an Android window format, such as
> WINDOW_FORMAT_RGBA_.
>
> Although it should be applicable overall.
>
> Even though we use HAL_PIXEL_FORMAT here, those are numerically
> identical to the  WINDOW_FORMAT_ and AHARDWAREBUFFER_FORMAT_ ones.
>
> Barring the said format of course. That one is only listed in HAL.
>
> Keep in mind that even if we try to use the said format, you'll get
> caught by droid_create_surface(). The function compares the format of
> the underlying window, against the NATIVE_VISUAL_ID of the config.
>
> Unfortunatelly it only prints a warning, rather than error out, likely
> leading to visual corruption.
>
> While SDL will even call ANativeWindow_setBuffersGeometry() with the
> wrong format, and conviniently ignore the [expected] failure.
>
> Signed-off-by: Emil Velikov 
> Acked-by: Tomasz Figa 
> (tfiga: Remove only respective EGL config, leave EGL image as is.)
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Lepton Wu 
> ---
>  src/egl/drivers/dri2/platform_android.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index d37f6b8e447..6c54fc4f1fe 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -1193,7 +1193,6 @@ droid_add_configs_for_visuals(_EGLDriver *drv, 
> _EGLDisplay *disp)
>{ HAL_PIXEL_FORMAT_RGBA_, { 0x00ff, 0xff00, 0x00ff, 
> 0xff00 } },
>{ HAL_PIXEL_FORMAT_RGBX_, { 0x00ff, 0xff00, 0x00ff, 
> 0x } },
>{ HAL_PIXEL_FORMAT_RGB_565,   { 0xf800, 0x07e0, 0x001f, 
> 0x } },
> -  { HAL_PIXEL_FORMAT_BGRA_, { 0x00ff, 0xff00, 0x00ff, 
> 0xff00 } },
> };
>
> unsigned int format_count[ARRAY_SIZE(visuals)] = { 0 };
> --
> 2.22.0.770.g0f2c4a37fd-goog
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111265] [TRACKER] Mesa 19.2 feature tracker

2019-08-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=111265
Bug 111265 depends on bug 111275, which changed state.

Bug 111275 Summary: Feature: CCS_E modifier support and dri_query_image fixes
https://bugs.freedesktop.org/show_bug.cgi?id=111275

   What|Removed |Added

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

-- 
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] panfrost: Kill a useless NULL test in panfrost_job_submit()

2019-08-13 Thread Alyssa Rosenzweig 
Reviewed-by: Alyssa Rosenzweig 

On Tue, Aug 13, 2019 at 08:35:21PM +0200, Boris Brezillon wrote:
> The !job test is done after dereferencing the job pointer, which means
> it's either always false or we have a NULL pointer exception.
> 
> Replace that test by an assert() at the beginning of the function.
> 
> Signed-off-by: Boris Brezillon 
> ---
>  src/gallium/drivers/panfrost/pan_job.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/src/gallium/drivers/panfrost/pan_job.c 
> b/src/gallium/drivers/panfrost/pan_job.c
> index 661f8ae154e2..c2c3aa30714d 100644
> --- a/src/gallium/drivers/panfrost/pan_job.c
> +++ b/src/gallium/drivers/panfrost/pan_job.c
> @@ -204,14 +204,12 @@ panfrost_job_submit(struct panfrost_context *ctx, 
> struct panfrost_job *job)
>  {
>  int ret;
>  
> +assert(job);
>  panfrost_scoreboard_link_batch(job);
>  
>  bool has_draws = job->last_job.gpu;
>  bool is_scanout = panfrost_is_scanout(ctx);
>  
> -if (!job)
> -return;
> -
>  ret = panfrost_drm_submit_vs_fs_job(ctx, has_draws, is_scanout);
>  
>  if (ret)
> -- 
> 2.21.0
> 


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

Re: [Mesa-dev] [PATCH 2/2] panfrost: Implement custom block/instruction iterators

2019-08-13 Thread Alyssa Rosenzweig 
> > > Would it be possible
> > > to extend the shared list.h helpers (might this contain functionality
> > > interesting to other drivers as well)?  
> > 
> > Hm, not without making them more complex I'm afraid. And since
> > most users are happy with the current implementation I'm not entirely
> > sure there's a need for such a feature.
> 
> Taking back what I said previously. Looks like we can add 2 simple macros
> to do that.

Oh, neat. How does that interact with the other parts of the patch
(particularly the next fields)? If this seems to be the ideal solution,
feel free to open an MR on gitlab for the util/ change and we can move
review there if it's easier for you. Thanks for looking into this.


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

Re: [Mesa-dev] [PATCH 2/2] panfrost: Implement custom block/instruction iterators

2019-08-13 Thread Boris Brezillon 
On Tue, 13 Aug 2019 22:25:49 +0200
Boris Brezillon  wrote:

> On Tue, 13 Aug 2019 12:59:03 -0700
> Alyssa Rosenzweig  wrote:
> 
> > Could you explain a little bit more why this is neded? What do these
> > helpers do that the generic list.h helpers can't?  
> 
> The _safe attribute in generic helpers is just about handling the case
> where the current item is removed from the list (or a new one is
> inserted and you want to skip the new entry in your iteration). Some
> users of the mir_foreach_xxx() iterators break this rule: they remove
> entries beyond the current one. That's okay if the removed entry is
> after the one stored in the temporary 'storage' param (also called
> next/prev sometimes), but when one actually removes the next/prev
> entry, the safe iterator ends up manipulating an element that's been
> removed from the list (->{prev,next} might be invalid) or even worse,
> something that's been released (use-after-free).
> 
> > Would it be possible
> > to extend the shared list.h helpers (might this contain functionality
> > interesting to other drivers as well)?  
> 
> Hm, not without making them more complex I'm afraid. And since
> most users are happy with the current implementation I'm not entirely
> sure there's a need for such a feature.

Taking back what I said previously. Looks like we can add 2 simple macros
to do that.

--->8---
diff --git a/src/util/list.h b/src/util/list.h
index 96e2f24695c2..979e68fd806a 100644
--- a/src/util/list.h
+++ b/src/util/list.h
@@ -231,6 +231,11 @@ static inline void list_validate(const struct list_head 
*list)
pos = __next,   \
__next = LIST_ENTRY(type, __next->member.next, member))
 
+#define list_del_safe(type, item, member)   \
+if (__next == item) \
+__next = LIST_ENTRY(type, __next->member.next, member); \
+list_del(>member)
+
 #define list_for_each_entry_rev(type, pos, head, member)\
for (type *pos = LIST_ENTRY(type, (head)->prev, member), \
 *__prev = LIST_ENTRY(type, pos->member.prev, member);  \
@@ -246,6 +251,11 @@ static inline void list_validate(const struct list_head 
*list)
pos = __prev,   \
 __prev = LIST_ENTRY(type, __prev->member.prev, member))
 
+#define list_del_safe_rev(type, item, member)   \
+if (__prev == item) \
+__prev = LIST_ENTRY(type, __prev->member.prev, member); \
+list_del(>member)
+
 #define list_for_each_entry_from(type, pos, start, head, member)\
for (type *pos = LIST_ENTRY(type, (start), member);  \
>member != (head); \
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] panfrost: Implement custom block/instruction iterators

2019-08-13 Thread Alyssa Rosenzweig 
> > Could you explain a little bit more why this is neded? What do these
> > helpers do that the generic list.h helpers can't?
> 
> The _safe attribute in generic helpers is just about handling the case
> where the current item is removed from the list (or a new one is
> inserted and you want to skip the new entry in your iteration). Some
> users of the mir_foreach_xxx() iterators break this rule: they remove
> entries beyond the current one. That's okay if the removed entry is
> after the one stored in the temporary 'storage' param (also called
> next/prev sometimes), but when one actually removes the next/prev
> entry, the safe iterator ends up manipulating an element that's been
> removed from the list (->{prev,next} might be invalid) or even worse,
> something that's been released (use-after-free).

That makes sense; I wish I had been aware of this when writing the
compiler to begin with. Thanks for the clarification!
> 
> > Would it be possible
> > to extend the shared list.h helpers (might this contain functionality
> > interesting to other drivers as well)?
> 
> Hm, not without making them more complex I'm afraid. And since
> most users are happy with the current implementation I'm not entirely
> sure there's a need for such a feature.

Alright, just wanted to ask to make sure we've thought through this
fully before doing our own thing. Sounds good to me!

> > Maybe we want a dedicated variant _with_next() to save the
> > empty argument in the usual case (when we don't actually need it).
> 
> We can, but I also find it useful to expose this implementation detail
> to users, so that they have a rough idea of what's happening behind the
> scene (temporary storage pointing to the next instruction to allow
> safe removal of the current item).

I disagree. Writing a compiler, let alone a compiler for an architecture
like Midgard, is extremely challenging mentally, requiring the author to
balance a large number of layers of abstraction.

Minor implementation details of how linked lists are stored cannot be
one of them.

For v2, could you keep the API exposed to the rest of the compiler the
same (with only two arguments, no next), simply adding additional
_with_next() versions where necessary? Thank you.

-A


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

Re: [Mesa-dev] [PATCH 1/2] panfrost: Don't use mir_foreach_instr_in_block_safe() when not needed

2019-08-13 Thread Alyssa Rosenzweig 
> I don't see any remove_ins()/insert_before() call in there. Do you see
> any reason for using the _safe() variant here?

Er, I think I meant the outer loop, which has a remove/insert pair at
the bottom to change the current instruction.


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

Re: [Mesa-dev] dEQP + llvmpipe

2019-08-13 Thread Ilia Mirkin 
On Tue, Aug 13, 2019 at 4:49 PM Eric Anholt  wrote:
>
> Ilia Mirkin  writes:
>
> > Hi Eric,
> >
> > I see that you recently added testing dEQP with llvmpipe in the CI. It
> > looks like a number of your expected failures would be resolved by
> > disabling some llvmpipe optimizations. You can do this by running with
> >
> > GALLIVM_DEBUG=no_rho_approx,no_brilinear,no_quad_lod
> >
> > in the environment. Some of this is detailed in
> > https://bugs.freedesktop.org/show_bug.cgi?id=94957 .
>
> Yeah, this was discussed in the MR.  I think that for GL and GLES
> contexts, we should disable noncormant hacks instead of using env vars
> to falsely claim conformance.

OK. I figured you'd want the wider coverage of dEQP tests (since a
test may fail for many reasons). But mostly wasn't sure if you knew
about that situation. Sounds like you were well aware though.

Cheers,

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

Re: [Mesa-dev] dEQP + llvmpipe

2019-08-13 Thread Eric Anholt 
Ilia Mirkin  writes:

> Hi Eric,
>
> I see that you recently added testing dEQP with llvmpipe in the CI. It
> looks like a number of your expected failures would be resolved by
> disabling some llvmpipe optimizations. You can do this by running with
>
> GALLIVM_DEBUG=no_rho_approx,no_brilinear,no_quad_lod
>
> in the environment. Some of this is detailed in
> https://bugs.freedesktop.org/show_bug.cgi?id=94957 .

Yeah, this was discussed in the MR.  I think that for GL and GLES
contexts, we should disable noncormant hacks instead of using env vars
to falsely claim conformance.


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

Re: [Mesa-dev] [PATCH] i965/gen11: fix genX_bits.h include path

2019-08-13 Thread Rafael Antognolli 
On Tue, Aug 13, 2019 at 05:50:30PM +0200, Mauro Rossi wrote:
> Instead of "genX_bits.h" use "genxml/genX_bits.h"
> as already done in other similar cases
> 
> Besides being more correct, it also fixes building error in Android.

Ugh, sorry for that.

Reviewed-by: Rafael Antognolli 

> Fixes: f0d2923 ("i965/gen11: Emit SLICE_HASH_TABLE when pipes are 
> unbalanced.")
> Signed-off-by: Mauro Rossi 
> ---
>  src/mesa/drivers/dri/i965/brw_state_upload.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
> b/src/mesa/drivers/dri/i965/brw_state_upload.c
> index c095f2e59c..87550425fc 100644
> --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> @@ -43,7 +43,7 @@
>  #include "brw_gs.h"
>  #include "brw_wm.h"
>  #include "brw_cs.h"
> -#include "genX_bits.h"
> +#include "genxml/genX_bits.h"
>  #include "main/framebuffer.h"
>  
>  void
> -- 
> 2.20.1
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] panfrost: Don't use mir_foreach_instr_in_block_safe() when not needed

2019-08-13 Thread Boris Brezillon 
On Tue, 13 Aug 2019 12:55:57 -0700
Alyssa Rosenzweig  wrote:

> > +++ b/src/panfrost/midgard/midgard_opt_perspective.c
> > @@ -71,7 +71,7 @@ midgard_opt_combine_projection(compiler_context *ctx, 
> > midgard_block *block)
> >  unsigned frcp_component = 0;
> >  unsigned frcp_from = 0;
> >  
> > -mir_foreach_instr_in_block_safe(block, sub) {
> > +mir_foreach_instr_in_block(block, sub) {  
> 
> Should this one be _safe?

I don't see any remove_ins()/insert_before() call in there. Do you see
any reason for using the _safe() variant here?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] panfrost: Implement custom block/instruction iterators

2019-08-13 Thread Boris Brezillon 
On Tue, 13 Aug 2019 12:59:03 -0700
Alyssa Rosenzweig  wrote:

> Could you explain a little bit more why this is neded? What do these
> helpers do that the generic list.h helpers can't?

The _safe attribute in generic helpers is just about handling the case
where the current item is removed from the list (or a new one is
inserted and you want to skip the new entry in your iteration). Some
users of the mir_foreach_xxx() iterators break this rule: they remove
entries beyond the current one. That's okay if the removed entry is
after the one stored in the temporary 'storage' param (also called
next/prev sometimes), but when one actually removes the next/prev
entry, the safe iterator ends up manipulating an element that's been
removed from the list (->{prev,next} might be invalid) or even worse,
something that's been released (use-after-free).

> Would it be possible
> to extend the shared list.h helpers (might this contain functionality
> interesting to other drivers as well)?

Hm, not without making them more complex I'm afraid. And since
most users are happy with the current implementation I'm not entirely
sure there's a need for such a feature.

> 
> What about the new next_ins argument -- should that always be required
> to specify?

AFAICT, it's only really needed in midgard_pair_load_store() to update
next_ins if the instruction we removed is next_ins. This being said, a
few functions were calling mir_next_op() manually and having next_ins
directly accessible saves us this extra call.

> Maybe we want a dedicated variant _with_next() to save the
> empty argument in the usual case (when we don't actually need it).

We can, but I also find it useful to expose this implementation detail
to users, so that they have a rough idea of what's happening behind the
scene (temporary storage pointing to the next instruction to allow
safe removal of the current item).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] panfrost: Implement custom block/instruction iterators

2019-08-13 Thread Alyssa Rosenzweig 
Could you explain a little bit more why this is neded? What do these
helpers do that the generic list.h helpers can't? Would it be possible
to extend the shared list.h helpers (might this contain functionality
interesting to other drivers as well)?

What about the new next_ins argument -- should that always be required
to specify? Maybe we want a dedicated variant _with_next() to save the
empty argument in the usual case (when we don't actually need it).

On Tue, Aug 13, 2019 at 09:25:45PM +0200, Boris Brezillon wrote:
> The generic list helpers are too restrictive for us: we want to be
> able to update the instruction pointer within the foreach body, and the
> list_assert() check done in list_for_each_entry() prevents it.
> Sometimes we also want to update the next_ins pointer (in case we
> delete/replace the next instruction by something else).
> 
> Let's implement our own iterators (still based on the existing list
> helpers) to address this limitation.
> 
> Signed-off-by: Boris Brezillon 
> ---
>  src/panfrost/midgard/compiler.h   | 75 ++-
>  src/panfrost/midgard/midgard_compile.c|  2 +-
>  src/panfrost/midgard/midgard_derivatives.c|  4 +-
>  src/panfrost/midgard/midgard_liveness.c   |  1 +
>  src/panfrost/midgard/midgard_opt_copy_prop.c  |  2 +-
>  src/panfrost/midgard/midgard_opt_dce.c|  6 +-
>  src/panfrost/midgard/midgard_opt_invert.c |  4 +-
>  .../midgard/midgard_opt_perspective.c |  4 +-
>  src/panfrost/midgard/midgard_ra.c |  4 +-
>  src/panfrost/midgard/midgard_schedule.c   | 18 +++--
>  src/panfrost/midgard/mir_promote_uniforms.c   |  2 +-
>  11 files changed, 84 insertions(+), 38 deletions(-)
> 
> diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
> index d62157f3be4f..19f65ddc96ec 100644
> --- a/src/panfrost/midgard/compiler.h
> +++ b/src/panfrost/midgard/compiler.h
> @@ -305,44 +305,83 @@ mir_remove_instruction(struct midgard_instruction *ins)
>  list_del(>link);
>  }
>  
> -static inline midgard_instruction*
> -mir_prev_op(struct midgard_instruction *ins)
> +static inline midgard_instruction *
> +mir_first_op(struct midgard_block *block)
>  {
> -return list_last_entry(&(ins->link), midgard_instruction, link);
> +assert(block);
> +return list_first_entry(>instructions, struct 
> midgard_instruction, link);
>  }
>  
> -static inline midgard_instruction*
> +static inline midgard_instruction *
> +mir_last_op(struct midgard_block *block)
> +{
> +assert(block);
> +return list_last_entry(>instructions, struct 
> midgard_instruction, link);
> +}
> +
> +static inline midgard_instruction *
> +mir_prev_op(struct midgard_instruction *ins)
> +{
> +assert(ins);
> +return list_last_entry(>link, struct midgard_instruction, link);
> +}
> +
> +static inline midgard_instruction *
>  mir_next_op(struct midgard_instruction *ins)
>  {
> -return list_first_entry(&(ins->link), midgard_instruction, link);
> +assert(ins);
> +return list_first_entry(>link, struct midgard_instruction, 
> link);
> +}
> +
> +static inline struct midgard_block *mir_first_block(compiler_context *ctx)
> +{
> +assert(ctx);
> +return list_first_entry(>blocks, struct midgard_block, link);
> +}
> +
> +static inline struct midgard_block *mir_next_block(struct midgard_block *b)
> +{
> +assert(b);
> +return list_first_entry(>link, struct midgard_block, link);
>  }
>  
>  #define mir_foreach_block(ctx, v) \
> -list_for_each_entry(struct midgard_block, v, >blocks, link)
> +for (struct midgard_block *v = mir_first_block(ctx); \
> + >link != >blocks; v = mir_next_block(v))
>  
>  #define mir_foreach_block_from(ctx, from, v) \
> -list_for_each_entry_from(struct midgard_block, v, from, 
> >blocks, link)
> +for (struct midgard_block *v = from; >link != >blocks; \
> + v = mir_next_block(v))
>  
>  #define mir_foreach_instr(ctx, v) \
> -list_for_each_entry(struct midgard_instruction, v, 
> >current_block->instructions, link)
> +for (struct midgard_instruction *v = 
> mir_first_op(ctx->current_block); \
> + >link != >current_block->instructions; v = 
> mir_next_op(v))
>  
> -#define mir_foreach_instr_safe(ctx, v) \
> -list_for_each_entry_safe(struct midgard_instruction, v, 
> >current_block->instructions, link)
> +#define mir_foreach_instr_safe(ctx, v, n) \
> +for (struct midgard_instruction *v = 
> mir_first_op(ctx->current_block), \
> + struct midgard_instruction *n = mir_next_op(v); \
> + >link != >current_block->instructions; \
> + v = n, n = mir_next_op(v))
>  
>  #define mir_foreach_instr_in_block(block, v) \
> -list_for_each_entry(struct midgard_instruction, v, 
> >instructions, link)
> +for (struct midgard_instruction *v = mir_first_op(block); \
> + >link !=

Re: [Mesa-dev] [PATCH 1/2] panfrost: Don't use mir_foreach_instr_in_block_safe() when not needed

2019-08-13 Thread Alyssa Rosenzweig 
> +++ b/src/panfrost/midgard/midgard_opt_perspective.c
> @@ -71,7 +71,7 @@ midgard_opt_combine_projection(compiler_context *ctx, 
> midgard_block *block)
>  unsigned frcp_component = 0;
>  unsigned frcp_from = 0;
>  
> -mir_foreach_instr_in_block_safe(block, sub) {
> +mir_foreach_instr_in_block(block, sub) {

Should this one be _safe?


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

[Mesa-dev] dEQP + llvmpipe

2019-08-13 Thread Ilia Mirkin 
Hi Eric,

I see that you recently added testing dEQP with llvmpipe in the CI. It
looks like a number of your expected failures would be resolved by
disabling some llvmpipe optimizations. You can do this by running with

GALLIVM_DEBUG=no_rho_approx,no_brilinear,no_quad_lod

in the environment. Some of this is detailed in
https://bugs.freedesktop.org/show_bug.cgi?id=94957 .

Cheers,

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

[Mesa-dev] [PATCH 1/2] panfrost: Don't use mir_foreach_instr_in_block_safe() when not needed

2019-08-13 Thread Boris Brezillon 
mir_foreach_instr_in_block_safe() is only needed if the caller intend
to remove the current item from the list. Downgrade to
mir_foreach_instr_in_block() when this is not the case.

Signed-off-by: Boris Brezillon 
---
 src/panfrost/midgard/midgard_compile.c | 2 +-
 src/panfrost/midgard/midgard_opt_invert.c  | 6 +++---
 src/panfrost/midgard/midgard_opt_perspective.c | 6 +++---
 src/panfrost/midgard/midgard_schedule.c| 2 +-
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/panfrost/midgard/midgard_compile.c 
b/src/panfrost/midgard/midgard_compile.c
index 460847e82660..e261e80c06c5 100644
--- a/src/panfrost/midgard/midgard_compile.c
+++ b/src/panfrost/midgard/midgard_compile.c
@@ -2161,7 +2161,7 @@ midgard_opt_pos_propagate(compiler_context *ctx, 
midgard_block *block)
 {
 bool progress = false;
 
-mir_foreach_instr_in_block_safe(block, ins) {
+mir_foreach_instr_in_block(block, ins) {
 if (ins->type != TAG_ALU_4) continue;
 if (ins->alu.op != midgard_alu_op_fmov) continue;
 if (ins->alu.outmod != midgard_outmod_pos) continue;
diff --git a/src/panfrost/midgard/midgard_opt_invert.c 
b/src/panfrost/midgard/midgard_opt_invert.c
index b68c98c74dbb..422be6ef03e5 100644
--- a/src/panfrost/midgard/midgard_opt_invert.c
+++ b/src/panfrost/midgard/midgard_opt_invert.c
@@ -69,7 +69,7 @@ midgard_opt_not_propagate(compiler_context *ctx, 
midgard_block *block)
 {
 bool progress = false;
 
-mir_foreach_instr_in_block_safe(block, ins) {
+mir_foreach_instr_in_block(block, ins) {
 if (ins->type != TAG_ALU_4) continue;
 if (ins->alu.op != midgard_alu_op_imov) continue;
 if (!ins->invert) continue;
@@ -162,7 +162,7 @@ midgard_opt_fuse_dest_invert(compiler_context *ctx, 
midgard_block *block)
 {
 bool progress = false;
 
-mir_foreach_instr_in_block_safe(block, ins) {
+mir_foreach_instr_in_block(block, ins) {
 /* Search for inverted bitwise */
 if (ins->type != TAG_ALU_4) continue;
 if (!mir_is_bitwise(ins)) continue;
@@ -213,7 +213,7 @@ midgard_opt_fuse_src_invert(compiler_context *ctx, 
midgard_block *block)
 {
 bool progress = false;
 
-mir_foreach_instr_in_block_safe(block, ins) {
+mir_foreach_instr_in_block(block, ins) {
 /* Search for inverted bitwise */
 if (ins->type != TAG_ALU_4) continue;
 if (!mir_is_bitwise(ins)) continue;
diff --git a/src/panfrost/midgard/midgard_opt_perspective.c 
b/src/panfrost/midgard/midgard_opt_perspective.c
index f5e483e68d0e..993000923b93 100644
--- a/src/panfrost/midgard/midgard_opt_perspective.c
+++ b/src/panfrost/midgard/midgard_opt_perspective.c
@@ -71,7 +71,7 @@ midgard_opt_combine_projection(compiler_context *ctx, 
midgard_block *block)
 unsigned frcp_component = 0;
 unsigned frcp_from = 0;
 
-mir_foreach_instr_in_block_safe(block, sub) {
+mir_foreach_instr_in_block(block, sub) {
 if (sub->ssa_args.dest != frcp) continue;
 
 midgard_vector_alu_src s =
@@ -97,7 +97,7 @@ midgard_opt_combine_projection(compiler_context *ctx, 
midgard_block *block)
 /* One for frcp and one for fmul */
 if (mir_use_count(ctx, frcp_from) > 2) continue;
 
-mir_foreach_instr_in_block_safe(block, v) {
+mir_foreach_instr_in_block(block, v) {
 if (v->ssa_args.dest != frcp_from) continue;
 if (v->type != TAG_LOAD_STORE_4) break;
 if (!OP_IS_LOAD_VARY_F(v->load_store.op)) break;
@@ -157,7 +157,7 @@ midgard_opt_varying_projection(compiler_context *ctx, 
midgard_block *block)
 
 bool rewritten = false;
 
-mir_foreach_instr_in_block_safe(block, v) {
+mir_foreach_instr_in_block(block, v) {
 if (v->ssa_args.dest != vary) continue;
 if (v->type != TAG_LOAD_STORE_4) break;
 if (!OP_IS_LOAD_VARY_F(v->load_store.op)) break;
diff --git a/src/panfrost/midgard/midgard_schedule.c 
b/src/panfrost/midgard/midgard_schedule.c
index 486bb38e0493..7ec0d4428a43 100644
--- a/src/panfrost/midgard/midgard_schedule.c
+++ b/src/panfrost/midgard/midgard_schedule.c
@@ -806,7 +806,7 @@ static void mir_spill_register(
 /* For special reads, figure out how many components we need */
 unsigned read_mask = 0;
 
-mir_foreach_instr_global_safe(ctx, ins) {
+mir_foreach_instr_global(ctx, ins) {
 read_mask |= mir_mask_of_read_components(ins, spill_node);
 }
 
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

[Mesa-dev] [PATCH 2/2] panfrost: Implement custom block/instruction iterators

2019-08-13 Thread Boris Brezillon 
The generic list helpers are too restrictive for us: we want to be
able to update the instruction pointer within the foreach body, and the
list_assert() check done in list_for_each_entry() prevents it.
Sometimes we also want to update the next_ins pointer (in case we
delete/replace the next instruction by something else).

Let's implement our own iterators (still based on the existing list
helpers) to address this limitation.

Signed-off-by: Boris Brezillon 
---
 src/panfrost/midgard/compiler.h   | 75 ++-
 src/panfrost/midgard/midgard_compile.c|  2 +-
 src/panfrost/midgard/midgard_derivatives.c|  4 +-
 src/panfrost/midgard/midgard_liveness.c   |  1 +
 src/panfrost/midgard/midgard_opt_copy_prop.c  |  2 +-
 src/panfrost/midgard/midgard_opt_dce.c|  6 +-
 src/panfrost/midgard/midgard_opt_invert.c |  4 +-
 .../midgard/midgard_opt_perspective.c |  4 +-
 src/panfrost/midgard/midgard_ra.c |  4 +-
 src/panfrost/midgard/midgard_schedule.c   | 18 +++--
 src/panfrost/midgard/mir_promote_uniforms.c   |  2 +-
 11 files changed, 84 insertions(+), 38 deletions(-)

diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index d62157f3be4f..19f65ddc96ec 100644
--- a/src/panfrost/midgard/compiler.h
+++ b/src/panfrost/midgard/compiler.h
@@ -305,44 +305,83 @@ mir_remove_instruction(struct midgard_instruction *ins)
 list_del(>link);
 }
 
-static inline midgard_instruction*
-mir_prev_op(struct midgard_instruction *ins)
+static inline midgard_instruction *
+mir_first_op(struct midgard_block *block)
 {
-return list_last_entry(&(ins->link), midgard_instruction, link);
+assert(block);
+return list_first_entry(>instructions, struct 
midgard_instruction, link);
 }
 
-static inline midgard_instruction*
+static inline midgard_instruction *
+mir_last_op(struct midgard_block *block)
+{
+assert(block);
+return list_last_entry(>instructions, struct 
midgard_instruction, link);
+}
+
+static inline midgard_instruction *
+mir_prev_op(struct midgard_instruction *ins)
+{
+assert(ins);
+return list_last_entry(>link, struct midgard_instruction, link);
+}
+
+static inline midgard_instruction *
 mir_next_op(struct midgard_instruction *ins)
 {
-return list_first_entry(&(ins->link), midgard_instruction, link);
+assert(ins);
+return list_first_entry(>link, struct midgard_instruction, link);
+}
+
+static inline struct midgard_block *mir_first_block(compiler_context *ctx)
+{
+assert(ctx);
+return list_first_entry(>blocks, struct midgard_block, link);
+}
+
+static inline struct midgard_block *mir_next_block(struct midgard_block *b)
+{
+assert(b);
+return list_first_entry(>link, struct midgard_block, link);
 }
 
 #define mir_foreach_block(ctx, v) \
-list_for_each_entry(struct midgard_block, v, >blocks, link)
+for (struct midgard_block *v = mir_first_block(ctx); \
+ >link != >blocks; v = mir_next_block(v))
 
 #define mir_foreach_block_from(ctx, from, v) \
-list_for_each_entry_from(struct midgard_block, v, from, >blocks, 
link)
+for (struct midgard_block *v = from; >link != >blocks; \
+ v = mir_next_block(v))
 
 #define mir_foreach_instr(ctx, v) \
-list_for_each_entry(struct midgard_instruction, v, 
>current_block->instructions, link)
+for (struct midgard_instruction *v = mir_first_op(ctx->current_block); 
\
+ >link != >current_block->instructions; v = mir_next_op(v))
 
-#define mir_foreach_instr_safe(ctx, v) \
-list_for_each_entry_safe(struct midgard_instruction, v, 
>current_block->instructions, link)
+#define mir_foreach_instr_safe(ctx, v, n) \
+for (struct midgard_instruction *v = mir_first_op(ctx->current_block), 
\
+ struct midgard_instruction *n = mir_next_op(v); \
+ >link != >current_block->instructions; \
+ v = n, n = mir_next_op(v))
 
 #define mir_foreach_instr_in_block(block, v) \
-list_for_each_entry(struct midgard_instruction, v, 
>instructions, link)
+for (struct midgard_instruction *v = mir_first_op(block); \
+ >link != >instructions; v = mir_next_op(v))
 
-#define mir_foreach_instr_in_block_safe(block, v) \
-list_for_each_entry_safe(struct midgard_instruction, v, 
>instructions, link)
+#define mir_foreach_instr_in_block_safe(block, v, n) \
+for (struct midgard_instruction *v = mir_first_op(block), *n = 
mir_next_op(v); \
+ >link != >instructions; v = n, n = mir_next_op(v))
 
 #define mir_foreach_instr_in_block_safe_rev(block, v) \
-list_for_each_entry_safe_rev(struct midgard_instruction, v, 
>instructions, link)
+for (struct midgard_instruction *v = mir_last_op(block), *p = 
mir_prev_op(v); \
+ >link != >instructions; v = p, p = mir_prev_op(v))
 
 #define mir_foreach_instr_in_block_from(block, v, from) \
-

Re: [Mesa-dev] [PATCH] android: mesa: revert "Enable asm unconditionally"

2019-08-13 Thread Mauro Rossi 
Hi,

On Tue, Aug 13, 2019 at 3:51 PM Tapani Pälli  wrote:

>
> On 8/13/19 3:32 PM, Mauro Rossi wrote:
> > Hi,
> >
> > On Tue, Aug 13, 2019 at 2:03 PM Tapani Pälli  > > wrote:
> >
> > Hi;
> >
> > On 8/13/19 2:43 PM, Mauro Rossi wrote:
> >  > Hi Tapani,
> >  >
> >  > On Sat, Jul 27, 2019 at 2:56 PM Mauro Rossi
> > mailto:issor.or...@gmail.com>
> >  > >>
> wrote:
> >  >
> >  > On Sat, Jul 27, 2019 at 2:56 PM Mauro Rossi
> > mailto:issor.or...@gmail.com>
> >  >  > >> wrote:
> >  >  >
> >  >  > On Thu, Jul 18, 2019 at 1:07 PM Chih-Wei Huang
> >  > mailto:cwhu...@android-x86.org>
> > >>
> > wrote:
> >  >  > >
> >  >  > > Mauro Rossi  > 
> >  >  > >> 於 2019年7月14日 週日 下午5:17寫道：
> >  >  > > >
> >  >  > > > This patch partially reverts 20294dc ("mesa: Enable asm
> >  > unconditionally, ...")
> >  >  > > >
> >  >  > > > Android makefile build logic needs to disable assembler
> >  > optimization
> >  >  > > > in 32bit builds to avoid text relocations for
> > libglapi.so shared
> >  >  > > >
> >  >  > > > Fixes the following build error with Android x86 32bit
> > target:
> >  >  > > >
> >  >  > > > [  0% 4/477] target SharedLib: libglapi
> >  >
> >
>  
> (out/target/product/x86/obj/SHARED_LIBRARIES/libglapi_intermediates/LINKED/libglapi.so)
> >  >  > > > FAILED:
> >  >
> >
>  
> out/target/product/x86/obj/SHARED_LIBRARIES/libglapi_intermediates/LINKED/libglapi.so
> >  >  > > > ...
> >  >  > > >
> >  >
> >
>  
> prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin/ld:
> >  > warning: shared library text segment is not shareable
> >  >  > > >
> >  >
> >
>  
> prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin/ld:
> >  > error: treating warnings as errors
> >  >  > > > clang-6.0: error: linker command failed with exit code
> > 1 (use
> >  > -v to see invocation)
> >  >  > > >
> >  >  > > > Fixes: 20294dc ("mesa: Enable asm unconditionally, now
> > that
> >  > gen_matypes is gone.")
> >  >  > > > Signed-off-by: Mauro Rossi  > 
> >  >  >>>
> >  >  > > > ---
> >  >  > > > Android.common.mk 
> > 
> >  >   | 3 +++
> >  >  > > >  Android.mk  | 7 +++
> >  >  > > >  src/mesa/Android.libmesa_dricore.mk
> > 
> >  >  | 2 ++
> >  >  > > >  src/mesa/Android.libmesa_st_mesa.mk
> > 
> >  >  | 2 ++
> >  >  > > >  4 files changed, 14 insertions(+)
> >  >  > > >
> >  >  > > > diff --git a/Android.common.mk
> >  
> >  > b/Android.common.mk 
> > 
> >  >  > > > index 8a1c734353..209654bb75 100644
> >  >  > > > --- a/Android.common.mk 
> > 
> >  >  > > > +++ b/Android.common.mk 
> > 
> >  >  > > > @@ -106,9 +106,12 @@ ifeq ($(shell test
> >  > $(PLATFORM_SDK_VERSION) -ge 26 && echo true),true)
> >  >  > > >  LOCAL_CFLAGS += -DHAVE_SYS_SHM_H
> >  >  > > >  endif
> >  >  > > >
> >  >  > > > +ifeq ($(strip $(MESA_ENABLE_ASM)),true)
> >  >  > > >  ifeq ($(TARGET_ARCH),x86)
> >  >  > > >  LOCAL_CFLAGS += \
> >  >  > > > -DUSE_X86_ASM
> >  >  > > > +
> >  >  > > > +endif
> >  >  > > >  endif
> >  >  > > >  ifeq ($(ARCH_ARM_HAVE_NEON),true)
> >  >  > > >  LOCAL_CFLAGS_arm += -DUSE_ARM_ASM
> >  >  > > > diff --git a/Android.mk b/Android.mk
> >  >  > > > index 57613eccfc..4a2a003ea3 100644
> >  >  > > > --- a/Android.mk
> >  >  > > > +++ b/Android.mk
> >  >  > > > @@ -83,6 +83,13 @@ endif
> >  >  > > >
> >  >  > > >  $(foreach d, $(MESA_BUILD_CLASSIC)
> $(MESA_BUILD_GALLIUM),
> >  > $(eval $(d) := true))
> >  >  > > >
> >  >  > > > +# host and target must be the same arch to generate
> > matypes.h
> >

[Mesa-dev] [PATCH] panfrost: Kill a useless NULL test in panfrost_job_submit()

2019-08-13 Thread Boris Brezillon 
The !job test is done after dereferencing the job pointer, which means
it's either always false or we have a NULL pointer exception.

Replace that test by an assert() at the beginning of the function.

Signed-off-by: Boris Brezillon 
---
 src/gallium/drivers/panfrost/pan_job.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_job.c 
b/src/gallium/drivers/panfrost/pan_job.c
index 661f8ae154e2..c2c3aa30714d 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -204,14 +204,12 @@ panfrost_job_submit(struct panfrost_context *ctx, struct 
panfrost_job *job)
 {
 int ret;
 
+assert(job);
 panfrost_scoreboard_link_batch(job);
 
 bool has_draws = job->last_job.gpu;
 bool is_scanout = panfrost_is_scanout(ctx);
 
-if (!job)
-return;
-
 ret = panfrost_drm_submit_vs_fs_job(ctx, has_draws, is_scanout);
 
 if (ret)
-- 
2.21.0

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

[Mesa-dev] [Bug 110471] No Man Sky GPU hang

2019-08-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=110471

--- Comment #5 from Haxk20  ---
That workaround works for me but has huge graphical artifacts. Like blue
triangles all over the screen. Basically unplayable.

-- 
You are receiving this mail because:
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 1/9] panfrost: Implement callbacks for PRIMITIVES queries

2019-08-13 Thread Boris Brezillon 
On Fri,  9 Aug 2019 13:00:44 -0700
Alyssa Rosenzweig  wrote:

> We're just going to compute them in the driver but let's get the
> structures setup to handle them. Implementation from v3d.
> 
> Signed-off-by: Alyssa Rosenzweig 

The whole patchset is

Reviewed-by: Boris Brezillon 

> ---
>  src/gallium/drivers/panfrost/pan_context.c | 52 --
>  src/gallium/drivers/panfrost/pan_context.h | 15 ++-
>  2 files changed, 52 insertions(+), 15 deletions(-)
> 
> diff --git a/src/gallium/drivers/panfrost/pan_context.c 
> b/src/gallium/drivers/panfrost/pan_context.c
> index ac1d1b9429b..3903a4ca337 100644
> --- a/src/gallium/drivers/panfrost/pan_context.c
> +++ b/src/gallium/drivers/panfrost/pan_context.c
> @@ -2365,7 +2365,8 @@ static void
>  panfrost_set_active_query_state(struct pipe_context *pipe,
>  bool enable)
>  {
> -//struct panfrost_context *panfrost = pan_context(pipe);
> +struct panfrost_context *ctx = pan_context(pipe);
> +ctx->active_queries = enable;
>  }
>  
>  static void
> @@ -2415,17 +2416,24 @@ panfrost_begin_query(struct pipe_context *pipe, 
> struct pipe_query *q)
>  switch (query->type) {
>  case PIPE_QUERY_OCCLUSION_COUNTER:
>  case PIPE_QUERY_OCCLUSION_PREDICATE:
> -case PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE: {
> +case PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE:
>  /* Allocate a word for the query results to be stored */
>  query->transfer = panfrost_allocate_transient(ctx, 
> sizeof(unsigned));
> -
>  ctx->occlusion_query = query;
> +break;
> +
> +/* Geometry statistics are computed in the driver. XXX: geom/tess
> + * shaders.. */
>  
> +case PIPE_QUERY_PRIMITIVES_GENERATED:
> +query->start = ctx->prims_generated;
> +break;
> +case PIPE_QUERY_PRIMITIVES_EMITTED:
> +query->start = ctx->tf_prims_generated;
>  break;
> -}
>  
>  default:
> -DBG("Skipping query %d\n", query->type);
> +fprintf(stderr, "Skipping query %d\n", query->type);
>  break;
>  }
>  
> @@ -2436,7 +2444,22 @@ static bool
>  panfrost_end_query(struct pipe_context *pipe, struct pipe_query *q)
>  {
>  struct panfrost_context *ctx = pan_context(pipe);
> -ctx->occlusion_query = NULL;
> +struct panfrost_query *query = (struct panfrost_query *) q;
> +
> +switch (query->type) {
> +case PIPE_QUERY_OCCLUSION_COUNTER:
> +case PIPE_QUERY_OCCLUSION_PREDICATE:
> +case PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE:
> +ctx->occlusion_query = NULL;
> +break;
> +case PIPE_QUERY_PRIMITIVES_GENERATED:
> +query->end = ctx->prims_generated;
> +break;
> +case PIPE_QUERY_PRIMITIVES_EMITTED:
> +query->end = ctx->tf_prims_generated;
> +break;
> +}
> +
>  return true;
>  }
>  
> @@ -2446,18 +2469,16 @@ panfrost_get_query_result(struct pipe_context *pipe,
>bool wait,
>union pipe_query_result *vresult)
>  {
> -/* STUB */
>  struct panfrost_query *query = (struct panfrost_query *) q;
>  
> -/* We need to flush out the jobs to actually run the counter, TODO
> - * check wait, TODO wallpaper after if needed */
> -
> -panfrost_flush(pipe, NULL, PIPE_FLUSH_END_OF_FRAME);
>  
>  switch (query->type) {
>  case PIPE_QUERY_OCCLUSION_COUNTER:
>  case PIPE_QUERY_OCCLUSION_PREDICATE:
> -case PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE: {
> +case PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE:
> +/* Flush first */
> +panfrost_flush(pipe, NULL, PIPE_FLUSH_END_OF_FRAME);
> +
>  /* Read back the query results */
>  unsigned *result = (unsigned *) query->transfer.cpu;
>  unsigned passed = *result;
> @@ -2469,7 +2490,12 @@ panfrost_get_query_result(struct pipe_context *pipe,
>  }
>  
>  break;
> -}
> +
> +case PIPE_QUERY_PRIMITIVES_GENERATED:
> +case PIPE_QUERY_PRIMITIVES_EMITTED:
> +vresult->u64 = query->end - query->start;
> +break;
> +
>  default:
>  DBG("Skipped query get %d\n", query->type);
>  break;
> diff --git a/src/gallium/drivers/panfrost/pan_context.h 
> b/src/gallium/drivers/panfrost/pan_context.h
> index 542d24d2c27..24c54fe3467 100644
> --- a/src/gallium/drivers/panfrost/pan_context.h
> +++ b/src/gallium/drivers/panfrost/pan_context.h
> @@ -79,8 +79,16 @@ struct panfrost_query {
>  unsigned type;
>  unsigned index;
>  
> -/* Memory for the GPU to writeback the value of

[Mesa-dev] [PATCH] i965/gen11: fix genX_bits.h include path

2019-08-13 Thread Mauro Rossi 
Instead of "genX_bits.h" use "genxml/genX_bits.h"
as already done in other similar cases

Besides being more correct, it also fixes building error in Android.

Fixes: f0d2923 ("i965/gen11: Emit SLICE_HASH_TABLE when pipes are unbalanced.")
Signed-off-by: Mauro Rossi 
---
 src/mesa/drivers/dri/i965/brw_state_upload.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index c095f2e59c..87550425fc 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -43,7 +43,7 @@
 #include "brw_gs.h"
 #include "brw_wm.h"
 #include "brw_cs.h"
-#include "genX_bits.h"
+#include "genxml/genX_bits.h"
 #include "main/framebuffer.h"
 
 void
-- 
2.20.1

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

[Mesa-dev] [Bug 111393] Warnings about Formats with "inconsistent channel types"

2019-08-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=111393

Bug ID: 111393
   Summary: Warnings about Formats with "inconsistent channel
types"
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: issor.or...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Hi,
I'm building mesa with radv and I'm getting these warnings
printed out from gfx10_format_table.h generator (gfx10_format_table.py)

Gen Header: libmesa_radv_common_32 <= gfx10_format_table.h
Format VK_FORMAT_D16_UNORM_S8_UINT has inconsistent channel types: set([1])
set([False, True]) set([False, True])
Format VK_FORMAT_D24_UNORM_S8_UINT has inconsistent channel types: set([1])
set([False, True]) set([False, True])
Format VK_FORMAT_D32_SFLOAT_S8_UINT has inconsistent channel types: set([1, 4])
set([False]) set([False, True])

Could you please check what is the problem?
Mauro

-- 
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] android: mesa: revert "Enable asm unconditionally"

2019-08-13 Thread Tapani Pälli 


On 8/13/19 3:32 PM, Mauro Rossi wrote:

Hi,

On Tue, Aug 13, 2019 at 2:03 PM Tapani Pälli > wrote:


Hi;

On 8/13/19 2:43 PM, Mauro Rossi wrote:
 > Hi Tapani,
 >
 > On Sat, Jul 27, 2019 at 2:56 PM Mauro Rossi
mailto:issor.or...@gmail.com>
 > >> wrote:
 >
 >     On Sat, Jul 27, 2019 at 2:56 PM Mauro Rossi
mailto:issor.or...@gmail.com>
 >     >> wrote:
 >      >
 >      > On Thu, Jul 18, 2019 at 1:07 PM Chih-Wei Huang
 >     mailto:cwhu...@android-x86.org>
>>
wrote:
 >      > >
 >      > > Mauro Rossi mailto:issor.or...@gmail.com>
 >     >> 於 2019年7月14日 週日 下午5:17寫道：
 >      > > >
 >      > > > This patch partially reverts 20294dc ("mesa: Enable asm
 >     unconditionally, ...")
 >      > > >
 >      > > > Android makefile build logic needs to disable assembler
 >     optimization
 >      > > > in 32bit builds to avoid text relocations for
libglapi.so shared
 >      > > >
 >      > > > Fixes the following build error with Android x86 32bit
target:
 >      > > >
 >      > > > [  0% 4/477] target SharedLib: libglapi
 >   
  (out/target/product/x86/obj/SHARED_LIBRARIES/libglapi_intermediates/LINKED/libglapi.so)

 >      > > > FAILED:
 >   
  out/target/product/x86/obj/SHARED_LIBRARIES/libglapi_intermediates/LINKED/libglapi.so

 >      > > > ...
 >      > > >
 >   
  prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin/ld:

 >     warning: shared library text segment is not shareable
 >      > > >
 >   
  prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin/ld:

 >     error: treating warnings as errors
 >      > > > clang-6.0: error: linker command failed with exit code
1 (use
 >     -v to see invocation)
 >      > > >
 >      > > > Fixes: 20294dc ("mesa: Enable asm unconditionally, now
that
 >     gen_matypes is gone.")
 >      > > > Signed-off-by: Mauro Rossi mailto:issor.or...@gmail.com>
 >     >>
 >      > > > ---
 >      > > > Android.common.mk 

 >       | 3 +++
 >      > > >  Android.mk                          | 7 +++
 >      > > >  src/mesa/Android.libmesa_dricore.mk

 >      | 2 ++
 >      > > >  src/mesa/Android.libmesa_st_mesa.mk

 >      | 2 ++
 >      > > >  4 files changed, 14 insertions(+)
 >      > > >
 >      > > > diff --git a/Android.common.mk
 
 >     b/Android.common.mk 

 >      > > > index 8a1c734353..209654bb75 100644
 >      > > > --- a/Android.common.mk 

 >      > > > +++ b/Android.common.mk 

 >      > > > @@ -106,9 +106,12 @@ ifeq ($(shell test
 >     $(PLATFORM_SDK_VERSION) -ge 26 && echo true),true)
 >      > > >  LOCAL_CFLAGS += -DHAVE_SYS_SHM_H
 >      > > >  endif
 >      > > >
 >      > > > +ifeq ($(strip $(MESA_ENABLE_ASM)),true)
 >      > > >  ifeq ($(TARGET_ARCH),x86)
 >      > > >  LOCAL_CFLAGS += \
 >      > > >         -DUSE_X86_ASM
 >      > > > +
 >      > > > +endif
 >      > > >  endif
 >      > > >  ifeq ($(ARCH_ARM_HAVE_NEON),true)
 >      > > >  LOCAL_CFLAGS_arm += -DUSE_ARM_ASM
 >      > > > diff --git a/Android.mk b/Android.mk
 >      > > > index 57613eccfc..4a2a003ea3 100644
 >      > > > --- a/Android.mk
 >      > > > +++ b/Android.mk
 >      > > > @@ -83,6 +83,13 @@ endif
 >      > > >
 >      > > >  $(foreach d, $(MESA_BUILD_CLASSIC) $(MESA_BUILD_GALLIUM),
 >     $(eval $(d) := true))
 >      > > >
 >      > > > +# host and target must be the same arch to generate
matypes.h
 >      > > > +ifeq ($(TARGET_ARCH),$(HOST_ARCH))
 >      > > > +MESA_ENABLE_ASM := true
 >      > > > +else
 >      > > > +MESA_ENABLE_ASM := false
 >      > > > +endif
 >      > > > +
 >      > > >  ifneq ($(filter true, $(HAVE_GALLIUM_RADEONSI)),)
 >      > > >  MESA_ENABLE_LLVM := true
 >      > > >  endif
 >      > > > diff --git a/src/mesa/Android.libmesa_dricore.mk

 >     
 > 

Re: [Mesa-dev] [PATCH v7 0/5] EGL_KHR_partial_update support

2019-08-13 Thread Boris Brezillon 
On Mon, 12 Aug 2019 12:07:03 +0200
Boris Brezillon  wrote:

> This is an attempt at resurrecting Daniel's MR [1] which was already
> resurrecting Harish's EGL_KHR_partial_update series [2]. This version
> implements Marek's suggestion to pass the set_damage_region() directly
> to the gallium driver and let it decide how to handle the request. Some
> drivers might just calculate the damage extent (as done in Daniel's
> initial proposal and in the panfrost implementation), others might do
> extra optimizations like trying to reduce the area we're supposed to
> reload (only valid for tile-based rendering) even further.
> 
> This patch series has been tested with weston on panfrost. Note that
> the panfrost implementation is rather simple (just limits the rendering
> area to the damage extent and picks the biggest damage rect as the only
> damage region) but we can improve it if we feel the need.
> 
> No major changes in this v7, just added the missing FREE(boxes) call
> in dri2_set_damage_region() and fixed an alignment issue in the
> panfrost driver.
> 
> Regards,
> 
> Boris
> 
> [1]https://gitlab.freedesktop.org/mesa/mesa/merge_requests/227
> [2]https://patchwork.freedesktop.org/series/45915/#rev2
> 
> *** BLURB HERE ***
> 
> Boris Brezillon (1):
>   panfrost: Add support for KHR_partial_update()
> 
> Daniel Stone (2):
>   dri_interface: add DRI2_BufferDamage interface
>   st/dri2: Implement DRI2bufferDamageExtension
> 
> Harish Krupo (2):
>   egl/android: Delete set_damage_region from egl dri vtbl
>   egl/dri: Use __DRI2_BUFFER_DAMAGE extension for KHR_partial_update

Patch series queued to master.

Thanks for your reviews.

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

Re: [Mesa-dev] [PATCH] android: mesa: revert "Enable asm unconditionally"

2019-08-13 Thread Mauro Rossi 
Hi,

On Tue, Aug 13, 2019 at 2:03 PM Tapani Pälli  wrote:

> Hi;
>
> On 8/13/19 2:43 PM, Mauro Rossi wrote:
> > Hi Tapani,
> >
> > On Sat, Jul 27, 2019 at 2:56 PM Mauro Rossi  > > wrote:
> >
> > On Sat, Jul 27, 2019 at 2:56 PM Mauro Rossi  > > wrote:
> >  >
> >  > On Thu, Jul 18, 2019 at 1:07 PM Chih-Wei Huang
> > mailto:cwhu...@android-x86.org>> wrote:
> >  > >
> >  > > Mauro Rossi  > > 於 2019年7月14日 週日 下午5:17寫道：
> >  > > >
> >  > > > This patch partially reverts 20294dc ("mesa: Enable asm
> > unconditionally, ...")
> >  > > >
> >  > > > Android makefile build logic needs to disable assembler
> > optimization
> >  > > > in 32bit builds to avoid text relocations for libglapi.so
> shared
> >  > > >
> >  > > > Fixes the following build error with Android x86 32bit target:
> >  > > >
> >  > > > [  0% 4/477] target SharedLib: libglapi
> >
>  
> (out/target/product/x86/obj/SHARED_LIBRARIES/libglapi_intermediates/LINKED/libglapi.so)
> >  > > > FAILED:
> >
>  
> out/target/product/x86/obj/SHARED_LIBRARIES/libglapi_intermediates/LINKED/libglapi.so
> >  > > > ...
> >  > > >
> >
>  
> prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin/ld:
> > warning: shared library text segment is not shareable
> >  > > >
> >
>  
> prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin/ld:
> > error: treating warnings as errors
> >  > > > clang-6.0: error: linker command failed with exit code 1 (use
> > -v to see invocation)
> >  > > >
> >  > > > Fixes: 20294dc ("mesa: Enable asm unconditionally, now that
> > gen_matypes is gone.")
> >  > > > Signed-off-by: Mauro Rossi  > >
> >  > > > ---
> >  > > > Android.common.mk 
> >   | 3 +++
> >  > > >  Android.mk  | 7 +++
> >  > > >  src/mesa/Android.libmesa_dricore.mk
> >  | 2 ++
> >  > > >  src/mesa/Android.libmesa_st_mesa.mk
> >  | 2 ++
> >  > > >  4 files changed, 14 insertions(+)
> >  > > >
> >  > > > diff --git a/Android.common.mk 
> > b/Android.common.mk 
> >  > > > index 8a1c734353..209654bb75 100644
> >  > > > --- a/Android.common.mk 
> >  > > > +++ b/Android.common.mk 
> >  > > > @@ -106,9 +106,12 @@ ifeq ($(shell test
> > $(PLATFORM_SDK_VERSION) -ge 26 && echo true),true)
> >  > > >  LOCAL_CFLAGS += -DHAVE_SYS_SHM_H
> >  > > >  endif
> >  > > >
> >  > > > +ifeq ($(strip $(MESA_ENABLE_ASM)),true)
> >  > > >  ifeq ($(TARGET_ARCH),x86)
> >  > > >  LOCAL_CFLAGS += \
> >  > > > -DUSE_X86_ASM
> >  > > > +
> >  > > > +endif
> >  > > >  endif
> >  > > >  ifeq ($(ARCH_ARM_HAVE_NEON),true)
> >  > > >  LOCAL_CFLAGS_arm += -DUSE_ARM_ASM
> >  > > > diff --git a/Android.mk b/Android.mk
> >  > > > index 57613eccfc..4a2a003ea3 100644
> >  > > > --- a/Android.mk
> >  > > > +++ b/Android.mk
> >  > > > @@ -83,6 +83,13 @@ endif
> >  > > >
> >  > > >  $(foreach d, $(MESA_BUILD_CLASSIC) $(MESA_BUILD_GALLIUM),
> > $(eval $(d) := true))
> >  > > >
> >  > > > +# host and target must be the same arch to generate matypes.h
> >  > > > +ifeq ($(TARGET_ARCH),$(HOST_ARCH))
> >  > > > +MESA_ENABLE_ASM := true
> >  > > > +else
> >  > > > +MESA_ENABLE_ASM := false
> >  > > > +endif
> >  > > > +
> >  > > >  ifneq ($(filter true, $(HAVE_GALLIUM_RADEONSI)),)
> >  > > >  MESA_ENABLE_LLVM := true
> >  > > >  endif
> >  > > > diff --git a/src/mesa/Android.libmesa_dricore.mk
> > 
> > b/src/mesa/Android.libmesa_dricore.mk
> > 
> >  > > > index 8eb6aabe83..792117767b 100644
> >  > > > --- a/src/mesa/Android.libmesa_dricore.mk
> > 
> >  > > > +++ b/src/mesa/Android.libmesa_dricore.mk
> > 
> >  > > > @@ -39,9 +39,11 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES
> >  > > >  LOCAL_SRC_FILES := \
> >  > > > $(MESA_FILES)
> >  > > >
> >  > > > +ifeq ($(strip $(MESA_ENABLE_ASM)),true)
> >  > > >  ifeq ($(TARGET_ARCH),x86)
> >  > > > LOCAL_SRC_FILES += $(X86_FILES)
> >  > > >  endif # x86
> >  > > > +endif # MESA_ENABLE_ASM
> >  > > >
> >  > > >  ifeq ($(ARCH_X86_HAVE_SSE4_1),true)
> >  > > >  LOCAL_WHOLE_STATIC_LIBRARIES := \
> >  > > > diff --git a/src/mesa/Android.libmesa_st_mesa.mk
> > 
> > b/src/mesa/Android.libmesa_st_mesa.mk
> >