[Mesa-dev] [PATCH 06/12] nir: Lower flrp(#a, #b, c) differently

From: Ian Romanick If the magnitudes of #a and #b are such that (b-a) won't lose too much precision, lower as a+c(b-a). I have CC'ed everyone responsible for drivers that sets lower_flrp32 or lower_flrp64. No changes on any other Intel platforms. Iron Lake total instructions in shared

[Mesa-dev] [PATCH 10/12] nir: Lower flrp(a, b, #c) differently

From: Ian Romanick This doesn't help on Intel GPUs now because we always take the "always_precise" path first. It may help on other GPUs, and it does prevent a bunch of regressions in "intel/compiler: Don't always require precise lowering of flrp". I have CC'ed everyone responsible for drivers

[Mesa-dev] [PATCH 07/12] nir: Lower flrp(±1, b, c) and flrp(a, ±1, c) differently

From: Ian Romanick I have CC'ed everyone responsible for drivers that sets lower_flrp32 or lower_flrp64. No changes on any other Intel platforms. Iron Lake total instructions in shared programs: 7752306 -> 7716901 (-0.46%) instructions in affected programs: 1160861 -> 1125456 (-3.05%) helped:

[Mesa-dev] [PATCH 09/12] nir: Lower flrp(a, b, c) differently if another flrp(_, b, c) exists

From: Ian Romanick There is little effect on Intel GPUs now because we almost always take the "always_precise" path first. It may help on other GPUs, and it does prevent a bunch of regressions in "intel/compiler: Don't always require precise lowering of flrp". I have CC'ed everyone responsible

[Mesa-dev] [PATCH 01/12] nir: Pull common addition out of flrp arguments

From: Ian Romanick Skylake total instructions in shared programs: 14304116 -> 14303686 (<.01%) instructions in affected programs: 49036 -> 48606 (-0.88%) helped: 209 HURT: 0 helped stats (abs) min: 1 max: 8 x̄: 2.06 x̃: 1 helped stats (rel) min: 0.23% max: 6.67% x̄: 1.19% x̃: 0.56% 95% mean

[Mesa-dev] [PATCH 04/12] nir: Use the flrp lowering pass instead of nir_opt_algebraic

From: Ian Romanick I tried to be very careful while updating all the various drivers, but I don't have any of that hardware for testing. :( I have CC'ed everyone responsible for drivers that sets lower_flrp32 or lower_flrp64. i965 is the only platform that sets always_precise = true, and it is

[Mesa-dev] [PATCH 08/12] nir: Lower flrp(a, b, c) differently if another flrp(a, _, c) exists

From: Ian Romanick This doesn't help on Intel GPUs now because we always take the "always_precise" path first. It may help on other GPUs, and it does prevent a bunch of regressions in "intel/compiler: Don't always require precise lowering of flrp". I have CC'ed everyone responsible for drivers

[Mesa-dev] [PATCH 12/12] RFC: intel/compiler: Don't always require precise lowering of flrp

From: Ian Romanick No changes on any other Intel platforms. Iron Lake total instructions in shared programs: 7727356 -> 7699517 (-0.36%) instructions in affected programs: 3152595 -> 3124756 (-0.88%) helped: 12836 HURT: 48 helped stats (abs) min: 1 max: 30 x̄: 2.18 x̃: 1 helped stats (rel) min:

[Mesa-dev] [PATCH 00/12] Do better for flrp on platforms that lack flrp instruction, take 2

This series replaces my previous series (https://patchwork.freedesktop.org/series/48138/) that did similar things. Rather than trying to do everything with only local information in nir_opt_algebraic, this series adds a new optimization pass. This new pass looks at how various parameters of a

[Mesa-dev] [PATCH 02/12] nir: Pull common multiplication out of flrp arguments

From: Ian Romanick Skylake, Broadwell, Haswell, and Sandy Bridge had similar results. (Skylake shown) total instructions in shared programs: 14303686 -> 14300269 (-0.02%) instructions in affected programs: 121704 -> 118287 (-2.81%) helped: 694 HURT: 0 helped stats (abs) min: 1 max: 16 x̄: 4.92

[Mesa-dev] [PATCH 03/12] nir: Add new lowering pass for flrp instructions

From: Ian Romanick This pass will soon grow to include some optimizations that are difficult or impossible to implement correctly within nir_opt_algebraic. It also include the ability to generate strictly correct code which the current nir_opt_algebraic lowering lacks (though that could be

[Mesa-dev] [PATCH 05/12] intel/compiler: Use the flrp lowering pass for all stages on Gen4 and Gen5

From: Ian Romanick Previously lower_flrp32 was only set for vertex shaders. Fragment shaders performed a(1-c)+bc lowering during code generation. The shaders with loops hurt are SIMD8 and SIMD16 shaders for a text-identical fragment shader. Iron Lake total instructions in shared programs:

[Mesa-dev] [PATCH 11/12] nir: Reassociate open-coded flrp(1, b, c)

From: Ian Romanick In a previous verion of this patch, Jason commented, "Re-associating based on whether or not something has a constant value of 1.0 seems a bit sneaky. I think it's well within the rules but it seems like something that could bite you." That is possibly true. The

[Mesa-dev] [PATCH 4/5] i965/fs: Emit BRW_AOP_INC or BRW_AOP_DEC for imageAtomicAdd of +1 or -1

From: Ian Romanick No changes on any other Intel platforms. Skylake total instructions in shared programs: 14304261 -> 14304241 (<.01%) instructions in affected programs: 1625 -> 1605 (-1.23%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 8 x̄: 5.00 x̃: 5 helped stats (rel) min: 1.01% max:

[Mesa-dev] [PATCH 2/5] i965/fs: Emit BRW_AOP_INC or BRW_AOP_DEC for atomicAdd of +1 or -1

From: Ian Romanick Funny story... a single shader was hurt for instructions, spills, fills. That same shader was also the most helped for cycles. #GPUsAreWeird No changes on any other Intel platform. Haswell, Broadwell, and Skylake had similar results. (Skylake shown) total instructions in

[Mesa-dev] [PATCH 1/5] intel/compiler: Silence unused parameter warnings in brw_eu.h

From: Ian Romanick All of the other brw_*_desc functions take a devinfo parameter, and all of the others at least have an assert that uses it. Keep the parameter, but mark it as unused. Silences 37 warnings like: In file included from src/intel/common/gen_disasm.c:27:0:

[Mesa-dev] [PATCH 3/5] i965/fs: Refactor image atomics to be a bit more like other atomics

From: Ian Romanick This greatly simplifies the next patch. Signed-off-by: Ian Romanick --- src/intel/compiler/brw_fs_nir.cpp | 84 --- 1 file changed, 44 insertions(+), 40 deletions(-) diff --git a/src/intel/compiler/brw_fs_nir.cpp

[Mesa-dev] [PATCH 0/5] Emit BRW_AOP_INC or BRW_AOP_DEC

I don't know why we never did this. Almost every shader in shader-db that uses atomicAdd or imageAtomicAdd uses it with a constant of 1 or -1. Results on Skylake across the whole series are below. There is some discussion in patch 2 about the 189 instructions (!) added. total instructions in

[Mesa-dev] [PATCH 5/5] i965/vec4: Emit BRW_AOP_INC or BRW_AOP_DEC for atomicAdd of +1 or -1

From: Ian Romanick No shader-db changes on any Intel platform. Signed-off-by: Ian Romanick --- src/intel/compiler/brw_vec4_nir.cpp | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/src/intel/compiler/brw_vec4_nir.cpp

Re: [Mesa-dev] [PATCH] i965/gen7_urb: Re-emit PUSH_CONSTANT_ALLOC on GLK

On Fri, Aug 24, 2018 at 9:39 PM, Nanley Chery wrote: > On Fri, Aug 24, 2018 at 09:17:03PM -0400, Ilia Mirkin wrote: >> On Fri, Aug 24, 2018 at 8:46 PM, Nanley Chery wrote: >> > According to internal docs, some gen9 platforms have a pixel shader push >> > constant synchronization issue. Although

[Mesa-dev] [Bug 107680] OpenCL does not work on Ubuntu 18.04 with Nvidia

https://bugs.freedesktop.org/show_bug.cgi?id=107680 Devyn Collier Johnson changed: What|Removed |Added Status|NEEDINFO|RESOLVED

Re: [Mesa-dev] [PATCH] i965/gen7_urb: Re-emit PUSH_CONSTANT_ALLOC on GLK

On Fri, Aug 24, 2018 at 09:17:03PM -0400, Ilia Mirkin wrote: > On Fri, Aug 24, 2018 at 8:46 PM, Nanley Chery wrote: > > According to internal docs, some gen9 platforms have a pixel shader push > > constant synchronization issue. Although not listed among said > > platforms, this issue seems to be

[Mesa-dev] [PATCH 1/3] nir: Create sampler2D variables in nir_lower_{bitmap, drawpixels}.

This is needed for nir_gather_info to actually count the new textures, since it operates solely on variables. --- src/compiler/nir/nir_lower_bitmap.c | 7 +++ src/compiler/nir/nir_lower_drawpixels.c | 17 - 2 files changed, 23 insertions(+), 1 deletion(-) diff --git

[Mesa-dev] [PATCH 3/3] st/nir: Call nir_gather_info in st_finalize_nir.

Several of the passes change varyings. This is necessary for inputs_read and outputs_written to be accurate. --- src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp b/src/mesa/state_tracker/st_glsl_to_nir.cpp

[Mesa-dev] [PATCH 2/3] nir: Create sampler variables in prog_to_nir.

This is needed for nir_gather_info to actually count the textures, since it operates solely on variables. --- src/mesa/program/prog_to_nir.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/src/mesa/program/prog_to_nir.c b/src/mesa/program/prog_to_nir.c index

Re: [Mesa-dev] [PATCH] i965/gen7_urb: Re-emit PUSH_CONSTANT_ALLOC on GLK

On Fri, Aug 24, 2018 at 8:46 PM, Nanley Chery wrote: > According to internal docs, some gen9 platforms have a pixel shader push > constant synchronization issue. Although not listed among said > platforms, this issue seems to be present on the GeminiLake 2x6's we've > tested. > > We consider the

[Mesa-dev] [PATCH] i965/gen7_urb: Re-emit PUSH_CONSTANT_ALLOC on GLK

According to internal docs, some gen9 platforms have a pixel shader push constant synchronization issue. Although not listed among said platforms, this issue seems to be present on the GeminiLake 2x6's we've tested. We consider the available workarounds to be too detrimental on performance.

Re: [Mesa-dev] [PATCH 1/4] intel/decoder: Clean up field iteration and fix sub-dword fields

The whole series is : Reviewed-by: Lionel Landwerlin Thanks for the great cleanup! - Lionel On 24/08/2018 22:40, Jason Ekstrand wrote: First of all, setting iter->name in advance_field is unnecessary because it gets set by gen_decode_field which gets called immediately after

[Mesa-dev] [Bug 107680] OpenCL does not work on Ubuntu 18.04 with Nvidia

https://bugs.freedesktop.org/show_bug.cgi?id=107680 Rhys Kidd changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Rhys Kidd

[Mesa-dev] [PATCH 2/4] intel/decoder: Print ISL formats for vertex elements

--- src/intel/common/gen_decoder.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c index e9dabeae653..9e46f271633 100644 --- a/src/intel/common/gen_decoder.c +++ b/src/intel/common/gen_decoder.c @@ -971,7 +971,8

[Mesa-dev] [PATCH 3/4] intel/batch_decoder: Fix dynamic state printing

Instead of printing addresses like everyone else, we were accidentally printing the offset from state base address. Also, state_map is a void pointer so we were incrementing in bytes instead of dwords and every state other than the first was wrong. --- src/intel/common/gen_batch_decoder.c | 4

[Mesa-dev] [PATCH 1/4] intel/decoder: Clean up field iteration and fix sub-dword fields

First of all, setting iter->name in advance_field is unnecessary because it gets set by gen_decode_field which gets called immediately after gen_decode_field in the one call-site. Second, we weren't properly initializing start_bit and end_bit in the initial condition of gen_field_iterator_next so

[Mesa-dev] [PATCH 4/4] intel/batch_decoder: Print blend states properly

--- src/intel/common/gen_batch_decoder.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/src/intel/common/gen_batch_decoder.c b/src/intel/common/gen_batch_decoder.c index a57bd93e0f0..6884a999401 100644 --- a/src/intel/common/gen_batch_decoder.c +++

Re: [Mesa-dev] [PATCH] egl/android: do not indent HAVE_DRM_GRALLOC preprocessor directive

Hi, Il giorno mer 15 ago 2018 alle ore 15:13 Mauro Rossi ha scritto: > > Fixes: 3f7bca44d9 ("egl/android: #ifdef out flink name support") > Fixes: c7bb82136b ("egl/android: Add DRM node probing and filtering") > Signed-off-by: Mauro Rossi > --- > src/egl/drivers/dri2/platform_android.c | 6

[Mesa-dev] [Bug 107680] OpenCL does not work on Ubuntu 18.04 with Nvidia

https://bugs.freedesktop.org/show_bug.cgi?id=107680 Bug ID: 107680 Summary: OpenCL does not work on Ubuntu 18.04 with Nvidia Product: Mesa Version: 18.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: [Mesa-dev] [PATCH v2 4/4] freedreno: Drop a bunch of duplicated gallium PIPE_CAP default code.

On Thu, Aug 23, 2018 at 1:59 PM Eric Anholt wrote: > > Now that we have the util function for the default values, we can get rid > of the boilerplate. > > Cc: Rob Clark I like the idea of reducing the boilerplate.. Reviewed-by: Rob Clark > --- > .../drivers/freedreno/freedreno_screen.c

Re: [Mesa-dev] [PATCH 2/3] configure: allow building with python3

Can we just change the script to write a file instead of sending it's output through the shell? That should fix any encoding problems since the shell wont touch it and the LANG settings (no matter what they are) shouldn't matter. Dylan Quoting Mathieu Bridon (2018-08-24 07:58:21) > Hi, > > On

Re: [Mesa-dev] [PATCH 4/5] util/gen_xmlpool: Add a --meson switch

Quoting Emil Velikov (2018-08-24 08:57:29) > On Fri, 24 Aug 2018 at 15:16, Dylan Baker wrote: > > > > Meson won't put the .gmo files in the layout that python's > > gettext.translation() expects, so we need to handle them differently, > > this switch allows the script to load the files as meson

Re: [Mesa-dev] [PATCH] egl/android: rework device probing

Hey Emil, On 24/08/2018 14.21, Emil Velikov wrote: From: Emil Velikov Unlike the other platforms, here we aim do guess if the device that we somewhat arbitrarily picked, is supported or not. In particular: when a vendor is _not_ requested we loop through all devices, picking the first one

[Mesa-dev] [Bug 107669] [bisected] wflinfo fails ctx->Const.MaxCombinedTextureImageUnits assertion

https://bugs.freedesktop.org/show_bug.cgi?id=107669 Kenneth Graunke changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Mesa-dev] [ANNOUNCE] mesa 18.1.7

Hi List, Mesa 18.1.7 is now available for general consumption. This release has been rather small compared to the last few release, There's just a handful of fixes in total. Meson, radv, anv, gallium winsys, intel, i965, and r600 were the only recipients of fixs this go around. Dylan git tag:

Re: [Mesa-dev] [PATCH] gallivm: Detect VSX separately from Altivec

Is there anything else I need to do on this? This is my first mesa patch so I'm not entirely clear what next steps are for getting it committed. On 08/20/2018 02:44 PM, Roland Scheidegger wrote: Alright, I guess it's ok then. In theory the u_cpu_detect bits could be used in different places,

[Mesa-dev] [PATCH v4 47/49] appveyor: use msbuild instead of ninja

While this works for a CI like Appveyor it doesn't work on a bit more complex build environment where paths can be longer. Unfortunately MsBuild doesn't handle well the situation when paths exceed MAX_PATH. Here is an example: - Mesa source code is in C:\Software\DEVELO~1\projects\mesa\mesa -

[Mesa-dev] [Bug 107477] [DXVK] Setting high shader quality in GTA V results in LLVM error

https://bugs.freedesktop.org/show_bug.cgi?id=107477 --- Comment #11 from Clément Guérin --- Here's the capture: https://send.firefox.com/download/157438a5ba/#DzGe_CjcHthydTi1jPT-0A -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the

Re: [Mesa-dev] [PATCH 4/5] util/gen_xmlpool: Add a --meson switch

On Fri, 24 Aug 2018 at 15:16, Dylan Baker wrote: > > Meson won't put the .gmo files in the layout that python's > gettext.translation() expects, so we need to handle them differently, > this switch allows the script to load the files as meson lays them out No obvious reason comes to mind why we

Re: [Mesa-dev] [PATCH 1/3] gitlab-ci: build Mesa using GitLab CI

On Thu, 2018-08-09 at 19:35 -0700, Eric Anholt wrote: > "Juan A. Suarez Romero" writes: > > > Creates different Docker images containing Mesa built with different > > tools (autotools, meson, scons, etc). > > > > The build is done in 3 levels: the first level creates a base image > > with all

Re: [Mesa-dev] [PATCH 1/4] mesa: use C99 initializer in get_gl_override()

This patch is Reviewed-by: Ian Romanick On 08/24/2018 06:05 AM, Emil Velikov wrote: > From: Emil Velikov > > The overrides array contains entries indexed on the gl_api enum. > Use a C99 initializer to make it a bit more obvious. > > Signed-off-by: Emil Velikov > --- >

Re: [Mesa-dev] [PATCH 5/5] nir: Lower flrp differently when the alpha value is reused

On 08/23/2018 06:59 PM, Eric Anholt wrote: > Ian Romanick writes: > >> From: Ian Romanick >> >> For some reason, if I did not move the regular lowering to late >> optimizations, the new lowering would never trigger. This also means >> that the fsub lowering had to be added to late

[Mesa-dev] [Bug 107670] Massive slowdown under specific memcpy implementations (32bit, no-SIMD, backward copy).

https://bugs.freedesktop.org/show_bug.cgi?id=107670 --- Comment #7 from i...@yahoo.com --- (In reply to Grazvydas Ignotas from comment #4) > What game/benchmark do you see this with? > > Can you try calling _mesa_streaming_load_memcpy() there? It's for reading > uncached memory, but by the looks

Re: [Mesa-dev] [PATCH 0/3] Use GitLab CI to build Mesa

On Wed, 2018-08-08 at 17:40 +0100, Daniel Stone wrote: > Hi Juan, > > On Wed, 8 Aug 2018 at 16:45, Juan A. Suarez Romero > wrote: > > This is a first part of a more complete proposal to use GitLab CI to build > > and > > test Mesa. This first part just adds the required pieces to build Mesa,

Re: [Mesa-dev] [PATCH 2/2] glsl: remove execute bit and shebang from python tests

On Fri, 24 Aug 2018 at 15:43, Andres Gomez wrote: > > Emil, I've done some trivial conflicts resolution upon cherry picking > this commit. > > You can see it at (staging/18.2): > https://gitlab.freedesktop.org/mesa/mesa/commit/f6dccf66865c31b13f48b50891a9f5a0d9949b1c > > Please, let me know if

Re: [Mesa-dev] [PATCH 2/3] configure: allow building with python3

Hi, On Thu, 2018-08-23 at 23:23 -0400, Ilia Mirkin wrote: > This breaks the build for me. It selects python3 instead of python2, > and gen_xmlpool.py bails out when trying to print \xf3 to stdout with > a LANG=C locale. In general though, Python 3 works very badly with LANG=C. Upstream Python

Re: [Mesa-dev] [PATCH v2 1/8] nir: evaluate if condition uses inside the if branches

On Fri, Aug 17, 2018 at 1:13 PM Jason Ekstrand wrote: > On Mon, Jul 23, 2018 at 3:03 AM Timothy Arceri > wrote: > >> Since we know what side of the branch we ended up on we can just >> replace the use with a constant. >> >> All the spill changes in shader-db are from Dolphin uber shaders, >>

Re: [Mesa-dev] [PATCH 2/2] glsl: remove execute bit and shebang from python tests

Emil, I've done some trivial conflicts resolution upon cherry picking this commit. You can see it at (staging/18.2): https://gitlab.freedesktop.org/mesa/mesa/commit/f6dccf66865c31b13f48b50891a9f5a0d9949b1c Please, let me know if this is OK. On Fri, 2018-08-17 at 12:11 +0100, Emil Velikov

[Mesa-dev] [PATCH] nir: Pull block_ends_in_jump into nir.h

We had two different implementations in different files. May as well have one and put it in nir.h. --- src/compiler/nir/nir.h | 7 +++ src/compiler/nir/nir_control_flow.c | 17 + src/compiler/nir/nir_opt_dead_cf.c | 12 +--- 3 files changed, 13

Re: [Mesa-dev] [PATCH 3/4] radeonsi: add radeonsi_zerovram driconfig option

On 2018-08-24 1:06 p.m., Timothy Arceri wrote: > More and more games seem to require this so lets make it a config > option. > --- > src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 1 + > src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 10 +++--- > src/util/xmlpool/t_options.h

[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

https://bugs.freedesktop.org/show_bug.cgi?id=77449 Vedran Miletić changed: What|Removed |Added Depends on||104809 Referenced Bugs:

[Mesa-dev] [Bug 107477] [DXVK] Setting high shader quality in GTA V results in LLVM error

https://bugs.freedesktop.org/show_bug.cgi?id=107477 --- Comment #10 from Samuel Pitoiset --- I would prefer a renderdoc capture if you can provide that. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the

Re: [Mesa-dev] [PATCH 2/3] configure: allow building with python3

Quoting Emil Velikov (2018-08-24 02:34:04) > On Fri, 24 Aug 2018 at 04:23, Ilia Mirkin wrote: > > > > This breaks the build for me. It selects python3 instead of python2, > > and gen_xmlpool.py bails out when trying to print \xf3 to stdout with > > a LANG=C locale. Revert until scripts are fixed

[Mesa-dev] [PATCH 2/5] util/gen_xmlpool: use argparse for argument handling

This is a little cleaner than just looking at sys.argv, but it's also going to allow us to handle the differences in the way meson and autotools hand translations more cleanly. --- src/util/xmlpool/gen_xmlpool.py | 20 +--- 1 file changed, 9 insertions(+), 11 deletions(-) diff

[Mesa-dev] [PATCH 0/5] Meson support for gettext translations

This is the last thing I know of that's outstanding for meson (that's not related to windows). One patch in this series is a fix that needs to go into 18.1 and 18.2. Dylan Baker (5): meson: Actually load translation files util/gen_xmlpool: use argparse for argument handling meson: add

[Mesa-dev] [PATCH 3/5] meson: add support for generating translation mo files

Meson has handy a handy built-in module for handling gettext called i18n, this module works a bit differently than our autotools build does, namely it doesn't automatically generate translations instead it creates 3 new top level targets to run. These are: xmlpool-pot xmlpool-update-po

[Mesa-dev] [PATCH 5/5] meson: use meson generated translation files

This is a change from the current status-quo, namely to get dri-conf translations you now *must* run the meson generation scripts, even if you're building from an autotools generated tarball (an official release). --- src/util/xmlpool/meson.build | 2 +- 1 file changed, 1 insertion(+), 1

[Mesa-dev] [PATCH 1/5] meson: Actually load translation files

Currently we run the script but don't actually load any files, even in a tarball where they exist. Fixes: 3218056e0eb375eeda470058d06add1532acd6d4 ("meson: Build i965 and dri stack") --- src/util/xmlpool/meson.build | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[Mesa-dev] [PATCH 4/5] util/gen_xmlpool: Add a --meson switch

Meson won't put the .gmo files in the layout that python's gettext.translation() expects, so we need to handle them differently, this switch allows the script to load the files as meson lays them out --- src/util/xmlpool/gen_xmlpool.py | 15 +++ 1 file changed, 11 insertions(+), 4

Re: [Mesa-dev] [PATCH 5/8] anv/android: support import/export of AHardwareBuffer objects

On Fri, Aug 24, 2018 at 12:12 AM Tapani Pälli wrote: > > > On 08/22/2018 05:28 PM, Jason Ekstrand wrote: > > On Tue, Aug 21, 2018 at 3:27 AM Tapani Pälli > > wrote: > > > > v2: add support for non-image buffers (AHARDWAREBUFFER_FORMAT_BLOB) > > v3:

Re: [Mesa-dev] [PATCH 3/8] anv/android: add GetAndroidHardwareBufferPropertiesANDROID

On Fri, Aug 24, 2018 at 12:08 AM Tapani Pälli wrote: > > > On 08/22/2018 05:18 PM, Jason Ekstrand wrote: > > On Tue, Aug 21, 2018 at 3:27 AM Tapani Pälli > > wrote: > > > > When adding YUV support, we need to figure out implementation-defined > > external

Re: [Mesa-dev] [PATCH] docs/relnotes: Mark NV_fragment_shader_interlock support in i965

Acked and pushed. Thanks! On Fri, Aug 24, 2018 at 1:01 AM wrote: > From: Kevin Rogovin > > --- > docs/relnotes/18.3.0.html | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/docs/relnotes/18.3.0.html b/docs/relnotes/18.3.0.html > index 594b0624a5..afcb044817 100644 > ---

[Mesa-dev] [PATCH] st/dri: implement the __DRI_DRIVER_VTABLE extension

From: Emil Velikov As the comment above globalDriverAPI (in dri_util.c) says, if the loader is unaware of createNewScreen2 there is a race condition. In which globalDriverAPI, will be set in the driver driDriverGetExtensions* function and used in createNewScreen(). If we call another drivers'

[Mesa-dev] [PATCH 4/4] st/dri: make swrast_no_present member of dri_screen

From: Emil Velikov Just like the dri2 options, this is better suited in the dri_screen struct. Signed-off-by: Emil Velikov --- src/gallium/state_trackers/dri/dri_screen.h | 2 ++ src/gallium/state_trackers/dri/drisw.c | 7 +++ 2 files changed, 5 insertions(+), 4 deletions(-) diff

[Mesa-dev] [PATCH 3/4] st/dri: inline dri2_buffer.h within dri2.c

From: Emil Velikov The header was used only by dri2.c, containing a two-member struct and cast wrapper. Just inline it where it's used/needed. Signed-off-by: Emil Velikov --- .../state_trackers/dri/Makefile.sources | 3 +-- src/gallium/state_trackers/dri/dri2.c | 15

[Mesa-dev] [PATCH 1/4] mesa: use C99 initializer in get_gl_override()

From: Emil Velikov The overrides array contains entries indexed on the gl_api enum. Use a C99 initializer to make it a bit more obvious. Signed-off-by: Emil Velikov --- src/mesa/main/version.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/mesa/main/version.c

[Mesa-dev] [PATCH 2/4] st/xa: remove unused xa_screen::d[s]_depth_bits_last

From: Emil Velikov Unused since the initial import. Signed-off-by: Emil Velikov --- src/gallium/state_trackers/xa/xa_priv.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/gallium/state_trackers/xa/xa_priv.h b/src/gallium/state_trackers/xa/xa_priv.h index 13a0e86f66d..c513b8d9629

[Mesa-dev] [Bug 107670] Massive slowdown under specific memcpy implementations (32bit, no-SIMD, backward copy).

https://bugs.freedesktop.org/show_bug.cgi?id=107670 --- Comment #6 from Eero Tamminen --- (In reply to Timothy Arceri from comment #1) > There already is asm optimized version of memcpy() in glibc. Why would we > want to reinvent that in Mesa? > > glibc should pick the right implementation for

[Mesa-dev] [Bug 107670] Massive slowdown under specific memcpy implementations (32bit, no-SIMD, backward copy).

https://bugs.freedesktop.org/show_bug.cgi?id=107670 --- Comment #5 from i...@yahoo.com --- (In reply to Roland Scheidegger from comment #3) > Isn't this mapped as WC? > In this case I'd expect the direction to make little difference, since write > combine of any decent cpu should be able to

Re: [Mesa-dev] [PATCH 2/3] configure: allow building with python3

Quoting Emil Velikov (2018-08-24 02:34:04) > On Fri, 24 Aug 2018 at 04:23, Ilia Mirkin wrote: > > > > This breaks the build for me. It selects python3 instead of python2, > > and gen_xmlpool.py bails out when trying to print \xf3 to stdout with > > a LANG=C locale. Revert until scripts are fixed

Re: [Mesa-dev] [PATCH 6/5] egl/android: continue to next device if dri2_create_screen fails

On Thu, 23 Aug 2018 at 04:27, Tomasz Figa wrote: > > On Thu, Aug 23, 2018 at 1:44 AM Emil Velikov wrote: > > > > Hi Tomasz, > > > > On 21 August 2018 at 14:54, Tomasz Figa wrote: > > > Hi Emil, > > > > > > On Tue, Aug 14, 2018 at 2:05 AM Emil Velikov > > > wrote: > > >> > > >> From: Emil

[Mesa-dev] [PATCH] egl/android: rework device probing

From: Emil Velikov Unlike the other platforms, here we aim do guess if the device that we somewhat arbitrarily picked, is supported or not. In particular: when a vendor is _not_ requested we loop through all devices, picking the first one which can create a DRI screen. When a vendor is

[Mesa-dev] [PATCH 2/2] meson: Enable readeon vulkan driver on arm, aarch64

This is similar to what the Debian package does so it looks like a sane default. Signed-off-by: Guido Günther --- meson.build | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meson.build b/meson.build index ccc0ed6a0ea..bf8f0770915 100644 --- a/meson.build +++ b/meson.build @@ -179,6

[Mesa-dev] [PATCH 1/2] meson: Be a bit more helpful when arch or OS is unknown

Signed-off-by: Guido Günther --- meson.build | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/meson.build b/meson.build index 1b3dfa221c9..ccc0ed6a0ea 100644 --- a/meson.build +++ b/meson.build @@ -102,13 +102,15 @@ if _drivers.contains('auto') elif

[Mesa-dev] [Bug 107524] Broken packDouble2x32 at llvmpipe

https://bugs.freedesktop.org/show_bug.cgi?id=107524 --- Comment #4 from Matwey V. Kornilov --- Any news? -- 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

Re: [Mesa-dev] [PATCH] egl/wayland: do not leak wl_buffer when it is locked

On Wed, 2018-08-08 at 17:49 +0100, Daniel Stone wrote: > Hi Juan, > > On Wed, 8 Aug 2018 at 17:40, Juan A. Suarez Romero > wrote: > > On Wed, 2018-08-08 at 17:21 +0100, Daniel Stone wrote: > > > On Thu, 2 Aug 2018 at 10:02, Juan A. Suarez Romero > > > wrote: > > > > If color buffer is locked,

Re: [Mesa-dev] [PATCH] anv: Add support for protected memory properties on anv_GetPhysicalDeviceProperties2()

On 24/08/2018 12:09, Samuel Iglesias Gonsálvez wrote: VkPhysicalDeviceProtectedMemoryProperties structure is new on Vulkan 1.1. Fixes Vulkan CTS CL#2849. Signed-off-by: Samuel Iglesias Gonsálvez Reviewed-by: Lionel Landwerlin --- src/intel/vulkan/anv_device.c | 7 +++ 1 file

Re: [Mesa-dev] [PATCH] egl/wayland: do not leak wl_buffer when it is locked

On Wed, 2018-08-08 at 17:49 +0100, Daniel Stone wrote: > Hi Juan, > > On Wed, 8 Aug 2018 at 17:40, Juan A. Suarez Romero > wrote: > > On Wed, 2018-08-08 at 17:21 +0100, Daniel Stone wrote: > > > On Thu, 2 Aug 2018 at 10:02, Juan A. Suarez Romero > > > wrote: > > > > If color buffer is locked,

[Mesa-dev] [PATCH] anv: Add support for protected memory properties on anv_GetPhysicalDeviceProperties2()

VkPhysicalDeviceProtectedMemoryProperties structure is new on Vulkan 1.1. Fixes Vulkan CTS CL#2849. Signed-off-by: Samuel Iglesias Gonsálvez --- src/intel/vulkan/anv_device.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/intel/vulkan/anv_device.c

[Mesa-dev] [PATCH 4/4] radeonsi: enable radeonsi_zerovram for No Mans Sky

--- src/util/00-mesa-defaults.conf | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf index ad59efba50b..5d15b3819fb 100644 --- a/src/util/00-mesa-defaults.conf +++ b/src/util/00-mesa-defaults.conf @@ -322,5 +322,8 @@ TODO:

[Mesa-dev] [PATCH 3/4] radeonsi: add radeonsi_zerovram driconfig option

More and more games seem to require this so lets make it a config option. --- src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 1 + src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 10 +++--- src/util/xmlpool/t_options.h| 5 + 3 files changed, 13 insertions(+), 3

[Mesa-dev] [PATCH 2/4] radeonsi: enable GL 4.5 in compat profile

--- src/gallium/drivers/radeonsi/si_get.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_get.c b/src/gallium/drivers/radeonsi/si_get.c index 47368fb7c91..f4c61a7e408 100644 --- a/src/gallium/drivers/radeonsi/si_get.c +++

[Mesa-dev] [PATCH 1/4] mesa: enable ARB_direct_state_access in compat for GL3.1+

We could enable it for lower versions of GL but this allows us to just use the existing version/extension checks that are already used by the core profile. --- src/mapi/glapi/gen/apiexec.py| 194 +++ src/mesa/main/extensions_table.h | 2 +-

Re: [Mesa-dev] [PATCH 2/3] configure: allow building with python3

On Fri, 24 Aug 2018 at 04:23, Ilia Mirkin wrote: > > This breaks the build for me. It selects python3 instead of python2, > and gen_xmlpool.py bails out when trying to print \xf3 to stdout with > a LANG=C locale. Revert until scripts are fixed and try again? > Sure will revert in a moment. The

[Mesa-dev] [Bug 107670] Massive slowdown under specific memcpy implementations (32bit, no-SIMD, backward copy).

https://bugs.freedesktop.org/show_bug.cgi?id=107670 --- Comment #4 from Grazvydas Ignotas --- What game/benchmark do you see this with? Can you try calling _mesa_streaming_load_memcpy() there? It's for reading uncached memory, but by the looks of it it might be suitable for writing too. --

Re: [Mesa-dev] [PATCH v2] glsl/linker: Allow unused in blocks which are not declated on previous stage

CCing Timothy just in case he still thinks that the original comment should remain as it is. In any case, it looks to me, so: Reviewed-by: Alejandro Piñeiro On 23/08/18 12:12, vadym.shovkoplias wrote: > From Section 4.3.4 (Inputs) of the GLSL 1.50 spec: > > "Only the input variables that

[Mesa-dev] [Bug 106231] llvmpipe blends produce bad code after llvm patch https://reviews.llvm.org/D44785

https://bugs.freedesktop.org/show_bug.cgi?id=106231 Roland Scheidegger changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Mesa-dev] [PATCH] docs/relnotes: Mark NV_fragment_shader_interlock support in i965

From: Kevin Rogovin --- docs/relnotes/18.3.0.html | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/relnotes/18.3.0.html b/docs/relnotes/18.3.0.html index 594b0624a5..afcb044817 100644 --- a/docs/relnotes/18.3.0.html +++ b/docs/relnotes/18.3.0.html @@ -59,6 +59,7 @@ Note: some of the new

[Mesa-dev] [PATCH] docs/relnotes: Mark NV_fragment_shader_interlock support in i965

From: Kevin Rogovin --- docs/relnotes/18.3.0.html | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/relnotes/18.3.0.html b/docs/relnotes/18.3.0.html index 594b0624a5..afcb044817 100644 --- a/docs/relnotes/18.3.0.html +++ b/docs/relnotes/18.3.0.html @@ -59,6 +59,7 @@ Note: some of the new