Re: [Mesa-dev] [PATCH] intel/fs,vec4: Fix a compiler warning

Reviewed-by: Alejandro Piñeiro On 16/11/18 16:25, Jason Ekstrand wrote: > ../src/intel/compiler/brw_fs_nir.cpp:3534:46: warning: comparison of integer > expressions of different signedness: ‘unsigned int’ and ‘int’ [-Wsign-compare] >assert(nir_intrinsic_write_mask(instr) == >

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

On 15/1/19 7:01, Tapani Pälli wrote: > > > On 1/14/19 2:36 PM, Daniel Stone wrote: >> Hi, >> >> On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand >> wrote: >>>   5. There's no way with gitlab for Reviewed-by tags to get >>> automatically applied as part of the merging process.  This makes >>> merging

Re: [Mesa-dev] [PATCH v1] nir: Length of boolean vtn_value now is 1

Just tested it with the ARB_gl_spirv tests where I found this: Tested-by: Alejandro Piñeiro On 15/1/19 12:08, Sergii Romantsov wrote: During conversion type-length was lost due to math. CC: Jason Ekstrand Fixes: 44227453ec03 (nir: Switch to using 1-bit Booleans for almost everything)

Re: [Mesa-dev] [PATCH v1] nir: Length of boolean vtn_value now is 1

I was waiting Jason to chime in, but just in case he is too busy I took a look in detail to the patch. It LGTM, so assuming it passes intel CI: Reviewed-by: Alejandro Piñeiro On 15/1/19 12:08, Sergii Romantsov wrote: During conversion type-length was lost due to math. CC: Jason Ekstrand

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

On 17/1/19 9:39, Kenneth Graunke wrote: On Wednesday, January 16, 2019 11:38:05 PM PST Erik Faye-Lund wrote: On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote: All, The mesa project has now hit 100 merge requests (36 are still open). I (and I'm sure others) would be curious to hear

[Mesa-dev] [MR] spirv/nir: handle location decorations on block interface members, plus cleaning

While doing a review of the current ARB_gl_spirv series, I found that this one also applies to Vulkan, and fixes some Vulkan tests, so I preferred to send it in advance, and keep any ARB_gl_spirv series to review to only apply to OpenGL. FWIW, this was sent a long time ago [1], but since then

Re: [Mesa-dev] [PATCH] spirv/nir: adjust location assignment for the case of arrays of blocks

On 14/12/18 0:54, Timothy Arceri wrote: > > > On 13/12/18 11:11 pm, Alejandro Piñeiro wrote: >> This is needed due how the types get rearranged after the struct >> splitting. >> >> So for example, this array of blocks: >> >>    layout(location = 0) out block { >> vec4 v; >> vec3 v2; >>   

Re: [Mesa-dev] Representing explicit memory layouts in NIR

On 30/11/18 23:52, Jason Ekstrand wrote: > On Fri, Nov 30, 2018 at 4:39 PM Timothy Arceri > wrote: > > On 1/12/18 9:11 am, Jason Ekstrand wrote: > > All, > > > > This week, I've been working on trying to move UBO and SSBO > access in > > NIR

Re: [Mesa-dev] Representing explicit memory layouts in NIR

On 1/12/18 14:34, Jason Ekstrand wrote: > On Sat, Dec 1, 2018 at 4:06 AM apinheiro <mailto:apinhe...@igalia.com>> wrote: > > On 30/11/18 23:52, Jason Ekstrand wrote: >> On Fri, Nov 30, 2018 at 4:39 PM Timothy Arceri >> mailto:tarc...@itsqueeze.com>&g

Re: [Mesa-dev] [PATCH 25/28] i965/fs: add support for shader float control to remove_extra_rounding_modes()

On 6/12/18 8:37, apinheiro wrote: > On 5/12/18 16:55, Samuel Iglesias Gonsálvez wrote: >> The remove_extra_rounding_modes() optimization will remove duplicated >> rounding mode changes. >> >> Signed-off-by: Samuel Iglesias Gonsálvez >> --- >> src/intel/

Re: [Mesa-dev] [PATCH 25/28] i965/fs: add support for shader float control to remove_extra_rounding_modes()

On 5/12/18 16:55, Samuel Iglesias Gonsálvez wrote: > The remove_extra_rounding_modes() optimization will remove duplicated > rounding mode changes. > > Signed-off-by: Samuel Iglesias Gonsálvez > --- > src/intel/compiler/brw_fs.cpp | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-)

[Mesa-dev] MR: ARB_gl_spirv xfb improvement

on piglit here: https://github.com/Igalia/piglit/tree/apinheiro/xfb For now a personal branch. It is mostly done, but it is pending the double checking before sending to review. As part of this series, we also change how input arrays of blocks are splitted, in order to support interpolators qualifiers

Re: [Mesa-dev] [PATCH 1/3] nir: make nir_opt_remove_phis_impl() static

The three patches: Reviewed-by: Alejandro Piñeiro On 2/1/19 6:00, Timothy Arceri wrote: > --- > src/compiler/nir/nir.h | 1 - > src/compiler/nir/nir_opt_remove_phis.c | 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/src/compiler/nir/nir.h

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

I mostly agree with your thoughts below. Will add some additional comments inline. On 11/1/19 18:05, Jason Ekstrand wrote: > I'm putting my own thoughts in a reply for some reason.  Here's what > I've seen. > >  1. I really like GitLab "discussions".  It provides a very good way > for both the

Re: [Mesa-dev] [PATCH] docs: Document and *require* usage of Signed-off-by

On 30/11/18 17:32, Ian Romanick wrote: > On 11/29/2018 03:53 PM, Eric Anholt wrote: >> e<#secure method=pgpmime mode=sign> >> Erik Faye-Lund writes: >> >>> On Wed, 2018-11-28 at 13:43 -0800, Eric Anholt wrote: Jordan Justen writes: > This adds the "Developer's Certificate of

Re: [Mesa-dev] [PATCH] nir/split_vars: Don't compact vectors unnecissarily

Reviewed-by: Alejandro Piñeiro On 23/2/19 6:14, Jason Ekstrand wrote: --- src/compiler/nir/nir_split_vars.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/compiler/nir/nir_split_vars.c b/src/compiler/nir/nir_split_vars.c index 244ffd6dcf0..96b6042e6d9 100644 ---

Re: [Mesa-dev] [PATCH] nir/split_vars: Don't compact vectors unnecissarily

On 23/2/19 12:07, apinheiro wrote: Reviewed-by: Alejandro Piñeiro Well, just in case, shouldn't be unnecessarily instead of unnecissarily? On 23/2/19 6:14, Jason Ekstrand wrote: ---   src/compiler/nir/nir_split_vars.c | 6 ++   1 file changed, 6 insertions(+) diff --git a/src

[Mesa-dev] [MR] anv: fix use after free when copying nir_xfb_info

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/442 After adding varyings to nir_xfb_info, I added varyings as a pointer, and replaced outputs[0] for also a pointer, so now both needed to be allocated. But anv was copying such xfb info as: *xfb_info = *xfb_info_in So after my

Re: [Mesa-dev] [PATCH] nir/serialize: Make preserving names optional

Reviewed-by: Alejandro Piñeiro Out of curiosity: right now it is always used as true (so maintain current behaviour). How it is intended to be used? With an envvar? On 7/3/19 22:38, Jason Ekstrand wrote: --- src/compiler/nir/nir_serialize.c | 56 ---

Re: [Mesa-dev] [PATCH] glsl: glsl to nir fix uninit static class member.

Reviewed-by: Alejandro Piñeiro On 8/2/19 6:24, Dave Airlie wrote: From: Dave Airlie The constructor should init this to NULL --- src/compiler/glsl/glsl_to_nir.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/compiler/glsl/glsl_to_nir.cpp b/src/compiler/glsl/glsl_to_nir.cpp

[Mesa-dev] [MR] nir: move pixel_center_integer/origin_upper_left to shader_info.fs

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/237 New version of the thread that I sent recently, showing two initial versions to solve the regression I found on MR #144: https://lists.freedesktop.org/archives/mesa-dev/2019-February/214808.html This MR includes a v2 of the second

Re: [Mesa-dev] [PATCH] nir/xfb: Properly align 64-bit values

I vaguely remember glslang doing something similar when computing offsets. This, and other xfb corner cases, were the reason I thought/concluded it would made sense to let glslang (or any other frontend) to do the offset assignment also for structs, so SPIR-V consuming drivers didn't need to

Re: [Mesa-dev] [PATCH] nir/deref: Rematerialize parents in rematerialize_derefs_in_use_blocks

Reviewed-by: Alejandro Piñeiro On 11/2/19 5:28, Jason Ekstrand wrote: When nir_rematerialize_derefs_in_use_blocks_impl was first written, I attempted to optimize things a bit by not bothering to re-materialize the sources of deref instructions figuring that the final caller would take care of

[Mesa-dev] [MR] mesa/i965: ARB_gl_spirv and ARB_spirv_extensions implementation, plus 4.6

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/178 TL; DR; This series implements all the mesa bits needed to enable ARB_gl_spirv and ARB_spirv_extensions on the i965 driver, and with that, expose OpenGL 4.6 on that driver. Detailed explanation: we reached a point where we consider

Re: [Mesa-dev] [PATCH] docs: advice to resolve discussion on gitlab MR doc

On 16/5/19 13:35, Eric Engestrom wrote: On Thursday, 2019-05-16 13:14:46 +0200, Connor Abbott wrote: Some grammar nits: - "Resolve Discussion" goes before "button" as it modifies it. - It's either "This way..." or "In this manner...", not "In this way...", although the latter is a little too

Re: [Mesa-dev] [PATCH] st/mesa: accelerate glCopyPixels(STENCIL)

Hi, the following piglit test: ./bin/fbo-stencil copypixels GL_DEPTH32F_STENCIL8 -auto -fbo regressed after this patch landed master with the v3d driver. So Marek and anyone reading this email, could you execute that test and confirms if only regress with v3d? Thanks in advance. On 25/6/19

Re: [Mesa-dev] [PATCH] st/mesa: accelerate glCopyPixels(STENCIL)

On 11/7/19 20:12, Marek Olšák wrote: The test passes here. I wouldn't push a commit that doesn't pass. Ok, thanks for confirming. It looks like v3d can't blit stencil. Ok, thanks for the hint. Marek On Thu, Jul 11, 2019 at 6:29 AM apinheiro <mailto:apinhe...@igalia.com>&

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

On 29/6/19 2:30, Rob Clark wrote: I had interpreted it as literally the "block the gitlab merge button" option, ie. "I want to get feedback but it is not ready to merge and I'll drop the WIP tag when I think it is".. (comments inline) On Fri, Jun 28, 2019 at 5:12 PM Ian Romanick wrote:

[Mesa-dev] shader-db MR: run: set NULL as initial value for binding_list

Without it, under some specific compilation options, it can be initialized to NULL or to garbage. On the latter case, if the shader doesn't require a binding_list, would cause a crash later when it attempts to be used. https://gitlab.freedesktop.org/mesa/shader-db/merge_requests/7

Re: [Mesa-dev] v3d: Difference between TransformFeedback Gallium <-> Vulkan

On 26/8/19 13:28, abergme...@gmx.net wrote: For a few weeks now I am working on implementing Vulkan for VideoCore 6 AKA 42 (using V3D/DRM). Don't hold you breath ;) Currently I am trying to understand what is necessary or how to interact with V3D. So I am looking at TransformFeedback because

Re: [Mesa-dev] [PATCH] broadcom/vc4: Expand width of dst surface

On 27/8/19 11:13, Zhaowei Yuan wrote: Four bytes of src_surf will be compressed into a 32-bits data and stored into dst_surf, and dst_surf is read as z-order,so its width must be aligned to multiples of 8(4x2) before devided by 2. Signed-off-by: Zhaowei Yuan Bugzilla:

Re: [Mesa-dev] Mesa 19.2.0 release plan

On 30/8/19 0:52, apinheiro wrote: On 7/8/19 10:44, Emil Velikov wrote: Hi all, Hi Emil, On Wed, 31 Jul 2019 at 09:37, Emil Velikov wrote: Hi all, Here is the tentative release plan for 19.2.0. As many of you are well aware, it's time to the next branch point. The calendar

Re: [Mesa-dev] [PATCH v3] broadcom/vc4: Expand width of dst surface

Just pushed, thanks for the patch. On 3/9/19 4:58, Zhaowei Yuan wrote: Four bytes of src_surf will be compressed into a 32-bits data and stored into dst_surf, and dst_surf is read as z-order,so its width must be aligned to multiples of 8(4x2) before divided by 2. Signed-off-by: Zhaowei Yuan

Re: [Mesa-dev] Mesa 19.2.0 release plan

On 7/8/19 10:44, Emil Velikov wrote: Hi all, Hi Emil, On Wed, 31 Jul 2019 at 09:37, Emil Velikov wrote: Hi all, Here is the tentative release plan for 19.2.0. As many of you are well aware, it's time to the next branch point. The calendar is already updated, so these are the

Re: [Mesa-dev] [PATCH v2] broadcom/vc4: Expand width of dst surface

On 28/8/19 3:16, Zhaowei Yuan wrote: Four bytes of src_surf will be compressed into a 32-bits data and stored into dst_surf, and dst_surf is read as z-order,so its width must be aligned to multiples of 8(4x2) before devided Nitpick: typo, "devided" instead of "divided". With that change:

Re: [Mesa-dev] Mesa 19.2.0 release plan

(Thanks Chema for pointing me this thread) On 21/8/19 9:09, Emil wrote: Hi Jason, On 21 August 2019 01:22:00 EEST, Jason Ekstrand wrote: Sorry for the late breaking hold but I just realized that GL_ARB_gl_spirv and OpenGL 4.6 for Intel is 1 regression (I think it's not even a regression)

Re: [Mesa-dev] [ANNOUNCE] mesa 19.2.0-rc2

On 5/9/19 0:57, Dylan Baker wrote: Hi List, I'd like to announce the availability of mesa-19.2.0-rc2. This is the culmination of two weeks worth of work. Due to maintenance the Intel CI is not running, but I've built and tested this locally. I would have preferred to get more testing, but

Re: [Mesa-dev] [PATCH] st/mesa: accelerate glCopyPixels(STENCIL)

apinheiro <mailto:apinhe...@igalia.com>> wrote: Hi, the following piglit test: ./bin/fbo-stencil copypixels GL_DEPTH32F_STENCIL8 -auto -fbo regressed after this patch landed master with the v3d driver. So Marek and anyone reading this email, could you execute

Re: [Mesa-dev] iris now officially OpenGL 4.6 conformant

On 20/11/19 19:31, Kenneth Graunke wrote: Hi all, iris is now officially a conformant OpenGL 4.6 implementation! https://www.khronos.org/conformance/adopters/conformant-products/opengl#submission_253 This is on Gen9. I've also submitted for Gen8, but that's still under review; Gen11 is 99%

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

On 12/12/19 5:46, Mark Janes wrote: Ian Romanick writes: 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

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

On 12/12/19 0:38, Eric Engestrom wrote: On 2019-12-11 at 23:09, Eric Anholt wrote: On Wed, Dec 11, 2019 at 2:35 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

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

On 5/12/19 8:48, Kenneth Graunke wrote: On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote: Hi, Here are 2 proposals to simplify and better optimize the GL->Gallium translation. 1) Move classic drivers to a fork of Mesa, and remove them from master. Classic drivers won't share any

Re: [Mesa-dev] Drop scons for 20.1?

On 26/2/20 5:15, Jason Ekstrand wrote: > +Jose & Brian > > I'm not personally opposed but I also can't remember the last time I > had to fix the scons build. I think it's been years. Maybe that's > because I don't work on GL anymore? I bet that the latter. I remember some years ago pushing new

Re: [Mesa-dev] Loading Vulkan Driver

://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e This commit added the basic skeleton for v3dv (broadcom mesa vulkan driver). It C and adapted the python scripts that Jason wrote for anv (that was that radv and turnip also did, afaik), and then provided

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

On 23/8/20 8:11, Luke Kenneth Casson Leighton wrote: On Sun, Aug 23, 2020 at 1:56 AM apinheiro wrote: On 22/8/20 23:59, Luke Kenneth Casson Leighton wrote: constructive feedback on this approach greatly appreciated: https://bugs.libre-soc.org/show_bug.cgi?id=251#c36 In any case, those

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

On 22/8/20 23:59, Luke Kenneth Casson Leighton wrote: On Sat, Aug 22, 2020 at 10:34 PM apinheiro wrote: As Jason mentioned, to get a Vulkan driver started, you would need more than just one method. If you want a reference: https://gitlab.freedesktop.org/apinheiro/mesa/-/commit

Re: [Mesa-dev] Plan for merging v3dv in mesa

, 2020 at 12:10 PM Jason Ekstrand wrote: Good work, all! I'm super-happy to see another Vulkan driver land in Mesa. On Thu, Sep 17, 2020 at 8:52 AM apinheiro wrote: Our development branch is ~525 patches on top of master, categorized as follows: a) Patches that touch common Mesa

[Mesa-dev] Plan for merging v3dv in mesa

Hi everybody, As some of you already know, we have been working on a Vulkan driver (v3dv) for the Broadcom V3D GPU present in the Raspberry Pi 4. So far we have beenworking on a personal branch, rebasing regularly, and we would like to start discussing about the process to merge the driver in

Re: [Mesa-dev] piglit/mesa marge access

On 31/7/20 18:35, Erik Faye-Lund wrote: I second the request :-) +1 Jul 31, 2020 16:15:05 Mike Blumenkrantz : Hi, I'd like to request marge access for the piglit and mesa gitlab projects. I've been contributing a number of patches here (primarily to zink/gallium), and this would be

[Mesa-dev] v3dv is Vulkan 1.0 conformant

So just a for your information, we submitted v3dv for Vulkan 1.0 conformance around one month ago, in behalf of the Raspberry Foundation, and it is not official [1]. Here the Foundation blog post [2]. We want to thanks everybody that helped with this, but specially to Eric Anholt, as without

Re: [Mesa-dev] Workflow Proposal

Answering here, as it is the second time it is mentioned that Rb is only for "who can help support this years from now?", but not specifically to this email. On 7/10/21 15:00, Alyssa Rosenzweig wrote: I would love to see this be the process across Mesa. We already don't rewrite commit

Re: [Mesa-dev] Workflow Proposal

On 12/10/21 13:55, Alyssa Rosenzweig wrote: I would love to see this be the process across Mesa. We already don't rewrite commit messages for freedreno and i915g, and I only have to do the rebase (busy-)work for my projects in other areas of the tree. Likewise for Panfrost. At least, I don't