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.")

[Mesa-dev] [Bug 106126] eglMakeCurrent does not always ensure dri_drawable->update_drawable_info has been called for a new EGLSurface if another has been created and destroyed first

https://bugs.freedesktop.org/show_bug.cgi?id=106126 Bug ID: 106126 Summary: eglMakeCurrent does not always ensure dri_drawable->update_drawable_info has been called for a new EGLSurface if another has been created and

[Mesa-dev] [Bug 106126] eglMakeCurrent does not always ensure dri_drawable->update_drawable_info has been called for a new EGLSurface if another has been created and destroyed first

https://bugs.freedesktop.org/show_bug.cgi?id=106126 Johan Helsing changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop.

[Mesa-dev] [AppVeyor] mesa 18.0 #7476 failed

Build mesa 7476 failed Commit 8bd719e3fa by Juan A. Suarez Romero on 4/18/2018 2:44 PM: docs: add release notes for 18.0.1\n\nSigned-off-by: Juan A. Suarez Romero Configure your notification preferences

[Mesa-dev] [AppVeyor] mesa mesa-18.0.1 #7477 completed

Build mesa 7477 completed Commit 8bd719e3fa by Juan A. Suarez Romero on 4/18/2018 2:44 PM: docs: add release notes for 18.0.1\n\nSigned-off-by: Juan A. Suarez Romero Configure your notification preferences

[Mesa-dev] [ANNOUNCE] mesa 18.0.1

Mesa 18.0.1 is now available. In this release we have: On the build system to highlight Meson is get improved thorugh several patches that fix issues around it. On the drivers part, RADV get several fixes: one for multisample regressions on Vega, another around GFX9 buffer views, and a couple

Re: [Mesa-dev] [PATCH 2/2] i965/blorp: Do the gen11 BTI flush

On Tue, Apr 17, 2018 at 05:53:49PM -0700, Jason Ekstrand wrote: > On Tue, Apr 17, 2018 at 4:19 PM, Anuj Phogat wrote: > > > For the series: > > Reviewed-by: Anuj Phogat > > > > This might explain piglit GPU hangs or failures. I'll do a piglit run

Re: [Mesa-dev] [PATCH 1/2] mesa: GL_EXT_texture_norm16 extension plumbing

On 17.04.2018 21:11, Ilia Mirkin wrote: On Tue, Apr 17, 2018 at 1:52 PM, Ian Romanick wrote: On 04/17/2018 05:19 AM, Ilia Mirkin wrote: On Mon, Apr 16, 2018 at 11:22 PM, Tapani Pälli wrote: On 17.04.2018 02:42, Ilia Mirkin wrote:

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

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 changed, 2 insertions(+), 2 deletions(-) diff --git

[Mesa-dev] [PATCH 2/2] radv: reset the image's predicate after a color decompression pass

After performing a fast-clear eliminate, a FMASK decompress, or a DCC decompress, we can reset the predicate to FALSE. With that, the GPU should be able to skip unnecessary color decompression passes. Signed-off-by: Samuel Pitoiset ---

Re: [Mesa-dev] [PATCH 0/9] RadeonSI LLVM crash workaround for Ubuntu 18.04

On Mon, 2018-04-16 at 20:52 -0400, Marek Olšák wrote: > Hi, > > This cleanup is motivated by a Mesa/LLVM crash on Ubuntu 18.04. > It happens inside gallivm_dispose_target_library_info and only > LLVM 5.0 and 6.0 seem to be affected. Should this series (or part of this) be nominated for stable?

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

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, maybe the CTS tests were wrong? Fixes:

[Mesa-dev] [RFC] egl/android: Add DRM node probing and filtering

This patch both adds support for probing & filtering DRM nodes and switches away from using the GRALLOC_MODULE_PERFORM_GET_DRM_FD gralloc call. Currently the filtering is based just on the driver name, and the desired name is supplied using the "drm.gpu.vendor_name" Android property. The

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 ---

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 1/2] radv: enable/disable prediction for the DCC decompression pass

On 04/18/2018 06:43 PM, Nicolai Hähnle wrote: s/prediction/predication/ ? :) Yep :) 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

[Mesa-dev] [PATCH] radv: dump the SHA1 of SPIRV in the hang report

Might be useful for debugging purposes, especially when we want to replace a shader on the fly. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_debug.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/amd/vulkan/radv_debug.c

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

Re: [Mesa-dev] [PATCH 2/2] radv: make sure to sync after resolving using the compute path

Reviewed-by: Bas Nieuwenhuizen On Tue, Apr 17, 2018 at 3:08 PM, Samuel Pitoiset wrote: > This fixes some random CTS failures: > > dEQP-VK.renderpass.multisample.*. > > Performing a fast-clear eliminate is still useless, but it > seems that we

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

IIRC if level N is unaligned then num_dcc_levels <= N+1, so level N+1 is not DCC compressed? On Wed, Apr 18, 2018 at 12:53 PM, Marek Olšák wrote: > On Wed, Apr 18, 2018 at 5:54 AM, Nicolai Hähnle wrote: >> >> On 17.04.2018 02:41, Marek Olšák wrote: >>> >>>

[Mesa-dev] [Bug 105928] [TRACKER] Mesa 18.1 feature tracker

https://bugs.freedesktop.org/show_bug.cgi?id=105928 Bug 105928 depends on bug 106114, which changed state. Bug 106114 Summary: Blocker to support VK_EXT_descriptor_indexing https://bugs.freedesktop.org/show_bug.cgi?id=106114 What|Removed |Added

[Mesa-dev] [Bug 106114] Blocker to support VK_EXT_descriptor_indexing

https://bugs.freedesktop.org/show_bug.cgi?id=106114 Bas Nieuwenhuizen changed: What|Removed |Added Status|NEW |RESOLVED

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

On Wed, Apr 18, 2018 at 4:44 PM, Bas Nieuwenhuizen wrote: > IIRC if level N is unaligned then num_dcc_levels <= N+1, so level N+1 > is not DCC compressed? > There is a difference between being aligned (contiguous really) and being compressible. Small mip levels might

[Mesa-dev] Reminder, 18.1 branching on Friday

I just wanted to remind everyone that the plan is to branch for 18.1 on Friday. I plan to take the head of master around 10am PDT, and assuming that all of our CI testing is good that will become the 18.1 branch point with RC1 to follow after that. Oh, and I'll be managing the 18.1 release, so

Re: [Mesa-dev] [PATCH 1/1] i965: Make sure the shadow buffers have enough space

On Friday, April 13, 2018 2:37:05 PM PDT James Xiong wrote: > On Fri, 13 Apr 2018 14:33:09 -0700 > Kenneth Graunke wrote: > > > On Friday, April 13, 2018 2:08:40 PM PDT James Xiong wrote: > > > On Fri, 13 Apr 2018 13:51:02 -0700 > > > Kenneth Graunke

[Mesa-dev] [Bug 105320] Storage texel buffer access produces wrong results (RX Vega)

https://bugs.freedesktop.org/show_bug.cgi?id=105320 Bas Nieuwenhuizen changed: What|Removed |Added Status|REOPENED|RESOLVED

[Mesa-dev] [PATCH 2/3] i965: Let batchbuffers be placed anywhere in the 48-bit address space.

We were trying to mark batch buffers with EXEC_OBJECT_CAPTURE, and accidentally stomped EXEC_OBJECT_SUPPORTS_48B_ADDRESS in the process. There's no reason to restrict batch buffers to the lower 4GB. --- src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [Mesa-dev] [PATCH 1/3] intel: fix check for 48b ppgtt support

Quoting Kenneth Graunke (2018-04-18 22:22:54) > From: Scott D Phillips > > The previous logic of the supports_48b_addresses wasn't actually > checking if i915.ko was running with full_48bit_ppgtt. The ENOENT > it was checking for was actually coming from the invalid

Re: [Mesa-dev] [PATCH 2/3] i965: Let batchbuffers be placed anywhere in the 48-bit address space.

Reviewed-by: Lionel Landwerlin On 18/04/18 14:22, Kenneth Graunke wrote: We were trying to mark batch buffers with EXEC_OBJECT_CAPTURE, and accidentally stomped EXEC_OBJECT_SUPPORTS_48B_ADDRESS in the process. There's no reason to restrict batch buffers to the

Re: [Mesa-dev] [PATCH 3/3] i965: Don't stomp initial kflags for program cache.

Reviewed-by: Lionel Landwerlin On 18/04/18 14:22, Kenneth Graunke wrote: We want to flag EXEC_OBJECT_CAPTURE, but we ought to preserve any existing kflags. Today, there are none (as the program cache doesn't support 48-bit addressing), but once we start using

[Mesa-dev] [PATCH] i965: Allocate shadow batches to explicitly be the BO size.

This unfortunately makes it malloc/realloc on every new batch, rather than once at startup. But it ensures that the shadow buffer's size will absolutely match the BO size. Otherwise, as we tune BATCH_SZ/STATE_SZ or bufmgr cache bucket sizes, we may get a BO size that's rounded up, and fail to

[Mesa-dev] [PATCH] i965/fs: retype offset_reg to UD at load_ssbo

All operations with offset_reg at do_vector_read are done with UD type. So copy propagation was not working through the generated MOVs: mov(8) vgrf9:UD, vgrf7:D This change allows removing the MOV generated for reading the first components for 16-bit and 64-bit ssbo reads with non-constant

[Mesa-dev] [PATCH 1/3] intel: fix check for 48b ppgtt support

From: Scott D Phillips The previous logic of the supports_48b_addresses wasn't actually checking if i915.ko was running with full_48bit_ppgtt. The ENOENT it was checking for was actually coming from the invalid context id provided in the test execbuffer. There is no

[Mesa-dev] [PATCH 3/3] i965: Don't stomp initial kflags for program cache.

We want to flag EXEC_OBJECT_CAPTURE, but we ought to preserve any existing kflags. Today, there are none (as the program cache doesn't support 48-bit addressing), but once we start using softpin, we'll need to preserve EXEC_OBJECT_PINNED. --- src/mesa/drivers/dri/i965/brw_program_cache.c | 4

Re: [Mesa-dev] [PATCH] radv: fix multisample image copies

On 18 April 2018 at 00:31, Matthew Nicholls wrote: > Previously before fb077b0728, the LOD parameter was being used in place of the > sample index, which would only copy the first sample to all samples in the > destination image. After that multisample image copies

[Mesa-dev] [Bug 105942] Graphical artefacts after update to mesa 18.0.0-2

https://bugs.freedesktop.org/show_bug.cgi?id=105942 --- Comment #8 from kaspar.t...@gmail.com --- Can confirm that since mesa 18.0.1-1 the issue has been fixed for me. Thank you for the work! -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for

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

On Wed, Apr 18, 2018 at 5:54 AM, Nicolai Hähnle wrote: > 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

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

Well, it fixes some piglits, but I don't remember which ones. Marek On Wed, Apr 18, 2018 at 5:31 AM, Nicolai Hähnle wrote: > On 16.04.2018 23:02, Marek Olšák wrote: > >> From: Marek Olšák >> >> Cc: 18.0 >> > > Would

Re: [Mesa-dev] [PATCH 0/9] RadeonSI LLVM crash workaround for Ubuntu 18.04

On Wed, Apr 18, 2018 at 8:00 AM, Juan A. Suarez Romero wrote: > On Mon, 2018-04-16 at 20:52 -0400, Marek Olšák wrote: > > Hi, > > > > This cleanup is motivated by a Mesa/LLVM crash on Ubuntu 18.04. > > It happens inside gallivm_dispose_target_library_info and only > > LLVM

Re: [Mesa-dev] [PATCH] glsl_to_nir: fix ir_binop_vector_extract handling

Marek, thanks for suggestion. But I've tested your patch and, unfortunately, it doesn't fix the https://bugs.freedesktop.org/show_bug.cgi?id=105438 Regards, Andriy. On Tue, Apr 17, 2018 at 8:33 PM, Marek Olšák wrote: >

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

On Tue, 2018-04-17 at 05:56 +0200, Bas Nieuwenhuizen wrote: > On Mon, Apr 16, 2018 at 1:17 PM, Juan A. Suarez Romero > wrote: > > On Mon, 2018-04-16 at 00:09 +0200, Bas Nieuwenhuizen wrote: > > > No clue how I missed those ... > > > > > > Fixes: 4503ff760c "ac/nir: Add

[Mesa-dev] [ANNOUNCE] mesa 17.3.9

Mesa 17.3.9 is now available. In this release we have: Patches that clarify and fix issues regarding GL/GLES version overriding through environment variables. AC get patches to use if/loop builder helpers, which increases the readability for LLVM IR dumps. RadeonSI is beneficiated from this.

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

On 17.04.2018 02:41, Marek Olšák wrote: From: Marek Olšák Reduce swizzle constraints to the ALPHA_IS_ON_MSB constraint and the clear value of 1. This significantly changes the DCC fast clear code, and fixes fast clear for RGB formats without alpha. ---

[Mesa-dev] [Bug 105613] Compute shader locks up within nested "for" loop

https://bugs.freedesktop.org/show_bug.cgi?id=105613 --- Comment #6 from Samuel Pitoiset --- I can reproduce the hang with mesa-git (893e19efb74) and LLVM-git (f31b39d494d). -- You are receiving this mail because: You are the QA Contact for the bug. You are the

Re: [Mesa-dev] [PATCH] gm107/ir: add emission for BAR

[ Quoted text copied from https://lists.freedesktop.org/archives/mesa-dev/2016-March/108926.html ] Hi, I've been playing around with bar.sync in ptx, JIT-compiling it to GM107 (my quadro m1200 card), and disassembling with cuobjdump -sass. I looked at nv50_ir_emit_gm107.cpp to understand

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. ---

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

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 ---

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

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

Re: [Mesa-dev] [PATCH v2 3/5] i965: perf: read slice/unslice frequencies from OA reports

On Tuesday, April 17, 2018 4:45:13 PM PDT Lionel Landwerlin wrote: > On 16/04/18 23:16, Kenneth Graunke wrote: > > On Tuesday, April 3, 2018 7:48:11 AM PDT Lionel Landwerlin wrote: > >> Signed-off-by: Lionel Landwerlin > >> --- > >>

Re: [Mesa-dev] [PATCH v2 3/5] i965: perf: read slice/unslice frequencies from OA reports

On 17/04/18 23:03, Kenneth Graunke wrote: On Tuesday, April 17, 2018 4:45:13 PM PDT Lionel Landwerlin wrote: On 16/04/18 23:16, Kenneth Graunke wrote: On Tuesday, April 3, 2018 7:48:11 AM PDT Lionel Landwerlin wrote: Signed-off-by: Lionel Landwerlin ---

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

Re: [Mesa-dev] Nouveau driver problem when using EGL_LINUX_DMA_BUF_EXT

On 17.04.2018 15:44, Pekka Paalanen wrote: On Mon, 9 Apr 2018 09:56:43 -0400 Ilia Mirkin wrote: On Mon, Apr 9, 2018 at 6:57 AM, Volker Vogelhuber wrote: I would have guessed, that the use case would be quite common, as having a Live

Re: [Mesa-dev] [PATCH] radv: dump the SHA1 of SPIRV in the hang report

Reviewed-by: Bas Nieuwenhuizen On Wed, Apr 18, 2018 at 6:53 PM, Samuel Pitoiset wrote: > Might be useful for debugging purposes, especially when we > want to replace a shader on the fly. > > Signed-off-by: Samuel Pitoiset

[Mesa-dev] [PATCH] radv: Add bound checking workaround for dynamic buffers.

I have seen a few applications and games do the dynamic buffer bounds incorrectly, this make it easier to work around, e.g. for debugging. --- src/amd/vulkan/radv_cmd_buffer.c | 4 +++- src/amd/vulkan/radv_debug.h | 1 + src/amd/vulkan/radv_device.c | 1 + 3 files changed, 5

[Mesa-dev] [PATCH] radv: Add Vega M support.

--- src/amd/vulkan/radv_device.c | 5 - src/amd/vulkan/radv_pipeline.c | 3 ++- src/amd/vulkan/radv_shader.c | 1 + src/amd/vulkan/si_cmd_buffer.c | 4 4 files changed, 11 insertions(+), 2 deletions(-) diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c index

Re: [Mesa-dev] [PATCH 1/5] radv: implement fast color clear for DCC with MSAA

Reviewed-by: Bas Nieuwenhuizen for the series. On Tue, Apr 17, 2018 at 4:05 PM, Samuel Pitoiset wrote: > When DCC is enabled with MSAA textures, CMASK should be > cleared to 0x. > > Signed-off-by: Samuel Pitoiset

[Mesa-dev] [PATCH v2] mesa: GL_EXT_texture_norm16 extension plumbing

Patch enables use of short and unsigned short data for texture uploads, rendering and reading of framebuffers within the restrictions specified in GL_EXT_texture_norm16 spec. Patch also enables those 16bit format layout qualifiers listed in GL_NV_image_formats that depend on EXT_texture_norm16.

Re: [Mesa-dev] [PATCH v2] mesa: GL_EXT_texture_norm16 extension plumbing

On Wed, Apr 18, 2018 at 7:49 PM, Tapani Pälli wrote: > Patch enables use of short and unsigned short data for texture uploads, > rendering and reading of framebuffers within the restrictions specified > in GL_EXT_texture_norm16 spec. > > Patch also enables those 16bit

[Mesa-dev] [Bug 105464] Reading per-patch outputs in Tessellation Control Shader returns undefined values

https://bugs.freedesktop.org/show_bug.cgi?id=105464 --- Comment #10 from FarhanaAleen --- Hi Samuel, We are observing performance regression on SGEMM on fiji with https://reviews.llvm.org/D44974. Shortening the vector length from 128 to 64 is causing the regression. I

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

On Wed, Apr 18, 2018 at 2:11 PM, Marek Olšák wrote: > On Wed, Apr 18, 2018 at 4:44 PM, Bas Nieuwenhuizen > wrote: >> >> IIRC if level N is unaligned then num_dcc_levels <= N+1, so level N+1 >> is not DCC compressed? > > > There is a difference between

[Mesa-dev] [Bug 106131] meson/ninja build missing file gtest.h

https://bugs.freedesktop.org/show_bug.cgi?id=106131 Bug ID: 106131 Summary: meson/ninja build missing file gtest.h Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity:

[Mesa-dev] [Bug 106131] meson/ninja build missing file gtest.h

https://bugs.freedesktop.org/show_bug.cgi?id=106131 --- Comment #1 from Dylan Baker --- I actually ran into this today, I have a patch I'll probably out of a larger series. Side quest: please send me a tester by on the other patch and I'll push it, I just can't get

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

On Wed, Apr 18, 2018, 8:01 PM Bas Nieuwenhuizen wrote: > On Wed, Apr 18, 2018 at 2:11 PM, Marek Olšák wrote: > > On Wed, Apr 18, 2018 at 4:44 PM, Bas Nieuwenhuizen < > b...@basnieuwenhuizen.nl> > > wrote: > >> > >> IIRC if level N is unaligned then

[Mesa-dev] [PATCH 2/2] i965/fs: Register allocator shoudn't use grf127 for sends dest (v2)

Since Gen8+ Intel PRM states that "r127 must not be used for return address when there is a src and dest overlap in send instruction." This patch implements this restriction creating new grf127_send_hack_node at the register allocator. This node has a fixed assignation to grf127. For vgrf that

[Mesa-dev] [Bug 100629] No mans sky renders white screen under wine in linux

https://bugs.freedesktop.org/show_bug.cgi?id=100629 --- Comment #13 from Timothy Arceri --- (In reply to freedesktop from comment #12) > (In reply to Timothy Arceri from comment #11) > > (In reply to freedesktop from comment #8) > > > > Do you think you can get and

[Mesa-dev] [Bug 100629] No mans sky renders white screen under wine in linux

https://bugs.freedesktop.org/show_bug.cgi?id=100629 --- Comment #12 from freedesk...@bremsspur.org --- (In reply to Timothy Arceri from comment #11) > (In reply to freedesktop from comment #8) > > Do you think you can get and apitrace [1] of this issue and upload share it > from google drive or