Re: [Mesa-dev] [PATCH 2/2] amd/addrlib: update Mesa's copy of addrlib

On 20.11.18 07:46, Marek Olšák wrote: On Tue, Nov 20, 2018 at 12:08 AM Dave Airlie > wrote: On Tue, 20 Nov 2018 at 14:42, Marek Olšák mailto:mar...@gmail.com>> wrote: > > On Mon, Nov 19, 2018 at 7:15 PM Bas Nieuwenhuizen mailto:b...@basnieuwenhuizen.nl

[Mesa-dev] [PATCH v2] radv: remove dependency on addrlib gfx9_enum.h

From: Nicolai Hähnle v2: - use SI_CONTEXT_REG_OFFSET Reviewed-by: Dave Airlie --- src/amd/common/sid.h | 3 +++ src/amd/vulkan/radv_cmd_buffer.c | 6 ++ src/amd/vulkan/radv_device.c | 9 - 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/src/amd

[Mesa-dev] [PATCH 0/2] amd/addrlib: update Mesa's copy of addrlib

Hi all, nothing special here, just updating addrlib from the internal version. This is bigger than usual because they decided to reorganize the source a bit. It does make a bit more sense this way. There's also a whole lot of churn in whitespace because for the first time I've used the same tool

[Mesa-dev] [PATCH 1/2] radv: remove dependency on addrlib gfx9_enum.h

From: Nicolai Hähnle --- src/amd/common/sid.h | 3 +++ src/amd/vulkan/radv_cmd_buffer.c | 6 ++ src/amd/vulkan/radv_device.c | 9 - 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h index 35782046dd5

[Mesa-dev] [PATCH] radeonsi: fix an out-of-bounds read reported by ASAN

From: Nicolai Hähnle We read 4 values out of sample_locs_8x, so make sure the array is big enough. Fixes: ac76aeef20 ("radeonsi: switch back to standard DX sample positions") --- src/gallium/drivers/radeonsi/si_state_msaa.c | 4 1 file changed, 4 insertions(+) diff --git a/s

[Mesa-dev] [PATCH] radv: include LLVM IR in the VK_AMD_shader_info "disassembly"

From: Nicolai Hähnle Helpful for debugging compiler backend problems: this allows us to easily retrieve the LLVM IR from RenderDoc. -- For the peanut gallery: AMD's official stance on radv hasn't changed. But we take regressions for radv caused by our changes in LLVM seriously. After

Re: [Mesa-dev] [PATCH 4/4] util: Get program name based on path when possible

On 12.09.2018 14:31, Kazlauskas, Nicholas wrote: On 09/12/2018 12:26 AM, Timothy Arceri wrote: On 12/9/18 2:24 am, Nicholas Kazlauskas wrote: Some programs start with the path and command line arguments in argv[0] (program_invocation_name). Chromium is an example of an application using mesa th

Re: [Mesa-dev] EGL_MESA_query_renderer

In a separate email, Rob wrote: > so, it was earlier discussed that > glXGetScreenDriver()/glXGetDriverConfig() equivalents could be lumped > into this extension, which is I guess not what you have done. I'm fairly agnostic on this, but if you do lump it into one extension, please make the GetD

Re: [Mesa-dev] [PATCH 4/6] ddebug: use util_snprintf() in dd_get_debug_filename_and_mkdir

Reviewed-by: Nicolai Hähnle On 01.08.2018 20:53, Andres Gomez wrote: Instead of plain snprintf(). To fix the MSVC 2013 build: Compiling src\gallium\auxiliary\driver_ddebug\dd_draw.c ... dd_draw.c c:\projects\mesa\src\gallium\auxiliary\driver_ddebug\dd_util.h(60) : warning C4013: 'snp

Re: [Mesa-dev] Getting started on DriConf replacement - EVoC 2018

Hi Veluri, glad to see you're interested. There have been several attempts at a DriConf replacement over the years. I believe the most advanced one currently is by Jean Hertel at https://github.com/jlHertel/adriconf -- so your best bet is probably to check that out, see what if anything is st

Re: [Mesa-dev] [PATCH] radv: Implement alternate GFX9 scissor workaround.

On 28.05.2018 12:21, Bas Nieuwenhuizen wrote: On Mon, May 28, 2018 at 12:19 PM, Nicolai Hähnle wrote: On 27.05.2018 18:57, Bas Nieuwenhuizen wrote: This improves dota2 performance for me by 11% when I force the GPU DPM level to low (otherwise dota2 is CPU limited for 4k on my threadripper

Re: [Mesa-dev] [PATCH] radv: Implement alternate GFX9 scissor workaround.

On 27.05.2018 18:57, Bas Nieuwenhuizen wrote: This improves dota2 performance for me by 11% when I force the GPU DPM level to low (otherwise dota2 is CPU limited for 4k on my threadripper), which should be a large part of the radv-amdvlk gap. (For me with that was radv 60.3 -> 66.6, while AMDVLK

Re: [Mesa-dev] Gitlab migration

On 27.05.2018 18:03, Marek Olšák wrote: On Sun, May 27, 2018 at 10:47 AM, Jason Ekstrand > wrote: On May 26, 2018 21:03:39 Marek Olšák mailto:mar...@gmail.com>> wrote: On Sat, May 26, 2018 at 11:13 AM, Jason Ekstrand mailto:ja...@jlekstrand.net>> wrote:

Re: [Mesa-dev] [PATCH 2/2] st/mesa: handle GL_UNSIGNED_INT64_ARB in st_pipe_vertex_format

On 25.05.2018 23:03, Marek Olšák wrote: From: Marek Olšák Bindless texture handles can be passed via vertex attribs using this type. This fixes a bunch of bindless piglit tests on radeonsi. Cc: 18.0 18.1 --- src/mesa/state_tracker/st_atom_array.c | 3 +++ 1 file changed, 3 insertions(+) d

[Mesa-dev] [PATCH] radeonsi: set GLC on stores to write-only memory

From: Nicolai Hähnle The only effect this has is that written cache lines are immediately freed in L1$. We're not going to read the data again, so it's better to leave room for other things in the cache. --- src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c | 12 +++- 1 file c

Re: [Mesa-dev] [PATCH 8/8] mesa: expose ARB_tessellation_shader in the compatibility profile

On 24.05.2018 15:32, Timothy Arceri wrote: On 24/05/18 18:41, Nicolai Hähnle wrote: What about selection and feedback mode for geometry shaders and tessellation? For now this will only enable the extension in compat when using env overrides. So this patch should be ok as is IMO. Fair

Re: [Mesa-dev] [PATCH 4/8] gallium: add PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY

Reviewed-by: Nicolai Hähnle On 23.05.2018 22:58, Marek Olšák wrote: From: Marek Olšák --- src/gallium/docs/source/screen.rst | 6 ++ src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915

Re: [Mesa-dev] Gitlab migration

On 24.05.2018 08:46, Tapani Pälli wrote: * [Optional] Merge-request workflow.  With the rise of github, there are many developers out there who are used to the merge-request workflow and switching to that may lower the barrier to entry for new contributors. I admit that it's been a while sinc

Re: [Mesa-dev] [PATCH] st/mesa: simplify lastLevel determination in st_finalize_texture

Seems plausible, although that code tends to be tricky as hell. Assuming no piglit / CTS regressions: Reviewed-by: Nicolai Hähnle On 23.05.2018 22:43, Marek Olšák wrote: From: Marek Olšák This fixes shader images where we always bind stObj->pt and not individual gl_texture_ima

Re: [Mesa-dev] [PATCH 3/8] mesa: update fixed-func state constants for TCS, TES, GS

gt;Parameters; + if (prog) { It may be slightly better to put this check into the caller to avoid the function call overhead. But admittedly that's just a hunch, and it's your call. Apart from that, patches 1-3: Reviewed-by: Nicolai Hähnle + const struct gl_program_parameter_

Re: [Mesa-dev] [PATCH 1/6] ac/surface/gfx6: don't overallocate mipmapped HTILE

For the series: Reviewed-by: Nicolai Hähnle On 23.05.2018 23:29, Marek Olšák wrote: ping On Wed, May 16, 2018 at 9:47 PM, Marek Olšák <mailto:mar...@gmail.com>> wrote: From: Marek Olšák mailto:marek.ol...@amd.com>> ---  src/amd/common/ac_surface.c | 13 ++

Re: [Mesa-dev] [PATCH 7/8] mesa: expose AMD_vertex_shader_layer in the compatibility profile

Reviewed-by: Nicolai Hähnle On 23.05.2018 22:58, Marek Olšák wrote: From: Marek Olšák This requires layered FBOs from GL 3.2. Gallium drivers don't expose this yet due to: "st/mesa: use PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY" --- src/mesa/drivers/dri/i965/intel_e

Re: [Mesa-dev] [PATCH 8/8] mesa: expose ARB_tessellation_shader in the compatibility profile

What about selection and feedback mode for geometry shaders and tessellation? Cheers, Nicolai On 23.05.2018 22:58, Marek Olšák wrote: From: Marek Olšák Gallium drivers don't expose this yet due to: "st/mesa: use PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY" --- src/mesa/drivers/dri/i965/

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for advanced MSAA

On 18.05.2018 06:05, Marek Olšák wrote: From: Marek Olšák The interface only uses general MSAA terms, so it's "advanced MSAA" and not something vendor-specific. It's a proper subset of EQAA, and a proper superset of CSAA, so it's neither. Changes: - pipe_resource is changed - is_format_suppor

Re: [Mesa-dev] [PATCH 3/3] radeonsi: fix passing gl_ClipVertex for GS and tess

STATIC_ASSERT(SI_MAX_IO_GENERIC + 12 + 8 <= 63); return SI_MAX_IO_GENERIC + 12 + index; + case TGSI_SEMANTIC_CLIPVERTEX: + return 63; default: + printf("name=%u\n", semantic_name); fprintf(stderr, ...); Apart from that, the series is

Re: [Mesa-dev] Gitlab migration

Hi Jason, On 23.05.2018 21:34, Jason Ekstrand wrote: Mesa developers, tl;dr.  Please go to gitlab.freedesktop.org , create your account, and upload your SSH keys.  Instructions are the bottom of this e-mail. The freedesktop.org admins

Re: [Mesa-dev] [PATCH v2] ac: Use DPP for build_ddxy where possible.

the older chips, right? So all the code below can be removed once we drop support for LLVM < 7 (which will of course be quite some time in the future, but hey!) Apart from that, Reviewed-by: Nicolai Hähnle + unsigned tl_lanes[4], trbl_lanes[4]; + + for (

Re: [Mesa-dev] [PATCH] ac: Use DPP for build_ddxy where possible.

On 23.05.2018 11:48, Bas Nieuwenhuizen wrote: WQM is pretty reliable now on LLVM 7, so let us just use DPP + WQM. This gives approximately a 1.5% performance increase on the vrcompositor built-in benchmark. --- src/amd/common/ac_llvm_build.c | 243 ++--- 1 file cha

Re: [Mesa-dev] [PATCH 00/16] RadeonSI: A bunch of random changes

I don't quite understand patch 8. All the rest (v2 of patch 2) are: Reviewed-by: Nicolai Hähnle On 02.05.2018 06:00, Marek Olšák wrote: Hi, These are pretty random. Please review. Thanks, Marek ___ mesa-dev mailing list mes

Re: [Mesa-dev] [PATCH 08/16] ac/surface/gfx6: don't overallocate mipmapped HTILE

On 02.05.2018 06:00, Marek Olšák wrote: From: Marek Olšák --- src/amd/common/ac_surface.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c index b2af1f70b69..341a7854fe5 100644 --- a/src/amd/common/ac_surfa

Re: [Mesa-dev] [PATCH 14/14] ac/gpu_info: add has_read_registers_query

For the series: Reviewed-by: Nicolai Hähnle On 03.05.2018 02:19, Marek Olšák wrote: From: Marek Olšák --- src/amd/common/ac_gpu_info.c | 2 ++ src/amd/common/ac_gpu_info.h | 1 + src/gallium/drivers/radeonsi/si_debug.c | 5 ++--- src

Re: [Mesa-dev] [PATCH 1/2] ac: add subgroup scan functions for SI

tmp1 = LLVMBuildSelect(ctx->builder, active, tmp2, tmp1, ""); + active = LLVMBuildICmp(ctx->builder, LLVMIntEQ, tid, LLVMConstInt(ctx->i32, 0, 0), ""); + result = LLVMBuildSelect(ctx->builder, active, identity, tmp1, ""); +

Re: [Mesa-dev] [PATCH 2/2] eg/compute: Drop reference on code_bo in destructor.

Reviewed-by: Nicolai Hähnle On 04.05.2018 08:34, Jan Vesely wrote: Signed-off-by: Jan Vesely --- src/gallium/drivers/r600/evergreen_compute.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/gallium/drivers/r600/evergreen_compute.c b/src/gallium/drivers/r600

Re: [Mesa-dev] [PATCH 1/2] eg/compute: Use reference counting to handle compute memory pool.

On 04.05.2018 08:34, Jan Vesely wrote: The original bug/corruption was by util_unreference_framebuffer_state, trying to drop reference on cbuf[0] (global AS for OCL). Adding reference counting to set_rat uncovered problems with acessing the pool->bo. Also drops leaked memory from 7,4kB to 1,7Kb

Re: [Mesa-dev] Ryzen 2500U lockup, HP Envy 360

Based on reports from other Raven users, it may be worth trying to update your kernel. Apart from that, the only way to help you would be if you submit a proper bugreport on freedesktop bugzilla where you clearly explain - when the lockup happened and how to reproduce it - exactly which versi

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for EQAA

On 01.05.2018 22:48, Marek Olšák wrote: +**nr_color_samples**: This is the number of color samples for EQAA, while +``nr_samples`` is the number of coverage samples. If the format is Z/S, +``nr_color_samples`` is ignored. Constraints: +* ``nr_color_

Re: [Mesa-dev] [PATCH 9/9] radeonsi: add an environment variable that forces EQAA for MSAA allocations

, the environment variable *will* have an effect on radeon, but it'll likely just not work correctly because the surfaces aren't computed correctly. So it seems a good idea to have an explicit check for that. With that, patches 5-9: Reviewed-by: Nicolai Hähnle Marek On Wed, May 2

Re: [Mesa-dev] [PATCH 4/9] radeonsi: use better sample locations for 8x EQAA

On 02.05.2018 06:13, Marek Olšák wrote: From: Marek Olšák Verified with the piglit MSAA accuracy test. Reviewed-by: Nicolai Hähnle --- src/gallium/drivers/radeonsi/si_state_msaa.c | 32 +++- 1 file changed, 11 insertions(+), 21 deletions(-) diff --git a/src/gallium

Re: [Mesa-dev] [PATCH 3/9] radeonsi: improve quality of 16 sample locations

On 02.05.2018 06:13, Marek Olšák wrote: From: Marek Olšák This results in better 16x and 8x quality when using these locations. Verified with the piglit MSAA accuracy test. How did you come up with those? :) Reviewed-by: Nicolai Hähnle --- src/gallium/drivers/radeonsi/si_state_msaa.c

Re: [Mesa-dev] [PATCH 2/9] radeonsi: use better sample locations for 4x MSAA

doesn't care. Curious. Can you actually tell the difference? Anyway, Reviewed-by: Nicolai Hähnle --- src/gallium/drivers/radeonsi/si_state_msaa.c | 21 ++-- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_state_msaa.c

Re: [Mesa-dev] [PATCH 1/9] radeonsi: reorder sample locations as required by EQAA

I={2,3} adds more detail to the vicinity of sample I-2) Isn't technically the requirement only that 0/1 are in opposite quadrants and 2/3 fill in the rest. Anyway, Reviewed-by: Nicolai Hähnle + * + * Sample 4 is approx. in the same quadrant as sample 0. (top-left) + * Sample 5 is app

Re: [Mesa-dev] [PATCH v3 05/13] mesa/st: Add helper classes for array merging and interleaving

On 01.05.2018 17:46, Gert Wollny wrote: Am Dienstag, den 01.05.2018, 12:38 +0200 schrieb Nicolai Hähnle: First some high-level remarks: Why is `finalized` necessary? The `finalize` operation should be idempotent, i.e. if you call if twice in a row, the second time should be a no-op. It

Re: [Mesa-dev] [PATCH v3 02/13] mesa/st: glsl_to_tgsi: Split arrays who's elements are only accessed directly

On 01.05.2018 18:13, Gert Wollny wrote: Am Dienstag, den 01.05.2018, 11:57 +0200 schrieb Nicolai Hähnle: So the GLSL transforms don't already do this? Interesting... anyway, seems a nice improvement, When I first sent this patch stand-alone there were some comments about this:

[Mesa-dev] [PATCH] amd/common: use llvm.amdgcn.wqm for explicit derivatives

From: Nicolai Hähnle To comply with an upcoming change in LLVM, see https://reviews.llvm.org/D46051 --- src/amd/common/ac_llvm_build.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c index f21a5d2623c..c9b2e36b632 100644

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for EQAA

On 01.05.2018 16:48, Roland Scheidegger wrote: -**nr_samples** the nr of msaa samples. 0 (or 1) specifies a resource -which isn't multisampled. +**nr_samples**: For Z/S, this is the number of samples. For color, if EQAA +is unsupported, this is the number of both coverage samples and color sample

Re: [Mesa-dev] [PATCH v3 13/13] mesa/st/glsl_to_tgsi: Expose array live range tracking and merging

On 28.04.2018 21:30, Gert Wollny wrote: This patch ties in the array split, merge, and interleave code. shader-wb changes in the TGSI code are: You mean shader-db? Cheers, Nicolai original code | array-merge | change in % mean max | meanmax | mean

Re: [Mesa-dev] [PATCH v3 10/13] mesa/st/glsl_to_tgsi: move evaluation of read mask up in the call hierarchy

Again, I don't think having separate classes for tracking temporaries and tracking arrays is a good idea. They do require some semantic differences, but the only one I can really think of can be summarized as "there are no unconditional writes into arrays". If you think about it that way, it s

Re: [Mesa-dev] [PATCH v3 09/13] mesa/st/glsl_to_tgsi: rename access_record to register_merge_record and some more renames

Reviewed-by: Nicolai Hähnle On 28.04.2018 21:30, Gert Wollny wrote: Signed-off-by: Gert Wollny --- .../state_tracker/st_glsl_to_tgsi_temprename.cpp | 61 +++--- .../state_tracker/st_glsl_to_tgsi_temprename.h | 2 +- 2 files changed, 32 insertions(+), 31 deletions

Re: [Mesa-dev] [PATCH v3 05/13] mesa/st: Add helper classes for array merging and interleaving

First some high-level remarks: Why is `finalized` necessary? The `finalize` operation should be idempotent, i.e. if you call if twice in a row, the second time should be a no-op. So you can just call finalize on the target array unconditionally. That would make the code cleaner. Similarly, t

Re: [Mesa-dev] [PATCH v3 06/13] mesa/st/glsl_to_tgsi: Add class to track array live range

On 28.04.2018 21:30, Gert Wollny wrote: todo explain Indeed... how is that different from the tracking of ordinary registers? Cheers, Nicolai Signed-off-by: Gert Wollny --- .../state_tracker/st_glsl_to_tgsi_array_merge.cpp | 69 ++ .../state_tracker/st_glsl_to_tgsi

Re: [Mesa-dev] [PATCH v3 04/13] mesa/st/glsl_to_tgsi:rename lifetime to register_live_range

0; i < ntemps; ++i) { RENAME_DEBUG(debug_log<< setw(4) << i); - lifetimes[i] = acc[i].get_required_lifetime(); - RENAME_DEBUG(debug_log << ": [" << lifetimes[i].begin << ", " -<< lifetime

Re: [Mesa-dev] [PATCH v3 03/13] mesa/st/glsl_to_tgsi: Properly resolve life times simple if/else + use constructs

On 28.04.2018 21:30, Gert Wollny wrote: in constructs like below, currently the live range estimation extends the live range of t unecessarily to the whole loop because it was not detected that t is unconditional written and later read only in the "if (a)" scope. while (foo) { ...

Re: [Mesa-dev] [PATCH v3 02/13] mesa/st: glsl_to_tgsi: Split arrays who's elements are only accessed directly

So the GLSL transforms don't already do this? Interesting... anyway, seems a nice improvement, I just have some stylistic nitpicks below. On 28.04.2018 21:30, Gert Wollny wrote: Array who's elements are only accessed directly are replaced by the according number of temporary registers. By doin

Re: [Mesa-dev] [PATCH v3 01/13] mesa/st/glsl_to_tgsi: Add method to collect some statistics

Please make this thread-safe. Thanks, Nicolai On 28.04.2018 21:30, Gert Wollny wrote: When mesa is compiled in debug mode then this adds the possibility to print out some statistics about the translated shaders to a file. The functionality is enabled by setting the environment variable G

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for EQAA

On 01.05.2018 01:43, Marek Olšák wrote: From: Marek Olšák This is a hypothetical interface for EQAA (a superset of CSAA). CSAA could be exposed via GL_NV_framebuffer_multisample_coverage. EQAA additionally removes the restriction that the number of samples in all FBO attachments must match, whi

Re: [Mesa-dev] [PATCH 1/1] main: fail texture_storage() call if the size is not okay

Reviewed-by: Nicolai Hähnle On 27.04.2018 17:34, James Xiong wrote: From: "Xiong, James" Signed-off-by: Xiong, James --- src/mesa/main/texstorage.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c index 44edba3..9cb8

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

On 27.04.2018 19:23, Marek Olšák wrote: On Fri, Apr 27, 2018 at 4:14 AM, Nicolai Hähnle <mailto:nhaeh...@gmail.com>> wrote: Sorry, but I still don't understand the logic of this :/ What we want to check for is that all the DCC bytes of a mip-level are contiguous, r

Re: [Mesa-dev] [PATCH 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

On 27.04.2018 19:21, Gurchetan Singh wrote: On Fri, Apr 27, 2018 at 2:00 AM, Nicolai Hähnle wrote: That was the whole point of the USER_STRIDE business. There are two alternatives I can see: 1. Change minigbm so that it always maps the entire texture regardless of what the caller requests

Re: [Mesa-dev] [PATCH 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

On 27.04.2018 17:55, Marek Olšák wrote: Even if ChromeOS doesn't map the whole texture, we still need the stride change, because the hw can't use the display stride for mappings (it's an unsupported user stride). You're right. They're two separate issues, but both need fixing (or not, but it

Re: [Mesa-dev] [PATCH v2] ac: fix texture query LOD for 1D textures on GFX9

Reviewed-by: Nicolai Hähnle On 25.04.2018 18:15, Samuel Pitoiset wrote: 1D textures are allocated as 2D which means we only need one coordinate for texture query LOD. v2: - move the fixup into ac_nir_to_llvm Fixes: 625dcbbc456 ("amd/common: pass address components individual

Re: [Mesa-dev] [PATCH 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

On 26.04.2018 04:30, Marek Olšák wrote: On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh mailto:gurchetansi...@chromium.org>> wrote: On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák mailto:mar...@gmail.com>> wrote: > From: Nicolai Hähnle mailto:nicolai.haeh...@amd.com>&

Re: [Mesa-dev] [PATCH v2] ac/nir: set lod to 0 for ac_image_load_mip

On 27.04.2018 10:05, Samuel Pitoiset wrote: On 04/26/2018 01:51 PM, Nicolai Hähnle wrote: Is there any reason why we can't just use ac_image_load in such cases? For nit_texop_txf_ms we need one more coordinate for the sample index, if we use ac_image_load we only loads 2 coordinates in

Re: [Mesa-dev] [PATCH] util/u_queue: fix a deadlock in util_queue_finish

Nice catch! Reviewed-by: Nicolai Hähnle On 24.04.2018 23:06, Marek Olšák wrote: From: Marek Olšák Cc: 18.0 18.1 --- src/util/u_queue.c | 9 + src/util/u_queue.h | 1 + 2 files changed, 10 insertions(+) diff --git a/src/util/u_queue.c b/src/util/u_queue.c index dba23f96456

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

Sorry, but I still don't understand the logic of this :/ What we want to check for is that all the DCC bytes of a mip-level are contiguous, right? Why does it matter for that whether a level is the last level? Here's the thought experiment that I can't make sense of: Let's say that you have

Re: [Mesa-dev] [PATCH v2] ac/nir: set lod to 0 for ac_image_load_mip

Is there any reason why we can't just use ac_image_load in such cases? On 26.04.2018 13:18, Samuel Pitoiset wrote: Otherwise we hit an assertion in ac_build_image_opcode() for ac_image_load_mip. v2: - set only for ac_image_load_mip Fixes: 24fb3e6aa16 ("ac/nir: use ac_build_image_opcode for ima

Re: [Mesa-dev] [PATCH 09/10] gallium: add PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT

On 25.04.2018 23:29, Roland Scheidegger wrote: Am 25.04.2018 um 23:16 schrieb Marek Olšák: From: Marek Olšák --- src/gallium/docs/source/screen.rst | 3 +++ src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/ga

Re: [Mesa-dev] [PATCH] ac: fix texture query LOD for 1D textures on GFX9

On 25.04.2018 16:46, Samuel Pitoiset wrote: On 04/25/2018 04:10 PM, Nicolai Hähnle wrote: On 25.04.2018 11:58, Samuel Pitoiset wrote: 1D textures are allocated as 2D which means we only need one coordinate for texture query LOD. Fixes: 625dcbbc456 ("amd/common: pass address compo

Re: [Mesa-dev] [PATCH] ac: fix texture query LOD for 1D textures on GFX9

On 25.04.2018 11:58, Samuel Pitoiset wrote: 1D textures are allocated as 2D which means we only need one coordinate for texture query LOD. Fixes: 625dcbbc456 ("amd/common: pass address components individually to ac_build_image_intrinsic") Cc: 18.1 Signed-off-by: Samuel Pitoiset --- src/amd/c

Re: [Mesa-dev] [Mesa-stable] [PATCH] ac: fix the number of coordinates for ac_image_get_lod and arrays

On 23.04.2018 21:45, Samuel Pitoiset wrote: On 04/23/2018 08:42 PM, Marek Olšák wrote: On Mon, Apr 23, 2018 at 1:12 PM, Samuel Pitoiset mailto:samuel.pitoi...@gmail.com>> wrote:     On 04/23/2018 06:55 PM, Nicolai Hähnle wrote:     On 23.04.2018 17:52, Samuel Pitoiset

Re: [Mesa-dev] [PATCH] ac/nir: add missing round_slice for 1D arrays

l Pitoiset Reviewed-by: Nicolai Hähnle --- src/amd/common/ac_nir_to_llvm.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c index 72c773522f4..34efb2b9fe1 100644 --- a/src/amd/common/ac_nir_to_llvm.c +++ b/src/

Re: [Mesa-dev] [PATCH] ac: fix the number of coordinates for ac_image_get_lod and arrays

break; + case ac_image_2darray: + num_coords = 2; This is probably also needed for cube maps, isn't it? With that: Reviewed-by: Nicolai Hähnle + break; + default: +

Re: [Mesa-dev] [PATCH] ac: teach get_ac_sampler_dim() about subpass attachments

Thanks! Reviewed-by: Nicolai Hähnle On 23.04.2018 16:55, Samuel Pitoiset wrote: Suggested by Nicolai. Signed-off-by: Samuel Pitoiset --- src/amd/common/ac_nir_to_llvm.c | 24 +++- 1 file changed, 7 insertions(+), 17 deletions(-) diff --git a/src/amd/common

Re: [Mesa-dev] [PATCH 1/2] ac/radv/radeonsi: refactor raster_config default values getters.

For the series: Reviewed-by: Nicolai Hähnle On 23.04.2018 02:17, Dave Airlie wrote: From: Dave Airlie This just makes this common code between the two drivers. --- src/amd/common/ac_gpu_info.c| 93 + src/amd/common/ac_gpu_info.h| 4

Re: [Mesa-dev] [PATCH 2/2] ac/radv/radeonsi: refactor harvest config register getters.

Acked-by: Nicolai Hähnle On 23.04.2018 02:43, Dave Airlie wrote: From: Dave Airlie This refactors the code out to share it between radv and radeonsi. --- src/amd/common/ac_gpu_info.c| 113 src/amd/common/ac_gpu_info.h| 4 ++ src

Re: [Mesa-dev] [PATCH 5/5] radeonsi: use common gs_table_depth code

Patches 2, 3, 5: Reviewed-by: Nicolai Hähnle On 23.04.2018 01:59, Dave Airlie wrote: From: Dave Airlie --- src/gallium/drivers/radeonsi/si_pipe.c | 33 ++--- 1 file changed, 2 insertions(+), 31 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_pipe.c

Re: [Mesa-dev] [PATCH] ac/nir: fix image dimension for subpass attachments

On 20.04.2018 18:06, Samuel Pitoiset wrote: For subpass attachments we need one more coordinate with the sample index, so make them array types. Sorry about that. Shouldn't it be layer index instead of sample index though? If I understand this right, I think it would be cleaner to just chang

Re: [Mesa-dev] 16-bit comparisons in NIR

On 21.04.2018 02:32, Bas Nieuwenhuizen wrote: On Fri, Apr 20, 2018 at 5:16 PM, Jason Ekstrand wrote: On Fri, Apr 20, 2018 at 5:16 AM, Nicolai Hähnle wrote: On 20.04.2018 10:21, Iago Toral wrote: Hi, while developing support for Vulkan shaderInt16 on Anvil I came across a feature of NIR

Re: [Mesa-dev] 16-bit comparisons in NIR

On 20.04.2018 10:21, Iago Toral wrote: Hi, while developing support for Vulkan shaderInt16 on Anvil I came across a feature of NIR that was a bit inconvenient: bools are always 32-bit by design, but the Intel hardware produces 16-bit bool results for 16- bit comparisons, so that creates a proble

Re: [Mesa-dev] [PATCH 5/5] radeonsi/nir: fix crash in test involving the sample mask

On 12.04.2018 02:13, Timothy Arceri wrote: On 11/04/18 20:56, Nicolai Hähnle wrote: From: Nicolai Hähnle Please add to the commit message which test was fixed by this. Otherwise the change seems reasonable: I agree, unfortunately I couldn't find my notes on this anymore... C

Re: [Mesa-dev] [PATCH 2/5] radeonsi: fix error paths of si_texture_transfer_map

On 12.04.2018 02:10, Timothy Arceri wrote: On 11/04/18 20:56, Nicolai Hähnle wrote: From: Nicolai Hähnle trans is zero-initialized, but trans->resource is setup immediately so needs to be dereferenced. ---   src/gallium/drivers/radeonsi/si_texture.c | 25 -   1 f

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

On 18.04.2018 21:53, Marek Olšák wrote: On Wed, Apr 18, 2018 at 5:54 AM, Nicolai Hähnle <mailto:nhaeh...@gmail.com>> wrote: On 17.04.2018 02:41, Marek Olšák wrote: From: Marek Olšák mailto:marek.ol...@amd.com>> ---   src/amd/common/ac

Re: [Mesa-dev] [PATCH 1/2] radv: enable/disable prediction for the DCC decompression pass

s/prediction/predication/ ? :) On 18.04.2018 14:34, Samuel Pitoiset wrote: Performing a DCC decompression pass is currently pretty rare, but using prediction allows the GPU to skip unnecessary passes. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_meta_fast_clear.c | 4 ++-- 1 file

Re: [Mesa-dev] [PATCH 1/2] ac/nir: fix interp mode for nir_intrinsic_interp_var_at_sample

On 18.04.2018 14:36, Samuel Pitoiset wrote: On 04/18/2018 12:19 PM, Nicolai Hähnle wrote: On 17.04.2018 15:08, Samuel Pitoiset wrote: This fixes the following CTS tests: dEQP-VK.pipeline.multisample_interpolation.sample_interpolate_at_consistency.* This restores the previous behaviour

Re: [Mesa-dev] [PATCH 3/3] radeon/vce: disable vce dual pipe on VegaM

Series is: Acked-by: Nicolai Hähnle On 18.04.2018 00:14, Marek Olšák wrote: From: Leo Liu --- src/gallium/drivers/radeon/radeon_vce.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeon/radeon_vce.c b/src/gallium/drivers/radeon/radeon_vce.c

Re: [Mesa-dev] [PATCH 1/2] ac/nir: fix interp mode for nir_intrinsic_interp_var_at_sample

On 17.04.2018 15:08, Samuel Pitoiset wrote: This fixes the following CTS tests: dEQP-VK.pipeline.multisample_interpolation.sample_interpolate_at_consistency.* This restores the previous behaviour, maybe the CTS tests were wrong? Fixes: 22b116171f8 ("radv: fix interp at sample code.") Signed-off

Re: [Mesa-dev] [PATCH 8/9] Revert "radeonsi: fix potential use-after-free of debug callbacks"

How can this possibly deadlock? Is this during process exit, like in the case where we got a deadlock when LLVM called abort()? The rest of the series is Reviewed-by: Nicolai Hähnle On 17.04.2018 02:52, Marek Olšák wrote: From: Marek Olšák This reverts commit

Re: [Mesa-dev] [PATCH 9/9] radeonsi: rename r600_texture::resource to buffer

Series is: Reviewed-by: Nicolai Hähnle On 17.04.2018 02:42, Marek Olšák wrote: From: Marek Olšák r600_resource could be renamed to si_buffer. --- src/gallium/drivers/radeon/radeon_vcn_dec.c | 2 +- src/gallium/drivers/radeonsi/cik_sdma.c | 22 +-- src/gallium/drivers

Re: [Mesa-dev] [PATCH 5/7] radeonsi: implement DCC fast clear swizzle constraints more accurately

hannels == 3) + return 1; /* same as xxxA; is any value OK here? */ Use true instead of 1 for the bool. Apart from that, Reviewed-by: Nicolai Hähnle + + return si_translate_colorswap(format, false) <= 1; +} + +static bool vi_get_fast_clear_

Re: [Mesa-dev] [PATCH 7/7] radeonsi/gfx9: workaround for INTERP with indirect indexing

Patches 2, 3, 4, 6, 7: Reviewed-by: Nicolai Hähnle On 17.04.2018 02:41, Marek Olšák wrote: From: Marek Olšák and clean up the conditions. We might just simplify this because the only stage that can return 0 or 1 is VS. --- src/gallium/drivers/radeonsi/si_get.c | 19

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

On 17.04.2018 02:41, Marek Olšák wrote: From: Marek Olšák --- src/amd/common/ac_surface.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c index 7558dd91e34..c209b209da2 100644 --- a/src/amd/common/ac

Re: [Mesa-dev] [PATCH] glsl_to_tgsi: try harder to lower unsupported ir_binop_vector_extract

On 16.04.2018 23:02, Marek Olšák wrote: From: Marek Olšák Cc: 18.0 Would be nice to have an indication of what this fixes. Apart from that it looks reasonable. Reviewed-by: Nicolai Hähnle --- src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 5 + 1 file changed, 5 insertions

Re: [Mesa-dev] [PATCH] radeonsi/gfx9: fix a hang with an empty first IB

Reviewed-by: Nicolai Hähnle On 17.04.2018 21:54, Marek Olšák wrote: From: Marek Olšák This packet causes the no-op IB detection to fail, so the IB is always submitted. Also fix the no-op IB detection by moving the begin call. Cc: 18.0 --- src/gallium/drivers/radeonsi/si_pipe.c | 7

Re: [Mesa-dev] [PATCH 3/3] radeonsi: don't emit partial flushes for internal CS flushes only

On 16.04.2018 20:44, Marek Olšák wrote: On Sun, Apr 15, 2018 at 2:47 PM, Nicolai Hähnle <mailto:nhaeh...@gmail.com>> wrote: How much testing have you done with the radeon drm? It may be safer to just skip that part of the changes. Piglit on CIK. Probably good enough. May

Re: [Mesa-dev] [PATCH 1/3] radeonsi: implement mechanism for IBs without partial flushes at the end (v6)

On 16.04.2018 10:51, Christian König wrote: Am 15.04.2018 um 20:46 schrieb Nicolai Hähnle: On 07.04.2018 04:31, Marek Olšák wrote: From: Marek Olšák (This patch doesn't enable the behavior. It will be enabled in a later commit.) Draw calls from multiple IBs can be executed in parallel

Re: [Mesa-dev] [PATCH] ac/nir: Make the GFX9 buffer size fix apply to image loads/atomics too.

Reviewed-by: Nicolai Hähnle On 16.04.2018 00:09, Bas Nieuwenhuizen wrote: No clue how I missed those ... Fixes: 4503ff760c "ac/nir: Add workaround for GFX9 buffer views." CC: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105320 --- src/amd/common/ac_nir_to_l

Re: [Mesa-dev] [PATCH v3 5/7] ac: add LLVM build functions for subgroup instrinsics

LLVMTypeOf(identity), ""); Weird whitespace again. With those style nitpicks fixed, Reviewed-by: Nicolai Hähnle + swap = ac_build_quad_swizzle(ctx, result, 1, 0, 3, 2); + result = ac_build_alu_op(ctx, result, swap, op); + if (c

Re: [Mesa-dev] [PATCH 3/3] radeonsi: don't emit partial flushes for internal CS flushes only

How much testing have you done with the radeon drm? It may be safer to just skip that part of the changes. Apart from that, the series is Reviewed-by: Nicolai Hähnle On 07.04.2018 04:31, Marek Olšák wrote: From: Marek Olšák --- src/gallium/drivers/radeonsi/si_buffer.c| 6

Re: [Mesa-dev] [PATCH 1/3] radeonsi: implement mechanism for IBs without partial flushes at the end (v6)

On 07.04.2018 04:31, Marek Olšák wrote: From: Marek Olšák (This patch doesn't enable the behavior. It will be enabled in a later commit.) Draw calls from multiple IBs can be executed in parallel. v2: do emit partial flushes on SI v3: invalidate all shader caches at the beginning of IBs v4: do

[Mesa-dev] [PATCH 4/5] ac/nir: use ac_build_image_opcode for image intrinsics

From: Nicolai Hähnle So that we'll use the dimension-aware intrinsics in the future. --- src/amd/common/ac_llvm_build.c | 22 - src/amd/common/ac_llvm_build.h | 6 -- src/amd/common/ac_nir_to_llvm.c | 190 +--- 3 files changed, 78 insertions(+), 140

[Mesa-dev] [PATCH 5/5] amd/common: use the dimension-aware image intrinsics on LLVM 7+

From: Nicolai Hähnle Requires LLVM trunk r329166. --- src/amd/common/ac_llvm_build.c | 189 +++-- 1 file changed, 165 insertions(+), 24 deletions(-) diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c index b5561533437..15768d1d26d

<    1   2   3   4   5   6   7   8   9   10   >