[Mesa-dev] [PATCH 43/44] 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. --- src/compiler/nir/nir_validate.c | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/src/co

Re: [Mesa-dev] [PATCH 2/3] docs/releasing: polish LLVM_CONFIG wording/handling

On Tue, 2017-09-05 at 15:21 +0100, Emil Velikov wrote: > From: Emil Velikov > > Use concistent way to manage "non-default" llvm installations, clearly ^^ consistent > documenting it. > > AKA, use LLVM_CONFIG throughout and unset for the Windows/mingw builds. > > Cc: Andres Gomez

[Mesa-dev] [PATCH 42/44] 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. --- src/compiler/spirv/spirv_to_nir.c | 13

[Mesa-dev] [PATCH 41/44] spirv: Add a vtn_constant_value helper

--- 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 +++ b/src/compiler/spirv/vtn_private.h @@ -557,6 +557,12 @@ vtn_va

[Mesa-dev] [PATCH 33/44] intel/compiler: Call nir_lower_system_values in brw_preprocess_nir

--- src/intel/compiler/brw_nir.c| 2 ++ src/intel/vulkan/anv_pipeline.c | 1 - src/mesa/drivers/dri/i965/brw_program.c | 2 -- 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c index ce21c01..88e42d1 10064

[Mesa-dev] [PATCH 40/44] 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 dyna

[Mesa-dev] [PATCH 35/44] nir: Add a new subgroups lowering pass

This commit pulls 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 it all together in one pass. --- src/compiler/M

[Mesa-dev] [PATCH 36/44] nir: Add a ssa_dest_init_for_type helper

This would be useful a number of places --- 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 1b64490..52aea05 100644 --- a/src/compiler/nir/nir.h +++ b/src/compiler/nir/nir.h @@ -2217,6 +2217,15 @@ void nir_ss

[Mesa-dev] [PATCH 39/44] 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] [PATCH 1/3] docs/releasing: remove -jX instances

This is: Reviewed-by: Andres Gomez On Tue, 2017-09-05 at 15:21 +0100, Emil Velikov wrote: > From: Emil Velikov > > One can control the number of jobs via MAKEFLAGS. As such there's > little reason to set the number of jobs for each make invocation. > > Cc: Andres Gomez > Signed-off-by: Emil

[Mesa-dev] [PATCH 38/44] 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. --- src/compiler/nir/nir_lower_system_values.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/compile

[Mesa-dev] [PATCH 34/44] nir/opt_intrinsics: Rework progress

This commit fixes two issues: First, we were returning false regardless of whether or not the function made progress. Second, we were calling nir_metadata_preserve far more often than needed; we only need to call it once per impl. --- src/compiler/nir/nir_opt_intrinsics.c | 14 +- 1

[Mesa-dev] [PATCH 37/44] 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. --- src/compiler/glsl/glsl_to_nir.cpp | 1 + src/compiler/nir/nir_intrinsics.h | 12 ++-- src/compiler/nir/nir_lower_system_values.c | 1 + 3

[Mesa-dev] [PATCH 25/44] 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 a/src/intel/compiler/brw

[Mesa-dev] [PATCH 29/44] anv/pipeline: Dump shader immedately after spirv_to_nir

--- src/intel/vulkan/anv_pipeline.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c index d593f59..bb49e78 100644 --- a/src/intel/vulkan/anv_pipeline.c +++ b/src/intel/vulkan/anv_pipeline.c @@ -83,6 +83,15 @@ vo

[Mesa-dev] [PATCH 31/44] nir/lower_wpos_ytransform: Support system value intrinsics

--- src/compiler/nir/nir_lower_wpos_ytransform.c | 4 1 file changed, 4 insertions(+) diff --git a/src/compiler/nir/nir_lower_wpos_ytransform.c b/src/compiler/nir/nir_lower_wpos_ytransform.c index 771c6ff..425e4b8 100644 --- a/src/compiler/nir/nir_lower_wpos_ytransform.c +++ b/src/compiler/

[Mesa-dev] [PATCH 26/44] 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 e

[Mesa-dev] [PATCH 32/44] i965/program: Move nir_lower_system_values higher up

We want this to get called before nir_lower_subgroups which is going in brw_preprocess_nir. Now that nir_lower_wpos_ytransform can handle system values, this should be safe to do. --- src/mesa/drivers/dri/i965/brw_program.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src

[Mesa-dev] [PATCH 28/44] spirv: Add support for the HelperInvocation builtin

I have no idea how this got missed but it's been missing since forever. Cc: mesa-sta...@lists.freedesktop.org --- src/compiler/spirv/vtn_variables.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/compiler/spirv/vtn_variables.c b/src/compiler/spirv/vtn_variables.c ind

[Mesa-dev] [PATCH 30/44] anv/pipeline: Drop nir_lower_clip_cull_distance_arrays

We already handle it in brw_preprocess_nir --- src/intel/vulkan/anv_pipeline.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c index bb49e78..a3a1bcf 100644 --- a/src/intel/vulkan/anv_pipeline.c +++ b/src/intel/vulkan/anv_pipel

[Mesa-dev] [PATCH 27/44] intel/eu/validate: Look up types on demand in execution_type()

We are looking up the execution type prior to checking how many sources we have. This leads to looking for a type for src1 on MOV instructions which is bogus. On BDW+, the src1 register type overlaps with the 64-bit immediate and causes us problems. Reviewed-by: Matt Turner --- src/intel/compi

[Mesa-dev] [PATCH 23/44] 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 22/44] intel/eu: Use EXECUTE_1 for JMPI

The PRM says "The execution size must be 1." In 73137997e23ff6c11, the execution size was set to 1 when it should have been BRW_EXECUTE_1 (which maps to 0). Later, in dc2d3a7f5c217a7cee9, JMPI was used for line AA on gen6 and earlier and we started manually stomping the exeution size to BRW_EXECU

[Mesa-dev] [PATCH 21/44] 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 anything

[Mesa-dev] [PATCH 24/44] 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 0e36544..7ed4fb8 100644 --- a/src/intel/compiler/brw_eu_emit.c +++ b/src/intel/compiler/brw_eu_emit.c @@ -1976,6 +1976,7 @@ vo

[Mesa-dev] [PATCH 20/44] 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 approac

[Mesa-dev] [PATCH 17/44] intel/cs: Rework the way thread local ID is handled

Previously, we added an extra uniform and inserted a NIR load_uniform intrinsic so that we could let NIR optimize it while avoiding adding a new NIR intrinsic. However, this ends up being a dirtier solution than one would like. This commit changes adds a new NIR intrinsic for intel thread local I

[Mesa-dev] [PATCH 18/44] 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. --- src/intel/compiler/brw_fs.c

[Mesa-dev] [PATCH 16/44] 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 3cab7ff..90d9b22 100644 --- a/src/intel/compiler/brw_fs.c

[Mesa-dev] [PATCH 19/44] 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 th

[Mesa-dev] [PATCH 15/44] 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 6753a8d..930c5b8 100644

[Mesa-dev] [PATCH 14/44] intel/cs: Drop min_dispatch_width checks from compile_cs

The only things that adjust min_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 b/src/intel/compiler/brw_fs.

[Mesa-dev] [PATCH 13/44] 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 ++--- src/intel

[Mesa-dev] [PATCH 12/44] 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 fro

[Mesa-dev] [PATCH 08/44] 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 c46998a..2ec05a7 100644 --- a/src/intel/compiler/brw_fs_nir.cpp +++ b/src/intel

[Mesa-dev] [PATCH 11/44] 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. --- src/intel/compiler/b

[Mesa-dev] [PATCH 10/44] 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 b/s

[Mesa-dev] [PATCH 09/44] 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 eb9b4c3..f29e47c 100644 --- a/src/intel/compiler/brw_fs.cpp +++ b/src/intel/compiler/brw_fs.cpp @@ -2417,8 +2417,14 @

[Mesa-dev] [PATCH 03/44] i965/fs/nir: Use the nir_src_bit_size helper

--- src/intel/compiler/brw_fs_nir.cpp | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/src/intel/compiler/brw_fs_nir.cpp b/src/intel/compiler/brw_fs_nir.cpp index d760946..18c5fc6 100644 --- a/src/intel/compiler/brw_fs_nir.cpp +++ b/src/intel/compiler/brw_fs_nir.cp

[Mesa-dev] [PATCH 01/44] nir/opcodes: Fix constant-folding of ufind_msb

We didn't fold correctly in the case of 0x1 because we never let the loop counter hit 0. Switching it to bit >= 0 solves this problem. Reviewed-by: Bas Nieuwenhuizen Reviewed-by: Connor Abbott Cc: mesa-sta...@lists.freedesktop.org --- src/compiler/nir/nir_opcodes.py | 2 +- 1 file changed, 1 i

[Mesa-dev] [PATCH 05/44] 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. --- src/in

[Mesa-dev] [PATCH 06/44] 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. --- src/intel/co

[Mesa-dev] [PATCH 07/44] 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 outp

[Mesa-dev] [PATCH 04/44] i965/fs: Add brw_reg_type_from_bit_size utility method

From: Alejandro Piñeiro Returns the brw_type for a given ssa.bit_size, and a reference type. So if bit_size is 64, and the reference type is BRW_REGISTER_TYPE_F, it returns BRW_REGISTER_TYPE_DF. The same applies if bit_size is 32 and reference type is BRW_REGISTER_TYPE_HF it returns BRW_REGISTER_

[Mesa-dev] [PATCH 02/44] nir: Get rid of the variable on vote intrinsics

This looks like a copy+paste error. They don't actually write into that variable as would be implied by putting the return there. --- src/compiler/glsl/glsl_to_nir.cpp | 2 -- src/compiler/nir/nir_intrinsics.h | 6 +++--- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/src/compiler

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

I've been working for the past couple of weeks on the up-and-coming Vulkan SPIR-V subgroups extensions. No spec is is public yet so I can't send full patches, but I do have it working. :-) (I don't mind mentioning it because the existence of such extensions has been announced at GDC and other pub

Re: [Mesa-dev] [PATCH 2/3] mesa: replace date/time macros with MESA_GIT_SHA1

Hi, On 05.09.2017 17:23, Emil Velikov wrote: From: Emil Velikov Former is non-deterministic and compilers throw a warning about it. Cc: Rob Herring Signed-off-by: Emil Velikov --- I think the patch is a good idea, although kind of split about it. Any arguments for/against would be appreciat

Re: [Mesa-dev] [PATCH 2/3] mesa: replace date/time macros with MESA_GIT_SHA1

On Tue, Sep 5, 2017 at 9:23 AM, Emil Velikov wrote: > From: Emil Velikov > > Former is non-deterministic and compilers throw a warning about it. > > Cc: Rob Herring > Signed-off-by: Emil Velikov > --- > I think the patch is a good idea, although kind of split about it. > Any arguments for/again

Re: [Mesa-dev] [PATCH 2/3] mesa: replace date/time macros with MESA_GIT_SHA1

On Tuesday, 2017-09-05 15:23:24 +0100, Emil Velikov wrote: > From: Emil Velikov > > Former is non-deterministic and compilers throw a warning about it. > > Cc: Rob Herring > Signed-off-by: Emil Velikov > --- > I think the patch is a good idea, although kind of split about it. > Any arguments f

Re: [Mesa-dev] [PATCH 3/3] docs/release-calendar: update and extend

On Tuesday, 2017-09-05 15:21:46 +0100, Emil Velikov wrote: > From: Emil Velikov > > Cc: Andres Gomez > Signed-off-by: Emil Velikov > --- > docs/release-calendar.html | 27 +-- > 1 file changed, 13 insertions(+), 14 deletions(-) > > diff --git a/docs/release-calendar.ht

Re: [Mesa-dev] [PATCH] egl: remove unused 'Screens' array from _egl_display

On Tuesday, 2017-09-05 14:48:56 +0300, Tapani Pälli wrote: > This was used by EGL_MESA_screen_surface that has been removed > in commit 7a58262e58d8edac3308777def0950032628edee. > > Signed-off-by: Tapani Pälli Reviewed-by: Eric Engestrom > --- > src/egl/main/egldisplay.h | 1 - > 1 file chang

[Mesa-dev] [PATCH 2/3] mesa: replace date/time macros with MESA_GIT_SHA1

From: Emil Velikov Former is non-deterministic and compilers throw a warning about it. Cc: Rob Herring Signed-off-by: Emil Velikov --- I think the patch is a good idea, although kind of split about it. Any arguments for/against would be appreciated. --- src/mesa/main/context.c | 10 +++---

[Mesa-dev] [PATCH 3/3] Revert "Android: add -Wno-date-time flag for clang"

This reverts commit 6dae9176d60d12de61aa03906c44f81e20ef7622. No longer needed as of last commit. Cc: Rob Herring --- Rob, this obviously depends if the previous patch lands. Regardless, are you setting the DEBUG macro yourself or the AOSP does it for you? There are a handful things controlled

[Mesa-dev] [PATCH 1/3] mesa: don't use %s for PACKAGE_VERSION macro

From: Emil Velikov The macro itself is a well defined string, which cannot cause issues with printf or other printf-like functions. All other places through Mesa already use it directly, so let's update the final two instances. Signed-off-by: Emil Velikov --- src/mesa/main/context.c | 4 ++--

[Mesa-dev] [PATCH 1/3] docs/releasing: remove -jX instances

From: Emil Velikov One can control the number of jobs via MAKEFLAGS. As such there's little reason to set the number of jobs for each make invocation. Cc: Andres Gomez Signed-off-by: Emil Velikov --- docs/releasing.html | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/

[Mesa-dev] [PATCH 2/3] docs/releasing: polish LLVM_CONFIG wording/handling

From: Emil Velikov Use concistent way to manage "non-default" llvm installations, clearly documenting it. AKA, use LLVM_CONFIG throughout and unset for the Windows/mingw builds. Cc: Andres Gomez Signed-off-by: Emil Velikov --- docs/releasing.html | 13 - 1 file changed, 8 inserti

[Mesa-dev] [PATCH 3/3] docs/release-calendar: update and extend

From: Emil Velikov Cc: Andres Gomez Signed-off-by: Emil Velikov --- docs/release-calendar.html | 27 +-- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/docs/release-calendar.html b/docs/release-calendar.html index 554eb6a540f..f95ef9f939a 100644 --- a/d

[Mesa-dev] [Bug 102530] [bisected] Kodi crashes when launching a stream - commit bd2662bf

https://bugs.freedesktop.org/show_bug.cgi?id=102530 --- Comment #12 from Alexandre Demers --- (In reply to Erik Faye-Lund from comment #11) > (In reply to Timothy Arceri from comment #9) > > (In reply to Erik Faye-Lund from comment #8) > > > Something like this? > > > > > > ---8<--- > > > > > >

[Mesa-dev] [Bug 102530] [bisected] Kodi crashes when launching a stream - commit bd2662bf

https://bugs.freedesktop.org/show_bug.cgi?id=102530 --- Comment #11 from Erik Faye-Lund --- (In reply to Timothy Arceri from comment #9) > (In reply to Erik Faye-Lund from comment #8) > > Something like this? > > > > ---8<--- > > > > diff --git a/src/mesa/main/uniform_query.cpp > > b/src/mesa/m

[Mesa-dev] [Bug 102530] [bisected] Kodi crashes when launching a stream - commit bd2662bf

https://bugs.freedesktop.org/show_bug.cgi?id=102530 --- Comment #10 from Alexandre Demers --- (In reply to Timothy Arceri from comment #6) > (In reply to Alexandre Demers from comment #5) > > Created attachment 133967 [details] > > Kodi's log after segfault > > > > This is the core dump produced

Re: [Mesa-dev] [Mesa-stable] [PATCH] spirv: Add support for the HelperInvocation builtin

On Mon, 2017-09-04 at 09:14 -0700, Jason Ekstrand wrote: > Yeah, just haven't gotten around to pushing it. Feel free. Pushed! ☺ > > > On September 4, 2017 7:33:38 AM Andres Gomez wrote: > > > Jason, has this patch fallen through the cracks ? > > > > On Mon, 2017-08-21 at 22:11 -0700, Jason E

Re: [Mesa-dev] [PATCH v2 2/2] i965: expose RGBA visuals only on Android

On 5 September 2017 at 08:44, Tapani Pälli wrote: > Hi; > > How to test these changes? I get exact same visuals on x11 (using glxinfo, > eglinfo) with or without the patch. > Upon second look that cannot happen, yet. As the masks (see attribMap in src/glx/dri_common.c) are unchecked, we currently

Re: [Mesa-dev] [PATCH] mesa/main: Fix GetTextureImage error reporting

On 09/05/2017 02:07 PM, Iago Toral Quiroga wrote: GetTex*Image should return INVALID_ENUM if target is not valid, however, GetTextureImage does not receive a target, and instead should return INVALID_OPERATION if the effective target is not valid. From the OpenGL 4.5 core profile spec, section

[Mesa-dev] [Bug 102467] src/mesa/state_tracker/st_cb_readpixels.c:178]: (warning) Redundant assignment

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

[Mesa-dev] [PATCH] mesa/main: Fix GetTransformFeedbacki64 for glTransformFeedbackBufferBase

The spec has special rules for querying buffer offsets and sizes when BindBufferBase is used, described in the OpenGL 4.6 spec, section 6.8 Buffer Object State: "To query the starting offset or size of the range of a buffer object binding in an indexed array, call GetInteger64i_v with

[Mesa-dev] [PATCH] mesa/main: Fix GetTextureImage error reporting

GetTex*Image should return INVALID_ENUM if target is not valid, however, GetTextureImage does not receive a target, and instead should return INVALID_OPERATION if the effective target is not valid. From the OpenGL 4.5 core profile spec, section 8.11 Texture Queries: "An INVALID_OPERATION error is

[Mesa-dev] [PATCH] egl: remove unused 'Screens' array from _egl_display

This was used by EGL_MESA_screen_surface that has been removed in commit 7a58262e58d8edac3308777def0950032628edee. Signed-off-by: Tapani Pälli --- src/egl/main/egldisplay.h | 1 - 1 file changed, 1 deletion(-) diff --git a/src/egl/main/egldisplay.h b/src/egl/main/egldisplay.h index 3d5a44578c..

[Mesa-dev] [PATCH 2/2] loader/dri3: Make sure we invalidate a drawable on size change

If we're seeing a drawable size change, in particular after processing a configure notify event, make sure we invalidate so that the state tracker picks up the new geometry. Signed-off-by: Thomas Hellstrom --- src/loader/loader_dri3_helper.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/

Re: [Mesa-dev] [PATCH] llvmpipe, draw: increase shader cache limits

On 05/09/17 00:28, srol...@vmware.com wrote: From: Roland Scheidegger We're not particularly concerned with memory usage, if the tradeoff is shader recompiles. And it's common for apps to have a lot of shaders nowadays (and, since our shaders include a LOT of context state of course we may crea

[Mesa-dev] [ANNOUNCE] mesa 17.2.0

Mesa 17.2.0 is now available. The release consists of 3300 commits from approximately 130 developers. Some ~300 commits while being 10 authors less, relative to Mesa 17.1.x Feature wise, this release mainly focuses on hardware driver improvements, although common code paths has also seen some lov

Re: [Mesa-dev] [PATCH 4/4] ac/debug: take ASIC generation into account when printing registers

For the series: Acked-by: Marek Olšák M. On Sep 5, 2017 8:53 AM, "Nicolai Hähnle" wrote: > On 05.09.2017 01:05, Marek Olšák wrote: > >> gfx9d.h contains almost no named values. Does it obtain named values >> from sid.h when the same field is also present in gfx9d.h? >> > > One possible differ

[Mesa-dev] [Bug 102542] mesa-17.2.0/src/gallium/state_trackers/nine/nine_ff.c:1938: bad assignment ?

https://bugs.freedesktop.org/show_bug.cgi?id=102542 --- Comment #1 from Axel Davy --- As mentionned, this is just a style issue, because the conversion is implicit. I'll push a patch to make the conversion explicit. -- You are receiving this mail because: You are the assignee for the bug. You

[Mesa-dev] [PATCH] Android: fix radeonsi building errors on Android O

The radeonsi driver fails in the error: [ 5% 200/3583] target C++: libmesa_amd_common_32 <= external/mesa/src/amd/common/ac_llvm_helper.cpp In file included from external/mesa/src/amd/common/ac_llvm_helper.cpp:35: In file included from external/llvm/include/llvm/ExecutionEngine/ExecutionEngine

[Mesa-dev] [Bug 102542] mesa-17.2.0/src/gallium/state_trackers/nine/nine_ff.c:1938: bad assignment ?

https://bugs.freedesktop.org/show_bug.cgi?id=102542 Bug ID: 102542 Summary: mesa-17.2.0/src/gallium/state_trackers/nine/nine_ff.c: 1938: bad assignment ? Product: Mesa Version: 17.2 Hardware: Other OS: All

[Mesa-dev] [PATCH 1/2] loader/dri3: Process event after each fence wait

This tries to mimic dri2 behaviour where events are typically processed while waiting for X replies. Since, during steady-state dri3 rendering, we seldom wait for xcb replies, and haven't enabled any automatic event processing, instead check for events after a fence wait. Signed-off-by: Thomas Hel

Re: [Mesa-dev] [PATCH 2/2] loader/dri3: Invalidate the drawable after copySubBuffer

On 09/05/2017 08:50 AM, Thomas Hellstrom wrote: Hi, Michel, [...] I guess what could perhaps be done is to process any received events in dri3_fence_await, and invalidate only if we see a drawable change to try to mimic dri2 behaviour.. Actually this seems like a better and more general a

[Mesa-dev] [Bug 102530] [bisected] Kodi crashes when launching a stream - commit bd2662bf

https://bugs.freedesktop.org/show_bug.cgi?id=102530 --- Comment #9 from Timothy Arceri --- (In reply to Erik Faye-Lund from comment #8) > Something like this? > > ---8<--- > > diff --git a/src/mesa/main/uniform_query.cpp > b/src/mesa/main/uniform_query.cpp > index c6488325a8..642c93270f 100644

Re: [Mesa-dev] RGB10 bit rendering support for OpenGL + Intel i965

Hi; On 09/05/2017 08:01 AM, Mario Kleiner wrote: Hi, this patch series adds support to the i965 classic Mesa driver for ARGB2101010 and XRGB2101010 fbconfigs/visuals for X11/GLX, X11/EGL and Wayland/EGL, and for rendering into those winsys framebuffers with 10 bpc precision. FYI I believe dEQ

[Mesa-dev] [PATCH v2] radeonsi/gfx9: proper workaround for LS/HS VGPR initialization bug

From: Nicolai Hähnle When the HS wave is empty, the hardware writes the LS VGPRs starting at v0 instead of v2. Workaround by shifting them back into place when necessary. For simplicity, this is always done in the LS prolog. According to the hardware team, this will be fixed in future chips, so

Re: [Mesa-dev] [PATCH 1/2] loader/dri3: Use client local back to front blit in copySubBuffer if available

Hi, On 05/09/2017 08:37, Thomas Hellstrom wrote: Hi! On 09/05/2017 07:36 AM, Axel Davy wrote: On 04/09/2017 14:27, Thomas Hellstrom wrote: The copySubBuffer functionality always attempted a server side blit from back to fake front if a fake front was present, and we weren't displaying on a

Re: [Mesa-dev] [PATCH v2 2/2] i965: expose RGBA visuals only on Android

Hi; How to test these changes? I get exact same visuals on x11 (using glxinfo, eglinfo) with or without the patch. On 07/31/2017 09:46 PM, Emil Velikov wrote: From: Emil Velikov As Marek pointed out in earlier commit - exposing RGBA on other platforms introduces ~500 Visuals, which are not

Re: [Mesa-dev] [PATCH 1/2] loader/dri3: Use client local back to front blit in copySubBuffer if available

On 09/05/2017 08:49 AM, Axel Davy wrote: Hi, [...] Reviewed-by: Axel Davy Thanks for reviewing, Axel. /Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] loader/dri3: Invalidate the drawable after copySubBuffer

Hi, Michel, On 09/05/2017 06:02 AM, Michel Dänzer wrote: On 04/09/17 09:27 PM, Thomas Hellstrom wrote: Anyone using copySubBuffer as a replacement for swapBuffers would probably want window resizing to update the viewport. Signed-off-by: Thomas Hellstrom --- src/loader/loader_dri3_helper.c

Re: [Mesa-dev] [PATCH 4/4] ac/debug: take ASIC generation into account when printing registers

On 05.09.2017 01:05, Marek Olšák wrote: gfx9d.h contains almost no named values. Does it obtain named values from sid.h when the same field is also present in gfx9d.h? Yes, the following snippet does that: +# Copy values for corresponding fields from older ASICs if they were +

<    1   2