[Mesa-dev] [PATCH] panfrost: Rewrite varying assembly
There are two stages to varying assembly in the command stream: creating
the varying buffers in the command stream, and creating the varying meta
descriptors (also in the command stream) linked to the aforementioned
buffers. The previous code for this was ad hoc and brittle, making some
invalid assumptions causing unmaintainable workarounds to pile up across
the driver (both compiler and command stream side).
This patch completely rewrites the varying assembly code. There's a
trivial performance penalty (we now memcpy the varying meta to the
command stream on draw, rather than on compile). That said, the
improvement in flexibility and clarity is well-worth it.
The motivator for these changes was support for gl_PointCoord (and
eventually point sprites for legacy GL), which was impossible to
implement with the old varying assembly code. With the new refactor,
it's super easy; support for gl_PointCoord is included with this patch.
All in all, I'm quite happy with how this turned out.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/include/panfrost-job.h | 7 +
.../panfrost/midgard/midgard_compile.c| 52 +--
.../panfrost/midgard/midgard_compile.h| 2 +
src/gallium/drivers/panfrost/pan_assemble.c | 144 +-
src/gallium/drivers/panfrost/pan_context.c| 127 ++-
src/gallium/drivers/panfrost/pan_context.h| 26 +---
6 files changed, 141 insertions(+), 217 deletions(-)
diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h
b/src/gallium/drivers/panfrost/include/panfrost-job.h
index 85ef02d04e0..f0a4de73085 100644
--- a/src/gallium/drivers/panfrost/include/panfrost-job.h
+++ b/src/gallium/drivers/panfrost/include/panfrost-job.h
@@ -754,6 +754,13 @@ enum mali_attr_mode {
MALI_ATTR_NPOT_DIVIDE = 4,
};
+/* This magic "pseudo-address" is used as `elements` to implement
+ * gl_PointCoord. When read from a fragment shader, it generates a point
+ * coordinate per the OpenGL ES 2.0 specification. Flipped coordinate spaces
+ * require an affine transformation in the shader. */
+
+#define MALI_VARYING_POINT_COORD (0x60)
+
union mali_attr {
/* This is used for actual attributes. */
struct {
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 7f3b6997ca0..87c504061aa 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -431,9 +431,6 @@ typedef struct compiler_context {
struct hash_table_u64 *uniform_nir_to_mdg;
int uniform_count;
-struct hash_table_u64 *varying_nir_to_mdg;
-int varying_count;
-
/* Just the count of the max register used. Higher count => higher
* register pressure */
int work_registers;
@@ -1398,17 +1395,6 @@ emit_intrinsic(compiler_context *ctx,
nir_intrinsic_instr *instr)
* guarantee correctness when considering some
* (common) edge cases XXX: FIXME */
-/* Look up how it was actually laid out */
-
-void *entry =
_mesa_hash_table_u64_search(ctx->varying_nir_to_mdg, offset + 1);
-
-if (!entry) {
-DBG("WARNING: skipping varying\n");
-break;
-}
-
-offset = (uintptr_t) (entry) - 1;
-
/* If this varying corresponds to a constant (why?!),
* emit that now since it won't get picked up by
* hoisting (since there is no corresponding move
@@ -3455,42 +3441,16 @@ midgard_compile_shader_nir(nir_shader *nir,
midgard_program *program, bool is_bl
}
}
-if (ctx->stage == MESA_SHADER_VERTEX) {
-ctx->varying_nir_to_mdg = _mesa_hash_table_u64_create(NULL);
-
-/* First, collect the special varyings */
-nir_foreach_variable(var, >outputs) {
-if (var->data.location == VARYING_SLOT_POS) {
-/* Set position first, always. It takes up two
- * spots, the latter one is de facto unused (at
- * least from the shader's perspective), we
- * just need to skip over the spot*/
-
-
_mesa_hash_table_u64_insert(ctx->varying_nir_to_mdg, var->data.driver_location
+ 1, (void *) ((uintptr_t) (0 + 1)));
-ctx->varying_count = MAX2(ctx->varying_count,
2);
-} else if (var->data.location == VARYING_SLOT_PSIZ) {
-/* Set point size second (third, see above) */
-
_mesa_hash_table_u64_insert(ctx->varying_nir_to_mdg,
Re: [Mesa-dev] [PATCH] android: nouveau: add support for nir
On Sun, Mar 17, 2019 at 11:56 PM Mauro Rossi wrote:
>
> Hi Karol,
>
> On Sun, Mar 17, 2019 at 11:25 PM Karol Herbst wrote:
> >
> > On Sun, Mar 17, 2019 at 10:52 PM Mauro Rossi wrote:
> > >
> > > Add the necessary build rules for android, to avoid building errors.
> > >
> > > Fixes: f014ae3 ("nouveau: add support for nir")
> > > Signed-off-by: Mauro Rossi
> > > ---
> > > src/gallium/drivers/nouveau/Android.mk | 7 ++-
> > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/gallium/drivers/nouveau/Android.mk
> > > b/src/gallium/drivers/nouveau/Android.mk
> > > index cd2dd0938f..49a341c831 100644
> > > --- a/src/gallium/drivers/nouveau/Android.mk
> > > +++ b/src/gallium/drivers/nouveau/Android.mk
> > > @@ -37,8 +37,13 @@ LOCAL_SRC_FILES := \
> > > $(NVC0_C_SOURCES)
> > >
> > > LOCAL_C_INCLUDES := \
> > > - $(MESA_TOP)/include
> > > + $(MESA_TOP)/include \
> > > + $(call
> > > generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
> > > + $(MESA_TOP)/src/compiler/nir \
> > > + $(MESA_TOP)/src/mapi \
> > > + $(MESA_TOP)/src/mesa
> >
> > do we really have to add all those includes? freedreno doesn't seem to
> > add those either and just has the libmesa_nir dependency
>
> Hi Karol,
>
> the first build error "main/config.h" not found
> was caused by $(MESA_TOP)/src/mesa missing,
> then I did not chased the others,
> I replicated with fidelity your Autotools build rules
> as I've always been instructed this way by Emil Velikov
>
> The patch is working and Android booting on GTX950 with the patch
> KR
>
> Mauro
yeah, I was mainly wondering if only some of those includes would be
sufficient.. anyway, I've pushed the patch.
>
> >
> > >
> > > +LOCAL_STATIC_LIBRARIES := libmesa_nir
> > > LOCAL_SHARED_LIBRARIES := libdrm_nouveau
> > > LOCAL_MODULE := libmesa_pipe_nouveau
> > >
> > > --
> > > 2.19.1
> > >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] android: nouveau: add support for nir
Hi Karol,
On Sun, Mar 17, 2019 at 11:25 PM Karol Herbst wrote:
>
> On Sun, Mar 17, 2019 at 10:52 PM Mauro Rossi wrote:
> >
> > Add the necessary build rules for android, to avoid building errors.
> >
> > Fixes: f014ae3 ("nouveau: add support for nir")
> > Signed-off-by: Mauro Rossi
> > ---
> > src/gallium/drivers/nouveau/Android.mk | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/nouveau/Android.mk
> > b/src/gallium/drivers/nouveau/Android.mk
> > index cd2dd0938f..49a341c831 100644
> > --- a/src/gallium/drivers/nouveau/Android.mk
> > +++ b/src/gallium/drivers/nouveau/Android.mk
> > @@ -37,8 +37,13 @@ LOCAL_SRC_FILES := \
> > $(NVC0_C_SOURCES)
> >
> > LOCAL_C_INCLUDES := \
> > - $(MESA_TOP)/include
> > + $(MESA_TOP)/include \
> > + $(call
> > generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
> > + $(MESA_TOP)/src/compiler/nir \
> > + $(MESA_TOP)/src/mapi \
> > + $(MESA_TOP)/src/mesa
>
> do we really have to add all those includes? freedreno doesn't seem to
> add those either and just has the libmesa_nir dependency
Hi Karol,
the first build error "main/config.h" not found
was caused by $(MESA_TOP)/src/mesa missing,
then I did not chased the others,
I replicated with fidelity your Autotools build rules
as I've always been instructed this way by Emil Velikov
The patch is working and Android booting on GTX950 with the patch
KR
Mauro
>
> >
> > +LOCAL_STATIC_LIBRARIES := libmesa_nir
> > LOCAL_SHARED_LIBRARIES := libdrm_nouveau
> > LOCAL_MODULE := libmesa_pipe_nouveau
> >
> > --
> > 2.19.1
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] android: nouveau: add support for nir
On Sun, Mar 17, 2019 at 10:52 PM Mauro Rossi wrote:
>
> Add the necessary build rules for android, to avoid building errors.
>
> Fixes: f014ae3 ("nouveau: add support for nir")
> Signed-off-by: Mauro Rossi
> ---
> src/gallium/drivers/nouveau/Android.mk | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/nouveau/Android.mk
> b/src/gallium/drivers/nouveau/Android.mk
> index cd2dd0938f..49a341c831 100644
> --- a/src/gallium/drivers/nouveau/Android.mk
> +++ b/src/gallium/drivers/nouveau/Android.mk
> @@ -37,8 +37,13 @@ LOCAL_SRC_FILES := \
> $(NVC0_C_SOURCES)
>
> LOCAL_C_INCLUDES := \
> - $(MESA_TOP)/include
> + $(MESA_TOP)/include \
> + $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
> + $(MESA_TOP)/src/compiler/nir \
> + $(MESA_TOP)/src/mapi \
> + $(MESA_TOP)/src/mesa
do we really have to add all those includes? freedreno doesn't seem to
add those either and just has the libmesa_nir dependency
>
> +LOCAL_STATIC_LIBRARIES := libmesa_nir
> LOCAL_SHARED_LIBRARIES := libdrm_nouveau
> LOCAL_MODULE := libmesa_pipe_nouveau
>
> --
> 2.19.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] android: nouveau: add support for nir
Add the necessary build rules for android, to avoid building errors.
Fixes: f014ae3 ("nouveau: add support for nir")
Signed-off-by: Mauro Rossi
---
src/gallium/drivers/nouveau/Android.mk | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/Android.mk
b/src/gallium/drivers/nouveau/Android.mk
index cd2dd0938f..49a341c831 100644
--- a/src/gallium/drivers/nouveau/Android.mk
+++ b/src/gallium/drivers/nouveau/Android.mk
@@ -37,8 +37,13 @@ LOCAL_SRC_FILES := \
$(NVC0_C_SOURCES)
LOCAL_C_INCLUDES := \
- $(MESA_TOP)/include
+ $(MESA_TOP)/include \
+ $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
+ $(MESA_TOP)/src/compiler/nir \
+ $(MESA_TOP)/src/mapi \
+ $(MESA_TOP)/src/mesa
+LOCAL_STATIC_LIBRARIES := libmesa_nir
LOCAL_SHARED_LIBRARIES := libdrm_nouveau
LOCAL_MODULE := libmesa_pipe_nouveau
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vulkan/util: meson build - add wayland client include
Thanks! On 17.03.19 19:33, Eric Engestrom wrote: On Saturday, 2019-03-16 20:32:46 +, Lionel Landwerlin wrote: There is merge request opened about this issue : https://gitlab.freedesktop.org/mesa/mesa/merge_requests/429 I think the deps need to be moved from src/vulkan/wsi/meson.build into src/vulkan/meson.build as they apply to the overlay, utils & wsi. Since it's correct though, I landed Tobias' patch with my r-b and Cc: stable (I dropped the unnecessary [] though), and I sent MR !460 with your suggestion. Thanks, -Lionel On 16/03/2019 18:56, Tobias Klausmann wrote: Without this the build breaks with: In file included from ../src/vulkan/util/vk_util.h:32, from ../src/vulkan/util/vk_util.c:28: ../include/vulkan/vulkan.h:51:10: fatal error: wayland-client.h: No such file or directory #include ^~ compilation terminated. The above misses the include directory for wayland: -I/usr/include/wayland Signed-off-by: Tobias Klausmann --- src/vulkan/util/meson.build | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/vulkan/util/meson.build b/src/vulkan/util/meson.build index 6aba265cc81..b845f57a660 100644 --- a/src/vulkan/util/meson.build +++ b/src/vulkan/util/meson.build @@ -36,10 +36,17 @@ vk_enum_to_str = custom_target( ], ) +vulkan_util_deps = [] + +if with_platform_wayland + vulkan_util_deps += dep_wayland_client +endif + libvulkan_util = static_library( 'vulkan_util', [files_vulkan_util, vk_enum_to_str], - include_directories : inc_common, + include_directories : [inc_common], + dependencies : [vulkan_util_deps], c_args : [c_vis_args, vulkan_wsi_args], build_by_default : false, ) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vulkan/util: meson build - add wayland client include
On Saturday, 2019-03-16 20:32:46 +, Lionel Landwerlin wrote: > There is merge request opened about this issue : > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/429 > > I think the deps need to be moved from src/vulkan/wsi/meson.build into > src/vulkan/meson.build as they apply to the overlay, utils & wsi. Since it's correct though, I landed Tobias' patch with my r-b and Cc: stable (I dropped the unnecessary [] though), and I sent MR !460 with your suggestion. > > Thanks, > > -Lionel > > On 16/03/2019 18:56, Tobias Klausmann wrote: > > Without this the build breaks with: > > > > In file included from ../src/vulkan/util/vk_util.h:32, > > from ../src/vulkan/util/vk_util.c:28: > > ../include/vulkan/vulkan.h:51:10: fatal error: wayland-client.h: No such > > file or > > directory > > #include > >^~ > > compilation terminated. > > > > The above misses the include directory for wayland: > > -I/usr/include/wayland > > > > Signed-off-by: Tobias Klausmann > > --- > > src/vulkan/util/meson.build | 9 - > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/src/vulkan/util/meson.build b/src/vulkan/util/meson.build > > index 6aba265cc81..b845f57a660 100644 > > --- a/src/vulkan/util/meson.build > > +++ b/src/vulkan/util/meson.build > > @@ -36,10 +36,17 @@ vk_enum_to_str = custom_target( > > ], > > ) > > +vulkan_util_deps = [] > > + > > +if with_platform_wayland > > + vulkan_util_deps += dep_wayland_client > > +endif > > + > > libvulkan_util = static_library( > > 'vulkan_util', > > [files_vulkan_util, vk_enum_to_str], > > - include_directories : inc_common, > > + include_directories : [inc_common], > > + dependencies : [vulkan_util_deps], > > c_args : [c_vis_args, vulkan_wsi_args], > > build_by_default : false, > > ) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v5] etnaviv: fix resource usage tracking across different pipe_context's
On 3/17/19 10:48 AM, Christian Gmeiner wrote: > Am Sa., 16. März 2019 um 20:55 Uhr schrieb Marek Vasut : >> >> On 2/22/19 10:30 AM, Boris Brezillon wrote: >>> On Thu, 21 Feb 2019 23:29:53 +0100 >>> Boris Brezillon wrote: >>> Christian, Marek, On Wed, 30 Jan 2019 05:28:14 +0100 Marek Vasut wrote: > From: Christian Gmeiner > > A pipe_resource can be shared by all the pipe_context's hanging off the > same pipe_screen. We seem to be impacted by the problem you're fixing here, but, while this patch definitely make things much better, the problem does not seem to be entirely fixed (at least in our case). A bit more context: we have Qt App using QtWebEngine to render html content. When we call QtWebEngine::initialize(), which as for effect to allow shared GL contexts, we sometimes notice that part of the web page is mis-rendered. That does not happen when we omit the QtWebEngine::initialize() call. As said above, this patch make those rendering issues less likely to happen, but we still have the problem from time to time. So I thought I'd share my guesses about what could cause these issues before debugging it further. First thing I noticed: I couldn't reproduce the problem with [1] applied (+ a tiny change forcing CPU-based tiling no matter the size of the region to tile/untile). So, my guess is that it's related to how we handle GPU-based tiling/untiling. Also noticed that we're testing the rsc->status here [2] without the screen->lock held, and there might be a race with another thread calling resource_used(). We might also lack a resource_read(ctx, >base) here [3]. But even after fixing those problems, the rendering issues are not gone. >>> >>> I tested again with the following diff applied on top of your patch, and >>> the remaining rendering issues we had seem to be gone (don't know what I >>> messed up in my previous tests :-/). >>> >>> --->8--- >>> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c >>> b/src/gallium/drivers/etnaviv/etnaviv_rs.c >>> index fc4f65dbeee1..b8c8b96a6f72 100644 >>> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c >>> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c >>> @@ -729,6 +729,7 @@ etna_try_rs_blit(struct pipe_context *pctx, >>> >>> etna_submit_rs_state(ctx, _to_screen); >>> resource_written(ctx, >base); >>> + resource_read(ctx, >base); >>> dst->seqno++; >>> dst->levels[blit_info->dst.level].ts_valid = false; >>> ctx->dirty |= ETNA_DIRTY_DERIVE_TS; >> While the V6 of this patch [1] is now in mesa upstream, this hunk is >> missing from the V6 . Any special reason for that or is this just an >> omission ? >> > > This and an other change was done in separates commits - see: > > https://cgit.freedesktop.org/mesa/mesa/commit/?id=7244e768040859126a5b74023f587beaa8bef81c > https://cgit.freedesktop.org/mesa/mesa/commit/?id=c56e73449698c31fe72b99a95b7e4ecdb2985b73 > > So everything went in. Ah, thanks :) Do you plan to backport those to mesa 18.3.5 too ? -- Best regards, Marek Vasut ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: implement "zombie" sampler views (v2)
On 15/03/2019 21:12, Brian Paul wrote:
When st_texture_release_all_sampler_views() is called the texture may
have sampler views belonging to several contexts. If we unreference a
sampler view and its refcount hits zero, we need to be sure to destroy
the sampler view with the same context which created it.
This was not the case with the previous code which used
pipe_sampler_view_release(). That function could end up freeing a
sampler view with a context different than the one which created it.
In the case of the VMware svga driver, we detected this but leaked the
sampler view. This led to a crash with google-chrome when the kernel
module had too many sampler views. VMware bug 2274734.
Alternately, if we try to delete a sampler view with the correct
context, we may be "reaching into" a context which is active on
another thread. That's not safe.
To fix these issues this patch adds a per-context list of "zombie"
sampler views. These are views which are to be freed at some point
when the context is active. Other contexts may safely add sampler
views to the zombie list at any time (it's mutex protected). This
avoids the context/view ownership mix-ups we had before.
Tested with: google-chrome, google earth, Redway3D Watch/Turbine demos
a few Linux games. If anyone can recomment some other multi-threaded,
multi-context GL apps to test, please let me know.
v2: avoid potential race issue by always adding sampler views to the
zombie list if the view's context doesn't match the current context,
ignoring the refcount.
Reviewed-by: Roland Scheidegger
Reviewed-by: Neha Bhende
Reviewed-by: Mathias Fröhlich
Reviewed-By: Jose Fonseca
---
src/mesa/state_tracker/st_cb_flush.c | 6 +++
src/mesa/state_tracker/st_context.c | 80
src/mesa/state_tracker/st_context.h | 25 ++
src/mesa/state_tracker/st_sampler_view.c | 21 +++--
src/mesa/state_tracker/st_texture.h | 3 ++
5 files changed, 131 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_flush.c
b/src/mesa/state_tracker/st_cb_flush.c
index 5b3188c..81e5338 100644
--- a/src/mesa/state_tracker/st_cb_flush.c
+++ b/src/mesa/state_tracker/st_cb_flush.c
@@ -39,6 +39,7 @@
#include "st_cb_flush.h"
#include "st_cb_clear.h"
#include "st_cb_fbo.h"
+#include "st_context.h"
#include "st_manager.h"
#include "pipe/p_context.h"
#include "pipe/p_defines.h"
@@ -53,6 +54,11 @@ st_flush(struct st_context *st,
{
st_flush_bitmap_cache(st);
+ /* We want to call this function periodically.
+* Typically, it has nothing to do so it shouldn't be expensive.
+*/
+ st_context_free_zombie_objects(st);
+
st->pipe->flush(st->pipe, fence, flags);
}
diff --git a/src/mesa/state_tracker/st_context.c b/src/mesa/state_tracker/st_context.c
index 2898279..c38f8e5 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -261,6 +261,79 @@ st_invalidate_state(struct gl_context *ctx)
}
+/*
+ * In some circumstances (such as running google-chrome) the state
+ * tracker may try to delete a resource view from a context different
+ * than when it was created. We don't want to do that.
+ *
+ * In that situation, st_texture_release_all_sampler_views() calls this
+ * function to transfer the sampler view reference to this context (expected
+ * to be the context which created the view.)
+ */
+void
+st_save_zombie_sampler_view(struct st_context *st,
+struct pipe_sampler_view *view)
+{
+ struct st_zombie_sampler_view_node *entry;
+
+ assert(view->context == st->pipe);
+
+ entry = MALLOC_STRUCT(st_zombie_sampler_view_node);
+ if (!entry)
+ return;
+
+ entry->view = view;
+
+ /* We need a mutex since this function may be called from one thread
+* while free_zombie_resource_views() is called from another.
+*/
+ mtx_lock(>zombie_sampler_views.mutex);
+ LIST_ADDTAIL(>node, >zombie_sampler_views.list.node);
+ mtx_unlock(>zombie_sampler_views.mutex);
+}
+
+
+/*
+ * Free any zombie sampler views that may be attached to this context.
+ */
+static void
+free_zombie_sampler_views(struct st_context *st)
+{
+ struct st_zombie_sampler_view_node *entry, *next;
+
+ if (LIST_IS_EMPTY(>zombie_sampler_views.list.node)) {
+ return;
+ }
+
+ mtx_lock(>zombie_sampler_views.mutex);
+
+ LIST_FOR_EACH_ENTRY_SAFE(entry, next,
+>zombie_sampler_views.list.node, node) {
+ LIST_DEL(>node); // remove this entry from the list
+
+ assert(entry->view->context == st->pipe);
+ pipe_sampler_view_reference(>view, NULL);
+
+ free(entry);
+ }
+
+ assert(LIST_IS_EMPTY(>zombie_sampler_views.list.node));
+
+ mtx_unlock(>zombie_sampler_views.mutex);
+}
+
+
+/*
+ * This function is called periodically to free any zombie objects
+ * which are attached to this context.
+ */
+void
+st_context_free_zombie_objects(struct st_context *st)
+{
+
Re: [Mesa-dev] [PATCH] ac/nir_to_llvm: add assert to emit_bcsel()
Reviewed-by: Bas Nieuwenhuizen
On Sun, Mar 17, 2019 at 11:04 AM Timothy Arceri wrote:
>
> nir to llvm assumes we have already split vectors to scalars via
> nir_lower_alu_to_scalar().
> ---
> src/amd/common/ac_nir_to_llvm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 18297ed99b1..0ca3f83a248 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -268,6 +268,8 @@ static LLVMValueRef emit_intrin_3f_param(struct
> ac_llvm_context *ctx,
> static LLVMValueRef emit_bcsel(struct ac_llvm_context *ctx,
>LLVMValueRef src0, LLVMValueRef src1,
> LLVMValueRef src2)
> {
> + assert(LLVMGetTypeKind(LLVMTypeOf(src0)) != LLVMVectorTypeKind);
> +
> LLVMValueRef v = LLVMBuildICmp(ctx->builder, LLVMIntNE, src0,
>ctx->i32_0, "");
> return LLVMBuildSelect(ctx->builder, v,
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] Lima mesa driver
Any chance you could submit a gitlab MR? Replying with comments inline to the driver patch is a bit more than gmail can handle.. but quick comments: In lima_pack_pp_frame_reg() maybe the swizzle field in 'struct util_format_description' is a better way to determine swap_channels? Not sure how many formats mali can render two, but I hope it is eventually more than two.. Maybe eventually you just want a formats table mapping pipe_format, to corresponding hw state for tex/fb/vbo. (Have a look at fd[3456]_format.c.. maybe a similar idea is useful to you?) Alyssa's drm_find_modifier() helper can make is_modifier_ok() go away. re: lima_screen_parse_env(), you might find DEBUG_GET_ONCE_FLAGS_OPTION() / struct debug_named_value useful? And for framebuffer (render target), pipe_surface's u.tex.level/first_layer aren't necessarily zero. Maybe I'm overlooking it, but I don't see where you're adding the offset within the resource to the requested layer/level. (I guess you'd hit that during mipmap generation, at least if relying on u_blitter for mipmap gen) BR, -R On Fri, Mar 15, 2019 at 9:30 PM Qiang Yu wrote: > > Mesa Gallium3D driver for ARM Mali 400/450 GPUs. > > Lima is still in development and not ready for daily usage, > but can run some simple tests like kmscube and glamrk2, and some > single full screen application like kodi-gbm. > > Mesa related EGL/GLX_EXT_buffer_age and EGL_KHR_partial_update > changes are not in this patch series because the solution has > not been settle down yet. > > All lima commits are squashed. For whole history of this > driver's development, see: > https://gitlab.freedesktop.org/lima/mesa/commits/lima-18.3 > https://gitlab.freedesktop.org/lima/mesa/commits/lima-18.1 > > Kernel driver is ready to be merged: > https://patchwork.kernel.org/patch/10845911/ > > This patch series also depends on a kernel patch which is > under review now: > https://patchwork.kernel.org/patch/10852619/ > > Erico Nunes (1): > gallium: add a cap to force compute minmax indices > > Qiang Yu (6): > gallium/u_math: add ushort_to_float/float_to_ushort > nir: add load uniform lower to scalar > u_dynarray: add util_dynarray_enlarge > drm-uapi: drm_fourcc.h add ARM GPU modifier > drm-uapi: add lima_drm.h > gallium: add lima driver > > Rob Herring (2): > kmsro: Add lima renderonly support > kmsro: Add platform support for exynos and sun4i > > include/drm-uapi/drm_fourcc.h | 31 +- > include/drm-uapi/lima_drm.h | 169 ++ > meson.build |7 +- > meson_options.txt |2 +- > src/compiler/nir/nir_intrinsics.py|4 +- > src/compiler/nir/nir_lower_io.c |2 +- > src/compiler/nir/nir_lower_io_to_scalar.c | 41 +- > .../auxiliary/pipe-loader/pipe_loader_drm.c |5 + > .../auxiliary/target-helpers/drm_helper.h | 23 + > .../target-helpers/drm_helper_public.h|3 + > src/gallium/auxiliary/util/u_screen.c |3 + > src/gallium/drivers/lima/ir/gp/codegen.c | 619 +++ > src/gallium/drivers/lima/ir/gp/codegen.h | 166 ++ > src/gallium/drivers/lima/ir/gp/disasm.c | 568 ++ > src/gallium/drivers/lima/ir/gp/gpir.h | 392 > src/gallium/drivers/lima/ir/gp/instr.c| 488 + > src/gallium/drivers/lima/ir/gp/lower.c| 529 ++ > src/gallium/drivers/lima/ir/gp/nir.c | 420 + > src/gallium/drivers/lima/ir/gp/node.c | 492 + > .../drivers/lima/ir/gp/physical_regalloc.c| 135 ++ > .../drivers/lima/ir/gp/reduce_scheduler.c | 220 +++ > src/gallium/drivers/lima/ir/gp/scheduler.c| 809 > .../drivers/lima/ir/gp/value_regalloc.c | 170 ++ > src/gallium/drivers/lima/ir/lima_ir.h | 65 + > src/gallium/drivers/lima/ir/pp/codegen.c | 669 +++ > src/gallium/drivers/lima/ir/pp/codegen.h | 359 > src/gallium/drivers/lima/ir/pp/disasm.c | 776 > src/gallium/drivers/lima/ir/pp/instr.c| 311 > src/gallium/drivers/lima/ir/pp/lower.c| 483 + > src/gallium/drivers/lima/ir/pp/nir.c | 497 + > src/gallium/drivers/lima/ir/pp/node.c | 432 + > .../drivers/lima/ir/pp/node_to_instr.c| 401 > src/gallium/drivers/lima/ir/pp/ppir.h | 515 ++ > src/gallium/drivers/lima/ir/pp/regalloc.c | 757 > src/gallium/drivers/lima/ir/pp/scheduler.c| 197 ++ > src/gallium/drivers/lima/lima_bo.c| 337 > src/gallium/drivers/lima/lima_bo.h| 66 + > src/gallium/drivers/lima/lima_context.c | 262 +++ > src/gallium/drivers/lima/lima_context.h | 291 +++ > src/gallium/drivers/lima/lima_draw.c | 1636 + > src/gallium/drivers/lima/lima_fence.c | 120 ++ > src/gallium/drivers/lima/lima_fence.h | 36 + >
Re: [Mesa-dev] [PATCH 5/9] drm-uapi: drm_fourcc.h add ARM GPU modifier
Note that the kernel patch for this should land first (at least in
drm-next), and then just sync (copy) the updated file to mesa.
It might be worthwhile to split the patch and anything that depends on
it into a second patchset that can land later once the drm_fourcc.h
parts land on the kernel side, so-as to not block the rest of this
patchset.
BR,
-R
On Fri, Mar 15, 2019 at 9:30 PM Qiang Yu wrote:
>
> Signed-off-by: Qiang Yu
> ---
> include/drm-uapi/drm_fourcc.h | 31 ++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
> index bab20298f42..56f737af8ca 100644
> --- a/include/drm-uapi/drm_fourcc.h
> +++ b/include/drm-uapi/drm_fourcc.h
> @@ -585,6 +585,19 @@ extern "C" {
> */
> #define DRM_FORMAT_MOD_BROADCOM_UIF fourcc_mod_code(BROADCOM, 6)
>
> +/*
> + * Arm Buffer Layout Type Code
> + *
> + * Arm has multiple types of buffer layout which are not totally shared
> + * across devices, so add a type field at the MSB of the format field
> + * to separate each type's encoding.
> + */
> +#define DRM_FORMAT_MOD_ARM_TYPE_AFBC 0x00
> +#define DRM_FORMAT_MOD_ARM_TYPE_AGTB 0x01
> +
> +#define DRM_FORMAT_MOD_ARM_CODE(type, val) \
> + fourcc_mod_code(ARM, ((__u64)type << 48) | ((val) &
> 0xULL))
> +
> /*
> * Arm Framebuffer Compression (AFBC) modifiers
> *
> @@ -599,7 +612,8 @@ extern "C" {
> * Further information on the use of AFBC modifiers can be found in
> * Documentation/gpu/afbc.rst
> */
> -#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) fourcc_mod_code(ARM,
> __afbc_mode)
> +#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) \
> + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AFBC, __afbc_mode)
>
> /*
> * AFBC superblock size
> @@ -693,6 +707,21 @@ extern "C" {
> */
> #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
>
> +/*
> + * Arm Graphics Tiled Buffer (AGTB) modifiers
> + */
> +#define DRM_FORMAT_MOD_ARM_AGTB(mode) \
> + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AGTB, mode)
> +
> +/*
> + * AGTB mode 0 modifier
> + *
> + * This is used by ARM Mali Utgard/Midgard GPU. It divides buffer into
> + * 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
> + * in the block are reordered.
> + */
> +#define DRM_FORMAT_MOD_ARM_AGTB_MODE0 DRM_FORMAT_MOD_ARM_AGTB(1)
> +
> /*
> * Allwinner tiled modifier
> *
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110141] glesv1_cm.pc and glesv2.pc missing after b01524fff05eef66e8cd24f1c5aacefed4209f03
https://bugs.freedesktop.org/show_bug.cgi?id=110141 Yurii Kolesnykov changed: What|Removed |Added CC||r...@yurikoles.com -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] ac/nir_to_llvm: add assert to emit_bcsel()
nir to llvm assumes we have already split vectors to scalars via
nir_lower_alu_to_scalar().
---
src/amd/common/ac_nir_to_llvm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 18297ed99b1..0ca3f83a248 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -268,6 +268,8 @@ static LLVMValueRef emit_intrin_3f_param(struct
ac_llvm_context *ctx,
static LLVMValueRef emit_bcsel(struct ac_llvm_context *ctx,
LLVMValueRef src0, LLVMValueRef src1,
LLVMValueRef src2)
{
+ assert(LLVMGetTypeKind(LLVMTypeOf(src0)) != LLVMVectorTypeKind);
+
LLVMValueRef v = LLVMBuildICmp(ctx->builder, LLVMIntNE, src0,
ctx->i32_0, "");
return LLVMBuildSelect(ctx->builder, v,
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v5] etnaviv: fix resource usage tracking across different pipe_context's
Am Sa., 16. März 2019 um 20:55 Uhr schrieb Marek Vasut : > > On 2/22/19 10:30 AM, Boris Brezillon wrote: > > On Thu, 21 Feb 2019 23:29:53 +0100 > > Boris Brezillon wrote: > > > >> Christian, Marek, > >> > >> On Wed, 30 Jan 2019 05:28:14 +0100 > >> Marek Vasut wrote: > >> > >>> From: Christian Gmeiner > >>> > >>> A pipe_resource can be shared by all the pipe_context's hanging off the > >>> same pipe_screen. > >> > >> We seem to be impacted by the problem you're fixing here, but, while > >> this patch definitely make things much better, the problem does not > >> seem to be entirely fixed (at least in our case). > >> > >> A bit more context: we have Qt App using QtWebEngine to render html > >> content. When we call QtWebEngine::initialize(), which as for effect > >> to allow shared GL contexts, we sometimes notice that part of the web > >> page is mis-rendered. That does not happen when we omit the > >> QtWebEngine::initialize() call. > >> As said above, this patch make those rendering issues less likely to > >> happen, but we still have the problem from time to time. So I thought > >> I'd share my guesses about what could cause these issues before > >> debugging it further. > >> > >> First thing I noticed: I couldn't reproduce the problem with [1] > >> applied (+ a tiny change forcing CPU-based tiling no matter the size of > >> the region to tile/untile). So, my guess is that it's related to how we > >> handle GPU-based tiling/untiling. > >> Also noticed that we're testing the rsc->status here [2] without the > >> screen->lock held, and there might be a race with another thread calling > >> resource_used(). We might also lack a resource_read(ctx, >base) > >> here [3]. But even after fixing those problems, the rendering issues > >> are not gone. > > > > I tested again with the following diff applied on top of your patch, and > > the remaining rendering issues we had seem to be gone (don't know what I > > messed up in my previous tests :-/). > > > > --->8--- > > diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c > > b/src/gallium/drivers/etnaviv/etnaviv_rs.c > > index fc4f65dbeee1..b8c8b96a6f72 100644 > > --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c > > +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c > > @@ -729,6 +729,7 @@ etna_try_rs_blit(struct pipe_context *pctx, > > > > etna_submit_rs_state(ctx, _to_screen); > > resource_written(ctx, >base); > > + resource_read(ctx, >base); > > dst->seqno++; > > dst->levels[blit_info->dst.level].ts_valid = false; > > ctx->dirty |= ETNA_DIRTY_DERIVE_TS; > While the V6 of this patch [1] is now in mesa upstream, this hunk is > missing from the V6 . Any special reason for that or is this just an > omission ? > This and an other change was done in separates commits - see: https://cgit.freedesktop.org/mesa/mesa/commit/?id=7244e768040859126a5b74023f587beaa8bef81c https://cgit.freedesktop.org/mesa/mesa/commit/?id=c56e73449698c31fe72b99a95b7e4ecdb2985b73 So everything went in. -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
