Re: aapoint issue

Can you test https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32313 ? On 11/14/24 12:57 AM, Erik Faye-Lund wrote: Yeah, that looks like a mistake, indeed. Do you mind submitting a patch on GitLab for it? The problem seems to originate from this commit (CCed ian): https://gitlab.freede

Re: time for amber2 branch?

On 6/20/24 7:20 AM, Erik Faye-Lund wrote: On Wed, 2024-06-19 at 10:33 -0400, Mike Blumenkrantz wrote: In looking at the gallium tree, I'm wondering if it isn't time for a second amber branch to prune some of the drivers that cause pain when doing big tree updates: * nv30 * r300 * r600 * lima *

Re: Replacing NIR with SPIR-V?

On 1/23/22 12:10 PM, Dave Airlie wrote: On Sun, 23 Jan 2022 at 22:58, Abel Bernabeu wrote: Yes, NIR arrays and struct and nir_deref to deal with them but, by the time you get into the back-end, all the nir_derefs are gone and you're left with load/store messages with actual addresses (either

Re: git and Marge troubles this week

Blarg. That all sounds awful. I think (hope!) I speak for everyone when I say that we all appreciate your and daniels' efforts to keep this big piece of machinery working. If the problems persist much longer, should we consider pushing out the 22.0 branch point? On 1/6/22 9:36 PM, Emma Anho

[Mesa-dev] One more thing to cut from the main branch...

If we're going to cut all the classic drivers and a handful of older Gallium drivers... can we also cut Apple GLX? Apple comes around every couple years to fix breakages that have crept in, and we periodically have compile breaks that need fixing (see https://gitlab.freedesktop.org/mesa/mesa/-/iss

Re: [Mesa-dev] [PATCH v3 3/4] drm/i915/uapi: convert i915_query and friend to kernel doc

On 4/15/21 8:59 AM, Matthew Auld wrote: > Add a note about the two-step process. > > Suggested-by: Daniel Vetter > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Jordan Justen > Cc: Daniel Vetter > Cc: Kenneth Graunke > Cc: Jason Ekstrand > Cc: Dave Airlie > Cc: dri-de...@lists.fr

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

On 3/25/21 3:13 PM, Jason Ekstrand wrote: > On Thu, Mar 25, 2021 at 4:32 PM Kenneth Graunke wrote: >> >> On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote: >>> On 3/25/21 10:49 AM, Jason Ekstrand wrote: >>> Can you be more specific? Also, is there a

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

he current testing problem. Right now, r200 and i915 are poorly tested, but 965G through Sandybridge are very well tested. While I can totally test core changes on r200 and i915, how would I verify that those changes don't break, say, Ironlake? > --Jason > > On Tue, Mar 23, 2021 at

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

I would like to wait a couple more releases to do this. I have a couple things that I've been gradually working on for some of the non-i965 classic drivers that I'd like to land before they're put out to pasture. I talked to ajax about this a few weeks ago, and he was amenable at the time. I can

Re: [Mesa-dev] docs: consistent language

On 3/15/21 5:44 AM, Erik Faye-Lund wrote: > TLDR; I'm proposing to standardize on US English in our public-facing > documentation. > > I proposed an MR a while back that changed the only occurrence of the > UK English spelling "optimisation" for the US English spelling > "optimization", which is a

Re: [Mesa-dev] SpvOpSelect w/ float operands

On 11/17/20 9:25 AM, Brian Paul wrote: > > Using the Intel Vulkan driver, we've found some cases where SpvOpSelect > is returning -0.0 (negative zeros) instead of normal 0.0 depending on > the arguments. Do you have a specific test case that fails? It seems like on some platforms there was an er

Re: [Mesa-dev] GLSLstd450NMin/NMax/NClamp

On 11/17/20 9:25 AM, Brian Paul wrote: > > It appears these SPIR-V extension functions don't behave as they should > on Intel (don't know about other Vulkan drivers). > > They're supposed to be NaN-aware such that if one argument is NaN, the > other argument is returned.  From our testing, it loo

Re: [Mesa-dev] piglit merge access

As one of the people guilty of forgetting to push your MRs... this is a very reasonable request, and I support it fully. On 10/13/20 1:12 AM, andrey simiklit wrote: > Hi, > > I would like to request merge access for piglit gitlab. I have > contributed a number of commits for mesa/piglit. It would

Re: [Mesa-dev] Rename "master" branch to "main"?

On 8/3/20 8:30 AM, Jason Ekstrand wrote: > All, > > I'm sure by now you've all seen the articles, LKML mails, and other > chatter around inclusive language in software. While mesa doesn't > provide a whole lot of documentation (hah!), we do have a website, a > code-base, and a git repo and this i

Re: [Mesa-dev] nir: find_msb vs clz

On 4/1/20 11:52 AM, Eric Anholt wrote: > I would generally be of the opinion that we should have NIR opcodes > that match any common hardware instructions, and lowering in algebraic > to help turn input patterns into clean sequences of hardware > instructions. There is quite a bit of benefit to ha

Re: [Mesa-dev] nir: find_msb vs clz

On 4/1/20 11:39 AM, Erik Faye-Lund wrote: > While working on the NIR to DXIL conversion code for D3D12, I've > noticed that we're not exactly doing the best we could here. > > First some background: > > NIR currently has a few instructions that does kinda the same: > > 1. nir_op_ufind_msb: Finds

Re: [Mesa-dev] [PATCH kmscube] texturator: Use !! for boolean assignment

On 3/31/20 12:25 PM, Fabio Estevam wrote: > The 'complemented' variable is a pointer to boolean. Use the !! operator > to fix the following build warning: > > ../texturator.c:603:45: warning: '*' in boolean context, suggest '&&' instead > [-Wint-in-bool-context] > *complemented = (((float)rgba[

Re: [Mesa-dev] [RFC PATCH] Add GL_MESA_ieee_fp_alu_mode specification draft

On 2/24/20 11:21 AM, Ilia Mirkin wrote: > On Mon, Feb 24, 2020 at 1:10 PM Ian Romanick wrote: >> >> On 2/23/20 5:57 PM, Ilia Mirkin wrote: >>> --- >>> >>> We talked about something like this a while back, but the end result >>> was inconclusiv

Re: [Mesa-dev] [RFC PATCH] Add GL_MESA_ieee_fp_alu_mode specification draft

On 2/23/20 5:57 PM, Ilia Mirkin wrote: > --- > > We talked about something like this a while back, but the end result > was inconclusive. I added a TGSI MUL_ZERO_WINS shader property for nine. > But it'd be nice for wine to be able to control this too. > > I couldn't actually find any evidence of

Re: [Mesa-dev] Merging experimental r600/nir code

On 2/12/20 10:46 AM, Marek Olšák wrote: > How do you enable LTO+PGO? Is it something we could enable by default > for release builds? I'm assuming PGO is "profile guided optimization." That requires a cycle of build, run workloads to collect data, rebuild with collected data. It would be awesome

Re: [Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)

On 1/20/20 6:41 AM, Stefan Dirsch wrote: > Hi > > Starting from the upcoming GCC release 10, the default of -fcommon option will > change to -fno-common. Due to this we're going to see a lot of build failures It seems like many of the places where this would occur in Mesa are likely to be fine...

Re: [Mesa-dev] Requiring a full author name when contributing to mesa?

On 12/11/19 2:27 PM, Timothy Arceri wrote: > Hi, > > So it seems lately we have been increasingly merging patches with made > up names, or single names etc [1]. The latest submitted patch has the > name Icecream95. This seems wrong to me from a point of keeping up the > integrity of the project. I

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

On 12/3/19 10:48 PM, Marek Olšák wrote: > On Wed., Dec. 4, 2019, 01:20 Tapani Pälli, > wrote: > > Hi; > > On 12/4/19 2:39 AM, Marek Olšák wrote: > > Hi, > > > > Here are 2 proposals to simplify and better optimize the GL->Gallium > > transla

Re: [Mesa-dev] [PATCH] nir: no-op C99 _Pragma() with MSVC

d up the debug builds in the pre-merge CI. Reviewed-by: Ian Romanick > Signed-off-by: Brian Paul > --- > src/compiler/nir/nir_range_analysis.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/src/compiler/nir/nir_range_analysis.c > b/src/compiler/nir/nir_ran

Re: [Mesa-dev] [2/2] state_tracker: Handle texture view min level in st_generate_mipmap()

On 11/1/19 12:47 PM, Paul Gofman wrote: > On 11/1/19 22:19, Ilia Mirkin wrote: >> It looks like the _mesa_generate_mipmap fallback has a similar problem >> (which would happen for glGenerateMipmap with e.g. a s3tc format). > > It looks to me it doesn't. I hit this path in the tests I am running >

Re: [Mesa-dev] Update on Khronos conformance submissions

On 10/15/19 1:38 AM, Daniel Vetter wrote: > Hi all, > > At XDC and with a few follow ups with Neil we've clarified the process > for submitting conformance results to get the GL/VK trademarks and > everything: > > https://www.x.org/wiki/Khronos/ > > Big update is that we've had a misunderstandin

Re: [Mesa-dev] [PATCH] st/nir: fix illegal designated initializer in st_glsl_to_nir.cpp

On 9/10/19 10:53 PM, Brian Paul wrote: > IIRC, designated initializers are not legal C++. > Fixes the MSVC build. > > Fixes: 83fd1e58 ("glsl/nir: Add and use a gl_nir_link() function") > --- > src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > d

Re: [Mesa-dev] Extension help

On 8/2/19 1:13 PM, Fritz Koenig wrote: > Hi, > > I would like to be able to use the MESA_framebuffer_flip_y extension > in GLES 3.0. The blocker is that FramebufferParameteri is not part of > GLES 3.0. I have explored a couple of ways of achieving this. > > 1. FramebufferParameteri was first

Re: [Mesa-dev] [PATCH] egl: fix OpenGL 3.1 context creation

On 8/2/19 12:39 PM, Ian Romanick wrote: > On 8/1/19 6:38 PM, Timothy Arceri wrote: >> From the EGL_KHR_create_context spec: >> >>"* If OpenGL 3.1 is requested, the context returned may implement >>any of the following versions: >> >>

Re: [Mesa-dev] [PATCH] egl: fix OpenGL 3.1 context creation

On 8/1/19 6:38 PM, Timothy Arceri wrote: > From the EGL_KHR_create_context spec: > >"* If OpenGL 3.1 is requested, the context returned may implement >any of the following versions: > > * Version 3.1. The GL_ARB_compatibility extension may or may >not be implement

Re: [Mesa-dev] Mesa (update-reviewers-for-vmware): i965/clear: clear_value better precision

On 8/2/19 9:12 AM, Brian Paul wrote: > On 08/02/2019 09:56 AM, Eric Engestrom wrote: >> On Friday, 2019-08-02 17:50:17 +0200, Michel Dänzer wrote: >>> On 2019-08-02 5:37 p.m., Brian Paul wrote: Ugh, I didn't mean to do this.  I'm trying to figure out how to make a merge request with gitla

[Mesa-dev] [PATCH] mesa: Set minimum possible GLSL version

From: Ian Romanick Set the absolute minimum possible GLSL version. API_OPENGL_CORE can mean an OpenGL 3.0 forward-compatible context, so that implies a minimum possible version of 1.30. Otherwise, the minimum possible version 1.20. Since Mesa unconditionally advertises

Re: [Mesa-dev] [PATCH] mesa: avoid _mesa_problem invocation when running on drivers without glsl

On 7/4/19 4:21 PM, Ilia Mirkin wrote: > For example wine might query GL_SHADING_LANGUAGE_VERSION on a driver > that doesn't support GLSL. This is not a problem in itself, we can just > return a INVALID_ENUM error. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109524 > Signed-off-by: I

[Mesa-dev] What does WIP really mean in an MR?

After a conversation yesterday with a couple of the other Intel devs, I've come to the conclusion that *everyone* interprets WIP to mean something different. I heard no less than four interpretations. * This series is good. It hasn't been reviewed, so don't click "merge." * This series has some

Re: [Mesa-dev] [PATCH] intel_stub: Wrap fcntl64

ely forgot about it. :) > --Jason > > On Fri, Jun 7, 2019 at 11:27 AM Emil Velikov <mailto:emil.l.veli...@gmail.com>> wrote: > > On Fri, 7 Jun 2019 at 00:30, Ian Romanick <mailto:i...@freedesktop.org>> wrote: > > > > From: Ian Romanick

Re: [Mesa-dev] Possible bug in nir_algebraic?

27;s state list in C, and then have a debugging option to print > the match set for each instruction so you'd know where something went > awry. I didn't do that earlier since I didn't have a need for it while > bringing up the automaton, but we could add it if it he

[Mesa-dev] Possible bug in nir_algebraic?

I have encountered what I believe to be a bug in nir_algebraic. Since the rewrite to use automata, I'm not sure how to begin debugging it. I'm looking for some suggestions... even if the suggestion is, "Fix your patterns." I have added a pattern like: (('~fadd@32', ('fmul', ('fadd', 1.0, ('fn

Re: [Mesa-dev] [PATCH 1/2] util: Add util_is_power_of_two_minus_one

ler. > latter function implemented similarly). Still, it's worth having a > dedicated check for this; semantically, in the context of masks, this > check is meaningful standalone, justifying an independent implementation > from the existing util_is_power_of_two* utilites. > &g

[Mesa-dev] [PATCH] intel_stub: Wrap fcntl64

From: Ian Romanick This makes the wrapper work on glibc 2.29 on Fedora 30. --- intel_stub.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/intel_stub.c b/intel_stub.c index 8b8db64..590792e 100644 --- a/intel_stub.c +++ b/intel_stub.c @@ -50,6 +50,7 @@ static int

Re: [Mesa-dev] [RFC PATCH] nir/algebraic: Simplify max(abs(a), 0.0) -> abs(a)

), could someone do a >> shader-db run? Thank you! >> >> Signed-off-by: Alyssa Rosenzweig >> Cc: Ian Romanick >> --- >> src/compiler/nir/nir_opt_algebraic.py | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/src/compiler/nir/nir_opt_alg

Re: [Mesa-dev] [PATCH] i965/tex: ignore the diff between GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE

On 5/21/19 4:36 AM, Olivier Fourdan wrote: > Hi all, > > On Thu, Jul 19, 2018 at 12:08 PM andrey simiklit > wrote: >>> Ugh... not so good. According to Oliver on the bug, this just make the >>> assert go away and doesn't actually fix anything. Likely this is needed >>> but not sufficient. >>

Re: [Mesa-dev] [PATCH] docs/features: don't list EXT extensions in a list for KHR/ARB/OES extensions

On 5/17/19 6:24 AM, Eric Engestrom wrote: > On 2019-05-16 at 18:34, Ian Romanick wrote: >> On 5/15/19 7:39 AM, Gert Wollny wrote: >>> How about moving these extensions to another (new) section? I think it >>> is nice to have a one-stop place to find out what is

Re: [Mesa-dev] [PATCH] docs/features: don't list EXT extensions in a list for KHR/ARB/OES extensions

On 5/15/19 7:39 AM, Gert Wollny wrote: > How about moving these extensions to another (new) section? I think it > is nice to have a one-stop place to find out what is supported. Given the existence of mesamatrix.net, is that useful? When we started this file, the purpose was to track work that p

Re: [Mesa-dev] [PATCH] docs/features: don't list EXT extensions in a list for KHR/ARB/OES extensions

Reviewed-by: Ian Romanick On 5/14/19 1:07 PM, Marek Olšák wrote: > From: Marek Olšák > > --- > docs/features.txt | 10 -- > 1 file changed, 10 deletions(-) > > diff --git a/docs/features.txt b/docs/features.txt > index 38d6186dbe1..b1799550a0c 100644 > ---

Re: [Mesa-dev] [PATCH] st/mesa: fix uninitialized lower_flrp_progress variable

I sent an MR for this and the other cases earlier this morning. On May 8, 2019 9:20:16 AM Brian Paul wrote: The 'progress' variable is initialized to false in other locations. This fixes a new Coverity warning. --- src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +- 1 file changed, 1 insertion(+)

Re: [Mesa-dev] [PATCH 1/7] compiler: Add enums for blend state

This commit is Reviewed-by: Ian Romanick On 5/5/19 7:26 PM, Alyssa Rosenzweig wrote: > We add enums corresponding to (GLES) blend state to shader_enums.h, > complementing the existing advanced blending enums in the file. This > allows us to represent blending state in a driver-agno

Re: [Mesa-dev] [PATCH 3/7] nir: Add blend_const_color_rgba sysval

This commit is Reviewed-by: Ian Romanick On 5/5/19 7:26 PM, Alyssa Rosenzweig wrote: > This represents a float vec4 constant color, as passed to glBlendColor. > While the existing 4 shader sysvals are retained to minimize code churn, > a single vectorized intrinsic is required for

Re: [Mesa-dev] [PATCH 4/7] nir: Add nir_lower_blend pass

On 5/5/19 7:26 PM, Alyssa Rosenzweig wrote: > This new lowering pass implements the OpenGL ES blend pipeline in > shaders, applicable to hardware lacking full-featured blending hardware > (including Midgard/Bifrost and vc4). This pass is run on a fragment > shader, rewriting the store to a blended

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

om before / after NIR. > On 5/7/19 8:01 AM, GitLab Mirror wrote: >> Module: Mesa >> Branch: master >> Commit: 5b908db604b2f47bb8382047533e556db8d5f52b >> URL:    >> http://cgit.freedesktop.org/mesa/mesa/commit/?id=5b908db604b2f47bb8382047533e556db8d5f52b >> >>

Re: [Mesa-dev] [PATCH 1/2] nir: Add inverted bitwise ops

specific code on affected > architectures, e.f. 8eb36c91 ("intel/fs: Emit logical-not of operands on > Gen8+"). > > Signed-off-by: Alyssa Rosenzweig > Cc: Ian Romanick > Cc: Kenneth Graunke > --- > src/compiler/nir/nir.h| 4 >

[Mesa-dev] [PATCH] glsl: Silence may unused parameter warnings in glsl/ir.h

From: Ian Romanick Every file that included glsl/ir.h had a warning like: src/compiler/glsl/ir.h: In member function ‘virtual bool ir_rvalue::is_lvalue(const _mesa_glsl_parse_state*) const’: src/compiler/glsl/ir.h:236:64: warning: unused parameter ‘state’ [-Wunused-parameter] virtual bool

Re: [Mesa-dev] [PATCH v3 1/2] nir: Add nir_lower_viewport_transform

This patch is Reviewed-by: Ian Romanick On 4/12/19 4:46 PM, Alyssa Rosenzweig wrote: > On Mali hardware (supported by Panfrost and Lima), the fixed-function > transformation from world-space to screen-space coordinates is done in > the vertex shader prior to writing out the gl_Positio

Re: [Mesa-dev] [PATCH v2 1/2] nir: Add nir_lower_viewport_transform

On 4/12/19 5:11 PM, Ian Romanick wrote: > On 4/8/19 5:34 AM, Thomas Helland wrote: >> man. 8. apr. 2019 kl. 06:30 skrev Alyssa Rosenzweig : >>> >>> On Mali hardware (supported by Panfrost and Lima), the fixed-function >>> transformation from world-space to

Re: [Mesa-dev] [PATCH v2 1/2] nir: Add nir_lower_viewport_transform

On 4/8/19 5:34 AM, Thomas Helland wrote: > man. 8. apr. 2019 kl. 06:30 skrev Alyssa Rosenzweig : >> >> On Mali hardware (supported by Panfrost and Lima), the fixed-function >> transformation from world-space to screen-space coordinates is done in >> the vertex shader prior to writing out the gl_Pos

Re: [Mesa-dev] new dispatch generator broke with Marek's parallel compile commit

On 4/3/19 10:20 AM, Emil Velikov wrote: > On Tue, 2 Apr 2019 at 20:00, Ian Romanick wrote: >> >> On 4/2/19 4:43 AM, Emil Velikov wrote: >>> On Tue, 2 Apr 2019 at 04:55, Dave Airlie wrote: >>>> >>>> On Tue, 2 Apr 2019 at 11:24, Dave

Re: [Mesa-dev] new dispatch generator broke with Marek's parallel compile commit

On 4/2/19 4:43 AM, Emil Velikov wrote: > On Tue, 2 Apr 2019 at 04:55, Dave Airlie wrote: >> >> On Tue, 2 Apr 2019 at 11:24, Dave Airlie wrote: >>> >>> Marek's commit to add ARB_parallel_shader_compile broke some es1 tests >>> in the Intel CI. >>> >>> It appears the whatever generates the es1api i

Re: [Mesa-dev] [PATCH] util: no-op __builtin_types_compatible_p() for non-GCC compilers

On 3/29/19 1:54 PM, Brian Paul wrote: > On 03/29/2019 12:58 PM, Ian Romanick wrote: >> On 3/29/19 9:57 AM, Brian Paul wrote: >>> __builtin_types_compatible_p() is GCC-specific and breaks the >>> MSVC build. >>> >>> This intrinsic has been in u_vector_

Re: [Mesa-dev] [PATCH] util: no-op __builtin_types_compatible_p() for non-GCC compilers

On 3/29/19 9:57 AM, Brian Paul wrote: > __builtin_types_compatible_p() is GCC-specific and breaks the > MSVC build. > > This intrinsic has been in u_vector_foreach() for a long time, but > that macro has only recently been used in code > (nir/nir_opt_comparison_pre.c) that's built with MSVC. > >

Re: [Mesa-dev] [PATCH 3/3] intel/compiler: implement more algebraic optimizations

On 2/28/19 4:47 AM, Iago Toral wrote: > On Wed, 2019-02-27 at 17:04 -0800, Ian Romanick wrote: >> On 2/27/19 4:45 AM, Iago Toral Quiroga wrote: >>> Now that we propagate constants to the first source of 2src >>> instructions we >>> see more opportunitie

Re: [Mesa-dev] [PATCH 3/3] intel/compiler: implement more algebraic optimizations

On 2/27/19 4:45 AM, Iago Toral Quiroga wrote: > Now that we propagate constants to the first source of 2src instructions we > see more opportunities of constant folding in the backend. > > Shader-db results on KBL: > > total instructions in shared programs: 14965607 -> 14855983 (-0.73%) > instruc

Re: [Mesa-dev] [PATCH 3/3] intel/compiler: implement more algebraic optimizations

On 2/27/19 4:45 AM, Iago Toral Quiroga wrote: > Now that we propagate constants to the first source of 2src instructions we > see more opportunities of constant folding in the backend. All the benefit of the series is from more constant folding? Once upon a time, I had a patch that added another

Re: [Mesa-dev] [PATCH 3/9] nir: Add a new ALU nir_op_imad24_ir3

On 2/13/19 1:29 PM, Eduardo Lima Mitev wrote: > ir3 compiler has an integer multiply-add instruction (MAD_S24) > that is used for different offset calculations in the backend. > Since we intend to move some of these calculations to NIR, we need > a new ALU op that can directly represent it. > --- >

Re: [Mesa-dev] [PATCH] nir/algebraic: Replace a-fract(a) with floor(a)

On 2/23/19 4:11 PM, Timothy Arceri wrote: > > > On 23/2/19 4:09 pm, Ian Romanick wrote: >> From: Ian Romanick >> >> I noticed this while looking at a shader that was affected by Tim's >> "more loop unrolling" series. >> >> All G

[Mesa-dev] [PATCH] nir/algebraic: Replace a-fract(a) with floor(a)

From: Ian Romanick I noticed this while looking at a shader that was affected by Tim's "more loop unrolling" series. All Gen6+ platforms had similar results. (Skylake shown) total instructions in shared programs: 15437001 -> 15435259 (-0.01%) instructions in affected programs

Re: [Mesa-dev] [PATCH] nir/builder: Don't emit no-op swizzles

Reviewed-by: Ian Romanick On 2/22/19 4:03 PM, Jason Ekstrand wrote: > The nir_swizzle helper is used some on it's own but it's also called by > nir_channel and nir_channels which are used everywhere. It's pretty > quick to check while we're walking the swizzle an

[Mesa-dev] [PATCH] spirv: Add missing break

From: Ian Romanick Fixes: c6465fec0c5 ("spirv: add SpvCapabilityInt64Atomics") CID: 1442555 --- src/compiler/spirv/spirv_to_nir.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/compiler/spirv/spirv_to_nir.c b/src/compiler/spirv/spirv_to_nir.c index 1cbc926c818..5e8eb222

Re: [Mesa-dev] [PATCH 2/4] nir: turn ssa check into an assert

On 2/13/19 12:00 AM, Timothy Arceri wrote: > Everthing should be in ssa form when this is called. Checking > for it here is expensive so turn this into an assert instead. > > Do the cheap thing first and check if we can even progress with > this instruction type. > --- > src/compiler/nir/nir_inst

Re: [Mesa-dev] [PATCH] nir: move ALU instruction before the jump instruction

On 2/13/19 9:59 AM, Juan A. Suarez Romero wrote: > On Wed, 2019-02-13 at 09:16 -0800, Ian Romanick wrote: >> On 2/13/19 7:53 AM, Juan A. Suarez Romero wrote: >>> On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote: >>>> On 2/12/19 12:58 AM, Juan A. Suarez Romero wro

Re: [Mesa-dev] [PATCH] nir: move ALU instruction before the jump instruction

On 2/13/19 7:53 AM, Juan A. Suarez Romero wrote: > On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote: >> On 2/12/19 12:58 AM, Juan A. Suarez Romero wrote: >>> opt_split_alu_of_phi moves ALU instruction to the end of continue block. >>> >>> But if the continu

Re: [Mesa-dev] [PATCH] nir: move ALU instruction before the jump instruction

problem in practice... or were you able to trigger it somehow? > CC: Ian Romanick > Fixes: 0881e90c099 ("nir: Split ALU instructions in loops that read phis") > --- > src/compiler/nir/nir_opt_if.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --g

Re: [Mesa-dev] [PATCH] nir: allow stitching of non-empty block

On 2/8/19 5:21 AM, Juan A. Suarez Romero wrote: > On Sat, 2019-01-26 at 08:37 -0800, Jason Ekstrand wrote: >> This makes me a bit nervous. I'll have to look at it in more detail. >> > > Did you have time to take a look at this? Is there a test case that hits this? Was it found by inspection? I'

Re: [Mesa-dev] [PATCH 05/12] nir: rename global/local to private/function memory

On 1/8/19 9:57 PM, Kenneth Graunke wrote: > On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote: >> the naming is a bit confusing no matter how you look at it. Within SPIR-V >> "global" memory is memory accessible from all threads. glsl "global" memory >> normally refers to shader threa

Re: [Mesa-dev] [PATCH 6/7] util/queue: add util_queue_adjust_num_threads

This patch is Reviewed-by: Ian Romanick On 11/28/18 6:59 PM, Marek Olšák wrote: > From: Marek Olšák > > for ARB_parallel_shader_compile > --- > src/util/u_queue.c | 50 -- > src/util/u_queue.h | 8 > 2 files changed

Re: [Mesa-dev] [PATCH 5/7] util/queue: hold a lock when reading num_threads in util_queue_finish

This patch is Reviewed-by: Ian Romanick On 11/28/18 6:59 PM, Marek Olšák wrote: > From: Marek Olšák > > --- > src/util/u_queue.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/src/util/u_queue.c b/src/util/u_queue.c > index 5aaf60a

Re: [Mesa-dev] [PATCH 4/7] util/queue: add ability to kill a subset of threads

On 11/28/18 6:59 PM, Marek Olšák wrote: > From: Marek Olšák > > for ARB_parallel_shader_compile > --- > src/util/u_queue.c | 49 +- > src/util/u_queue.h | 5 ++--- > 2 files changed, 33 insertions(+), 21 deletions(-) > > diff --git a/src/util/u_queue

Re: [Mesa-dev] [PATCH 3/7] util/queue: move thread creation into a separate function

Looks to be a simple enough refactor. This patch is Reviewed-by: Ian Romanick On 11/28/18 6:59 PM, Marek Olšák wrote: > From: Marek Olšák > > --- > src/util/u_queue.c | 56 ++ > 1 file changed, 32 insertions(+), 24 deletions(-) &g

Re: [Mesa-dev] [PATCH 1/7] mesa: implement ARB/KHR_parallel_shader_compile

On 1/3/19 11:40 AM, Ian Romanick wrote: > On 11/28/18 6:59 PM, Marek Olšák wrote: >> From: Marek Olšák >> >> Tested by piglit. > > It doesn't look like there are any piglit test Ignore that. I started typing, checked the piglit list, then forgot to delete i

Re: [Mesa-dev] [PATCH 1/7] mesa: implement ARB/KHR_parallel_shader_compile

On 11/28/18 6:59 PM, Marek Olšák wrote: > From: Marek Olšák > > Tested by piglit. It doesn't look like there are any piglit test > --- > docs/features.txt | 2 +- > docs/relnotes/19.0.0.html | 2 ++ > src/mapi/glapi/gen/gl_API.xml | 15 ++

Re: [Mesa-dev] [PATCH 05/16] nir: combine fmul and fadd across ffma operations

On 12/19/18 8:39 AM, Jonathan Marek wrote: > This works by moving the fadd up across the ffma operations, so that it > can eventually can be combined with a fmul. I'm not sure it works in all > cases, but it works in all the common cases. > > This will only affect freedreno since it is the only dr

Re: [Mesa-dev] [PATCH 04/16] nir: add nir_lower_bool_to_float

On 12/19/18 9:25 AM, Dylan Baker wrote: > Quoting Jonathan Marek (2018-12-19 08:39:53) >> Mainly a copy of nir_lower_bool_to_int32, but with float opcodes. >> >> Signed-off-by: Jonathan Marek >> --- >> src/compiler/Makefile.sources | 1 + >> src/compiler/nir/meson.build

[Mesa-dev] MR: nir/algebraic: Don't put quotes around floating point literals

then treats it as an arbitrary variable replacement, so any iand involving a ('ineg', ('b2i', a)) matches. Signed-off-by: Ian Romanick Fixes: 6bcd2af0863 ("nir/algebraic: Add some optimizations for D3D-style Booleans") Bugzilla: https://bugs.fre

[Mesa-dev] MR: Revert "nir/lower_indirect: Bail early if modes == 0"

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/26 "There's no point in walking the program if we're never going to actually lower anything." Except we might lower compacted local arrays. In that case, modes will be 0, but there is still lowering to be done. This reverts commit

[Mesa-dev] MR: NIR: fsign optimizations and a couple 1-bit Boolean optimizations too.

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/27 This series mostly improves code generation for cases of x*fsign(y). I had some difficulty getting everything working after rebasing on the 1-bit Boolean changes. In that process, I noticed a couple things that led to the last two patche

Re: [Mesa-dev] MR: NIR: Partial redundancy elimination for compares

gt;>> On Mon, Dec 17, 2018 at 5:05 PM Ian Romanick wrote: >>>> >>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F22&data=02%7C01%7Csroland%40vmware.com%7C5773f37aa397417e6beb08d6646c2

Re: [Mesa-dev] PSA: Please send MRs to the mailing list

On 12/16/18 4:54 PM, Ilia Mirkin wrote: > A diffstat would also be nice as it would better inform people reading > emails whether they need to care or not. That's a good idea. I tagged the message that I just sent with MR: to make it more obvious that it's for a merge request. I saw Jason's mess

[Mesa-dev] MR: NIR: Partial redundancy elimination for compares

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/22 This series adds a new optimization pass that tries to replace code sequences like if (x < y) { z = y - x; ... } with a sequence like t = x - y; if (t < 0) { z = -t; ... } On architectures where the subtract can generat

Re: [Mesa-dev] Let's talk about -DDEBUG

On 12/12/18 4:13 PM, Dylan Baker wrote: > Quoting Rob Clark (2018-12-12 15:52:47) >> On Wed, Dec 12, 2018 at 6:25 PM Dylan Baker wrote: >>> >>> In the autotools discussion I've come to realize that we also need to talk >>> about >>> the -DDEBUG guard. It seems that there are two different uses, a

Re: [Mesa-dev] [PATCH v2] docs: Document GitLab merge request process (email alternative)

It's fairly common for Mesa developers to have several patch series on the mailing list at a time. I believe most people will author these as a continuous stream with either implicit dependencies (i.e., commit messages in the second series with shader-db results that are impacted by the first seri

Re: [Mesa-dev] [PATCH 1/6] mesa: wire up InvalidateFramebuffer

On 12/11/18 3:15 PM, Rob Clark wrote: > On Tue, Dec 11, 2018 at 6:06 PM Ian Romanick wrote: >> >> On 12/11/18 2:50 PM, Rob Clark wrote: >>> And before someone actually starts implementing DiscardFramebuffer() >>> lets rework the interface to something that is ac

Re: [Mesa-dev] [PATCH 2/6] mesa: wire up InvalidateSubFramebuffer

On 12/11/18 2:50 PM, Rob Clark wrote: > Signed-off-by: Rob Clark > --- > src/mesa/main/dd.h | 3 +++ > src/mesa/main/fbobject.c | 34 +- > 2 files changed, 36 insertions(+), 1 deletion(-) > > diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h > index 1214

Re: [Mesa-dev] [PATCH 2/6] mesa: wire up InvalidateSubFramebuffer

zei numAttachments, const GLenum *attachments, > +GLint x, GLint y, GLsizei width, GLsizei height) > +{ > + GLint i; > + > + if (!ctx->Driver.DiscardSubFramebuffer) > + return; > + > + for (i = 0; i < numAttachmen

Re: [Mesa-dev] [PATCH 1/6] mesa: wire up InvalidateFramebuffer

+ return NULL; > + } > +} > + > +static void > +discard_framebuffer(struct gl_context *ctx, struct gl_framebuffer *fb, > +GLsizei numAttachments, const GLenum *attachments) > +{ > + GLint i; > + > + if (!ctx->Driver.DiscardFramebuffer)

Re: [Mesa-dev] [PATCH] mesa: add EXT_debug_label support

On 12/10/18 5:52 PM, Timothy Arceri wrote: > On 11/12/18 11:35 am, Ian Romanick wrote: >> It seems like someone already sent out patches to implement this, and we >> decided to not take it for some reason.  Maybe it was Rob? > > I discovered a thread from the beginning of 201

Re: [Mesa-dev] [PATCH] mesa: add EXT_debug_label support

It seems like someone already sent out patches to implement this, and we decided to not take it for some reason. Maybe it was Rob? On 12/10/18 4:08 PM, Timothy Arceri wrote: > KHR_debug already provides superior functionality but this > extension is still in use and adding support for it seems fa

Re: [Mesa-dev] [PATCH v2] glapi: fixup EXT_multisampled_render_to_texture dispatch

Reviewed-by: Ian Romanick On 12/10/18 10:14 AM, Emil Velikov wrote: > From: "Kristian H. Kristensen" > > There's a few missing and convoluted bits: > > - FramebufferTexture2DMultisampleEXT > Missing sanity check, should be desktop="false" > &g

Re: [Mesa-dev] [PATCH 05/28] Revert "spirv: Don’t check for NaN for most OpFOrd* comparisons"

On 12/05/2018 10:12 AM, Connor Abbott wrote: > This won't work, since this optimization in nir_opt_algebraic will undo it: > > # For any float comparison operation, "cmp", if you have "a == a && a cmp b" > # then the "a == a" is redundant because it's equivalent to "a is not NaN" > # and, if a is

Re: [Mesa-dev] [PATCH] spirv: Silence a couple of warnings

These look good to me. I don't remember whether or not that kind of initializer makes MSCV happy, but meh. Reviewed-by: Ian Romanick On 12/05/2018 01:13 PM, Jason Ekstrand wrote: > They occur when building with clang: > > [1/40] Compiling C object > 'src/compiler/nir/

Re: [Mesa-dev] Make Jordan an Owner of the mesa project?

Ack from me. On December 3, 2018 4:49:09 PM Jason Ekstrand wrote: Jordan has requested to be made an Owner of the mesa project. As much as I may be the guy who pushed to get everything set up, I don't want to do this sort of thing on my own. As such, I'm asking for some ACKs. If I can get

Re: [Mesa-dev] [PATCH 1/2] nir: add a compiler option for disabling float comparison simplifications

On 11/29/2018 07:47 AM, Connor Abbott wrote: > On Thu, Nov 29, 2018 at 4:22 PM Jason Ekstrand wrote: >> >> Can you provide some context for this? Those rules are already flagged >> "inexact" (that's what the ~ means) so they won't apply to anything that's >> "precise" or "invariant". > > I thi

Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: Revert INTEL_fragment_shader_ordering support

On 12/03/2018 08:10 AM, Emil Velikov wrote: > On Thu, 29 Nov 2018 at 23:54, Matt Turner wrote: >> >> This extension is not properly tested (testing for >> GL_ARB_fragment_shader_interlock is not sufficient), and since this was >> noted in review on August 28th no tests have been sent. >> >> Revert

  1   2   3   4   5   6   7   8   9   10   >