Re: [Mesa-dev] Perfetto CPU/GPU tracing

Rob Clark writes: > On Fri, Feb 12, 2021 at 5:01 AM Tamminen, Eero T > wrote: >> >> Hi, >> >> On Thu, 2021-02-11 at 17:39 -0800, John Bates wrote: >> > I recently opened issue 4262 >> > to begin the >> > discussion on integrating perfetto

Re: [Mesa-dev] Perfetto CPU/GPU tracing

I've recently been using GPUVis to look at trace events. On Intel platforms, GPUVis incorporates ftrace events from the i915 driver, performance metrics from igt-gpu-tools, and userspace ftrace markers that I locally hack up in Mesa. It is very easy to compile the GPUVis UI. Userspace

Re: [Mesa-dev] Mesa main repor branch clean-up

Thank you for doing this. The dead branches in the mesa repo always annoyed me. There are still many tags that look like they were inadvertently pushed to the origin by developers. Does it make sense to delete them as well? -Mark Jason Ekstrand writes: > All, > > At suggestion from several

Re: [Mesa-dev] [ANNOUNCE] mesa 20.0.5

Michel Dänzer writes: > On 2020-04-23 8:37 p.m., Mark Janes wrote: >> - search for issues mentioning a test name (unless it is in the title) > > https://gitlab.freedesktop.org/mesa/mesa/-/issues?scope=all=%E2%9C%93=opened=test > > lists issues without "test" in

Re: [Mesa-dev] [ANNOUNCE] mesa 20.0.5

Michel Dänzer writes: > On 2020-04-23 6:19 p.m., Mark Janes wrote: >> Michel Dänzer writes: >>> On 2020-04-23 5:14 p.m., Mark Janes wrote: >>>> >>>> Does anyone have recommendations for how to use Gitlab to verify that >>>> there a

Re: [Mesa-dev] [ANNOUNCE] mesa 20.0.5

Michel Dänzer writes: > On 2020-04-23 5:14 p.m., Mark Janes wrote: >> >> Does anyone have recommendations for how to use Gitlab to verify that >> there are no identified-but-unfixed bugs in a pending release? > > I'd say GitLab milestones could be used to address th

Re: [Mesa-dev] [ANNOUNCE] mesa 20.0.5

Danylo Piliaiev writes: > I want to sum up what happened from my perspective, I think it could be > useful to improve the process: > > 1) There was a regression in 20.* > (https://gitlab.freedesktop.org/mesa/mesa/-/issues/2758) > 2) I "fixed" the regression and broke non-iris drivers >

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

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 a point of keeping up

Re: [Mesa-dev] How to merge Mesa changes which require corresponding piglit changes

Michel Dänzer writes: > On 2019-12-02 3:15 p.m., Tapani Pälli wrote: >> On 11/15/19 8:41 PM, Mark Janes wrote: >>> Michel Dänzer writes: >>> >>>> On 2019-11-15 4:02 p.m., Mark Janes wrote: >>>>> Michel Dänzer writes: >>>>&

Re: [Mesa-dev] How to merge Mesa changes which require corresponding piglit changes

Michel Dänzer writes: > On 2019-11-15 4:02 p.m., Mark Janes wrote: >> Michel Dänzer writes: >> >>> Now that the GitLab CI pipeline tests a snapshot of piglit with llvmpipe >>> (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2468), the >>> q

Re: [Mesa-dev] How to merge Mesa changes which require corresponding piglit changes

Michel Dänzer writes: > Now that the GitLab CI pipeline tests a snapshot of piglit with llvmpipe > (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2468), the > question has come up how to deal with inter-dependent Mesa/piglit > changes (where merging only one or the other causes some

Re: [Mesa-dev] Release workflow with gitlab issues

Adam Jackson writes: > On Wed, 2019-09-18 at 12:08 -0700, Mark Janes wrote: >> Adding the release managers to the CC to make sure they see the thread... >> >> Dylan Baker writes: >> >> > Hi everyone, >> > >> > Since we're migrating to gi

Re: [Mesa-dev] Release workflow with gitlab issues

Adding the release managers to the CC to make sure they see the thread... Dylan Baker writes: > Hi everyone, > > Since we're migrating to gitlab issues, it seems like a good time to review > how > we track stable releases, particularly release blockers. > > I'd like to use a gitlab milestone

Re: [Mesa-dev] Mesa 19.2.0 release plan

Eric Engestrom writes: > On 2019-07-31 at 09:38, 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 tentative dates: >> >> Aug 06

Re: [Mesa-dev] [PATCH 3/3] android: amd/addrlib: add gfx10 support

Do you have some documentation on how you are building Android with Mesa? We set up a buildtest using an Android (Celadon) tree from Intel, and it seems to be less up-to-date than your build. Last week, you found a build error that was missed by our CI. When you pushed this series, we got:

Re: [Mesa-dev] [PATCH 00/11] i965 shader debug through KHR_debug

to review. I can make a MR in gitlab if you think it would help. Jason Ekstrand writes: > Did this get dropped on the ground? > > On Fri, Dec 7, 2018 at 12:07 PM Mark Janes wrote: > >> Ilia Mirkin writes: >> >> > On Thu, Dec 6, 2018 at 7:36 PM Mark Janes

Re: [Mesa-dev] [ANNOUNCE] mesa 19.0.0-rc1

Eero Tamminen writes: > Hi, > > On 31.1.2019 1.37, Dylan Baker wrote: >> This email announces the mesa 19.0 release candidate 1. I'll keep this email >> fairly brief since I'm already running a little late on getting this done :) >> I've just had to resolve quite a few autotools issues to get

Re: [Mesa-dev] [PATCH v4] anv/device: fix maximum number of images supported

Hi Iago, It looks like you tested this patch in CI and got the same failures that we are seeing on master: http://mesa-ci-results.jf.intel.com/itoral/builds/263/group/63a9f0ea7bb98050796b649e85481845 Why was this patch pushed? -Mark Mark Janes writes: > This patch regresses thousa

Re: [Mesa-dev] [PATCH v4] anv/device: fix maximum number of images supported

This patch regresses thousands of tests on BDW and HSW: http://mesa-ci-results.jf.intel.com/vulkancts/builds/10035/group/63a9f0ea7bb98050796b649e85481845#fails I'll revert it as soon as my testing completes. Iago Toral Quiroga writes: > We had defined MAX_IMAGES as 8, which we used to size

Re: [Mesa-dev] [PATCH 00/11] i965 shader debug through KHR_debug

Ilia Mirkin writes: > On Thu, Dec 6, 2018 at 7:36 PM Mark Janes wrote: >> >> This series provides Intel shader compilation debug information via >> KHR_debug. Previously, shader assembly and related compilation >> artifacts were dumped to stderr. Tools associati

[Mesa-dev] [PATCH 04/11] i965/disasm: allow caller to specify output filehandle.

--- src/intel/compiler/brw_disasm_info.c | 28 +++ src/intel/compiler/brw_disasm_info.h | 2 +- src/intel/compiler/brw_fs_generator.cpp | 2 +- src/intel/compiler/brw_vec4_generator.cpp | 2 +- src/intel/compiler/test_eu_validate.cpp | 2 +- 5 files changed,

[Mesa-dev] [PATCH 11/11] i965: provide shader cache assemblies to KHR_debug

--- src/mesa/drivers/dri/i965/brw_disk_cache.c | 23 ++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_disk_cache.c b/src/mesa/drivers/dri/i965/brw_disk_cache.c index 65fcab24b7f..0acbef4f20e 100644 ---

[Mesa-dev] [PATCH 00/11] i965 shader debug through KHR_debug

continue to be provided on stderr. Pre-existing KHR_debug messages used by shader-db are unchanged. * wip branch to handle KHR_debug: https://github.com/janesma/apitrace/tree/khr_debug Mark Janes (11): mesa: properly report the length of truncated log messages mesa: rename logging functions

[Mesa-dev] [PATCH 01/11] mesa: properly report the length of truncated log messages

_mesa_log_msg must provide the length of the string passed into the KHR_debug api. When the string formatted by _mesa_gl_vdebugf exceeds MAX_DEBUG_MESSAGE_LENGTH, the length is incorrectly set to the number of characters that would have been written if enough space had been available. Fixes:

[Mesa-dev] [PATCH 10/11] i965: provide GLSL IR to KHR_debug

--- src/mesa/drivers/dri/i965/brw_link.cpp | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp b/src/mesa/drivers/dri/i965/brw_link.cpp index 2cbb1e0b879..24e0079fc5d 100644 --- a/src/mesa/drivers/dri/i965/brw_link.cpp +++

[Mesa-dev] [PATCH 06/11] i965/disasm: provide shader assembly to KHR_debug.

Shader assemblies can be more easily incorporated into debug tools if they are presented through KHR_debug. --- src/intel/compiler/brw_fs_generator.cpp | 38 --- src/intel/compiler/brw_vec4_generator.cpp | 22 +++-- 2 files changed, 33 insertions(+), 27 deletions(-)

[Mesa-dev] [PATCH 09/11] i965: make shader_debug_log_mesa callable

Debug output of IR/assemblies is likely to exceed the 4k limit in KHR_debug. shader_debug_log_mesa splits large messages, providing the full content through KHR_debug. Expose the function, so it can be called from the shader cache and the linker. --- src/mesa/drivers/dri/i965/intel_screen.c | 2

[Mesa-dev] [PATCH 05/11] i965: provide stable message id's for shader_debug_log

KHR_debug indicates that message id's can be used to filter debug logs. Mesa incorrectly generates incrementing message id's for each message in shader_debug_log. The ids must be stable if they are to be used for filtering. _mesa_gl_vdebug expects the address of a static GLuint, which is

[Mesa-dev] [PATCH 03/11] mesa: add logging function for formatted string

--- src/mesa/main/errors.c | 27 +++ src/mesa/main/errors.h | 8 2 files changed, 35 insertions(+) diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c index fad8cb59cae..995b0510575 100644 --- a/src/mesa/main/errors.c +++ b/src/mesa/main/errors.c @@

[Mesa-dev] [PATCH 08/11] intel/nir: provide SSA form to KHR_debug

--- src/intel/compiler/brw_fs.cpp | 11 - src/intel/compiler/brw_nir.c | 26 +- src/intel/compiler/brw_nir.h | 1 + src/intel/compiler/brw_shader.cpp | 2 +- src/intel/compiler/brw_vec4.cpp| 2 +-

[Mesa-dev] [PATCH 07/11] i965/compiler: provide formatted strings to the shader debug log

--- src/intel/compiler/brw_compiler.h | 2 +- src/intel/compiler/brw_fs_generator.cpp | 2 +- src/intel/compiler/brw_vec4_generator.cpp | 3 +-- src/intel/vulkan/anv_device.c | 2 +- src/mesa/drivers/dri/i965/intel_screen.c | 19 ++- 5 files changed, 14

[Mesa-dev] [PATCH 02/11] mesa: rename logging functions to reflect that they format strings

In preparation for the definition of a function to log a formatted string. --- src/mesa/drivers/dri/i915/intel_context.h | 18 +-- src/mesa/drivers/dri/i915/intel_fbo.c | 10 +++--- src/mesa/drivers/dri/i965/brw_context.h | 18 +--

Re: [Mesa-dev] [PATCH] mesa/main: fix up _mesa_has_rg_textures for gles2

, and when it finishes. Results will appear on mesa-ci.01.org a few minutes after the final notification. Erik Faye-Lund writes: > On Tue, 2018-12-04 at 10:33 -0800, Mark Janes wrote: >> Tested-by: Mark Janes >> >> Erik Faye-Lund writes: >> >> > r

Re: [Mesa-dev] [PATCH] mesa/main: fix up _mesa_has_rg_textures for gles2

Tested-by: Mark Janes Erik Faye-Lund writes: > rg-textures are supported in GLES 2.0 if EXT_texture_rg, so let's make > sure the enums are accepted. > > Fixes: 510b6424607 "mesa/main: do not allow rg-textures enums before gles3" > Bugzilla: https://bugs.freedesktop.o

Re: [Mesa-dev] [PATCH] mesa/main: fixup requirements for GL_PRIMITIVES_GENERATED

Tested-by: Mark Janes Erik Faye-Lund writes: > This enum is also allowed by EXT_tessellation_shader, which is supported > on older i965 HW (as opposed to OES_geometry_shader). This was missed > when narrowing this code-path, leading to dEQP regressions. > >

Re: [Mesa-dev] [PATCH] Revert "nir/builder: Assert that intN_t immediates fit"

"Juan A. Suarez Romero" writes: > On Tue, 2018-11-20 at 11:13 +0100, Juan A. Suarez Romero wrote: >> On Tue, 2018-11-20 at 09:47 +0100, Iago Toral Quiroga wrote: >> > This reverts commit . >> > >> > For this to work the compiler must ensure that it never puts >> > the values that arrive to this

Re: [Mesa-dev] [PATCH 4/4] i965: Add support for and expose EXT_texture_sRGB_R8

Eric Engestrom writes: > On Thursday, 2018-11-15 19:01:24 +0100, Gert Wollny wrote: >> Emulate MESA_FORMAT_R_SRGB8 by using L8_UNORM_SRGB. This is possible >> because component swizzling is handled based on the mesa format and, >> hence, the a r001 swizzling can be used to correct the

Re: [Mesa-dev] [PATCH v4 1/2] i965/batch: avoid reverting batch buffer if saved state is an empty

repeat ourselves. >> >> v2: Merge with new commits, changes was minimized, added the 'fixes' tag >> v3: Added in to patch series >> v4: Fixed the regression which was introduced by this patch >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108630 >>

Re: [Mesa-dev] [PATCH] anv: Don't advertise ASTC support on BSW

Tested-by: Mark Janes Jason Ekstrand writes: > --- > src/intel/vulkan/anv_formats.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_formats.c > index 33faf7cc37f..9199567f445 100644 > --- a/src/intel

Re: [Mesa-dev] [PATCH] intel/fs: Fix a typo in need_matching_subreg_offset

Tested-by: Mark Janes Jason Ekstrand writes: > This fixes a bunch of Vulkan subgroup tests on little core platforms. > > Fixes: 4150920b95 "intel/fs: Add a helper for emitting scan operations" > --- > src/intel/compiler/brw_fs_builder.h | 2 +- > 1 file changed

Re: [Mesa-dev] [PATCH] mesa: only update framebuffer-state for clears

This patch broke all the intel systems also. Ilia Mirkin writes: > On Wed, Sep 19, 2018 at 7:04 AM, Jakob Bornecrantz > wrote: >> This patch regresses about 3000 dEQP [2,3,3.1] tests on virgl. Full >> setup is dEQP running on virgl with vtest that is running RadeonSI. So >> QEMU is not in the

Re: [Mesa-dev] [ANNOUNCE] mesa 18.2.0-rc5

Hi Andres, The final blockers have been resolved. You should be able to make an RC that passes all Intel validation, if you pick up: 904c2a617d8 * i965/gen7_urb: Re-emit PUSH_CONSTANT_ALLOC on some gen9 d9cf4308cee * i965/screen: Allow modifiers on sRGB formats Looking forward to the release,

Re: [Mesa-dev] [PATCH 0/2] Implement INTEL_fragment_shader_ordering

Kevin, Your email messages are missing the in-reply-to header, making this thread completely incomprehensible on the mailing list. Please fix your mail client to include the standard headers so we can follow what you are saying. -Mark "Rogovin, Kevin" writes: > Hi, > >> Having the same

Re: [Mesa-dev] [PATCH 0/2] Implement INTEL_fragment_shader_ordering

L_fragment_shader_ordering. Sounds like a good plan! > Thank you, > Pam > > On Tue, Aug 28, 2018 at 6:41 PM Mark Janes wrote: > >> Is there a piglit test that verifies that this feature works properly? >> >> writes: >> >> > From: Kevin Rogovin >&g

Re: [Mesa-dev] [PATCH 0/2] Implement INTEL_fragment_shader_ordering

Is there a piglit test that verifies that this feature works properly? writes: > From: Kevin Rogovin > > INTEL_fragment_shader_ordering provides the ability for shaders > to issue a call to gaurnantee memory write operation ordering > of overlapping pixels or samples. In contrast to >

Re: [Mesa-dev] [PATCH] Revert "intel/nir: Call nir_lower_io_to_scalar_early"

This corrects all of the performance regressions that I can see on our perf CI. Please make sure to add the fixes tag before pushing. Tested-by: Mark Janes Jason Ekstrand writes: > Commit 4434591bf56a6b0 caused substantially more URB messages in > geometry and tessellation shaders.

Re: [Mesa-dev] [Mesa-stable] [PATCH] nir/serialize: Alloc constants off the variable

Please add the bugzilla reference for 107366 Tested-by: Mark Janes Jason Ekstrand writes: > nir_sweep assumes that constants area always allocated off the variable > to which they belong. Violating this assumption causes them to get > freed early and leads to use-after-free bug

Re: [Mesa-dev] [PATCH v2 1/3] i965: Sweep NIR after linking phase to free held memory

This patch segfaults when both of the following environment variables are set: NIR_TEST_CLONE=true NIR_TEST_SERIALIZE=true Dylan -- please do not apply this to any stable branch until this bug has been resolved: https://bugs.freedesktop.org/show_bug.cgi?id=107366 -Mark Danylo Piliaiev

Re: [Mesa-dev] [PATCH 1/2] i965/misc: Use depth/stencil surf's tiling on gen4-5

Tested-by: Mark Janes Nanley Chery writes: > Make the 3D engine aware of the depth/stencil surface's tiling before > doing any render operations. > > Fixes fbe01625f6bf2cef6742e1ff0d3d44a2afec003e > ("i965/miptree: Share tiling_flags in miptree_create"). &g

Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.4 release candidate

Oops -- sorry, I was looking at the 18.1 branch, which is already updated with most (but not all) of the commits in the staging/18.1 branch. Mark Janes writes: > I think you've included a patch that caused a regression, but not the fix > > https://bugs.freedesktop.org/show_bug.cgi?

Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.4 release candidate

I think you've included a patch that caused a regression, but not the fix https://bugs.freedesktop.org/show_bug.cgi?id=107193 Dylan Baker writes: > Hi List, > > Mesa 18.1.4 is planned for release this Friday, July 13th, at or around 10 AM > PDT. > > There are currently: > - 27 queued > - 1

Re: [Mesa-dev] [PATCH v3] i965/gen6/gs: Handle case where a GS doesn't allocate VUE

Tested-by: Mark Janes Iago Toral writes: > Thanks Andrii, this version looks good to me. > > Mark: this change fixes a GPU hang in sandy bridge with geometry > shaders (the change itself affects a path in the driver that is only > executed in SNB with GS, so nothing else is aff

Re: [Mesa-dev] [PATCH v3] i965/gen6/gs: Handle case where a GS doesn't allocate VUE

Hi Iago, It is usually safe to push changes to CI which provoke GPU hangs. Occasionally, systems do not recover, so I appreciate the extra notification. I've sent this commit for testing and will let you know how it goes. -Mark Iago Toral writes: > Thanks Andrii, this version looks good to

Re: [Mesa-dev] [Mesa-stable] [PATCH 2/7] intel/isl: Add bounds-checking assertions for the format_info table

This is cc'd to stable, but causes compile errors when to stable branches: src/intel/isl/isl_format.c:372:20: error: ‘ISL_NUM_FORMATS’ undeclared (first use in this function); did you mean ‘ISL_UFLOAT’? Is it dependent on another patch? Jason Ekstrand writes: > We follow the same convention

Re: [Mesa-dev] Gitlab migration

Daniel Stone writes: > On 26 May 2018 at 00:47, Mark Janes wrote: > >> I am eager to make Intel CI results more visible. Can I push our >> artifacts to an fd.o directory, and have GitLab display them to users as >> if the build ran on fd.o? A typical build produ

Re: [Mesa-dev] Gitlab migration

Daniel Stone writes: > We had a go at using Jenkins for some of this: Intel's been really > quite successful at doing it internally, but our community efforts > have been a miserable failure. After a few years I've concluded that > it's not going to change - even with

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] radv: Fix up 2_10_10_10 alpha sign.

Bas Nieuwenhuizen writes: > Pre-Vega HW always interprets the alpha for this format as unsigned, > so we have to implement a fixup to do the sign correctly for signed > formats. > > CC: 18.0 18.1 I couldn't apply this to 18.0. You

Re: [Mesa-dev] [PATCH] mesa: revert GL_[SECONDARY_]COLOR_ARRAY_SIZE glGet type to TYPE_INT

Tested-by: Mark Janes <mark.a.ja...@intel.com> Brian Paul <bri...@vmware.com> writes: > Since size can be 3, 4 or GL_BGRA we need to keep these glGet types > as TYPE_INT, not TYPE_UBYTE. > > Fixes: d07466fe18522 ("mesa: fix glGetInteger/Float/etc queries for > ve

Re: [Mesa-dev] [Mesa-stable] [PATCH 2/2] eg/compute: Drop reference to kernel_param bo in destructor

y cleanly. >> > The >> > 18.1-proposed branch at git://people.freedesktop.org/~dbaker/mesa is where >> > it >> > needs to apply if that's what needs to happen. >> > >> > Thanks, >> > Dylan >> > >> > Quoting Mark

Re: [Mesa-dev] [Mesa-stable] [PATCH 2/2] eg/compute: Drop reference to kernel_param bo in destructor

Hi Jan, Jan Vesely writes: > CC: > Signed-off-by: Jan Vesely > --- > src/gallium/drivers/r600/evergreen_compute.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [Mesa-dev] [PATCH 4/4] anv/device: expose shaderInt16 support in gen8+

Patches 1-4 are Tested-by: Mark Janes <mark.a.ja...@intel.com> Iago Toral Quiroga <ito...@igalia.com> writes: > This rollbacks the revert of this patch introduced with > commit 7cf284f18e6774c810ed6db17b98e597bf96f8a5. > --- > src/intel/vulkan/anv_device.c | 2 +- >

Re: [Mesa-dev] [PATCH v2 00/18] anv: add shaderInt16 support

Clayton Craft writes: > Quoting Iago Toral Quiroga (2018-04-30 07:18:08) >> This version addresses the feedback received to v1, which includes moving the >> bit-size lowering pass from intel to core NIR (patch 8) and a separate patch >> to add Intel's specific

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vcn: fix mpeg4 msg buffer settings

Leo Liu writes: > Reviewed-by: Leo Liu > > And Cc Mesa-stable as well. Please include stable tags in your commit message, eg: Cc: 18.0 18.1 > On 2018-04-24 04:49 PM, boyuan.zh...@amd.com wrote: >> From: Boyuan Zhang

Re: [Mesa-dev] [PATCH 4/4] intel/compiler: Add scheduler deps for instructions that implicitly read g0

Ian Romanick <i...@freedesktop.org> writes: > On 04/23/2018 09:19 AM, Mark Janes wrote: >> I enabled these tests, and could not make them fail in CI. > > Can I consider that a Tested-by? Sorry, I should have been more explicit. Yes, tested-by. >> This bug may al

Re: [Mesa-dev] [PATCH 4/4] intel/compiler: Add scheduler deps for instructions that implicitly read g0

move the writes after the reads. > > Signed-off-by: Ian Romanick <ian.d.roman...@intel.com> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95012 > Cc: Mark Janes <mark.a.ja...@intel.com> > Cc: Clayton A Craft <clayton.a.cr...@intel.com> > --- > I'd really

Re: [Mesa-dev] [PATCH] radv: fix radv_layout_dcc_compressed() when image doesn't have DCC

Hi Samuel, When this patch is applied directly to the 18.0 branch, I get a mesa compile error: radv_image.c:1175:9: error: implicit declaration of function ‘radv_image_has_dcc’; did you mean ‘radv_image_alloc_dcc’? Is there another patch that this is dependent on? -Mark Samuel Pitoiset

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/1] i965: return the fourcc saved in __DRIimage when possible

Hi James, Would it be possible to create a piglit test to exercise the bug referenced in your commit message? If possible, we want to prevent future regressions for this use case. thanks, Mark James Xiong writes: > From: "Xiong, James" > >

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

Emil Velikov <emil.l.veli...@gmail.com> writes: > (Dropping Leo, since it doesn't affect him. He's already subscribed to > the list.) > > On 6 April 2018 at 19:20, Mark Janes <mark.a.ja...@intel.com> wrote: > >> I agree with you, however our release process sti

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

Emil Velikov <emil.l.veli...@gmail.com> writes: > On 5 April 2018 at 20:33, Mark Janes <mark.a.ja...@intel.com> wrote: >> Emil Velikov <emil.l.veli...@gmail.com> writes: >> >>> On 4 April 2018 at 22:50, Mark Janes <mark.a.ja...@intel.com&

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

Emil Velikov <emil.l.veli...@gmail.com> writes: > On 4 April 2018 at 22:50, Mark Janes <mark.a.ja...@intel.com> wrote: >> Leo Liu <leo@amd.com> writes: >> >>> On 04/04/2018 12:40 PM, Mark Janes wrote: >>>> Leo Liu <leo@amd.co

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

Leo Liu <leo@amd.com> writes: > On 04/04/2018 12:40 PM, Mark Janes wrote: >> Leo Liu <leo@amd.com> writes: >> >>> On the CI family, firmware requires the destory command have to be the >>> last command in the IB, moving feedback command after

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

Emil Velikov <emil.l.veli...@gmail.com> writes: > On 4 April 2018 at 17:40, Mark Janes <mark.a.ja...@intel.com> wrote: >> Leo Liu <leo@amd.com> writes: >> >>> On the CI family, firmware requires the destory command have to be the >>> la

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

"Juan A. Suarez Romero" <jasua...@igalia.com> writes: > On Wed, 2018-04-04 at 10:07 -0700, Mark Janes wrote: >> Emil Velikov <emil.l.veli...@gmail.com> writes: >> > In detail: >> > * make the patch queue, release date and blockers accessibl

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

Emil Velikov writes: > Hi all, > > Having gone through the thread a few times, I believe it can be > summarised as follows: > * Greater transparency is needed. > * Subsystem/team maintainers. > * Unfit and late nominations. > * Developers/everyone should be more

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

Leo Liu writes: > On the CI family, firmware requires the destory command have to be the > last command in the IB, moving feedback command after destroy is causing > issues on CI cards, so we have to keep the previous logic that moves > destroy back to the last command. > > But

Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

This patch passes Intel's CI suites. It needs a CC for stable in the commit message. Tested-by: Mark Janes <mark.a.ja...@intel.com> Sergii Romantsov <sergii.romant...@gmail.com> writes: > Gen8+ use 48-bit address relocations so need to extend the sign > to 64-bit return va

Re: [Mesa-dev] [PATCH] mesa: ensure that variable is initialized

Tested-by: Mark Janes <mark.a.ja...@intel.com> Dylan Baker <dy...@pnwbakers.com> writes: > locally I've added: > Fixes: 16f6634e7fb5ada308e55b852cd49251e7f3f8b1 >("mesa/program: Link SPIR-V shaders using the SPIR-V code-path") > > Quoting Dylan Bak

Re: [Mesa-dev] [PATCH 2/2 v2] nir: mako all the intrinsics

Rob Herring writes: > On Wed, Mar 28, 2018 at 10:18 AM, Rob Clark wrote: >> On Wed, Mar 28, 2018 at 10:43 AM, Rob Herring wrote: >>> On Sun, Mar 25, 2018 at 1:10 PM, Rob Clark wrote: I threatened to do this a

Re: [Mesa-dev] [PATCH] clover/llvm: Fix build against LLVM/Clang 4.0

This patch fixes the clover build for Clang 4.0, which is what the Intel CI uses. Tested-by: Mark Janes <mark.a.ja...@intel.com> Aaron Watry <awa...@gmail.com> writes: > The opencl 1.0 langstandard was renamed in 5.0+ > > Cc: Mark Janes <mark.a.ja...@intel.c

Re: [Mesa-dev] [PATCH 5/5] clover: Dynamically calculate __OPENCL_VERSION__ and CLC language version

Aaron, this patch breaks the meson build-test in our CI: ../src/gallium/state_trackers/clover/llvm/invocation.cpp:88:36: error: ‘lang_opencl10’ is not a member of ‘clang::LangStandard’ { 100, clang::LangStandard::lang_opencl10}, configured with: meson -Dbuild-tests=true

Re: [Mesa-dev] [PATCH v3] i965: android: pass the correct header name to the python script

I tested this, and still got an error: FAILED: out/target/product/androidia_64/gen/SHARED_LIBRARIES/i965_dri_intermediates/brw_oa_metrics.c /bin/bash -c "python vendor/intel/external/android_ia/mesa/src/mesa/drivers/dri/i965/brw_oa.py

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

"Juan A. Suarez Romero" writes: > On Fri, 2018-03-16 at 12:03 -0400, Ilia Mirkin wrote: >> On Fri, Mar 16, 2018 at 11:52 AM, Juan A. Suarez Romero >> wrote: >> > On Fri, 2018-03-16 at 11:38 -0400, Ilia Mirkin wrote: >> > > On Fri, Mar 16, 2018 at 11:27

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

Timothy Arceri writes: > I'd just like to point out that as an outside user of Intels CI I have > missed regressions on a couple of occasions. However this was not due to > "Lazy behaviour", having a CI system is fantastic and I'm very grateful > to have access to it.

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

Daniel Vetter <dan...@ffwll.ch> writes: > On Tue, Mar 13, 2018 at 4:46 PM, Mark Janes <mark.a.ja...@intel.com> wrote: >> Daniel Vetter <dan...@ffwll.ch> writes: >> >>> On Mon, Mar 12, 2018 at 11:54:45PM -0700, Kenneth Graunke wrote: >>>> On

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

Daniel Vetter <dan...@ffwll.ch> writes: > On Mon, Mar 12, 2018 at 11:54:45PM -0700, Kenneth Graunke wrote: >> On Friday, March 9, 2018 12:12:28 PM PDT Mark Janes wrote: >> [snip] >> > I've been doing this for Intel. Developers are on the hook to fix their >>

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

Kenneth Graunke <kenn...@whitecape.org> writes: > On Friday, March 9, 2018 12:12:28 PM PDT Mark Janes wrote: > [snip] >> I've been doing this for Intel. Developers are on the hook to fix their >> bugs, but you can't make them do it. They have many pressures on them, &

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

Dylan Baker <dy...@pnwbakers.com> writes: > Quoting Mark Janes (2018-03-12 12:40:47) >> Handling a screw-up could be done by maintainers by force-pushing the >> commits off the WIP branch, and adding some annotations that prevent the >> broken commit from being re-a

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

Emil Velikov <emil.l.veli...@gmail.com> writes: > On 12 March 2018 at 11:31, Juan A. Suarez Romero <jasua...@igalia.com> wrote: >> On Fri, 2018-03-09 at 12:12 -0800, Mark Janes wrote: >>> - Patches are applied to proposed stable branch by automation when the >

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

Dylan Baker <dy...@pnwbakers.com> writes: > Quoting Emil Velikov (2018-03-12 08:38:31) >> On 12 March 2018 at 11:31, Juan A. Suarez Romero <jasua...@igalia.com> wrote: >> > On Fri, 2018-03-09 at 12:12 -0800, Mark Janes wrote: >> >> Ilia Mirkin <imir.

Re: [Mesa-dev] [RFC] Mesa release improvements - Release schedule

Andres Gomez writes: > Hi, > > * Release schedule: move from pre-announce Wed, announcement Fri [0] >to pre-announce Mon, announcement Wed. This seems like an improvement to me. > * Why would we want to do this? >* We have delays in the release every now and

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

"Juan A. Suarez Romero" <jasua...@igalia.com> writes: > On Fri, 2018-03-09 at 12:12 -0800, Mark Janes wrote: >> Ilia Mirkin <imir...@alum.mit.edu> writes: >> >> > On Tue, Mar 6, 2018 at 2:34 PM, Emil Velikov <emil.l.veli...@gmail.com> >>

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

Ilia Mirkin writes: > On Tue, Mar 6, 2018 at 2:34 PM, Emil Velikov wrote: >> So while others explore ways of improving the testing, let me propose >> a few ideas for improving the actual releasing process. >> >> >> - Making the current state

Re: [Mesa-dev] [PATCH 1/5] i965: Hard code scratch_ids_per_subslice for Cherryview

Could this be the reason that BSW systems never reliably passed all unit tests? Up to now, we re-execute each failing test, and mark it as a pass if it succeeds a second time. I'd like to remove that crutch if possible. Jordan Justen writes: > Ken suggested that we

Re: [Mesa-dev] [PATCH] i965/sbe: fix number of inputs for active components

Please add the Fixes: tag, so this patch gets applied to the appropriate stable branches. Iago Toral Quiroga writes: > In 16631ca30ea6 we fixed gen9 active components to account for padded > inputs in the URB, which we can have with SSO programs. To do that, > instead of

Re: [Mesa-dev] [PATCH] mesa: Update vertex processing mode on _mesa_UseProgram.

writes: > From: Mathias Fröhlich > > Hi Clayton, > > The following change fixes the reported problem on my site. > Please test/review!! > > best > > Mathias > > > The change is a bug fix for 92d76a169: > mesa: Provide an alternative to

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.4 release candidate

Kenneth Graunke writes: > On Thursday, February 8, 2018 8:47:00 PM PST Emil Velikov wrote: >> Rejected (9) >> >> Jason Ekstrand (2): >> e52a9f18d69c94b7cb7f81361cdb9e2582c3d742 i965: Replace >> draw_aux_buffer_disabled with draw_aux_usage >>

Re: [Mesa-dev] [ANNOUNCE] mesa 17.3.4

Bas Nieuwenhuizen writes: > (-mesa-announce + Mark, Dave and James) > > Hi Emil, > > radv is broken for nearly all commercial games in 17.3.4. The cause is > > commit ad764e365beb8a119369b97f5cb95fc7ea8c > Author: Bas Nieuwenhuizen > Date:

Re: [Mesa-dev] [PATCH] meson: freedreno depends on nir

Acked-by: Mark Janes <mark.a.ja...@intel.com> Dylan Baker <dy...@pnwbakers.com> writes: > This fixes a race condition in building targets that link in freedreno. > > cc: Mark Janes <mark.a.ja...@intel.com> > Fixes: 0bbecc5a8548883f76a7 ("meson: define

Re: [Mesa-dev] [PATCH 1/2] i965: perf: use drmIoctl() instead of ioctl()

Tested-by: Mark Janes <mark.a.ja...@intel.com> Lionel Landwerlin <lionel.g.landwer...@intel.com> writes: > ioctl() might be interrupted, use drmIoctl() instead as it'll retry > automatically. > > Fixes: 27ee83eaf7e "i965: perf: add support for userspace configura

Re: [Mesa-dev] [PATCH 7/8] mesa: rename some 'client' array functions

This series that was just pushed to master generates ~200 assertions on all platforms, eg: piglit.spec.ext_framebuffer_multisample.formats 2 ext_framebuffer_multisample-formats: ../src/mesa/main/varray.c:1068: _mesa_enable_vertex_array_attrib: Assertion `attrib >= VERT_ATTRIB_GENERIC0' failed.

  1   2   3   >