Re: [Mesa-dev] Build mesa-dev on Windows with AVX instruction set problem

On Wed, Oct 25, 2017 at 6:15 PM, Fabrício Ceolin < fabricio.ceo...@miningmath.com> wrote: > Hi, > > Thanks. I recompiled everything (on Windows) using this real machine: > > #under msys2 > $ cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model

Re: [Mesa-dev] [Mesa-stable] [PATCH 6/7] configure.ac: add missing LLVM components for OpenCL

Emil, by 17.2, Clover is still asking only for LLVM 3.6 and "coverage" doesn't seem to be there. Hence, I think we should drop or backport this patch. In any case, check my other mail about this patch series ... On Thu, 2017-10-05 at 11:19 +0100, Emil Velikov wrote: > From: Emil Velikov

Re: [Mesa-dev] [PATCH 2/3] mesa: enable ARB_texture_buffer_* extensions in the Compatibility profile

For list posterity, since my intel email isn't subscribed, There are a significant number of i965 regressions from

Re: [Mesa-dev] [PATCH 2/3] mesa: enable ARB_texture_buffer_* extensions in the Compatibility profile

On Sat, Oct 21, 2017 at 8:54 AM, Marek Olšák wrote: > From: Marek Olšák > > We already have piglit tests testing alpha, luminance, and intensity > formats. They were skipped by piglit until now. > > Additionally, I'm enabling one ARB_texture_buffer_range

[Mesa-dev] [PATCH 2/9] meson: rename all instances of xf86vm to xxf86vm

Because consistency Signed-off-by: Dylan Baker --- meson.build | 6 +++--- src/glx/meson.build | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/meson.build b/meson.build index c480dd410d9..5b31194b0df 100644 --- a/meson.build +++

[Mesa-dev] [PATCH 8/9] meson: build classic osmesa

From: Dylan Baker This builds the classic (non-gallium) osmesa with meson. This has been tested with the osdemo application from mesa-demos. Signed-off-by: Dylan Baker --- include/meson.build | 2 +- meson.build

[Mesa-dev] [PATCH 1/9] meson: fix pkg-config Gl Require.Private

xf86vm -> xxf86vm Signed-off-by: Dylan Baker --- meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meson.build b/meson.build index 2a89b6482f9..c480dd410d9 100644 --- a/meson.build +++ b/meson.build @@ -814,7 +814,7 @@ gl_priv_reqs = [

[Mesa-dev] [PATCH 7/9] meson: Add generated files to non-shared glapi

Signed-off-by: Dylan Baker --- src/mapi/glapi/meson.build | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mapi/glapi/meson.build b/src/mapi/glapi/meson.build index d3e070d0d1a..74f84d289ba 100644 --- a/src/mapi/glapi/meson.build +++

[Mesa-dev] [PATCH 0/9] Meson: osmesa support

This series adds support to the meson build system for both classic osmesa and gallium based osmesa. There are quite a few cleanup patches in this series as well, one of which is reviewed but sent back out so the whole series can be reviewed. Dylan Dylan Baker (9): meson: fix pkg-config Gl

[Mesa-dev] [PATCH 3/9] meson: fix glprocs.h generator

There was a typo that causes the generated file to be called gl_procs.h instead. Signed-off-by: Dylan Baker Reviewed-by: Eric Engestrom --- src/mapi/glapi/gen/meson.build | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff

[Mesa-dev] [PATCH 5/9] osmesa: Include generated headers without path

This makes things much easier to ensure correctness with meson. Tested with make dist-check and with meson. Signed-off-by: Dylan Baker --- src/mesa/drivers/osmesa/Makefile.am | 2 ++ src/mesa/drivers/osmesa/osmesa.c| 4 ++-- 2 files changed, 4 insertions(+), 2

[Mesa-dev] [PATCH 4/9] meson: move gallium include declarations to src

These are used by non-gallium osmesa, so they need to be defined outside of the gallium subdirectory. Signed-off-by: Dylan Baker --- src/gallium/auxiliary/meson.build | 2 -- src/gallium/meson.build | 1 - src/meson.build | 2 ++ 3 files

[Mesa-dev] [PATCH 9/9] meson: build gallium based osmesa

This has been tested with the osdemo from mesa-demos Signed-off-by: Dylan Baker --- meson.build | 3 ++ meson_options.txt | 2 +- src/gallium/meson.build | 7 ++-

[Mesa-dev] [PATCH 6/9] glapi: include generated headers without path

This has been tested wtih make dist-check and with meson. Signed-off-by: Dylan Baker --- src/mapi/glapi/glapi_dispatch.c | 2 +- src/mapi/glapi/glapi_getproc.c | 4 ++-- src/mapi/glapi/glapi_nop.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff

Re: [Mesa-dev] [PATCH v2] clover: Fix compilation after clang r315871

On Tue, 2017-10-24 at 15:32 +0200, Vedran Miletić wrote: > On 10/23/2017 05:24 AM, Jan Vesely wrote: > > From: Jan Vesely > > > > v2: use a more generic compat function > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103388 > > Signed-off-by: Jan Vesely

[Mesa-dev] [PATCH v5 04/10] configure.ac: Add tizen to supported platforms (v2)

It checks tpl-egl/libtbm/libtdm packages and defines HAVE_PLATFORM_TIZEN. This feature is enabled by the config option '--with-platforms=tizen' v2: Fixes from Emil's review: - Add require_libdrm to tizen platform Signed-off-by: Mun Gwan-gyeong --- configure.ac | 10

[Mesa-dev] [PATCH v5 03/10] egl/tizen: add support of the swrast related features for tizen platform (v2)

It implements the egl swrast related features for tizen platform on platform_tizen.c It works with libtpl-egl (Tizen Porting Layer for egl) and libtbm (Tizen Buffer Manager) where back buffers of windows are backed by GEM objects. In Tizen a native window has a queue (tbm_surface_queue) of

[Mesa-dev] [PATCH v5 00/10] new series of Mesa for Tizen

Hi, These Patch v5 series modified with new helper function series [1]. These series only have mesa for tizen feature. [1] https://patchwork.freedesktop.org/series/32577/ Thanks, Gwan-gyeong. Gwan-gyeong Mun (10): egl: add a treatment of tizen platform on egl display (v2) egl/dri2: Add

[Mesa-dev] [PATCH v5 02/10] egl/dri2: Add some member variables for tizen platform on dri2_egl_display and dri2_egl_surface (v2)

It adds some member variables for tizen platform on dri2_egl_display and dri2_egl_surface. - tpl_display stores a object which encapsulates native disply (wl_display, gbm_device, tbm_bufmgr) for tizen platfom. - native_win stores native window (wl_surface, gbm_surface,

[Mesa-dev] [PATCH v5 07/10] egl/tizen: add tizen specific implementation for EGL_WAYLAND_BUFFER_WL target of eglCreateImageKHR() (v2)

In the tizen platform, a wl_buffer wraps a tbm_surface. The tbm_surface contains gem name or prime fd. For creating dri_image, we need to extract the tbm_surface from the wl_buffer and we use tpl_display_get_buffer_from_native_pixmap() api for that. v2: a) Add switch's default case to return

[Mesa-dev] [PATCH v5 06/10] egl/tizen: add tizen specific implementations for BindWaylandDisplayWL/UnbindWaylandDisplayWL/QueryWaylandBufferWL (v2)

Tizen platform (actually WL_TBM protocol) internally processes similiar actions such as mesa's BindWaylandDisplayWL/UnbindWaylandDisplayWL/QueryWaylandBufferWL. So the platform_tizen.c needs to implemment BindWaylandDisplayWL, UnbindWaylandDisplayWL and QueryWaylandBufferWL apart from mesa's. -

[Mesa-dev] [PATCH v5 05/10] egl/tizen: add support of dri2_loader (v3)

It adds support of dri2_loader to egl dri2 tizen backend. - referenced a basic buffer flow and management implementation from android. And it implements a query buffer age extesion for tizen and turn on swap_buffers_with_damage extension. - it add color buffer related member variables to

[Mesa-dev] [PATCH v5 01/10] egl: add a treatment of tizen platform on egl display (v2)

It adds a _EGL_PLATFORM_TIZEN enum value to _EGLPlatformType for tizen platform. It adds a detecting routine of tizen platform to _eglNativePlatformDetectNativeDisplay() and _eglGetNativePlatform(). - As tizen platform internally distinguishes native displays of tbm, drm/gbm and wayland

Re: [Mesa-dev] Build mesa-dev on Windows with AVX instruction set problem

Hi, Thanks. I recompiled everything (on Windows) using this real machine: #under msys2 $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Genuine Intel(R) CPU U2300 @ 1.20GHz stepping: 10 cpu MHz

Re: [Mesa-dev] [Mesa-stable] [PATCH 3/7] configure.ac: rework llvm libs handling for 3.9+

Emil, this patch series introduces a lot of changes on how we treat LLVM's dependency. After applying this patch in the stable queue, I get these errors: For the "make Gallium Drivers SWR" and "make Gallium Drivers Other" targets: " ... CXXLDgallium_dri.la /usr/bin/ld:

Re: [Mesa-dev] Build mesa-dev on Windows with AVX instruction set problem

Am 26.10.2017 um 00:26 schrieb Ilia Mirkin: > On Wed, Oct 25, 2017 at 6:15 PM, Fabrício Ceolin > > > wrote: > > Hi, > > Thanks. I recompiled everything (on Windows) using this real machine: > > #under msys2 >

Re: [Mesa-dev] [PATCH v2 43/52] nir: Add a new subgroups lowering pass

On Fri, Oct 13, 2017 at 3:52 AM, Lionel Landwerlin < lionel.g.landwer...@intel.com> wrote: > On 13/10/17 06:48, Jason Ekstrand wrote: > >> This commit pulls nir_lower_read_invocations_to_scalar along with most >> of the guts of nir_opt_intrinsics (which mostly does subgroup lowering) >> into a

Re: [Mesa-dev] [PATCH v2 06/52] intel/fs: Use an explicit D type for vote any/all/eq intrinsics

On Tue, Oct 17, 2017 at 2:03 PM, Matt Turner wrote: > On 10/12, Jason Ekstrand wrote: > >> They return a boolean so this is the right type. Unfortunately, >> get_nir_dest has the annoying behavior of giving us a float type by >> default. This is mostly to work around the

Re: [Mesa-dev] [PATCH 2/2] radv: Implement VK_AMD_shader_info

On Wed, Oct 25, 2017 at 4:03 PM, Samuel Pitoiset wrote: > > > On 10/25/2017 02:20 PM, Alex Smith wrote: >> >> On 25 October 2017 at 12:46, Samuel Pitoiset > > wrote: >> >> I have something similar on my

Re: [Mesa-dev] [PATCH 2/3] i965/blorp: Use more temporary isl_format variables

On Mon, Oct 23, 2017 at 11:07 PM, Pohjolainen, Topi < topi.pohjolai...@gmail.com> wrote: > On Mon, Oct 23, 2017 at 05:23:08PM -0700, Jason Ekstrand wrote: > > --- > > src/mesa/drivers/dri/i965/brw_blorp.c | 15 +++ > > 1 file changed, 7 insertions(+), 8 deletions(-) > > > > diff

[Mesa-dev] [PATCH v3 00/48] nir, intel: Prerequisites for subgroups

This series is a third respin of my subgroups prerequisites series that that I sent out a few weeks ago. Not a whole lot has changed but there are some new patches. Primarily, 1) Some patches which were reviewed by Matt and Lionel were pushed and are no longer in the series. Thanks guys!

[Mesa-dev] [PATCH v3 02/48] intel/fs: Be more explicit about our placement of [un]zip

Before, we were careful to place the zip after the last of the split instructions but did unzip on-demand. This changes things so that the unzips go before all of the split instructions and the unzip comes explicitly after all the split instructions. As a side-effect of this change, we now emit

[Mesa-dev] [PATCH v3 05/48] intel/fs: Use an explicit D type for vote any/all/eq intrinsics

The any/all intrinsics return a boolean value so D or UD is the correct type. Unfortunately, get_nir_dest has the annoying behavior of returnning a float type by default. This causes format conversion which gives us -1.0f or 0.0f in the register. If the consumer of the result does an integer

[Mesa-dev] [PATCH v3 14/48] i965/fs: Extend the live ranges of VGRFs which leave loops

No Shader-db changes. Cc: mesa-sta...@lists.freedesktop.org --- src/intel/compiler/brw_fs_live_variables.cpp | 55 1 file changed, 55 insertions(+) diff --git a/src/intel/compiler/brw_fs_live_variables.cpp b/src/intel/compiler/brw_fs_live_variables.cpp index

[Mesa-dev] [PATCH v3 09/48] intel/eu/reg: Add a subscript() helper

This is similar to the identically named fs_reg helper. Cc: mesa-sta...@lists.freedesktop.org --- src/intel/compiler/brw_reg.h | 16 1 file changed, 16 insertions(+) diff --git a/src/intel/compiler/brw_reg.h b/src/intel/compiler/brw_reg.h index d68d64f..9d63717 100644 ---

[Mesa-dev] [PATCH v3 11/48] intel/fs: Fix MOV_INDIRECT for 64-bit values on little-core

The same workaround we need for 64-bit values on little core also takes care of the Ivy Bridge problem and does so a bit more efficiently so we can drop that code while we're here. Cc: mesa-sta...@lists.freedesktop.org --- src/intel/compiler/brw_fs_generator.cpp | 75

[Mesa-dev] [PATCH v3 03/48] intel/fs: Use ANY/ALL32 predicates in SIMD32

We have ANY/ALL32 predicates and, for the most part, they work just fine. (See the next commit for more details.) Also, due to the way that flag registers are handled in hardware, instruction splitting is able to split the CMP correctly. Specifically, that hardware looks at the execution group

[Mesa-dev] [PATCH v3 08/48] intel/eu: Just modify the offset in brw_broadcast

This means we have to drop const from a variable but it also means that 100% of the code which deals with the offset limit is in one place. --- src/intel/compiler/brw_eu_emit.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/intel/compiler/brw_eu_emit.c

[Mesa-dev] [PATCH v3 06/48] intel/fs: Use a pair of 1-wide MOVs instead of SEL for any/all

For some reason, the any/all predicates don't work properly with SIMD32. In particular, it appears that a SEL with a QtrCtrl of 2H doesn't read the correct subset of the flag register and you end up getting garbage in the second half. Work around this by using a pair of 1-wide MOVs and scattering

[Mesa-dev] [PATCH v3 01/48] intel/fs: Pass builders instead of blocks into emit_[un]zip

This makes it far more explicit where we're inserting the instructions rather than the magic "before and after" stuff that the emit_[un]zip helpers did based on block and inst. Cc: mesa-sta...@lists.freedesktop.org --- src/intel/compiler/brw_fs.cpp | 50

[Mesa-dev] [PATCH v3 15/48] intel/fs: Restrict live intervals to the subset possibly reachable from any definition.

From: Francisco Jerez Currently the liveness analysis pass would extend a live interval up to the top of the program when no unconditional and complete definition of the variable is found that dominates all of its uses. This can lead to a serious performance problem in

[Mesa-dev] [PATCH v3 07/48] intel/compiler: Add some restrictions to MOV_INDIRECT and BROADCAST

These restrictions effectively already existed due to the way we use indirect sources but weren't being directly enforced. --- src/intel/compiler/brw_eu_emit.c| 16 src/intel/compiler/brw_fs_generator.cpp | 2 ++ src/intel/compiler/brw_shader.cpp | 2 ++ 3 files

[Mesa-dev] [PATCH v3 04/48] intel/fs: Don't stomp f0.1 in SIMD16 ballot

In fragment shaders f0.1 is used for discards so doing ballot after a discard can potentially cause the discard to not happen. However, we don't support SIMD32 fragment shaders yet so this isn't a problem. Cc: mesa-sta...@lists.freedesktop.org --- src/intel/compiler/brw_fs_nir.cpp | 11

[Mesa-dev] [PATCH v3 17/48] i965/fs: Return a fs_reg from shuffle_64bit_data_for_32bit_write

All callers of this function allocate a fs_reg expressly to pass into it. It's much easier if we just let the helper allocate the register. While we're here, we switch it to doing the MOVs with an integer type so that we don't accidentally canonicalize floats on half of a double. ---

[Mesa-dev] [PATCH v3 12/48] intel/fs: Fix integer multiplication lowering for src/dst hazards

Cc: mesa-sta...@lists.freedesktop.org --- src/intel/compiler/brw_fs.cpp | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp index ef36af9..56455e9 100644 --- a/src/intel/compiler/brw_fs.cpp +++

[Mesa-dev] [PATCH v3 22/48] intel/fs: Retype dest to match value in read[First]Invocation

This is what we really wanted all along. Always retyping to D works because that's what get_nir_src() always gives us, at least for 32-bit types. The SPIR-V variants of these operations accept arbitrary types and we need this if we're going to handle 64 or 16-bit values. ---

[Mesa-dev] [PATCH v3 20/48] intel/fs: Protect opt_algebraic from OOB BROADCAST indices

--- src/intel/compiler/brw_fs.cpp | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp index 1c4351b..52079d3 100644 --- a/src/intel/compiler/brw_fs.cpp +++ b/src/intel/compiler/brw_fs.cpp @@ -2416,8 +2416,14

[Mesa-dev] [PATCH v3 39/48] nir: Add a new subgroups lowering pass

This commit pulls nir_lower_read_invocations_to_scalar along with most of the guts of nir_opt_intrinsics (which mostly does subgroup lowering) into a new nir_lower_subgroups pass. There are various other bits of subgroup lowering that we're going to want to do so it makes a bit more sense to keep

[Mesa-dev] [PATCH v3 29/48] intel/cs: Rework the way thread local ID is handled

Previously, brw_nir_lower_intrinsics added the param and then emitted a load_uniform intrinsic to load it directly. This commit switches things over to use a specific NIR intrinsic for the thread id. The one thing I don't like about this approach is that we have to copy thread_local_id over to

[Mesa-dev] [PATCH v3 34/48] intel/fs: Rework zero-length URB write handling

Originally we tried to handle this case based on slots_valid. However, there are a number of ways that this can go wrong. For one, we throw away any trailing slots which either aren't written or are set to VARYING_SLOT_PAD. Second, even if PSIZ is a valid slot, we may not actually write

[Mesa-dev] [PATCH v3 21/48] intel/fs: Uniformize the index in readInvocation

The index is any value provided by the shader and this can be called in non-uniform control flow so we can't just take component 0. Found by inspection. --- src/intel/compiler/brw_fs_nir.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/intel/compiler/brw_fs_nir.cpp

[Mesa-dev] [PATCH v3 33/48] intel/compiler/fs: Set up subgroup invocation as a system value

Subgroup invocation is computed using a vector immediate and some dispatch-aware arithmetic. Unfortunately, due to the vector arithmetic, and the fact that it's frequently read 16-wide, it's not something that can easily be CSEd by the back-end compiler. There are a few different possible

[Mesa-dev] [PATCH v3 30/48] intel/cs: Re-run final NIR optimizations for each SIMD size

With the advent of SPIR-V subgroup operations, compute shaders will have to be slightly different depending on the SIMD size at which they execute. In order to allow us to do dispatch-width specific things in NIR, we re-run the final NIR stages for each sIMD width. One side-effect of this change

[Mesa-dev] [PATCH v3 18/48] i965/fs/nir: Minor refactor of store_output

Stop retyping the output of shuffle_64bit_data_for_32bit_write. It's always BRW_REGISTER_TYPE_D which is perfectly fine for writing out. Also, when we change get_nir_src to return something with a 64-bit type for 64-bit values, the retyping will not be at all what we want. Also, retyping the

[Mesa-dev] [PATCH v3 38/48] intel/fs: Don't use automatic exec size inference

The automatic exec size inference can accidentally mess things up if we're not careful. For instance, if we have add(4)g38.2<4>Dg38.1<8,2,4>Dg38.2<8,2,4>D then the destination register will end up having a width of 2 with a horizontal stride of 4 and a vertical stride of 8. The EU

[Mesa-dev] [PATCH v3 26/48] intel/cs: Stop setting dispatch_grf_start_reg

Nothing ever reads it for compute shaders because it's always 1. --- src/intel/compiler/brw_compiler.h | 1 - src/intel/compiler/brw_fs.cpp | 2 -- 2 files changed, 3 deletions(-) diff --git a/src/intel/compiler/brw_compiler.h b/src/intel/compiler/brw_compiler.h index 014202d..508d4ba

[Mesa-dev] [PATCH v3 27/48] intel/cs: Ignore runtime_check_aads_emit for CS

It's only set on gen4-5 which clearly don't support compute shaders. --- src/intel/compiler/brw_fs.cpp | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp index 35d1ca4..4ebf539 100644 ---

[Mesa-dev] [PATCH v3 19/48] i965/fs/nir: Don't stomp 64-bit values to D in get_nir_src

--- src/intel/compiler/brw_fs_nir.cpp | 33 + 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/src/intel/compiler/brw_fs_nir.cpp b/src/intel/compiler/brw_fs_nir.cpp index e008e2e..a441f57 100644 --- a/src/intel/compiler/brw_fs_nir.cpp +++

[Mesa-dev] [PATCH v3 28/48] intel/fs: Mark 64-bit values as being contiguous

This isn't often a problem , when we're in a compute shader, we must push the thread local ID so we decrement the amount of available push space by 1 and it's no longer even and 64-bit data can, in theory, span it. By marking those uniforms contiguous, we ensure that they never get split in half

[Mesa-dev] [PATCH v3 35/48] intel/eu: Make automatic exec sizes a configurable option

We have had a feature in codegen for some time that tries to automatically infer the execution size of an instruction from the width of its destination. For things such as fixed function GS, clipper, and SF programs, this is very useful because they tend to have lots of hand-rolled register setup

[Mesa-dev] [PATCH v3 13/48] intel/fs: Use the original destination region for int MUL lowering

Some hardware (CHV, BXT) have special restrictions on register regions when doing integer multiplication. We want to respect those when we lower to DxW multiplication. Cc: mesa-sta...@lists.freedesktop.org --- src/intel/compiler/brw_fs.cpp | 16 +--- 1 file changed, 9 insertions(+),

[Mesa-dev] [PATCH v3 10/48] intel/eu: Fix broadcast instruction for 64-bit values on little-core

We're not using broadcast for any 32-bit types right now since we mostly use it for emit_uniformize on 32-bit buffer indices. However, SPIR-V subgroups are going to need it for 64-bit so let's make it work. --- src/intel/compiler/brw_eu_emit.c | 26 -- 1 file changed, 24

[Mesa-dev] [PATCH v3 24/48] intel/fs: Remove min_dispatch_width from fs_visitor

It's 8 for everything except compute shaders. For compute shaders, there's no need to duplicate the computation and it's just a possible source of error. --- src/intel/compiler/brw_fs.cpp | 42 +++ src/intel/compiler/brw_fs.h | 5 ++---

[Mesa-dev] [PATCH v3 16/48] i965/fs/nir: Simplify 64-bit store_output

The swizzles weren't doing any good because swiz is just XYZW. Also, we were emitting an extra set of MOVs because shuffle_64bit_data_for_32bit already does a MOV for us. Finally, the temporary was only ever used inside the inner loop so there's no need for it to actually be an array. ---

[Mesa-dev] [PATCH v3 23/48] intel/fs: Assign constant locations if they haven't been assigned

Before, we bailing in assign_constant_locations based on the minimum dispatch size. The more direct thing to do is simply to check for whether or not we have constant locations and bail if we do. For nir_setup_uniforms, it's completely safe to do it multiple times because we just copy a value

[Mesa-dev] [PATCH v3 31/48] intel/cs: Re-run final NIR optimizations for each SIMD size

With the advent of SPIR-V subgroup operations, compute shaders will have to be slightly different depending on the SIMD size at which they execute. In order to allow us to do dispatch-width specific things in NIR, we re-run the final NIR stages for each sIMD width. As a side-effect of this

[Mesa-dev] [PATCH v3 48/48] compiler/nir_types: Handle vectors in glsl_get_array_element

Most of NIR doesn't allow doing array indexing on a vector (though it does on a matrix). However, nir_lower_io handles it just fine and this behavior is needed for shared variables in Vulkan. This commit makes glsl_get_array_element do something sensible for vector types and makes nir_validate

[Mesa-dev] [PATCH v3 41/48] nir: Make ballot intrinsics variable-size

This way they can return either a uvec4 or a uint64_t. At the moment, this is a no-op since we still always return a uint64_t. Reviewed-by: Lionel Landwerlin --- src/compiler/glsl/glsl_to_nir.cpp | 1 + src/compiler/nir/nir_intrinsics.h | 12

[Mesa-dev] [PATCH v3 46/48] spirv: Rework barriers

Our previous handling of barriers always used the big hammer and didn't correctly emit memory barriers when specified along with a control barrier. This commit completely reworks the way we emit barriers to make things both more precise and more correct. Reviewed-by: Lionel Landwerlin

[Mesa-dev] [PATCH v3 36/48] intel/eu: Explicitly set EXECUTE_1 where needed

--- src/intel/compiler/brw_eu_emit.c | 9 + 1 file changed, 9 insertions(+) diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c index 902914f..952d489 100644 --- a/src/intel/compiler/brw_eu_emit.c +++ b/src/intel/compiler/brw_eu_emit.c @@ -1983,6 +1983,7 @@

[Mesa-dev] [PATCH v3 37/48] intel/fs: Explicitly set EXECUTE_1 where needed

--- src/intel/compiler/brw_fs.cpp | 2 +- src/intel/compiler/brw_fs_generator.cpp | 7 +++ src/intel/compiler/brw_fs_nir.cpp | 8 src/intel/compiler/brw_fs_visitor.cpp | 7 +++ 4 files changed, 15 insertions(+), 9 deletions(-) diff --git

[Mesa-dev] [PATCH v3 45/48] spirv: Add a vtn_constant_value helper

Reviewed-by: Lionel Landwerlin --- src/compiler/spirv/vtn_private.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/compiler/spirv/vtn_private.h b/src/compiler/spirv/vtn_private.h index 8458462..e7a7c36 100644 --- a/src/compiler/spirv/vtn_private.h

[Mesa-dev] [PATCH v3 40/48] nir: Add a ssa_dest_init_for_type helper

This would be useful a number of places Reviewed-by: Lionel Landwerlin --- src/compiler/nir/nir.h | 9 + 1 file changed, 9 insertions(+) diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h index 8c3a20c..1a25d7b 100644 ---

[Mesa-dev] [PATCH v3 25/48] intel/cs: Drop max_dispatch_width checks from compile_cs

The only things that adjust fs_visitor::max_dispatch_width are render target writes which don't happen in compute shaders so they're pointless. --- src/intel/compiler/brw_fs.cpp | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/intel/compiler/brw_fs.cpp

[Mesa-dev] [PATCH v3 42/48] nir/lower_system_values: Lower SUBGROUP_*_MASK based on type

The SUBGROUP_*_MASK system values are uint64_t when coming in from GLSL but uvec4 when coming in from SPIR-V. Lowering based on type allows us to nicely handle both. Reviewed-by: Lionel Landwerlin --- src/compiler/nir/nir_lower_system_values.c | 5 +++-- 1 file

[Mesa-dev] [PATCH v3 47/48] nir: Validate base types on array dereferences

We were already validating that the parent type goes along with the child type but we weren't actually validating that the parent type is reasonable. This fixes that. Acked-by: Lionel Landwerlin --- src/compiler/nir/nir_validate.c | 18 -- 1 file

[Mesa-dev] [PATCH v3 32/48] intel/cs: Push subgroup ID instead of base thread ID

We're going to want subgroup ID for SPIR-V subgroups eventually anyway. We really only want to push one and calculate the other from it. It makes a bit more sense to push the subgroup ID because it's simpler to calculate and because it's a real API thing. The only advantage to pushing the base

[Mesa-dev] [PATCH v3 44/48] nir, intel/compiler: Use a fixed subgroup size

The GL_ARB_shader_ballot spec says that gl_SubGroupSizeARB is declared as a uniform. This means that it cannot change across an invocation such as a draw call or a compute dispatch. For compute shaders, we're ok because we only ever use one dispatch size. For fragment, however, the hardware

[Mesa-dev] [PATCH v3 43/48] nir/lower_subgroups: Lower ballot intrinsics to the specified bit size

Ballot intrinsics return a bitfield of subgroups. In GLSL and some SPIR-V extensions, they return a uint64_t. In SPV_KHR_shader_ballot, they return a uvec4. Also, some back-ends would rather pass around 32-bit values because it's easier than messing with 64-bit all the time. To solve this mess,

Re: [Mesa-dev] Build mesa-dev on Windows with AVX instruction set problem

Seeing the source code in disassembly and the stacktrace, it appears to me that the problem is in the std:: basic_string(), not related to mesa-dev. Although, it's strange to me the source of this include is at MSVC dir (according to VS2017) and opengl32.dll was compiled using LLVM. Maybe the

Re: [Mesa-dev] [PATCH v2] clover: Fix compilation after clang r315871

Jan Vesely writes: > On Tue, 2017-10-24 at 15:32 +0200, Vedran Miletić wrote: >> On 10/23/2017 05:24 AM, Jan Vesely wrote: >> > From: Jan Vesely >> > >> > v2: use a more generic compat function >> > >> > Bugzilla:

Re: [Mesa-dev] meson for remaining class drivers

ping Quoting Dylan Baker (2017-10-16 17:55:49) > Here is build support for the three remaining classic drivers, radeon (r100), > r200, and the nouveau-veaux driver. None of these are too crazy, but I don't > have hardware to test any of these. > > ___

[Mesa-dev] [Bug 103449] Mesa 17.2 cannot be built with clang and libc++

https://bugs.freedesktop.org/show_bug.cgi?id=103449 Bug ID: 103449 Summary: Mesa 17.2 cannot be built with clang and libc++ Product: Mesa Version: 17.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: [Mesa-dev] [PATCH 2/2] radv: Implement VK_AMD_shader_info

I have something similar on my local tree (started on monday). Though, I don't like the way we expose the number of VGPRS/SGPRS because we can't really figure out the number of spilled ones. On 10/25/2017 01:18 PM, Alex Smith wrote: This allows an app to query shader statistics and get a

[Mesa-dev] [PATCH V2] ac/nir: generate correct instruction for atomic min/max on unsigned images

v2: fix silly typo Cc: "17.2 17.3" --- src/amd/common/ac_nir_to_llvm.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c index 3d635d4206..06937d684b 100644 ---

[Mesa-dev] [PATCH 1/2] vulkan: Update headers and registry to 1.0.64

Signed-off-by: Alex Smith --- include/vulkan/vulkan.h| 50 +- src/vulkan/registry/vk.xml | 159 + 2 files changed, 181 insertions(+), 28 deletions(-) diff --git a/include/vulkan/vulkan.h

[Mesa-dev] [PATCH 2/2] radv: Implement VK_AMD_shader_info

This allows an app to query shader statistics and get a disassembly of a shader. RenderDoc git has support for it, so this allows you to view shader disassembly from a capture. When this extension is enabled on a device (or when tracing), we now disable pipeline caching, since we don't get the

Re: [Mesa-dev] [PATCH] i965: Revert absolute mode for constant buffer pointers.

On Mon, 2017-10-23 at 16:19 -0700, Kenneth Graunke wrote: > On Monday, October 23, 2017 3:53:15 PM PDT Rodrigo Vivi wrote: > > On Mon, Oct 23, 2017 at 10:32:43PM +, Jordan Justen wrote: > > > On 2017-10-19 16:30:44, Kristian Høgsberg wrote: > > > > On Thu, Oct 19, 2017 at 4:18 PM, Kenneth

Re: [Mesa-dev] [PATCH 00/10] anv: Implement VK_ANDROID_native_buffer (v4)

On Mon, Oct 16, 2017 at 1:54 PM, Chad Versace wrote: > (This is v4 submission of the series, but contains v9 of the key patch). > > This series adds Android support to Anvil. And Android requires > VK_ANDROID_native_buffer. > > > I tested the series on 64-bit ARC++ on a

Re: [Mesa-dev] [PATCH] radeon/video: add gfx9 offsets when rejoin the video surface

Am 25.10.2017 um 15:46 schrieb Leo Liu: For CPU access. Signed-off-by: Leo Liu Cc: mesa-sta...@lists.freedesktop.org Reviewed-by: Christian König --- src/gallium/drivers/radeon/radeon_video.c | 5 - 1 file changed, 4 insertions(+), 1

Re: [Mesa-dev] [PATCH 2/2] radv: Implement VK_AMD_shader_info

On 25 October 2017 at 12:46, Samuel Pitoiset wrote: > I have something similar on my local tree (started on monday). > > Though, I don't like the way we expose the number of VGPRS/SGPRS because > we can't really figure out the number of spilled ones. My assumption

Re: [Mesa-dev] [PATCH mesa] meson: be explicit about the version required

On Tue, Oct 24, 2017 at 11:48 PM, Dylan Baker wrote: > Quoting Eric Engestrom (2017-10-24 10:32:36) >> On Tuesday, 2017-10-24 09:40:22 -0700, Dylan Baker wrote: >> > This seems reasonable, could you wrap the hanging indent like >> > meson_options with >> > the closing brace

Re: [Mesa-dev] [PATCH 2/2] radv: Implement VK_AMD_shader_info

On 10/25/2017 02:20 PM, Alex Smith wrote: On 25 October 2017 at 12:46, Samuel Pitoiset > wrote: I have something similar on my local tree (started on monday). Though, I don't like the way we expose the number of

Re: [Mesa-dev] [PATCH mesa] meson: bring MESA_GIT_SHA1 in line with other build systems

On Wednesday, 2017-10-25 00:02:49 -0700, Jordan Justen wrote: > On 2017-10-24 14:54:10, Eric Engestrom wrote: > > Meson's vcs_tag() uses the output of `git describe`, eg. > > 17.3-branchpoint-5-gfbf29c3cd15ae831e249+ > > > > Whereas the other build systems used a script that outputs only the

Re: [Mesa-dev] [PATCH v2 10/8] glsl/linker: Fix type checks for location aliasing

On Wed, Oct 25, 2017 at 5:15 AM, Iago Toral Quiroga wrote: > From the OpenGL 4.6 spec, section 4.4.1 Input Layout Qualifiers, Page 68, > (Location aliasing): > >"Further, when location aliasing, the aliases sharing the location > must have the same underlying numerical

Re: [Mesa-dev] [PATCH v2 9/8] glsl/linker: refactor check_location_aliasing

Not your fault, but this diff is hard to read. On the bright side, 20 lines removed... Can you confirm that layout(location = 1, component = 2) int foo; layout(location = 0) dvec3 bar; fails due to the int vs double conflicts? (I'm specifically interested in the case where the int is specified

[Mesa-dev] [PATCH] radeon/video: add gfx9 offsets when rejoin the video surface

For CPU access. Signed-off-by: Leo Liu Cc: mesa-sta...@lists.freedesktop.org --- src/gallium/drivers/radeon/radeon_video.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeon/radeon_video.c

[Mesa-dev] [Bug 103253] blob.h:138:1: error: unknown type name 'ssize_t'

https://bugs.freedesktop.org/show_bug.cgi?id=103253 Jason Ekstrand changed: What|Removed |Added Resolution|--- |FIXED

Re: [Mesa-dev] [PATCH] gallium/util: remove some block alignment assertions

Am 25.10.2017 um 16:29 schrieb Brian Paul: > On 10/24/2017 07:06 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> These assertions were revisited a couple of times in the past, and they >> still weren't quite right. >> The problem I was seeing (with some other

Re: [Mesa-dev] [PATCH] gallium/util: remove some block alignment assertions

On 10/25/2017 09:54 AM, Roland Scheidegger wrote: Am 25.10.2017 um 16:57 schrieb Roland Scheidegger: Am 25.10.2017 um 16:29 schrieb Brian Paul: On 10/24/2017 07:06 PM, srol...@vmware.com wrote: From: Roland Scheidegger These assertions were revisited a couple of times in

  1   2   >