[Mesa-dev] [PATCH] nir: use common deref has indirect code in scratch lowering.
From: Dave Airlie
This doesn't seem to need it's own copy here.
---
src/compiler/nir/nir_lower_scratch.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/src/compiler/nir/nir_lower_scratch.c
b/src/compiler/nir/nir_lower_scratch.c
index df0d3f43124..aacc2ddca08 100644
--- a/src/compiler/nir/nir_lower_scratch.c
+++ b/src/compiler/nir/nir_lower_scratch.c
@@ -34,20 +34,6 @@
#include "nir_builder.h"
#include "nir_deref.h"
-static bool
-deref_has_indirect(nir_deref_instr *deref)
-{
- while (deref->deref_type != nir_deref_type_var) {
- if (deref->deref_type == nir_deref_type_array &&
- nir_src_as_const_value(deref->arr.index) == NULL)
- return true;
-
- deref = nir_deref_instr_parent(deref);
- }
-
- return false;
-}
-
static void
lower_load_store(nir_builder *b,
nir_intrinsic_instr *intrin,
@@ -128,7 +114,7 @@ nir_lower_vars_to_scratch(nir_shader *shader,
if (!(deref->mode & modes))
continue;
-if (!deref_has_indirect(nir_src_as_deref(intrin->src[0])))
+if
(!nir_deref_instr_has_indirect(nir_src_as_deref(intrin->src[0])))
continue;
nir_variable *var = nir_deref_instr_get_variable(deref);
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111264] u_thread.h:64:39: error: too many arguments to function call, expected 1, have 2
https://bugs.freedesktop.org/show_bug.cgi?id=111264 Bug ID: 111264 Summary: u_thread.h:64:39: error: too many arguments to function call, expected 1, have 2 Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Mac OS X (All) Status: NEW Keywords: bisected, regression Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: v...@freedesktop.org QA Contact: mesa-dev@lists.freedesktop.org CC: matts...@gmail.com In file included from src/gallium/auxiliary/os/os_thread.h:42: src/util/u_thread.h:64:39: error: too many arguments to function call, expected 1, have 2 pthread_setname_np(pthread_self(), name); ~~ ^~~~ 9c411e020d164563fb6fcd92a28a435277bf0745 is the first bad commit commit 9c411e020d164563fb6fcd92a28a435277bf0745 Author: Matt Turner Date: Wed Jul 24 18:26:49 2019 -0700 util: Drop preprocessor guards for glibc-2.12 glibc-2.12 was released in 2010. No one is building new Mesa against 9 year old glibc, and removing these checks allows the code to work on other C libraries like musl. Acked-by: Eric Engestrom -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111262] lp_bld_misc.cpp:811:51: error: ‘llvm::AtomicOrdering’ is not a class or namespace
https://bugs.freedesktop.org/show_bug.cgi?id=111262 --- Comment #2 from Roland Scheidegger --- Seems like different llvm versions (before 5.0) need different wrappers for AtomicCmpXchg(). Pretty much the same issue as bug 02. Although I can't reproduce this bug actually, maybe depends on compiler. (I can reproduce the other one, for llvm 3.5-3.8 the function parameters are wrong.) Though I'm wondering if we actually need a mapping function, isn't it possible to just static cast the c enum to the class enum (as in (llvm::AtomicOrdering)SuccessOrdering)? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111262] lp_bld_misc.cpp:811:51: error: ‘llvm::AtomicOrdering’ is not a class or namespace
https://bugs.freedesktop.org/show_bug.cgi?id=111262 Vinson Lee changed: What|Removed |Added CC||srol...@vmware.com Keywords||bisected --- Comment #1 from Vinson Lee --- 2a55acbc1de0b8d1901988ee4f17d5697519c2d2 is the first bad commit commit 2a55acbc1de0b8d1901988ee4f17d5697519c2d2 Author: Dave Airlie Date: Tue Jul 2 07:10:53 2019 +1000 gallivm: add compare exchange wrapper This just pulls the wrapper from LLVM for older versions Reviewed-by: Roland Scheidegger :04 04 cee7aedaa0ddff70fc6ab1b45205ed5d9d7bf771 4aa821efcbb5ee85301518e72b79afb636a1fd0f M src bisect run success -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv/gfx10: add Wave32 support for compute shaders
r-b
On Tue, Jul 30, 2019 at 6:29 PM Samuel Pitoiset
wrote:
>
> It can be enabled with RADV_PERFTEST=cswave32.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_debug.h | 1 +
> src/amd/vulkan/radv_device.c | 12 +++-
> src/amd/vulkan/radv_nir_to_llvm.c | 14 +-
> src/amd/vulkan/radv_pipeline.c| 3 ++-
> src/amd/vulkan/radv_private.h | 3 +++
> src/amd/vulkan/radv_shader.c | 25 ++---
> src/amd/vulkan/radv_shader.h | 1 +
> 7 files changed, 53 insertions(+), 6 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_debug.h b/src/amd/vulkan/radv_debug.h
> index 723fabda57f..6414e882676 100644
> --- a/src/amd/vulkan/radv_debug.h
> +++ b/src/amd/vulkan/radv_debug.h
> @@ -64,6 +64,7 @@ enum {
> RADV_PERFTEST_BO_LIST= 0x20,
> RADV_PERFTEST_SHADER_BALLOT = 0x40,
> RADV_PERFTEST_TC_COMPAT_CMASK = 0x80,
> + RADV_PERFTEST_CS_WAVE_32 = 0x100,
> };
>
> bool
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 65e3ccf91ad..29be192443a 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -383,6 +383,14 @@ radv_physical_device_init(struct radv_physical_device
> *device,
>
> device->use_shader_ballot = device->instance->perftest_flags &
> RADV_PERFTEST_SHADER_BALLOT;
>
> + /* Determine the number of threads per wave for all stages. */
> + device->cs_wave_size = 64;
> +
> + if (device->rad_info.chip_class >= GFX10) {
> + if (device->instance->perftest_flags &
> RADV_PERFTEST_CS_WAVE_32)
> + device->cs_wave_size = 32;
> + }
> +
> radv_physical_device_init_mem_types(device);
> radv_fill_device_extension_table(device,
> &device->supported_extensions);
>
> @@ -494,6 +502,7 @@ static const struct debug_control radv_perftest_options[]
> = {
> {"bolist", RADV_PERFTEST_BO_LIST},
> {"shader_ballot", RADV_PERFTEST_SHADER_BALLOT},
> {"tccompatcmask", RADV_PERFTEST_TC_COMPAT_CMASK},
> + {"cswave32", RADV_PERFTEST_CS_WAVE_32},
> {NULL, 0}
> };
>
> @@ -1930,7 +1939,8 @@ VkResult radv_CreateDevice(
> device->scratch_waves = MAX2(32 *
> physical_device->rad_info.num_good_compute_units,
> max_threads_per_block / 64);
>
> - device->dispatch_initiator = S_00B800_COMPUTE_SHADER_EN(1);
> + device->dispatch_initiator = S_00B800_COMPUTE_SHADER_EN(1) |
> +
> S_00B800_CS_W32_EN(device->physical_device->cs_wave_size == 32);
>
> if (device->physical_device->rad_info.chip_class >= GFX7) {
> /* If the KMD allows it (there is a KMD hw register for it),
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index 020c6d17771..feaab8f6370 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -4317,6 +4317,15 @@ static void declare_esgs_ring(struct
> radv_shader_context *ctx)
> LLVMSetAlignment(ctx->esgs_ring, 64 * 1024);
> }
>
> +static uint8_t
> +radv_nir_shader_wave_size(struct nir_shader *const *shaders, int
> shader_count,
> + const struct radv_nir_compiler_options *options)
> +{
> + if (shaders[0]->info.stage == MESA_SHADER_COMPUTE)
> + return options->cs_wave_size;
> + return 64;
> +}
> +
> static
> LLVMModuleRef ac_translate_nir_to_llvm(struct ac_llvm_compiler *ac_llvm,
> struct nir_shader *const *shaders,
> @@ -4333,8 +4342,11 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct
> ac_llvm_compiler *ac_llvm,
> options->unsafe_math ? AC_FLOAT_MODE_UNSAFE_FP_MATH :
>AC_FLOAT_MODE_DEFAULT;
>
> + uint8_t wave_size = radv_nir_shader_wave_size(shaders,
> + shader_count, options);
> +
> ac_llvm_context_init(&ctx.ac, ac_llvm, options->chip_class,
> -options->family, float_mode, 64);
> +options->family, float_mode, wave_size);
> ctx.context = ctx.ac.context;
>
> radv_nir_shader_info_init(&shader_info->info);
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index 583b600dfdd..6b8b7bbe25a 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -4648,7 +4648,8 @@ radv_compute_generate_pm4(struct radv_pipeline
> *pipeline)
> threads_per_threadgroup = compute_shader->info.cs.block_size[0] *
> compute_shader->info.cs.block_size[1] *
> compute_shader->info.cs.block_size[2];
> - waves_per_threadgroup = DIV_ROUND_UP(threads_per_threadgroup, 64);
> + waves_per_threadgroup = DIV_ROUND_UP(threads_per_threadgroup,
> +
[Mesa-dev] [Bug 111262] lp_bld_misc.cpp:811:51: error: ‘llvm::AtomicOrdering’ is not a class or namespace
https://bugs.freedesktop.org/show_bug.cgi?id=111262 Bug ID: 111262 Summary: lp_bld_misc.cpp:811:51: error: ‘llvm::AtomicOrdering’ is not a class or namespace Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/Gallium/llvmpipe Assignee: mesa-dev@lists.freedesktop.org Reporter: v...@freedesktop.org QA Contact: mesa-dev@lists.freedesktop.org CC: airl...@freedesktop.org llvm-3.4 build error src/gallium/auxiliary/gallivm/lp_bld_misc.cpp: In function ‘llvm::AtomicOrdering mapFromLLVMOrdering(LLVMAtomicOrdering)’: src/gallium/auxiliary/gallivm/lp_bld_misc.cpp:811:51: error: ‘llvm::AtomicOrdering’ is not a class or namespace case LLVMAtomicOrderingNotAtomic: return llvm::AtomicOrdering::NotAtomic; ^ -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv/gfx10: add Wave32 support for compute shaders
It can be enabled with RADV_PERFTEST=cswave32.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_debug.h | 1 +
src/amd/vulkan/radv_device.c | 12 +++-
src/amd/vulkan/radv_nir_to_llvm.c | 14 +-
src/amd/vulkan/radv_pipeline.c| 3 ++-
src/amd/vulkan/radv_private.h | 3 +++
src/amd/vulkan/radv_shader.c | 25 ++---
src/amd/vulkan/radv_shader.h | 1 +
7 files changed, 53 insertions(+), 6 deletions(-)
diff --git a/src/amd/vulkan/radv_debug.h b/src/amd/vulkan/radv_debug.h
index 723fabda57f..6414e882676 100644
--- a/src/amd/vulkan/radv_debug.h
+++ b/src/amd/vulkan/radv_debug.h
@@ -64,6 +64,7 @@ enum {
RADV_PERFTEST_BO_LIST= 0x20,
RADV_PERFTEST_SHADER_BALLOT = 0x40,
RADV_PERFTEST_TC_COMPAT_CMASK = 0x80,
+ RADV_PERFTEST_CS_WAVE_32 = 0x100,
};
bool
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 65e3ccf91ad..29be192443a 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -383,6 +383,14 @@ radv_physical_device_init(struct radv_physical_device
*device,
device->use_shader_ballot = device->instance->perftest_flags &
RADV_PERFTEST_SHADER_BALLOT;
+ /* Determine the number of threads per wave for all stages. */
+ device->cs_wave_size = 64;
+
+ if (device->rad_info.chip_class >= GFX10) {
+ if (device->instance->perftest_flags & RADV_PERFTEST_CS_WAVE_32)
+ device->cs_wave_size = 32;
+ }
+
radv_physical_device_init_mem_types(device);
radv_fill_device_extension_table(device, &device->supported_extensions);
@@ -494,6 +502,7 @@ static const struct debug_control radv_perftest_options[] =
{
{"bolist", RADV_PERFTEST_BO_LIST},
{"shader_ballot", RADV_PERFTEST_SHADER_BALLOT},
{"tccompatcmask", RADV_PERFTEST_TC_COMPAT_CMASK},
+ {"cswave32", RADV_PERFTEST_CS_WAVE_32},
{NULL, 0}
};
@@ -1930,7 +1939,8 @@ VkResult radv_CreateDevice(
device->scratch_waves = MAX2(32 *
physical_device->rad_info.num_good_compute_units,
max_threads_per_block / 64);
- device->dispatch_initiator = S_00B800_COMPUTE_SHADER_EN(1);
+ device->dispatch_initiator = S_00B800_COMPUTE_SHADER_EN(1) |
+
S_00B800_CS_W32_EN(device->physical_device->cs_wave_size == 32);
if (device->physical_device->rad_info.chip_class >= GFX7) {
/* If the KMD allows it (there is a KMD hw register for it),
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index 020c6d17771..feaab8f6370 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -4317,6 +4317,15 @@ static void declare_esgs_ring(struct radv_shader_context
*ctx)
LLVMSetAlignment(ctx->esgs_ring, 64 * 1024);
}
+static uint8_t
+radv_nir_shader_wave_size(struct nir_shader *const *shaders, int shader_count,
+ const struct radv_nir_compiler_options *options)
+{
+ if (shaders[0]->info.stage == MESA_SHADER_COMPUTE)
+ return options->cs_wave_size;
+ return 64;
+}
+
static
LLVMModuleRef ac_translate_nir_to_llvm(struct ac_llvm_compiler *ac_llvm,
struct nir_shader *const *shaders,
@@ -4333,8 +4342,11 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct
ac_llvm_compiler *ac_llvm,
options->unsafe_math ? AC_FLOAT_MODE_UNSAFE_FP_MATH :
AC_FLOAT_MODE_DEFAULT;
+ uint8_t wave_size = radv_nir_shader_wave_size(shaders,
+ shader_count, options);
+
ac_llvm_context_init(&ctx.ac, ac_llvm, options->chip_class,
-options->family, float_mode, 64);
+options->family, float_mode, wave_size);
ctx.context = ctx.ac.context;
radv_nir_shader_info_init(&shader_info->info);
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 583b600dfdd..6b8b7bbe25a 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -4648,7 +4648,8 @@ radv_compute_generate_pm4(struct radv_pipeline *pipeline)
threads_per_threadgroup = compute_shader->info.cs.block_size[0] *
compute_shader->info.cs.block_size[1] *
compute_shader->info.cs.block_size[2];
- waves_per_threadgroup = DIV_ROUND_UP(threads_per_threadgroup, 64);
+ waves_per_threadgroup = DIV_ROUND_UP(threads_per_threadgroup,
+
device->physical_device->cs_wave_size);
if (device->physical_device->rad_info.chip_class >= GFX10 &&
waves_per_threadgroup == 1)
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 466f0288
Re: [Mesa-dev] [PATCH] radv/gfx10: only compile the GS copy shader on-demand
r-b
On Tue, Jul 30, 2019 at 3:11 PM Samuel Pitoiset
wrote:
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_pipeline.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index 583b600dfdd..e11196bd82e 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -2626,7 +2626,8 @@ void radv_create_shaders(struct radv_pipeline *pipeline,
>
> if(modules[MESA_SHADER_GEOMETRY]) {
> struct radv_shader_binary *gs_copy_binary = NULL;
> - if (!pipeline->gs_copy_shader) {
> + if (!pipeline->gs_copy_shader &&
> + !radv_pipeline_has_ngg(pipeline)) {
> pipeline->gs_copy_shader = radv_create_gs_copy_shader(
> device, nir[MESA_SHADER_GEOMETRY],
> &gs_copy_binary,
>
> keys[MESA_SHADER_GEOMETRY].has_multiview_view_index);
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111259] Presentation regression while rendering on X11 surface
https://bugs.freedesktop.org/show_bug.cgi?id=111259 Lionel Landwerlin changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |NOTOURBUG --- Comment #6 from Lionel Landwerlin --- Thanks, feel free to open if you still have the issue. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv/gfx10: only compile the GS copy shader on-demand
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 583b600dfdd..e11196bd82e 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -2626,7 +2626,8 @@ void radv_create_shaders(struct radv_pipeline *pipeline,
if(modules[MESA_SHADER_GEOMETRY]) {
struct radv_shader_binary *gs_copy_binary = NULL;
- if (!pipeline->gs_copy_shader) {
+ if (!pipeline->gs_copy_shader &&
+ !radv_pipeline_has_ngg(pipeline)) {
pipeline->gs_copy_shader = radv_create_gs_copy_shader(
device, nir[MESA_SHADER_GEOMETRY],
&gs_copy_binary,
keys[MESA_SHADER_GEOMETRY].has_multiview_view_index);
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111259] Presentation regression while rendering on X11 surface
https://bugs.freedesktop.org/show_bug.cgi?id=111259 --- Comment #5 from jaelp...@outlook.com --- Okay, thanks a lot. I'll try fix this later and see how it goes. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111259] Presentation regression while rendering on X11 surface
https://bugs.freedesktop.org/show_bug.cgi?id=111259 --- Comment #4 from Lionel Landwerlin --- I would recommend using a list in which you push indices returned by acquireNextImage() and when you need a new currentFrame, you pull from that list. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111259] Presentation regression while rendering on X11 surface
https://bugs.freedesktop.org/show_bug.cgi?id=111259 --- Comment #3 from Lionel Landwerlin --- (In reply to jaelpark from comment #2) > I was looking if there would be some minimal test case to demonstrate this, > but couldn't find one so far. One case where this gets reproduced is the > desktop compositor I've been working on. The build instructions and setup is > here: > https://jaelpark.github.io/chamferwm-docs/setup.html#building-with-meson > > After building, change the terminal emulator in line 504 of config/config.py > to your preference, and once running, launch the terminal with Alt+Enter. > Typing something will reveal how the frames come disordered and lagging. > Using a recent version of mesa before this particular commit will result in > expected behavior. I think I can spot the bug in your compositor : compositor.cpp:984 : currentFrame = (currentFrame+1)%swapChainImageCount; That's incorrect, the image indice returned by acquireNextImage() might not increment. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111259] Presentation regression while rendering on X11 surface
https://bugs.freedesktop.org/show_bug.cgi?id=111259 --- Comment #2 from jaelp...@outlook.com --- I was looking if there would be some minimal test case to demonstrate this, but couldn't find one so far. One case where this gets reproduced is the desktop compositor I've been working on. The build instructions and setup is here: https://jaelpark.github.io/chamferwm-docs/setup.html#building-with-meson After building, change the terminal emulator in line 504 of config/config.py to your preference, and once running, launch the terminal with Alt+Enter. Typing something will reveal how the frames come disordered and lagging. Using a recent version of mesa before this particular commit will result in expected behavior. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111259] Presentation regression while rendering on X11 surface
https://bugs.freedesktop.org/show_bug.cgi?id=111259 Lionel Landwerlin changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Lionel Landwerlin --- What application are you using to reproduce this problem? -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111259] Presentation regression while rendering on X11 surface
https://bugs.freedesktop.org/show_bug.cgi?id=111259 Bug ID: 111259 Summary: Presentation regression while rendering on X11 surface Product: Mesa Version: git Hardware: All OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/Common Assignee: mesa-dev@lists.freedesktop.org Reporter: jaelp...@outlook.com CC: airl...@freedesktop.org, chadvers...@chromium.org, ja...@jlekstrand.net While rendering to an x11 surface, the frames appear in wrong order, making the graphics look corrupted. This probably depends on how the swap chain was created, since vkcube for example works fine. I bisected the problem to this commit: 6f880f128f9862a047a5ba543c2843e14517b1e6 vulkan/wsi: update swapchain status on vkQueuePresent Reproduced on: OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2) -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109791] The mesa release config doesn't define NDEBUG when building using meson 0.45.0
https://bugs.freedesktop.org/show_bug.cgi?id=109791 andrii simiklit changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from andrii simiklit --- This issue was fixed by commit: f7b6a8d12fdc446e325129033e5f61e3bbafb0b2 "meson: bump required version to 0.46" -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
