Re: [Mesa-dev] [PATCH 3/3] winsys/svga: use new pb_usage_flags enum type
On Tue, 2019-03-05 at 20:48 -0700, Brian Paul wrote:
> And add a comment that we're implicitly converting PIPE_TRANSFER_
> flags to PB_USAGE_ flags in one place. And statically assert that
> the enum values match.
LGTM. Thanks for fixing this!
Reviewed-by: Thomas Hellstrom
> ---
> src/gallium/winsys/svga/drm/vmw_buffer.c | 27
> +++
> src/gallium/winsys/svga/drm/vmw_buffer.h | 1 +
> src/gallium/winsys/svga/drm/vmw_context.c | 4 ++--
> 3 files changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/winsys/svga/drm/vmw_buffer.c
> b/src/gallium/winsys/svga/drm/vmw_buffer.c
> index 3ac80c7..91b5b25 100644
> --- a/src/gallium/winsys/svga/drm/vmw_buffer.c
> +++ b/src/gallium/winsys/svga/drm/vmw_buffer.c
> @@ -90,6 +90,11 @@ static inline struct vmw_gmr_bufmgr *
> vmw_gmr_bufmgr(struct pb_manager *mgr)
> {
> assert(mgr);
> +
> + /* Make sure our extra flags don't collide with pipebuffer's
> flags */
> + STATIC_ASSERT((VMW_BUFFER_USAGE_SHARED & PB_USAGE_ALL) == 0);
> + STATIC_ASSERT((VMW_BUFFER_USAGE_SYNC & PB_USAGE_ALL) == 0);
> +
> return (struct vmw_gmr_bufmgr *)mgr;
> }
>
> @@ -109,7 +114,7 @@ vmw_gmr_buffer_destroy(struct pb_buffer *_buf)
>
> static void *
> vmw_gmr_buffer_map(struct pb_buffer *_buf,
> - unsigned flags,
> + enum pb_usage_flags flags,
> void *flush_ctx)
> {
> struct vmw_gmr_buffer *buf = vmw_gmr_buffer(_buf);
> @@ -140,7 +145,7 @@ static void
> vmw_gmr_buffer_unmap(struct pb_buffer *_buf)
> {
> struct vmw_gmr_buffer *buf = vmw_gmr_buffer(_buf);
> - unsigned flags = buf->map_flags;
> + enum pb_usage_flags flags = buf->map_flags;
>
> if ((_buf->usage & VMW_BUFFER_USAGE_SYNC) &&
> !(flags & PB_USAGE_UNSYNCHRONIZED)) {
> @@ -164,7 +169,7 @@ vmw_gmr_buffer_get_base_buffer(struct pb_buffer
> *buf,
> static enum pipe_error
> vmw_gmr_buffer_validate( struct pb_buffer *_buf,
> struct pb_validate *vl,
> - unsigned flags )
> + enum pb_usage_flags flags )
> {
> /* Always pinned */
> return PIPE_OK;
> @@ -338,7 +343,7 @@ vmw_svga_winsys_buffer_destroy(struct
> svga_winsys_screen *sws,
> void *
> vmw_svga_winsys_buffer_map(struct svga_winsys_screen *sws,
> struct svga_winsys_buffer *buf,
> - unsigned flags)
> + enum pipe_transfer_usage flags)
> {
> void *map;
>
> @@ -346,6 +351,20 @@ vmw_svga_winsys_buffer_map(struct
> svga_winsys_screen *sws,
> if (flags & PIPE_TRANSFER_UNSYNCHRONIZED)
>flags &= ~PIPE_TRANSFER_DONTBLOCK;
>
> + /* NOTE: we're passing PIPE_TRANSFER_x flags instead of
> +* PB_USAGE_x flags here. We should probably fix that.
> +*/
> + STATIC_ASSERT((unsigned) PB_USAGE_CPU_READ ==
> + (unsigned) PIPE_TRANSFER_READ);
> + STATIC_ASSERT((unsigned) PB_USAGE_CPU_WRITE ==
> + (unsigned) PIPE_TRANSFER_WRITE);
> + STATIC_ASSERT((unsigned) PB_USAGE_GPU_READ ==
> + (unsigned) PIPE_TRANSFER_MAP_DIRECTLY);
> + STATIC_ASSERT((unsigned) PB_USAGE_DONTBLOCK ==
> + (unsigned) PIPE_TRANSFER_DONTBLOCK);
> + STATIC_ASSERT((unsigned) PB_USAGE_UNSYNCHRONIZED ==
> + (unsigned) PIPE_TRANSFER_UNSYNCHRONIZED);
> +
> map = pb_map(vmw_pb_buffer(buf), flags, NULL);
>
> #ifdef DEBUG
> diff --git a/src/gallium/winsys/svga/drm/vmw_buffer.h
> b/src/gallium/winsys/svga/drm/vmw_buffer.h
> index 6e1151e..8ed56d4 100644
> --- a/src/gallium/winsys/svga/drm/vmw_buffer.h
> +++ b/src/gallium/winsys/svga/drm/vmw_buffer.h
> @@ -33,6 +33,7 @@
> #include "util/u_debug_flush.h"
>
>
> +/* These extra flags are used wherever the pb_usage_flags enum type
> is used */
> #define VMW_BUFFER_USAGE_SHARED(1 << 20)
> #define VMW_BUFFER_USAGE_SYNC (1 << 21)
>
> diff --git a/src/gallium/winsys/svga/drm/vmw_context.c
> b/src/gallium/winsys/svga/drm/vmw_context.c
> index c0ee833..59963ff 100644
> --- a/src/gallium/winsys/svga/drm/vmw_context.c
> +++ b/src/gallium/winsys/svga/drm/vmw_context.c
> @@ -161,10 +161,10 @@ vmw_svga_winsys_context(struct
> svga_winsys_context *swc)
> }
>
>
> -static inline unsigned
> +static inline enum pb_usage_flags
> vmw_translate_to_pb_flags(unsigned flags)
> {
> - unsigned f = 0;
> + enum pb_usage_flags f = 0;
> if (flags & SVGA_RELOC_READ)
>f |= PB_USAGE_GPU_READ;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/u_transfer_helper: do not call resource_create(..) directly
Am Fr., 1. März 2019 um 16:54 Uhr schrieb Christian Gmeiner
:
>
> Use u_transfer_helper_resource_create(..) instead which uses the
> resource_create(..) function specified in u_transfer_vtbl.
>
> Signed-off-by: Christian Gmeiner
> ---
> src/gallium/auxiliary/util/u_transfer_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/util/u_transfer_helper.c
> b/src/gallium/auxiliary/util/u_transfer_helper.c
> index 14c4d56392d..a5c3c026e71 100644
> --- a/src/gallium/auxiliary/util/u_transfer_helper.c
> +++ b/src/gallium/auxiliary/util/u_transfer_helper.c
> @@ -182,7 +182,7 @@ transfer_map_msaa(struct pipe_context *pctx,
> .depth0 = 1,
> .array_size = 1,
> };
> - trans->ss = pscreen->resource_create(pscreen, );
> + trans->ss = u_transfer_helper_resource_create(pscreen, );
> if (!trans->ss) {
>free(trans);
>return NULL;
> --
> 2.20.1
>
ping
--
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
[Mesa-dev] [Bug 41595] Hi10P videos produce improper output in gl unless yv12 is used.
https://bugs.freedesktop.org/show_bug.cgi?id=41595 Tapani Pälli changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Tapani Pälli --- *** This bug has been marked as a duplicate of bug 41461 *** -- 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
Re: [Mesa-dev] [PATCH] docs: try to improve the Meson documentation
On 2019-03-08 at 03:42, Brian Paul wrote: > Add new Introduction and Advanced Usage sections. > Spell out a few more details, like "ninja install". > Improve the layout around example commands. > Fix grammatical errors and tighten up the text. > Explain the --prefix option. Thanks! I left a couple comments below, but this is: Reviewed-by: Eric Engestrom > --- > docs/contents.html | 2 +- > docs/meson.html| 138 > +++-- > 2 files changed, 104 insertions(+), 36 deletions(-) > > diff --git a/docs/contents.html b/docs/contents.html > index 6364776..619ac3d 100644 > --- a/docs/contents.html > +++ b/docs/contents.html > @@ -42,8 +42,8 @@ > Downloading / Unpacking > Compiling / Installing > > -Autoconf > Meson > +Autoconf > (deprecated) > > > Precompiled Libraries > diff --git a/docs/meson.html b/docs/meson.html > index f21479c..f9ae669 100644 > --- a/docs/meson.html > +++ b/docs/meson.html > @@ -17,65 +17,98 @@ > Compilation and Installation using Meson > > > + Introduction >Basic Usage > + Advanced Usage >Cross-compilation and 32-bit > builds > > > -1. Basic Usage > +1. Introduction > > -The Meson build system is generally considered stable and ready > -for production > +For general information about Meson see the > +http://mesonbuild.com/;>Meson website. > > -The meson build is tested on Linux, macOS, Cygwin and Haiku, > FreeBSD, > +Mesa's Meson build system is generally considered stable > and ready > +for production. > + > +The Meson build of Mesa is tested on Linux, macOS, Cygwin and > Haiku, FreeBSD, > DragonflyBSD, NetBSD, and should work on OpenBSD. > > +If Meson is not already installed on your system, you can typically > +install it with your package installer. For example: > + > +sudo apt-get install meson # Ubuntu > + > +or > + > +sudo dnf install meson # Fedora > + > + > Mesa requires Meson >= 0.45.0 to build. > > Some older versions of meson do not check that they are too old and will > error > out in odd ways. > > > +You'll also need https://ninja-build.org/;>Ninja. > +If it's not already installed, use apt-get or dnf to install > +the ninja-build package. > + > + > +2. Basic Usage > + > > The meson program is used to configure the source directory and > generates > either a ninja build file or Visual Studio® build files. The latter > must > -be enabled via the --backend switch, as ninja is the > default backend on all > -operating systems. Meson only supports out-of-tree builds, and must be > passed a > +be enabled via the --backend switch, as ninja is the > default > +backend on all > +operating systems. > + > + > + > +Meson only supports out-of-tree builds, and must be passed a > directory to put built and generated sources into. We'll call that > directory > -"build" for examples. > +"build" here. > > > +Basic configuration is done with: > + > > -meson build/ > +meson build/ > > > > -To see a description of your options you can run meson configure > -along with a build directory to view the selected options for. This will show > -your meson global arguments and project arguments, along with their defaults > -and your local settings. > +This will create the build directory. > +If any dependencies are missing, you can install them, or try to remove > +the dependency with a Meson configuration option (see below). > + > + > + > +To review the options which Meson chose, run: > > + > +meson configure build/ > + > > > -Meson does not currently support listing options before configure a build > -directory, but this feature is being discussed upstream. > +Meson does not currently support listing configuration options before > +running "meson build/" but this feature is being discussed upstream. > For now, we have a bin/meson-options.py script that prints > the options for you. > If that script doesn't work for some reason, you can always look in the > meson_options.txt file at the root of the project. > > > - > -meson configure build/ > - > - > > -With additional arguments meson configure is used to change > -options on already configured build directory. All options passed to this > -command are in the form -D "command"="value". > +With additional arguments meson configure can be used to change > +options for a previously configured build directory. > +All options passed to this command are in the form > +-D "command"="value". I know you didn't write this bit, but can I suggest s/command/option/ ? > +For example: > > > > -meson configure build/ -Dprefix=/tmp/install -Dglx=true > +meson configure build/ -Dprefix=/tmp/install -Dglx=true > > > > @@ -88,33 +121,68 @@ and brackets to represent an empty list (-D > platforms=[]). > > > Once you've run the initial meson command successfully you can > use > -your configured backend to build the project. With ninja, the -C option can > be > -be used to point
Re: [Mesa-dev] [PATCH] svga: remove SVGA_RELOC_READ flag in SVGA3D_BindGBSurface()
On Thu, 2019-03-07 at 19:45 -0700, Brian Paul wrote: > This fixes a rendering issue where UBO updates aren't always picked > up by drawing calls. This issue effected the Webots robotics > simulator. VMware bug 2175527. > > Testing Done: Webots replay, piglit, misc Linux games > --- > src/gallium/drivers/svga/svga_cmd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/svga/svga_cmd.c > b/src/gallium/drivers/svga/svga_cmd.c > index 5557d20..6577c83 100644 > --- a/src/gallium/drivers/svga/svga_cmd.c > +++ b/src/gallium/drivers/svga/svga_cmd.c > @@ -1693,7 +1693,7 @@ SVGA3D_BindGBSurface(struct svga_winsys_context > *swc, >return PIPE_ERROR_OUT_OF_MEMORY; > > swc->surface_relocation(swc, >sid, >mobid, surface, > - SVGA_RELOC_READ | SVGA_RELOC_INTERNAL); > + SVGA_RELOC_READ); > > swc->commit(swc); > Reviewed-by: Thomas Hellström ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] st/nine: Disable depth write when nothing gets updated
On Thursday, March 7, 2019 2:23:53 PM PST Axel Davy wrote:
> I do not see any perf impact on radeonsi, but it
> seems iris needs this.
> It seems something sensible to do.
>
> Signed-off-by: Axel Davy
> Reviewed-by: Timur Kristóf
> Tested-by: Andre Heider
> ---
> It may be argued this kind of stuff should be done in the driver.
> I don't mind either way. The ogl state tracker already does that
> optimization.
> src/gallium/state_trackers/nine/nine_pipe.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/nine/nine_pipe.c
> b/src/gallium/state_trackers/nine/nine_pipe.c
> index a84a17f551f..b69ddb67113 100644
> --- a/src/gallium/state_trackers/nine/nine_pipe.c
> +++ b/src/gallium/state_trackers/nine/nine_pipe.c
> @@ -36,8 +36,11 @@ nine_convert_dsa_state(struct
> pipe_depth_stencil_alpha_state *dsa_state,
>
> if (rs[D3DRS_ZENABLE]) {
> dsa.depth.enabled = 1;
> -dsa.depth.writemask = !!rs[D3DRS_ZWRITEENABLE];
> dsa.depth.func = d3dcmpfunc_to_pipe_func(rs[D3DRS_ZFUNC]);
> +/* Disable depth write if no change can occur */
> +dsa.depth.writemask = !!rs[D3DRS_ZWRITEENABLE] &&
> +dsa.depth.func != PIPE_FUNC_EQUAL &&
> +dsa.depth.func != PIPE_FUNC_NEVER;
> }
>
> if (rs[D3DRS_STENCILENABLE]) {
>
I don't think we actually need the NEVER check, but it seems fine.
Patches 1 and 3 are:
Reviewed-by: Kenneth Graunke
I'm not really up to speed to review the others.
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109401] [DXVK] Project Cars rendering problems
https://bugs.freedesktop.org/show_bug.cgi?id=109401 ammy...@gmail.com changed: What|Removed |Added CC||ammy...@gmail.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
Re: [Mesa-dev] [PATCH] gallium: Add PIPE_BARRIER_UPDATE_BUFFER and UPDATE_TEXTURE bits.
Forgot Marek is on vacation. Nicolai, do you have an opinion?
It looks like you added the original comments that it isn't
necessary to handle these cases, too...
--Ken
On Thursday, March 7, 2019 3:48:04 PM PST Kenneth Graunke wrote:
> Hey Ilia, Marek,
>
> Do you have an opinion about this? I've got a R-b from Eric Anholt
> and what sounds like an Ack from Roland, but I wanted to make sure
> everyone was OK with this before landing it.
>
> --Ken
>
> On Wednesday, March 6, 2019 12:32:23 AM PST Kenneth Graunke wrote:
> > The glMemoryBarrier() function makes shader memory stores ordered with
> > respect to things specified by the given bits. Until now, st/mesa has
> > ignored GL_TEXTURE_UPDATE_BARRIER_BIT and GL_BUFFER_UPDATE_BARRIER_BIT,
> > saying that drivers should implicitly perform the needed flushing.
> >
> > This seems like a pretty big assumption to make. Instead, this commit
> > opts to translate them to new PIPE_BARRIER bits, and adjusts existing
> > drivers to continue ignoring them (preserving the current behavior).
> >
> > The i965 driver performs actions on these memory barriers. Shader
> > memory stores go through a "data cache" which is separate from the
> > render cache and other read caches (like the texture cache). All
> > memory barriers need to flush the data cache (to ensure shader memory
> > stores are visible), and possibly invalidate read caches (to ensure
> > stale data is no longer visible). The driver implicitly flushes for
> > most caches, but not for data cache, since ARB_shader_image_load_store
> > introduced MemoryBarrier() precisely to order these explicitly.
> >
> > I would like to follow i965's approach in iris, flushing the data cache
> > on any MemoryBarrier() call, so I need st/mesa to actually call the
> > pipe->memory_barrier() callback.
> > ---
> > .../drivers/freedreno/freedreno_context.c | 3 ++
> > src/gallium/drivers/r600/r600_state_common.c | 4 +++
> > src/gallium/drivers/radeonsi/si_state.c | 3 ++
> > src/gallium/drivers/softpipe/sp_flush.c | 3 ++
> > src/gallium/drivers/tegra/tegra_context.c | 3 ++
> > src/gallium/drivers/v3d/v3d_context.c | 3 ++
> > src/gallium/include/pipe/p_defines.h | 7 +++-
> > src/mesa/state_tracker/st_cb_texturebarrier.c | 34 +++
> > 8 files changed, 44 insertions(+), 16 deletions(-)
> >
> > I am curious to hear people's thoughts on this. It seems useful for the
> > driver to receive a memory_barrier() call...and adding a few bits seemed
> > to be the cleanest way to make that happen. But I'm open to ideas.
> >
> > There are no nouveau changes in this patch, but that's only because none
> > appeared to be necessary. Most drivers performed some kind of flush on
> > any memory_barrier() call, regardless of the bits - but nouveau's hooks
> > don't. So the newly added case would already be a no-op.
> >
> > diff --git a/src/gallium/drivers/freedreno/freedreno_context.c
> > b/src/gallium/drivers/freedreno/freedreno_context.c
> > index 6c01c15bb32..4e86d099974 100644
> > --- a/src/gallium/drivers/freedreno/freedreno_context.c
> > +++ b/src/gallium/drivers/freedreno/freedreno_context.c
> > @@ -99,6 +99,9 @@ fd_texture_barrier(struct pipe_context *pctx, unsigned
> > flags)
> > static void
> > fd_memory_barrier(struct pipe_context *pctx, unsigned flags)
> > {
> > + if (!(flags & ~PIPE_BARRIER_UPDATE))
> > + return;
> > +
> > fd_context_flush(pctx, NULL, 0);
> > /* TODO do we need to check for persistently mapped buffers and
> > fd_bo_cpu_prep()?? */
> > }
> > diff --git a/src/gallium/drivers/r600/r600_state_common.c
> > b/src/gallium/drivers/r600/r600_state_common.c
> > index f886a27170d..c7c606f131b 100644
> > --- a/src/gallium/drivers/r600/r600_state_common.c
> > +++ b/src/gallium/drivers/r600/r600_state_common.c
> > @@ -94,6 +94,10 @@ void r600_emit_alphatest_state(struct r600_context
> > *rctx, struct r600_atom *atom
> > static void r600_memory_barrier(struct pipe_context *ctx, unsigned flags)
> > {
> > struct r600_context *rctx = (struct r600_context *)ctx;
> > +
> > + if (!(flags & ~PIPE_BARRIER_UPDATE))
> > + return;
> > +
> > if (flags & PIPE_BARRIER_CONSTANT_BUFFER)
> > rctx->b.flags |= R600_CONTEXT_INV_CONST_CACHE;
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_state.c
> > b/src/gallium/drivers/radeonsi/si_state.c
> > index 458b108a7e3..3c29b4c92ed 100644
> > --- a/src/gallium/drivers/radeonsi/si_state.c
> > +++ b/src/gallium/drivers/radeonsi/si_state.c
> > @@ -4710,6 +4710,9 @@ void si_memory_barrier(struct pipe_context *ctx,
> > unsigned flags)
> > {
> > struct si_context *sctx = (struct si_context *)ctx;
> >
> > + if (!(flags & ~PIPE_BARRIER_UPDATE))
> > + return;
> > +
> > /* Subsequent commands must wait for all shader invocations to
> > * complete. */
> > sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
> > diff --git
[Mesa-dev] [PATCH] docs: try to improve the Meson documentation
Add new Introduction and Advanced Usage sections. Spell out a few more details, like "ninja install". Improve the layout around example commands. Fix grammatical errors and tighten up the text. Explain the --prefix option. --- docs/contents.html | 2 +- docs/meson.html| 138 +++-- 2 files changed, 104 insertions(+), 36 deletions(-) diff --git a/docs/contents.html b/docs/contents.html index 6364776..619ac3d 100644 --- a/docs/contents.html +++ b/docs/contents.html @@ -42,8 +42,8 @@ Downloading / Unpacking Compiling / Installing -Autoconf Meson +Autoconf (deprecated) Precompiled Libraries diff --git a/docs/meson.html b/docs/meson.html index f21479c..f9ae669 100644 --- a/docs/meson.html +++ b/docs/meson.html @@ -17,65 +17,98 @@ Compilation and Installation using Meson + Introduction Basic Usage + Advanced Usage Cross-compilation and 32-bit builds -1. Basic Usage +1. Introduction -The Meson build system is generally considered stable and ready -for production +For general information about Meson see the +http://mesonbuild.com/;>Meson website. -The meson build is tested on Linux, macOS, Cygwin and Haiku, FreeBSD, +Mesa's Meson build system is generally considered stable and ready +for production. + +The Meson build of Mesa is tested on Linux, macOS, Cygwin and Haiku, FreeBSD, DragonflyBSD, NetBSD, and should work on OpenBSD. +If Meson is not already installed on your system, you can typically +install it with your package installer. For example: + +sudo apt-get install meson # Ubuntu + +or + +sudo dnf install meson # Fedora + + Mesa requires Meson >= 0.45.0 to build. Some older versions of meson do not check that they are too old and will error out in odd ways. +You'll also need https://ninja-build.org/;>Ninja. +If it's not already installed, use apt-get or dnf to install +the ninja-build package. + + +2. Basic Usage + The meson program is used to configure the source directory and generates either a ninja build file or Visual Studio® build files. The latter must -be enabled via the --backend switch, as ninja is the default backend on all -operating systems. Meson only supports out-of-tree builds, and must be passed a +be enabled via the --backend switch, as ninja is the default +backend on all +operating systems. + + + +Meson only supports out-of-tree builds, and must be passed a directory to put built and generated sources into. We'll call that directory -"build" for examples. +"build" here. +Basic configuration is done with: + -meson build/ +meson build/ -To see a description of your options you can run meson configure -along with a build directory to view the selected options for. This will show -your meson global arguments and project arguments, along with their defaults -and your local settings. +This will create the build directory. +If any dependencies are missing, you can install them, or try to remove +the dependency with a Meson configuration option (see below). + + + +To review the options which Meson chose, run: + +meson configure build/ + -Meson does not currently support listing options before configure a build -directory, but this feature is being discussed upstream. +Meson does not currently support listing configuration options before +running "meson build/" but this feature is being discussed upstream. For now, we have a bin/meson-options.py script that prints the options for you. If that script doesn't work for some reason, you can always look in the meson_options.txt file at the root of the project. - -meson configure build/ - - -With additional arguments meson configure is used to change -options on already configured build directory. All options passed to this -command are in the form -D "command"="value". +With additional arguments meson configure can be used to change +options for a previously configured build directory. +All options passed to this command are in the form +-D "command"="value". +For example: -meson configure build/ -Dprefix=/tmp/install -Dglx=true +meson configure build/ -Dprefix=/tmp/install -Dglx=true @@ -88,33 +121,68 @@ and brackets to represent an empty list (-D platforms=[]). Once you've run the initial meson command successfully you can use -your configured backend to build the project. With ninja, the -C option can be -be used to point at a directory to build. +your configured backend to build the project in your build directory: + + + +ninja -C build/ + + + +The next step is to install the Mesa libraries, drivers, etc. +This also finishes up some final steps of the build process (such as creating +symbolic links for drivers). To install: -ninja -C build/ +ninja -C build/ install -Without arguments, it will produce libGL.so and/or several other libraries -depending on the options you have chosen. Later, if you want to rebuild for a +Later, if you want to rebuild
[Mesa-dev] [Bug 109656] duplicate symbol _compute_shader_video_buffer
https://bugs.freedesktop.org/show_bug.cgi?id=109656
Vinson Lee changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #1 from Vinson Lee ---
commit 2bd08b8b9de9b10ecad5b808f56af2aa1bb8e007
Author: Vinson Lee
Date: Mon Feb 18 19:27:27 2019 -0800
gallium/auxiliary/vl: Fix duplicate symbol build errors.
CXXLDgallium_dri.la
duplicate symbol _compute_shader_video_buffer in:
../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor.o)
../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor_cs.o)
duplicate symbol _compute_shader_weave in:
../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor.o)
../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor_cs.o)
duplicate symbol _compute_shader_rgba in:
../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor.o)
../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor_cs.o)
Fixes: 9364d66cb7f7 ("gallium/auxiliary/vl: Add video compositor compute
shader render")
Signed-off-by: Vinson Lee
Reviewed-by: Emil Velikov
Reviewed-by: James Zhu
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] svga: remove SVGA_RELOC_READ flag in SVGA3D_BindGBSurface()
This fixes a rendering issue where UBO updates aren't always picked up by drawing calls. This issue effected the Webots robotics simulator. VMware bug 2175527. Testing Done: Webots replay, piglit, misc Linux games --- src/gallium/drivers/svga/svga_cmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/svga/svga_cmd.c b/src/gallium/drivers/svga/svga_cmd.c index 5557d20..6577c83 100644 --- a/src/gallium/drivers/svga/svga_cmd.c +++ b/src/gallium/drivers/svga/svga_cmd.c @@ -1693,7 +1693,7 @@ SVGA3D_BindGBSurface(struct svga_winsys_context *swc, return PIPE_ERROR_OUT_OF_MEMORY; swc->surface_relocation(swc, >sid, >mobid, surface, - SVGA_RELOC_READ | SVGA_RELOC_INTERNAL); + SVGA_RELOC_READ); swc->commit(swc); -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] svga: refactor draw_vgpu10() function
Looks good to me.
Just one nit pick,
In definition of validate_index_buffer, extra space is required in argument
list.
Reviewed-by: Neha Bhende
Regards,
Neha
Regards,
Neha
From: Brian Paul
Sent: Thursday, March 7, 2019 3:23 PM
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende
Subject: [PATCH] svga: refactor draw_vgpu10() function
The draw_vgpu10() function was huge. Move the code for preparing the
vertex buffers and the index buffer into separate functions.
---
src/gallium/drivers/svga/svga_draw.c | 246 ---
1 file changed, 141 insertions(+), 105 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_draw.c
b/src/gallium/drivers/svga/svga_draw.c
index 649bc22..a358170 100644
--- a/src/gallium/drivers/svga/svga_draw.c
+++ b/src/gallium/drivers/svga/svga_draw.c
@@ -507,62 +507,25 @@ vertex_buffers_equal(unsigned count,
}
+/*
+ * Prepare the vertex buffers for a drawing command.
+ */
static enum pipe_error
-draw_vgpu10(struct svga_hwtnl *hwtnl,
-const SVGA3dPrimitiveRange *range,
-unsigned vcount,
-struct pipe_resource *ib,
-unsigned start_instance, unsigned instance_count)
+validate_vertex_buffers(struct svga_hwtnl *hwtnl)
{
struct svga_context *svga = hwtnl->svga;
struct pipe_resource *vbuffers[SVGA3D_INPUTREG_MAX];
struct svga_winsys_surface *vbuffer_handles[SVGA3D_INPUTREG_MAX];
- struct svga_winsys_surface *ib_handle;
const unsigned vbuf_count = hwtnl->cmd.vbuf_count;
int last_vbuf = -1;
- enum pipe_error ret;
unsigned i;
assert(svga_have_vgpu10(svga));
- assert(hwtnl->cmd.prim_count == 0);
-
- /* We need to reemit all the current resource bindings along with the Draw
-* command to be sure that the referenced resources are available for the
-* Draw command, just in case the surfaces associated with the resources
-* are paged out.
-*/
- if (svga->rebind.val) {
- ret = svga_rebind_framebuffer_bindings(svga);
- if (ret != PIPE_OK)
- return ret;
-
- ret = svga_rebind_shaders(svga);
- if (ret != PIPE_OK)
- return ret;
-
- /* Rebind stream output targets */
- ret = svga_rebind_stream_output_targets(svga);
- if (ret != PIPE_OK)
- return ret;
-
- /* No need to explicitly rebind index buffer and vertex buffers here.
- * Even if the same index buffer or vertex buffers are referenced for
this
- * draw and we skip emitting the redundant set command, we will still
- * reference the associated resources.
- */
- }
-
- ret = validate_sampler_resources(svga);
- if (ret != PIPE_OK)
- return ret;
-
- ret = validate_constant_buffers(svga);
- if (ret != PIPE_OK)
- return ret;
/* Get handle for each referenced vertex buffer */
for (i = 0; i < vbuf_count; i++) {
- struct svga_buffer *sbuf =
svga_buffer(hwtnl->cmd.vbufs[i].buffer.resource);
+ struct svga_buffer *sbuf =
+ svga_buffer(hwtnl->cmd.vbufs[i].buffer.resource);
if (sbuf) {
vbuffer_handles[i] = svga_buffer_handle(svga, >b.b,
@@ -584,25 +547,11 @@ draw_vgpu10(struct svga_hwtnl *hwtnl,
vbuffer_handles[i] = NULL;
}
- /* Get handle for the index buffer */
- if (ib) {
- struct svga_buffer *sbuf = svga_buffer(ib);
-
- ib_handle = svga_buffer_handle(svga, ib, PIPE_BIND_INDEX_BUFFER);
- if (!ib_handle)
- return PIPE_ERROR_OUT_OF_MEMORY;
-
- assert(sbuf->key.flags & SVGA3D_SURFACE_BIND_INDEX_BUFFER);
- (void) sbuf; /* silence unused var warning */
- }
- else {
- ib_handle = NULL;
- }
-
/* setup vertex attribute input layout */
if (svga->state.hw_draw.layout_id != hwtnl->cmd.vdecl_layout_id) {
- ret = SVGA3D_vgpu10_SetInputLayout(svga->swc,
- hwtnl->cmd.vdecl_layout_id);
+ enum pipe_error ret =
+ SVGA3D_vgpu10_SetInputLayout(svga->swc,
+ hwtnl->cmd.vdecl_layout_id);
if (ret != PIPE_OK)
return ret;
@@ -658,14 +607,13 @@ draw_vgpu10(struct svga_hwtnl *hwtnl,
* corresponding entries in the device's vertex buffer list.
*/
for (i = 0; i < num_vbuffers; i++) {
- boolean emit;
-
- emit = vertex_buffers_equal(1,
- _attrs[i],
- [i],
-
>state.hw_draw.vbuffer_attrs[i],
- >state.hw_draw.vbuffers[i]);
-
+ boolean emit =
+ vertex_buffers_equal(1,
+ _attrs[i],
+ [i],
+ >state.hw_draw.vbuffer_attrs[i],
+ >state.hw_draw.vbuffers[i]);
+
if
Re: [Mesa-dev] [PATCH] gallium: Add PIPE_BARRIER_UPDATE_BUFFER and UPDATE_TEXTURE bits.
Hey Ilia, Marek,
Do you have an opinion about this? I've got a R-b from Eric Anholt
and what sounds like an Ack from Roland, but I wanted to make sure
everyone was OK with this before landing it.
--Ken
On Wednesday, March 6, 2019 12:32:23 AM PST Kenneth Graunke wrote:
> The glMemoryBarrier() function makes shader memory stores ordered with
> respect to things specified by the given bits. Until now, st/mesa has
> ignored GL_TEXTURE_UPDATE_BARRIER_BIT and GL_BUFFER_UPDATE_BARRIER_BIT,
> saying that drivers should implicitly perform the needed flushing.
>
> This seems like a pretty big assumption to make. Instead, this commit
> opts to translate them to new PIPE_BARRIER bits, and adjusts existing
> drivers to continue ignoring them (preserving the current behavior).
>
> The i965 driver performs actions on these memory barriers. Shader
> memory stores go through a "data cache" which is separate from the
> render cache and other read caches (like the texture cache). All
> memory barriers need to flush the data cache (to ensure shader memory
> stores are visible), and possibly invalidate read caches (to ensure
> stale data is no longer visible). The driver implicitly flushes for
> most caches, but not for data cache, since ARB_shader_image_load_store
> introduced MemoryBarrier() precisely to order these explicitly.
>
> I would like to follow i965's approach in iris, flushing the data cache
> on any MemoryBarrier() call, so I need st/mesa to actually call the
> pipe->memory_barrier() callback.
> ---
> .../drivers/freedreno/freedreno_context.c | 3 ++
> src/gallium/drivers/r600/r600_state_common.c | 4 +++
> src/gallium/drivers/radeonsi/si_state.c | 3 ++
> src/gallium/drivers/softpipe/sp_flush.c | 3 ++
> src/gallium/drivers/tegra/tegra_context.c | 3 ++
> src/gallium/drivers/v3d/v3d_context.c | 3 ++
> src/gallium/include/pipe/p_defines.h | 7 +++-
> src/mesa/state_tracker/st_cb_texturebarrier.c | 34 +++
> 8 files changed, 44 insertions(+), 16 deletions(-)
>
> I am curious to hear people's thoughts on this. It seems useful for the
> driver to receive a memory_barrier() call...and adding a few bits seemed
> to be the cleanest way to make that happen. But I'm open to ideas.
>
> There are no nouveau changes in this patch, but that's only because none
> appeared to be necessary. Most drivers performed some kind of flush on
> any memory_barrier() call, regardless of the bits - but nouveau's hooks
> don't. So the newly added case would already be a no-op.
>
> diff --git a/src/gallium/drivers/freedreno/freedreno_context.c
> b/src/gallium/drivers/freedreno/freedreno_context.c
> index 6c01c15bb32..4e86d099974 100644
> --- a/src/gallium/drivers/freedreno/freedreno_context.c
> +++ b/src/gallium/drivers/freedreno/freedreno_context.c
> @@ -99,6 +99,9 @@ fd_texture_barrier(struct pipe_context *pctx, unsigned
> flags)
> static void
> fd_memory_barrier(struct pipe_context *pctx, unsigned flags)
> {
> + if (!(flags & ~PIPE_BARRIER_UPDATE))
> + return;
> +
> fd_context_flush(pctx, NULL, 0);
> /* TODO do we need to check for persistently mapped buffers and
> fd_bo_cpu_prep()?? */
> }
> diff --git a/src/gallium/drivers/r600/r600_state_common.c
> b/src/gallium/drivers/r600/r600_state_common.c
> index f886a27170d..c7c606f131b 100644
> --- a/src/gallium/drivers/r600/r600_state_common.c
> +++ b/src/gallium/drivers/r600/r600_state_common.c
> @@ -94,6 +94,10 @@ void r600_emit_alphatest_state(struct r600_context *rctx,
> struct r600_atom *atom
> static void r600_memory_barrier(struct pipe_context *ctx, unsigned flags)
> {
> struct r600_context *rctx = (struct r600_context *)ctx;
> +
> + if (!(flags & ~PIPE_BARRIER_UPDATE))
> + return;
> +
> if (flags & PIPE_BARRIER_CONSTANT_BUFFER)
> rctx->b.flags |= R600_CONTEXT_INV_CONST_CACHE;
>
> diff --git a/src/gallium/drivers/radeonsi/si_state.c
> b/src/gallium/drivers/radeonsi/si_state.c
> index 458b108a7e3..3c29b4c92ed 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -4710,6 +4710,9 @@ void si_memory_barrier(struct pipe_context *ctx,
> unsigned flags)
> {
> struct si_context *sctx = (struct si_context *)ctx;
>
> + if (!(flags & ~PIPE_BARRIER_UPDATE))
> + return;
> +
> /* Subsequent commands must wait for all shader invocations to
>* complete. */
> sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
> diff --git a/src/gallium/drivers/softpipe/sp_flush.c
> b/src/gallium/drivers/softpipe/sp_flush.c
> index 3bf8c499218..5eccbe34d46 100644
> --- a/src/gallium/drivers/softpipe/sp_flush.c
> +++ b/src/gallium/drivers/softpipe/sp_flush.c
> @@ -192,5 +192,8 @@ void softpipe_texture_barrier(struct pipe_context *pipe,
> unsigned flags)
>
> void softpipe_memory_barrier(struct pipe_context *pipe, unsigned flags)
> {
> + if (!(flags &
[Mesa-dev] [PATCH] svga: refactor draw_vgpu10() function
The draw_vgpu10() function was huge. Move the code for preparing the
vertex buffers and the index buffer into separate functions.
---
src/gallium/drivers/svga/svga_draw.c | 246 ---
1 file changed, 141 insertions(+), 105 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_draw.c
b/src/gallium/drivers/svga/svga_draw.c
index 649bc22..a358170 100644
--- a/src/gallium/drivers/svga/svga_draw.c
+++ b/src/gallium/drivers/svga/svga_draw.c
@@ -507,62 +507,25 @@ vertex_buffers_equal(unsigned count,
}
+/*
+ * Prepare the vertex buffers for a drawing command.
+ */
static enum pipe_error
-draw_vgpu10(struct svga_hwtnl *hwtnl,
-const SVGA3dPrimitiveRange *range,
-unsigned vcount,
-struct pipe_resource *ib,
-unsigned start_instance, unsigned instance_count)
+validate_vertex_buffers(struct svga_hwtnl *hwtnl)
{
struct svga_context *svga = hwtnl->svga;
struct pipe_resource *vbuffers[SVGA3D_INPUTREG_MAX];
struct svga_winsys_surface *vbuffer_handles[SVGA3D_INPUTREG_MAX];
- struct svga_winsys_surface *ib_handle;
const unsigned vbuf_count = hwtnl->cmd.vbuf_count;
int last_vbuf = -1;
- enum pipe_error ret;
unsigned i;
assert(svga_have_vgpu10(svga));
- assert(hwtnl->cmd.prim_count == 0);
-
- /* We need to reemit all the current resource bindings along with the Draw
-* command to be sure that the referenced resources are available for the
-* Draw command, just in case the surfaces associated with the resources
-* are paged out.
-*/
- if (svga->rebind.val) {
- ret = svga_rebind_framebuffer_bindings(svga);
- if (ret != PIPE_OK)
- return ret;
-
- ret = svga_rebind_shaders(svga);
- if (ret != PIPE_OK)
- return ret;
-
- /* Rebind stream output targets */
- ret = svga_rebind_stream_output_targets(svga);
- if (ret != PIPE_OK)
- return ret;
-
- /* No need to explicitly rebind index buffer and vertex buffers here.
- * Even if the same index buffer or vertex buffers are referenced for
this
- * draw and we skip emitting the redundant set command, we will still
- * reference the associated resources.
- */
- }
-
- ret = validate_sampler_resources(svga);
- if (ret != PIPE_OK)
- return ret;
-
- ret = validate_constant_buffers(svga);
- if (ret != PIPE_OK)
- return ret;
/* Get handle for each referenced vertex buffer */
for (i = 0; i < vbuf_count; i++) {
- struct svga_buffer *sbuf =
svga_buffer(hwtnl->cmd.vbufs[i].buffer.resource);
+ struct svga_buffer *sbuf =
+ svga_buffer(hwtnl->cmd.vbufs[i].buffer.resource);
if (sbuf) {
vbuffer_handles[i] = svga_buffer_handle(svga, >b.b,
@@ -584,25 +547,11 @@ draw_vgpu10(struct svga_hwtnl *hwtnl,
vbuffer_handles[i] = NULL;
}
- /* Get handle for the index buffer */
- if (ib) {
- struct svga_buffer *sbuf = svga_buffer(ib);
-
- ib_handle = svga_buffer_handle(svga, ib, PIPE_BIND_INDEX_BUFFER);
- if (!ib_handle)
- return PIPE_ERROR_OUT_OF_MEMORY;
-
- assert(sbuf->key.flags & SVGA3D_SURFACE_BIND_INDEX_BUFFER);
- (void) sbuf; /* silence unused var warning */
- }
- else {
- ib_handle = NULL;
- }
-
/* setup vertex attribute input layout */
if (svga->state.hw_draw.layout_id != hwtnl->cmd.vdecl_layout_id) {
- ret = SVGA3D_vgpu10_SetInputLayout(svga->swc,
- hwtnl->cmd.vdecl_layout_id);
+ enum pipe_error ret =
+ SVGA3D_vgpu10_SetInputLayout(svga->swc,
+ hwtnl->cmd.vdecl_layout_id);
if (ret != PIPE_OK)
return ret;
@@ -658,14 +607,13 @@ draw_vgpu10(struct svga_hwtnl *hwtnl,
* corresponding entries in the device's vertex buffer list.
*/
for (i = 0; i < num_vbuffers; i++) {
- boolean emit;
-
- emit = vertex_buffers_equal(1,
- _attrs[i],
- [i],
-
>state.hw_draw.vbuffer_attrs[i],
- >state.hw_draw.vbuffers[i]);
-
+ boolean emit =
+ vertex_buffers_equal(1,
+ _attrs[i],
+ [i],
+ >state.hw_draw.vbuffer_attrs[i],
+ >state.hw_draw.vbuffers[i]);
+
if (!emit && i == num_vbuffers-1) {
/* Include the last vertex buffer in the next emit
* if it is different.
@@ -681,10 +629,11 @@ draw_vgpu10(struct svga_hwtnl *hwtnl,
* In this case, there is nothing to send yet.
*/
if (numVBuf) {
-
[Mesa-dev] [Bug 109929] tgsi_to_nir.c:2111: undefined reference to `gl_nir_lower_samplers_as_deref'
https://bugs.freedesktop.org/show_bug.cgi?id=109929 Bug ID: 109929 Summary: tgsi_to_nir.c:2111: undefined reference to `gl_nir_lower_samplers_as_deref' Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Keywords: regression Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: v...@freedesktop.org QA Contact: mesa-dev@lists.freedesktop.org autotools build error CXXLDpipe_msm.la /usr/bin/ld: ../../../../src/gallium/auxiliary/.libs/libgallium.a(tgsi_to_nir.o): in function `ttn_finalize_nir': src/gallium/auxiliary/nir/tgsi_to_nir.c:2111: undefined reference to `gl_nir_lower_samplers_as_deref' /usr/bin/ld: src/gallium/auxiliary/nir/tgsi_to_nir.c:2113: undefined reference to `gl_nir_lower_samplers' -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] st/nine: Do not advertise CANMANAGERESOURCE
It doesn't seem the main vendors advertise it. Signed-off-by: Axel Davy --- src/gallium/state_trackers/nine/adapter9.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/nine/adapter9.c b/src/gallium/state_trackers/nine/adapter9.c index 0634d5918ce..94a5d8d2aa3 100644 --- a/src/gallium/state_trackers/nine/adapter9.c +++ b/src/gallium/state_trackers/nine/adapter9.c @@ -547,7 +547,7 @@ NineAdapter9_GetDeviceCaps( struct NineAdapter9 *This, pCaps->Caps = 0; -pCaps->Caps2 = D3DCAPS2_CANMANAGERESOURCE | +pCaps->Caps2 = /* D3DCAPS2_CANMANAGERESOURCE | */ /* D3DCAPS2_CANSHARERESOURCE | */ /* D3DCAPS2_CANCALIBRATEGAMMA | */ D3DCAPS2_DYNAMICTEXTURES | -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] st/nine: Change a few advertised caps
Most hw on the native platform advertise these caps this way. D3DCAPS_READ_SCANLINE: We don't really have hardware support for that, but many games don't even check the flag, and expect GetRasterStatus to work, which is why we emulated it with a timer (like wine). So we may as well advertise the cap. D3DCURSORCAPS_LOWRES: I don't know what is the status of this on X11, but I don't know of any dx9 game running at height < 400 either. D3DPTEXTURECAPS_TEXREPEATNOTSCALEDBYSIZE: The cap should correspond to what the current generation of hw is doing. Signed-off-by: Axel Davy --- include/D3D9/d3d9caps.h| 3 +++ src/gallium/state_trackers/nine/adapter9.c | 6 +++--- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/include/D3D9/d3d9caps.h b/include/D3D9/d3d9caps.h index 0cce5d3f689..70f9919c53d 100644 --- a/include/D3D9/d3d9caps.h +++ b/include/D3D9/d3d9caps.h @@ -26,6 +26,9 @@ #include "d3d9types.h" /* Caps flags */ +#define D3DCAPS_OVERLAY 0x0800 +#define D3DCAPS_READ_SCANLINE 0x0002 + #define D3DCAPS2_FULLSCREENGAMMA 0x0002 #define D3DCAPS2_CANCALIBRATEGAMMA 0x0010 #define D3DCAPS2_RESERVED 0x0200 diff --git a/src/gallium/state_trackers/nine/adapter9.c b/src/gallium/state_trackers/nine/adapter9.c index 94a5d8d2aa3..3aa95b93b2f 100644 --- a/src/gallium/state_trackers/nine/adapter9.c +++ b/src/gallium/state_trackers/nine/adapter9.c @@ -545,7 +545,7 @@ NineAdapter9_GetDeviceCaps( struct NineAdapter9 *This, pCaps->AdapterOrdinal = 0; -pCaps->Caps = 0; +pCaps->Caps = D3DCAPS_READ_SCANLINE; pCaps->Caps2 = /* D3DCAPS2_CANMANAGERESOURCE | */ /* D3DCAPS2_CANSHARERESOURCE | */ @@ -568,7 +568,7 @@ NineAdapter9_GetDeviceCaps( struct NineAdapter9 *This, D3DPRESENT_INTERVAL_THREE | D3DPRESENT_INTERVAL_FOUR | D3DPRESENT_INTERVAL_IMMEDIATE; -pCaps->CursorCaps = D3DCURSORCAPS_COLOR | D3DCURSORCAPS_LOWRES; +pCaps->CursorCaps = D3DCURSORCAPS_COLOR /* | D3DCURSORCAPS_LOWRES*/; pCaps->DevCaps = D3DDEVCAPS_CANBLTSYSTONONLOCAL | D3DDEVCAPS_CANRENDERAFTERFLIP | @@ -678,7 +678,7 @@ NineAdapter9_GetDeviceCaps( struct NineAdapter9 *This, D3DPTEXTURECAPS_ALPHAPALETTE | D3DPTEXTURECAPS_PERSPECTIVE | D3DPTEXTURECAPS_PROJECTED | -/*D3DPTEXTURECAPS_TEXREPEATNOTSCALEDBYSIZE |*/ +D3DPTEXTURECAPS_TEXREPEATNOTSCALEDBYSIZE | D3DPTEXTURECAPS_CUBEMAP | D3DPTEXTURECAPS_VOLUMEMAP | D3DNPIPECAP(NPOT_TEXTURES, D3DPTEXTURECAPS_POW2) | -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] d3dadapter9: Support software renderer on any DRI device
From: Patrick Rudolph
If D3D_ALWAYS_SOFTWARE is set for debugging purposes,
run on any DRI enabled platform.
Instead of probing for a compatible gallium driver (which might
fail if there's none) always use the KMS DRI software renderer.
Allows to run nine on i915 when D3D_ALWAYS_SOFTWARE=1.
Signed-off-by: Patrick Rudolph
---
src/gallium/targets/d3dadapter9/drm.c | 28 +++
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/src/gallium/targets/d3dadapter9/drm.c
b/src/gallium/targets/d3dadapter9/drm.c
index 1d01d4a067c..28dbd2ef9db 100644
--- a/src/gallium/targets/d3dadapter9/drm.c
+++ b/src/gallium/targets/d3dadapter9/drm.c
@@ -205,6 +205,7 @@ drm_create_adapter( int fd,
struct d3dadapter9drm_context *ctx = CALLOC_STRUCT(d3dadapter9drm_context);
HRESULT hr;
bool different_device;
+bool software_device;
const struct drm_conf_ret *throttle_ret = NULL;
const struct drm_conf_ret *dmabuf_ret = NULL;
driOptionCache defaultInitOptions;
@@ -222,7 +223,11 @@ drm_create_adapter( int fd,
ctx->fd = fd;
ctx->base.linear_framebuffer = different_device;
-if (!pipe_loader_drm_probe_fd(>dev, fd)) {
+const char *force_sw = getenv("D3D_ALWAYS_SOFTWARE");
+software_device = force_sw && !strcmp(force_sw, "1");
+
+if ((software_device && !pipe_loader_sw_probe_kms(>dev, fd)) ||
+(!software_device && !pipe_loader_drm_probe_fd(>dev, fd))) {
ERR("Failed to probe drm fd %d.\n", fd);
FREE(ctx);
close(fd);
@@ -236,13 +241,20 @@ drm_create_adapter( int fd,
return D3DERR_DRIVERINTERNALERROR;
}
-dmabuf_ret = pipe_loader_configuration(ctx->dev, DRM_CONF_SHARE_FD);
-throttle_ret = pipe_loader_configuration(ctx->dev, DRM_CONF_THROTTLE);
-if (!dmabuf_ret || !dmabuf_ret->val.val_bool) {
-ERR("The driver is not capable of dma-buf sharing."
-"Abandon to load nine state tracker\n");
-drm_destroy(>base);
-return D3DERR_DRIVERINTERNALERROR;
+if (!software_device) {
+/*
+ * The software renderer isn't a DRM device and doesn't support
+ * pipe_loader_configuration.
+ * The KMS winsys supports SHARE_FD, so skip this check.
+ */
+dmabuf_ret = pipe_loader_configuration(ctx->dev, DRM_CONF_SHARE_FD);
+throttle_ret = pipe_loader_configuration(ctx->dev, DRM_CONF_THROTTLE);
+if (!dmabuf_ret || !dmabuf_ret->val.val_bool) {
+ERR("The driver is not capable of dma-buf sharing."
+"Abandon to load nine state tracker\n");
+drm_destroy(>base);
+return D3DERR_DRIVERINTERNALERROR;
+}
}
if (throttle_ret && throttle_ret->val.val_int != -1) {
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] st/nine: Disable depth write when nothing gets updated
I do not see any perf impact on radeonsi, but it
seems iris needs this.
It seems something sensible to do.
Signed-off-by: Axel Davy
Reviewed-by: Timur Kristóf
Tested-by: Andre Heider
---
It may be argued this kind of stuff should be done in the driver.
I don't mind either way. The ogl state tracker already does that
optimization.
src/gallium/state_trackers/nine/nine_pipe.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/nine/nine_pipe.c
b/src/gallium/state_trackers/nine/nine_pipe.c
index a84a17f551f..b69ddb67113 100644
--- a/src/gallium/state_trackers/nine/nine_pipe.c
+++ b/src/gallium/state_trackers/nine/nine_pipe.c
@@ -36,8 +36,11 @@ nine_convert_dsa_state(struct pipe_depth_stencil_alpha_state
*dsa_state,
if (rs[D3DRS_ZENABLE]) {
dsa.depth.enabled = 1;
-dsa.depth.writemask = !!rs[D3DRS_ZWRITEENABLE];
dsa.depth.func = d3dcmpfunc_to_pipe_func(rs[D3DRS_ZFUNC]);
+/* Disable depth write if no change can occur */
+dsa.depth.writemask = !!rs[D3DRS_ZWRITEENABLE] &&
+dsa.depth.func != PIPE_FUNC_EQUAL &&
+dsa.depth.func != PIPE_FUNC_NEVER;
}
if (rs[D3DRS_STENCILENABLE]) {
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] st/nine: Do not advertise support for D15S1 and D24X4S4
The former is supported on Matrox cards but no other hw. The latter isn't supported anywhere. It is fine to not advertise them as supported, and it could prevent apps to trigger weird rendering paths. Signed-off-by: Axel Davy --- src/gallium/state_trackers/nine/nine_pipe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/state_trackers/nine/nine_pipe.c b/src/gallium/state_trackers/nine/nine_pipe.c index b69ddb67113..dd858aef743 100644 --- a/src/gallium/state_trackers/nine/nine_pipe.c +++ b/src/gallium/state_trackers/nine/nine_pipe.c @@ -286,10 +286,10 @@ const enum pipe_format nine_d3d9_to_pipe_format_map[120] = [D3DFMT_A2W10V10U10] = PIPE_FORMAT_R10SG10SB10SA2U_NORM, [D3DFMT_D16_LOCKABLE] = PIPE_FORMAT_Z16_UNORM, [D3DFMT_D32] = PIPE_FORMAT_Z32_UNORM, - [D3DFMT_D15S1] = PIPE_FORMAT_Z24_UNORM_S8_UINT, + [D3DFMT_D15S1] = PIPE_FORMAT_NONE, [D3DFMT_D24S8] = PIPE_FORMAT_S8_UINT_Z24_UNORM, [D3DFMT_D24X8] = PIPE_FORMAT_X8Z24_UNORM, - [D3DFMT_D24X4S4] = PIPE_FORMAT_Z24_UNORM_S8_UINT, + [D3DFMT_D24X4S4] = PIPE_FORMAT_NONE, [D3DFMT_D16] = PIPE_FORMAT_Z16_UNORM, [D3DFMT_D32F_LOCKABLE] = PIPE_FORMAT_Z32_FLOAT, [D3DFMT_D24FS8]= PIPE_FORMAT_Z32_FLOAT_S8X24_UINT, -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir/serialize: Make preserving names optional
---
src/compiler/nir/nir_serialize.c | 56 ---
src/compiler/nir/nir_serialize.h | 3 +-
.../drivers/radeonsi/si_state_shaders.c | 2 +-
src/intel/vulkan/anv_pipeline_cache.c | 2 +-
.../drivers/dri/i965/brw_program_binary.c | 2 +-
src/mesa/state_tracker/st_shader_cache.c | 2 +-
6 files changed, 42 insertions(+), 25 deletions(-)
diff --git a/src/compiler/nir/nir_serialize.c b/src/compiler/nir/nir_serialize.c
index 743eeaed3d5..ad094beb1f4 100644
--- a/src/compiler/nir/nir_serialize.c
+++ b/src/compiler/nir/nir_serialize.c
@@ -42,6 +42,9 @@ typedef struct {
/* the next index to assign to a NIR in-memory object */
uintptr_t next_idx;
+ /* Whether or not to preserve variable and SSA def names */
+ bool preserve_names;
+
/* Array of write_phi_fixup structs representing phi sources that need to
* be resolved in the second pass.
*/
@@ -136,9 +139,13 @@ write_variable(write_ctx *ctx, const nir_variable *var)
{
write_add_object(ctx, var);
encode_type_to_blob(ctx->blob, var->type);
- blob_write_uint32(ctx->blob, !!(var->name));
- if (var->name)
- blob_write_string(ctx->blob, var->name);
+ if (ctx->preserve_names) {
+ blob_write_uint32(ctx->blob, !!(var->name));
+ if (var->name)
+ blob_write_string(ctx->blob, var->name);
+ } else {
+ blob_write_uint32(ctx->blob, 0);
+ }
blob_write_bytes(ctx->blob, (uint8_t *) >data, sizeof(var->data));
blob_write_uint32(ctx->blob, var->num_state_slots);
blob_write_bytes(ctx->blob, (uint8_t *) var->state_slots,
@@ -224,9 +231,13 @@ write_register(write_ctx *ctx, const nir_register *reg)
blob_write_uint32(ctx->blob, reg->bit_size);
blob_write_uint32(ctx->blob, reg->num_array_elems);
blob_write_uint32(ctx->blob, reg->index);
- blob_write_uint32(ctx->blob, !!(reg->name));
- if (reg->name)
- blob_write_string(ctx->blob, reg->name);
+ if (ctx->preserve_names) {
+ blob_write_uint32(ctx->blob, !!(reg->name));
+ if (reg->name)
+ blob_write_string(ctx->blob, reg->name);
+ } else {
+ blob_write_uint32(ctx->blob, 0);
+ }
blob_write_uint32(ctx->blob, reg->is_global << 1 | reg->is_packed);
}
@@ -327,7 +338,7 @@ write_dest(write_ctx *ctx, const nir_dest *dst)
{
uint32_t val = dst->is_ssa;
if (dst->is_ssa) {
- val |= !!(dst->ssa.name) << 1;
+ val |= (ctx->preserve_names && dst->ssa.name) << 1;
val |= dst->ssa.num_components << 2;
val |= dst->ssa.bit_size << 5;
} else {
@@ -336,7 +347,7 @@ write_dest(write_ctx *ctx, const nir_dest *dst)
blob_write_uint32(ctx->blob, val);
if (dst->is_ssa) {
write_add_object(ctx, >ssa);
- if (dst->ssa.name)
+ if (ctx->preserve_names && dst->ssa.name)
blob_write_string(ctx->blob, dst->ssa.name);
} else {
blob_write_intptr(ctx->blob, write_lookup_object(ctx, dst->reg.reg));
@@ -1079,28 +1090,33 @@ read_function(read_ctx *ctx)
}
void
-nir_serialize(struct blob *blob, const nir_shader *nir)
+nir_serialize(struct blob *blob, const nir_shader *nir, bool preserve_names)
{
write_ctx ctx;
ctx.remap_table = _mesa_pointer_hash_table_create(NULL);
ctx.next_idx = 0;
ctx.blob = blob;
ctx.nir = nir;
+ ctx.preserve_names = preserve_names;
util_dynarray_init(_fixups, NULL);
size_t idx_size_offset = blob_reserve_intptr(blob);
struct shader_info info = nir->info;
- uint32_t strings = 0;
- if (info.name)
- strings |= 0x1;
- if (info.label)
- strings |= 0x2;
- blob_write_uint32(blob, strings);
- if (info.name)
- blob_write_string(blob, info.name);
- if (info.label)
- blob_write_string(blob, info.label);
+ if (ctx.preserve_names) {
+ uint32_t strings = 0;
+ if (info.name)
+ strings |= 0x1;
+ if (info.label)
+ strings |= 0x2;
+ blob_write_uint32(blob, strings);
+ if (info.name)
+ blob_write_string(blob, info.name);
+ if (info.label)
+ blob_write_string(blob, info.label);
+ } else {
+ blob_write_uint32(blob, 0);
+ }
info.name = info.label = NULL;
blob_write_bytes(blob, (uint8_t *) , sizeof(info));
@@ -1204,7 +1220,7 @@ nir_shader_serialize_deserialize(void *mem_ctx,
nir_shader *s)
struct blob writer;
blob_init();
- nir_serialize(, s);
+ nir_serialize(, s, true);
ralloc_free(s);
struct blob_reader reader;
diff --git a/src/compiler/nir/nir_serialize.h b/src/compiler/nir/nir_serialize.h
index f77d8e367ff..22e5fa88ee1 100644
--- a/src/compiler/nir/nir_serialize.h
+++ b/src/compiler/nir/nir_serialize.h
@@ -31,7 +31,8 @@
extern "C" {
#endif
-void nir_serialize(struct blob *blob, const nir_shader *nir);
+void nir_serialize(struct blob *blob, const nir_shader *nir, bool
+ preserve_names);
nir_shader *nir_deserialize(void *mem_ctx,
const struct nir_shader_compiler_options
[Mesa-dev] [Bug 109927] Xorg segfault when a web browser is opened
https://bugs.freedesktop.org/show_bug.cgi?id=109927 --- Comment #4 from keiron.dav...@googlemail.com --- I found that the previously built .debs were available on launchpad, so I reverted packages to isolate. After rolling back xserver-xorg-video-amdgpu to the previously working version and rebooting there was no change to the problem behaviour. Next I reverted the updates to Mesa, where I ended up in dependency hell for not paying proper attention. After using my /var/log/apt/history.log to figure out which packages I needed, I made corrections, rebooted, and the problem behaviour is gone. So this change does seem to be located in Mesa after commit 6fa923a65daf1ee73c5cc763ade91abc82da7085. I will update xserver-xorg-video-amdgpu alone and see if that makes any change, but I doubt it. -- 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 #3 from keiron.dav...@googlemail.com --- (In reply to Michel Dänzer from comment #2) > Can you isolate whether it was the Mesa or xserver-xorg-video-amdgpu update > that triggered it? I'm not sure how I'd roll back either one, the PPA no longer has the old packages (I'll see if they're cached on disk). The only way I can conceive of is building them from git myself, but I suppose I'd have to be careful to use the same build options as the PPA (libs, llvm 9.0 etc.) Can you suggest which would be easier to build? There are a relatively small number of accepted commits between the updates, bisection should be possible, it's just not something I've ever done before. I've confirmed the same behaviour with kernel 4.20, just to make sure it wasn't a 5.0 bug that didn't present itself for a few days. Also, setting amdgpu.dc=1 as a kernel command line parameter allows me to launch Firefox and navigate here but then the same crash occurs when I interact with a dropdown menu. No difference in log output. -- 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] st/mesa: move, clean-up shader variant key decls/inits
Reviewed-by: Neha Bhende
Regards,
Neha
From: Brian Paul
Sent: Thursday, March 7, 2019 8:20 AM
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende
Subject: [PATCH] st/mesa: move, clean-up shader variant key decls/inits
Move the variant key declarations inside the scope they're used.
Use designated initializers instead of memset() calls.
---
src/mesa/state_tracker/st_atom_shader.c | 8
src/mesa/state_tracker/st_program.c | 9 +++--
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_shader.c
b/src/mesa/state_tracker/st_atom_shader.c
index c6faa3f..ac7a1a5 100644
--- a/src/mesa/state_tracker/st_atom_shader.c
+++ b/src/mesa/state_tracker/st_atom_shader.c
@@ -97,7 +97,6 @@ void
st_update_fp( struct st_context *st )
{
struct st_fragment_program *stfp;
- struct st_fp_variant_key key;
assert(st->ctx->FragmentProgram._Current);
stfp = st_fragment_program(st->ctx->FragmentProgram._Current);
@@ -113,7 +112,8 @@ st_update_fp( struct st_context *st )
!stfp->variants->key.bitmap) {
shader = stfp->variants->driver_shader;
} else {
- memset(, 0, sizeof(key));
+ struct st_fp_variant_key key = {0};
+
key.st = st->has_shareable_shaders ? NULL : st;
/* _NEW_FRAG_CLAMP */
@@ -155,7 +155,6 @@ void
st_update_vp( struct st_context *st )
{
struct st_vertex_program *stvp;
- struct st_vp_variant_key key;
/* find active shader and params -- Should be covered by
* ST_NEW_VERTEX_PROGRAM
@@ -169,7 +168,8 @@ st_update_vp( struct st_context *st )
stvp->variants->key.passthrough_edgeflags == st->vertdata_edgeflags) {
st->vp_variant = stvp->variants;
} else {
- memset(, 0, sizeof key);
+ struct st_vp_variant_key key = {0};
+
key.st = st->has_shareable_shaders ? NULL : st;
/* When this is true, we will add an extra input to the vertex
diff --git a/src/mesa/state_tracker/st_program.c
b/src/mesa/state_tracker/st_program.c
index c2daa4d..5e43a2e 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -1772,9 +1772,8 @@ st_get_cp_variant(struct st_context *st,
{
struct pipe_context *pipe = st->pipe;
struct st_basic_variant *v;
- struct st_basic_variant_key key;
+ struct st_basic_variant_key key = {0};
- memset(, 0, sizeof(key));
key.st = st->has_shareable_shaders ? NULL : st;
/* Search for existing variant */
@@ -1996,9 +1995,8 @@ st_precompile_shader_variant(struct st_context *st,
switch (prog->Target) {
case GL_VERTEX_PROGRAM_ARB: {
struct st_vertex_program *p = (struct st_vertex_program *)prog;
- struct st_vp_variant_key key;
+ struct st_vp_variant_key key = {0};
- memset(, 0, sizeof(key));
key.st = st->has_shareable_shaders ? NULL : st;
st_get_vp_variant(st, p, );
break;
@@ -2024,9 +2022,8 @@ st_precompile_shader_variant(struct st_context *st,
case GL_FRAGMENT_PROGRAM_ARB: {
struct st_fragment_program *p = (struct st_fragment_program *)prog;
- struct st_fp_variant_key key;
+ struct st_fp_variant_key key = {0};
- memset(, 0, sizeof(key));
key.st = st->has_shareable_shaders ? NULL : st;
st_get_fp_variant(st, p, );
break;
--
1.8.5.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir/builder: Emit better code for iadd/imul_imm
On Thu, Mar 07, 2019 at 11:34:50AM -0600, Jason Ekstrand wrote:
> Because we already know the immediate right-hand parameter, we can
> potentially save the optimizer a bit of work.
> ---
> src/compiler/nir/nir_builder.h | 25 +++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
Reviewed-by: Caio Marcelo de Oliveira Filho
There's a single case in
src/compiler/spirv/vtn_variables.c:^vtn_access_link_as_ssa
that does a check for != 1 before multiply. Maybe remove it too?
> diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
> index cd760c8d9ef..56e76ddcb39 100644
> --- a/src/compiler/nir/nir_builder.h
> +++ b/src/compiler/nir/nir_builder.h
> @@ -25,6 +25,7 @@
> #define NIR_BUILDER_H
>
> #include "nir_control_flow.h"
> +#include "util/bitscan.h"
> #include "util/half_float.h"
>
> struct exec_list;
> @@ -601,13 +602,33 @@ nir_u2u(nir_builder *build, nir_ssa_def *x, unsigned
> dest_bit_size)
> static inline nir_ssa_def *
> nir_iadd_imm(nir_builder *build, nir_ssa_def *x, uint64_t y)
> {
> - return nir_iadd(build, x, nir_imm_intN_t(build, y, x->bit_size));
> + assert(x->bit_size <= 64);
> + if (x->bit_size < 64)
> + y &= (1ull << x->bit_size) - 1;
> +
> + if (y == 0) {
> + return x;
> + } else {
> + return nir_iadd(build, x, nir_imm_intN_t(build, y, x->bit_size));
> + }
> }
>
> static inline nir_ssa_def *
> nir_imul_imm(nir_builder *build, nir_ssa_def *x, uint64_t y)
> {
> - return nir_imul(build, x, nir_imm_intN_t(build, y, x->bit_size));
> + assert(x->bit_size <= 64);
> + if (x->bit_size < 64)
> + y &= (1ull << x->bit_size) - 1;
> +
> + if (y == 0) {
> + return nir_imm_intN_t(build, 0, x->bit_size);
> + } else if (y == 1) {
> + return x;
> + } else if (util_is_power_of_two_or_zero64(y)) {
> + return nir_ishl(build, x, nir_imm_int(build, ffsll(y) - 1));
> + } else {
> + return nir_imul(build, x, nir_imm_intN_t(build, y, x->bit_size));
> + }
> }
>
> static inline nir_ssa_def *
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Caio
___
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 #2 from Michel Dänzer --- Can you isolate whether it was the Mesa or xserver-xorg-video-amdgpu update that triggered it? -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir/builder: Emit better code for iadd/imul_imm
Because we already know the immediate right-hand parameter, we can
potentially save the optimizer a bit of work.
---
src/compiler/nir/nir_builder.h | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
index cd760c8d9ef..56e76ddcb39 100644
--- a/src/compiler/nir/nir_builder.h
+++ b/src/compiler/nir/nir_builder.h
@@ -25,6 +25,7 @@
#define NIR_BUILDER_H
#include "nir_control_flow.h"
+#include "util/bitscan.h"
#include "util/half_float.h"
struct exec_list;
@@ -601,13 +602,33 @@ nir_u2u(nir_builder *build, nir_ssa_def *x, unsigned
dest_bit_size)
static inline nir_ssa_def *
nir_iadd_imm(nir_builder *build, nir_ssa_def *x, uint64_t y)
{
- return nir_iadd(build, x, nir_imm_intN_t(build, y, x->bit_size));
+ assert(x->bit_size <= 64);
+ if (x->bit_size < 64)
+ y &= (1ull << x->bit_size) - 1;
+
+ if (y == 0) {
+ return x;
+ } else {
+ return nir_iadd(build, x, nir_imm_intN_t(build, y, x->bit_size));
+ }
}
static inline nir_ssa_def *
nir_imul_imm(nir_builder *build, nir_ssa_def *x, uint64_t y)
{
- return nir_imul(build, x, nir_imm_intN_t(build, y, x->bit_size));
+ assert(x->bit_size <= 64);
+ if (x->bit_size < 64)
+ y &= (1ull << x->bit_size) - 1;
+
+ if (y == 0) {
+ return nir_imm_intN_t(build, 0, x->bit_size);
+ } else if (y == 1) {
+ return x;
+ } else if (util_is_power_of_two_or_zero64(y)) {
+ return nir_ishl(build, x, nir_imm_int(build, ffsll(y) - 1));
+ } else {
+ return nir_imul(build, x, nir_imm_intN_t(build, y, x->bit_size));
+ }
}
static inline nir_ssa_def *
--
2.20.1
___
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 Michel Dänzer changed: What|Removed |Added Attachment #143574|text/x-log |text/plain mime type|| -- 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 #1 from keiron.dav...@googlemail.com --- Created attachment 143575 --> https://bugs.freedesktop.org/attachment.cgi?id=143575=edit /home/usernaym/.local/share/xorg/Xorg.0.log.old & Xorg.0.log Here are the Xorg logs from the same Chromium crash. -- 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 Bug ID: 109927 Summary: Xorg segfault when a web browser is opened Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: keiron.dav...@googlemail.com QA Contact: mesa-dev@lists.freedesktop.org Created attachment 143574 --> https://bugs.freedesktop.org/attachment.cgi?id=143574=edit Output of journalctl -b I use the Padoka PPA. Approximately 45 hours ago, there was an update for Bionic that moved the Mesa version from 'master git branch up to commit 6fa923a65daf1ee73c5cc763ade91abc82da7085' to commit 43f40dc7cb234e007fe612b67cc765288ddf0533, and xserver-xorg-video-amdgpu from 'master git branch up to commit 9045fb310f88780e250e60b80431ca153330e61b' to commit a2b32e72fdaff3007a79b84929997d8176c2d512. No other changes have taken place in my system. Since then, within 1.5s of opening a web browser (Firefox, Chromium), I get a crash to graphical login prompt. I can open the Nautilus file browser, even a terminal session with transparency enabled, without issue for as long as I like. Below is the error message and my system specs, and attached are the relevant logfiles from a Chromium crash. Firefox crash produces no specific error messages prior to the segfault, but I can upload those logs too if needed. Apologies if this bug is incorrectly filed, I wasn't sure whether the issue may lie with mesa or xserver-xorg-video-amdgpu. Mar 07 15:35:07 host chromium-browser.desktop[3259]: [3293:3293:0307/153507.139737:ERROR:sandbox_linux.cc(364)] InitializeSandbox() called with multiple threads in process gpu-process. Mar 07 15:35:07 host gnome-keyring-daemon[1895]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk Mar 07 15:35:07 host gnome-keyring-daemon[1895]: asked to register item /org/freedesktop/secrets/collection/Default_5fkeyring/1, but it's already registered Mar 07 15:35:07 host gnome-keyring-daemon[1895]: asked to register item /org/freedesktop/secrets/collection/Default_5fkeyring/1, but it's already registered Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) Backtrace: Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4d) [0x5558457998cd] Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) 1: /usr/lib/xorg/Xorg (0x5558455e1000+0x1bc669) [0x55584579d669] Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7ffb48abe000+0x12890) [0x7ffb48ad0890] Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) Segmentation fault at address 0x0 Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: Fatal server error: Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) Caught signal 11 (Segmentation fault). Server aborting Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: Please consult the The X.Org Foundation support Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: at http://wiki.x.org Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: for help. Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) Please also check the log file at "/home/usernaym/.local/share/xorg/Xorg.0.log" for additional information. Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) System:Host: host Kernel: 5.0.0-05-generic x86_64 bits: 64 Desktop: Gnome 3.28.3 Distro: Ubuntu 18.04.2 LTS Machine: Device: desktop Mobo: ASUSTeK model: M4A87TD EVO v: Rev 1.xx serial: N/A BIOS: American Megatrends v: 2001 date: 03/08/2011 CPU: Quad core AMD Phenom II X4 970 Graphics: Card: Advanced Micro Devices [AMD/ATI] Hawaii PRO [Radeon R9 290/390] Display Server: x11 (X.Org 1.19.6 ) drivers: ati,vesa (unloaded: modesetting,fbdev,radeon) Resolution: 2560x1440@59.95hz OpenGL: renderer: AMD Radeon R9 390 Series (HAWAII, DRM 3.27.0, 5.0.0-05-generic, LLVM 9.0.0) version: 4.5 Mesa 19.1.0-devel - padoka PPA -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GraphicsFuzz 1.2 released
Hi all, We’re pleased to announce the release 1.2 of GraphicsFuzz, a testing framework for shader compilers which we think might be of interest to the Mesa community: https://github.com/google/graphicsfuzz/releases/tag/v1.2 Our how-it-works doc is a short recap of our testing approach: https://github.com/google/graphicsfuzz/blob/master/docs/glsl-fuzz-intro.md And the walkthrough doc is a step-by-step guide to try out the tools: https://github.com/google/graphicsfuzz/blob/master/docs/glsl-fuzz-walkthrough.md Please let us know if you have the opportunity to try out these tools, and do not hesitate to file bugs and enhancement ideas as GitHub issues! Thanks, -- Hugues Evrard Android Graphics Tools ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: move, clean-up shader variant key decls/inits
Move the variant key declarations inside the scope they're used.
Use designated initializers instead of memset() calls.
---
src/mesa/state_tracker/st_atom_shader.c | 8
src/mesa/state_tracker/st_program.c | 9 +++--
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_shader.c
b/src/mesa/state_tracker/st_atom_shader.c
index c6faa3f..ac7a1a5 100644
--- a/src/mesa/state_tracker/st_atom_shader.c
+++ b/src/mesa/state_tracker/st_atom_shader.c
@@ -97,7 +97,6 @@ void
st_update_fp( struct st_context *st )
{
struct st_fragment_program *stfp;
- struct st_fp_variant_key key;
assert(st->ctx->FragmentProgram._Current);
stfp = st_fragment_program(st->ctx->FragmentProgram._Current);
@@ -113,7 +112,8 @@ st_update_fp( struct st_context *st )
!stfp->variants->key.bitmap) {
shader = stfp->variants->driver_shader;
} else {
- memset(, 0, sizeof(key));
+ struct st_fp_variant_key key = {0};
+
key.st = st->has_shareable_shaders ? NULL : st;
/* _NEW_FRAG_CLAMP */
@@ -155,7 +155,6 @@ void
st_update_vp( struct st_context *st )
{
struct st_vertex_program *stvp;
- struct st_vp_variant_key key;
/* find active shader and params -- Should be covered by
* ST_NEW_VERTEX_PROGRAM
@@ -169,7 +168,8 @@ st_update_vp( struct st_context *st )
stvp->variants->key.passthrough_edgeflags == st->vertdata_edgeflags) {
st->vp_variant = stvp->variants;
} else {
- memset(, 0, sizeof key);
+ struct st_vp_variant_key key = {0};
+
key.st = st->has_shareable_shaders ? NULL : st;
/* When this is true, we will add an extra input to the vertex
diff --git a/src/mesa/state_tracker/st_program.c
b/src/mesa/state_tracker/st_program.c
index c2daa4d..5e43a2e 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -1772,9 +1772,8 @@ st_get_cp_variant(struct st_context *st,
{
struct pipe_context *pipe = st->pipe;
struct st_basic_variant *v;
- struct st_basic_variant_key key;
+ struct st_basic_variant_key key = {0};
- memset(, 0, sizeof(key));
key.st = st->has_shareable_shaders ? NULL : st;
/* Search for existing variant */
@@ -1996,9 +1995,8 @@ st_precompile_shader_variant(struct st_context *st,
switch (prog->Target) {
case GL_VERTEX_PROGRAM_ARB: {
struct st_vertex_program *p = (struct st_vertex_program *)prog;
- struct st_vp_variant_key key;
+ struct st_vp_variant_key key = {0};
- memset(, 0, sizeof(key));
key.st = st->has_shareable_shaders ? NULL : st;
st_get_vp_variant(st, p, );
break;
@@ -2024,9 +2022,8 @@ st_precompile_shader_variant(struct st_context *st,
case GL_FRAGMENT_PROGRAM_ARB: {
struct st_fragment_program *p = (struct st_fragment_program *)prog;
- struct st_fp_variant_key key;
+ struct st_fp_variant_key key = {0};
- memset(, 0, sizeof(key));
key.st = st->has_shareable_shaders ? NULL : st;
st_get_fp_variant(st, p, );
break;
--
1.8.5.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 108900] [KBL-G][Vulkan] Non-recoverable GPU hangs with GfxBench v5 Aztec Ruins Vulkan test
https://bugs.freedesktop.org/show_bug.cgi?id=108900 --- Comment #12 from Eero Tamminen --- (In reply to Samuel Pitoiset from comment #11) > First time I see a shader like that... > > Can you install spirv-dis and generate a new hang report, please? The SPIR-V > is probably useful too. Sorry, shortly after filing this bug, I stopped having extra time for 3D bugs. I'll still file bugs on larger issues I notice, and can verify the fixed ones, but not spend time investigating them (it would have helped if spirv-tools would have been available in Ubuntu :-/). -- 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 108900] [KBL-G][Vulkan] Non-recoverable GPU hangs with GfxBench v5 Aztec Ruins Vulkan test
https://bugs.freedesktop.org/show_bug.cgi?id=108900 --- Comment #11 from Samuel Pitoiset --- First time I see a shader like that... Can you install spirv-dis and generate a new hang report, please? The SPIR-V is probably useful too. -- 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 108900] [KBL-G][Vulkan] Non-recoverable GPU hangs with GfxBench v5 Aztec Ruins Vulkan test
https://bugs.freedesktop.org/show_bug.cgi?id=108900 --- Comment #10 from Eero Tamminen --- Created attachment 143573 --> https://bugs.freedesktop.org/attachment.cgi?id=143573=edit 70MB output from the RADV debug options (compressed) -- 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 108900] [KBL-G][Vulkan] Non-recoverable GPU hangs with GfxBench v5 Aztec Ruins Vulkan test
https://bugs.freedesktop.org/show_bug.cgi?id=108900 --- Comment #9 from Eero Tamminen --- Created attachment 143572 --> https://bugs.freedesktop.org/attachment.cgi?id=143572=edit Hang trace (In reply to Samuel Pitoiset from comment #8) > Again, without the demo is hard to fix. While GfxBench v5 / AztecRuins seems still to be proprietary for Desktop Linux (available for free only on Windows & Android), (recoverable) Manhattan hangs in bug 108898 can be tested with the public GfxBench v4 version. > Can you try 'export RADV_DEBUG=nodcc,nohiz,zerovram,nofastclears' ? > > If it still hangs Yes, it still hangs, just less verbosely. dmesg: [ 546.116535] amdgpu :01:00.0: GPU fault detected: 146 0x0fa0880c for process testfw_app pid 1859 thread testfw_app pid 1860 [ 546.116538] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x001001F4 [ 546.116539] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0808800C [ 546.116541] amdgpu :01:00.0: VM fault (0x0c, vmid 4, pasid 32772) at page 1049076, read from 'TC4' (0x54433400) (136) [ 556.201073] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=11253, emitted seq=11254 [ 556.201101] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process testfw_app pid 1859 thread testfw_app pid 1860 [ 556.201104] amdgpu :01:00.0: GPU reset begin! [ 556.616910] cp is busy, skip halt cp [ 556.805398] rlc is busy, skip halt rlc [ 556.806410] amdgpu :01:00.0: GPU pci config reset [ 556.818925] amdgpu :01:00.0: GPU reset succeeded, trying to resume [ 556.818962] [drm] PCIE GART of 256M enabled (table at 0x00F4007E9000). [ 556.818991] [drm:amdgpu_device_gpu_recover [amdgpu]] *ERROR* VRAM is lost! [ 556.896623] [drm] UVD and UVD ENC initialized successfully. [ 556.997551] [drm] VCE initialized successfully. [ 557.007168] [drm] recover vram bo from shadow start [ 557.012867] [drm] recover vram bo from shadow done [ 557.012869] [drm] Skip scheduling IBs! [ 557.012956] amdgpu :01:00.0: GPU reset(2) succeeded! [ 557.013063] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125! ... Application: -- Warm up Generate SH shader... Workgroup size: 8 compile deferred_irradiance_volumes/m_envprobe_generate_sh_compute.shader... done amdgpu: radv_amdgpu_cs_query_fence_status failed. glVkError: 2 line: 4329 func: Finish amdgpu: radv_amdgpu_cs_query_fence_status failed. glVkError: 2 line: 4219 func: BeginCommandBuffer amdgpu: The CS has been rejected, see dmesg for more information. vk: error: failed to submit CS 0 -- > generating a hang report might help > export RADV_TRACE_FILE=$HOME/hang.trace > export RADV_DEBUG=allbos,vmfaults,zerovram,syncshaders Hang trace attached. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Merge request #362]scons: Fix MSYS2 Mingw-w64 build (toolchain=mingw)
This patch is based on https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-mesa/link-ole32.patch but with tweaks to avoid MSVC build break when applied. There is a caveat to this patch though, it doesn't help swr driver. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] nir: Add ability for shaders to use window space coordinates - broken tessellation under NIR - bisected
Hello Andre, @Tim: Tested-by: Dieter Nützel with UH on Polaris 20 Am 07.03.2019 15:35, schrieb Andre Heider: On 07/03/2019 15:08, Dieter Nützel wrote: can you please send a patch to the list (and then we will see it at Patchwork Mesa, too), please? It is much faster (for me) and I haven't the time to dig me into Gitlab MRs etc. stuff at the moment. OLD school man... It's just a single patch in that MR. I know. Got it in the meantime. There is an 'Options' pulldown (Download | Email Patches | Plain Diff) on the 'page' of every commit. As with github, you can append .patch to the url: https://gitlab.freedesktop.org/Venemo/mesa/commit/24d534e355f54edb4b27451d0e4d92a1adb1669c.patch Or just `curl | git am`. Does that work for you? "Auch gut." ;-) Regards, Andre I'm learning... Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] nir: Add ability for shaders to use window space coordinates - broken tessellation under NIR - bisected
On 07/03/2019 15:08, Dieter Nützel wrote: can you please send a patch to the list (and then we will see it at Patchwork Mesa, too), please? It is much faster (for me) and I haven't the time to dig me into Gitlab MRs etc. stuff at the moment. OLD school man... It's just a single patch in that MR. As with github, you can append .patch to the url: https://gitlab.freedesktop.org/Venemo/mesa/commit/24d534e355f54edb4b27451d0e4d92a1adb1669c.patch Or just `curl | git am`. Does that work for you? Regards, Andre ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] nir: Add ability for shaders to use window space coordinates - broken tessellation under NIR - bisected
Hello Tim, can you please send a patch to the list (and then we will see it at Patchwork Mesa, too), please? It is much faster (for me) and I haven't the time to dig me into Gitlab MRs etc. stuff at the moment. OLD school man... Thanks, Dieter Am 07.03.2019 11:16, schrieb Timur Kristóf: Hi, I was able to reproduce the problem with heaven, and that the proposed patch fixes it, so I made a MR: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/402 Best regards, Tim On Thu, 2019-03-07 at 08:27 +0100, Timur Kristóf wrote: Hi Dieter, Thanks for noticing this. I think I made a mistake by setting window_space_position the way I did. Should've only set that for vertex shaders. I believe this is the right thing to do: https://gitlab.freedesktop.org/Venemo/mesa/commit/4d8b97bacbe14bd6584d7a45ff98e65dfcb4c02b Still need to test it myself. If it works, I'll submit a MR. Let me know what you think. Best regards, Tim On Thu, 2019-03-07 at 05:45 +0100, Dieter Nützel wrote: > This commit (#317f10bf404) brake whole tessellation (empty parts of > the > screen) running UH under radeonsi NIR on Polaris 20 (RX580). > > 317f10bf404b562e1dda79c0636aee86beeccc2f is the first bad commit > commit 317f10bf404b562e1dda79c0636aee86beeccc2f > Author: Timur Kristóf > Date: Tue Feb 5 18:08:24 2019 +0100 > > nir: Add ability for shaders to use window space coordinates. > > This patch adds a shader_info field that tells the driver to > use > window > space coordinates for a given vertex shader. It also enables > this > feature > in radeonsi (the only NIR-capable driver that supported it in > TGSI), > and makes tgsi_to_nir aware of it. > > Signed-Off-By: Timur Kristóf > Tested-by: Andre Heider > Tested-by: Rob Clark > Reviewed-by: Timothy Arceri > Reviewed-by: Eric Anholt > > :04 04 3123b07ce063ffd4fee56974c64c130f3e617373 > df57eb5bb70c0e46583399c73db499e1970fdd1b M src > > Reverting it fixed UH. > > Sorry, I don't have time for a ticket, yet 'cause I badly need > some > sleep... > > Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109920] "NIR validation failed in internal shader" abort with all Vulkan test-cases
https://bugs.freedesktop.org/show_bug.cgi?id=109920 Eero Tamminen changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #4 from Eero Tamminen --- Verified -- 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] nir/spirv: short-circuit when conditional branch contains end block
Woah, is this legal SPIR-V? I think a second OpSelectionMerge is required.
--Jason
On March 6, 2019 05:25:26 "Juan A. Suarez Romero" wrote:
This fixes the case when the SPIR-V code has two nested conditional
branches, but only one selection merge:
[...]
%1 = OpLabel
OpSelectionMerge %2 None
OpBranchConditional %3 %4 %2
%4 = OpLabel
OpBranchConditional %3 %5 %2
%5 = OpLabel
OpBranch %2
%2 = OpLabel
[...]
In the second OpBranchConditional, as the else-part is the end
block (started in the first OpBranchConditional) we can just follow the
then-part.
This fixes dEQP-VK.vkrunner.controlflow.2-obc-triangle-triangle
CC: Jason Ekstrand
---
src/compiler/spirv/vtn_cfg.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 7868eeb60bc..f749118efbe 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -605,7 +605,16 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct
list_head *cf_list,
}
} else if (if_stmt->then_type == vtn_branch_type_none &&
if_stmt->else_type == vtn_branch_type_none) {
-/* Neither side of the if is something we can short-circuit. */
+/* Neither side of the if is something we can short-circuit,
+ * unless one of the blocks is the end block. */
+if (then_block == end) {
+ block = else_block;
+ continue;
+} else if (else_block == end) {
+ block = then_block;
+ continue;
+}
+
vtn_assert((*block->merge & SpvOpCodeMask) == SpvOpSelectionMerge);
struct vtn_block *merge_block =
vtn_value(b, block->merge[1], vtn_value_type_block)->block;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles
https://bugs.freedesktop.org/show_bug.cgi?id=77449 andrew.m.mcma...@gmail.com changed: What|Removed |Added Depends on||109925 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=109925 [Bug 109925] Age of Wonders 3 - Vertical lines on Main Menu (Linux native via Steam) -- 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
Re: [Mesa-dev] [PATCH] radv: disable DCC for X4 Foundations to workaround a GPU hang
Superseded by
https://patchwork.freedesktop.org/patch/290846/?series=57689=1
On 3/6/19 7:39 PM, Samuel Pitoiset wrote:
The game apparently hangs inside a copy image operation, but
only when DCC is enabled. I haven't figured out the root cause
yet, but this workaround fixes the problem and allows people
to play that title, at least.
Cc: 18.3 19.0
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index fc04de21025..bb76885d986 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -510,6 +510,12 @@ radv_handle_per_app_options(struct radv_instance *instance,
} else if (!strcmp(name, "DOOM_VFR")) {
/* Work around a Doom VFR game bug */
instance->debug_flags |= RADV_DEBUG_NO_DYNAMIC_BOUNDS;
+ } else if (!strcmp(name, "X4")) {
+ /* FIXME: X4 Foundations hangs the GPU on GFX9. It seems to
+* work on GFX8, but I think it's safer to disable DCC
+* everywhere for now.
+*/
+ instance->debug_flags |= RADV_DEBUG_NO_DCC;
}
}
___
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 #15 from Samuel Pitoiset --- Does the attached patch help https://patchwork.freedesktop.org/patch/290846/?series=57689=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 109805] GPU hangs with error VM_CONTEXT1_PROTECTION_FAULT_STATUS
https://bugs.freedesktop.org/show_bug.cgi?id=109805 --- Comment #12 from Samuel Pitoiset --- Does the attached patch help https://patchwork.freedesktop.org/patch/290846/?series=57689=1 ? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: increase aligment when allocating descriptors for meta operations
We usually align to 0x100 when allocating descriptors and resources in the upload BO. I assume some data were corrupted because the alignment was too small. Be consistent (and safe) and align internal descriptors to 0x100 as well. This fixes a GPU hang at startup with X4 Foundations. Cc: 18.3 19.0 Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_cmd_buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c index 5b66930d137..24ed6d47a51 100644 --- a/src/amd/vulkan/radv_cmd_buffer.c +++ b/src/amd/vulkan/radv_cmd_buffer.c @@ -2848,7 +2848,7 @@ void radv_meta_push_descriptor_set( push_set->size = layout->set[set].layout->size; push_set->layout = layout->set[set].layout; - if (!radv_cmd_buffer_upload_alloc(cmd_buffer, push_set->size, 32, + if (!radv_cmd_buffer_upload_alloc(cmd_buffer, push_set->size, 256, _offset, (void**) _set->mapped_ptr)) return; -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] nir: Add ability for shaders to use window space coordinates - broken tessellation under NIR - bisected
Hi, I was able to reproduce the problem with heaven, and that the proposed patch fixes it, so I made a MR: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/402 Best regards, Tim On Thu, 2019-03-07 at 08:27 +0100, Timur Kristóf wrote: > Hi Dieter, > > Thanks for noticing this. > I think I made a mistake by setting window_space_position the way I > did. Should've only set that for vertex shaders. > > I believe this is the right thing to do: > https://gitlab.freedesktop.org/Venemo/mesa/commit/4d8b97bacbe14bd6584d7a45ff98e65dfcb4c02b > Still need to test it myself. If it works, I'll submit a MR. > > Let me know what you think. > Best regards, > Tim > > > On Thu, 2019-03-07 at 05:45 +0100, Dieter Nützel wrote: > > This commit (#317f10bf404) brake whole tessellation (empty parts of > > the > > screen) running UH under radeonsi NIR on Polaris 20 (RX580). > > > > 317f10bf404b562e1dda79c0636aee86beeccc2f is the first bad commit > > commit 317f10bf404b562e1dda79c0636aee86beeccc2f > > Author: Timur Kristóf > > Date: Tue Feb 5 18:08:24 2019 +0100 > > > > nir: Add ability for shaders to use window space coordinates. > > > > This patch adds a shader_info field that tells the driver to > > use > > window > > space coordinates for a given vertex shader. It also enables > > this > > feature > > in radeonsi (the only NIR-capable driver that supported it in > > TGSI), > > and makes tgsi_to_nir aware of it. > > > > Signed-Off-By: Timur Kristóf > > Tested-by: Andre Heider > > Tested-by: Rob Clark > > Reviewed-by: Timothy Arceri > > Reviewed-by: Eric Anholt > > > > :04 04 3123b07ce063ffd4fee56974c64c130f3e617373 > > df57eb5bb70c0e46583399c73db499e1970fdd1b M src > > > > Reverting it fixed UH. > > > > Sorry, I don't have time for a ticket, yet 'cause I badly need > > some > > sleep... > > > > Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109919] radv is broken on SI
https://bugs.freedesktop.org/show_bug.cgi?id=109919 --- Comment #6 from Turo Lamminen --- Confirm fixed. -- 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 109540] gen_builder_meta.hpp:51:117: error: no matching function for call to ‘cast(llvm::FunctionCallee)’
https://bugs.freedesktop.org/show_bug.cgi?id=109540
--- Comment #1 from Philip Meulengracht ---
I haven't really had a chance to make a patch. But I've fixed this in my own
fork, just add .getCallee() like this:
Function* pFunc =
cast(JM()->mpCurrentModule->getOrInsertFunction("meta.intrinsic.VGATHERPD",
pFuncTy).getCallee());
This is due to the fact that the functions now return an opaque pointer
instead, wrapped in the FunctionCallee class, the offending commit is here:
https://github.com/llvm-mirror/llvm/commit/9ec60d7d8fa237f19210d325c8c058b89c7b17d2#diff-295d2c56655729b2bd6dc1dfca7c2f0e
The fix is needed several places, also in the codegen template
--
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
