Re: [Mesa-dev] [RFC 1/2] gallium: add renderonly driver

2015-10-19 Thread Lucas Stach
MHO this whole device fusing is wrong from an architectural
point of view.

This series implements a way to fuse multiple DRM devices into a single
EGL device, solely on the base that current EGL users expect that a
single device is able to render and scanout at the same time. This is a
flawed premise on itself and this series actively tries to keep the
illusion that this is true, even for SoC and prime systems. While doing
so it is putting a lot device specific knowledge into the implementation
of the midlayer/helpers.

IMHO we should not try to keep that illusion, but work out a way for
client applications to deal with the situation of having multiple
scanout/render devices in a easy way.

I mean having render/scanout on different devices isn't exactly news, in
fact we already have to deal with that for the various prime laptops.
Currently all the complexity of those setups is hidden in the X server,
but that one will go away and we have to find a way to make it easy for
the various wayland compositors to deal with that.

My current proposal would be as follows:

1. Implement etnaviv/nouveau on tegra as EGL devices that are only able
to render into offscreen surfaces.

2. Implement an easy way for compositors to discover EGL devices and
their capabilities. (There are already patches for EGL device and
related stuff on the ML)

3. Implement a generic KMS EGL device that is only able to prove
scanout. Have EGL_EXT_stream_consumer_egloutput [1] working on top of
that.

4. Implement EGL_KHR_stream_producer_eglsurface for the render only EGL
devices.

Details of the hardware like the need to detile the render buffer can be
negotiated as part of the EGL stream handshaking.

This will give a generic compositor an easy way to deal with the
situation of multiple render/scanout devices without the need to know
about hardware details. I know that this isn't the easy way to go, but
it solves the problem in a generic way and we don't run into the same
problem again once someone attaches a discreet GPU to one of those SoCs.

I would like to hear what others are thinking about that.

[...]
> > I know that this is a copy of what I had in my original proposal, but I
> > fully admit that it wasn't much more than a proof of concept with quite
> > a few rough edges to work out.
> >
> 
> Mine is also more like a proof-of-concept but I want to get it merged
> in some form :)
> 
I fear that getting a solution merged that gets us the half way, nobody
will bother to do it more generically after that.

Regards,
Lucas

[1]
https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_stream_consumer_egloutput.txt

[2]
https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_stream_producer_eglsurface.txt




-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

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


[Mesa-dev] [PATCH libdrm] add support for imx-drm in tests

2015-02-18 Thread Lucas Stach
From: Philipp Zabel 

Since imx-drm has graduated from staging it seems to be a good idea to
recognize it by default in the libdrm tests.

Signed-off-by: Philipp Zabel 
Signed-off-by: Lucas Stach 
---
lst: added commit message + rebase to master
---
 tests/kmstest/main.c  | 1 +
 tests/modetest/modetest.c | 2 +-
 tests/vbltest/vbltest.c   | 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/kmstest/main.c b/tests/kmstest/main.c
index 449d75f6a880..2c87b1c1b1c0 100644
--- a/tests/kmstest/main.c
+++ b/tests/kmstest/main.c
@@ -62,6 +62,7 @@ char *drivers[] = {
"nouveau",
"vmwgfx",
"exynos",
+   "imx-drm",
NULL
 };
 
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 4b9cf2f5b439..425e5287b107 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1453,7 +1453,7 @@ int main(int argc, char **argv)
int drop_master = 0;
int test_vsync = 0;
int test_cursor = 0;
-   const char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", 
"omapdrm", "exynos", "tilcdc", "msm", "sti", "tegra" };
+   const char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", 
"omapdrm", "exynos", "tilcdc", "msm", "sti", "tegra", "imx-drm" };
char *device = NULL;
char *module = NULL;
unsigned int i;
diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
index 6e13c57c6e38..916d494635b2 100644
--- a/tests/vbltest/vbltest.c
+++ b/tests/vbltest/vbltest.c
@@ -106,7 +106,7 @@ int main(int argc, char **argv)
 {
unsigned i;
int c, fd, ret;
-   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos", 
"omapdrm", "tilcdc", "msm", "tegra" };
+   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos", 
"omapdrm", "tilcdc", "msm", "tegra", "imx-drm" };
drmVBlank vbl;
drmEventContext evctx;
struct vbl_info handler_info;
-- 
2.1.4

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


Re: [Mesa-dev] [Mesa-announce] Mesa 10.3 release candidate 1

2015-02-19 Thread Lucas Stach
Am Freitag, den 07.11.2014, 01:19 -0800 schrieb Matt Turner:
> On Fri, Nov 7, 2014 at 1:07 AM, Thierry Vignaud
>  wrote:
> > On 5 November 2014 04:44, Matt Turner  wrote:
> >>>>>I tried to reproduce this today and couldn't.
> >
> > (...)
> >
> >>>> Thanks. Maybe you could give a little more information, like an error
> >>>> message or something?
> >>>
> >>> Same error as Thierry reported in this thread in August:
> >>
> >> Unfortunately Thierry's was from a re-run of make, so it wasn't useful.
> >
> > No It wasn't a re-run!
> > It was a clean build in our build system with make -jXX with XX auto set to
> > the number of cores and is always reproducable given enough cores
> 
> Oh, weird.
> 
> >> I've gone over this all and can't spot the problem. The dependencies
> >> look fine. I tried automake-1.13 and 1.14, and make-3.82 and 4.0.
> >> Maybe I'll have more luck on a 40 core system.
> >
> > As already explained, in order to be able to reproduce, you must either have
> > a large system or force make -j to a high value (eg: -j24)
> 
> Did you see the rest of the thread where I said I couldn't reproduce
> on a 40 core system?
> 
> Perhaps someone who can reproduce could try to take a look?

Ok, here is what happens:

This failure is only reproducible with the following config options:
--disable-shared-glapi
--disable-gles1
--disable-gles2

Which makes it pretty obvious what is to be blamed here. With those
options set no installable libraries will be build below src/mapi, the
only target is a static glapi.la. As lib_LTLIBRARIES is empty in that
case the install-mesa-links target has no dependencies and gets executed
immediately. This fails as it races with the compilation to create
the .libs dir.

As the install-mesa-links target works perfectly fine with an empty
lib_LTLIBRARIES the fix is simply to not depends on the .libs directory
for the state file of this target. A patch is on the list.

Regards,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

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


[Mesa-dev] [PATCH] install-lib-links: don't depend on .libs directory

2015-02-19 Thread Lucas Stach
This snippet can be included in Makefiles that may, depending on the
project configuration, not actually build any installable libraries.

In that case we don't have anything to depend on and this part of
the makefile may be executed before the .libs directory is created,
so do not depend on it being there.

Signed-off-by: Lucas Stach 
Cc: "10.3 10.4" 
---
 install-lib-links.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/install-lib-links.mk b/install-lib-links.mk
index 6976ca4911ab..3545b268ebd1 100644
--- a/install-lib-links.mk
+++ b/install-lib-links.mk
@@ -3,9 +3,9 @@
 
 if BUILD_SHARED
 if HAVE_COMPAT_SYMLINKS
-all-local : .libs/install-mesa-links
+all-local : .install-mesa-links
 
-.libs/install-mesa-links : $(lib_LTLIBRARIES)
+.install-mesa-links : $(lib_LTLIBRARIES)
$(AM_V_GEN)$(MKDIR_P) $(top_builddir)/$(LIB_DIR);   \
for f in $(join $(addsuffix .libs/,$(dir $(lib_LTLIBRARIES))),$(notdir 
$(lib_LTLIBRARIES:%.la=%.$(LIB_EXT)*))); do \
if test -h .libs/$$f; then  \
-- 
2.1.4

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


Re: [Mesa-dev] [PATCH libdrm] add support for imx-drm in tests

2015-02-23 Thread Lucas Stach
As this is a really trivial one I'm going to push this by Wednesday this
week if nobody voices any objections.

Regards,
Lucas

Am Mittwoch, den 18.02.2015, 12:01 +0100 schrieb Lucas Stach:
> From: Philipp Zabel 
> 
> Since imx-drm has graduated from staging it seems to be a good idea to
> recognize it by default in the libdrm tests.
> 
> Signed-off-by: Philipp Zabel 
> Signed-off-by: Lucas Stach 
> ---
> lst: added commit message + rebase to master
> ---
>  tests/kmstest/main.c  | 1 +
>  tests/modetest/modetest.c | 2 +-
>  tests/vbltest/vbltest.c   | 2 +-
>  3 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/kmstest/main.c b/tests/kmstest/main.c
> index 449d75f6a880..2c87b1c1b1c0 100644
> --- a/tests/kmstest/main.c
> +++ b/tests/kmstest/main.c
> @@ -62,6 +62,7 @@ char *drivers[] = {
>   "nouveau",
>   "vmwgfx",
>   "exynos",
> + "imx-drm",
>   NULL
>  };
>  
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 4b9cf2f5b439..425e5287b107 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -1453,7 +1453,7 @@ int main(int argc, char **argv)
>   int drop_master = 0;
>   int test_vsync = 0;
>   int test_cursor = 0;
> - const char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", 
> "omapdrm", "exynos", "tilcdc", "msm", "sti", "tegra" };
> + const char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", 
> "omapdrm", "exynos", "tilcdc", "msm", "sti", "tegra", "imx-drm" };
>   char *device = NULL;
>   char *module = NULL;
>   unsigned int i;
> diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
> index 6e13c57c6e38..916d494635b2 100644
> --- a/tests/vbltest/vbltest.c
> +++ b/tests/vbltest/vbltest.c
> @@ -106,7 +106,7 @@ int main(int argc, char **argv)
>  {
>   unsigned i;
>   int c, fd, ret;
> - char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos", 
> "omapdrm", "tilcdc", "msm", "tegra" };
> + char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos", 
> "omapdrm", "tilcdc", "msm", "tegra", "imx-drm" };
>   drmVBlank vbl;
>   drmEventContext evctx;
>   struct vbl_info handler_info;

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

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


Re: [Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

2017-02-03 Thread Lucas Stach
Hi Wladimir,

this is about the userspace component of the driver, so dri-devel isn't
the correct list for this question, you should instead CC the MESA dev
list, even if mostly the same people hang out on those lists.

Done that for you now. 

Regards,
Lucas 

Am Freitag, den 03.02.2017, 10:56 +0100 schrieb Wladimir J. van der
Laan:
> Hello,
> 
> With the Etnaviv driver we're running into an issue: The GPU can only render 
> *to*
> BGRA formats. It can however render *from* BGRA as well as RGBA textures.
> 
> I know that the OpenGL ES standard allows drivers to choose what order is most
> appropriate when being asked for "GL_RGBA" textures. So back when etnaviv 
> supported
> only BGRA, Mesa automatically picked that and everything was okay.
> 
> However a recent patch added support for RGBA formats in etnaviv_format.c.
> 
> Now, Mesa creates a real GL_RGBA texture when this is requested. This is all
> and well for rendering, however for anything using FBO to render to textures
> this is a problem.
> 
> Qt, for example, is assuming it can attach the GL_RGBA texture to a FBO. This
> fails now that GL_RGBA textures are really GL_RGBA, and it doesn't handle that
> error to fall back to something else so rendering issues ensue.
> 
> I'm not sure how to handle this:
> 
> - The quick fix would be to revert the RGBA formats patch, but the hardware
>   supports rendering *from* RGBA textures fine so this would be throwing away 
> a
>   feature.
> 
> - Another way would be to try to fix Qt to cope with this, and try e.g. 
> GL_BGRA_EXT
>   when it wants to render to a texture. Burdening the client code with this 
> seems
>   unintuitive to me.
> 
> - Another hack would be to implement shader variants, and swap R/B in the 
> pixel
>   shader to emulate rendering to RGBA.
> 
> Neither seems great. Does anyone have suggestions, do any of the other
> (gallium) drivers have this problem?
> 
> Regards,
> Wladimir
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv


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


Re: [Mesa-dev] [PATCH 2/3] etnaviv: keep track of emitted loops

2017-02-08 Thread Lucas Stach
Am Mittwoch, den 08.02.2017, 12:10 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_compiler.c | 6 ++
>  src/gallium/drivers/etnaviv/etnaviv_compiler.h | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c 
> b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> index 7446a19..af7b64d 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> @@ -183,6 +183,8 @@ struct etna_compile {
> unsigned labels_count, labels_sz;
> struct etna_compile_label *labels;
>  
> +   unsigned num_loops;
> +
> /* Code generation */
> int inst_ptr; /* current instruction pointer */
> uint32_t code[ETNA_MAX_INSTRUCTIONS * ETNA_INST_SIZE];
> @@ -1166,6 +1168,8 @@ trans_loop_bgn(const struct instr_translater *t, struct 
> etna_compile *c,
> f->lbl_loop_end = alloc_new_label(c);
>  
> label_place(c, f->lbl_loop_bgn);
> +
> +   c->num_loops++;
>  }
>  
>  static void
> @@ -2418,6 +2422,7 @@ etna_compile_shader(const struct etna_specs *specs,
> shader->processor = c->info.processor;
> shader->code_size = c->inst_ptr * 4;
> shader->code = mem_dup(c->code, c->inst_ptr * 16);
> +   shader->num_loops = c->num_loops;
> shader->num_temps = c->next_free_native;
> shader->vs_pos_out_reg = -1;
> shader->vs_pointsize_out_reg = -1;
> @@ -2455,6 +2460,7 @@ etna_dump_shader(const struct etna_shader *shader)
>  
> etna_disasm(shader->code, shader->code_size, PRINT_RAW);
>  
> +   printf("num loops: %i\n", shader->num_loops);
> printf("num temps: %i\n", shader->num_temps);
> printf("num const: %i\n", shader->uniforms.const_count);
> printf("immediates:\n");
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.h 
> b/src/gallium/drivers/etnaviv/etnaviv_compiler.h
> index d310109..211ae1a 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_compiler.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.h
> @@ -59,6 +59,7 @@ struct etna_shader {
> uint processor; /* TGSI_PROCESSOR_... */
> uint32_t code_size; /* code size in uint32 words */
> uint32_t *code;
> +   unsigned num_loops;
> unsigned num_temps;
>  
> struct etna_shader_uniform_info uniforms;


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


Re: [Mesa-dev] [PATCH 3/3] etnaviv: shader-db traces

2017-02-08 Thread Lucas Stach
Am Mittwoch, den 08.02.2017, 12:10 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_compiler.h |  2 ++
>  src/gallium/drivers/etnaviv/etnaviv_debug.h|  1 +
>  src/gallium/drivers/etnaviv/etnaviv_screen.c   |  1 +
>  src/gallium/drivers/etnaviv/etnaviv_shader.c   | 44 
> +-
>  4 files changed, 47 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.h 
> b/src/gallium/drivers/etnaviv/etnaviv_compiler.h
> index 211ae1a..de3e20d 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_compiler.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.h
> @@ -56,6 +56,8 @@ struct etna_shader_io_file {
>  
>  /* shader object, for linking */
>  struct etna_shader {
> +   uint32_t id; /* for debug */

Do you need this? It can certainly be removed from this patch, but I
don't know if you have other stuff building on top of this.

> uint processor; /* TGSI_PROCESSOR_... */
> uint32_t code_size; /* code size in uint32 words */
> uint32_t *code;
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_debug.h 
> b/src/gallium/drivers/etnaviv/etnaviv_debug.h
> index cfda52b..f47dffe 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_debug.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_debug.h
> @@ -51,6 +51,7 @@
>  #define ETNA_DBG_FLUSH_ALL   0x10 /* Flush after every rendered 
> primitive */
>  #define ETNA_DBG_ZERO0x20 /* Zero all resources after 
> allocation */
>  #define ETNA_DBG_DRAW_STALL  0x40 /* Stall FE/PE after every draw op 
> */
> +#define ETNA_DBG_SHADERDB0x80 /* dump program compile 
> information */
>  
>  extern int etna_mesa_debug; /* set in etna_screen.c from ETNA_DEBUG */
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index 8f2882f..6272f6f 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -62,6 +62,7 @@ static const struct debug_named_value debug_options[] = {
> {"flush_all",  ETNA_DBG_FLUSH_ALL, "Flush after every rendered 
> primitive"},
> {"zero",   ETNA_DBG_ZERO, "Zero all resources after allocation"},
> {"draw_stall", ETNA_DBG_DRAW_STALL, "Stall FE/PE after each rendered 
> primitive"},
> +   {"shaderdb",   ETNA_DBG_SHADERDB, "Enable shaderdb output"},
> DEBUG_NAMED_VALUE_END
>  };
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_shader.c 
> b/src/gallium/drivers/etnaviv/etnaviv_shader.c
> index 8895311..87edf5b 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_shader.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_shader.c
> @@ -223,6 +223,42 @@ etna_shader_update_vs_inputs(struct etna_context *ctx,
> return true;
>  }
>  
> +static inline const char *
> +etna_shader_stage(struct etna_shader *shader)
> +{
> +   switch (shader->processor) {
> +   case PIPE_SHADER_VERTEX: return "VERT";
> +   case PIPE_SHADER_FRAGMENT:   return "FRAG";
> +   case PIPE_SHADER_COMPUTE:return "CL";
> +   default:
> +  unreachable("invalid type");
> +  return NULL;
> +   }
> +}
> +
> +static void
> +dump_shader_info(struct etna_shader *shader, struct pipe_debug_callback 
> *debug)
> +{
> +   if (!unlikely(etna_mesa_debug & ETNA_DBG_SHADERDB))
> +  return;
> +
> +   pipe_debug_message(debug, SHADER_INFO, "\n"
> + "SHADER-DB: %s prog %d: %u instructions %u temps\n"
> + "SHADER-DB: %s prog %d: %u immediates %u consts\n"
> + "SHADER-DB: %s prog %d: %u loops\n",
> + etna_shader_stage(shader),
> + shader->id,
> + shader->code_size,
> + shader->num_temps,
> + etna_shader_stage(shader),
> + shader->id,
> + shader->uniforms.imm_count,
> + shader->uniforms.const_count,
> + etna_shader_stage(shader),
> + shader->id,
> + shader->num_loops);
> +}
> +
>  bool
>  etna_shader_update_vertex(struct etna_context *ctx)
>  {
> @@ -235,8 +271,14 @@ etna_create_shader_state(struct pipe_context *pctx,
>   const struct pipe_shader_state *pss)
>  {
> struct etna_context *ctx = etna_context(pctx);
> +   struct etna_shader *shader = etna_compile_shader(&ctx->specs, 
> pss->tokens);
> +
> +   static uint32_t id;

A matter of personal taste, but I would prefer this static variable to
be outside of the function. Makes it easier to grok that it is external
state and stable across function calls.

> +   shader->id = id++;
> +
> +   dump_shader_info(shader, &ctx->debug);
>  
> -   return etna_compile_shader(&ctx->specs, pss->tokens);
> +   return shader;
>  }
>  
>  static void


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


Re: [Mesa-dev] [PATCH 1/3] etnaviv: wire up core pipe_debug_callback

2017-02-08 Thread Lucas Stach
Am Mittwoch, den 08.02.2017, 12:10 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.c | 13 +
>  src/gallium/drivers/etnaviv/etnaviv_context.h |  2 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
> b/src/gallium/drivers/etnaviv/etnaviv_context.c
> index d767cd1..ce2d871 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> @@ -246,6 +246,18 @@ etna_cmd_stream_reset_notify(struct etna_cmd_stream 
> *stream, void *priv)
> assert(LIST_IS_EMPTY(&ctx->used_resources));
>  }
>  
> +static void
> +etna_set_debug_callback(struct pipe_context *pctx,
> +const struct pipe_debug_callback *cb)
> +{
> +   struct etna_context *ctx = etna_context(pctx);
> +
> +   if (cb)
> +  ctx->debug = *cb;
> +   else
> +  memset(&ctx->debug, 0, sizeof(ctx->debug));
> +}
> +
>  struct pipe_context *
>  etna_context_create(struct pipe_screen *pscreen, void *priv, unsigned flags)
>  {
> @@ -279,6 +291,7 @@ etna_context_create(struct pipe_screen *pscreen, void 
> *priv, unsigned flags)
> pctx->destroy = etna_context_destroy;
> pctx->draw_vbo = etna_draw_vbo;
> pctx->flush = etna_flush;
> +   pctx->set_debug_callback = etna_set_debug_callback;
>  
> /* creation of compile states */
> pctx->create_blend_state = etna_blend_state_create;
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
> b/src/gallium/drivers/etnaviv/etnaviv_context.h
> index 74e93e1..a921403 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
> @@ -174,6 +174,8 @@ struct etna_context {
>uint64_t prims_emitted;
>uint64_t draw_calls;
> } stats;
> +
> +   struct pipe_debug_callback debug;
>  };
>  
>  static inline struct etna_context *


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


Re: [Mesa-dev] [PATCH 3/3] etnaviv: shader-db traces

2017-02-09 Thread Lucas Stach
Am Mittwoch, den 08.02.2017, 20:47 +0100 schrieb Christian Gmeiner:
> Hi Lucas,
> 
> 2017-02-08 12:36 GMT+01:00 Lucas Stach :
> > Am Mittwoch, den 08.02.2017, 12:10 +0100 schrieb Christian Gmeiner:
> >> Signed-off-by: Christian Gmeiner 
> >> ---
> >>  src/gallium/drivers/etnaviv/etnaviv_compiler.h |  2 ++
> >>  src/gallium/drivers/etnaviv/etnaviv_debug.h|  1 +
> >>  src/gallium/drivers/etnaviv/etnaviv_screen.c   |  1 +
> >>  src/gallium/drivers/etnaviv/etnaviv_shader.c   | 44 
> >> +-
> >>  4 files changed, 47 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.h 
> >> b/src/gallium/drivers/etnaviv/etnaviv_compiler.h
> >> index 211ae1a..de3e20d 100644
> >> --- a/src/gallium/drivers/etnaviv/etnaviv_compiler.h
> >> +++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.h
> >> @@ -56,6 +56,8 @@ struct etna_shader_io_file {
> >>
> >>  /* shader object, for linking */
> >>  struct etna_shader {
> >> +   uint32_t id; /* for debug */
> >
> > Do you need this? It can certainly be removed from this patch, but I
> > don't know if you have other stuff building on top of this.
> >
> 
> It gets used in dump_shader_info(..) which was added with this patch.

My argument was that you could pass that value as an argument to
dump_shader_info(). I don't see why it needs to be stored inside the
etna_shader object.

> 
> >> uint processor; /* TGSI_PROCESSOR_... */
> >> uint32_t code_size; /* code size in uint32 words */
> >> uint32_t *code;
> >> diff --git a/src/gallium/drivers/etnaviv/etnaviv_debug.h 
> >> b/src/gallium/drivers/etnaviv/etnaviv_debug.h
> >> index cfda52b..f47dffe 100644
> >> --- a/src/gallium/drivers/etnaviv/etnaviv_debug.h
> >> +++ b/src/gallium/drivers/etnaviv/etnaviv_debug.h
> >> @@ -51,6 +51,7 @@
> >>  #define ETNA_DBG_FLUSH_ALL   0x10 /* Flush after every rendered 
> >> primitive */
> >>  #define ETNA_DBG_ZERO0x20 /* Zero all resources after 
> >> allocation */
> >>  #define ETNA_DBG_DRAW_STALL  0x40 /* Stall FE/PE after every draw 
> >> op */
> >> +#define ETNA_DBG_SHADERDB0x80 /* dump program compile 
> >> information */
> >>
> >>  extern int etna_mesa_debug; /* set in etna_screen.c from ETNA_DEBUG */
> >>
> >> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> >> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> >> index 8f2882f..6272f6f 100644
> >> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> >> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> >> @@ -62,6 +62,7 @@ static const struct debug_named_value debug_options[] = {
> >> {"flush_all",  ETNA_DBG_FLUSH_ALL, "Flush after every rendered 
> >> primitive"},
> >> {"zero",   ETNA_DBG_ZERO, "Zero all resources after 
> >> allocation"},
> >> {"draw_stall", ETNA_DBG_DRAW_STALL, "Stall FE/PE after each 
> >> rendered primitive"},
> >> +   {"shaderdb",   ETNA_DBG_SHADERDB, "Enable shaderdb output"},
> >> DEBUG_NAMED_VALUE_END
> >>  };
> >>
> >> diff --git a/src/gallium/drivers/etnaviv/etnaviv_shader.c 
> >> b/src/gallium/drivers/etnaviv/etnaviv_shader.c
> >> index 8895311..87edf5b 100644
> >> --- a/src/gallium/drivers/etnaviv/etnaviv_shader.c
> >> +++ b/src/gallium/drivers/etnaviv/etnaviv_shader.c
> >> @@ -223,6 +223,42 @@ etna_shader_update_vs_inputs(struct etna_context *ctx,
> >> return true;
> >>  }
> >>
> >> +static inline const char *
> >> +etna_shader_stage(struct etna_shader *shader)
> >> +{
> >> +   switch (shader->processor) {
> >> +   case PIPE_SHADER_VERTEX: return "VERT";
> >> +   case PIPE_SHADER_FRAGMENT:   return "FRAG";
> >> +   case PIPE_SHADER_COMPUTE:return "CL";
> >> +   default:
> >> +  unreachable("invalid type");
> >> +  return NULL;
> >> +   }
> >> +}
> >> +
> >> +static void
> >> +dump_shader_info(struct etna_shader *shader, struct pipe_debug_callback 
> >> *debug)
> >> +{
> >> +   if (!unlikely(etna_mesa_debug & ETNA_DBG_SHADERDB))
> >> +  return;
> >> +
> >> +   pipe_debug_message(debug, SHADER_INF

[Mesa-dev] [PATCH] gbm: request correct version of the DRI2_FENCE extension

2016-11-22 Thread Lucas Stach
There is no version 2 of the DRI2_FENCE extension. So only a request
for version 1 has a chance to succeed.

Fixes: 74b1969d717f (gbm: wire up fence extension)
Cc: "13.0" 
Signed-off-by: Lucas Stach 
---
 src/gbm/backends/dri/gbm_dri.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index e9b104e13aca..676abce37d1c 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -245,7 +245,7 @@ struct dri_extension_match {
 static struct dri_extension_match dri_core_extensions[] = {
{ __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
{ __DRI_IMAGE, 1, offsetof(struct gbm_dri_device, image) },
-   { __DRI2_FENCE, 2, offsetof(struct gbm_dri_device, fence), 1 },
+   { __DRI2_FENCE, 1, offsetof(struct gbm_dri_device, fence), 1 },
{ NULL, 0, 0 }
 };
 
-- 
2.10.2

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


[Mesa-dev] [PATCH 6/6] st/egl: fix drm surface size init

2013-11-06 Thread Lucas Stach
Signed-off-by: Lucas Stach 
---
 src/gallium/state_trackers/egl/drm/modeset.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/egl/drm/modeset.c 
b/src/gallium/state_trackers/egl/drm/modeset.c
index dc71a761053b..11b6db1949c6 100644
--- a/src/gallium/state_trackers/egl/drm/modeset.c
+++ b/src/gallium/state_trackers/egl/drm/modeset.c
@@ -311,7 +311,8 @@ drm_display_create_surface_from_resource(struct 
native_display *ndpy,
  PIPE_BIND_SAMPLER_VIEW |
  PIPE_BIND_DISPLAY_TARGET |
  PIPE_BIND_SCANOUT);
-   
+
+   resource_surface_set_size(drmsurf->rsurf, drmsurf->width, drmsurf->height);
resource_surface_import_resource(drmsurf->rsurf, natt, resource);
 
drmsurf->base.destroy = drm_surface_destroy;
-- 
1.8.4.rc3

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


[Mesa-dev] [PATCH 2/6] gallium/targets: build freedreno pipe

2013-11-06 Thread Lucas Stach
Signed-off-by: Lucas Stach 
---
 src/gallium/targets/pipe-loader/Makefile.am  | 16 
 src/gallium/targets/pipe-loader/pipe_freedreno.c | 21 +
 2 files changed, 37 insertions(+)
 create mode 100644 src/gallium/targets/pipe-loader/pipe_freedreno.c

diff --git a/src/gallium/targets/pipe-loader/Makefile.am 
b/src/gallium/targets/pipe-loader/Makefile.am
index e6772b8e3083..234da336a8f8 100644
--- a/src/gallium/targets/pipe-loader/Makefile.am
+++ b/src/gallium/targets/pipe-loader/Makefile.am
@@ -45,6 +45,22 @@ PIPE_LIBS = \
-lpthread \
-lm
 
+if HAVE_GALLIUM_FREEDRENO
+pipe_LTLIBRARIES += pipe_freedreno.la
+pipe_freedreno_la_SOURCES = pipe_freedreno.c
+nodist_EXTRA_pipe_freedreno_la_SOURCES = dummy.cpp
+pipe_freedreno_la_LIBADD = \
+   $(PIPE_LIBS) \
+   $(top_builddir)/src/gallium/winsys/freedreno/drm/libfreedrenodrm.la \
+   $(top_builddir)/src/gallium/drivers/freedreno/libfreedreno.la \
+   $(FREEDRENO_LIBS)
+pipe_freedreno_la_LDFLAGS = -no-undefined -avoid-version -module
+if HAVE_MESA_LLVM
+pipe_freedreno_la_LIBADD += $(LLVM_LIBS)
+pipe_freedreno_la_LDFLAGS += $(LLVM_LDFLAGS)
+endif
+endif
+
 if HAVE_GALLIUM_I915
 pipe_LTLIBRARIES += pipe_i915.la
 pipe_i915_la_SOURCES = pipe_i915.c
diff --git a/src/gallium/targets/pipe-loader/pipe_freedreno.c 
b/src/gallium/targets/pipe-loader/pipe_freedreno.c
new file mode 100644
index ..72d24ba4428b
--- /dev/null
+++ b/src/gallium/targets/pipe-loader/pipe_freedreno.c
@@ -0,0 +1,21 @@
+
+#include "target-helpers/inline_debug_helper.h"
+#include "state_tracker/drm_driver.h"
+#include "freedreno/drm/freedreno_drm_public.h"
+
+static struct pipe_screen *
+create_screen(int fd)
+{
+   struct pipe_screen *screen;
+
+   screen = fd_drm_screen_create(fd);
+   if (!screen)
+  return NULL;
+
+   screen = debug_screen_wrap(screen);
+
+   return screen;
+}
+
+PUBLIC
+DRM_DRIVER_DESCRIPTOR("freedreno", "freedreno", create_screen, NULL)
-- 
1.8.4.rc3

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


[Mesa-dev] [PATCH 3/6] gallium: pipe-loader: make aware of platform DRM devices

2013-11-06 Thread Lucas Stach
Allows to load gallium pipes for ARM DRM drivers.

Signed-off-by: Lucas Stach 
---
 include/platform_ids/platform_driver_map.h | 18 
 src/gallium/auxiliary/pipe-loader/pipe_loader.h|  1 +
 .../auxiliary/pipe-loader/pipe_loader_drm.c| 53 ++
 3 files changed, 62 insertions(+), 10 deletions(-)
 create mode 100644 include/platform_ids/platform_driver_map.h

diff --git a/include/platform_ids/platform_driver_map.h 
b/include/platform_ids/platform_driver_map.h
new file mode 100644
index ..c428b81349e6
--- /dev/null
+++ b/include/platform_ids/platform_driver_map.h
@@ -0,0 +1,18 @@
+#ifndef _PLATFORM_DRIVER_MAP_H_
+#define _PLATFORM_DRIVER_MAP_H_
+
+#include 
+
+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
+#endif
+
+static const struct {
+   const char *driver;
+   const char **platform_ids;
+   int num_platform_ids;
+} platform_driver_map[] = {
+   { NULL, NULL, 0 }
+};
+
+#endif /* _PLATFORM_DRIVER_MAP_H_ */
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h 
b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
index 444bdf1751f9..e915c6380185 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
@@ -44,6 +44,7 @@ struct pipe_screen;
 enum pipe_loader_device_type {
PIPE_LOADER_DEVICE_SOFTWARE,
PIPE_LOADER_DEVICE_PCI,
+   PIPE_LOADER_DEVICE_PLATFORM,
NUM_PIPE_LOADER_DEVICE_TYPES
 };
 
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
index 339d7bf10b67..908beac24cb4 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
@@ -50,6 +50,7 @@
 
 #define DRIVER_MAP_GALLIUM_ONLY
 #include "pci_ids/pci_id_driver_map.h"
+#include "platform_ids/platform_driver_map.h"
 
 struct pipe_loader_drm_device {
struct pipe_loader_device base;
@@ -88,6 +89,7 @@ find_drm_pci_id(struct pipe_loader_drm_device *ddev)
   &ddev->base.u.pci.chip_id) != 2)
   goto fail;
 
+   ddev->base.type = PIPE_LOADER_DEVICE_PCI;
return TRUE;
 
   fail:
@@ -100,7 +102,7 @@ find_drm_pci_id(struct pipe_loader_drm_device *ddev)
 }
 
 static boolean
-find_drm_driver_name(struct pipe_loader_drm_device *ddev)
+find_drm_pci_driver_name(struct pipe_loader_drm_device *ddev)
 {
struct pipe_loader_device *dev = &ddev->base;
int i, j;
@@ -128,6 +130,36 @@ find_drm_driver_name(struct pipe_loader_drm_device *ddev)
return TRUE;
 }
 
+static boolean
+find_drm_platform_driver(struct pipe_loader_drm_device *ddev)
+{
+   char *driver = NULL;
+   drmVersionPtr version;
+   int i, j;
+
+   version = drmGetVersion(ddev->fd);
+   if (!version)
+  return FALSE;
+
+   driver = strndup(version->name, version->name_len);
+   drmFreeVersion(version);
+
+   for (i = 0; platform_driver_map[i].driver; i++) {
+  for (j = 0; j < platform_driver_map[i].num_platform_ids; j++) {
+ if (strcmp(driver, platform_driver_map[i].platform_ids[j]) == 0) {
+ddev->base.driver_name = platform_driver_map[i].driver;
+ddev->base.type = PIPE_LOADER_DEVICE_PLATFORM;
+
+free(driver);
+return TRUE;
+ }
+  }
+   }
+
+   free(driver);
+   return FALSE;
+}
+
 static struct pipe_loader_ops pipe_loader_drm_ops;
 
 static void
@@ -188,22 +220,23 @@ pipe_loader_drm_probe_fd(struct pipe_loader_device **dev, 
int fd)
 {
struct pipe_loader_drm_device *ddev = CALLOC_STRUCT(pipe_loader_drm_device);
 
-   ddev->base.type = PIPE_LOADER_DEVICE_PCI;
ddev->base.ops = &pipe_loader_drm_ops;
ddev->fd = fd;
 
pipe_loader_drm_x_auth(fd);
 
-   if (!find_drm_pci_id(ddev))
-  goto fail;
-
-   if (!find_drm_driver_name(ddev))
-  goto fail;
+   if (find_drm_pci_id(ddev)) {
+  if (find_drm_pci_driver_name(ddev)) {
+  *dev = &ddev->base;
+  return TRUE;
+  }
+   }
 
-   *dev = &ddev->base;
-   return TRUE;
+   if (find_drm_platform_driver(ddev)) {
+  *dev = &ddev->base;
+  return TRUE;
+   }
 
-  fail:
FREE(ddev);
return FALSE;
 }
-- 
1.8.4.rc3

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


[Mesa-dev] [PATCH 5/6] gallium: gbm/egl: support GBM surface extensions on DRM

2013-11-06 Thread Lucas Stach
Let's applications like Weston create EGL onscreen-surfaces
on bare DRM devices.

Signed-off-by: Lucas Stach 
---
 src/gallium/state_trackers/egl/drm/native_drm.c| 11 ++
 src/gallium/state_trackers/gbm/gbm_drm.c   | 44 ++
 .../state_trackers/gbm/gbm_gallium_drmint.h| 12 ++
 3 files changed, 67 insertions(+)

diff --git a/src/gallium/state_trackers/egl/drm/native_drm.c 
b/src/gallium/state_trackers/egl/drm/native_drm.c
index c82bbe4d7417..10a77603d2aa 100644
--- a/src/gallium/state_trackers/egl/drm/native_drm.c
+++ b/src/gallium/state_trackers/egl/drm/native_drm.c
@@ -83,6 +83,7 @@ drm_display_get_configs(struct native_display *ndpy, int 
*num_configs)
   }
 
   nconf->color_format = format;
+  nconf->window_bit = TRUE;
 
   /* support KMS */
   if (drmdpy->resources)
@@ -211,6 +212,15 @@ drm_create_pixmap_surface(struct native_display *ndpy,
return drm_display_create_surface_from_resource(ndpy, bo->resource);
 }
 
+static struct native_surface *
+drm_create_window_surface(struct native_display *ndpy,
+EGLNativeWindowType win,
+const struct native_config *nconf)
+{
+   struct gbm_gallium_drm_surface *surf = (void *) win;
+   return drm_display_create_surface_from_resource(ndpy, surf->bo->resource);
+}
+
 static boolean
 drm_display_init_screen(struct native_display *ndpy)
 {
@@ -246,6 +256,7 @@ drm_create_display(struct gbm_gallium_drm_device *gbmdrm, 
int own_gbm,
drmdpy->base.get_configs = drm_display_get_configs;
 
drmdpy->base.create_pixmap_surface = drm_create_pixmap_surface;
+   drmdpy->base.create_window_surface = drm_create_window_surface;
 
drmdpy->base.buffer = &drm_display_buffer;
 #ifdef HAVE_WAYLAND_BACKEND
diff --git a/src/gallium/state_trackers/gbm/gbm_drm.c 
b/src/gallium/state_trackers/gbm/gbm_drm.c
index 725f12f6dad5..ad1c4a5c5639 100644
--- a/src/gallium/state_trackers/gbm/gbm_drm.c
+++ b/src/gallium/state_trackers/gbm/gbm_drm.c
@@ -218,6 +218,47 @@ gbm_gallium_drm_bo_create(struct gbm_device *gbm,
return &bo->base.base;
 }
 
+static struct gbm_surface *
+gbm_gallium_drm_surface_create(struct gbm_device *gbm,
+   uint32_t width, uint32_t height,
+   uint32_t format, uint32_t flags)
+{
+   struct gbm_gallium_drm_surface *surf;
+
+   surf = calloc(1, sizeof *surf);
+   if (surf == NULL)
+  return NULL;
+
+   surf->base.gbm = gbm;
+   surf->base.width = width;
+   surf->base.height = height;
+   surf->base.format = format;
+   surf->base.flags = flags;
+
+   surf->bo = gbm_gallium_drm_bo_create(gbm, width, height, format,
+GBM_BO_USE_RENDERING);
+
+   return &surf->base;
+}
+
+static void
+gbm_gallium_drm_surface_destroy(struct gbm_surface *_surf)
+{
+   struct gbm_gallium_drm_surface *surf = gbm_gallium_drm_surface(_surf);
+
+   gbm_gallium_drm_bo_destroy(&surf->bo->base.base);
+
+   free(surf);
+}
+
+static struct gbm_bo *
+gbm_gallium_drm_lock_front_buffer(struct gbm_surface *_surf)
+{
+   struct gbm_gallium_drm_surface *surf = gbm_gallium_drm_surface(_surf);
+
+   return surf->bo;
+}
+
 static void
 gbm_gallium_drm_destroy(struct gbm_device *gbm)
 {
@@ -240,6 +281,9 @@ gbm_gallium_drm_device_create(int fd)
gdrm->base.base.bo_import = gbm_gallium_drm_bo_import;
gdrm->base.base.bo_destroy = gbm_gallium_drm_bo_destroy;
gdrm->base.base.is_format_supported = gbm_gallium_drm_is_format_supported;
+   gdrm->base.base.surface_create = gbm_gallium_drm_surface_create;
+   gdrm->base.base.surface_destroy = gbm_gallium_drm_surface_destroy;
+   gdrm->base.base.surface_lock_front_buffer = 
gbm_gallium_drm_lock_front_buffer;
gdrm->base.base.destroy = gbm_gallium_drm_destroy;
 
gdrm->base.type = GBM_DRM_DRIVER_TYPE_GALLIUM;
diff --git a/src/gallium/state_trackers/gbm/gbm_gallium_drmint.h 
b/src/gallium/state_trackers/gbm/gbm_gallium_drmint.h
index a5d6d834737b..e873e9174d45 100644
--- a/src/gallium/state_trackers/gbm/gbm_gallium_drmint.h
+++ b/src/gallium/state_trackers/gbm/gbm_gallium_drmint.h
@@ -53,6 +53,12 @@ struct gbm_gallium_drm_bo {
struct pipe_resource *resource;
 };
 
+struct gbm_gallium_drm_surface {
+   struct gbm_surface base;
+
+   struct gbm_gallium_drm_bo *bo;
+};
+
 static inline struct gbm_gallium_drm_device *
 gbm_gallium_drm_device(struct gbm_device *gbm)
 {
@@ -65,6 +71,12 @@ gbm_gallium_drm_bo(struct gbm_bo *bo)
return (struct gbm_gallium_drm_bo *) bo;
 }
 
+static inline struct gbm_gallium_drm_surface *
+gbm_gallium_drm_surface(struct gbm_surface *surface)
+{
+   return (struct gbm_gallium_drm_surface *) surface;
+}
+
 struct gbm_device *
 gbm_gallium_drm_device_create(int fd);
 
-- 
1.8.4.rc3

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


[Mesa-dev] [PATCH 4/6] pipe-loader: add freedreno platform IDs

2013-11-06 Thread Lucas Stach
Signed-off-by: Lucas Stach 
---
 include/platform_ids/platform_driver_map.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/platform_ids/platform_driver_map.h 
b/include/platform_ids/platform_driver_map.h
index c428b81349e6..68595ef0a2f7 100644
--- a/include/platform_ids/platform_driver_map.h
+++ b/include/platform_ids/platform_driver_map.h
@@ -7,11 +7,16 @@
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
 #endif
 
+static const char *freedreno_platform_ids[] = {
+   "msm",
+};
+
 static const struct {
const char *driver;
const char **platform_ids;
int num_platform_ids;
 } platform_driver_map[] = {
+   { "freedreno", freedreno_platform_ids, ARRAY_SIZE(freedreno_platform_ids)},
{ NULL, NULL, 0 }
 };
 
-- 
1.8.4.rc3

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


[Mesa-dev] [PATCH 1/6] gbm: Support non-PCI devices

2013-11-06 Thread Lucas Stach
From: Thierry Reding 

When probing non-PCI DRM devices, such as those found in a lot of SoCs,
GBM errors out because it expects the device to have an associated PCI
ID which can be used to lookup the driver name in a table.

This patch removes this restriction by using the driver name from the
drmVersion structure as a fallback if a device doesn't have an
associated PCI ID.

Signed-off-by: Thierry Reding 
Tested-by: Rob Clark 
---
 src/gbm/backends/dri/driver_name.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/src/gbm/backends/dri/driver_name.c 
b/src/gbm/backends/dri/driver_name.c
index 2ed209fa438b..be74023d6c3a 100644
--- a/src/gbm/backends/dri/driver_name.c
+++ b/src/gbm/backends/dri/driver_name.c
@@ -30,6 +30,7 @@
 #include 
 
 #include 
+#include 
 
 #include "gbm_driint.h"
 #define DRIVER_MAP_DRI2_ONLY
@@ -43,6 +44,7 @@ dri_fd_get_driver_name(int fd)
const char *pci_id;
char *driver = NULL;
int vendor_id, chip_id, i, j;
+   drmVersionPtr version;
 
udev = udev_new();
device = _gbm_udev_device_new_from_fd(udev, fd);
@@ -56,9 +58,22 @@ dri_fd_get_driver_name(int fd)
}
 
pci_id = udev_device_get_property_value(parent, "PCI_ID");
-   if (pci_id == NULL ||
-   sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
-  fprintf(stderr, "gbm: malformed or no PCI ID");
+   if (pci_id == NULL) {
+  version = drmGetVersion(fd);
+  if (!version) {
+ fprintf(stderr, "gbm: cannot get DRM module version\n");
+ goto out;
+  }
+
+  driver = strndup(version->name, version->name_len);
+  _gbm_log("using driver %s for %d\n", driver, fd);
+
+  drmFreeVersion(version);
+  goto out;
+   }
+
+   if (sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
+  fprintf(stderr, "gbm: malformed PCI ID");
   goto out;
}
 
-- 
1.8.4.rc3

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


Re: [Mesa-dev] [PATCH 3/3] st/xorg: Delete.

2013-11-07 Thread Lucas Stach
Am Mittwoch, den 06.11.2013, 21:52 -0800 schrieb Matt Turner:
> ---
> Deleted files diff removed.
> 
I think there was some nice stuff in here that didn't make it into XA,
but that's no valid reason to keep st/xorg alive in the tree.

If someone is interested in porting things to XA, it's just some git
history digging.

So,
Acked-by: Lucas Stach 

>  configure.ac |   56 +-
>  src/gallium/SConscript   |3 -
>  src/gallium/state_trackers/Makefile.am   |4 -
>  src/gallium/state_trackers/xorg/Makefile.am  |   43 -
>  src/gallium/state_trackers/xorg/Makefile.sources |   11 -
>  src/gallium/state_trackers/xorg/SConscript   |   29 -
>  src/gallium/state_trackers/xorg/compat-api.h |   99 --
>  src/gallium/state_trackers/xorg/xorg_composite.c |  585 --
>  src/gallium/state_trackers/xorg/xorg_composite.h |   36 -
>  src/gallium/state_trackers/xorg/xorg_crtc.c  |  448 
>  src/gallium/state_trackers/xorg/xorg_dri2.c  |  473 
>  src/gallium/state_trackers/xorg/xorg_driver.c| 1323 
> --
>  src/gallium/state_trackers/xorg/xorg_exa.c   | 1087 --
>  src/gallium/state_trackers/xorg/xorg_exa.h   |   76 --
>  src/gallium/state_trackers/xorg/xorg_exa_tgsi.c  |  690 ---
>  src/gallium/state_trackers/xorg/xorg_exa_tgsi.h  |   59 -
>  src/gallium/state_trackers/xorg/xorg_output.c|  331 --
>  src/gallium/state_trackers/xorg/xorg_renderer.c  |  547 -
>  src/gallium/state_trackers/xorg/xorg_renderer.h  |   81 --
>  src/gallium/state_trackers/xorg/xorg_tracker.h   |  236 
>  src/gallium/state_trackers/xorg/xorg_winsys.h|   50 -
>  src/gallium/state_trackers/xorg/xorg_xv.c|  750 
>  src/gallium/state_trackers/xorg/xorg_xvmc.c  |  119 --
>  23 files changed, 11 insertions(+), 7125 deletions(-)
>  delete mode 100644 src/gallium/state_trackers/xorg/Makefile.am
>  delete mode 100644 src/gallium/state_trackers/xorg/Makefile.sources
>  delete mode 100644 src/gallium/state_trackers/xorg/SConscript
>  delete mode 100644 src/gallium/state_trackers/xorg/compat-api.h
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_composite.c
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_composite.h
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_crtc.c
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_dri2.c
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_driver.c
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_exa.c
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_exa.h
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_exa_tgsi.c
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_exa_tgsi.h
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_output.c
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_renderer.c
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_renderer.h
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_tracker.h
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_winsys.h
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_xv.c
>  delete mode 100644 src/gallium/state_trackers/xorg/xorg_xvmc.c
> 
> diff --git a/configure.ac b/configure.ac
> index 6caa125..28faf24 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -35,8 +35,6 @@ LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
>  LIBDRM_FREEDRENO_REQUIRED=2.4.39
>  DRI2PROTO_REQUIRED=2.6
>  GLPROTO_REQUIRED=1.4.14
> -LIBDRM_XORG_REQUIRED=2.4.24
> -LIBKMS_XORG_REQUIRED=1.0.0
>  
>  dnl Check for progs
>  AC_PROG_CPP
> @@ -556,11 +554,6 @@ AC_ARG_ENABLE([egl],
>  [enable_egl="$enableval"],
>  [enable_egl=yes])
>  
> -AC_ARG_ENABLE([xorg],
> -[AS_HELP_STRING([--enable-xorg],
> -[enable support for X.Org DDX API @<:@default=no@:>@])],
> -[enable_xorg="$enableval"],
> -[enable_xorg=no])
>  AC_ARG_ENABLE([xa],
>  [AS_HELP_STRING([--enable-xa],
>  [enable build of the XA X Acceleration API @<:@default=no@:>@])],
> @@ -651,7 +644,6 @@ if test "x$enable_opengl" = xno -a \
>  "x$enable_gles1" = xno -a \
>  "x$enable_gles2" = xno -a \
>  "x$enable_openvg" = xno -a \
> -"x$enable_xorg" = xno -a \
>  "x$enable_xa" = xno -a \
>  "x$enable_xvmc" = xno -a \
>  "x$enable_vdpau" = xno -a \
> @@ -1236,20 +1228,6 @@ fi
>  AM_CONDITIONAL(HAVE_GALLIUM_GBM, test "x$enable_gallium_gbm" = xyes)
>  
>  dnl
> -dnl X.Org DDX configuration
> -d

Re: [Mesa-dev] [PATCH 2/4] nv50: implement new float comparison instructions

2013-08-28 Thread Lucas Stach
Am Dienstag, den 13.08.2013, 20:14 +0200 schrieb Christoph Bumiller:
> On 13.08.2013 19:04, srol...@vmware.com wrote:
> > From: Roland Scheidegger 
> >
> > untested.
> 
> Looks like it should work though, thanks.
> nv50 only supported u32 result all along and on nvc0 both cases are
> already handled by the rest of the code, too.
> 
This commit beaks Xonotic on NV92 for me. Dmesg has a lot of those:
TRAP_MP_EXEC - TP 0 MP 0: TIMEOUT at 07fed0 warp 20, opcode 90001204 82051008

> > ---
> >  .../drivers/nv50/codegen/nv50_ir_from_tgsi.cpp |   17 +
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/src/gallium/drivers/nv50/codegen/nv50_ir_from_tgsi.cpp 
> > b/src/gallium/drivers/nv50/codegen/nv50_ir_from_tgsi.cpp
> > index 56eccac..a2ad9f4 100644
> > --- a/src/gallium/drivers/nv50/codegen/nv50_ir_from_tgsi.cpp
> > +++ b/src/gallium/drivers/nv50/codegen/nv50_ir_from_tgsi.cpp
> > @@ -440,6 +440,11 @@ nv50_ir::DataType Instruction::inferDstType() const
> > switch (getOpcode()) {
> > case TGSI_OPCODE_F2U: return nv50_ir::TYPE_U32;
> > case TGSI_OPCODE_F2I: return nv50_ir::TYPE_S32;
> > +   case TGSI_OPCODE_FSEQ:
> > +   case TGSI_OPCODE_FSGE:
> > +   case TGSI_OPCODE_FSLT:
> > +   case TGSI_OPCODE_FSNE:
> > +  return nv50_ir::TYPE_U32;
> > case TGSI_OPCODE_I2F:
> > case TGSI_OPCODE_U2F:
> >return nv50_ir::TYPE_F32;
> > @@ -456,19 +461,23 @@ nv50_ir::CondCode Instruction::getSetCond() const
> > case TGSI_OPCODE_SLT:
> > case TGSI_OPCODE_ISLT:
> > case TGSI_OPCODE_USLT:
> > +   case TGSI_OPCODE_FSLT:
> >return CC_LT;
> > case TGSI_OPCODE_SLE:
> >return CC_LE;
> > case TGSI_OPCODE_SGE:
> > case TGSI_OPCODE_ISGE:
> > case TGSI_OPCODE_USGE:
> > +   case TGSI_OPCODE_FSGE:
> >return CC_GE;
> > case TGSI_OPCODE_SGT:
> >return CC_GT;
> > case TGSI_OPCODE_SEQ:
> > case TGSI_OPCODE_USEQ:
> > +   case TGSI_OPCODE_FSEQ:
> >return CC_EQ;
> > case TGSI_OPCODE_SNE:
> > +   case TGSI_OPCODE_FSNE:
> >return CC_NEU;
> > case TGSI_OPCODE_USNE:
> >return CC_NE;
> > @@ -556,6 +565,10 @@ static nv50_ir::operation translateOpcode(uint opcode)
> > NV50_IR_OPCODE_CASE(KILL_IF, DISCARD);
> >  
> > NV50_IR_OPCODE_CASE(F2I, CVT);
> > +   NV50_IR_OPCODE_CASE(FSEQ, SET);
> > +   NV50_IR_OPCODE_CASE(FSGE, SET);
> > +   NV50_IR_OPCODE_CASE(FSLT, SET);
> > +   NV50_IR_OPCODE_CASE(FSNE, SET);
> > NV50_IR_OPCODE_CASE(IDIV, DIV);
> > NV50_IR_OPCODE_CASE(IMAX, MAX);
> > NV50_IR_OPCODE_CASE(IMIN, MIN);
> > @@ -2354,6 +2367,10 @@ Converter::handleInstruction(const struct 
> > tgsi_full_instruction *insn)
> > case TGSI_OPCODE_SLE:
> > case TGSI_OPCODE_SNE:
> > case TGSI_OPCODE_STR:
> > +   case TGSI_OPCODE_FSEQ:
> > +   case TGSI_OPCODE_FSGE:
> > +   case TGSI_OPCODE_FSLT:
> > +   case TGSI_OPCODE_FSNE:
> > case TGSI_OPCODE_ISGE:
> > case TGSI_OPCODE_ISLT:
> > case TGSI_OPCODE_USEQ:
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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


[Mesa-dev] [PATCH libdrm] modeprint: pretty print connector names

2014-01-17 Thread Lucas Stach
Use same names as the kernel, makes it easier to identify
connectors in the common case.

Signed-off-by: Lucas Stach 
---
 tests/modeprint/modeprint.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 545ff40a98d4..6f0d03905a46 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -41,6 +41,8 @@
 #include "xf86drm.h"
 #include "xf86drmMode.h"
 
+#define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
+
 int connectors;
 int full_props;
 int edid;
@@ -140,13 +142,37 @@ int printProperty(int fd, drmModeResPtr res, 
drmModePropertyPtr props, uint64_t
return 0;
 }
 
+static const char * const output_names[] = { "None",
+"VGA",
+"DVI-I",
+"DVI-D",
+"DVI-A",
+"Composite",
+"SVIDEO",
+"LVDS",
+"Component",
+"DIN",
+"DP",
+"HDMI-A",
+"HDMI-B",
+"TV",
+"eDP",
+"Virtual",
+"DSI",
+};
+
 int printConnector(int fd, drmModeResPtr res, drmModeConnectorPtr connector, 
uint32_t id)
 {
int i = 0;
struct drm_mode_modeinfo *mode = NULL;
drmModePropertyPtr props;
 
-   printf("Connector: %d-%d\n", connector->connector_type, 
connector->connector_type_id);
+   if (connector->connector_type < ARRAY_SIZE(output_names))
+   printf("Connector: %s-%d\n", 
output_names[connector->connector_type],
+   connector->connector_type_id);
+   else
+   printf("Connector: %d-%d\n", connector->connector_type,
+   connector->connector_type_id);
printf("\tid : %i\n", id);
printf("\tencoder id : %i\n", connector->encoder_id);
printf("\tconn   : %s\n", 
getConnectionText(connector->connection));
-- 
1.8.5.2

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


Re: [Mesa-dev] [PATCH libdrm] modeprint: pretty print connector names

2014-01-24 Thread Lucas Stach
Ping.

Can someone please take a look and if there are no objections commit
this for me? I don't have commit access myself.

Am Freitag, den 17.01.2014, 12:19 +0100 schrieb Lucas Stach:
> Use same names as the kernel, makes it easier to identify
> connectors in the common case.
> 
> Signed-off-by: Lucas Stach 
> ---
>  tests/modeprint/modeprint.c | 28 +++-
>  1 file changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
> index 545ff40a98d4..6f0d03905a46 100644
> --- a/tests/modeprint/modeprint.c
> +++ b/tests/modeprint/modeprint.c
> @@ -41,6 +41,8 @@
>  #include "xf86drm.h"
>  #include "xf86drmMode.h"
>  
> +#define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
> +
>  int connectors;
>  int full_props;
>  int edid;
> @@ -140,13 +142,37 @@ int printProperty(int fd, drmModeResPtr res, 
> drmModePropertyPtr props, uint64_t
>   return 0;
>  }
>  
> +static const char * const output_names[] = { "None",
> +  "VGA",
> +  "DVI-I",
> +  "DVI-D",
> +  "DVI-A",
> +  "Composite",
> +  "SVIDEO",
> +  "LVDS",
> +  "Component",
> +  "DIN",
> +  "DP",
> +  "HDMI-A",
> +  "HDMI-B",
> +  "TV",
> +  "eDP",
> +  "Virtual",
> +  "DSI",
> +};
> +
>  int printConnector(int fd, drmModeResPtr res, drmModeConnectorPtr connector, 
> uint32_t id)
>  {
>   int i = 0;
>   struct drm_mode_modeinfo *mode = NULL;
>   drmModePropertyPtr props;
>  
> - printf("Connector: %d-%d\n", connector->connector_type, 
> connector->connector_type_id);
> + if (connector->connector_type < ARRAY_SIZE(output_names))
> + printf("Connector: %s-%d\n", 
> output_names[connector->connector_type],
> + connector->connector_type_id);
> + else
> + printf("Connector: %d-%d\n", connector->connector_type,
> + connector->connector_type_id);
>   printf("\tid : %i\n", id);
>   printf("\tencoder id : %i\n", connector->encoder_id);
>   printf("\tconn   : %s\n", 
> getConnectionText(connector->connection));

-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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


Re: [Mesa-dev] [PATCH v4] etnaviv: fix resource usage tracking across different pipe_context's

2019-01-14 Thread Lucas Stach
Hi Marek,

Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut:
> > From: Christian Gmeiner 
> 
> A pipe_resource can be shared by all the pipe_context's hanging off the
> same pipe_screen.
> 
> > Signed-off-by: Christian Gmeiner 
> > Signed-off-by: Marek Vasut 
> To: mesa-dev@lists.freedesktop.org
> Cc: etna...@lists.freedesktop.org
> ---
> Changes from v1 -> v2:
>  - to remove the resource from the used_resources set when it is destroyed
> Changes from v2 -> v3:
>  - add locking with mtx_*() to resource and screen (Marek)
> Changes from v3 -> v4:
>  - drop rsc->lock, just use screen->lock for the entire serialization (Marek)
>  - simplify etna_resource_used() flush condition, which also prevents
>    potentially flushing resources twice (Marek)
>  - don't remove resouces from screen->used_resources in
>    etna_cmd_stream_reset_notify(), they may still be used in other
>    contexts and may need flushing there later on (Marek)

The patch mostly makes sense to me now, but don't we need to take the
screen->lock on all call sites where we do a ctx->flush? Otherwise we
may enter etna_cmd_stream_reset_notify unlocked, changing the
used_resources set while other threads might use it at the same time,
right?

Regards,
Lucas

> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.c | 26 +-
>  src/gallium/drivers/etnaviv/etnaviv_context.h |  3 --
>  .../drivers/etnaviv/etnaviv_resource.c| 52 +++
>  .../drivers/etnaviv/etnaviv_resource.h|  8 +--
>  src/gallium/drivers/etnaviv/etnaviv_screen.c  | 12 +
>  src/gallium/drivers/etnaviv/etnaviv_screen.h  |  6 +++
>  6 files changed, 78 insertions(+), 29 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
> b/src/gallium/drivers/etnaviv/etnaviv_context.c
> index 3038d21..2f8cae8 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> @@ -36,6 +36,7 @@
>  #include "etnaviv_query.h"
>  #include "etnaviv_query_hw.h"
>  #include "etnaviv_rasterizer.h"
> +#include "etnaviv_resource.h"
>  #include "etnaviv_screen.h"
>  #include "etnaviv_shader.h"
>  #include "etnaviv_state.h"
> @@ -329,7 +330,8 @@ static void
>  etna_cmd_stream_reset_notify(struct etna_cmd_stream *stream, void *priv)
>  {
> struct etna_context *ctx = priv;
> -   struct etna_resource *rsc, *rsc_tmp;
> +   struct etna_screen *screen = ctx->screen;
> +   struct set_entry *entry;
>  
> etna_set_state(stream, VIVS_GL_API_MODE, VIVS_GL_API_MODE_OPENGL);
> etna_set_state(stream, VIVS_GL_VERTEX_ELEMENT_CONFIG, 0x0001);
> @@ -384,16 +386,18 @@ etna_cmd_stream_reset_notify(struct etna_cmd_stream 
> *stream, void *priv)
> ctx->dirty = ~0L;
> ctx->dirty_sampler_views = ~0L;
>  
> -   /* go through all the used resources and clear their status flag */
> -   LIST_FOR_EACH_ENTRY_SAFE(rsc, rsc_tmp, &ctx->used_resources, list)
> -   {
> -  debug_assert(rsc->status != 0);
> -  rsc->status = 0;
> -  rsc->pending_ctx = NULL;
> -  list_delinit(&rsc->list);
> -   }
> +   /*
> +* Go through all _resources_ associated with this _screen_, pending
> +* in this _context_ and mark them as not pending in this _context_
> +* anymore, since they were just flushed.
> +*/
> +   mtx_lock(&screen->lock);
> +   set_foreach(screen->used_resources, entry) {
> +  struct etna_resource *rsc = (struct etna_resource *)entry->key;
>  
> -   assert(LIST_IS_EMPTY(&ctx->used_resources));
> +  _mesa_set_remove_key(rsc->pending_ctx, ctx);
> +   }
> +   mtx_unlock(&screen->lock);
>  }
>  
>  static void
> @@ -437,8 +441,6 @@ etna_context_create(struct pipe_screen *pscreen, void 
> *priv, unsigned flags)
> /* need some sane default in case state tracker doesn't set some state: */
> ctx->sample_mask = 0x;
>  
> -   list_inithead(&ctx->used_resources);
> -
> /*  Set sensible defaults for state */
> etna_cmd_stream_reset_notify(ctx->stream, ctx);
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
> b/src/gallium/drivers/etnaviv/etnaviv_context.h
> index 584caa7..eff0a23 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
> @@ -136,9 +136,6 @@ struct etna_context {
> uint32_t prim_hwsupport;
> struct primconvert_context *primconvert;
>  
> -   /* list of resources used by currently-unsubmitted renders */
> -   struct list_head used_resources;
> -
> struct slab_child_pool transfer_pool;
> struct blitter_context *blitter;
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 3808c29..46ab849 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -33,6 +33,7 @@
>  #include "etnaviv_screen.h"
>  #include "etnaviv_translate.h"
>  
> +#include "util/hash_table.h"
>  #include "util/u_inlines.h"
>  #include "util/u_memory.h"
>

Re: [Mesa-dev] [PATCH v4] etnaviv: fix resource usage tracking across different pipe_context's

2019-01-14 Thread Lucas Stach
Am Montag, den 14.01.2019, 14:54 +0100 schrieb Marek Vasut:
> On 1/14/19 12:16 PM, Lucas Stach wrote:
> > Hi Marek,
> > 
> > Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut:
> > > > From: Christian Gmeiner 
> > > 
> > > A pipe_resource can be shared by all the pipe_context's hanging off the
> > > same pipe_screen.
> > > 
> > > > > > > > Signed-off-by: Christian Gmeiner 
> > > > Signed-off-by: Marek Vasut 
> > > 
> > > To: mesa-dev@lists.freedesktop.org
> > > Cc: etna...@lists.freedesktop.org
> > > ---
> > > Changes from v1 -> v2:
> > >  - to remove the resource from the used_resources set when it is destroyed
> > > Changes from v2 -> v3:
> > >  - add locking with mtx_*() to resource and screen (Marek)
> > > Changes from v3 -> v4:
> > >  - drop rsc->lock, just use screen->lock for the entire serialization 
> > > (Marek)
> > >  - simplify etna_resource_used() flush condition, which also prevents
> > >    potentially flushing resources twice (Marek)
> > >  - don't remove resouces from screen->used_resources in
> > >    etna_cmd_stream_reset_notify(), they may still be used in other
> > >    contexts and may need flushing there later on (Marek)
> > 
> > The patch mostly makes sense to me now, but don't we need to take the
> > screen->lock on all call sites where we do a ctx->flush? Otherwise we
> > may enter etna_cmd_stream_reset_notify unlocked, changing the
> > used_resources set while other threads might use it at the same time,
> > right?
> 
> etna_cmd_stream_reset_notify() takes the lock when accessing the
> used_resources set , see below.

Uh, sorry seems I mixed this up. But then I don't see how this isn't
deadlocking, as AFAICS mtx_lock isn't recursive.

In etna_resource_used() you already lock the screen mutex, then when
you find a context that needs flushing you call the context flush,
which flushes the cmd stream and calls into
etna_cmd_stream_reset_notify() where the mutex is locked again -> self
deadlock.

Regards,
Lucas


> > Regards,
> > Lucas
> > 
> > > ---
> > >  src/gallium/drivers/etnaviv/etnaviv_context.c | 26 +-
> > >  src/gallium/drivers/etnaviv/etnaviv_context.h |  3 --
> > >  .../drivers/etnaviv/etnaviv_resource.c| 52 +++
> > >  .../drivers/etnaviv/etnaviv_resource.h|  8 +--
> > >  src/gallium/drivers/etnaviv/etnaviv_screen.c  | 12 +
> > >  src/gallium/drivers/etnaviv/etnaviv_screen.h  |  6 +++
> > >  6 files changed, 78 insertions(+), 29 deletions(-)
> > > 
> > > diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
> > > b/src/gallium/drivers/etnaviv/etnaviv_context.c
> > > index 3038d21..2f8cae8 100644
> > > --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> > > +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> > > @@ -36,6 +36,7 @@
> > >  #include "etnaviv_query.h"
> > >  #include "etnaviv_query_hw.h"
> > >  #include "etnaviv_rasterizer.h"
> > > +#include "etnaviv_resource.h"
> > >  #include "etnaviv_screen.h"
> > >  #include "etnaviv_shader.h"
> > >  #include "etnaviv_state.h"
> > > @@ -329,7 +330,8 @@ static void
> > >  etna_cmd_stream_reset_notify(struct etna_cmd_stream *stream, void *priv)
> > >  {
> > > struct etna_context *ctx = priv;
> > > -   struct etna_resource *rsc, *rsc_tmp;
> > > +   struct etna_screen *screen = ctx->screen;
> > > +   struct set_entry *entry;
> > >  
> > > etna_set_state(stream, VIVS_GL_API_MODE, VIVS_GL_API_MODE_OPENGL);
> > > etna_set_state(stream, VIVS_GL_VERTEX_ELEMENT_CONFIG, 0x0001);
> > > @@ -384,16 +386,18 @@ etna_cmd_stream_reset_notify(struct etna_cmd_stream 
> > > *stream, void *priv)
> > > ctx->dirty = ~0L;
> > > ctx->dirty_sampler_views = ~0L;
> > >  
> > > -   /* go through all the used resources and clear their status flag */
> > > -   LIST_FOR_EACH_ENTRY_SAFE(rsc, rsc_tmp, &ctx->used_resources, list)
> > > -   {
> > > -  debug_assert(rsc->status != 0);
> > > -  rsc->status = 0;
> > > -  rsc->pending_ctx = NULL;
> > > -  list_delinit(&rsc->list);
> > > -   }
> > > +   /*
> > > +* Go through all _resources_ associate

Re: [Mesa-dev] [PATCH v4] etnaviv: fix resource usage tracking across different pipe_context's

2019-01-14 Thread Lucas Stach
Am Montag, den 14.01.2019, 15:20 +0100 schrieb Marek Vasut:
> On 1/14/19 3:02 PM, Lucas Stach wrote:
> > Am Montag, den 14.01.2019, 14:54 +0100 schrieb Marek Vasut:
> > > On 1/14/19 12:16 PM, Lucas Stach wrote:
> > > > Hi Marek,
> > > > 
> > > > Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut:
> > > > > > From: Christian Gmeiner 
> > > > > 
> > > > > A pipe_resource can be shared by all the pipe_context's hanging off 
> > > > > the
> > > > > same pipe_screen.
> > > > > 
> > > > > > > > > > Signed-off-by: Christian Gmeiner 
> > > > > > > > > > 
> > > > > > 
> > > > > > Signed-off-by: Marek Vasut 
> > > > > 
> > > > > To: mesa-dev@lists.freedesktop.org
> > > > > Cc: etna...@lists.freedesktop.org
> > > > > ---
> > > > > Changes from v1 -> v2:
> > > > >  - to remove the resource from the used_resources set when it is 
> > > > > destroyed
> > > > > Changes from v2 -> v3:
> > > > >  - add locking with mtx_*() to resource and screen (Marek)
> > > > > Changes from v3 -> v4:
> > > > >  - drop rsc->lock, just use screen->lock for the entire serialization 
> > > > > (Marek)
> > > > >  - simplify etna_resource_used() flush condition, which also prevents
> > > > >    potentially flushing resources twice (Marek)
> > > > >  - don't remove resouces from screen->used_resources in
> > > > >    etna_cmd_stream_reset_notify(), they may still be used in other
> > > > >    contexts and may need flushing there later on (Marek)
> > > > 
> > > > The patch mostly makes sense to me now, but don't we need to take the
> > > > screen->lock on all call sites where we do a ctx->flush? Otherwise we
> > > > may enter etna_cmd_stream_reset_notify unlocked, changing the
> > > > used_resources set while other threads might use it at the same time,
> > > > right?
> > > 
> > > etna_cmd_stream_reset_notify() takes the lock when accessing the
> > > used_resources set , see below.
> > 
> > Uh, sorry seems I mixed this up. But then I don't see how this isn't
> > deadlocking, as AFAICS mtx_lock isn't recursive.
> > 
> > In etna_resource_used() you already lock the screen mutex, then when
> > you find a context that needs flushing you call the context flush,
> > which flushes the cmd stream and calls into
> > etna_cmd_stream_reset_notify() where the mutex is locked again -> self
> > deadlock.
> 
> [...]
> 
> > > > > +   mtx_init(&screen->lock, mtx_recursive);
> 
> [...]
> 
> But it is recursive ...

Thanks, going back to ridicule myself somewhere myself somewhere else
now.

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


Re: [Mesa-dev] [PATCH v4] etnaviv: fix resource usage tracking across different pipe_context's

2019-01-16 Thread Lucas Stach
Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut:
> > From: Christian Gmeiner 
> 
> A pipe_resource can be shared by all the pipe_context's hanging off the
> same pipe_screen.
> 
> > Signed-off-by: Christian Gmeiner 
> > Signed-off-by: Marek Vasut 
> To: mesa-dev@lists.freedesktop.org
> Cc: etna...@lists.freedesktop.org

I would appreciate if this can get a review from someone who didn't
totally mess up the mental model of the locking involved. To me this
change looks good. I'll push this through some internal testing and
push upstream by the end of the week if there aren't any objections.

Regards,
Lucas

> ---
> Changes from v1 -> v2:
>  - to remove the resource from the used_resources set when it is destroyed
> Changes from v2 -> v3:
>  - add locking with mtx_*() to resource and screen (Marek)
> Changes from v3 -> v4:
>  - drop rsc->lock, just use screen->lock for the entire serialization (Marek)
>  - simplify etna_resource_used() flush condition, which also prevents
>    potentially flushing resources twice (Marek)
>  - don't remove resouces from screen->used_resources in
>    etna_cmd_stream_reset_notify(), they may still be used in other
>    contexts and may need flushing there later on (Marek)
> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.c | 26 +-
>  src/gallium/drivers/etnaviv/etnaviv_context.h |  3 --
>  .../drivers/etnaviv/etnaviv_resource.c| 52 +++
>  .../drivers/etnaviv/etnaviv_resource.h|  8 +--
>  src/gallium/drivers/etnaviv/etnaviv_screen.c  | 12 +
>  src/gallium/drivers/etnaviv/etnaviv_screen.h  |  6 +++
>  6 files changed, 78 insertions(+), 29 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
> b/src/gallium/drivers/etnaviv/etnaviv_context.c
> index 3038d21..2f8cae8 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> @@ -36,6 +36,7 @@
>  #include "etnaviv_query.h"
>  #include "etnaviv_query_hw.h"
>  #include "etnaviv_rasterizer.h"
> +#include "etnaviv_resource.h"
>  #include "etnaviv_screen.h"
>  #include "etnaviv_shader.h"
>  #include "etnaviv_state.h"
> @@ -329,7 +330,8 @@ static void
>  etna_cmd_stream_reset_notify(struct etna_cmd_stream *stream, void *priv)
>  {
> struct etna_context *ctx = priv;
> -   struct etna_resource *rsc, *rsc_tmp;
> +   struct etna_screen *screen = ctx->screen;
> +   struct set_entry *entry;
>  
> etna_set_state(stream, VIVS_GL_API_MODE, VIVS_GL_API_MODE_OPENGL);
> etna_set_state(stream, VIVS_GL_VERTEX_ELEMENT_CONFIG, 0x0001);
> @@ -384,16 +386,18 @@ etna_cmd_stream_reset_notify(struct etna_cmd_stream 
> *stream, void *priv)
> ctx->dirty = ~0L;
> ctx->dirty_sampler_views = ~0L;
>  
> -   /* go through all the used resources and clear their status flag */
> -   LIST_FOR_EACH_ENTRY_SAFE(rsc, rsc_tmp, &ctx->used_resources, list)
> -   {
> -  debug_assert(rsc->status != 0);
> -  rsc->status = 0;
> -  rsc->pending_ctx = NULL;
> -  list_delinit(&rsc->list);
> -   }
> +   /*
> +* Go through all _resources_ associated with this _screen_, pending
> +* in this _context_ and mark them as not pending in this _context_
> +* anymore, since they were just flushed.
> +*/
> +   mtx_lock(&screen->lock);
> +   set_foreach(screen->used_resources, entry) {
> +  struct etna_resource *rsc = (struct etna_resource *)entry->key;
>  
> -   assert(LIST_IS_EMPTY(&ctx->used_resources));
> +  _mesa_set_remove_key(rsc->pending_ctx, ctx);
> +   }
> +   mtx_unlock(&screen->lock);
>  }
>  
>  static void
> @@ -437,8 +441,6 @@ etna_context_create(struct pipe_screen *pscreen, void 
> *priv, unsigned flags)
> /* need some sane default in case state tracker doesn't set some state: */
> ctx->sample_mask = 0x;
>  
> -   list_inithead(&ctx->used_resources);
> -
> /*  Set sensible defaults for state */
> etna_cmd_stream_reset_notify(ctx->stream, ctx);
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
> b/src/gallium/drivers/etnaviv/etnaviv_context.h
> index 584caa7..eff0a23 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
> @@ -136,9 +136,6 @@ struct etna_context {
> uint32_t prim_hwsupport;
> struct primconvert_context *primconvert;
>  
> -   /* list of resources used by currently-unsubmitted renders */
> -   struct list_head used_resources;
> -
> struct slab_child_pool transfer_pool;
> struct blitter_context *blitter;
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 3808c29..46ab849 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -33,6 +33,7 @@
>  #include "etnaviv_screen.h"
>  #include "etnaviv_translate.h"
>  
> +#include "util/hash_table.h"
>  #include "util/u_inlines.h"
>  #include "util/u_memory.h"
>  
> @@ -275,7 +

Re: [Mesa-dev] [PATCH] egl/wayland: break double/tripple buffering feedback loops

2019-01-16 Thread Lucas Stach
Am Dienstag, den 15.01.2019, 10:35 -0600 schrieb Derek Foreman:
> On 1/15/19 8:02 AM, Daniel Stone wrote:
> > Hi,
> > 
> > > > On Tue, 18 Dec 2018 at 17:59, Lucas Stach  
> > > > wrote:
> > > Am Dienstag, den 18.12.2018, 17:43 + schrieb Emil Velikov:
> > > > > On Tue, 18 Dec 2018 at 11:16, Lucas Stach  
> > > > > wrote:
> > > > >   if (dri2_surf->back == NULL)
> > > > >  dri2_surf->back = &dri2_surf->color_buffers[i];
> > > > > - else if (dri2_surf->back->dri_image == NULL)
> > > > > + else if (dri2_surf->back->dri_image == NULL && 
> > > > > dri2_surf->color_buffers[i].dri_image)
> > > > >  dri2_surf->back = &dri2_surf->color_buffers[i];
> > > > > + age = dri2_surf->back->age;
> > > > >    }
> > > > > 
> > > > 
> > > > AFAICT this is the wayland equivalent of
> > > > 4f1d27a406478d405eac6f9894ccc46a80034adb
> > > > Where the exact same logic/commit message applies.
> > > 
> > > No it isn't. It's exactly what it says in the commit log. It's keeping
> > > the tripple buffer around for a bit, even if we don't strictly need it
> > > when the client is currently doing double buffering.
> 
> I'm having a bit of a hard time following the logic in this first hunk
> myself...
> 
> The dri2_surf->color_buffers[i].age < age check looks like it's intended
> to skip buffers younger than the one currently in hand - ie) pick the
> oldest buffer.  But doing so would break the second hunk because we'd
> never end up with a very old buffer to trim.  (It doesn't actually cause
> the oldest buffer to be picked though, because of the other tests involved)
> 
> I would like to at least see a comment explaining what's going on,
> because it looks kind of like a bug on a casual read.

The age check is really bogus and I believe I messed this up when
cleaning this up from a previous version of the patch. Thanks for
taking a close look. I'll fix this.

Regards,
Lucas

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


Re: [Mesa-dev] Double free error on etnaviv driver.

2019-01-17 Thread Lucas Stach
Hi Sergey,

Am Mittwoch, den 16.01.2019, 13:34 +0300 schrieb Nazarov Sergey:
> Hello!
> I use mesa+etnaviv Gallium driver on iMX6Q based board.
> I have double free error at the end of any application using mesa.
> I've found that the problem comes from current ARM g++ compilers
> (at least from 4.9.4 up to latest ones) which call static objects destructors 
> before
> on_exit handler. So, static builtin_builder builtins destructor frees 
> dynamically allocated
> internal members memory before call of _mesa_glsl_release_builtin_functions(),
> which do that again. Here is a patch to fix the problem:

Do you have a reproducer for this issue? I haven't experienced any
memory corruption issues with etnaviv in a long time. Also this being
shared code, it should also happen on other ARM drivers too.

I gave some applications a quick run under valgrind, which didn't turn 
up anything bad immediately, so I would be interested in a way to
clearly demonstrate the issue.

Regards,
Lucas

> 
> --- a/src/compiler/glsl/builtin_functions.cpp
> +++ b/src/compiler/glsl/builtin_functions.cpp
> @@ -6268,7 +6268,7 @@ builtin_builder::_vote(const char *intri
>  
> /**/
>  
>  /* The singleton instance of builtin_builder. */
> -static builtin_builder builtins;
> +static builtin_builder *builtins = NULL;
>  static mtx_t builtins_lock = _MTX_INITIALIZER_NP;
>  
>  /**
> @@ -6279,7 +6279,9 @@ void
>  _mesa_glsl_initialize_builtin_functions()
>  {
> mtx_lock(&builtins_lock);
> -   builtins.initialize();
> +   if (!builtins)
> + builtins = new builtin_builder;
> +   builtins->initialize();
> mtx_unlock(&builtins_lock);
>  }
>  
> @@ -6287,7 +6289,9 @@ void
>  _mesa_glsl_release_builtin_functions()
>  {
> mtx_lock(&builtins_lock);
> -   builtins.release();
> +   builtins->release();
> +   delete builtins;
> +   builtins = NULL;
> mtx_unlock(&builtins_lock);
>  }
>  
> @@ -6297,7 +6301,7 @@ _mesa_glsl_find_builtin_function(_mesa_g
>  {
> ir_function_signature *s;
> mtx_lock(&builtins_lock);
> -   s = builtins.find(state, name, actual_parameters);
> +   s = builtins->find(state, name, actual_parameters);
> mtx_unlock(&builtins_lock);
>  
> return s;
> @@ -6309,7 +6313,7 @@ _mesa_glsl_has_builtin_function(_mesa_gl
> ir_function *f;
> bool ret = false;
> mtx_lock(&builtins_lock);
> -   f = builtins.shader->symbols->get_function(name);
> +   f = builtins->shader->symbols->get_function(name);
> if (f != NULL) {
>    foreach_in_list(ir_function_signature, sig, &f->signatures) {
>   if (sig->is_builtin_available(state)) {
> @@ -6326,7 +6330,7 @@ _mesa_glsl_has_builtin_function(_mesa_gl
>  gl_shader *
>  _mesa_glsl_get_builtin_function_shader()
>  {
> -   return builtins.shader;
> +   return builtins ? builtins->shader : NULL;
>  }
> 
> ___
> 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] Double free error on etnaviv driver.

2019-01-18 Thread Lucas Stach
Hi Sergey,

Am Donnerstag, den 17.01.2019, 18:14 +0300 schrieb Nazarov Sergey:
> Hi, Lucas!
> Here is result of execution standard Qt5 example application mainwindow
> built under custom buildroot with gcc-4.9.4, mesa3d-17.3.6.
> But we had the same error with latest buildroot and latest supported mesa and 
> gcc.
> ---
> # ./mainwindow
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
> '/root/.tmp/runtime-root'
> Failed to move cursor on screen LVDS1: -14
> *** Error in `./mainwindow': double free or corruption (fasttop): 0x021295b8 
> ***
> Aborted
> ---
> Some from valgrind output:
> ==1473== Invalid free() / delete / delete[] / realloc()
> ==1473==at 0x48469F8: free (vg_replace_malloc.c:530)
> ==1473==by 0x825C61B: _mesa_glsl_release_builtin_functions() (in 
> /usr/lib/dri/imx-drm_dri.so)
> ==1473==by 0x8286113: _mesa_destroy_shader_compiler (in 
> /usr/lib/dri/imx-drm_dri.so)
> ==1473==by 0x808F073: one_time_fini (in /usr/lib/dri/imx-drm_dri.so)
> ==1473==  Address 0x96f4ee8 is 0 bytes inside a block of size 24 free'd
> ==1473==at 0x48469F8: free (vg_replace_malloc.c:530)
> ==1473==by 0x4015CF7: _dl_close_worker (in /lib/ld-2.23.so)
> ==1473==  Block was alloc'd at
> ==1473==at 0x48454B0: malloc (vg_replace_malloc.c:299)
> ==1473==by 0x829EA7F: ralloc_size (in /usr/lib/dri/imx-drm_dri.so)

I've just been made aware of a peculiarity of the buildroot toolchain
configuration, which might well explain why you are seeing the obvious
crash, but no one else is complaining about this.

Can you try if [1] also solves this issue for you? If it does, I think
we should not try to work around this in Mesa.

Regards,
Lucas

[1] http://lists.busybox.net/pipermail/buildroot/2018-November/235923.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/4] etnaviv: extend etna_resource with an addressing mode

2019-01-21 Thread Lucas Stach
Hi Christian,

first of all, thanks for figuring this out. This is really nice
to finally know how it works.

Am Montag, den 21.01.2019, 07:49 +0100 schrieb Christian Gmeiner:
> Defines how sampler (and pixel pipes) needs to access the data
> represented with a resource. The used default is mode is
> ETNA_ADDRESSING_MODE_TILED.

Do you see any reason why we need a separate property for this? IMHO
etna_resource is already a bit too fat and from this set of patches I
can't see why we can't infer the addressing mode from the layout. Do
you have something specific in mind, that I don't see right now?

Regards,
Lucas

> 
> > Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 17 +++--
>  src/gallium/drivers/etnaviv/etnaviv_resource.h |  9 -
>  src/gallium/drivers/etnaviv/etnaviv_texture.c  |  1 +
>  src/gallium/drivers/etnaviv/etnaviv_transfer.c |  3 ++-
>  4 files changed, 22 insertions(+), 8 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index c0091288030..9a7ebf3064e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -188,7 +188,8 @@ static bool is_rs_align(struct etna_screen *screen,
>  /* Create a new resource object, using the given template info */
>  struct pipe_resource *
>  etna_resource_alloc(struct pipe_screen *pscreen, unsigned layout,
> -uint64_t modifier, const struct pipe_resource *templat)
> +enum etna_resource_addressing_mode mode, uint64_t 
> modifier,
> +const struct pipe_resource *templat)
>  {
> struct etna_screen *screen = etna_screen(pscreen);
> struct etna_resource *rsc;
> @@ -280,6 +281,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, unsigned 
> layout,
> rsc->base.nr_samples = nr_samples;
> rsc->layout = layout;
> rsc->halign = halign;
> +   rsc->addressing_mode = mode;
>  
> pipe_reference_init(&rsc->base.reference, 1);
> list_inithead(&rsc->list);
> @@ -316,12 +318,14 @@ etna_resource_create(struct pipe_screen *pscreen,
>  {
> struct etna_screen *screen = etna_screen(pscreen);
>  
> -   /* Figure out what tiling to use -- for now, assume that texture cannot 
> be linear.
> -* there is a capability LINEAR_TEXTURE_SUPPORT (supported on gc880 and
> -* gc2000 at least), but not sure how it works.
> +   /* Figure out what tiling and address mode to use -- for now, assume that
> +* texture cannot be linear. there is a capability LINEAR_TEXTURE_SUPPORT
> +* (supported on gc880 and gc2000 at least), but not sure how it works.
>  * Buffers always have LINEAR layout.
>  */
> unsigned layout = ETNA_LAYOUT_LINEAR;
> +   enum etna_resource_addressing_mode mode = ETNA_ADDRESSING_MODE_TILED;
> +
> if (etna_resource_sampler_only(templat)) {
>    /* The buffer is only used for texturing, so create something
> * directly compatible with the sampler.  Such a buffer can
> @@ -364,7 +368,7 @@ etna_resource_create(struct pipe_screen *pscreen,
>    layout = ETNA_LAYOUT_LINEAR;
>  
> /* modifier is only used for scanout surfaces, so safe to use LINEAR here 
> */
> -   return etna_resource_alloc(pscreen, layout, DRM_FORMAT_MOD_LINEAR, 
> templat);
> +   return etna_resource_alloc(pscreen, layout, mode, DRM_FORMAT_MOD_LINEAR, 
> templat);
>  }
>  
>  enum modifier_priority {
> @@ -445,7 +449,7 @@ etna_resource_create_modifiers(struct pipe_screen 
> *pscreen,
> tmpl.bind |= PIPE_BIND_SCANOUT;
>  
> return etna_resource_alloc(pscreen, modifier_to_layout(modifier),
> -  modifier, &tmpl);
> +  ETNA_ADDRESSING_MODE_TILED, modifier, &tmpl);
>  }
>  
>  static void
> @@ -518,6 +522,7 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
> rsc->seqno = 1;
> rsc->layout = modifier_to_layout(handle->modifier);
> rsc->halign = TEXTURE_HALIGN_FOUR;
> +   rsc->addressing_mode = ETNA_ADDRESSING_MODE_TILED;
>  
>  
> level->width = tmpl->width0;
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 11ccf8f7bcb..75aa80b3d7a 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -49,6 +49,11 @@ struct etna_resource_level {
> bool ts_valid;
>  };
>  
> +enum etna_resource_addressing_mode {
> +   ETNA_ADDRESSING_MODE_TILED = 0,
> +   ETNA_ADDRESSING_MODE_LINEAR,
> +};
> +
>  /* status of queued up but not flushed reads and write operations.
>   * In _transfer_map() we need to know if queued up rendering needs
>   * to be flushed to preserve the order of cpu and gpu access. */
> @@ -66,6 +71,7 @@ struct etna_resource {
> /* only lod 0 used for non-texture buffers */
> /* Layout for surface (tiled, multitiled, split tiled, ...) */
> enum e

Re: [Mesa-dev] [PATCH 4/4] etnaviv: hook up linear texture sampling support

2019-01-21 Thread Lucas Stach
Am Montag, den 21.01.2019, 07:50 +0100 schrieb Christian Gmeiner:
> If the GPU supports linear sampling, linear addressing mode
> will be used as default.
> 
> > Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 10 +++---
>  src/gallium/drivers/etnaviv/etnaviv_texture.c  |  4 +++-
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 9a7ebf3064e..7d24b1f03bd 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -318,9 +318,9 @@ etna_resource_create(struct pipe_screen *pscreen,
>  {
> struct etna_screen *screen = etna_screen(pscreen);
>  
> -   /* Figure out what tiling and address mode to use -- for now, assume that
> -* texture cannot be linear. there is a capability LINEAR_TEXTURE_SUPPORT
> -* (supported on gc880 and gc2000 at least), but not sure how it works.
> +   /* Figure out what tiling and address mode to use.
> +* Textures are TILED or LINEAR. If LINEAR_TEXTURE_SUPPORT capability is
> +* available LINEAR gets prefered.
>  * Buffers always have LINEAR layout.
>  */
> unsigned layout = ETNA_LAYOUT_LINEAR;
> @@ -334,6 +334,10 @@ etna_resource_create(struct pipe_screen *pscreen,
>  
>    if (util_format_is_compressed(templat->format))
>   layout = ETNA_LAYOUT_LINEAR;
> +  else if (VIV_FEATURE(screen, chipMinorFeatures1, 
> LINEAR_TEXTURE_SUPPORT)) {
> + layout = ETNA_LAYOUT_LINEAR;
> + mode = ETNA_ADDRESSING_MODE_LINEAR;
> +  }

Did you do any performance measurements with this change? I don't think
we generally want to prefer linear textures, as in theory they have
much worse texture cache hit rates. Also a lot of the async transfer
stuff currently depends on hitting the RS linear->tiled blit path for
optimal performance on uploads.

There are 2 cases where I think linear textures are useful:

1. Imported external buffers, where we might need to update the
internal tiled copy on each resource update. Getting rid of this blit
should help performance a good bit.

2. 8bpp formats that can't be tiled with the RS and would hit the
software fallback path. The tradeoff software tiling path vs. reduced
texture cache hit rates might still prefer linear textures.

Regards,
Lucas
 

> } else if (templat->target != PIPE_BUFFER) {
>    bool want_multitiled = false;
>    bool want_supertiled = screen->specs.can_supertile;
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_texture.c 
> b/src/gallium/drivers/etnaviv/etnaviv_texture.c
> index 3993e31cec1..b06f20531fd 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_texture.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_texture.c
> @@ -172,7 +172,9 @@ etna_resource_sampler_compatible(struct etna_resource 
> *res)
> if (res->layout == ETNA_LAYOUT_SUPER_TILED && VIV_FEATURE(screen, 
> chipMinorFeatures2, SUPERTILED_TEXTURE))
>    return true;
>  
> -   /* TODO: LINEAR_TEXTURE_SUPPORT */
> +   /* This GPU supports texturing from linear textures? */
> +   if (res->layout == ETNA_LAYOUT_LINEAR && VIV_FEATURE(screen, 
> chipMinorFeatures1, LINEAR_TEXTURE_SUPPORT))
> +  return true;
>  
> /* Otherwise, only support tiled layouts */
> if (res->layout != ETNA_LAYOUT_TILED)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/4] etnaviv: extend etna_resource with an addressing mode

2019-01-24 Thread Lucas Stach
Am Donnerstag, den 24.01.2019, 07:31 +0100 schrieb Christian Gmeiner:
> Hi Lucas
> 
> Am Mo., 21. Jan. 2019 um 10:03 Uhr schrieb Lucas Stach 
> :
> > 
> > Hi Christian,
> > 
> > first of all, thanks for figuring this out. This is really nice
> > to finally know how it works.
> > 
> > Am Montag, den 21.01.2019, 07:49 +0100 schrieb Christian Gmeiner:
> > > Defines how sampler (and pixel pipes) needs to access the data
> > > represented with a resource. The used default is mode is
> > > ETNA_ADDRESSING_MODE_TILED.
> > 
> > Do you see any reason why we need a separate property for this? IMHO
> > etna_resource is already a bit too fat and from this set of patches I
> > can't see why we can't infer the addressing mode from the layout. Do
> > you have something specific in mind, that I don't see right now?
> > 
> 
> We are using ETNA_LAYOUT_LINEAR for compressed textures with an
> addressing mode of TILED (register value of 0). That is the root cause why
> was forced to add something new to etna_resource as I can not trust that
> ETNA_LAYOUT_LINEAR for sampler resources implies an linear addressing
> mode.

Ah, right. This had escaped my mind. With this out of the way, patch
looks good.

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


Re: [Mesa-dev] [PATCH 4/4] etnaviv: hook up linear texture sampling support

2019-01-24 Thread Lucas Stach
Am Donnerstag, den 24.01.2019, 07:46 +0100 schrieb Christian Gmeiner:
> Am Mo., 21. Jan. 2019 um 10:10 Uhr schrieb Lucas Stach 
> :
> > 
> > Am Montag, den 21.01.2019, 07:50 +0100 schrieb Christian Gmeiner:
> > > If the GPU supports linear sampling, linear addressing mode
> > > will be used as default.
> > > 
> > > > Signed-off-by: Christian Gmeiner 
> > > 
> > > ---
> > >  src/gallium/drivers/etnaviv/etnaviv_resource.c | 10 +++---
> > >  src/gallium/drivers/etnaviv/etnaviv_texture.c  |  4 +++-
> > >  2 files changed, 10 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> > > b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > index 9a7ebf3064e..7d24b1f03bd 100644
> > > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > @@ -318,9 +318,9 @@ etna_resource_create(struct pipe_screen *pscreen,
> > >  {
> > > struct etna_screen *screen = etna_screen(pscreen);
> > > 
> > > -   /* Figure out what tiling and address mode to use -- for now, assume 
> > > that
> > > -* texture cannot be linear. there is a capability 
> > > LINEAR_TEXTURE_SUPPORT
> > > -* (supported on gc880 and gc2000 at least), but not sure how it 
> > > works.
> > > +   /* Figure out what tiling and address mode to use.
> > > +* Textures are TILED or LINEAR. If LINEAR_TEXTURE_SUPPORT capability 
> > > is
> > > +* available LINEAR gets prefered.
> > >  * Buffers always have LINEAR layout.
> > >  */
> > > unsigned layout = ETNA_LAYOUT_LINEAR;
> > > @@ -334,6 +334,10 @@ etna_resource_create(struct pipe_screen *pscreen,
> > > 
> > >    if (util_format_is_compressed(templat->format))
> > >   layout = ETNA_LAYOUT_LINEAR;
> > > +  else if (VIV_FEATURE(screen, chipMinorFeatures1, 
> > > LINEAR_TEXTURE_SUPPORT)) {
> > > + layout = ETNA_LAYOUT_LINEAR;
> > > + mode = ETNA_ADDRESSING_MODE_LINEAR;
> > > +  }
> > 
> > Did you do any performance measurements with this change? I don't think
> > we generally want to prefer linear textures, as in theory they have
> > much worse texture cache hit rates. Also a lot of the async transfer
> > stuff currently depends on hitting the RS linear->tiled blit path for
> > optimal performance on uploads.
> > 
> 
> I have not done any performance measurements yet - I only tried to get it
> render correctly (piglit and amoeba) and get some feedback asap.
> But I will keep an eye on perf for v2.

FWIW, I did some preliminary testing and couldn't find a big perf
difference. Even after a hack to use linear textures more often (in
most cases we end up with textures being allocated with both SAMPLER
and RENDER binding, where we still end up with tiled resources.

But my tests didn't pound very hard on sampler performance.

> Regarding the async transfer staff I have the feeling that we lose the shadow
> resource (etna_transfer->rsc) handling if we are using linear, which saves us
> from some RS blits. Or?

That's right, but at the price that the CPU side of the transfer needs
to synchronize with the GPU job. Getting rid of those synchronization
points was one of the key performance optimizations up until now.

Basically we are trading the overhead of a temporary buffer allocation
and a RS blit (which is only done to the part of the buffer that is
actually updated) against a full GPU stall in most cases. I'm not
saying that getting rid of the RS blit for some of the transfers won't
be beneficial, but we need to carefully weight the performance
implications here. Being able to directly map the texture resource and
blindly doing this when possible (what our current transfer code does) 
will not be a net win in performance in most cases.

> > There are 2 cases where I think linear textures are useful:
> > 
> > 1. Imported external buffers, where we might need to update the
> > internal tiled copy on each resource update. Getting rid of this blit
> > should help performance a good bit.
> > 
> 
> You are taking about etna_resource_from_handle(..). I *think* for this we
> need support for linear in the pixel engine too - based on the binding flag
> combinations I have seen.

That would be ideal, but for a start we can just keep the external
imported resource as linear and keep a tiled base resource, just as we
do now. Linear texture sampling support would already allow us to
sample the external import directly, without the need to do a copy into
a tiled texture resource.

> > 2. 8bpp formats that can't be tiled with the RS and would hit the
> > software fallback path. The tradeoff software tiling path vs. reduced
> > texture cache hit rates might still prefer linear textures.
> > 
> 
> Yes that I something to look into.
> 

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


Re: [Mesa-dev] [PATCH 4/4] etnaviv: hook up linear texture sampling support

2019-01-25 Thread Lucas Stach
Hi Christian,

Am Montag, den 21.01.2019, 07:50 +0100 schrieb Christian Gmeiner:
> If the GPU supports linear sampling, linear addressing mode
> will be used as default.
> 
> > Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 10 +++---
>  src/gallium/drivers/etnaviv/etnaviv_texture.c  |  4 +++-
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 9a7ebf3064e..7d24b1f03bd 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -318,9 +318,9 @@ etna_resource_create(struct pipe_screen *pscreen,
>  {
> struct etna_screen *screen = etna_screen(pscreen);
>  
> -   /* Figure out what tiling and address mode to use -- for now, assume that
> -* texture cannot be linear. there is a capability LINEAR_TEXTURE_SUPPORT
> -* (supported on gc880 and gc2000 at least), but not sure how it works.
> +   /* Figure out what tiling and address mode to use.
> +* Textures are TILED or LINEAR. If LINEAR_TEXTURE_SUPPORT capability is
> +* available LINEAR gets prefered.
>  * Buffers always have LINEAR layout.
>  */
> unsigned layout = ETNA_LAYOUT_LINEAR;
> @@ -334,6 +334,10 @@ etna_resource_create(struct pipe_screen *pscreen,
>  
>    if (util_format_is_compressed(templat->format))
>   layout = ETNA_LAYOUT_LINEAR;
> +  else if (VIV_FEATURE(screen, chipMinorFeatures1, 
> LINEAR_TEXTURE_SUPPORT)) {
> + layout = ETNA_LAYOUT_LINEAR;
> + mode = ETNA_ADDRESSING_MODE_LINEAR;
> +  }
> } else if (templat->target != PIPE_BUFFER) {
>    bool want_multitiled = false;
>    bool want_supertiled = screen->specs.can_supertile;
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_texture.c 
> b/src/gallium/drivers/etnaviv/etnaviv_texture.c
> index 3993e31cec1..b06f20531fd 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_texture.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_texture.c
> @@ -172,7 +172,9 @@ etna_resource_sampler_compatible(struct etna_resource 
> *res)
> if (res->layout == ETNA_LAYOUT_SUPER_TILED && VIV_FEATURE(screen, 
> chipMinorFeatures2, SUPERTILED_TEXTURE))
>    return true;
>  
> -   /* TODO: LINEAR_TEXTURE_SUPPORT */
> +   /* This GPU supports texturing from linear textures? */
> +   if (res->layout == ETNA_LAYOUT_LINEAR && VIV_FEATURE(screen, 
> chipMinorFeatures1, LINEAR_TEXTURE_SUPPORT))
> +  return true;

In order to avoid this sitting on the ML for too long while mostly
looking good: how would you feel about squashing this last hunk into
the previous patch and dropping the other parts of this patch for now?

This way we could have most of the stuff in master and do further
experiments about the performance implications later on. If you want to
do this, patches 1-3 are:

Reviewed-by: Lucas Stach 

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


Re: [Mesa-dev] [PATCH 2/4] etnaviv: keep track of mapped bo address

2019-02-22 Thread Lucas Stach
Am Freitag, den 22.02.2019, 10:18 +0100 schrieb Christian Gmeiner:
> Saves us from calling etna_bo_map(..) and saves us from doing the
> same offset calcs for map() and unmap() operations.
> 
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.h |  1 +
>  .../drivers/etnaviv/etnaviv_transfer.c| 19 ++-
>  2 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
> b/src/gallium/drivers/etnaviv/etnaviv_context.h
> index 6ad9f3431e1..45b3954c7cb 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
> @@ -70,6 +70,7 @@ struct etna_transfer {
> struct pipe_transfer base;
> struct pipe_resource *rsc;
> void *staging;
> +   void *mapped;
>  };
>  
>  struct etna_vertexbuf_state {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 0b7411b47ef..01da393d211 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -91,16 +91,15 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> pipe_transfer *ptrans)
>} else if (trans->staging) {
>   /* map buffer object */
>   struct etna_resource_level *res_level = &rsc->levels[ptrans->level];
> - void *mapped = etna_bo_map(rsc->bo) + res_level->offset;
>  
>   if (rsc->layout == ETNA_LAYOUT_TILED) {
>  etna_texture_tile(
> -   mapped + ptrans->box.z * res_level->layer_stride,
> +   trans->mapped + ptrans->box.z * res_level->layer_stride,
> trans->staging, ptrans->box.x, ptrans->box.y,
> res_level->stride, ptrans->box.width, ptrans->box.height,
> ptrans->stride, util_format_get_blocksize(rsc->base.format));
>   } else if (rsc->layout == ETNA_LAYOUT_LINEAR) {
> -util_copy_box(mapped, rsc->base.format, res_level->stride,
> +util_copy_box(trans->mapped, rsc->base.format, res_level->stride,
>res_level->layer_stride, ptrans->box.x,
>ptrans->box.y, ptrans->box.z, ptrans->box.width,
>ptrans->box.height, ptrans->box.depth,
> @@ -327,8 +326,8 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
> }
>  
> /* map buffer object */
> -   void *mapped = etna_bo_map(rsc->bo);
> -   if (!mapped)
> +   trans->mapped = etna_bo_map(rsc->bo);
> +   if (!trans->mapped)
>goto fail;
>  
> *out_transfer = ptrans;
> @@ -337,9 +336,11 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>ptrans->stride = res_level->stride;
>ptrans->layer_stride = res_level->layer_stride;
>  
> -  return mapped + res_level->offset +
> +  trans->mapped += res_level->offset +
>   etna_compute_offset(prsc->format, box, res_level->stride,
>   res_level->layer_stride);
> +
> +  return trans->mapped;
> } else {
>unsigned divSizeX = util_format_get_blockwidth(format);
>unsigned divSizeY = util_format_get_blockheight(format);
> @@ -350,7 +351,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>if (usage & PIPE_TRANSFER_MAP_DIRECTLY)
>   goto fail;
>  
> -  mapped += res_level->offset;
> +  trans->mapped += res_level->offset;
>ptrans->stride = align(box->width, divSizeX) * 
> util_format_get_blocksize(format); /* row stride in bytes */
>ptrans->layer_stride = align(box->height, divSizeY) * ptrans->stride;
>size_t size = ptrans->layer_stride * box->depth;
> @@ -362,7 +363,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>if (usage & PIPE_TRANSFER_READ) {
>   if (rsc->layout == ETNA_LAYOUT_TILED) {
>  etna_texture_untile(trans->staging,
> -mapped + ptrans->box.z * 
> res_level->layer_stride,
> +trans->mapped + ptrans->box.z * 
> res_level->layer_stride,
>  ptrans->box.x, ptrans->box.y, 
> res_level->stride,
>  ptrans->box.width, ptrans->box.height, 
> ptrans->stride,
>  util_form

Re: [Mesa-dev] [PATCH 3/4] etnaviv: hook-up etc2 patching

2019-02-22 Thread Lucas Stach
Am Freitag, den 22.02.2019, 10:18 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

AFAICS this is directly operating on the mapped buffer, right?

As ETC is stored as a linear, we won't get a temporary resource for the
transfer, but map the GPU resource directly. So this will fail in some
cases for read transfers, as both GPU and CPU are allowed to do reads
to the resource at the same time, but now your read transfer mutates
the GPU resource. If we don't want to have a full temporary resource to
operate on, at least the DRM_ETNA_PREP_WRITE needs to be set on
etna_bo_cpu_prep(), to avoid the GPU sampling from the resource that
gets mutated by the the transfer map.

Regards,
Lucas
 

> ---
>  .../drivers/etnaviv/etnaviv_resource.c|  3 ++
>  .../drivers/etnaviv/etnaviv_resource.h|  5 ++
>  .../drivers/etnaviv/etnaviv_transfer.c| 49 +++
>  3 files changed, 57 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index db5ead4d0ba..45d5f69169e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -478,6 +478,9 @@ etna_resource_destroy(struct pipe_screen *pscreen, struct 
> pipe_resource *prsc)
> pipe_resource_reference(&rsc->texture, NULL);
> pipe_resource_reference(&rsc->external, NULL);
>  
> +   for (unsigned i = 0; i < ETNA_NUM_LOD; i++)
> +  FREE(rsc->levels[i].patch_offsets);
> +
> FREE(rsc);
>  }
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 75aa80b3d7a..c45ff7586d1 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -33,6 +33,7 @@
>  #include "util/list.h"
>  
>  struct pipe_screen;
> +struct util_dynarray;
>  
>  struct etna_resource_level {
> unsigned width, padded_width; /* in pixels */
> @@ -47,6 +48,10 @@ struct etna_resource_level {
> uint32_t ts_size;
> uint32_t clear_value; /* clear value of resource level (mainly for TS) */
> bool ts_valid;
> +
> +   /* keep track if we have done some per block patching */
> +   bool patched;
> +   struct util_dynarray *patch_offsets;
>  };
>  
>  enum etna_resource_addressing_mode {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 01da393d211..119820d52b5 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -28,6 +28,7 @@
>  #include "etnaviv_clear_blit.h"
>  #include "etnaviv_context.h"
>  #include "etnaviv_debug.h"
> +#include "etnaviv_etc2.h"
>  #include "etnaviv_screen.h"
>  
>  #include "pipe/p_defines.h"
> @@ -57,6 +58,46 @@ etna_compute_offset(enum pipe_format format, const struct 
> pipe_box *box,
>   util_format_get_blocksize(format);
>  }
>  
> +static void etna_patch_data(void *buffer, const struct pipe_transfer *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = &rsc->levels[ptrans->level];
> +
> +   if (!etna_etc2_needs_patching(prsc))
> +  return;
> +
> +   if (level->patched)
> +  return;
> +
> +   /* do have the offsets of blocks to patch? */
> +   if (!level->patch_offsets) {
> +  level->patch_offsets = CALLOC_STRUCT(util_dynarray);
> +
> +  etna_etc2_calculate_blocks(buffer, ptrans->stride,
> + ptrans->box.width, 
> ptrans->box.height,
> + prsc->format, level->patch_offsets);
> +   }
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = true;
> +}
> +
> +static void etna_unpatch_data(void *buffer, const struct pipe_transfer 
> *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = &rsc->levels[ptrans->level];
> +
> +   if (!level->patched)
> +  return;
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = false;
> +}
> +
>  static void
>  etna_transfer_unmap(struct pipe_context *pctx, struct pipe_transfer *ptrans)
>  {
> @@ -119,6 +160,10 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> pipe_transfer *ptrans)
>}
> }
>  
> +   /* We need to have the patched data ready for the GPU. */
> +   if (rsc->layout == ETNA_LAYOUT_LINEAR)
> +  etna_patch_data(trans->mapped, ptrans);
> +
> /*
>  * Transfers without a temporary are only pulled into the CPU domain if 
> they
>  * are not mapped unsynchronized. If they are, must push them back into 
> GPU
> @@ -340,6 +385,10 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>   etna_compute_offset(prsc->format, box, res_le

Re: [Mesa-dev] etnaviv: rs: mark used src resource as read from

2019-02-22 Thread Lucas Stach
Am Freitag, den 22.02.2019, 11:02 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index fc4f65dbeee..a9d3872ad41 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -728,6 +728,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
> });
>  
> etna_submit_rs_state(ctx, ©_to_screen);
> +   resource_read(ctx, &src->base);
> resource_written(ctx, &dst->base);
> dst->seqno++;
> dst->levels[blit_info->dst.level].ts_valid = false;

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

Re: [Mesa-dev] [PATCH] etnaviv: blt: mark used src resource as read from

2019-02-22 Thread Lucas Stach
Am Freitag, den 22.02.2019, 11:10 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_blt.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_blt.c
> b/src/gallium/drivers/etnaviv/etnaviv_blt.c
> index 52731a9c770..42190d75d4e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_blt.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_blt.c
> @@ -510,7 +510,9 @@ etna_try_blt_blit(struct pipe_context *pctx,
> etna_stall(ctx->stream, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_BLT);
> etna_set_state(ctx->stream, VIVS_GL_FLUSH_CACHE, 0x0c23);
>  
> +   resource_read(ctx, &src->base);
> resource_written(ctx, &dst->base);
> +
> dst->seqno++;
> dst_lev->ts_valid = false;
>  

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

Re: [Mesa-dev] [PATCH v2 3/4] etnaviv: hook-up etc2 patching

2019-02-27 Thread Lucas Stach
Am Dienstag, den 26.02.2019, 19:15 +0100 schrieb Christian Gmeiner:
> Changes v1 -> v2:
>  - Avoid the GPU sampling from the resource that gets mutated by the the
>    transfer map by setting DRM_ETNA_PREP_WRITE.
> 
> > Signed-off-by: Christian Gmeiner 
> ---
>  .../drivers/etnaviv/etnaviv_resource.c|  3 +
>  .../drivers/etnaviv/etnaviv_resource.h|  5 ++
>  .../drivers/etnaviv/etnaviv_transfer.c| 55 +++
>  3 files changed, 63 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index db5ead4d0ba..45d5f69169e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -478,6 +478,9 @@ etna_resource_destroy(struct pipe_screen *pscreen, struct 
> pipe_resource *prsc)
> pipe_resource_reference(&rsc->texture, NULL);
> pipe_resource_reference(&rsc->external, NULL);
>  
> +   for (unsigned i = 0; i < ETNA_NUM_LOD; i++)
> +  FREE(rsc->levels[i].patch_offsets);
> +
> FREE(rsc);
>  }
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 75aa80b3d7a..c45ff7586d1 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -33,6 +33,7 @@
>  #include "util/list.h"
>  
>  struct pipe_screen;
> +struct util_dynarray;
>  
>  struct etna_resource_level {
> unsigned width, padded_width; /* in pixels */
> @@ -47,6 +48,10 @@ struct etna_resource_level {
> uint32_t ts_size;
> uint32_t clear_value; /* clear value of resource level (mainly for TS) */
> bool ts_valid;
> +
> +   /* keep track if we have done some per block patching */
> +   bool patched;
> +   struct util_dynarray *patch_offsets;
>  };
>  
>  enum etna_resource_addressing_mode {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 01da393d211..9a83c481dce 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -28,6 +28,7 @@
>  #include "etnaviv_clear_blit.h"
>  #include "etnaviv_context.h"
>  #include "etnaviv_debug.h"
> +#include "etnaviv_etc2.h"
>  #include "etnaviv_screen.h"
>  
>  #include "pipe/p_defines.h"
> @@ -57,6 +58,46 @@ etna_compute_offset(enum pipe_format format, const struct 
> pipe_box *box,
>   util_format_get_blocksize(format);
>  }
>  
> +static void etna_patch_data(void *buffer, const struct pipe_transfer *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = &rsc->levels[ptrans->level];
> +
> +   if (!etna_etc2_needs_patching(prsc))

Maybe likely() here?

> +  return;
> +
> +   if (level->patched)
> +  return;
> +
> +   /* do have the offsets of blocks to patch? */
> +   if (!level->patch_offsets) {
> +  level->patch_offsets = CALLOC_STRUCT(util_dynarray);
> +
> +  etna_etc2_calculate_blocks(buffer, ptrans->stride,
> + ptrans->box.width, 
> ptrans->box.height,
> + prsc->format, level->patch_offsets);
> +   }
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = true;
> +}
> +
> +static void etna_unpatch_data(void *buffer, const struct pipe_transfer 
> *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = &rsc->levels[ptrans->level];
> +
> +   if (!level->patched)
> +  return;
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = false;
> +}
> +
>  static void
>  etna_transfer_unmap(struct pipe_context *pctx, struct pipe_transfer *ptrans)
>  {
> @@ -119,6 +160,10 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> pipe_transfer *ptrans)
>    }
> }
>  
> +   /* We need to have the patched data ready for the GPU. */
> +   if (rsc->layout == ETNA_LAYOUT_LINEAR)

I don't like the LAYOUT_LINEAR checks here, as GC3000 actually has a
feature bit TEX_COMPRESSION_SUPERTILED, so I don't think the assertion
that all compressed formats are linear will hold in the future and it
seems like a minor optimization.

> +  etna_patch_data(trans->mapped, ptrans);
> +
> /*
>  * Transfers without a temporary are only pulled into the CPU domain if 
> they
>  * are not mapped unsynchronized. If they are, must push them back into 
> GPU
> @@ -321,6 +366,12 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>    if (usage & PIPE_TRANSFER_WRITE)
>   prep_flags |= DRM_ETNA_PREP_WRITE;
>  
> +  /* avoid the GPU sampling from the resource that gets mutated */

This doesn't really explain to the reader of this function what happens
here. Maybe 

Re: [Mesa-dev] [PATCH v2 1/4] etnaviv: implement ETC2 block patching for HALTI0

2019-02-27 Thread Lucas Stach
Am Dienstag, den 26.02.2019, 19:15 +0100 schrieb Christian Gmeiner:
> ETC2 is supported with HALTI0, however that implementation is buggy
> in hardware. The blob driver does per-block patching to work around
> this. We need to swap colors for t-mode etc2 blocks.
> 
> > Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/drivers/etnaviv/Makefile.sources |   2 +
>  src/gallium/drivers/etnaviv/etnaviv_etc2.c   | 149 +++
>  src/gallium/drivers/etnaviv/etnaviv_etc2.h   |  51 +++
>  src/gallium/drivers/etnaviv/meson.build  |   2 +
>  4 files changed, 204 insertions(+)
>  create mode 100644 src/gallium/drivers/etnaviv/etnaviv_etc2.c
>  create mode 100644 src/gallium/drivers/etnaviv/etnaviv_etc2.h
> 
> diff --git a/src/gallium/drivers/etnaviv/Makefile.sources 
> b/src/gallium/drivers/etnaviv/Makefile.sources
> index 0b208122999..01e7e49a38a 100644
> --- a/src/gallium/drivers/etnaviv/Makefile.sources
> +++ b/src/gallium/drivers/etnaviv/Makefile.sources
> @@ -25,6 +25,8 @@ C_SOURCES :=  \
> >     etnaviv_disasm.h \
> >     etnaviv_emit.c \
> >     etnaviv_emit.h \
> > +   etnaviv_etc2.c \
> > +   etnaviv_etc2.h \
> >     etnaviv_fence.c \
> >     etnaviv_fence.h \
> >     etnaviv_format.c \
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_etc2.c 
> b/src/gallium/drivers/etnaviv/etnaviv_etc2.c
> new file mode 100644
> index 000..64811c3038d
> --- /dev/null
> +++ b/src/gallium/drivers/etnaviv/etnaviv_etc2.c
> @@ -0,0 +1,149 @@
> +/*
> + * Copyright (c) 2019 Etnaviv Project
> + * Copyright (C) 2019 Zodiac Inflight Innovations
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sub license,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Authors:
> > + *Christian Gmeiner 
> + */
> +
> +#include "etnaviv_etc2.h"
> +#include "etnaviv_resource.h"
> +#include "etnaviv_screen.h"
> +#include "hw/common.xml.h"
> +#include "util/u_format.h"
> +
> +bool
> +etna_etc2_needs_patching(const struct pipe_resource *prsc)
> +{
> +   const struct etna_screen *screen = etna_screen(prsc->screen);
> +
> +   if (!util_format_is_etc(prsc->format))
> +  return false;
> +
> +   if (prsc->format == PIPE_FORMAT_ETC1_RGB8)
> +  return false;

Isn't this format check redundant with the default case of the switch
below?

Other than that:

Acked-by: Lucas Stach 

Regards,
Lucas


> +   if (VIV_FEATURE(screen, chipMinorFeatures2, HALTI1))
> +  return false;
> +
> +   switch (prsc->format) {
> +   case PIPE_FORMAT_ETC2_RGB8:
> +   case PIPE_FORMAT_ETC2_SRGB8:
> +   case PIPE_FORMAT_ETC2_RGB8A1:
> +   case PIPE_FORMAT_ETC2_SRGB8A1:
> +   case PIPE_FORMAT_ETC2_RGBA8:
> +   case PIPE_FORMAT_ETC2_SRGBA8:
> +  return true;
> +  break;
> +
> +   default:
> +  return false;
> +   }
> +}
> +
> +static inline bool
> +needs_patching(uint8_t *buffer, bool punchthrough_alpha)
> +{
> +   /* punchthrough_alpha or etc2 individual mode? */
> +   if (!punchthrough_alpha && !(buffer[3] & 0x2))
> + return false;
> +
> +   /* etc2 t-mode? */
> +   static const int lookup[8] = { 0, 1, 2, 3, -4, -3, -2, -1 };
> +   const int R_plus_dR = (buffer[0] >> 3) + lookup[buffer[0] & 0x7];
> +
> +   if (R_plus_dR < 0 || R_plus_dR > 31)
> +  return true;
> +
> +   return false;
> +}
> +
> +void
> +etna_etc2_calculate_blocks(uint8_t *buffer, unsigned stride,
> +   unsigned width, unsigned height,
> +   enum pipe_format format,
>

Re: [Mesa-dev] [PATCH v2 4/4] etnaviv: enable ETC2 texture compression support for HALTI0 GPUs

2019-02-27 Thread Lucas Stach
Am Dienstag, den 26.02.2019, 19:15 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_screen.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index de822fc85ca..ee32a499fb5 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -518,19 +518,9 @@ gpu_supports_texure_format(struct etna_screen *screen, 
> uint32_t fmt,
> if (util_format_is_srgb(format))
>    supported = VIV_FEATURE(screen, chipMinorFeatures1, HALTI0);
>  
> -   if (fmt & EXT_FORMAT) {
> +   if (fmt & EXT_FORMAT)
>    supported = VIV_FEATURE(screen, chipMinorFeatures1, HALTI0);
>  
> -  /* ETC1 is checked above, as it has its own feature bit. ETC2 is
> -   * supported with HALTI0, however that implementation is buggy in 
> hardware.
> -   * The blob driver does per-block patching to work around this. As this
> -   * is currently not implemented by etnaviv, enable it for HALTI1 
> (GC3000)
> -   * only.
> -   */
> -  if (util_format_is_etc(format))
> - supported = VIV_FEATURE(screen, chipMinorFeatures2, HALTI1);
> -   }
> -
> if (fmt & ASTC_FORMAT) {
>    supported = screen->specs.tex_astc;
> }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 3/4] etnaviv: hook-up etc2 patching

2019-02-27 Thread Lucas Stach
Am Donnerstag, den 28.02.2019, 07:26 +0100 schrieb Christian Gmeiner:
> Changes v1 -> v2:
>  - Avoid the GPU sampling from the resource that gets mutated by the the
>transfer map by setting DRM_ETNA_PREP_WRITE.
> 
> Changes v2 -> v3:
>  - make use of likely(..)
>  - drop minor optimization regarding rsc->layout == ETNA_LAYOUT_LINEAR
>  - better documentation why DRM_ETNA_PREP_WRITE is needed
> 
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  .../drivers/etnaviv/etnaviv_resource.c|  3 +
>  .../drivers/etnaviv/etnaviv_resource.h|  5 ++
>  .../drivers/etnaviv/etnaviv_transfer.c| 56 +++
>  3 files changed, 64 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index db5ead4d0ba..45d5f69169e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -478,6 +478,9 @@ etna_resource_destroy(struct pipe_screen *pscreen, struct 
> pipe_resource *prsc)
> pipe_resource_reference(&rsc->texture, NULL);
> pipe_resource_reference(&rsc->external, NULL);
>  
> +   for (unsigned i = 0; i < ETNA_NUM_LOD; i++)
> +  FREE(rsc->levels[i].patch_offsets);
> +
> FREE(rsc);
>  }
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 75aa80b3d7a..c45ff7586d1 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -33,6 +33,7 @@
>  #include "util/list.h"
>  
>  struct pipe_screen;
> +struct util_dynarray;
>  
>  struct etna_resource_level {
> unsigned width, padded_width; /* in pixels */
> @@ -47,6 +48,10 @@ struct etna_resource_level {
> uint32_t ts_size;
> uint32_t clear_value; /* clear value of resource level (mainly for TS) */
> bool ts_valid;
> +
> +   /* keep track if we have done some per block patching */
> +   bool patched;
> +   struct util_dynarray *patch_offsets;
>  };
>  
>  enum etna_resource_addressing_mode {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 01da393d211..3b925a8ef9f 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -28,6 +28,7 @@
>  #include "etnaviv_clear_blit.h"
>  #include "etnaviv_context.h"
>  #include "etnaviv_debug.h"
> +#include "etnaviv_etc2.h"
>  #include "etnaviv_screen.h"
>  
>  #include "pipe/p_defines.h"
> @@ -57,6 +58,46 @@ etna_compute_offset(enum pipe_format format, const struct 
> pipe_box *box,
>   util_format_get_blocksize(format);
>  }
>  
> +static void etna_patch_data(void *buffer, const struct pipe_transfer *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = &rsc->levels[ptrans->level];
> +
> +   if (likely(!etna_etc2_needs_patching(prsc)))
> +  return;
> +
> +   if (level->patched)
> +  return;
> +
> +   /* do have the offsets of blocks to patch? */
> +   if (!level->patch_offsets) {
> +  level->patch_offsets = CALLOC_STRUCT(util_dynarray);
> +
> +  etna_etc2_calculate_blocks(buffer, ptrans->stride,
> + ptrans->box.width, 
> ptrans->box.height,
> + prsc->format, level->patch_offsets);
> +   }
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = true;
> +}
> +
> +static void etna_unpatch_data(void *buffer, const struct pipe_transfer 
> *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = &rsc->levels[ptrans->level];
> +
> +   if (!level->patched)
> +  return;
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = false;
> +}
> +
>  static void
>  etna_transfer_unmap(struct pipe_context *pctx, struct pipe_transfer *ptrans)
>  {
> @@ -119,6 +160,9 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> pipe_transfer *ptrans)
>}
> }
>  
> +   /* We need to have the patched data ready for the GPU. */
> +   etna_patch_data(trans->mapped, ptrans);
> +
> /*
>  * Transfers without a temporary are only pulled into 

[Mesa-dev] [PATCH RFC 2/2] GBM: use KMS device to allocate scanout and cursor BOs

2016-03-04 Thread Lucas Stach
If we have a KMS device which is distinct to the render GBM
device, try to allocate cursor and scanout BOs from this device.

Right now this only makes sure that the selected format is
compatible with both devices. We need more internal API to
signal width/height/stride and tiling constraints.

Signed-off-by: Lucas Stach 
---
 src/gbm/main/gbm.c| 77 +--
 src/gbm/main/gbmint.h |  1 +
 2 files changed, 69 insertions(+), 9 deletions(-)

diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 26339747f3a1..74f0bdb6d0f1 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -87,7 +87,18 @@ GBM_EXPORT int
 gbm_device_is_format_supported(struct gbm_device *gbm,
uint32_t format, uint32_t usage)
 {
-   return gbm->is_format_supported(gbm, format, usage);
+   /*
+* If there is a KMS provider, scanout formats must be supported by both the
+* KMS and the render device, cursor formats only by the KMS device.
+*/
+   if (gbm->kms_provider && (usage & GBM_BO_USE_CURSOR))
+  return gbm->kms_provider->is_format_supported(gbm->kms_provider,
+format, usage);
+   else if (gbm->kms_provider && (usage & GBM_BO_USE_SCANOUT))
+  return gbm->kms_provider->is_format_supported(gbm->kms_provider,
+   format, usage) && gbm->is_format_supported(gbm, format, usage);
+   else
+  return gbm->is_format_supported(gbm, format, usage);
 }
 
 /** Set the KMS provider device used for scanout and cursor BO allocations
@@ -339,6 +350,9 @@ gbm_bo_destroy(struct gbm_bo *bo)
if (bo->destroy_user_data)
   bo->destroy_user_data(bo, bo->user_data);
 
+   if (bo->prime_bo)
+  bo->prime_bo->gbm->bo_destroy(bo->prime_bo);
+
bo->gbm->bo_destroy(bo);
 }
 
@@ -363,17 +377,54 @@ gbm_bo_create(struct gbm_device *gbm,
   uint32_t width, uint32_t height,
   uint32_t format, uint32_t usage)
 {
-   struct gbm_bo *bo;
-
if (width == 0 || height == 0) {
   errno = EINVAL;
   return NULL;
}
 
-   bo = gbm->bo_create(gbm, width, height, format, usage);
-   bo->type = GBM_BO_TYPE_RENDER | GBM_BO_TYPE_KMS;
+   if (gbm->kms_provider && (usage & GBM_BO_USE_CURSOR)) {
+  struct gbm_bo *bo = gbm->kms_provider->bo_create(gbm->kms_provider, 
width,
+   height, format, usage);
+  bo->type = GBM_BO_TYPE_KMS;
+  return bo;
+   }
+
+   if (gbm->kms_provider && (usage & GBM_BO_USE_SCANOUT)) {
+  struct gbm_bo *kms_bo, *render_bo;
+  struct gbm_import_fd_data import_data;
+
+  /* FIXME: we need a way to communicate constraints here */
+  kms_bo = gbm->kms_provider->bo_create(gbm->kms_provider, width, height,
+format, usage);
+  if (!kms_bo)
+ return NULL;
+
+  kms_bo->type = GBM_BO_TYPE_KMS;
+
+  import_data.fd = gbm_bo_get_fd(kms_bo);
+  import_data.format = gbm_bo_get_format(kms_bo);
+  import_data.height = gbm_bo_get_height(kms_bo);
+  import_data.width = gbm_bo_get_width(kms_bo);
+  import_data.stride = gbm_bo_get_stride(kms_bo);
+
+  render_bo = gbm->bo_import(gbm, GBM_BO_IMPORT_FD, &import_data, usage);
+  close(import_data.fd);
+  if (!render_bo) {
+ gbm->kms_provider->bo_destroy(kms_bo);
+ return NULL;
+  }
+  render_bo->type = GBM_BO_TYPE_RENDER;
 
-   return bo;
+  /* link bos together, so we know they represent the same thing */
+  render_bo->prime_bo = kms_bo;
+  kms_bo->prime_bo = render_bo;
+
+  return render_bo;
+   } else {
+  struct gbm_bo *bo = gbm->bo_create(gbm, width, height, format, usage);
+  bo->type = GBM_BO_TYPE_KMS | GBM_BO_TYPE_RENDER;
+  return bo;
+   }
 }
 
 /**
@@ -412,10 +463,13 @@ gbm_bo_import(struct gbm_device *gbm,
 GBM_EXPORT struct gbm_bo *
 gbm_bo_get_kms_bo(struct gbm_bo *bo)
 {
-   if (!bo || !(bo->type & GBM_BO_TYPE_KMS))
+   if (!bo)
   return NULL;
 
-   return bo;
+   if (bo->type & GBM_BO_TYPE_KMS)
+  return bo;
+   else
+  return bo->prime_bo;
 }
 
 /**
@@ -497,7 +551,12 @@ gbm_surface_lock_front_buffer(struct gbm_surface *surf)
 GBM_EXPORT void
 gbm_surface_release_buffer(struct gbm_surface *surf, struct gbm_bo *bo)
 {
-   surf->gbm->surface_release_buffer(surf, bo);
+   struct gbm_bo *release_bo = bo;
+
+   if (!(bo->type & GBM_BO_TYPE_RENDER))
+  release_bo = bo->prime_bo;
+
+   surf->gbm->surface_release_buffer(surf, release_bo);
 }
 
 /**
diff --git a/src/gbm/main/gbmint.h b/src/gbm/main/gbmint.h
index 218ecf66c0fd..17438141da50 100644
--- a/src/gbm/main/gbmint.h
+++ b/src/gbm/main/gbmint.h
@@ -101,6 +101,7 @@ struct gbm_bo {
union gb

[Mesa-dev] [PATCH RFC 1/2] GBM: add KMS provider interface

2016-03-04 Thread Lucas Stach
The GBM device, which is used to bootstrap the EGL context
should always be constructed atop a render capable DRM device.
If this device is a render node or a standalone renderonly DRM
device, we need a way to set the actual KMS output device to
allow for proper allocations of the buffer objects backing the
window surface and hiding the needed PRIME import/export.

This interface allows this by constructing a second GBM device
on top of the KMS capable DRM device and binding this as the
KMS provider to the render GBM device.

Signed-off-by: Lucas Stach 
---
 src/gbm/main/gbm.c| 35 ++-
 src/gbm/main/gbm.h|  7 +++
 src/gbm/main/gbmint.h |  5 +
 3 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index c046b1ad7c8a..26339747f3a1 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -90,6 +90,25 @@ gbm_device_is_format_supported(struct gbm_device *gbm,
return gbm->is_format_supported(gbm, format, usage);
 }
 
+/** Set the KMS provider device used for scanout and cursor BO allocations
+ *
+ * \param gbm The created buffer manager
+ * \param provider The buffer manager that should be used for KMS buffers
+ * \return 0 if successful
+ */
+GBM_EXPORT int
+gbm_device_set_kms_provider(struct gbm_device *gbm,
+struct gbm_device *provider)
+{
+   /* Changing the provider on the fly is not supported */
+   if (gbm->kms_provider)
+  return -1;
+   else
+  gbm->kms_provider = provider;
+
+   return 0;
+}
+
 /** Destroy the gbm device and free all resources associated with it.
  *
  * \param gbm The device created using gbm_create_device()
@@ -344,12 +363,17 @@ gbm_bo_create(struct gbm_device *gbm,
   uint32_t width, uint32_t height,
   uint32_t format, uint32_t usage)
 {
+   struct gbm_bo *bo;
+
if (width == 0 || height == 0) {
   errno = EINVAL;
   return NULL;
}
 
-   return gbm->bo_create(gbm, width, height, format, usage);
+   bo = gbm->bo_create(gbm, width, height, format, usage);
+   bo->type = GBM_BO_TYPE_RENDER | GBM_BO_TYPE_KMS;
+
+   return bo;
 }
 
 /**
@@ -385,6 +409,15 @@ gbm_bo_import(struct gbm_device *gbm,
return gbm->bo_import(gbm, type, buffer, usage);
 }
 
+GBM_EXPORT struct gbm_bo *
+gbm_bo_get_kms_bo(struct gbm_bo *bo)
+{
+   if (!bo || !(bo->type & GBM_BO_TYPE_KMS))
+  return NULL;
+
+   return bo;
+}
+
 /**
  * Allocate a surface object
  *
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index 8db2153e84bb..1faff360130b 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -226,6 +226,10 @@ int
 gbm_device_is_format_supported(struct gbm_device *gbm,
uint32_t format, uint32_t usage);
 
+int
+gbm_device_set_kms_provider(struct gbm_device *gbm,
+struct gbm_device *provider);
+
 void
 gbm_device_destroy(struct gbm_device *gbm);
 
@@ -274,6 +278,9 @@ gbm_bo_get_handle(struct gbm_bo *bo);
 int
 gbm_bo_get_fd(struct gbm_bo *bo);
 
+struct gbm_bo *
+gbm_bo_get_kms_bo(struct gbm_bo *bo);
+
 int
 gbm_bo_write(struct gbm_bo *bo, const void *buf, size_t count);
 
diff --git a/src/gbm/main/gbmint.h b/src/gbm/main/gbmint.h
index 155eb12b06bc..218ecf66c0fd 100644
--- a/src/gbm/main/gbmint.h
+++ b/src/gbm/main/gbmint.h
@@ -52,6 +52,7 @@ struct gbm_device {
/* Hack to make a gbm_device detectable by its first element. */
struct gbm_device *(*dummy)(int);
 
+   struct gbm_device *kms_provider;
int fd;
const char *name;
unsigned int refcount;
@@ -87,8 +88,12 @@ struct gbm_device {
  *
  * The members in this structure should not be accessed directly.
  */
+#define GBM_BO_TYPE_KMS(1 << 0)
+#define GBM_BO_TYPE_RENDER (1 << 1)
+
 struct gbm_bo {
struct gbm_device *gbm;
+   uint32_t type;
uint32_t width;
uint32_t height;
uint32_t stride;
-- 
2.7.0

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


[Mesa-dev] [PATCH RFC 0/2] GBM API extension to support fusing KMS and render devices

2016-03-04 Thread Lucas Stach
Hi all,

this is a first shot at trying to hash out an API to allow bootstrapping
an EGL context on top of split render/scanout DRM devices. It tries to make
things really easy for applications, while leaving them in full control over
swap/flip scheduling etc.

It adds 2 new API calls:

1. gbm_device_set_kms_provider()
   This is used to add a KMS device to the render GBM device.
2. gbm_bo_get_kms_bo()
   This should be used by applications to translate the buffer returned
   by gbm_surface_lock_front_buffer() into a buffer that can be used to
   construct DRM FBs.

The design requires a DRI2/Gallium driver to be present for the KMS
device, so we can construct a GBM device on top of it. This is then
coupled to the render GBM device. Some ASCII art to visualize it:

 EGLSurface
 |
 v
  gbm_surface_create
 |
 v
  gbm_device_set_kms_provider
  v  |
 GBM device  v
 (minimal gallium driver)GBM device
 |   |
 v   v
 --
 (imx-drm)   (etnaviv)
(tegra-drm)  (nouveau)

While this currently does not do any negotiation about BO
width/height/stride/tiling constraints, it makes it clear that the single
place where this needs to happen is within GBM.

This API is really easy to use from an application POV (the patch to
convert the QT5.6 eglfs_kms backend to use this is less than 100LOC).
I have this running on top of a simple imx-drm gallium driver and etnaviv,
both of which are not upstream yet. I can provide git repos for those
components if necessary.

I hope that the Tegra guys can help to move things forward and would like
to hear from you if this design sounds sane to all of you.

Regards,
Lucas

Lucas Stach (2):
  GBM: add KMS provider interface
  GBM: use KMS device to allocate scanout and cursor BOs

 src/gbm/main/gbm.c| 98 +--
 src/gbm/main/gbm.h|  7 
 src/gbm/main/gbmint.h |  6 
 3 files changed, 108 insertions(+), 3 deletions(-)

-- 
2.7.0

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


Re: [Mesa-dev] [PATCH RFC 0/2] GBM API extension to support fusing KMS and render devices

2016-03-04 Thread Lucas Stach
Am Freitag, den 04.03.2016, 15:09 + schrieb Daniel Stone:
> Hi Lucas,
> 
> On 4 March 2016 at 13:49, Lucas Stach  wrote:
> > this is a first shot at trying to hash out an API to allow bootstrapping
> > an EGL context on top of split render/scanout DRM devices. It tries to make
> > things really easy for applications, while leaving them in full control over
> > swap/flip scheduling etc.
> >
> > It adds 2 new API calls:
> >
> > 1. gbm_device_set_kms_provider()
> >This is used to add a KMS device to the render GBM device.
> > 2. gbm_bo_get_kms_bo()
> >This should be used by applications to translate the buffer returned
> >by gbm_surface_lock_front_buffer() into a buffer that can be used to
> >construct DRM FBs.
> 
> Thanks for taking this on, it looks really good! I just have the one
> question though - did you look at the EGLDevice extension? Using that
> to enumerate the GPUs, we could create the gbm_device using the KMS
> device and pass that in to the EGLDisplay, with an additional attrib
> to pass in an EGLDevice handle to eglGetPlatformDisplay. This could
> possibly be better since it is more independent of DRM as the API, and
> also allows people to share device enumeration/selection code with
> other platforms (e.g. choosing between multiple GPUs when using a
> winsys like Wayland or X11).
> 
I have not looked at this in detail yet, but I think it's just an
extension to the interface outlined by this series.

If we require the KMS device to have a DRI2/Gallium driver it should be
easy to hook up the EGLDevice discovery for them.
Passing in a second device handle for the KMS device is then just the
EGL implementation calling gbm_device_set_kms_provider() on the render
GBM device, instead of the application doing it manually.

Regards,
Lucas



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


Re: [Mesa-dev] [PATCH RFC 0/2] GBM API extension to support fusing KMS and render devices

2016-03-04 Thread Lucas Stach
Am Freitag, den 04.03.2016, 17:20 + schrieb Daniel Stone:
> Hi,
> 
> On 4 March 2016 at 16:08, Lucas Stach  wrote:
> > Am Freitag, den 04.03.2016, 15:09 + schrieb Daniel Stone:
> >> Thanks for taking this on, it looks really good! I just have the one
> >> question though - did you look at the EGLDevice extension? Using that
> >> to enumerate the GPUs, we could create the gbm_device using the KMS
> >> device and pass that in to the EGLDisplay, with an additional attrib
> >> to pass in an EGLDevice handle to eglGetPlatformDisplay. This could
> >> possibly be better since it is more independent of DRM as the API, and
> >> also allows people to share device enumeration/selection code with
> >> other platforms (e.g. choosing between multiple GPUs when using a
> >> winsys like Wayland or X11).
> >>
> > I have not looked at this in detail yet, but I think it's just an
> > extension to the interface outlined by this series.
> >
> > If we require the KMS device to have a DRI2/Gallium driver it should be
> > easy to hook up the EGLDevice discovery for them.
> > Passing in a second device handle for the KMS device is then just the
> > EGL implementation calling gbm_device_set_kms_provider() on the render
> > GBM device, instead of the application doing it manually.
> 
> It turns the API backwards a bit though ...
> 
> Right now, what we require is that the GBM device passed in is the KMS
> device, not the GPU device; what you're suggesting is that we discover
> the GPU device and then add the KMS device.
> 
> So, with your proposal:
> gbm_gpu = gbm_device_create("/dev/dri/renderD128");
> egl_dpy = eglGetDisplay(gbm_gpu);
> gbm_kms = gbm_device_create("/dev/dri/card0");
> gbm_device_set_kms_provider(gbm_gpu, gbm_kms);
> 
> i.e. the device the user creates first is the GPU device.
> 
> With EGLDevice, we would have:
> gbm_kms = gbm_device_create("/dev/dri/card0");
> egl_gpus = eglGetDevicesEXT();
> egl_dpy = eglGetPlatformDisplay(gbm_kms, { EGL_TARGET_DEVICE, egl_gpus[0] });
> 
> So, the first/main device the user deals with is the KMS device - same
> as today. This makes sense, since GBM is the allocation API for KMS,
> and EGL should be the one dealing with the GPU ...
> 
Right, my API design was from my view of GBM being the API to bootstrap
EGL rendering, but defining it as the KMS allocation API makes a lot
more sense, when you think about it.

> Maybe it would make sense to reverse the API, so rather than creating
> a GBM device for the GPU and then linking that to the KMS device -
> requiring users to make different calls, e.g. gbm_bo_get_kms_bo(),
> which makes it harder to use and means we need to port current users -
> we create a GBM device for KMS and then link that to a GPU device.
> This would then mean that eglGetPlatformDisplay could do the linkage
> internally, and then existing users using gbm_bo_get_handle() etc
> would still work without needing any different codepaths.

Yes, this will make the implementation inside GBM a bit more involved,
but it seems more natural this way around when thinking about hooking it
up to EGLDevice. I'll try it out and send an updated RFC after the
weekend.

Regards,
Lucas

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


Re: [Mesa-dev] [PATCH RFC 0/2] GBM API extension to support fusing KMS and render devices

2016-03-07 Thread Lucas Stach
Am Freitag, den 04.03.2016, 18:34 + schrieb Emil Velikov:
> On 4 March 2016 at 17:38, Lucas Stach  wrote:
> > Am Freitag, den 04.03.2016, 17:20 + schrieb Daniel Stone:
> >> Hi,
> >>
> >> On 4 March 2016 at 16:08, Lucas Stach  wrote:
> >> > Am Freitag, den 04.03.2016, 15:09 + schrieb Daniel Stone:
> >> >> Thanks for taking this on, it looks really good! I just have the one
> >> >> question though - did you look at the EGLDevice extension? Using that
> >> >> to enumerate the GPUs, we could create the gbm_device using the KMS
> >> >> device and pass that in to the EGLDisplay, with an additional attrib
> >> >> to pass in an EGLDevice handle to eglGetPlatformDisplay. This could
> >> >> possibly be better since it is more independent of DRM as the API, and
> >> >> also allows people to share device enumeration/selection code with
> >> >> other platforms (e.g. choosing between multiple GPUs when using a
> >> >> winsys like Wayland or X11).
> >> >>
> >> > I have not looked at this in detail yet, but I think it's just an
> >> > extension to the interface outlined by this series.
> >> >
> >> > If we require the KMS device to have a DRI2/Gallium driver it should be
> >> > easy to hook up the EGLDevice discovery for them.
> >> > Passing in a second device handle for the KMS device is then just the
> >> > EGL implementation calling gbm_device_set_kms_provider() on the render
> >> > GBM device, instead of the application doing it manually.
> >>
> >> It turns the API backwards a bit though ...
> >>
> >> Right now, what we require is that the GBM device passed in is the KMS
> >> device, not the GPU device; what you're suggesting is that we discover
> >> the GPU device and then add the KMS device.
> >>
> >> So, with your proposal:
> >> gbm_gpu = gbm_device_create("/dev/dri/renderD128");
> >> egl_dpy = eglGetDisplay(gbm_gpu);
> >> gbm_kms = gbm_device_create("/dev/dri/card0");
> >> gbm_device_set_kms_provider(gbm_gpu, gbm_kms);
> >>
> >> i.e. the device the user creates first is the GPU device.
> >>
> >> With EGLDevice, we would have:
> >> gbm_kms = gbm_device_create("/dev/dri/card0");
> >> egl_gpus = eglGetDevicesEXT();
> >> egl_dpy = eglGetPlatformDisplay(gbm_kms, { EGL_TARGET_DEVICE, egl_gpus[0] 
> >> });
> >>
> >> So, the first/main device the user deals with is the KMS device - same
> >> as today. This makes sense, since GBM is the allocation API for KMS,
> >> and EGL should be the one dealing with the GPU ...
> >>
> > Right, my API design was from my view of GBM being the API to bootstrap
> > EGL rendering, but defining it as the KMS allocation API makes a lot
> > more sense, when you think about it.
> >
> >> Maybe it would make sense to reverse the API, so rather than creating
> >> a GBM device for the GPU and then linking that to the KMS device -
> >> requiring users to make different calls, e.g. gbm_bo_get_kms_bo(),
> >> which makes it harder to use and means we need to port current users -
> >> we create a GBM device for KMS and then link that to a GPU device.
> >> This would then mean that eglGetPlatformDisplay could do the linkage
> >> internally, and then existing users using gbm_bo_get_handle() etc
> >> would still work without needing any different codepaths.
> >
> > Yes, this will make the implementation inside GBM a bit more involved,
> > but it seems more natural this way around when thinking about hooking it
> > up to EGLDevice. I'll try it out and send an updated RFC after the
> > weekend.
> >
> While I'm more inclined to Daniel's suggestion, I wonder why people
> moved away from Thierry's approach - creating a composite/wrapped dri
> module ? Is there anything wrong with it - be that from technical or
> conceptual POV ?
> 
The wrapped driver takes away the ability of the application to decide
which GPUs to bind together - at least if you want to keep things
tightly coupled at that level.

The point of the explicit application control is that we not only solve
the "SoCs have split render/scanout devices" issue, but gain an API for
compositors to work properly on PRIME laptop configurations with
render/render/scanout. We don't want any autodetection to happen there,
a compositor may well decide to use the Intel GPU as scanout only and do
all composition on the di

Re: [Mesa-dev] [PATCH RFC 0/2] GBM API extension to support fusing KMS and render devices

2016-03-07 Thread Lucas Stach
Am Montag, den 07.03.2016, 11:19 +0100 schrieb Thierry Reding:
> On Mon, Mar 07, 2016 at 10:46:52AM +0100, Lucas Stach wrote:
> > Am Freitag, den 04.03.2016, 18:34 + schrieb Emil Velikov:
> > > On 4 March 2016 at 17:38, Lucas Stach  wrote:
> > > > Am Freitag, den 04.03.2016, 17:20 + schrieb Daniel Stone:
> > > >> Hi,
> > > >>
> > > >> On 4 March 2016 at 16:08, Lucas Stach  wrote:
> > > >> > Am Freitag, den 04.03.2016, 15:09 + schrieb Daniel Stone:
> > > >> >> Thanks for taking this on, it looks really good! I just have the one
> > > >> >> question though - did you look at the EGLDevice extension? Using 
> > > >> >> that
> > > >> >> to enumerate the GPUs, we could create the gbm_device using the KMS
> > > >> >> device and pass that in to the EGLDisplay, with an additional attrib
> > > >> >> to pass in an EGLDevice handle to eglGetPlatformDisplay. This could
> > > >> >> possibly be better since it is more independent of DRM as the API, 
> > > >> >> and
> > > >> >> also allows people to share device enumeration/selection code with
> > > >> >> other platforms (e.g. choosing between multiple GPUs when using a
> > > >> >> winsys like Wayland or X11).
> > > >> >>
> > > >> > I have not looked at this in detail yet, but I think it's just an
> > > >> > extension to the interface outlined by this series.
> > > >> >
> > > >> > If we require the KMS device to have a DRI2/Gallium driver it should 
> > > >> > be
> > > >> > easy to hook up the EGLDevice discovery for them.
> > > >> > Passing in a second device handle for the KMS device is then just the
> > > >> > EGL implementation calling gbm_device_set_kms_provider() on the 
> > > >> > render
> > > >> > GBM device, instead of the application doing it manually.
> > > >>
> > > >> It turns the API backwards a bit though ...
> > > >>
> > > >> Right now, what we require is that the GBM device passed in is the KMS
> > > >> device, not the GPU device; what you're suggesting is that we discover
> > > >> the GPU device and then add the KMS device.
> > > >>
> > > >> So, with your proposal:
> > > >> gbm_gpu = gbm_device_create("/dev/dri/renderD128");
> > > >> egl_dpy = eglGetDisplay(gbm_gpu);
> > > >> gbm_kms = gbm_device_create("/dev/dri/card0");
> > > >> gbm_device_set_kms_provider(gbm_gpu, gbm_kms);
> > > >>
> > > >> i.e. the device the user creates first is the GPU device.
> > > >>
> > > >> With EGLDevice, we would have:
> > > >> gbm_kms = gbm_device_create("/dev/dri/card0");
> > > >> egl_gpus = eglGetDevicesEXT();
> > > >> egl_dpy = eglGetPlatformDisplay(gbm_kms, { EGL_TARGET_DEVICE, 
> > > >> egl_gpus[0] });
> > > >>
> > > >> So, the first/main device the user deals with is the KMS device - same
> > > >> as today. This makes sense, since GBM is the allocation API for KMS,
> > > >> and EGL should be the one dealing with the GPU ...
> > > >>
> > > > Right, my API design was from my view of GBM being the API to bootstrap
> > > > EGL rendering, but defining it as the KMS allocation API makes a lot
> > > > more sense, when you think about it.
> > > >
> > > >> Maybe it would make sense to reverse the API, so rather than creating
> > > >> a GBM device for the GPU and then linking that to the KMS device -
> > > >> requiring users to make different calls, e.g. gbm_bo_get_kms_bo(),
> > > >> which makes it harder to use and means we need to port current users -
> > > >> we create a GBM device for KMS and then link that to a GPU device.
> > > >> This would then mean that eglGetPlatformDisplay could do the linkage
> > > >> internally, and then existing users using gbm_bo_get_handle() etc
> > > >> would still work without needing any different codepaths.
> > > >
> > > > Yes, this will make the implementation inside GBM a bit more involved,
> > > > but it seems more natural this way around when thinking about hooking it
> > > > up to EGLDevice

[Mesa-dev] [PATCH 3/6] etnaviv: honor PIPE_TRANSFER_UNSYNCHRONIZED flag

2017-05-19 Thread Lucas Stach
This gets rid of quite a bit of CPU/GPU sync on frequent vertex buffer
uploads and I haven't seen any of the issues mentioned in the comment,
so this one seems stale.

Ignore the flag if there exists a temporary resource, as those ones are
never busy.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_transfer.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
index 269bd498f89f..a2cd4e6234dd 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
@@ -114,7 +114,7 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
pipe_transfer *ptrans)
   }
}
 
-   if (!trans->rsc)
+   if (!trans->rsc && !(ptrans->usage & PIPE_TRANSFER_UNSYNCHRONIZED))
   etna_bo_cpu_fini(rsc->bo);
 
pipe_resource_reference(&trans->rsc, NULL);
@@ -260,19 +260,17 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
(rsc->layout == ETNA_LAYOUT_TILED &&
 util_format_is_compressed(prsc->format));
 
-   /* Ignore PIPE_TRANSFER_UNSYNCHRONIZED and PIPE_TRANSFER_DONTBLOCK here.
-* It appears that Gallium operates the index/vertex buffers in a
-* circular fashion, and the CPU can catch up with the GPU and starts
-* overwriting yet-to-be-processed entries, causing rendering corruption. */
-   uint32_t prep_flags = 0;
+   if (trans->rsc || !(usage & PIPE_TRANSFER_UNSYNCHRONIZED)) {
+  uint32_t prep_flags = 0;
 
-   if (usage & PIPE_TRANSFER_READ)
-  prep_flags |= DRM_ETNA_PREP_READ;
-   if (usage & PIPE_TRANSFER_WRITE)
-  prep_flags |= DRM_ETNA_PREP_WRITE;
+  if (usage & PIPE_TRANSFER_READ)
+ prep_flags |= DRM_ETNA_PREP_READ;
+  if (usage & PIPE_TRANSFER_WRITE)
+ prep_flags |= DRM_ETNA_PREP_WRITE;
 
-   if (etna_bo_cpu_prep(rsc->bo, prep_flags))
-  goto fail_prep;
+  if (etna_bo_cpu_prep(rsc->bo, prep_flags))
+ goto fail_prep;
+   }
 
/* map buffer object */
void *mapped = etna_bo_map(rsc->bo);
-- 
2.11.0

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


[Mesa-dev] [PATCH 1/6] etnaviv: always do cpu_fini in transfer_unmap

2017-05-19 Thread Lucas Stach
The cpu_fini() call pushes the buffer back into the GPU domain, which needs
to be done for all buffers, not just the ones with CPU written content. The
etnaviv kernel driver currently doesn't validate this, but may start to do
so at a later point in time. If there is a temporary resource the fini needs
to happen before the RS uses this one as the source for the upload.

Also remove an invalid comment about flushing CPU caches, cpu_fini takes
care of everything involved in this.

Fixes: c9e8b49b885 ("etnaviv: gallium driver for Vivante GPUs")
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_transfer.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
index 1a5aa7fc043c..4809b04ff95f 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
@@ -70,6 +70,9 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
pipe_transfer *ptrans)
if (rsc->texture && !etna_resource_newer(rsc, etna_resource(rsc->texture)))
   rsc = etna_resource(rsc->texture); /* switch to using the texture 
resource */
 
+   if (trans->rsc)
+  etna_bo_cpu_fini(etna_resource(trans->rsc)->bo);
+
if (ptrans->usage & PIPE_TRANSFER_WRITE) {
   if (trans->rsc) {
  /* We have a temporary resource due to either tile status or
@@ -105,15 +108,15 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
pipe_transfer *ptrans)
   }
 
   rsc->seqno++;
-  etna_bo_cpu_fini(rsc->bo);
 
   if (rsc->base.bind & PIPE_BIND_SAMPLER_VIEW) {
- /* XXX do we need to flush the CPU cache too or start a write barrier
-  * to make sure the GPU sees it? */
  ctx->dirty |= ETNA_DIRTY_TEXTURE_CACHES;
   }
}
 
+   if (!trans->rsc)
+  etna_bo_cpu_fini(rsc->bo);
+
pipe_resource_reference(&trans->rsc, NULL);
pipe_resource_reference(&ptrans->resource, NULL);
slab_free(&ctx->transfer_pool, trans);
-- 
2.11.0

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


[Mesa-dev] [PATCH 4/6] etnaviv: don't read back resource if transfer discards contents

2017-05-19 Thread Lucas Stach
Reduces bandwidth usage of transfers which discard the buffer contents,
as well as skipping unnecessary command stream flushes and CPU/GPU
synchronization.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_transfer.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
index a2cd4e6234dd..f7871f485371 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
@@ -188,7 +188,9 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
  return NULL;
   }
 
-  etna_copy_resource(pctx, trans->rsc, prsc, level, 
trans->rsc->last_level);
+  if (!(usage & PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE))
+ etna_copy_resource(pctx, trans->rsc, prsc, level,
+trans->rsc->last_level);
 
   /* Switch to using the temporary resource instead */
   rsc = etna_resource(trans->rsc);
-- 
2.11.0

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


[Mesa-dev] [PATCH 5/6] etnaviv: simplify transfer tiling handling

2017-05-19 Thread Lucas Stach
There is no need to special case compressed resources, as they are already
marked as linear on allocation. With that out of the way, there is room to
cut down on the number of if clauses used.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_transfer.c | 70 +++---
 1 file changed, 29 insertions(+), 41 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
index f7871f485371..05cdbc599956 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
@@ -85,21 +85,19 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
pipe_transfer *ptrans)
  struct etna_resource_level *res_level = &rsc->levels[ptrans->level];
  void *mapped = etna_bo_map(rsc->bo) + res_level->offset;
 
- if (rsc->layout == ETNA_LAYOUT_LINEAR || rsc->layout == 
ETNA_LAYOUT_TILED) {
-if (rsc->layout == ETNA_LAYOUT_TILED && 
!util_format_is_compressed(rsc->base.format)) {
-   etna_texture_tile(
-  mapped + ptrans->box.z * res_level->layer_stride,
-  trans->staging, ptrans->box.x, ptrans->box.y,
-  res_level->stride, ptrans->box.width, ptrans->box.height,
-  ptrans->stride, util_format_get_blocksize(rsc->base.format));
-} else { /* non-tiled or compressed format */
-   util_copy_box(mapped, rsc->base.format, res_level->stride,
- res_level->layer_stride, ptrans->box.x,
- ptrans->box.y, ptrans->box.z, ptrans->box.width,
- ptrans->box.height, ptrans->box.depth,
- trans->staging, ptrans->stride,
- ptrans->layer_stride, 0, 0, 0 /* src x,y,z */);
-}
+ if (rsc->layout == ETNA_LAYOUT_TILED) {
+etna_texture_tile(
+   mapped + ptrans->box.z * res_level->layer_stride,
+   trans->staging, ptrans->box.x, ptrans->box.y,
+   res_level->stride, ptrans->box.width, ptrans->box.height,
+   ptrans->stride, util_format_get_blocksize(rsc->base.format));
+ } else if (rsc->layout == ETNA_LAYOUT_LINEAR) {
+util_copy_box(mapped, rsc->base.format, res_level->stride,
+  res_level->layer_stride, ptrans->box.x,
+  ptrans->box.y, ptrans->box.z, ptrans->box.width,
+  ptrans->box.height, ptrans->box.depth,
+  trans->staging, ptrans->stride,
+  ptrans->layer_stride, 0, 0, 0 /* src x,y,z */);
  } else {
 BUG("unsupported tiling %i", rsc->layout);
  }
@@ -255,13 +253,6 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
   PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE is set.
 */
 
-   /* No need to allocate a buffer for copying if the resource is not in use,
-* and no tiling is needed, can just return a direct pointer.
-*/
-   bool in_place = rsc->layout == ETNA_LAYOUT_LINEAR ||
-   (rsc->layout == ETNA_LAYOUT_TILED &&
-util_format_is_compressed(prsc->format));
-
if (trans->rsc || !(usage & PIPE_TRANSFER_UNSYNCHRONIZED)) {
   uint32_t prep_flags = 0;
 
@@ -281,7 +272,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
 
*out_transfer = ptrans;
 
-   if (in_place) {
+   if (rsc->layout == ETNA_LAYOUT_LINEAR) {
   ptrans->stride = res_level->stride;
   ptrans->layer_stride = res_level->layer_stride;
 
@@ -308,24 +299,21 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
  goto fail;
 
   if (usage & PIPE_TRANSFER_READ) {
- /* untile or copy resource for reading */
- if (rsc->layout == ETNA_LAYOUT_LINEAR || rsc->layout == 
ETNA_LAYOUT_TILED) {
-if (rsc->layout == ETNA_LAYOUT_TILED && 
!util_format_is_compressed(rsc->base.format)) {
-   etna_texture_untile(trans->staging,
-   mapped + ptrans->box.z * 
res_level->layer_stride,
-   ptrans->box.x, ptrans->box.y, 
res_level->stride,
-   ptrans->box.width, ptrans->box.height, 
ptrans->stride,
-   
util_format_get_blocksize(rsc->base.format));
-} else { /* non-tiled or compressed format */
-   util_copy_box(trans->staging, rsc->base.format, ptrans->stride,
- ptrans->layer_stride, 0, 0, 

[Mesa-dev] [PATCH 2/6] etnaviv: slim down resource waiting

2017-05-19 Thread Lucas Stach
cpu_prep() already does all the required waiting, so the only thing that
needs to be done is flushing the commandstream, if a GPU write is pending.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_clear_blit.c |  5 +++--
 src/gallium/drivers/etnaviv/etnaviv_resource.c   | 16 
 src/gallium/drivers/etnaviv/etnaviv_resource.h   |  3 ---
 src/gallium/drivers/etnaviv/etnaviv_transfer.c   |  5 +++--
 4 files changed, 6 insertions(+), 23 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
index ae1c5862880f..ea416bf192f3 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
@@ -528,8 +528,9 @@ etna_try_rs_blit(struct pipe_context *pctx,
 
 manual:
if (src->layout == ETNA_LAYOUT_TILED && dst->layout == ETNA_LAYOUT_TILED) {
-  etna_resource_wait(pctx, dst);
-  etna_resource_wait(pctx, src);
+  if ((src->status & ETNA_PENDING_WRITE) ||
+  (dst->status & ETNA_PENDING_WRITE))
+ pctx->flush(pctx, NULL, 0);
   return etna_manual_blit(dst, dst_lev, dst_offset, src, src_lev, 
src_offset, blit_info);
}
 
diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index 1341e1ea2314..9aa1aa617a51 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -429,22 +429,6 @@ etna_resource_used(struct etna_context *ctx, struct 
pipe_resource *prsc,
 }
 
 void
-etna_resource_wait(struct pipe_context *pctx, struct etna_resource *rsc)
-{
-   if (rsc->status & ETNA_PENDING_WRITE) {
-  struct pipe_fence_handle *fence;
-  struct pipe_screen *pscreen = pctx->screen;
-
-  pctx->flush(pctx, &fence, 0);
-
-  if (!pscreen->fence_finish(pscreen, pctx, fence, 50ULL))
- BUG("fence timed out (hung GPU?)");
-
-  pscreen->fence_reference(pscreen, &fence, NULL);
-   }
-}
-
-void
 etna_resource_screen_init(struct pipe_screen *pscreen)
 {
pscreen->can_create_resource = etna_screen_can_create_resource;
diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
b/src/gallium/drivers/etnaviv/etnaviv_resource.h
index a8d42ee1a09f..913316f193c2 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
@@ -124,9 +124,6 @@ void
 etna_resource_used(struct etna_context *ctx, struct pipe_resource *prsc,
enum etna_resource_status status);
 
-void
-etna_resource_wait(struct pipe_context *ctx, struct etna_resource *rsc);
-
 static inline void
 resource_read(struct etna_context *ctx, struct pipe_resource *prsc)
 {
diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
index 4809b04ff95f..269bd498f89f 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
@@ -199,8 +199,9 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
/* Always sync if we have the temporary resource.  The PIPE_TRANSFER_READ
 * case could be optimised if we knew whether the resource has outstanding
 * rendering. */
-   if (usage & PIPE_TRANSFER_READ || trans->rsc)
-  etna_resource_wait(pctx, rsc);
+   if ((usage & PIPE_TRANSFER_READ || trans->rsc) &&
+   rsc->status & ETNA_PENDING_WRITE)
+  pctx->flush(pctx, NULL, 0);
 
/* XXX we don't handle PIPE_TRANSFER_FLUSH_EXPLICIT; this flag can be 
ignored
 * when mapping in-place,
-- 
2.11.0

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


[Mesa-dev] [PATCH 0/6] etnaviv transfer handling improvements

2017-05-19 Thread Lucas Stach
Hi guys!

So I've looked a bit at our transfer functions, as they are causing significant
CPU/GPU syncs in some workloads, which I would like to kill.

This patch series is the first step in that direction. It fixes one bug, cleans
up the code a bit, to make it easier to follow and implements some handling for
the easy "make things faster" flags.

Regards,
Lucas

Lucas Stach (6):
  etnaviv: always do cpu_fini in transfer_unmap
  etnaviv: slim down resource waiting
  etnaviv: honor PIPE_TRANSFER_UNSYNCHRONIZED flag
  etnaviv: don't read back resource if transfer discards contents
  etnaviv: simplify transfer tiling handling
  etnaviv: upgrade DISCARD_RANGE to DISCARD_WHOLE_RESOURCE if possible

 src/gallium/drivers/etnaviv/etnaviv_clear_blit.c |   5 +-
 src/gallium/drivers/etnaviv/etnaviv_resource.c   |  16 ---
 src/gallium/drivers/etnaviv/etnaviv_resource.h   |   3 -
 src/gallium/drivers/etnaviv/etnaviv_transfer.c   | 122 ---
 4 files changed, 67 insertions(+), 79 deletions(-)

-- 
2.11.0

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


[Mesa-dev] [PATCH 6/6] etnaviv: upgrade DISCARD_RANGE to DISCARD_WHOLE_RESOURCE if possible

2017-05-19 Thread Lucas Stach
Stolen from VC4. As we don't do any fancy reallocation tricks yet, it's
possible to upgrade also coherent mappings and shared resources.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_transfer.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
index 05cdbc599956..fe57aa4d17b2 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
@@ -148,6 +148,20 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
 
assert(level <= prsc->last_level);
 
+   /* Upgrade DISCARD_RANGE to WHOLE_RESOURCE if the whole resource is
+* being mapped. If we add buffer reallocation to avoid CPU/GPU sync this
+* check needs to be extended to coherent mappings and shared resources.
+*/
+   if ((usage & PIPE_TRANSFER_DISCARD_RANGE) &&
+   !(usage & PIPE_TRANSFER_UNSYNCHRONIZED) &&
+   prsc->last_level == 0 &&
+   prsc->width0 == box->width &&
+   prsc->height0 == box->height &&
+   prsc->depth0 == box->depth &&
+   prsc->array_size == 1) {
+  usage |= PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE;
+   }
+
if (rsc->texture && !etna_resource_newer(rsc, etna_resource(rsc->texture))) 
{
   /* We have a texture resource which is the same age or newer than the
* render resource. Use the texture resource, which avoids bouncing
-- 
2.11.0

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


Re: [Mesa-dev] [PATCH v13 11/36] st/dri: implement createImageWithModifiers in DRIimage

2017-05-19 Thread Lucas Stach
Am Freitag, den 19.05.2017, 10:37 +0100 schrieb Daniel Stone:
> From: Varad Gautam 
> 
> adds a pscreen->resource_create_with_modifiers() to create textures
> with modifier.
> 
> Signed-off-by: Varad Gautam 
> Signed-off-by: Daniel Stone 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/include/pipe/p_screen.h   | 18 
>  src/gallium/state_trackers/dri/dri2.c | 79 
> ---
>  2 files changed, 81 insertions(+), 16 deletions(-)
> 
> diff --git a/src/gallium/include/pipe/p_screen.h 
> b/src/gallium/include/pipe/p_screen.h
> index 8b4239c61a..8eddf355d7 100644
> --- a/src/gallium/include/pipe/p_screen.h
> +++ b/src/gallium/include/pipe/p_screen.h
> @@ -328,6 +328,24 @@ struct pipe_screen {
>  * driver doesn't support an on-disk shader cache.
>  */
> struct disk_cache *(*get_disk_shader_cache)(struct pipe_screen *screen);
> +
> +   /**
> +* Create a new texture object from the given template info, taking
> +* format modifiers into account. \p modifiers specifies a list of format
> +* modifier tokens, as defined in drm_fourcc.h. The driver then picks the
> +* best modifier among these and creates the resource. \p count must
> +* contain the size of \p modifiers array. The selected modifier is
> +* returned via \p modifier after a successful call.
> +*
> +* Returns NULL if an entry in \p modifiers is unsupported by the driver,
> +* or if only DRM_FORMAT_MOD_INVALID is provided.
> +*/
> +   struct pipe_resource * (*resource_create_with_modifiers)(
> +   struct pipe_screen *,
> +   const struct pipe_resource *templat,
> +   const uint64_t *modifiers, int count,
> +   uint64_t *modifier);
> +
>  };
>  
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index 7614474e4a..713f482181 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -977,27 +977,38 @@ dri2_create_image_from_renderbuffer(__DRIcontext 
> *context,
>  }
>  
>  static __DRIimage *
> -dri2_create_image(__DRIscreen *_screen,
> -   int width, int height, int format,
> -   unsigned int use, void *loaderPrivate)
> +dri2_create_image_common(__DRIscreen *_screen,
> + int width, int height,
> + int format, unsigned int use,
> + const uint64_t *modifiers,
> + const unsigned count,
> + void *loaderPrivate)
>  {
> struct dri_screen *screen = dri_screen(_screen);
> __DRIimage *img;
> struct pipe_resource templ;
> unsigned tex_usage;
> enum pipe_format pf;
> +   uint64_t modifier = DRM_FORMAT_MOD_INVALID;
> +
> +   /* createImageWithModifiers doesn't supply usage, and we should not get
> +* here with both modifiers and a usage flag.
> +*/
> +   assert(!(use && (modifiers != NULL)));
>  
> tex_usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> -   if (use & __DRI_IMAGE_USE_SCANOUT)
> -  tex_usage |= PIPE_BIND_SCANOUT;
> -   if (use & __DRI_IMAGE_USE_SHARE)
> -  tex_usage |= PIPE_BIND_SHARED;
> -   if (use & __DRI_IMAGE_USE_LINEAR)
> -  tex_usage |= PIPE_BIND_LINEAR;
> -   if (use & __DRI_IMAGE_USE_CURSOR) {
> -  if (width != 64 || height != 64)
> - return NULL;
> -  tex_usage |= PIPE_BIND_CURSOR;
> +   if (use) {
> +  if (use & __DRI_IMAGE_USE_SCANOUT)
> + tex_usage |= PIPE_BIND_SCANOUT;
> +  if (use & __DRI_IMAGE_USE_SHARE)
> + tex_usage |= PIPE_BIND_SHARED;
> +  if (use & __DRI_IMAGE_USE_LINEAR)
> + tex_usage |= PIPE_BIND_LINEAR;
> +  if (use & __DRI_IMAGE_USE_CURSOR) {
> + if (width != 64 || height != 64)
> +return NULL;
> + tex_usage |= PIPE_BIND_CURSOR;
> +  }
> }
>  
> pf = dri2_format_to_pipe_format (format);
> @@ -1018,7 +1029,16 @@ dri2_create_image(__DRIscreen *_screen,
> templ.depth0 = 1;
> templ.array_size = 1;
>  
> -   img->texture = screen->base.screen->resource_create(screen->base.screen, 
> &templ);
> +   if (modifiers)
> +  img->texture = screen->base.screen
> +->resource_create_with_modifiers(screen->base.screen,
> + &templ,
> + modifiers,
> + cou

Re: [Mesa-dev] [PATCH v13 10/36] st/dri: enable DRIimage modifier queries

2017-05-19 Thread Lucas Stach
Am Freitag, den 19.05.2017, 10:37 +0100 schrieb Daniel Stone:
> From: Varad Gautam 
> 
> introduce modifier field in DRIimage and set it to
> DRM_FORMAT_MOD_INVALID for now. support DRIimage modifier
> queries.
> 
> Suggested-by: Daniel Stone 
> Signed-off-by: Varad Gautam 
> Signed-off-by: Daniel Stone 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/state_trackers/dri/dri2.c   | 15 +++
>  src/gallium/state_trackers/dri/dri_screen.h |  1 +
>  2 files changed, 16 insertions(+)
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index 0c5783cbd3..7614474e4a 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -52,6 +52,10 @@
>  #include "dri_query_renderer.h"
>  #include "dri2_buffer.h"
>  
> +#ifndef DRM_FORMAT_MOD_INVALID
> +#define DRM_FORMAT_MOD_INVALID ((1ULL<<56) - 1)
> +#endif
> +
>  /* format list taken from intel_screen.c */
>  static struct image_format image_formats[] = {
> { __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> @@ -874,6 +878,7 @@ dri2_create_image_from_winsys(__DRIscreen *_screen,
> img->layer = 0;
> img->dri_format = format;
> img->use = 0;
> +   img->modifier = DRM_FORMAT_MOD_INVALID;
> img->loader_private = loaderPrivate;
>  
> return img;
> @@ -1024,6 +1029,7 @@ dri2_create_image(__DRIscreen *_screen,
> img->dri_format = format;
> img->dri_components = 0;
> img->use = use;
> +   img->modifier = DRM_FORMAT_MOD_INVALID;
>  
> img->loader_private = loaderPrivate;
> return img;
> @@ -1103,6 +1109,12 @@ dri2_query_image(__DRIimage *image, int attrib, int 
> *value)
> case __DRI_IMAGE_ATTRIB_NUM_PLANES:
>*value = 1;
>return GL_TRUE;
> +   case __DRI_IMAGE_ATTRIB_MODIFIER_UPPER:
> +  *value = ((image->modifier >> 32) & 0x);
> +  return GL_TRUE;
> +   case __DRI_IMAGE_ATTRIB_MODIFIER_LOWER:
> +  *value = image->modifier & 0x;
> +  return GL_TRUE;
> default:
>return GL_FALSE;
> }
> @@ -1121,6 +1133,7 @@ dri2_dup_image(__DRIimage *image, void *loaderPrivate)
> pipe_resource_reference(&img->texture, image->texture);
> img->level = image->level;
> img->layer = image->layer;
> +   img->modifier = image->modifier;
> img->dri_format = image->dri_format;
> /* This should be 0 for sub images, but dup is also used for base images. 
> */
> img->dri_components = image->dri_components;
> @@ -1250,6 +1263,8 @@ dri2_create_from_texture(__DRIcontext *context, int 
> target, unsigned texture,
> img->level = level;
> img->layer = depth;
> img->dri_format = 
> driGLFormatToImageFormat(obj->Image[face][level]->TexFormat);
> +   /* XXX: no way to retrieve modifier from tex here, we lose the modifier. 
> */
> +   img->modifier = DRM_FORMAT_MOD_INVALID;
>  
> img->loader_private = loaderPrivate;
>  
> diff --git a/src/gallium/state_trackers/dri/dri_screen.h 
> b/src/gallium/state_trackers/dri/dri_screen.h
> index de88cd26db..0fae51bfb5 100644
> --- a/src/gallium/state_trackers/dri/dri_screen.h
> +++ b/src/gallium/state_trackers/dri/dri_screen.h
> @@ -123,6 +123,7 @@ struct __DRIimageRec {
> uint32_t dri_format;
> uint32_t dri_components;
> unsigned use;
> +   uint64_t modifier;
>  
> void *loader_private;
>  


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


Re: [Mesa-dev] [PATCH v13 12/36] st/dri: implement DRIimage creation from dmabufs with modifiers

2017-05-19 Thread Lucas Stach
Am Freitag, den 19.05.2017, 10:37 +0100 schrieb Daniel Stone:
> From: Varad Gautam 
> 
> support importing dmabufs into DRIimage while taking format modifiers
> in account, as per DRIimage extension version 15.
> 
> bump __DRIimageExtension to 15.
> 
> v2: initialize winsys modifier to DRM_FORMAT_MOD_INVALID (Daniel Stone)
> 
> Signed-off-by: Varad Gautam 
> Signed-off-by: Daniel Stone 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/include/state_tracker/drm_driver.h |  2 ++
>  src/gallium/state_trackers/dri/dri2.c  | 48 
> +++---
>  2 files changed, 45 insertions(+), 5 deletions(-)
> 
> diff --git a/src/gallium/include/state_tracker/drm_driver.h 
> b/src/gallium/include/state_tracker/drm_driver.h
> index c80fb09dbc..8b9d6bc621 100644
> --- a/src/gallium/include/state_tracker/drm_driver.h
> +++ b/src/gallium/include/state_tracker/drm_driver.h
> @@ -45,6 +45,8 @@ struct winsys_handle
>  * Output for texture_get_handle.
>  */
> unsigned offset;
> +
> +   uint64_t modifier;
>  };
>  
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index 713f482181..3f83cc96cc 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -878,7 +878,7 @@ dri2_create_image_from_winsys(__DRIscreen *_screen,
> img->layer = 0;
> img->dri_format = format;
> img->use = 0;
> -   img->modifier = DRM_FORMAT_MOD_INVALID;
> +   img->modifier = whandle[0].modifier;
> img->loader_private = loaderPrivate;
>  
> return img;
> @@ -895,6 +895,7 @@ dri2_create_image_from_name(__DRIscreen *_screen,
> memset(&whandle, 0, sizeof(whandle));
> whandle.type = DRM_API_HANDLE_TYPE_SHARED;
> whandle.handle = name;
> +   whandle.modifier = DRM_FORMAT_MOD_INVALID;
>  
> pf = dri2_format_to_pipe_format (format);
> if (pf == PIPE_FORMAT_NONE)
> @@ -910,7 +911,7 @@ static __DRIimage *
>  dri2_create_image_from_fd(__DRIscreen *_screen,
>int width, int height, int fourcc,
>int *fds, int num_fds, int *strides,
> -  int *offsets, unsigned *error,
> +  int *offsets, uint64_t *modifiers, unsigned *error,
>int *dri_components, void *loaderPrivate)
>  {
> struct winsys_handle whandles[3];
> @@ -941,6 +942,7 @@ dri2_create_image_from_fd(__DRIscreen *_screen,
>whandles[i].handle = (unsigned)fds[i];
>whandles[i].stride = (unsigned)strides[i];
>whandles[i].offset = (unsigned)offsets[i];
> +  whandles[i].modifier = modifiers ? modifiers[i] : 
> DRM_FORMAT_MOD_INVALID;
> }
>  
> if (fourcc == __DRI_IMAGE_FOURCC_YVU420) {
> @@ -1219,6 +1221,7 @@ dri2_from_names(__DRIscreen *screen, int width, int 
> height, int format,
> whandle.handle = names[0];
> whandle.stride = strides[0];
> whandle.offset = offsets[0];
> +   whandle.modifier = DRM_FORMAT_MOD_INVALID;
>  
> img = dri2_create_image_from_winsys(screen, width, height,
> f->planes[0].dri_format,
> @@ -1331,7 +1334,7 @@ dri2_from_fds(__DRIscreen *screen, int width, int 
> height, int fourcc,
> int dri_components;
>  
> img = dri2_create_image_from_fd(screen, width, height, fourcc,
> -   fds, num_fds, strides, offsets, NULL,
> +   fds, num_fds, strides, offsets, NULL, 
> NULL,
> &dri_components, loaderPrivate);
> if (img == NULL)
>return NULL;
> @@ -1356,7 +1359,7 @@ dri2_from_dma_bufs(__DRIscreen *screen,
> int dri_components;
>  
> img = dri2_create_image_from_fd(screen, width, height, fourcc,
> -   fds, num_fds, strides, offsets, error,
> +   fds, num_fds, strides, offsets, NULL, 
> error,
> &dri_components, loaderPrivate);
> if (img == NULL)
>return NULL;
> @@ -1371,6 +1374,38 @@ dri2_from_dma_bufs(__DRIscreen *screen,
> return img;
>  }
>  
> +static __DRIimage *
> +dri2_from_dma_bufs2(__DRIscreen *screen,
> +int width, int height, int fourcc,
> +int *fds, int num_fds,
> +int *strides, int *offsets,
> +uint64_t *modifiers,
> +enum __DRIYUVColorSpace yuv_color_space,
> +enum __DRISampleRange sample_range,
> +enum __DRIChromaSiting horizontal_siting,
> + 

Re: [Mesa-dev] [PATCH v13 13/36] st/dri: support format queries

2017-05-19 Thread Lucas Stach
Am Freitag, den 19.05.2017, 10:37 +0100 schrieb Daniel Stone:
> From: Varad Gautam 
> 
> ask the driver for supported dmabuf formats
> 
> v2: rebase to master.
> v3: return false on failure.
> v4: use pscreen->is_format_supported instead of adding a new query.
> (Lucas Stach)
> Signed-off-by: Varad Gautam 
> Signed-off-by: Daniel Stone 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/state_trackers/dri/dri2.c | 91 
> +++
>  1 file changed, 91 insertions(+)
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index 3f83cc96cc..814a08e3cb 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -216,6 +216,69 @@ static enum pipe_format dri2_format_to_pipe_format (int 
> format)
> return pf;
>  }
>  
> +static enum pipe_format fourcc_to_pipe_format(int fourcc) {
> +   enum pipe_format pf;
> +
> +   switch (fourcc) {
> +   case __DRI_IMAGE_FOURCC_R8:
> +  pf = PIPE_FORMAT_R8_UNORM;
> +  break;
> +   case __DRI_IMAGE_FOURCC_GR88:
> +  pf = PIPE_FORMAT_RG88_UNORM;
> +  break;
> +   case __DRI_IMAGE_FOURCC_ARGB1555:
> +  pf = PIPE_FORMAT_B5G5R5A1_UNORM;
> +  break;
> +   case __DRI_IMAGE_FOURCC_R16:
> +  pf = PIPE_FORMAT_R16_UNORM;
> +  break;
> +   case __DRI_IMAGE_FOURCC_GR1616:
> +  pf = PIPE_FORMAT_RG1616_UNORM;
> +  break;
> +   case __DRI_IMAGE_FOURCC_RGB565:
> +  pf = PIPE_FORMAT_B5G6R5_UNORM;
> +  break;
> +   case __DRI_IMAGE_FOURCC_ARGB:
> +  pf = PIPE_FORMAT_BGRA_UNORM;
> +  break;
> +   case __DRI_IMAGE_FOURCC_XRGB:
> +  pf = PIPE_FORMAT_BGRX_UNORM;
> +  break;
> +   case __DRI_IMAGE_FOURCC_ABGR:
> +  pf = PIPE_FORMAT_RGBA_UNORM;
> +  break;
> +   case __DRI_IMAGE_FOURCC_XBGR:
> +  pf = PIPE_FORMAT_RGBX_UNORM;
> +  break;
> +
> +   case __DRI_IMAGE_FOURCC_NV12:
> +  pf = PIPE_FORMAT_NV12;
> +  break;
> +   case __DRI_IMAGE_FOURCC_YUYV:
> +  pf = PIPE_FORMAT_YUYV;
> +  break;
> +   case __DRI_IMAGE_FOURCC_YUV420:
> +   case __DRI_IMAGE_FOURCC_YVU420:
> +  pf = PIPE_FORMAT_YV12;
> +  break;
> +
> +   case __DRI_IMAGE_FOURCC_SARGB:
> +   case __DRI_IMAGE_FOURCC_YUV410:
> +   case __DRI_IMAGE_FOURCC_YUV411:
> +   case __DRI_IMAGE_FOURCC_YUV422:
> +   case __DRI_IMAGE_FOURCC_YUV444:
> +   case __DRI_IMAGE_FOURCC_NV16:
> +   case __DRI_IMAGE_FOURCC_YVU410:
> +   case __DRI_IMAGE_FOURCC_YVU411:
> +   case __DRI_IMAGE_FOURCC_YVU422:
> +   case __DRI_IMAGE_FOURCC_YVU444:
> +   default:
> +  pf = PIPE_FORMAT_NONE;
> +   }
> +
> +   return pf;
> +}
> +
>  /**
>   * DRI2 flush extension.
>   */
> @@ -1343,6 +1406,31 @@ dri2_from_fds(__DRIscreen *screen, int width, int 
> height, int fourcc,
> return img;
>  }
>  
> +static boolean
> +dri2_query_dma_buf_formats(__DRIscreen *_screen, int max, int *formats,
> +   int *count)
> +{
> +   struct dri_screen *screen = dri_screen(_screen);
> +   struct pipe_screen *pscreen = screen->base.screen;
> +   const unsigned bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> +   int i, j;
> +
> +   for (i = 0, j = 0; (i < ARRAY_SIZE(image_formats)) &&
> + (j < max || max == 0); i++) {
> +  if (pscreen->is_format_supported(pscreen,
> +   fourcc_to_pipe_format(
> +  image_formats[i].fourcc),
> +   screen->target,
> +   0, bind)) {
> + if (j < max)
> +formats[j] = image_formats[i].fourcc;
> + j++;
> +  }
> +   }
> +   *count = j;
> +   return true;
> +}
> +
>  static __DRIimage *
>  dri2_from_dma_bufs(__DRIscreen *screen,
> int width, int height, int fourcc,
> @@ -1529,6 +1617,7 @@ static __DRIimageExtension dri2ImageExtension = {
>  .unmapImage   = dri2_unmap_image,
>  .createImageWithModifiers = NULL,
>  .createImageFromDmaBufs2  = NULL,
> +.queryDmaBufFormats   = NULL,
>  };
>  
> 
> @@ -2075,6 +2164,7 @@ dri2_init_screen(__DRIscreen * sPriv)
>   dri2ImageExtension.createImageFromFds = dri2_from_fds;
>   dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
>   dri2ImageExtension.createImageFromDmaBufs2 = dri2_from_dma_bufs2;
> + dri2ImageExtension.queryDmaBufFormats = dri2_query_dma_buf_forma

Re: [Mesa-dev] [PATCH v13 15/36] st/dri: support format modifier queries

2017-05-19 Thread Lucas Stach
Am Freitag, den 19.05.2017, 10:37 +0100 schrieb Daniel Stone:
> From: Varad Gautam 
> 
> ask the driver for supported modifiers for a given format.
> bump __DRIimageExtension to 16.
> 
> v2: move to __DRIimageExtension v16.
> v3: fail if the supplied format is not supported by driver.
> v4: purge PIPE_CAP_QUERY_DMABUF_ATTRIBS.
> 
> Signed-off-by: Varad Gautam 
> Signed-off-by: Daniel Stone 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/state_trackers/dri/dri2.c | 24 +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index 814a08e3cb..36cd235b3c 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -1431,6 +1431,24 @@ dri2_query_dma_buf_formats(__DRIscreen *_screen, int 
> max, int *formats,
> return true;
>  }
>  
> +static boolean
> +dri2_query_dma_buf_modifiers(__DRIscreen *_screen, int fourcc, int max,
> + uint64_t *modifiers, int *count)
> +{
> +   struct dri_screen *screen = dri_screen(_screen);
> +   struct pipe_screen *pscreen = screen->base.screen;
> +   enum pipe_format format = fourcc_to_pipe_format(fourcc);
> +   const unsigned usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> +
> +   if (pscreen->query_dmabuf_modifiers != NULL &&
> +   pscreen->is_format_supported(pscreen, format, screen->target, 0, 
> usage)) {
> +  pscreen->query_dmabuf_modifiers(pscreen, format, max, modifiers,
> + count);
> +  return true;
> +   }
> +   return false;
> +}
> +
>  static __DRIimage *
>  dri2_from_dma_bufs(__DRIscreen *screen,
> int width, int height, int fourcc,
> @@ -1597,7 +1615,7 @@ dri2_get_capabilities(__DRIscreen *_screen)
>  
>  /* The extension is modified during runtime if DRI_PRIME is detected */
>  static __DRIimageExtension dri2ImageExtension = {
> -.base = { __DRI_IMAGE, 15 },
> +.base = { __DRI_IMAGE, 16 },
>  
>  .createImageFromName  = dri2_create_image_from_name,
>  .createImageFromRenderbuffer  = dri2_create_image_from_renderbuffer,
> @@ -1618,6 +1636,7 @@ static __DRIimageExtension dri2ImageExtension = {
>  .createImageWithModifiers = NULL,
>  .createImageFromDmaBufs2  = NULL,
>  .queryDmaBufFormats   = NULL,
> +.queryDmaBufModifiers = NULL,
>  };
>  
> 
> @@ -2165,6 +2184,8 @@ dri2_init_screen(__DRIscreen * sPriv)
>   dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
>   dri2ImageExtension.createImageFromDmaBufs2 = dri2_from_dma_bufs2;
>   dri2ImageExtension.queryDmaBufFormats = dri2_query_dma_buf_formats;
> + dri2ImageExtension.queryDmaBufModifiers =
> +dri2_query_dma_buf_modifiers;
>}
> }
>  
> @@ -2243,6 +2264,7 @@ dri_kms_init_screen(__DRIscreen * sPriv)
>dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
>dri2ImageExtension.createImageFromDmaBufs2 = dri2_from_dma_bufs2;
>dri2ImageExtension.queryDmaBufFormats = dri2_query_dma_buf_formats;
> +  dri2ImageExtension.queryDmaBufModifiers = dri2_query_dma_buf_modifiers;
> }
>  
> sPriv->extensions = dri_screen_extensions;


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


Re: [Mesa-dev] [PATCH] etnaviv: Don't try to use the index buffer if size is zero

2017-05-22 Thread Lucas Stach
Am Freitag, den 19.05.2017, 12:40 +0200 schrieb Tomeu Vizoso:
> If info->index_size is zero, info->index will point to uninitialized
> memory.
> 
> Fatal signal 11 (SIGSEGV), code 2, fault addr 0xab5d07a3 in tid 20456 
> (surfaceflinger)
> 
> Signed-off-by: Tomeu Vizoso 
> Cc: etna...@lists.freedesktop.org
> Cc: Marek Olšák 
> Fixes: 330d0607ed60 ("gallium: remove pipe_index_buffer and set_index_buffer")

Reviewed-by: Lucas Stach 

If no one objects, I'm going to push this today.

Regards,
Lucas

> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.c | 36 
> +++
>  1 file changed, 20 insertions(+), 16 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
> b/src/gallium/drivers/etnaviv/etnaviv_context.c
> index 306cb6fc498d..dcda4088bfd5 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> @@ -178,24 +178,28 @@ etna_draw_vbo(struct pipe_context *pctx, const struct 
> pipe_draw_info *info)
>  
> /* Upload a user index buffer. */
> unsigned index_offset = 0;
> -   struct pipe_resource *indexbuf = info->has_user_indices ? NULL : 
> info->index.resource;
> -   if (info->index_size && info->has_user_indices &&
> -   !util_upload_index_buffer(pctx, info, &indexbuf, &index_offset)) {
> -  BUG("Index buffer upload failed.");
> -  return;
> -   }
> +   struct pipe_resource *indexbuf = NULL;
>  
> -   if (info->index_size && indexbuf) {
> -  ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.bo = 
> etna_resource(indexbuf)->bo;
> -  ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.offset = index_offset;
> -  ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.flags = ETNA_RELOC_READ;
> -  ctx->index_buffer.FE_INDEX_STREAM_CONTROL = 
> translate_index_size(info->index_size);
> -  ctx->dirty |= ETNA_DIRTY_INDEX_BUFFER;
> -   }
> +   if (info->index_size) {
> +  indexbuf = info->has_user_indices ? NULL : info->index.resource;
> +  if (info->has_user_indices &&
> +  !util_upload_index_buffer(pctx, info, &indexbuf, &index_offset)) {
> + BUG("Index buffer upload failed.");
> + return;
> +  }
>  
> -   if (info->index_size && !ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.bo) {
> -  BUG("Unsupported or no index buffer");
> -  return;
> +  if (indexbuf) {
> + ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.bo = 
> etna_resource(indexbuf)->bo;
> + ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.offset = index_offset;
> + ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.flags = ETNA_RELOC_READ;
> + ctx->index_buffer.FE_INDEX_STREAM_CONTROL = 
> translate_index_size(info->index_size);
> + ctx->dirty |= ETNA_DIRTY_INDEX_BUFFER;
> +  }
> +
> +  if (!ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.bo) {
> + BUG("Unsupported or no index buffer");
> + return;
> +  }
> }
>  
> struct etna_shader_key key = {};


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


Re: [Mesa-dev] [PATCH libdrm] header: update drm_fourcc.h

2017-05-22 Thread Lucas Stach
Am Dienstag, den 02.05.2017, 16:35 +0200 schrieb Lucas Stach:
> Mostly to pull in the Vivante tiling format modifiers, but some other
> little changes included.
> 
> Signed-off-by: Lucas Stach 

If there are no objections to this patch, I'm going to push it today.

Regards,
Lucas

> ---
>  include/drm/drm_fourcc.h | 81 
> 
>  1 file changed, 81 insertions(+)
> 
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 4d8da699a623..995c8f9c692f 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -26,6 +26,10 @@
>  
>  #include "drm.h"
>  
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +
>  #define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
>((__u32)(c) << 16) | ((__u32)(d) << 24))
>  
> @@ -37,10 +41,17 @@
>  /* 8 bpp Red */
>  #define DRM_FORMAT_R8fourcc_code('R', '8', ' ', ' ') /* 
> [7:0] R */
>  
> +/* 16 bpp Red */
> +#define DRM_FORMAT_R16   fourcc_code('R', '1', '6', ' ') /* 
> [15:0] R little endian */
> +
>  /* 16 bpp RG */
>  #define DRM_FORMAT_RG88  fourcc_code('R', 'G', '8', '8') /* 
> [15:0] R:G 8:8 little endian */
>  #define DRM_FORMAT_GR88  fourcc_code('G', 'R', '8', '8') /* 
> [15:0] G:R 8:8 little endian */
>  
> +/* 32 bpp RG */
> +#define DRM_FORMAT_RG1616fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
> 16:16 little endian */
> +#define DRM_FORMAT_GR1616fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
> 16:16 little endian */
> +
>  /* 8 bpp RGB */
>  #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
> 3:3:2 */
>  #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
> 2:3:3 */
> @@ -103,6 +114,20 @@
>  #define DRM_FORMAT_AYUV  fourcc_code('A', 'Y', 'U', 'V') /* 
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
>  
>  /*
> + * 2 plane RGB + A
> + * index 0 = RGB plane, same format as the corresponding non _A8 format has
> + * index 1 = A plane, [7:0] A
> + */
> +#define DRM_FORMAT_XRGB_A8   fourcc_code('X', 'R', 'A', '8')
> +#define DRM_FORMAT_XBGR_A8   fourcc_code('X', 'B', 'A', '8')
> +#define DRM_FORMAT_RGBX_A8   fourcc_code('R', 'X', 'A', '8')
> +#define DRM_FORMAT_BGRX_A8   fourcc_code('B', 'X', 'A', '8')
> +#define DRM_FORMAT_RGB888_A8 fourcc_code('R', '8', 'A', '8')
> +#define DRM_FORMAT_BGR888_A8 fourcc_code('B', '8', 'A', '8')
> +#define DRM_FORMAT_RGB565_A8 fourcc_code('R', '5', 'A', '8')
> +#define DRM_FORMAT_BGR565_A8 fourcc_code('B', '5', 'A', '8')
> +
> +/*
>   * 2 plane YCbCr
>   * index 0 = Y plane, [7:0] Y
>   * index 1 = Cr:Cb plane, [15:0] Cr:Cb little endian
> @@ -150,11 +175,13 @@
>  
>  /* Vendor Ids: */
>  #define DRM_FORMAT_MOD_NONE   0
> +#define DRM_FORMAT_MOD_VENDOR_NONE0
>  #define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
>  #define DRM_FORMAT_MOD_VENDOR_AMD 0x02
>  #define DRM_FORMAT_MOD_VENDOR_NV  0x03
>  #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
>  #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
> +#define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
>  /* add more to the end as needed */
>  
>  #define fourcc_mod_code(vendor, val) \
> @@ -168,6 +195,16 @@
>   * authoritative source for all of these.
>   */
>  
> +/*
> + * Linear Layout
> + *
> + * Just plain linear layout. Note that this is different from no specifying 
> any
> + * modifier (e.g. not setting DRM_MODE_FB_MODIFIERS in the DRM_ADDFB2 ioctl),
> + * which tells the driver to also take driver-internal information into 
> account
> + * and so might actually result in a tiled framebuffer.
> + */
> +#define DRM_FORMAT_MOD_LINEARfourcc_mod_code(NONE, 0)
> +
>  /* Intel framebuffer modifiers */
>  
>  /*
> @@ -229,4 +266,48 @@
>   */
>  #define DRM_FORMAT_MOD_SAMSUNG_64_32_TILEfourcc_mod_code(SAMSUNG, 1)
>  
> +/* Vivante framebuffer modifiers */
> +
> +

Re: [Mesa-dev] [PATCH v3 01/15] st/dri: refactor multi-planar YUV import path

2017-05-22 Thread Lucas Stach
Am Mittwoch, den 10.05.2017, 23:15 +0530 schrieb Varad Gautam:
> From: Varad Gautam 
> 
> we currently ignore the plane count when converting from
> __DRI_IMAGE_FORMAT* tokens to __DRI_IMAGE_FOURCC* for multiplanar
> images, and only return the first plane's simplified fourcc.
> 
> this adds a fourcc to __DRI_IMAGE_FORMAT_* mapping to dri, allowing
> us to return the correct fourcc format from DRIimage queries, and
> simplifies the multiplane import logic.
> 
> Signed-off-by: Varad Gautam 
> ---
>  src/gallium/state_trackers/dri/dri2.c   | 288 
> +++-
>  src/gallium/state_trackers/dri/dri_screen.h |  13 ++
>  2 files changed, 168 insertions(+), 133 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index ed6004f..0c5783c 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -52,93 +52,133 @@
>  #include "dri_query_renderer.h"
>  #include "dri2_buffer.h"
>  
> -static int convert_fourcc(int format, int *dri_components_p)
> +/* format list taken from intel_screen.c */
> +static struct image_format image_formats[] = {
> +   { __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
> +
> +   { __DRI_IMAGE_FOURCC_ABGR, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_ABGR, 4 } } },
> +
> +   { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
> +
> +   { __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
> +
> +   { __DRI_IMAGE_FOURCC_XBGR, __DRI_IMAGE_COMPONENTS_RGB, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_XBGR, 4 }, } },
> +
> +   { __DRI_IMAGE_FOURCC_ARGB1555, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB1555, 2 } } },
> +
> +   { __DRI_IMAGE_FOURCC_RGB565, __DRI_IMAGE_COMPONENTS_RGB, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_RGB565, 2 } } },
> +
> +   { __DRI_IMAGE_FOURCC_R8, __DRI_IMAGE_COMPONENTS_R, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 }, } },
> +
> +   { __DRI_IMAGE_FOURCC_R16, __DRI_IMAGE_COMPONENTS_R, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R16, 1 }, } },
> +
> +   { __DRI_IMAGE_FOURCC_GR88, __DRI_IMAGE_COMPONENTS_RG, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_GR88, 2 }, } },
> +
> +   { __DRI_IMAGE_FOURCC_GR1616, __DRI_IMAGE_COMPONENTS_RG, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_GR1616, 2 }, } },
> +
> +   { __DRI_IMAGE_FOURCC_YUV410, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 2, 2, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 2, 2, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YUV411, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 2, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 2, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YUV420, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 1, 1, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 1, 1, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YUV422, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 1, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 1, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YUV444, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YVU410, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 2, 2, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 2, 2, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YVU411, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 2, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 2, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YVU420, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 1, 1, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 1, 1, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YVU422, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 1, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 1, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YVU444, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_NV12, __DRI_IMAGE_COMPONENTS_Y_UV, 2,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 1, 1, __DRI_IMAGE_FORMAT_GR88, 2 } } },
> +
> +   { __DRI_IMAG

Re: [Mesa-dev] [PATCH 1/3] etnaviv: Add support for extended texture formats

2017-05-22 Thread Lucas Stach
Am Dienstag, den 16.05.2017, 21:31 +0200 schrieb Christian Gmeiner:
> Hi Wladimir.
> 
> I started working on this topic last week and thought some time on how
> to add those ext texture formats in a clean and nice way. I come up
> with this patches:
> 
> https://github.com/austriancoder/mesa/commit/1fac9dd179976dce3d991bb0715707021c093f1a.patch
> https://github.com/austriancoder/mesa/commit/f408fc40a028fa00e87900e6fd4cce65ee6640c2.patch
> 
> IMO it is a simpler implementation as I do not need two variants of
> macros (base and extended) and there is no need for
> translate_texture_format_ext(..).
> What is your opinion about it?

This looks much cleaner. I like it!

Just a heads up if you haven't noticed: the first patch is broken, as
sv->base isn't initialized yet at the point where the format is
converted. I had to apply the following diff to make it work:

>8
-   const uint32_t format = translate_texture_format(sv->base.format);
+   const uint32_t format = translate_texture_format(so->format);
8<

Regards,
Lucas

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


Re: [Mesa-dev] [PATCH v3 01/15] st/dri: refactor multi-planar YUV import path

2017-05-23 Thread Lucas Stach
Hi Varad,

Am Dienstag, den 23.05.2017, 14:40 +0530 schrieb Varad Gautam:
> Hi Lucas,
> 
> On Mon, May 22, 2017 at 11:16 PM, Lucas Stach  wrote:
> > Am Mittwoch, den 10.05.2017, 23:15 +0530 schrieb Varad Gautam:
> >> From: Varad Gautam 
> >>
> >> we currently ignore the plane count when converting from
> >> __DRI_IMAGE_FORMAT* tokens to __DRI_IMAGE_FOURCC* for multiplanar
> >> images, and only return the first plane's simplified fourcc.
> >>
> >> this adds a fourcc to __DRI_IMAGE_FORMAT_* mapping to dri, allowing
> >> us to return the correct fourcc format from DRIimage queries, and
> >> simplifies the multiplane import logic.
> >>
> >> Signed-off-by: Varad Gautam 
> >> ---
> >>  src/gallium/state_trackers/dri/dri2.c   | 288 
> >> +++-
> >>  src/gallium/state_trackers/dri/dri_screen.h |  13 ++
> >>  2 files changed, 168 insertions(+), 133 deletions(-)
> >>
> >> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> >> b/src/gallium/state_trackers/dri/dri2.c
> >> index ed6004f..0c5783c 100644
> >> --- a/src/gallium/state_trackers/dri/dri2.c
> >> +++ b/src/gallium/state_trackers/dri/dri2.c
> >> @@ -52,93 +52,133 @@
> >>  #include "dri_query_renderer.h"
> >>  #include "dri2_buffer.h"
> >>
> >> -static int convert_fourcc(int format, int *dri_components_p)
> >> +/* format list taken from intel_screen.c */
> >> +static struct image_format image_formats[] = {
> >> +   { __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_ABGR, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_ABGR, 4 } } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_XBGR, __DRI_IMAGE_COMPONENTS_RGB, 1,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_XBGR, 4 }, } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_ARGB1555, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB1555, 2 } } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_RGB565, __DRI_IMAGE_COMPONENTS_RGB, 1,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_RGB565, 2 } } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_R8, __DRI_IMAGE_COMPONENTS_R, 1,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 }, } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_R16, __DRI_IMAGE_COMPONENTS_R, 1,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R16, 1 }, } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_GR88, __DRI_IMAGE_COMPONENTS_RG, 1,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_GR88, 2 }, } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_GR1616, __DRI_IMAGE_COMPONENTS_RG, 1,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_GR1616, 2 }, } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_YUV410, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> >> +   { 1, 2, 2, __DRI_IMAGE_FORMAT_R8, 1 },
> >> +   { 2, 2, 2, __DRI_IMAGE_FORMAT_R8, 1 } } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_YUV411, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> >> +   { 1, 2, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> >> +   { 2, 2, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_YUV420, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> >> +   { 1, 1, 1, __DRI_IMAGE_FORMAT_R8, 1 },
> >> +   { 2, 1, 1, __DRI_IMAGE_FORMAT_R8, 1 } } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_YUV422, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> >> +   { 1, 1, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> >> +   { 2, 1, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_YUV444, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> >> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> >> +   { 1, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> >> +   { 2, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> >> +
> >> +   { __DRI_IMAGE_FOURCC_YVU410, __DRI_IMAGE_COM

Re: [Mesa-dev] [PATCH] etnaviv: Don't try to use the index buffer if size is zero

2017-05-29 Thread Lucas Stach
Hi Tomeu,

Am Freitag, den 19.05.2017, 12:40 +0200 schrieb Tomeu Vizoso:
> If info->index_size is zero, info->index will point to uninitialized
> memory.
> 
> Fatal signal 11 (SIGSEGV), code 2, fault addr 0xab5d07a3 in tid 20456 
> (surfaceflinger)
> 
> Signed-off-by: Tomeu Vizoso 
> Cc: etna...@lists.freedesktop.org
> Cc: Marek Olšák 
> Fixes: 330d0607ed60 ("gallium: remove pipe_index_buffer and set_index_buffer")
> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.c | 36 
> +++
>  1 file changed, 20 insertions(+), 16 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
> b/src/gallium/drivers/etnaviv/etnaviv_context.c
> index 306cb6fc498d..dcda4088bfd5 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> @@ -178,24 +178,28 @@ etna_draw_vbo(struct pipe_context *pctx, const struct 
> pipe_draw_info *info)
>  
> /* Upload a user index buffer. */
> unsigned index_offset = 0;
> -   struct pipe_resource *indexbuf = info->has_user_indices ? NULL : 
> info->index.resource;
> -   if (info->index_size && info->has_user_indices &&
> -   !util_upload_index_buffer(pctx, info, &indexbuf, &index_offset)) {
> -  BUG("Index buffer upload failed.");
> -  return;
> -   }
> +   struct pipe_resource *indexbuf = NULL;
>  
> -   if (info->index_size && indexbuf) {
> -  ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.bo = 
> etna_resource(indexbuf)->bo;
> -  ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.offset = index_offset;
> -  ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.flags = ETNA_RELOC_READ;
> -  ctx->index_buffer.FE_INDEX_STREAM_CONTROL = 
> translate_index_size(info->index_size);
> -  ctx->dirty |= ETNA_DIRTY_INDEX_BUFFER;
> -   }
> +   if (info->index_size) {
> +  indexbuf = info->has_user_indices ? NULL : info->index.resource;
> +  if (info->has_user_indices &&
> +  !util_upload_index_buffer(pctx, info, &indexbuf, &index_offset)) {
> + BUG("Index buffer upload failed.");
> + return;
> +  }
>  
> -   if (info->index_size && !ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.bo) {
> -  BUG("Unsupported or no index buffer");
> -  return;
> +  if (indexbuf) {

This can be simplified: If this is a indexed draw (index_size != 0) then
we will have a indexbuf at that point in the code, as its either
provided or constructed via the util_upload_index_buffer() call.

Mind if squash this simplification into your patch while pushing?

Regards,
Lucas

> + ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.bo = 
> etna_resource(indexbuf)->bo;
> + ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.offset = index_offset;
> + ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.flags = ETNA_RELOC_READ;
> + ctx->index_buffer.FE_INDEX_STREAM_CONTROL = 
> translate_index_size(info->index_size);
> + ctx->dirty |= ETNA_DIRTY_INDEX_BUFFER;
> +  }
> +
> +  if (!ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.bo) {
> + BUG("Unsupported or no index buffer");
> + return;
> +  }
> }
>  
> struct etna_shader_key key = {};


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


Re: [Mesa-dev] [PATCH 1/6] etnaviv: always do cpu_fini in transfer_unmap

2017-05-30 Thread Lucas Stach
Can someone please take a look at this one patch at least? I'm fine with
the rest of the series waiting a bit longer, but I would like to push
this bugfix patch in the next few days.

Thanks,
Lucas

Am Freitag, den 19.05.2017, 11:41 +0200 schrieb Lucas Stach:
> The cpu_fini() call pushes the buffer back into the GPU domain, which needs
> to be done for all buffers, not just the ones with CPU written content. The
> etnaviv kernel driver currently doesn't validate this, but may start to do
> so at a later point in time. If there is a temporary resource the fini needs
> to happen before the RS uses this one as the source for the upload.
> 
> Also remove an invalid comment about flushing CPU caches, cpu_fini takes
> care of everything involved in this.
> 
> Fixes: c9e8b49b885 ("etnaviv: gallium driver for Vivante GPUs")
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_transfer.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 1a5aa7fc043c..4809b04ff95f 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -70,6 +70,9 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> pipe_transfer *ptrans)
> if (rsc->texture && !etna_resource_newer(rsc, 
> etna_resource(rsc->texture)))
>rsc = etna_resource(rsc->texture); /* switch to using the texture 
> resource */
>  
> +   if (trans->rsc)
> +  etna_bo_cpu_fini(etna_resource(trans->rsc)->bo);
> +
> if (ptrans->usage & PIPE_TRANSFER_WRITE) {
>if (trans->rsc) {
>   /* We have a temporary resource due to either tile status or
> @@ -105,15 +108,15 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> pipe_transfer *ptrans)
>}
>  
>rsc->seqno++;
> -  etna_bo_cpu_fini(rsc->bo);
>  
>if (rsc->base.bind & PIPE_BIND_SAMPLER_VIEW) {
> - /* XXX do we need to flush the CPU cache too or start a write 
> barrier
> -  * to make sure the GPU sees it? */
>   ctx->dirty |= ETNA_DIRTY_TEXTURE_CACHES;
>}
> }
>  
> +   if (!trans->rsc)
> +  etna_bo_cpu_fini(rsc->bo);
> +
> pipe_resource_reference(&trans->rsc, NULL);
> pipe_resource_reference(&ptrans->resource, NULL);
> slab_free(&ctx->transfer_pool, trans);


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


[Mesa-dev] [PATCH 0/6] Shooting some piglits

2017-06-04 Thread Lucas Stach
Hi all,

I decided to take a look at our current piglit status and the following are
some stright foward fixes for some of the issues.

The first 3 patches fix some resource copy issues, that may send the blitter
into an infinite loop in a release build, or just fall over in a debug build.

The next 2 patches fix some fallout from the RB swapped rendertarget work, so
they are fixing real regressions from mesa 17.0.

The last patch gets the LOD bias test to pass.

Regards,
Lucas

Lucas Stach (6):
  etnaviv: don't try RS blit if blit region is unaligned
  etnaviv: use padded width/height for resource copies
  etnaviv: remove bogus assert
  etnaviv: replace translate_clear_color with util_pack_color
  etnaviv: mask correct channel for RB swapped rendertargets
  etnaviv: advertise correct max LOD bias

 src/gallium/drivers/etnaviv/etnaviv_blend.c  | 48 +---
 src/gallium/drivers/etnaviv/etnaviv_blend.h  |  7 
 src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 22 ---
 src/gallium/drivers/etnaviv/etnaviv_screen.c |  4 +-
 src/gallium/drivers/etnaviv/etnaviv_state.c  |  4 ++
 src/gallium/drivers/etnaviv/etnaviv_translate.h  | 47 ---
 6 files changed, 65 insertions(+), 67 deletions(-)

-- 
2.9.4

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


[Mesa-dev] [PATCH 3/6] etnaviv: remove bogus assert

2017-06-04 Thread Lucas Stach
etna_resource_copy_region handles resources with multiple samples
by falling back to the software path. There is no need to kill the
application there.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
index 263b283..6a61ae2 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
@@ -285,8 +285,6 @@ etna_resource_copy_region(struct pipe_context *pctx, struct 
pipe_resource *dst,
 
/* The resource must be of the same format. */
assert(src->format == dst->format);
-   /* Resources with nr_samples > 1 are not allowed. */
-   assert(src->nr_samples <= 1 && dst->nr_samples <= 1);
 
/* XXX we can use the RS as a literal copy engine here
 * the only complexity is tiling; the size of the boxes needs to be aligned
-- 
2.9.4

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


[Mesa-dev] [PATCH 1/6] etnaviv: don't try RS blit if blit region is unaligned

2017-06-04 Thread Lucas Stach
If the blit region is not aligned to the RS min alignment don't try
to execute the blit, but fall back to the software path.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
index ae1c586..6844943 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
@@ -446,7 +446,8 @@ etna_try_rs_blit(struct pipe_context *pctx,
if (width > src_lev->padded_width ||
width > dst_lev->padded_width * msaa_xscale ||
height > src_lev->padded_height ||
-   height > dst_lev->padded_height * msaa_yscale)
+   height > dst_lev->padded_height * msaa_yscale ||
+   width & (w_align - 1) || height & (h_align - 1))
   goto manual;
 
if (src->base.nr_samples > 1) {
-- 
2.9.4

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


[Mesa-dev] [PATCH 2/6] etnaviv: use padded width/height for resource copies

2017-06-04 Thread Lucas Stach
When copying a resource fully we can just blit the whole level. This allows
to use the RS even for level sizes not aligned to the RS min alignment. This
is especially useful, as etna_copy_resource is part of the software fallback
paths (used in etna_transfer), that are used for doing unaligned copies.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
index 6844943..263b283 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
@@ -626,9 +626,9 @@ etna_copy_resource(struct pipe_context *pctx, struct 
pipe_resource *dst,
for (int level = first_level; level <= last_level; level++) {
   blit.src.level = blit.dst.level = level;
   blit.src.box.width = blit.dst.box.width =
- MIN2(src_priv->levels[level].width, dst_priv->levels[level].width);
+ MIN2(src_priv->levels[level].padded_width, 
dst_priv->levels[level].padded_width);
   blit.src.box.height = blit.dst.box.height =
- MIN2(src_priv->levels[level].height, dst_priv->levels[level].height);
+ MIN2(src_priv->levels[level].padded_height, 
dst_priv->levels[level].padded_height);
 
   for (int layer = 0; layer < dst->array_size; layer++) {
  blit.src.box.z = blit.dst.box.z = layer;
-- 
2.9.4

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


[Mesa-dev] [PATCH 4/6] etnaviv: replace translate_clear_color with util_pack_color

2017-06-04 Thread Lucas Stach
This replaces the open coded etnaviv version of the color pack with the
common util_pack_color.

Fixes piglits:
arb_color_buffer_float-clear
fcc-front-buffer-distraction
fbo-clearmipmap

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 13 ++-
 src/gallium/drivers/etnaviv/etnaviv_translate.h  | 47 
 2 files changed, 12 insertions(+), 48 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
index 6a61ae2..db23a84 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
@@ -100,13 +100,24 @@ etna_rs_gen_clear_surface(struct etna_context *ctx, 
struct etna_surface *surf,
});
 }
 
+static inline uint32_t
+pack_rgba(enum pipe_format format, const float *rgba)
+{
+   union util_color uc;
+   util_pack_color(rgba, format, &uc);
+   if (util_format_get_blocksize(format) == 2)
+  return uc.ui[0] << 16 | uc.ui[0];
+   else
+  return uc.ui[0];
+}
+
 static void
 etna_blit_clear_color(struct pipe_context *pctx, struct pipe_surface *dst,
   const union pipe_color_union *color)
 {
struct etna_context *ctx = etna_context(pctx);
struct etna_surface *surf = etna_surface(dst);
-   uint32_t new_clear_value = translate_clear_color(surf->base.format, color);
+   uint32_t new_clear_value = pack_rgba(surf->base.format, color->f);
 
if (surf->surf.ts_size) { /* TS: use precompiled clear command */
   ctx->framebuffer.TS_COLOR_CLEAR_VALUE = new_clear_value;
diff --git a/src/gallium/drivers/etnaviv/etnaviv_translate.h 
b/src/gallium/drivers/etnaviv/etnaviv_translate.h
index e8466d6..cbbfdf2 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_translate.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_translate.h
@@ -405,53 +405,6 @@ etna_layout_multiple(unsigned layout, unsigned 
pixel_pipes, bool rs_align,
}
 }
 
-/* return 32-bit clear pattern for color */
-static inline uint32_t
-translate_clear_color(enum pipe_format format,
-  const union pipe_color_union *color)
-{
-   uint32_t clear_value = 0;
-
-   // XXX util_pack_color
-   switch (format) {
-   case PIPE_FORMAT_B8G8R8A8_UNORM:
-   case PIPE_FORMAT_B8G8R8X8_UNORM:
-   case PIPE_FORMAT_R8G8B8A8_UNORM:
-   case PIPE_FORMAT_R8G8B8X8_UNORM:
-  clear_value = etna_cfloat_to_uintN(color->f[2], 8) |
-(etna_cfloat_to_uintN(color->f[1], 8) << 8) |
-(etna_cfloat_to_uintN(color->f[0], 8) << 16) |
-(etna_cfloat_to_uintN(color->f[3], 8) << 24);
-  break;
-   case PIPE_FORMAT_B4G4R4X4_UNORM:
-   case PIPE_FORMAT_B4G4R4A4_UNORM:
-  clear_value = etna_cfloat_to_uintN(color->f[2], 4) |
-(etna_cfloat_to_uintN(color->f[1], 4) << 4) |
-(etna_cfloat_to_uintN(color->f[0], 4) << 8) |
-(etna_cfloat_to_uintN(color->f[3], 4) << 12);
-  clear_value |= clear_value << 16;
-  break;
-   case PIPE_FORMAT_B5G5R5X1_UNORM:
-   case PIPE_FORMAT_B5G5R5A1_UNORM:
-  clear_value = etna_cfloat_to_uintN(color->f[2], 5) |
-(etna_cfloat_to_uintN(color->f[1], 5) << 5) |
-(etna_cfloat_to_uintN(color->f[0], 5) << 10) |
-(etna_cfloat_to_uintN(color->f[3], 1) << 15);
-  clear_value |= clear_value << 16;
-  break;
-   case PIPE_FORMAT_B5G6R5_UNORM:
-  clear_value = etna_cfloat_to_uintN(color->f[2], 5) |
-(etna_cfloat_to_uintN(color->f[1], 6) << 5) |
-(etna_cfloat_to_uintN(color->f[0], 5) << 11);
-  clear_value |= clear_value << 16;
-  break;
-   default:
-  DBG("Unhandled pipe format for color clear: %i", format);
-   }
-
-   return clear_value;
-}
-
 static inline uint32_t
 translate_clear_depth_stencil(enum pipe_format format, float depth,
   unsigned stencil)
-- 
2.9.4

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


[Mesa-dev] [PATCH 6/6] etnaviv: advertise correct max LOD bias

2017-06-04 Thread Lucas Stach
The maximum LOD bias supported is the same as the max texture level
supported.

Fixes piglit: ext_texture_lod_bias

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_screen.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index 8fd1184..bfd3d88 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -344,6 +344,8 @@ etna_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
 static float
 etna_screen_get_paramf(struct pipe_screen *pscreen, enum pipe_capf param)
 {
+   struct etna_screen *screen = etna_screen(pscreen);
+
switch (param) {
case PIPE_CAPF_MAX_LINE_WIDTH:
case PIPE_CAPF_MAX_LINE_WIDTH_AA:
@@ -353,7 +355,7 @@ etna_screen_get_paramf(struct pipe_screen *pscreen, enum 
pipe_capf param)
case PIPE_CAPF_MAX_TEXTURE_ANISOTROPY:
   return 16.0f;
case PIPE_CAPF_MAX_TEXTURE_LOD_BIAS:
-  return 16.0f;
+  return util_last_bit(screen->specs.max_texture_size);
case PIPE_CAPF_GUARD_BAND_LEFT:
case PIPE_CAPF_GUARD_BAND_TOP:
case PIPE_CAPF_GUARD_BAND_RIGHT:
-- 
2.9.4

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


[Mesa-dev] [PATCH 5/6] etnaviv: mask correct channel for RB swapped rendertargets

2017-06-04 Thread Lucas Stach
Now that we support RB swapped targets by using a shader variant, we
must derive the color mask from both the blend state and the bound
framebuffer.

Fixes piglit: fbo-colormask-formats

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_blend.c | 48 +
 src/gallium/drivers/etnaviv/etnaviv_blend.h |  7 +
 src/gallium/drivers/etnaviv/etnaviv_state.c |  4 +++
 3 files changed, 46 insertions(+), 13 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_blend.c 
b/src/gallium/drivers/etnaviv/etnaviv_blend.c
index ebef75d..8ea09a3 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_blend.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_blend.c
@@ -48,7 +48,7 @@ etna_blend_state_create(struct pipe_context *pctx,
 * - NOT source factor is ONE and destination factor ZERO for both rgb and
 *   alpha (which would mean that blending is effectively disabled)
 */
-   bool enable = rt0->blend_enable &&
+   co->enable = rt0->blend_enable &&
  !(rt0->rgb_src_factor == PIPE_BLENDFACTOR_ONE &&
rt0->rgb_dst_factor == PIPE_BLENDFACTOR_ZERO &&
rt0->alpha_src_factor == PIPE_BLENDFACTOR_ONE &&
@@ -59,17 +59,11 @@ etna_blend_state_create(struct pipe_context *pctx,
 * - NOT source factor is equal to destination factor for both rgb abd
 *   alpha (which would effectively that mean alpha is not separate)
 */
-   bool separate_alpha = enable &&
+   bool separate_alpha = co->enable &&
  !(rt0->rgb_src_factor == rt0->alpha_src_factor &&
rt0->rgb_dst_factor == rt0->alpha_dst_factor);
 
-   /* If the complete render target is written, set full_overwrite:
-* - The color mask is 
-* - No blending is used
-*/
-   bool full_overwrite = (rt0->colormask == 15) && !enable;
-
-   if (enable) {
+   if (co->enable) {
   co->PE_ALPHA_CONFIG =
  VIVS_PE_ALPHA_CONFIG_BLEND_ENABLE_COLOR |
  COND(separate_alpha, VIVS_PE_ALPHA_CONFIG_BLEND_SEPARATE_ALPHA) |
@@ -83,10 +77,6 @@ etna_blend_state_create(struct pipe_context *pctx,
   co->PE_ALPHA_CONFIG = 0;
}
 
-   co->PE_COLOR_FORMAT =
- VIVS_PE_COLOR_FORMAT_COMPONENTS(rt0->colormask) |
- COND(full_overwrite, VIVS_PE_COLOR_FORMAT_OVERWRITE);
-
co->PE_LOGIC_OP =
  VIVS_PE_LOGIC_OP_OP(so->logicop_enable ? so->logicop_func : 
LOGIC_OP_COPY) |
  0x000E4000 /* ??? */;
@@ -107,3 +97,35 @@ etna_blend_state_create(struct pipe_context *pctx,
 
return co;
 }
+
+bool
+etna_update_blend(struct etna_context *ctx)
+{
+   struct pipe_framebuffer_state *pfb = &ctx->framebuffer_s;
+   struct pipe_blend_state *pblend = ctx->blend;
+   struct etna_blend_state *blend = etna_blend_state(pblend);
+   const struct pipe_rt_blend_state *rt0 = &pblend->rt[0];
+   uint32_t colormask;
+
+   if (pfb->cbufs[0] &&
+   translate_rs_format_rb_swap(pfb->cbufs[0]->texture->format)) {
+  colormask = rt0->colormask & (PIPE_MASK_A | PIPE_MASK_G);
+  if (rt0->colormask & PIPE_MASK_R)
+ colormask |= PIPE_MASK_B;
+  if (rt0->colormask & PIPE_MASK_B)
+ colormask |= PIPE_MASK_R;
+   } else {
+  colormask = rt0->colormask;
+   }
+
+   /* If the complete render target is written, set full_overwrite:
+* - The color mask is 
+* - No blending is used
+*/
+   bool full_overwrite = (rt0->colormask == 0xf) && !blend->enable;
+   blend->PE_COLOR_FORMAT =
+VIVS_PE_COLOR_FORMAT_COMPONENTS(colormask) |
+COND(full_overwrite, VIVS_PE_COLOR_FORMAT_OVERWRITE);
+
+   return true;
+}
diff --git a/src/gallium/drivers/etnaviv/etnaviv_blend.h 
b/src/gallium/drivers/etnaviv/etnaviv_blend.h
index 54e7bab..e26864d 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_blend.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_blend.h
@@ -30,9 +30,13 @@
 #include "pipe/p_context.h"
 #include "pipe/p_state.h"
 
+struct etna_context;
+
 struct etna_blend_state {
struct pipe_blend_state base;
 
+   bool enable;
+
uint32_t PE_ALPHA_CONFIG;
uint32_t PE_COLOR_FORMAT;
uint32_t PE_LOGIC_OP;
@@ -49,4 +53,7 @@ void *
 etna_blend_state_create(struct pipe_context *pctx,
 const struct pipe_blend_state *so);
 
+bool
+etna_update_blend(struct etna_context *ctx);
+
 #endif
diff --git a/src/gallium/drivers/etnaviv/etnaviv_state.c 
b/src/gallium/drivers/etnaviv/etnaviv_state.c
index cd9f974..fb7bb0f 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_state.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_state.c
@@ -29,6 +29,7 @@
 
 #include "hw/common.xml.h"
 
+#include "etnaviv_blend.h"
 #include "etnaviv_clear_blit.h"
 #include "etnaviv_context.h"
 #i

Re: [Mesa-dev] [PATCH 5/6] etnaviv: mask correct channel for RB swapped rendertargets

2017-06-05 Thread Lucas Stach
Am Sonntag, den 04.06.2017, 16:37 -0400 schrieb Ilia Mirkin:
> On Sun, Jun 4, 2017 at 3:06 PM, Lucas Stach  wrote:
> > +   /* If the complete render target is written, set
> > full_overwrite:
> > +* - The color mask is 
> > +* - No blending is used
> > +*/
> > +   bool full_overwrite = (rt0->colormask == 0xf) && !blend-
> > >enable;
> > +   blend->PE_COLOR_FORMAT =
> > +VIVS_PE_COLOR_FORMAT_COMPONENTS(colormask) |
> > +COND(full_overwrite, VIVS_PE_COLOR_FORMAT_OVERWRITE);
> 
> [I realize you're just shuffling logic around, so this comment isn't
> about the patch specifically but rather about the driver.]
> 
> Presumably there's some benefit to flipping on this overwrite,
> otherwise it wouldn't exist. It should be safe to flip this on when
> the colormask is e.g. 0x7 and it's a RGB surface. You can instead use
> util_format_colormask_full() to determine if it's a full colormask
> for
> the RT format in question.

Yes, that occurred to me as well, but wanted to keep things as is for
the fixes series. Thanks for the hint, though.

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


[Mesa-dev] [PATCH] etnaviv: fix blend color for RB swapped rendertargets

2017-06-05 Thread Lucas Stach
Same as with the colormasks, the blend color needs to be swizzled according
to the rendertarget format.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_blend.c| 35 ++
 src/gallium/drivers/etnaviv/etnaviv_blend.h|  6 +
 src/gallium/drivers/etnaviv/etnaviv_internal.h |  1 +
 src/gallium/drivers/etnaviv/etnaviv_state.c| 17 +++--
 4 files changed, 45 insertions(+), 14 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_blend.c 
b/src/gallium/drivers/etnaviv/etnaviv_blend.c
index 8ea09a3..6ed0e0f 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_blend.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_blend.c
@@ -129,3 +129,38 @@ etna_update_blend(struct etna_context *ctx)
 
return true;
 }
+
+void
+etna_set_blend_color(struct pipe_context *pctx, const struct pipe_blend_color 
*bc)
+{
+   struct etna_context *ctx = etna_context(pctx);
+   struct compiled_blend_color *cs = &ctx->blend_color;
+
+   memcpy(cs->color, bc->color, sizeof(float) * 4);
+
+   ctx->dirty |= ETNA_DIRTY_BLEND_COLOR;
+}
+
+bool
+etna_update_blend_color(struct etna_context *ctx)
+{
+   struct pipe_framebuffer_state *pfb = &ctx->framebuffer_s;
+   struct compiled_blend_color *cs = &ctx->blend_color;
+
+   if (pfb->cbufs[0] &&
+   translate_rs_format_rb_swap(pfb->cbufs[0]->texture->format)) {
+  cs->PE_ALPHA_BLEND_COLOR =
+ VIVS_PE_ALPHA_BLEND_COLOR_R(etna_cfloat_to_uint8(cs->color[2])) |
+ VIVS_PE_ALPHA_BLEND_COLOR_G(etna_cfloat_to_uint8(cs->color[1])) |
+ VIVS_PE_ALPHA_BLEND_COLOR_B(etna_cfloat_to_uint8(cs->color[0])) |
+ VIVS_PE_ALPHA_BLEND_COLOR_A(etna_cfloat_to_uint8(cs->color[3]));
+   } else {
+  cs->PE_ALPHA_BLEND_COLOR =
+ VIVS_PE_ALPHA_BLEND_COLOR_R(etna_cfloat_to_uint8(cs->color[0])) |
+ VIVS_PE_ALPHA_BLEND_COLOR_G(etna_cfloat_to_uint8(cs->color[1])) |
+ VIVS_PE_ALPHA_BLEND_COLOR_B(etna_cfloat_to_uint8(cs->color[2])) |
+ VIVS_PE_ALPHA_BLEND_COLOR_A(etna_cfloat_to_uint8(cs->color[3]));
+   }
+
+   return true;
+}
diff --git a/src/gallium/drivers/etnaviv/etnaviv_blend.h 
b/src/gallium/drivers/etnaviv/etnaviv_blend.h
index e26864d..c219396 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_blend.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_blend.h
@@ -56,4 +56,10 @@ etna_blend_state_create(struct pipe_context *pctx,
 bool
 etna_update_blend(struct etna_context *ctx);
 
+void
+etna_set_blend_color(struct pipe_context *pctx, const struct pipe_blend_color 
*bc);
+
+bool
+etna_update_blend_color(struct etna_context *ctx);
+
 #endif
diff --git a/src/gallium/drivers/etnaviv/etnaviv_internal.h 
b/src/gallium/drivers/etnaviv/etnaviv_internal.h
index 2f8dacb..1212fdf 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_internal.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_internal.h
@@ -126,6 +126,7 @@ struct etna_specs {
 
 /* Compiled pipe_blend_color */
 struct compiled_blend_color {
+   float color[4];
uint32_t PE_ALPHA_BLEND_COLOR;
 };
 
diff --git a/src/gallium/drivers/etnaviv/etnaviv_state.c 
b/src/gallium/drivers/etnaviv/etnaviv_state.c
index fb7bb0f..fc3d9f1 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_state.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_state.c
@@ -43,20 +43,6 @@
 #include "util/u_memory.h"
 
 static void
-etna_set_blend_color(struct pipe_context *pctx, const struct pipe_blend_color 
*bc)
-{
-   struct etna_context *ctx = etna_context(pctx);
-   struct compiled_blend_color *cs = &ctx->blend_color;
-
-   cs->PE_ALPHA_BLEND_COLOR =
-  VIVS_PE_ALPHA_BLEND_COLOR_R(etna_cfloat_to_uint8(bc->color[0])) |
-  VIVS_PE_ALPHA_BLEND_COLOR_G(etna_cfloat_to_uint8(bc->color[1])) |
-  VIVS_PE_ALPHA_BLEND_COLOR_B(etna_cfloat_to_uint8(bc->color[2])) |
-  VIVS_PE_ALPHA_BLEND_COLOR_A(etna_cfloat_to_uint8(bc->color[3]));
-   ctx->dirty |= ETNA_DIRTY_BLEND_COLOR;
-}
-
-static void
 etna_set_stencil_ref(struct pipe_context *pctx, const struct pipe_stencil_ref 
*sr)
 {
struct etna_context *ctx = etna_context(pctx);
@@ -600,6 +586,9 @@ static const struct etna_state_updater etna_state_updates[] 
= {
},
{
   etna_update_blend, ETNA_DIRTY_BLEND | ETNA_DIRTY_FRAMEBUFFER
+   },
+   {
+  etna_update_blend_color, ETNA_DIRTY_BLEND_COLOR | ETNA_DIRTY_FRAMEBUFFER,
}
 };
 
-- 
2.9.4

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


Re: [Mesa-dev] [PATCH 0/6] Shooting some piglits

2017-06-05 Thread Lucas Stach
Hi Fabio,

Am Sonntag, den 04.06.2017, 18:26 -0300 schrieb Fabio Estevam:
> Hi Lucas,
> 
> On Sun, Jun 4, 2017 at 4:06 PM, Lucas Stach  wrote:
> > Hi all,
> > 
> > I decided to take a look at our current piglit status and the
> > following are
> > some stright foward fixes for some of the issues.
> > 
> > The first 3 patches fix some resource copy issues, that may send
> > the blitter
> > into an infinite loop in a release build, or just fall over in a
> > debug build.
> > 
> > The next 2 patches fix some fallout from the RB swapped
> > rendertarget work, so
> > they are fixing real regressions from mesa 17.0.
> > 
> > The last patch gets the LOD bias test to pass.
> 
> Out of curiosity: what is the piglit pass rate for etnaviv now?

For a tests/quick OpenGL + ES2 run, we are at 1511 out of 2489 tests
passing.

A big pile of the failing tests are for desktop GL 1 features, where
the hardware lacks the necessary features and it's unclear if adding
emulation would fix any real world applications. If you look only at
the ES2 profile things look much better, but I don't have the numbers
handy.

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


[Mesa-dev] [PATCH 2/2] etnaviv: flush resource when binding as sampler view

2017-06-06 Thread Lucas Stach
As TS is also allowed on sampler resources, we need to make sure to resolve
to self when binding the resource as a texture, to avoid stale content
being sampled.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_texture.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_texture.c 
b/src/gallium/drivers/etnaviv/etnaviv_texture.c
index 6f77af286f26..df77829078c0 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_texture.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_texture.c
@@ -120,6 +120,9 @@ etna_update_sampler_source(struct pipe_sampler_view *view)
   etna_copy_resource(view->context, res->texture, view->texture, 0,
  view->texture->last_level);
   etna_resource(res->texture)->seqno = res->seqno;
+   } else if (etna_resource_needs_flush(res)) {
+  etna_copy_resource(view->context, view->texture, view->texture, 0, 0);
+  res->flush_seqno = res->seqno;
}
 }
 
-- 
2.11.0

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


[Mesa-dev] [PATCH 1/2] etnaviv: don't flush resource to self without TS

2017-06-06 Thread Lucas Stach
From: Lucas Stach 

A resolve to self is only necessary if the resource is fast cleared, so
there is never a need to do so if there is no TS allocated.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_resource.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
b/src/gallium/drivers/etnaviv/etnaviv_resource.h
index a8d42ee1a09f..1084103386ef 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
@@ -102,7 +102,7 @@ etna_resource_older(struct etna_resource *a, struct 
etna_resource *b)
 static inline bool
 etna_resource_needs_flush(struct etna_resource *res)
 {
-   return (int)(res->seqno - res->flush_seqno) > 0;
+   return res->ts_bo && ((int)(res->seqno - res->flush_seqno) > 0);
 }
 
 /* is the resource only used on the sampler? */
-- 
2.11.0

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


Re: [Mesa-dev] [PATCH 3/6] etnaviv: honor PIPE_TRANSFER_UNSYNCHRONIZED flag

2017-06-06 Thread Lucas Stach
Am Dienstag, den 30.05.2017, 17:40 +0200 schrieb Philipp Zabel:
> On Fri, 2017-05-19 at 11:41 +0200, Lucas Stach wrote:
> > This gets rid of quite a bit of CPU/GPU sync on frequent vertex buffer
> > uploads and I haven't seen any of the issues mentioned in the comment,
> > so this one seems stale.
> > 
> > Ignore the flag if there exists a temporary resource, as those ones are
> > never busy.
> > 
> > Signed-off-by: Lucas Stach 
> > ---
> >  src/gallium/drivers/etnaviv/etnaviv_transfer.c | 22 ++
> >  1 file changed, 10 insertions(+), 12 deletions(-)
> > 
> > diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> > b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> > index 269bd498f89f..a2cd4e6234dd 100644
> > --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> > +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> > @@ -114,7 +114,7 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> > pipe_transfer *ptrans)
> >}
> > }
> >  
> > -   if (!trans->rsc)
> > +   if (!trans->rsc && !(ptrans->usage & PIPE_TRANSFER_UNSYNCHRONIZED))
> 
> As we just talked about, this looks like it should be '||' ...

This is actually correct as-is, the || below is for the "have temp
resource" case, while this cpu_fini is for the "no temp resource" path.

This deserves a comment, which I'll add before pushing out.

Regards,
Lucas

> >etna_bo_cpu_fini(rsc->bo);
> >  
> > pipe_resource_reference(&trans->rsc, NULL);
> > @@ -260,19 +260,17 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> > pipe_resource *prsc,
> > (rsc->layout == ETNA_LAYOUT_TILED &&
> >  util_format_is_compressed(prsc->format));
> >  
> > -   /* Ignore PIPE_TRANSFER_UNSYNCHRONIZED and PIPE_TRANSFER_DONTBLOCK here.
> > -* It appears that Gallium operates the index/vertex buffers in a
> > -* circular fashion, and the CPU can catch up with the GPU and starts
> > -* overwriting yet-to-be-processed entries, causing rendering 
> > corruption. */
> > -   uint32_t prep_flags = 0;
> > +   if (trans->rsc || !(usage & PIPE_TRANSFER_UNSYNCHRONIZED)) {
> 
> ... for symmetry with etna_bo_cpu_prep call below.
> 
> > +  uint32_t prep_flags = 0;
> >  
> > -   if (usage & PIPE_TRANSFER_READ)
> > -  prep_flags |= DRM_ETNA_PREP_READ;
> > -   if (usage & PIPE_TRANSFER_WRITE)
> > -  prep_flags |= DRM_ETNA_PREP_WRITE;
> > +  if (usage & PIPE_TRANSFER_READ)
> > + prep_flags |= DRM_ETNA_PREP_READ;
> > +  if (usage & PIPE_TRANSFER_WRITE)
> > + prep_flags |= DRM_ETNA_PREP_WRITE;
> >  
> > -   if (etna_bo_cpu_prep(rsc->bo, prep_flags))
> > -  goto fail_prep;
> > +  if (etna_bo_cpu_prep(rsc->bo, prep_flags))
> > + goto fail_prep;
> > +   }
> >  
> > /* map buffer object */
> > void *mapped = etna_bo_map(rsc->bo);
> 
> regards
> Philipp
> 
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv


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


Re: [Mesa-dev] [PATCH 1/2] etnaviv: don't flush resource to self without TS

2017-06-06 Thread Lucas Stach
Am Dienstag, den 06.06.2017, 12:59 +0200 schrieb Wladimir J. van der
Laan:
> On Tue, Jun 06, 2017 at 12:38:23PM +0200, Lucas Stach wrote:
> > From: Lucas Stach 
> > 
> > A resolve to self is only necessary if the resource is fast cleared, so
> > there is never a need to do so if there is no TS allocated.
> > 
> > Signed-off-by: Lucas Stach 
> 
> Does this take into account the case on GC2000, where there can be a texture 
> resource
> that is out of date with the rendered-to resource?

Yes, etna_resource_needs_flush is only used for the self-resolve cases.
Other cases are handled by explicitly comparing the seqno of the
resource with the seqno of the derived (like texture) resources.

Regards,
Lucas

> If so:
> Reviewed-By: Wladimir J. van der Laan 
> 
> > ---
> >  src/gallium/drivers/etnaviv/etnaviv_resource.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
> > b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> > index a8d42ee1a09f..1084103386ef 100644
> > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> > @@ -102,7 +102,7 @@ etna_resource_older(struct etna_resource *a, struct 
> > etna_resource *b)
> >  static inline bool
> >  etna_resource_needs_flush(struct etna_resource *res)
> >  {
> > -   return (int)(res->seqno - res->flush_seqno) > 0;
> > +   return res->ts_bo && ((int)(res->seqno - res->flush_seqno) > 0);
> >  }
> >  
> >  /* is the resource only used on the sampler? */
> > -- 
> > 2.11.0
> > 
> > ___
> > etnaviv mailing list
> > etna...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/etnaviv


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


Re: [Mesa-dev] [PATCH 6/6] etnaviv: upgrade DISCARD_RANGE to DISCARD_WHOLE_RESOURCE if possible

2017-06-08 Thread Lucas Stach
Hi Wladimir,

did you also review this patch? It's the last one of this series missing
review.

Regards,
Lucas

Am Freitag, den 19.05.2017, 11:41 +0200 schrieb Lucas Stach:
> Stolen from VC4. As we don't do any fancy reallocation tricks yet, it's
> possible to upgrade also coherent mappings and shared resources.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_transfer.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 05cdbc599956..fe57aa4d17b2 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -148,6 +148,20 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>  
> assert(level <= prsc->last_level);
>  
> +   /* Upgrade DISCARD_RANGE to WHOLE_RESOURCE if the whole resource is
> +* being mapped. If we add buffer reallocation to avoid CPU/GPU sync this
> +* check needs to be extended to coherent mappings and shared resources.
> +*/
> +   if ((usage & PIPE_TRANSFER_DISCARD_RANGE) &&
> +   !(usage & PIPE_TRANSFER_UNSYNCHRONIZED) &&
> +   prsc->last_level == 0 &&
> +   prsc->width0 == box->width &&
> +   prsc->height0 == box->height &&
> +   prsc->depth0 == box->depth &&
> +   prsc->array_size == 1) {
> +  usage |= PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE;
> +   }
> +
> if (rsc->texture && !etna_resource_newer(rsc, 
> etna_resource(rsc->texture))) {
>/* We have a texture resource which is the same age or newer than the
> * render resource. Use the texture resource, which avoids bouncing


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


[Mesa-dev] [PATCH 2/2] etnaviv: remove flat shading workaround

2017-06-08 Thread Lucas Stach
It turned out not to be a hardware bug, but the shader compiler
emitting wrong varying component use information. With that fixed
we can turn flat shading back on.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_rasterizer.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_rasterizer.c 
b/src/gallium/drivers/etnaviv/etnaviv_rasterizer.c
index 4990fd180257..56f2735e8a18 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_rasterizer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_rasterizer.c
@@ -38,10 +38,6 @@ etna_rasterizer_state_create(struct pipe_context *pctx,
struct etna_rasterizer_state *cs;
struct etna_context *ctx = etna_context(pctx);
 
-/* Disregard flatshading on GC880+, as a HW bug there seem to disable all
- * varying interpolation if it's enabled */
-   bool flatshade = ctx->screen->model < 880 ? so->flatshade : false;
-
if (so->fill_front != so->fill_back)
   DBG("Different front and back fill mode not supported");
 
@@ -51,7 +47,7 @@ etna_rasterizer_state_create(struct pipe_context *pctx,
 
cs->base = *so;
 
-   cs->PA_CONFIG = (flatshade ? VIVS_PA_CONFIG_SHADE_MODEL_FLAT : 
VIVS_PA_CONFIG_SHADE_MODEL_SMOOTH) |
+   cs->PA_CONFIG = (so->flatshade ? VIVS_PA_CONFIG_SHADE_MODEL_FLAT : 
VIVS_PA_CONFIG_SHADE_MODEL_SMOOTH) |
translate_cull_face(so->cull_face, so->front_ccw) |
translate_polygon_mode(so->fill_front) |
COND(so->point_quad_rasterization, 
VIVS_PA_CONFIG_POINT_SPRITE_ENABLE) |
-- 
2.11.0

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


[Mesa-dev] [PATCH 1/2] etnaviv: fix varying interpolation

2017-06-08 Thread Lucas Stach
It seems that newer cores don't use the PA_ATTRIBUTES to decide if the
varying should bypass the flat shading, but derive this from the component
use. This fixes flat shading on GC880+.

VARYING_COMPONENT_USE_POINTCOORD is a bit of a misnomer now, as it isn't
only used for pointcoords, but missing a better name I left it as-is.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_compiler.c | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c 
b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
index eafb511bb813..2605924613c7 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
@@ -2552,6 +2552,7 @@ etna_link_shader(struct etna_shader_link_info *info,
   const struct etna_shader_inout *fsio = &fs->infile.reg[idx];
   const struct etna_shader_inout *vsio = etna_shader_vs_lookup(vs, fsio);
   struct etna_varying *varying;
+  bool interpolate = fsio->semantic.Name != TGSI_SEMANTIC_COLOR;
 
   assert(fsio->reg > 0 && fsio->reg <= ARRAY_SIZE(info->varyings));
 
@@ -2561,28 +2562,23 @@ etna_link_shader(struct etna_shader_link_info *info,
   varying = &info->varyings[fsio->reg - 1];
   varying->num_components = fsio->num_components;
 
-  if (fsio->semantic.Name == TGSI_SEMANTIC_COLOR) /* colors affected by 
flat shading */
+  if (!interpolate) /* colors affected by flat shading */
  varying->pa_attributes = 0x200;
   else /* texture coord or other bypasses flat shading */
  varying->pa_attributes = 0x2f1;
 
-  if (fsio->semantic.Name == TGSI_SEMANTIC_PCOORD) {
- varying->use[0] = VARYING_COMPONENT_USE_POINTCOORD_X;
- varying->use[1] = VARYING_COMPONENT_USE_POINTCOORD_Y;
- varying->use[2] = VARYING_COMPONENT_USE_USED;
- varying->use[3] = VARYING_COMPONENT_USE_USED;
- varying->reg = 0; /* replaced by point coord -- doesn't matter */
+  varying->use[0] = interpolate ? VARYING_COMPONENT_USE_POINTCOORD_X : 
VARYING_COMPONENT_USE_USED;
+  varying->use[1] = interpolate ? VARYING_COMPONENT_USE_POINTCOORD_Y : 
VARYING_COMPONENT_USE_USED;
+  varying->use[2] = VARYING_COMPONENT_USE_USED;
+  varying->use[3] = VARYING_COMPONENT_USE_USED;
+  varying->reg = vsio->reg; /* replaced by point coord -- doesn't matter */
+
+
+  if (fsio->semantic.Name == TGSI_SEMANTIC_PCOORD)
  continue;
-  }
 
   if (vsio == NULL)
  return true; /* not found -- link error */
-
-  varying->use[0] = VARYING_COMPONENT_USE_USED;
-  varying->use[1] = VARYING_COMPONENT_USE_USED;
-  varying->use[2] = VARYING_COMPONENT_USE_USED;
-  varying->use[3] = VARYING_COMPONENT_USE_USED;
-  varying->reg = vsio->reg;
}
 
assert(info->num_varyings == fs->infile.num_reg);
-- 
2.11.0

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


Re: [Mesa-dev] [PATCH 6/6] etnaviv: upgrade DISCARD_RANGE to DISCARD_WHOLE_RESOURCE if possible

2017-06-08 Thread Lucas Stach
Am Donnerstag, den 08.06.2017, 15:08 +0200 schrieb Wladimir J. van der
Laan:
> Hello Lucas,
> 
> On Thu, Jun 08, 2017 at 10:26:04AM +0200, Lucas Stach wrote:
> > Hi Wladimir,
> > 
> > did you also review this patch? It's the last one of this series missing
> > review.
> 
> Sorry, no, I missed it somehow.
> Looks obviously correct to me, and matches the code from VC4 (apart from the 
> coherent which you mention), so
> 
> Reviewed-By: Wladimir J. van der Laan 

Thanks,
I've pushed this series to upstream MESA.

Regards,
Lucas

> > Am Freitag, den 19.05.2017, 11:41 +0200 schrieb Lucas Stach:
> > > Stolen from VC4. As we don't do any fancy reallocation tricks yet, it's
> > > possible to upgrade also coherent mappings and shared resources.
> > > 
> > > Signed-off-by: Lucas Stach 
> > > ---
> > >  src/gallium/drivers/etnaviv/etnaviv_transfer.c | 14 ++
> > >  1 file changed, 14 insertions(+)
> > > 
> > > diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> > > b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> > > index 05cdbc599956..fe57aa4d17b2 100644
> > > --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> > > +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> > > @@ -148,6 +148,20 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> > > pipe_resource *prsc,
> > >  
> > > assert(level <= prsc->last_level);
> > >  
> > > +   /* Upgrade DISCARD_RANGE to WHOLE_RESOURCE if the whole resource is
> > > +* being mapped. If we add buffer reallocation to avoid CPU/GPU sync 
> > > this
> > > +* check needs to be extended to coherent mappings and shared 
> > > resources.
> > > +*/
> > > +   if ((usage & PIPE_TRANSFER_DISCARD_RANGE) &&
> > > +   !(usage & PIPE_TRANSFER_UNSYNCHRONIZED) &&
> > > +   prsc->last_level == 0 &&
> > > +   prsc->width0 == box->width &&
> > > +   prsc->height0 == box->height &&
> > > +   prsc->depth0 == box->depth &&
> > > +   prsc->array_size == 1) {
> > > +  usage |= PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE;
> > > +   }
> > > +
> > > if (rsc->texture && !etna_resource_newer(rsc, 
> > > etna_resource(rsc->texture))) {
> > >/* We have a texture resource which is the same age or newer than 
> > > the
> > > * render resource. Use the texture resource, which avoids bouncing
> > 
> > 
> 


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


Re: [Mesa-dev] [PATCH v14 08/36] gallium/winsys/drm: introduce modifier field to winsys_handle

2017-06-08 Thread Lucas Stach
Am Dienstag, den 30.05.2017, 17:23 +0530 schrieb Varad Gautam:
> From: Varad Gautam 
> 
> we use this to import resources with format modifiers, and to support
> per-resource modifier queries.
> 
> Signed-off-by: Varad Gautam 
> Cc: Lucas Stach 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/include/state_tracker/drm_driver.h | 6 ++
>  src/gallium/state_trackers/dri/dri2.c  | 7 +++
>  2 files changed, 13 insertions(+)
> 
> diff --git a/src/gallium/include/state_tracker/drm_driver.h 
> b/src/gallium/include/state_tracker/drm_driver.h
> index c80fb09..88dda0a 100644
> --- a/src/gallium/include/state_tracker/drm_driver.h
> +++ b/src/gallium/include/state_tracker/drm_driver.h
> @@ -45,6 +45,12 @@ struct winsys_handle
>  * Output for texture_get_handle.
>  */
> unsigned offset;
> +
> +   /**
> +* Input to resource_from_handle.
> +* Output from resource_get_handle.
> +*/
> +   uint64_t modifier;
>  };
>  
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index ed6004f..f1794b7 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -52,6 +52,10 @@
>  #include "dri_query_renderer.h"
>  #include "dri2_buffer.h"
>  
> +#ifndef DRM_FORMAT_MOD_INVALID
> +#define DRM_FORMAT_MOD_INVALID ((1ULL<<56) - 1)
> +#endif
> +
>  static int convert_fourcc(int format, int *dri_components_p)
>  {
> int dri_components;
> @@ -869,6 +873,7 @@ dri2_create_image_from_name(__DRIscreen *_screen,
> memset(&whandle, 0, sizeof(whandle));
> whandle.type = DRM_API_HANDLE_TYPE_SHARED;
> whandle.handle = name;
> +   whandle.modifier = DRM_FORMAT_MOD_INVALID;
>  
> pf = dri2_format_to_pipe_format (format);
> if (pf == PIPE_FORMAT_NONE)
> @@ -929,6 +934,7 @@ dri2_create_image_from_fd(__DRIscreen *_screen,
>whandles[i].handle = (unsigned)fds[i];
>whandles[i].stride = (unsigned)strides[i];
>whandles[i].offset = (unsigned)offsets[i];
> +  whandles[i].modifier = DRM_FORMAT_MOD_INVALID;
> }
>  
> if (fourcc == __DRI_IMAGE_FOURCC_YVU420) {
> @@ -1143,6 +1149,7 @@ dri2_from_names(__DRIscreen *screen, int width, int 
> height, int format,
> whandle.handle = names[0];
> whandle.stride = strides[0];
> whandle.offset = offsets[0];
> +   whandle.modifier = DRM_FORMAT_MOD_INVALID;
>  
> img = dri2_create_image_from_winsys(screen, width, height, format,
> 1, &whandle, loaderPrivate);


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


Re: [Mesa-dev] [PATCH v14 09/36] st/dri: enable DRIimage modifier queries

2017-06-08 Thread Lucas Stach
Am Dienstag, den 30.05.2017, 17:23 +0530 schrieb Varad Gautam:
> From: Varad Gautam 
> 
> return the modifier selected by the driver when creating this image.
> 
> v2: since we can use winsys_handle->modifier to serve these, remove
> DRIimage->modifier from v1.
> use DRM_API_HANDLE_TYPE_KMS instead of DRM_API_HANDLE_TYPE_FD to avoid
> ownership transfer. (Lucas)
> 
> Suggested-by: Daniel Stone 
> Signed-off-by: Varad Gautam 
> Cc: Lucas Stach 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/state_trackers/dri/dri2.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index f1794b7..fb1c829 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -1088,6 +1088,18 @@ dri2_query_image(__DRIimage *image, int attrib, int 
> *value)
> case __DRI_IMAGE_ATTRIB_NUM_PLANES:
>*value = 1;
>return GL_TRUE;
> +   case __DRI_IMAGE_ATTRIB_MODIFIER_UPPER:
> +  whandle.type = DRM_API_HANDLE_TYPE_KMS;
> +  image->texture->screen->resource_get_handle(image->texture->screen,
> +NULL, image->texture, &whandle, usage);
> +  *value = (whandle.modifier >> 32) & 0x;
> +  return GL_TRUE;
> +   case __DRI_IMAGE_ATTRIB_MODIFIER_LOWER:
> +  whandle.type = DRM_API_HANDLE_TYPE_KMS;
> +  image->texture->screen->resource_get_handle(image->texture->screen,
> +NULL, image->texture, &whandle, usage);
> +  *value = whandle.modifier & 0x;
> +  return GL_TRUE;
> default:
>return GL_FALSE;
> }


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


Re: [Mesa-dev] [PATCH v14 10/36] st/dri: implement createImageWithModifiers in DRIimage

2017-06-08 Thread Lucas Stach
Am Dienstag, den 30.05.2017, 17:23 +0530 schrieb Varad Gautam:
> From: Varad Gautam 
> 
> adds a pscreen->resource_create_with_modifiers() to create textures
> with modifier.
> 
> v2:
> - stylefixes (Emil Velikov)
> - don't return selected modifier from resource_create_with_modifiers. we can
>   use the winsys_handle to get this.
> 
> Signed-off-by: Varad Gautam 
> Reviewed-by: Lucas Stach  (v1)
> Cc: Lucas Stach 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/include/pipe/p_screen.h   | 15 +
>  src/gallium/state_trackers/dri/dri2.c | 58 
> ---
>  2 files changed, 68 insertions(+), 5 deletions(-)
> 
> diff --git a/src/gallium/include/pipe/p_screen.h 
> b/src/gallium/include/pipe/p_screen.h
> index 8b4239c..5102827 100644
> --- a/src/gallium/include/pipe/p_screen.h
> +++ b/src/gallium/include/pipe/p_screen.h
> @@ -328,6 +328,21 @@ struct pipe_screen {
>  * driver doesn't support an on-disk shader cache.
>  */
> struct disk_cache *(*get_disk_shader_cache)(struct pipe_screen *screen);
> +
> +   /**
> +* Create a new texture object from the given template info, taking
> +* format modifiers into account. \p modifiers specifies a list of format
> +* modifier tokens, as defined in drm_fourcc.h. The driver then picks the
> +* best modifier among these and creates the resource. \p count must
> +* contain the size of \p modifiers array.
> +*
> +* Returns NULL if an entry in \p modifiers is unsupported by the driver,
> +* or if only DRM_FORMAT_MOD_INVALID is provided.
> +*/
> +   struct pipe_resource * (*resource_create_with_modifiers)(
> +   struct pipe_screen *,
> +   const struct pipe_resource *templat,
> +   const uint64_t *modifiers, int count);
>  };
>  
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index fb1c829..59e6261 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -971,9 +971,12 @@ dri2_create_image_from_renderbuffer(__DRIcontext 
> *context,
>  }
>  
>  static __DRIimage *
> -dri2_create_image(__DRIscreen *_screen,
> -   int width, int height, int format,
> -   unsigned int use, void *loaderPrivate)
> +dri2_create_image_common(__DRIscreen *_screen,
> + int width, int height,
> + int format, unsigned int use,
> + const uint64_t *modifiers,
> + const unsigned count,
> + void *loaderPrivate)
>  {
> struct dri_screen *screen = dri_screen(_screen);
> __DRIimage *img;
> @@ -981,7 +984,13 @@ dri2_create_image(__DRIscreen *_screen,
> unsigned tex_usage;
> enum pipe_format pf;
>  
> +   /* createImageWithModifiers doesn't supply usage, and we should not get
> +* here with both modifiers and a usage flag.
> +*/
> +   assert(!(use && (modifiers != NULL)));
> +
> tex_usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> +
> if (use & __DRI_IMAGE_USE_SCANOUT)
>tex_usage |= PIPE_BIND_SCANOUT;
> if (use & __DRI_IMAGE_USE_SHARE)
> @@ -1012,7 +1021,16 @@ dri2_create_image(__DRIscreen *_screen,
> templ.depth0 = 1;
> templ.array_size = 1;
>  
> -   img->texture = screen->base.screen->resource_create(screen->base.screen, 
> &templ);
> +   if (modifiers)
> +  img->texture =
> + screen->base.screen
> +->resource_create_with_modifiers(screen->base.screen,
> + &templ,
> + modifiers,
> + count);
> +   else
> +  img->texture =
> + screen->base.screen->resource_create(screen->base.screen, &templ);
> if (!img->texture) {
>FREE(img);
>return NULL;
> @@ -1028,6 +1046,28 @@ dri2_create_image(__DRIscreen *_screen,
> return img;
>  }
>  
> +static __DRIimage *
> +dri2_create_image(__DRIscreen *_screen,
> +   int width, int height, int format,
> +   unsigned int use, void *loaderPrivate)
> +{
> +   return dri2_create_image_common(_screen, width, height, format, use,
> +   NULL /* modifiers */, 0 /* count */,
> +   loaderPrivate);
> +}
> +
> +static __DRIimage *
> +dri2_create_image_with_modifiers(__DRIscreen *dri_screen,
> +  

Re: [Mesa-dev] [PATCH v14 13/36] gallium: introduce format modifier querying

2017-06-08 Thread Lucas Stach
Am Dienstag, den 30.05.2017, 17:23 +0530 schrieb Varad Gautam:
> From: Varad Gautam 
> 
> format modifiers tokens are driver specific, and hence, need to come
> in from the driver. this allows drivers to be queried for supported
> format modifiers for EGL_EXT_image_dma_buf_import_modifiers.
> 
> v2: rebase to master.
> v3: drivers must return false on query failure.
> v4: use pscreen->is_format_supported instead of adding a separate
> format query handle, remove PIPE_CAP_QUERY_DMABUF_ATTRIBS.
> (Lucas Stach)
> v5: add external_only parameter.
> 
> Signed-off-by: Varad Gautam 
> Cc: Lucas Stach 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/include/pipe/p_screen.h | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/src/gallium/include/pipe/p_screen.h 
> b/src/gallium/include/pipe/p_screen.h
> index 5102827..65e954a 100644
> --- a/src/gallium/include/pipe/p_screen.h
> +++ b/src/gallium/include/pipe/p_screen.h
> @@ -343,6 +343,20 @@ struct pipe_screen {
> struct pipe_screen *,
> const struct pipe_resource *templat,
> const uint64_t *modifiers, int count);
> +
> +   /**
> +* Get supported modifiers for a format.
> +* If \p max is 0, the total number of supported modifiers for the 
> supplied
> +* format is returned in \p count, with no modification to \p modifiers.
> +* Otherwise, \p modifiers is filled with upto \p max supported modifier
> +* codes, and \p count with the number of modifiers copied.
> +* The \p external_only array is used to return whether the format and
> +* modifier combination can only be used with an external texture target.
> +*/
> +   void (*query_dmabuf_modifiers)(struct pipe_screen *screen,
> +  enum pipe_format format, int max,
> +  uint64_t *modifiers,
> +  unsigned int *external_only, int *count);
>  };
>  
> 


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


Re: [Mesa-dev] [PATCH v14 14/36] st/dri: support format modifier queries

2017-06-08 Thread Lucas Stach
Am Dienstag, den 30.05.2017, 17:23 +0530 schrieb Varad Gautam:
> From: Varad Gautam 
> 
> ask the driver for supported modifiers for a given format.
> 
> v2: move to __DRIimageExtension v16.
> v3: fail if the supplied format is not supported by driver.
> v4: purge PIPE_CAP_QUERY_DMABUF_ATTRIBS.
> v5:
> - move to __DRIimageExtension v15, pass external_only to the driver.
> 
> Signed-off-by: Varad Gautam 
> Reviewed-by: Lucas Stach  (v4)

Still valid.

> Cc: Lucas Stach 
> ---
>  src/gallium/state_trackers/dri/dri2.c | 24 +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index 864dbcd..b864053 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -1437,6 +1437,25 @@ dri2_query_dma_buf_formats(__DRIscreen *_screen, int 
> max, int *formats,
> return true;
>  }
>  
> +static boolean
> +dri2_query_dma_buf_modifiers(__DRIscreen *_screen, int fourcc, int max,
> + uint64_t *modifiers, unsigned int 
> *external_only,
> + int *count)
> +{
> +   struct dri_screen *screen = dri_screen(_screen);
> +   struct pipe_screen *pscreen = screen->base.screen;
> +   enum pipe_format format = fourcc_to_pipe_format(fourcc);
> +   const unsigned usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> +
> +   if (pscreen->query_dmabuf_modifiers != NULL &&
> +   pscreen->is_format_supported(pscreen, format, screen->target, 0, 
> usage)) {
> +  pscreen->query_dmabuf_modifiers(pscreen, format, max, modifiers,
> +  external_only, count);
> +  return true;
> +   }
> +   return false;
> +}
> +
>  static __DRIimage *
>  dri2_from_dma_bufs(__DRIscreen *screen,
> int width, int height, int fourcc,
> @@ -1603,7 +1622,7 @@ dri2_get_capabilities(__DRIscreen *_screen)
>  
>  /* The extension is modified during runtime if DRI_PRIME is detected */
>  static __DRIimageExtension dri2ImageExtension = {
> -.base = { __DRI_IMAGE, 14 },
> +.base = { __DRI_IMAGE, 15 },
>  
>  .createImageFromName  = dri2_create_image_from_name,
>  .createImageFromRenderbuffer  = dri2_create_image_from_renderbuffer,
> @@ -2172,6 +2191,8 @@ dri2_init_screen(__DRIscreen * sPriv)
>   dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
>   dri2ImageExtension.createImageFromDmaBufs2 = dri2_from_dma_bufs2;
>   dri2ImageExtension.queryDmaBufFormats = dri2_query_dma_buf_formats;
> + dri2ImageExtension.queryDmaBufModifiers =
> +dri2_query_dma_buf_modifiers;
>}
> }
>  
> @@ -2250,6 +2271,7 @@ dri_kms_init_screen(__DRIscreen * sPriv)
>dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
>dri2ImageExtension.createImageFromDmaBufs2 = dri2_from_dma_bufs2;
>dri2ImageExtension.queryDmaBufFormats = dri2_query_dma_buf_formats;
> +  dri2ImageExtension.queryDmaBufModifiers = dri2_query_dma_buf_modifiers;
> }
>  
> sPriv->extensions = dri_screen_extensions;


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


[Mesa-dev] [PATCH 2/2] gbm: implement FD import with modifier

2017-06-08 Thread Lucas Stach
This implements a way to import FDs with modifiers on plain GBM devices,
without the need to go through EGL. This is mostly to the benefit of
gbm_gralloc, which can keep its dependencies low.

Signed-off-by: Lucas Stach 
---
 src/gbm/backends/dri/gbm_dri.c | 54 ++
 1 file changed, 54 insertions(+)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 7fb569078b27..19be440d48e3 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -932,6 +932,60 @@ gbm_dri_bo_import(struct gbm_device *gbm,
   break;
}
 
+   case GBM_BO_IMPORT_FD_MODIFIER:
+   {
+  struct gbm_import_fd_modifier_data *fd_data = buffer;
+  unsigned int error;
+  int fourcc;
+
+  /* Import with modifier requires createImageFromDmaBufs2 */
+  if (dri->image == NULL || dri->image->base.version < 15 ||
+  dri->image->createImageFromDmaBufs2 == NULL) {
+ errno = ENOSYS;
+ return NULL;
+  }
+
+  switch(fd_data->format) {
+  case GBM_FORMAT_RGB565:
+ fourcc = __DRI_IMAGE_FOURCC_RGB565;
+ break;
+  case GBM_FORMAT_ARGB:
+  case GBM_BO_FORMAT_ARGB:
+ fourcc = __DRI_IMAGE_FOURCC_ARGB;
+ break;
+  case GBM_FORMAT_XRGB:
+  case GBM_BO_FORMAT_XRGB:
+ fourcc = __DRI_IMAGE_FOURCC_XRGB;
+ break;
+  case GBM_FORMAT_ABGR:
+ fourcc = __DRI_IMAGE_FOURCC_ABGR;
+ break;
+  case GBM_FORMAT_XBGR:
+ fourcc = __DRI_IMAGE_FOURCC_XBGR;
+ break;
+  default:
+ errno = EINVAL;
+ return NULL;
+  }
+
+  image = dri->image->createImageFromDmaBufs2(dri->screen, fd_data->width,
+  fd_data->height, fourcc,
+  fd_data->modifier,
+  fd_data->fds,
+  fd_data->num_fds,
+  fd_data->strides,
+  fd_data->offsets,
+  0, 0, 0, 0,
+  &error, NULL);
+  if (image == NULL) {
+ errno = ENOSYS;
+ return NULL;
+  }
+
+  gbm_format = fd_data->format;
+  break;
+   }
+
default:
   errno = ENOSYS;
   return NULL;
-- 
2.11.0

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


[Mesa-dev] [PATCH 1/2] gbm: add API to to import FD with modifier

2017-06-08 Thread Lucas Stach
This allows to import an FD with an explicit modifier passed through
userspace protocols.

Signed-off-by: Lucas Stach 
---
 src/gbm/main/gbm.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index b52137ed01d4..6a9bf1fc2a80 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -252,6 +252,7 @@ gbm_bo_create_with_modifiers(struct gbm_device *gbm,
 #define GBM_BO_IMPORT_WL_BUFFER 0x5501
 #define GBM_BO_IMPORT_EGL_IMAGE 0x5502
 #define GBM_BO_IMPORT_FD0x5503
+#define GBM_BO_IMPORT_FD_MODIFIER   0x5504
 
 struct gbm_import_fd_data {
int fd;
@@ -261,6 +262,17 @@ struct gbm_import_fd_data {
uint32_t format;
 };
 
+struct gbm_import_fd_modifier_data {
+   uint32_t width;
+   uint32_t height;
+   uint32_t format;
+   uint32_t num_fds;
+   int fds[4];
+   int strides[4];
+   int offsets[4];
+   uint64_t modifier;
+};
+
 struct gbm_bo *
 gbm_bo_import(struct gbm_device *gbm, uint32_t type,
   void *buffer, uint32_t usage);
-- 
2.11.0

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


Re: [Mesa-dev] [PATCH] etnaviv: add rs-operations sw query

2017-06-09 Thread Lucas Stach
Am Freitag, den 09.06.2017, 12:34 +0200 schrieb Christian Gmeiner:
> It could be useful to get the number of emited resolve operations when
> doing driver optimizations.
> 
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.h  | 1 +
>  src/gallium/drivers/etnaviv/etnaviv_emit.c | 2 ++
>  src/gallium/drivers/etnaviv/etnaviv_query.c| 1 +
>  src/gallium/drivers/etnaviv/etnaviv_query.h| 1 +
>  src/gallium/drivers/etnaviv/etnaviv_query_sw.c | 3 +++
>  5 files changed, 8 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
> b/src/gallium/drivers/etnaviv/etnaviv_context.h
> index 2bb8cf5..2c9b24d 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
> @@ -174,6 +174,7 @@ struct etna_context {
> struct {
>uint64_t prims_emitted;
>uint64_t draw_calls;
> +  uint64_t rs_operations;
> } stats;
>  
> struct pipe_debug_callback debug;
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> index 81aaca9..bfff699 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> @@ -171,6 +171,8 @@ etna_submit_rs_state(struct etna_context *ctx,
> struct etna_cmd_stream *stream = ctx->stream;
> struct etna_coalesce coalesce;
>  
> +   ctx->stats.rs_operations++;
> +
> if (screen->specs.pixel_pipes == 1) {
>etna_cmd_stream_reserve(stream, 22);
>etna_coalesce_start(stream, &coalesce);
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_query.c 
> b/src/gallium/drivers/etnaviv/etnaviv_query.c
> index b33e580..617e475 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_query.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_query.c
> @@ -84,6 +84,7 @@ etna_get_driver_query_info(struct pipe_screen *pscreen, 
> unsigned index,
> struct pipe_driver_query_info list[] = {
>{"prims-emitted", PIPE_QUERY_PRIMITIVES_EMITTED, { 0 }},
>{"draw-calls", ETNA_QUERY_DRAW_CALLS, { 0 }},
> +  {"rs-operations", ETNA_QUERY_RS_OPERATIONS, { 0 }},
> };
>  
> if (!info)
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_query.h 
> b/src/gallium/drivers/etnaviv/etnaviv_query.h
> index 9a8d579..cebd662 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_query.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_query.h
> @@ -54,6 +54,7 @@ etna_query(struct pipe_query *pq)
>  }
>  
>  #define ETNA_QUERY_DRAW_CALLS(PIPE_QUERY_DRIVER_SPECIFIC + 0)
> +#define ETNA_QUERY_RS_OPERATIONS (PIPE_QUERY_DRIVER_SPECIFIC + 1)
>  
>  void
>  etna_query_screen_init(struct pipe_screen *pscreen);
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_query_sw.c 
> b/src/gallium/drivers/etnaviv/etnaviv_query_sw.c
> index d6420d9..213c61f 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_query_sw.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_query_sw.c
> @@ -50,6 +50,8 @@ read_counter(struct etna_context *ctx, int type)
>return ctx->stats.prims_emitted;
> case ETNA_QUERY_DRAW_CALLS:
>return ctx->stats.draw_calls;
> +   case ETNA_QUERY_RS_OPERATIONS:
> +  return ctx->stats.rs_operations;
> }
>  
> return 0;
> @@ -106,6 +108,7 @@ etna_sw_create_query(struct etna_context *ctx, unsigned 
> query_type)
> switch (query_type) {
> case PIPE_QUERY_PRIMITIVES_EMITTED:
> case ETNA_QUERY_DRAW_CALLS:
> +   case ETNA_QUERY_RS_OPERATIONS:
>break;
> default:
>return NULL;


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


Re: [Mesa-dev] glmark2 segfault on imx6

2017-06-13 Thread Lucas Stach
Hi Fabio,

the attached patch should fix the issue. I should really try to get
this upstream, as some people complained about this already...

Regards,
Lucas

Am Dienstag, den 13.06.2017, 16:20 -0300 schrieb Fabio Estevam:
> Hi,
> 
> I am running kernel 4.11.4 with Etnaviv 17.1.2 on a imx6qsabresd
> board
> and when I try to run glmark I am getting a segmentation fault:
> 
> # glmark2-es2-drm
> ** Failed to set swap interval. Results may be bounded above by
> refresh rate.
> ===
> glmark2 2014.03
> ===
> OpenGL Information
> GL_VENDOR: etnaviv
> GL_RENDERER:   Gallium 0.4 on Vivante GC2000 rev 5108
> GL_VERSION:OpenGL ES 2.0 Mesa 17.1.2
> ===
> ** Failed to set swap interval. Results may be bounded above by
> refresh rate.
> [build] use-vbo=false:Segmentation fault
> #
> 
> strace log can be found here:
> https://paste.ubuntu.com/24851027/
> 
> This used to work before. Does anyone have any suggestions?
> 
> Thanks
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-devFrom: Lucas Stach 
Date: Wed, 31 May 2017 13:01:00 +0200
Subject: [PATCH] NativeStateDRM: use fixed event context version

Using the latest version is not a good idea, as the context content may
change between versions.

Fixes a segfault with new kernel and libdrm.

Signed-off-by: Lucas Stach 
---
 src/native-state-drm.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/native-state-drm.cpp b/src/native-state-drm.cpp
index 454a24d898ff..b9af996667dc 100644
--- a/src/native-state-drm.cpp
+++ b/src/native-state-drm.cpp
@@ -106,7 +106,7 @@ NativeStateDRM::flip()
 FD_ZERO(&fds);
 FD_SET(fd_, &fds);
 drmEventContext evCtx;
-evCtx.version = DRM_EVENT_CONTEXT_VERSION;
+evCtx.version = 2;
 evCtx.page_flip_handler = page_flip_handler;
 
 while (waiting) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] etnaviv: keep track of buffer valid ranges

2017-10-19 Thread Lucas Stach
Am Donnerstag, den 19.10.2017, 07:59 +0200 schrieb Christian Gmeiner:
> This allows a write to proceed to an uninitialized part of a buffer
> even when the GPU is using the previously-initialized portions.
> Same is done for freedreno, nouveau and radeon.
> 
> > Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c |  3 +++
>  src/gallium/drivers/etnaviv/etnaviv_resource.h |  4 
>  src/gallium/drivers/etnaviv/etnaviv_transfer.c | 22 +++---
>  3 files changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index d6cccd2dbb..4eb49bf936 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -268,6 +268,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, unsigned 
> layout,
>  
> pipe_reference_init(&rsc->base.reference, 1);
> list_inithead(&rsc->list);
> +   util_range_init(&rsc->valid_buffer_range);
>  
> size = setup_miptree(rsc, paddingX, paddingY, msaa_xscale, msaa_yscale);
>  
> @@ -458,6 +459,7 @@ etna_resource_destroy(struct pipe_screen *pscreen, struct 
> pipe_resource *prsc)
> if (rsc->scanout)
>    renderonly_scanout_destroy(rsc->scanout, etna_screen(pscreen)->ro);
>  
> +   util_range_destroy(&rsc->valid_buffer_range);
> list_delinit(&rsc->list);
>  
> pipe_resource_reference(&rsc->texture, NULL);
> @@ -494,6 +496,7 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
>  
> pipe_reference_init(&prsc->reference, 1);
> list_inithead(&rsc->list);
> +   util_range_init(&rsc->valid_buffer_range);
> prsc->screen = pscreen;
>  
> rsc->bo = etna_screen_bo_from_handle(pscreen, handle, &level->stride);
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 0b135e2373..705c1d1af6 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -31,6 +31,7 @@
>  #include "etnaviv_tiling.h"
>  #include "pipe/p_state.h"
>  #include "util/list.h"
> +#include "util/u_range.h"
>  
>  struct pipe_screen;
>  
> @@ -73,6 +74,9 @@ struct etna_resource {
>  
> struct etna_resource_level levels[ETNA_NUM_LOD];
>  
> +   /* buffer range that has been initialized */
> +   struct util_range valid_buffer_range;
> +
> /* When we are rendering to a texture, we need a differently tiled 
> resource */
> struct pipe_resource *texture;
> /*
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 6c1edd4835..33f3b058fa 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -126,6 +126,10 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> pipe_transfer *ptrans)
> if (!trans->rsc && !(ptrans->usage & PIPE_TRANSFER_UNSYNCHRONIZED))
>    etna_bo_cpu_fini(rsc->bo);
>  
> +   util_range_add(&rsc->valid_buffer_range,
> +  ptrans->box.x,
> +  ptrans->box.x + ptrans->box.width);
> +
> pipe_resource_reference(&trans->rsc, NULL);
> pipe_resource_reference(&ptrans->resource, NULL);
> slab_free(&ctx->transfer_pool, trans);
> @@ -283,7 +287,14 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>  * Pull resources into the CPU domain. Only skipped for unsynchronized
>  * transfers without a temporary resource.
>  */
> -   if (trans->rsc || !(usage & PIPE_TRANSFER_UNSYNCHRONIZED)) {
> +   if ((usage & PIPE_TRANSFER_WRITE) &&
> + prsc->target == PIPE_BUFFER &&
> + !util_ranges_intersect(&rsc->valid_buffer_range,
> +box->x, box->x + box->width)) {
> + /* We are trying to write to a previously uninitialized range. No 
> need
> +  * to wait.
> +  */

This unbalances the cpu_prep/fini in the map/unmap path. This isn't
allowed and the kernel will start to reject this in the near future.

Also you need to differentiate between transfers with and without a
temporary resource (trans->rsc), as the valid range of the temporary
might be different from the base resource, especially if we need to
read back from the base.

Regards,
Lucas

> +} else if (trans->rsc || !(usage & PIPE_TRANSFER_UNSYNCHRONIZED)) {
>    uint32_t prep_flags = 0;
>  
>    if (usage & PIPE_TRANSFER_READ)
> @@ -360,10 +371,15 @@ fail_prep:
>  
>  static void
>  etna_transfer_flush_region(struct pipe_context *pctx,
> -   struct pipe_transfer *transfer,
> +   struct pipe_transfer *ptrans,
> const struct pipe_box *box)
>  {
> -   /* NOOP for now */
> +   struct etna_resource *rsc = etna_resource(ptrans->resource);
> +
> +   if (ptrans->resource->target == PIPE_BUFFER)
> +  util_range_add(&rsc

Re: [Mesa-dev] [PATCH] etnaviv: make use of TEXTURE_TYPE_1D

2017-10-26 Thread Lucas Stach
Am Donnerstag, den 26.10.2017, 03:17 +0200 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

Has this been tested on older GPU cores like the GC600?

> ---
>  src/gallium/drivers/etnaviv/etnaviv_texture.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_texture.c
> b/src/gallium/drivers/etnaviv/etnaviv_texture.c
> index b8ebab6082..f71169d227 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_texture.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_texture.c
> @@ -212,11 +212,8 @@ etna_create_sampler_view(struct pipe_context
> *pctx, struct pipe_resource *prsc,
>  
> switch (sv->base.target) {
> case PIPE_TEXTURE_1D:
> -  /* For 1D textures, we will have a height of 1, so we can use
> 2D
> -   * but set T wrap to repeat */
> -  sv->TE_SAMPLER_CONFIG0_MASK =
> ~VIVS_TE_SAMPLER_CONFIG0_VWRAP__MASK;
> -  sv->TE_SAMPLER_CONFIG0 |=
> VIVS_TE_SAMPLER_CONFIG0_VWRAP(TEXTURE_WRAPMODE_REPEAT);
> -  /* fallthrough */
> +  sv->TE_SAMPLER_CONFIG0 |=
> VIVS_TE_SAMPLER_CONFIG0_TYPE(TEXTURE_TYPE_1D);
> +  break;
> case PIPE_TEXTURE_2D:
> case PIPE_TEXTURE_RECT:
>sv->TE_SAMPLER_CONFIG0 |=
> VIVS_TE_SAMPLER_CONFIG0_TYPE(TEXTURE_TYPE_2D);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] etnaviv: Don't flush on transfer when UNSYNCHRONIZED

2017-10-30 Thread Lucas Stach
Am Samstag, den 28.10.2017, 16:01 +0200 schrieb Wladimir J. van der Laan:
> Structure code to only flush when we will potentially call cpu_prep. This
> prevents spurious flushes in applications that heavily rely on u_uploader.
> 
> > Signed-off-by: Wladimir J. van der Laan 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_transfer.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> I'm not 100% sure about this, but if this isn't correct please explain to me 
> what
> use is a flush if we don't synchronize.

This change is fine as-is. Flushes are only necessary for GPU/CPU sync and to 
actually
fill temporary resources with data, the latter case is handled by the 
trans->rsc part
of the condition.

Reviewed-by: Lucas Stach 

> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 08ec198..c389920 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -243,18 +243,6 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>  
> struct etna_resource_level *res_level = &rsc->levels[level];
>  
> -   /*
> -* Always flush if we have the temporary resource and have a copy to this
> -* outstanding. Otherwise infer flush requirement from resource access and
> -* current GPU usage (reads must wait for GPU writes, writes must have
> -* exclusive access to the buffer).
> -*/
> -   if ((trans->rsc && (etna_resource(trans->rsc)->status & 
> ETNA_PENDING_WRITE)) ||
> -   (!trans->rsc &&
> -(((usage & PIPE_TRANSFER_READ) && (rsc->status & 
> ETNA_PENDING_WRITE)) ||
> -((usage & PIPE_TRANSFER_WRITE) && rsc->status
> -  pctx->flush(pctx, NULL, 0);
> -
> /* XXX we don't handle PIPE_TRANSFER_FLUSH_EXPLICIT; this flag can be 
> ignored
>  * when mapping in-place,
>  * but when not in place we need to fire off the copy operation in
> @@ -312,6 +300,18 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
> if (trans->rsc || !(usage & PIPE_TRANSFER_UNSYNCHRONIZED)) {
>    uint32_t prep_flags = 0;
>  
> +  /*
> +   * Always flush if we have the temporary resource and have a copy to 
> this
> +   * outstanding. Otherwise infer flush requirement from resource access 
> and
> +   * current GPU usage (reads must wait for GPU writes, writes must have
> +   * exclusive access to the buffer).
> +   */
> +  if ((trans->rsc && (etna_resource(trans->rsc)->status & 
> ETNA_PENDING_WRITE)) ||
> +  (!trans->rsc &&
> +   (((usage & PIPE_TRANSFER_READ) && (rsc->status & 
> ETNA_PENDING_WRITE)) ||
> +   ((usage & PIPE_TRANSFER_WRITE) && rsc->status
> + pctx->flush(pctx, NULL, 0);
> +
>    if (usage & PIPE_TRANSFER_READ)
>   prep_flags |= DRM_ETNA_PREP_READ;
>    if (usage & PIPE_TRANSFER_WRITE)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] etnaviv: Allow clearing constant buffer using buffer==NULL user_buffer==NULL

2017-10-30 Thread Lucas Stach
Am Samstag, den 28.10.2017, 16:16 +0200 schrieb Wladimir J. van der Laan:
> Prevents an assertion when using GALLIUM_HUD with ioquake3,
> when cso_restore_constant_buffer_slot0 restores an empty
> constant buffer in slot 0.
> 
> > Signed-off-by: Wladimir J. van der Laan 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_state.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Oops - needed to pull the rest of the expression into unlikely(...) too
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_state.c 
> b/src/gallium/drivers/etnaviv/etnaviv_state.c
> index 34bcb19..91f12f3 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_state.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_state.c
> @@ -89,7 +89,7 @@ etna_set_constant_buffer(struct pipe_context *pctx,
>  
> /* Note that the state tracker can unbind constant buffers by
>  * passing NULL here. */
> -   if (unlikely(!cb))
> +   if (unlikely(!cb || (cb->buffer == NULL && cb->user_buffer == NULL)))

I would prefer the shorter expression (!cb->buffer && !cb->user_buffer) 
here, which seems more consistent with the rest of the codebase.

Regards,
Lucas

>    return;
>  
> /* there is no support for ARB_uniform_buffer_object */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] etnaviv: bugfix: Don't do resolve-in-place without valid TS

2017-11-01 Thread Lucas Stach
Am Mittwoch, den 01.11.2017, 11:17 +0100 schrieb Wladimir J. van der Laan:
> GC3000 resolve-in-place assumes that the TS state is configured.
> If it is not, this will result in MMU errors. This is especially
> apparent when using glGenMipmaps().
> 
> Fixes a problem introduced in 78ade659569ee6fe9bd244170956139f19dd8c6c.
> 
> > Signed-off-by: Wladimir J. van der Laan 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 4 
>  src/gallium/drivers/etnaviv/etnaviv_emit.c   | 4 
>  src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 +
>  src/gallium/drivers/etnaviv/etnaviv_rs.h | 2 ++
>  4 files changed, 11 insertions(+)
> 
> Ooops. This seems like an obvious oversight but I hadn't thought we would get
> into this path at all when there is no TS to "flush".

And that's probably what we should fix. The self-resolve cases on
resource flush and sampler update don't check the TS status, but they
are only useful if there is a valid TS.

With the change you did here we are still wasting bandwidth for a no-op 
blit on older cores like GC880 when generating mipmaps.

Regards,
Lucas
 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> index c62287b..8fc7cfc 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> @@ -555,6 +555,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
> }
>  
> /* Set up color TS to source surface before blit, if needed */
> +   bool source_ts_valid = false;
> if (src->levels[blit_info->src.level].ts_size &&
> src->levels[blit_info->src.level].ts_valid) {
>    struct etna_reloc reloc;
> @@ -579,6 +580,8 @@ etna_try_rs_blit(struct pipe_context *pctx,
>  
>    etna_set_state(ctx->stream, VIVS_TS_COLOR_CLEAR_VALUE,
>   src->levels[blit_info->src.level].clear_value);
> +
> +  source_ts_valid = true;
> } else {
>    etna_set_state(ctx->stream, VIVS_TS_MEM_CONFIG, ts_mem_config);
> }
> @@ -593,6 +596,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
>    .source_stride = src_lev->stride,
>    .source_padded_width = src_lev->padded_width,
>    .source_padded_height = src_lev->padded_height,
> +  .source_ts_valid = source_ts_valid,
>    .dest_format = translate_rs_format(dst_format),
>    .dest_tiling = dst->layout,
>    .dest = dst->bo,
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> index 707b1e7..5397aa3 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> @@ -171,6 +171,10 @@ etna_submit_rs_state(struct etna_context *ctx,
> struct etna_cmd_stream *stream = ctx->stream;
> struct etna_coalesce coalesce;
>  
> +   if (cs->RS_KICKER_INPLACE && !cs->source_ts_valid)
> +  /* Inplace resolve is no-op if TS is not configured */
> +  return;
> +
> ctx->stats.rs_operations++;
>  
> if (cs->RS_KICKER_INPLACE) {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index c9072c2..60c2c39 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -133,6 +133,7 @@ etna_compile_rs_state(struct etna_context *ctx, struct 
> compiled_rs_state *cs,
>    /* Total number of tiles (same as for autodisable) */
>    cs->RS_KICKER_INPLACE = rs->source_padded_width * 
> rs->source_padded_height / 16;
> }
> +   cs->source_ts_valid = rs->source_ts_valid;
>  }
>  
>  void
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.h 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.h
> index 171d3fa..41a5960 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.h
> @@ -33,6 +33,7 @@
>  struct rs_state {
> uint8_t downsample_x : 1; /* Downsample in x direction */
> uint8_t downsample_y : 1; /* Downsample in y direction */
> +   uint8_t source_ts_valid : 1;
>  
> uint8_t source_format; /* RS_FORMAT_XXX */
> uint8_t source_tiling; /* ETNA_LAYOUT_XXX */
> @@ -61,6 +62,7 @@ struct rs_state {
>  
>  /* treat this as opaque structure */
>  struct compiled_rs_state {
> +   uint8_t source_ts_valid : 1;
> uint32_t RS_CONFIG;
> uint32_t RS_SOURCE_STRIDE;
> uint32_t RS_DEST_STRIDE;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] etnaviv: bugfix: Don't do resolve-in-place without valid TS

2017-11-01 Thread Lucas Stach
Am Mittwoch, den 01.11.2017, 12:34 +0100 schrieb Wladimir J. van der Laan:
> On Wed, Nov 01, 2017 at 11:52:55AM +0100, Lucas Stach wrote:
> > Am Mittwoch, den 01.11.2017, 11:17 +0100 schrieb Wladimir J. van der Laan:
> > > GC3000 resolve-in-place assumes that the TS state is configured.
> > > If it is not, this will result in MMU errors. This is especially
> > > apparent when using glGenMipmaps().
> > > 
> > > Fixes a problem introduced in 78ade659569ee6fe9bd244170956139f19dd8c6c.
> > > 
> > > > Signed-off-by: Wladimir J. van der Laan 
> > > 
> > > ---
> > >  src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 4 
> > >  src/gallium/drivers/etnaviv/etnaviv_emit.c   | 4 
> > >  src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 +
> > >  src/gallium/drivers/etnaviv/etnaviv_rs.h | 2 ++
> > >  4 files changed, 11 insertions(+)
> > > 
> > > Ooops. This seems like an obvious oversight but I hadn't thought we would 
> > > get
> > > into this path at all when there is no TS to "flush".
> > 
> > And that's probably what we should fix. The self-resolve cases on
> > resource flush and sampler update don't check the TS status, but they
> > are only useful if there is a valid TS.
> > 
> > With the change you did here we are still wasting bandwidth for a no-op 
> > blit on older cores like GC880 when generating mipmaps.
> 
> Yes, just a bugfix (my original commit did not introduce the higher-level
> behavior). This particular case should not result in a MMU error. If we fix 
> the
> higher level, then this could be replaced with an assertion instead.
> 
> On the longer run I'd personally prefer to make "Flush resource level TS" a
> separate, explicit operation, for example a method on the context, and not 
> make
> it go through the blit path with source==destination. It's a hardware 
> operation
> implemented differently on GC3000 and GC7000, that just happens to use the RS
> blit on https://lists.freedesktop.org/mailman/listinfo/mesa-dev


  1   2   3   4   >