[Mesa-dev] [Bug 109945] pan_assemble.c:51:46: error: passing argument 2 of ‘tgsi_to_nir’ from incompatible pointer type [-Werror=incompatible-pointer-types]
https://bugs.freedesktop.org/show_bug.cgi?id=109945 Andre Heider changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Andre Heider --- Fixed with: commit d4d29c0455bf8540de3c006dd213ae1ccf2bc361 Author: Eric Engestrom Date: Sat Mar 9 22:04:21 2019 + panfrost: fix tgsi_to_nir() call Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109945 Fixes: 7da251fc721360fc28b9 "panfrost: Check in sources for command stream" Cc: Alyssa Rosenzweig Signed-off-by: Eric Engestrom -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=109939 --- Comment #11 from mikhail.v.gavri...@gmail.com --- (In reply to Mike Lothian from comment #7) > Out of interest, if you wait long enough does it eventually complete and it > it faster the next time you load if you get it to complete > > Might be that you're relying on caching and each time you install a newer RC > you have to rebuild the cache I was wait a bit more and level are was loaded after while. But this is abnormal to wait 20 minutes for loading each level on high end level hardware. CPU: Ryzen 2700X RAM: 32GB GPU: Vega 64 SSD: Optane 905P I remember that when the game out on Linux i am not experienced this problem on worse hardware. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109927] Xorg segfault when a web browser is opened
https://bugs.freedesktop.org/show_bug.cgi?id=109927 --- Comment #6 from fin4...@hotmail.com --- > Display Server: x11 (X.Org 1.19.6 ) drivers: ati,vesa You should use the radeon or amdgpu kernel driver with a Hawaii card. Update to ubuntu cosmic. See: https://wiki.archlinux.org/index.php/AMDGPU#Enable_Southern_Islands_(SI)_and_Sea_Islands_(CIK)_support -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: document Meson -Dc_args and -Dcpp_args
On Fri, Mar 8, 2019 at 4:20 PM Eric Engestrom
wrote:
> On Friday, 2019-03-08 15:54:37 -0700, Brian Paul wrote:
> > ---
> > docs/meson.html | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/docs/meson.html b/docs/meson.html
> > index 7ffef81..43090aa 100644
> > --- a/docs/meson.html
> > +++ b/docs/meson.html
> > @@ -274,6 +274,19 @@ on the system. This environment variable is used to
> control the search path for
> > PKG_CONFIG_PATH=/usr/X11R6/lib/pkgconfig will search for
> package
> > metadata in /usr/X11R6 before the standard directories.
> >
> > +
> > +
> > +Extra Compiler Flags
> > +
> > +
> > +If you need to pass additional flags to the C/C++ compiler, one can use
> > +the -Dc_args or -Dcpp_args options. For
> example:
> > +
> > +
> > +meson builddir/ -Dc_args=-fmax-errors=10 -Dcpp_args=-DMAGIC=123
> > +
> > +
>
> This is already explained in the "Environment Variables" section on this
> page. Perhaps it should be rephrased instead, if it didn't have the
> information you were looking for, or wasn't clear?
> ("env var" is an accident of how autotools used to do it, and might not
> be the best title for it in meson, for instance)
>
Yeah, I think I only skimmed over that and didn't make the connection
between environment variables and meson configuration options. I'll rework
this patch on Monday. Thanks.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] st/mesa: fix sampler view context mismatch issue
On Sun, Mar 10, 2019 at 1:20 AM Mathias Fröhlich wrote: > Brian, > > One question also for my own education inline below: > > On Friday, 8 March 2019 23:52:09 CET Brian Paul wrote: > > After a while of running google-chrome and viewing Bing maps, we'd see > > "context mismatch in svga_sampler_view_destroy()" messages and > > eventually crash because we leaked too many sampler views (the kernel > > module would have too many sampler views). > > > > When a texture object is being deleted, we call > > st_texture_release_all_sampler_views() to release all the sampler > > views. In the list, there may sampler views which were created from > > other contexts. > > > > Previously, we called pipe_sampler_view_release(pipe, view) which would > > use the given pipe context to destroy the view if the refcount hit > > zero. The svga error was triggered because we were calling > > pipe->sampler_view_destroy(pipe, view) and the pipe context didn't > > match the view's parent context. > > > > Instead, call pipe_sampler_reference(&view, NULL). That way, if > > the refcount hits zero, we'll use the view's parent context to > > destroy the view. That's what we want. > > That sounds plausible so far. > > What I wonder, is calling into an 'arbitrary' different context and do > work there > thread safe for any gallium driver? > Right. Before this patch there was the problem of trying to destroy a sampler view with a context different from the one which created it. That's fixed, but now there's the multi-threading issue as you say, and which I believe, is a less-common situation. > > Especially since pipe_sampler_view_reference in its documentation says > that the > views provided need to originate from the same context and that this must > be the 'current'. > > I have been taking a quick look into iris and radeonsi and both seem to be > safe > in terms of threads for dereferencing the views finally. > But either the documentation of pipe_sampler_view_reference should be > updated > or I may miss an other piece of the puzzle to see that it is still save to > do so. > Last week I posted a patch series for the VMware driver which handled the thread issue with a list of "zombie" sampler views. Jose suggested moving that up into the state tracker, and that is a better long-term solution. I'm almost done with a patch series that does that. I'll likely post it tomorrow. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] android, autotools: st/mesa: fix location of float64_glsl.h
Hi Jordan,
On Wed, Mar 6, 2019 at 10:01 PM Jordan Justen wrote:
>
> On 2019-03-04 16:11:33, Jordan Justen wrote:
> > On 2019-03-04 15:21:26, Mauro Rossi wrote:
> > > Hi,
> > > On Mon, Mar 4, 2019 at 7:50 PM Mauro Rossi wrote:
> > > >
> > > > Il lun 4 mar 2019, 18:59 Dylan Baker ha scritto:
> > > >>
> > > >> I wrote c812, and I'd be very happy to revert it. The problem that I
> > > >> ran into
> > > >> was putting it in a place that android, meson, and the autotools dist
> > > >> tarball
> > > >> were happy with. I'm hoping that we can remove autotools in the very
> > > >> near future
> > > >> and just revert c812 at that time. Does that seem like a reasonable
> > > >> solution?
> > > >>
> > > >> Dylan
> > >
> > > Hi Dylan,
> > > I have checked on Android.mk and reverting you commit c812c740e6
> > > would be very complex.
> > >
> > > The best way is to proceed now is with my patch to un-break the Android
> > > build
> > >
> > > Then as a reference, the future solution may require chages to sources:
> > >
> > > #include "compiler/glsl/{header}.h"
> > > to become
> > > #include "glsl/{header}.h"
> > >
> > > in order to reach the Android generated files with
> > > $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_glsl,,)
> > > as equivalent of -I$(top_builddir)/src/compiler
> >
> > Just wanted to point out that Jason is moving this under glsl in:
> >
> > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/371
>
> Mauro,
>
> Jason pushed MR 371 in 9ab1b1d0227499b7ff6a61fdebe75693212a67f5.
>
> > So, either that will fix this, or else cause it to break in a new,
> > different way. :)
>
> Which was it? :)
>
> -Jordan
The android build is ok for me, without need for android, autotools patch
I tested also build of iris
Mauro
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=109939 --- Comment #10 from Timur Kristóf --- (In reply to Alex Smith from comment #8) > What LLVM version are you using and what CPU do you have? I'm unable to > reproduce this on current 19.0 branch > (8ab2fc8c963955818d6cbc1db47b76d9bffb9eb6) using LLVM 7, loading times seem > as expected to me with the disk cache cleared (on an i7 6700, a couple of > minutes to load Soviet Installation, which has the most pipelines of all > levels in the game). I have an Intel i7-8550U, 16 GB RAM and an AMD RX 570 with 4 GB or VRAM (connected through a TB3 port). On this system, RotTR is mostly limited by the GPU, so once the game is loaded it hardly uses any CPU, but it utilizes the GPU to nearly 100%. On some heavy areas (Soviet Installation and Geothermal Valley are the most heavy ones in my experience), the game takes a long time to load, but sometimes (regardless of which area I'm in), it never loads, just keeps showing the loading screen and spins up the CPU. (By never, I mean about 20-30 minutes when I run out of patience and kill it.) When this happens, it helps to clear the contents of "~/.local/share/feral-interactive/Rise of the Tomb Raider" (except for the savegames of course). After that the game always loads (though takes a bit longer than usual, I assume it has to rebuild some cache). I'm running Fedora 29 with mesa 18.3.4 and LLVM 7.0.1. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109393] [vega10] hang with Mario Party 9 through Dolphin
https://bugs.freedesktop.org/show_bug.cgi?id=109393 --- Comment #16 from Jaap Buurman --- I am only familiar with Building mesa through the AUR (Mesa-Git). Can I easily apply that patch somehow in the PKGBUILD or would it be easier for me to wait for the patch to be accepted into the repository and build from that? -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] st/mesa: fix sampler view context mismatch issue
Brian,
One question also for my own education inline below:
On Friday, 8 March 2019 23:52:09 CET Brian Paul wrote:
> After a while of running google-chrome and viewing Bing maps, we'd see
> "context mismatch in svga_sampler_view_destroy()" messages and
> eventually crash because we leaked too many sampler views (the kernel
> module would have too many sampler views).
>
> When a texture object is being deleted, we call
> st_texture_release_all_sampler_views() to release all the sampler
> views. In the list, there may sampler views which were created from
> other contexts.
>
> Previously, we called pipe_sampler_view_release(pipe, view) which would
> use the given pipe context to destroy the view if the refcount hit
> zero. The svga error was triggered because we were calling
> pipe->sampler_view_destroy(pipe, view) and the pipe context didn't
> match the view's parent context.
>
> Instead, call pipe_sampler_reference(&view, NULL). That way, if
> the refcount hits zero, we'll use the view's parent context to
> destroy the view. That's what we want.
That sounds plausible so far.
What I wonder, is calling into an 'arbitrary' different context and do work
there
thread safe for any gallium driver?
Especially since pipe_sampler_view_reference in its documentation says that the
views provided need to originate from the same context and that this must
be the 'current'.
I have been taking a quick look into iris and radeonsi and both seem to be safe
in terms of threads for dereferencing the views finally.
But either the documentation of pipe_sampler_view_reference should be updated
or I may miss an other piece of the puzzle to see that it is still save to do
so.
Can you tell me?
thanks
Mathias
>
> The pipe_sampler_view_release() function was introduced years ago to
> avoid freeing a sampler view with a context that was already deleted.
>
> But since then we've improved sampler view and context tracking.
> When a context is destroyed, the state tracker walks over all
> texture objects and frees all sampler views which belong to that
> context. So, we should never end up deleting a sampler view after
> its context is deleted.
>
> After this, we can remove all calls to pipe_sampler_view_release()
> in the drivers.
>
> Finally, it appears that we need to implement a similar tear-down
> mechanism for shaders and programs since we may generate per-context
> shader variants.
>
> Testing done: google chrome, misc GL demos, games
> ---
> src/mesa/state_tracker/st_context.c | 3 +--
> src/mesa/state_tracker/st_sampler_view.c | 8
> 2 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_context.c
> b/src/mesa/state_tracker/st_context.c
> index 2898279..a7464fd 100644
> --- a/src/mesa/state_tracker/st_context.c
> +++ b/src/mesa/state_tracker/st_context.c
> @@ -278,8 +278,7 @@ st_destroy_context_priv(struct st_context *st, bool
> destroy_pipe)
> st_destroy_bound_image_handles(st);
>
> for (i = 0; i < ARRAY_SIZE(st->state.frag_sampler_views); i++) {
> - pipe_sampler_view_release(st->pipe,
> -&st->state.frag_sampler_views[i]);
> + pipe_sampler_view_reference(&st->state.frag_sampler_views[i], NULL);
> }
>
> /* free glReadPixels cache data */
> diff --git a/src/mesa/state_tracker/st_sampler_view.c
> b/src/mesa/state_tracker/st_sampler_view.c
> index e4eaf39..650a2b0 100644
> --- a/src/mesa/state_tracker/st_sampler_view.c
> +++ b/src/mesa/state_tracker/st_sampler_view.c
> @@ -74,7 +74,7 @@ st_texture_set_sampler_view(struct st_context *st,
>if (sv->view) {
> /* check if the context matches */
> if (sv->view->context == st->pipe) {
> -pipe_sampler_view_release(st->pipe, &sv->view);
> +pipe_sampler_view_reference(&sv->view, NULL);
> goto found;
> }
>} else {
> @@ -94,13 +94,13 @@ st_texture_set_sampler_view(struct st_context *st,
>
> if (new_max < views->max ||
> new_max > (UINT_MAX - sizeof(*views)) /
> sizeof(views->views[0])) {
> -pipe_sampler_view_release(st->pipe, &view);
> +pipe_sampler_view_reference(&view, NULL);
> goto out;
> }
>
> struct st_sampler_views *new_views = malloc(new_size);
> if (!new_views) {
> -pipe_sampler_view_release(st->pipe, &view);
> +pipe_sampler_view_reference(&view, NULL);
> goto out;
> }
>
> @@ -225,7 +225,7 @@ st_texture_release_all_sampler_views(struct st_context
> *st,
> simple_mtx_lock(&stObj->validate_mutex);
> struct st_sampler_views *views = stObj->sampler_views;
> for (i = 0; i < views->count; ++i)
> - pipe_sampler_view_release(st->pipe, &views->views[i].view);
> + pipe_sampler_view_reference(&views->views[i].view, NULL);
> simple_mtx_unlock(&stObj->validate_mutex);
> }
>
>
___
