Re: [Mesa-dev] [PATCH 23/25] radeonsi: factor si_query_buffer logic out of si_query_hw

On 2/2/19 2:56 pm, Marek Olšák wrote: Feel free to revert the commit if it's not difficult. Unfortunately it no longer seems to be a simple revert. Marek On Thu, Jan 31, 2019, 11:25 PM Timothy Arceri wrote: On 26/1/19 11:56 am, Marek Olšák wrote: >

Re: [Mesa-dev] [PATCH 23/25] radeonsi: factor si_query_buffer logic out of si_query_hw

Feel free to revert the commit if it's not difficult. Marek On Thu, Jan 31, 2019, 11:25 PM Timothy Arceri On 26/1/19 11:56 am, Marek Olšák wrote: > > Timothy, can you please test the attached fix? > > I'm having trouble compiling 32bit mesa on my machine at the moment so > haven't been able to

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 4/6] glsl/linker: don't fail non static used inputs without matching outputs

On 2/2/19 10:28 am, Timothy Arceri wrote: On 2/2/19 5:05 am, Andres Gomez wrote: If there is no Static Use of an input variable, the linker shouldn't fail whenever there is no defined matching output variable in the previous stage.  From page 47 (page 51 of the PDF) of the GLSL 4.60 v.5

Re: [Mesa-dev] [PATCH 2/6] glsl: correctly validate component layout qualifier for dvec{3, 4}

On 2/2/19 5:05 am, Andres Gomez wrote: From page 62 (page 68 of the PDF) of the GLSL 4.50 v.7 spec: " A dvec3 or dvec4 can only be declared without specifying a component." Therefore, using the "component" qualifier with a dvec3 or dvec4 should result in a compiling error. Fixes:

Re: [Mesa-dev] [PATCH 4/6] glsl/linker: don't fail non static used inputs without matching outputs

On Fri, Feb 1, 2019 at 1:08 PM Andres Gomez wrote: > > If there is no Static Use of an input variable, the linker shouldn't > fail whenever there is no defined matching output variable in the > previous stage. > > From page 47 (page 51 of the PDF) of the GLSL 4.60 v.5 spec: > > " Only the input

Re: [Mesa-dev] [PATCH 3/6] glsl/linker: always validate explicit location among inputs

Nice catch! Reviewed-by: Timothy Arceri On 2/2/19 5:05 am, Andres Gomez wrote: Outputs are always validated when having explicit locations and we were trusting its outcome to catch similar problems with the inputs since, in case of having undefined outputs for existing inputs, we would be

Re: [Mesa-dev] [PATCH 4/6] glsl/linker: don't fail non static used inputs without matching outputs

On 2/2/19 5:05 am, Andres Gomez wrote: If there is no Static Use of an input variable, the linker shouldn't fail whenever there is no defined matching output variable in the previous stage. From page 47 (page 51 of the PDF) of the GLSL 4.60 v.5 spec: " Only the input variables that are

Re: [Mesa-dev] [PATCH 5/6] glsl/linker: simplify xfb_offset vs xfb_stride overflow check

On 2/2/19 5:05 am, Andres Gomez wrote: Current implementation uses a complicated calculation which relies in an implicit conversion to check the integral part of 2 division results. However, the calculation actually checks that the xfb_offset is smaller or a multiplier of the xfb_stride. For

Re: [Mesa-dev] [PATCH v2 07/32] intel/isl: Rename ISL_TILING_Yf/s to ISL_TILING_GEN9_Yf/s

TBH, I don't for sure remember why this was needed. I think it was because gen10 has a slightly different miptail layout. That said, miptails are still broken on gen10 so maybe there's really no point? I don't remember for sure. --Jason On Fri, Oct 12, 2018 at 1:47 PM Jason Ekstrand wrote:

Re: [Mesa-dev] [PATCH v2 08/32] intel/isl: Add gen10 variants of Yf and Ys tiling

On Fri, Oct 12, 2018 at 01:46:38PM -0500, Jason Ekstrand wrote: > --- > src/intel/isl/isl.c | 9 +++-- > src/intel/isl/isl.h | 12 ++-- > src/intel/isl/isl_drm.c | 2 ++ > src/intel/isl/isl_gen7.c | 8 +++- >

Re: [Mesa-dev] [PATCH v2 07/32] intel/isl: Rename ISL_TILING_Yf/s to ISL_TILING_GEN9_Yf/s

On Wed, Jan 23, 2019 at 02:25:14PM -0800, Nanley Chery wrote: > On Fri, Oct 12, 2018 at 01:46:37PM -0500, Jason Ekstrand wrote: > > The Yf and Ys tilings change a bit between gen9 and gen10 so we have to > > be able to distinguish between them. > > --- > > src/intel/isl/isl.c | 12

Re: [Mesa-dev] [PATCH 19/19] radv: don't flush src stages when dstStageMask == BOTTOM_OF_PIPE

Reviewed-by: Bas Nieuwenhuizen for the series except 09 where I had comments. On Tue, Jan 29, 2019 at 10:17 PM Samuel Pitoiset wrote: > > Original patch by Fredrik Höglund. > > Signed-off-by: Samuel Pitoiset > --- > src/amd/vulkan/radv_cmd_buffer.c | 16 +++- >

Re: [Mesa-dev] [PATCH] anv/cmd_buffer: check for NULL framebuffer

On Fri, Feb 1, 2019 at 10:14 AM Juan A. Suarez Romero wrote: > This can happen when we record a VkCmdDraw in a secondary buffer that > was created inheriting from the primary buffer, but with the framebuffer > set to NULL in the VkCommandBufferInheritanceInfo. > > CC: Jason Ekstrand > --- >

[Mesa-dev] [Bug 109107] gallium/st/va: change va max_profiles when using Radeon VCN Hardware

https://bugs.freedesktop.org/show_bug.cgi?id=109107 --- Comment #2 from Michael Eagle --- Hi, I am not sure if this is related with regards to what is causing hardware accelerated decoding on my Raven laptop not to work. Fedora repos: che-mesa, rpmfusion, fedora-rawhide-kernel-nodebug Mesa-git

Re: [Mesa-dev] [PATCH] meson: drop the xcb-xrandr version requirement

If there is no feedback soon, I'll push this. Marek On Wed, Jan 30, 2019 at 12:44 PM Erik Faye-Lund < erik.faye-l...@collabora.com> wrote: > On Wed, 2019-01-30 at 12:32 -0500, Marek Olšák wrote: > > ping > > > > Probably worth including Keith, who added this line... > > But yeah, I tend to

Re: [Mesa-dev] [PATCH 1/6] gallium\auxiliary\vl: Move dirty define to header file

Thanks for point it out! James On 2019-02-01 2:33 p.m., Matt Turner wrote: > My OCD is really bothered by the backslashes in the commit title. Can > we use forward slashes like all the other commits? ___ mesa-dev mailing list

Re: [Mesa-dev] [PATCH 1/6] gallium\auxiliary\vl: Move dirty define to header file

My OCD is really bothered by the backslashes in the commit title. Can we use forward slashes like all the other commits? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel/compiler: update validator to account for half-float exec type promotion

Iago Toral writes: > On Fri, 2019-01-25 at 12:54 -0800, Francisco Jerez wrote: >> Iago Toral writes: >> >> > On Thu, 2019-01-24 at 11:45 -0800, Francisco Jerez wrote: >> > > Iago Toral writes: >> > > >> > > > On Wed, 2019-01-23 at 06:03 -0800, Francisco Jerez wrote: >> > > > > Iago Toral

Re: [Mesa-dev] [PATCH 6/6] glsl/linker: check for xfb_offset aliasing

This causes a O(N^2) behavior in the number of feedback'd variables, which I suspect is undesirable. Elsewhere we use arrays and/or maps -- since the size of the xfb offset has a max value, an array-based solution may work well. On Fri, Feb 1, 2019 at 1:08 PM Andres Gomez wrote: > > From page 76

Re: [Mesa-dev] [PATCH 5/6] glsl/linker: simplify xfb_offset vs xfb_stride overflow check

On Fri, Feb 1, 2019 at 1:08 PM Andres Gomez wrote: > > Current implementation uses a complicated calculation which relies in > an implicit conversion to check the integral part of 2 division > results. > > However, the calculation actually checks that the xfb_offset is > smaller or a multiplier

[Mesa-dev] [PATCH v4 1/6] glsl/linker: location aliasing requires types to have the same width

From: Iago Toral Quiroga Regarding location aliasing requirements, the OpenGL spec says: "Further, when location aliasing, the aliases sharing the location must have the same underlying numerical type (floating-point or integer)." Khronos has further clarified that this also requires

[Mesa-dev] [PATCH 4/6] glsl/linker: don't fail non static used inputs without matching outputs

If there is no Static Use of an input variable, the linker shouldn't fail whenever there is no defined matching output variable in the previous stage. From page 47 (page 51 of the PDF) of the GLSL 4.60 v.5 spec: " Only the input variables that are statically read need to be written by the

[Mesa-dev] [PATCH 0/6] glsl/linker: several arb_enhanced_layouts related fixes

This series addresses the problems tested in the piglit series sent for review at: https://patchwork.freedesktop.org/series/56099/ Andres Gomez (5): glsl: correctly validate component layout qualifier for dvec{3,4} glsl/linker: always validate explicit location among inputs glsl/linker:

[Mesa-dev] [PATCH 2/6] glsl: correctly validate component layout qualifier for dvec{3, 4}

From page 62 (page 68 of the PDF) of the GLSL 4.50 v.7 spec: " A dvec3 or dvec4 can only be declared without specifying a component." Therefore, using the "component" qualifier with a dvec3 or dvec4 should result in a compiling error. Fixes: 94438578d21 ("glsl: validate and store

[Mesa-dev] [PATCH 6/6] glsl/linker: check for xfb_offset aliasing

From page 76 (page 80 of the PDF) of the GLSL 4.60 v.5 spec: " No aliasing in output buffers is allowed: It is a compile-time or link-time error to specify variables with overlapping transform feedback offsets." Currently, this is expected to fail, but it succeeds: " ...

[Mesa-dev] [PATCH 5/6] glsl/linker: simplify xfb_offset vs xfb_stride overflow check

Current implementation uses a complicated calculation which relies in an implicit conversion to check the integral part of 2 division results. However, the calculation actually checks that the xfb_offset is smaller or a multiplier of the xfb_stride. For example, while this is expected to fail, it

[Mesa-dev] [PATCH 3/6] glsl/linker: always validate explicit location among inputs

Outputs are always validated when having explicit locations and we were trusting its outcome to catch similar problems with the inputs since, in case of having undefined outputs for existing inputs, we would be already reporting a linker error. However, consider this case: " Shader stage n:

Re: [Mesa-dev] [PATCH] intel/fs: Fix memory corruption when compiling a CS

On Saturday, January 26, 2019 7:47:42 AM PST Oscar Blumberg wrote: > Missing check for shader stage in the fs_visitor would corrupt the > cs_prog_data.push information and trigger crashes / corruption later > when uploading the CS state. > --- > src/intel/compiler/brw_fs_nir.cpp | 5 +++-- > 1

Re: [Mesa-dev] [PATCH 6/6] gallium\auxiliary\vl: Add video compute shader render

On 2019-02-01 11:38 a.m., Christian König wrote: > Am 01.02.19 um 17:28 schrieb Zhu, James: >> Add video compute shader render. export CS_COMPOSITOR_RENDER=true >> to enable video compute shader render. > > Ok that actually makes more sense, but I would either put everything > into one file or

Re: [Mesa-dev] [PATCH 1/6] gallium\auxiliary\vl: Move dirty define to header file

On 2019-02-01 11:34 a.m., Christian König wrote: > Am 01.02.19 um 17:28 schrieb Zhu, James: >> Move dirty define to header file to share with compute shader. >> >> Signed-off-by: James Zhu >> --- >>   src/gallium/auxiliary/vl/vl_compositor.c | 3 --- >>   src/gallium/auxiliary/vl/vl_compositor.h

Re: [Mesa-dev] [PATCH 6/6] gallium\auxiliary\vl: Add video compute shader render

Am 01.02.19 um 17:28 schrieb Zhu, James: Add video compute shader render. export CS_COMPOSITOR_RENDER=true to enable video compute shader render. Ok that actually makes more sense, but I would either put everything into one file or cleanly separate between gfx and compute implementation.

Re: [Mesa-dev] [PATCH 3/6] gallium\auxiliary\vl: Add compute shader to support video compositor render

Am 01.02.19 um 17:28 schrieb Zhu, James: Add compute shader to support video compositor render. I don't think that this is actually a good approach. It adds a second implementation of the compositor instead of adapting the original one to use compute shaders when available. Christian.

Re: [Mesa-dev] [PATCH 1/6] gallium\auxiliary\vl: Move dirty define to header file

Am 01.02.19 um 17:28 schrieb Zhu, James: Move dirty define to header file to share with compute shader. Signed-off-by: James Zhu --- src/gallium/auxiliary/vl/vl_compositor.c | 3 --- src/gallium/auxiliary/vl/vl_compositor.h | 2 ++ 2 files changed, 2 insertions(+), 3 deletions(-) diff

[Mesa-dev] [PATCH 1/6] gallium\auxiliary\vl: Move dirty define to header file

Move dirty define to header file to share with compute shader. Signed-off-by: James Zhu --- src/gallium/auxiliary/vl/vl_compositor.c | 3 --- src/gallium/auxiliary/vl/vl_compositor.h | 2 ++ 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/src/gallium/auxiliary/vl/vl_compositor.c

[Mesa-dev] [PATCH 0/6] Add compute shader support on video compositor render

Initially add compute shader support on video compositor render process. These patches include only normal video buffer, weave and video sub-pictures compute shader for video compositor render. export CS_COMPOSITOR_RENDER=true to enable compuet shader video compositor render. James Zhu (6):

[Mesa-dev] [PATCH 2/6] gallium\auxiliary\vl: Increase csc_matrix size

Increase csc_matrix size to store more constants for compute shader. Signed-off-by: James Zhu --- src/gallium/auxiliary/vl/vl_compositor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/vl/vl_compositor.c b/src/gallium/auxiliary/vl/vl_compositor.c

[Mesa-dev] [PATCH 4/6] gallium\auxiliary\vl: Add compute shader initilization, assign and cleanup

Add compute shader initilization, assign and cleanup in vl_compositor API. Signed-off-by: James Zhu --- src/gallium/auxiliary/vl/vl_compositor.c | 30 +- src/gallium/auxiliary/vl/vl_compositor.h | 4 2 files changed, 33 insertions(+), 1 deletion(-) diff --git

[Mesa-dev] [PATCH 3/6] gallium\auxiliary\vl: Add compute shader to support video compositor render

Add compute shader to support video compositor render. Signed-off-by: James Zhu --- src/gallium/auxiliary/Makefile.sources | 2 + src/gallium/auxiliary/meson.build | 2 + src/gallium/auxiliary/vl/vl_compositor_cs.c | 414

[Mesa-dev] [PATCH 6/6] gallium\auxiliary\vl: Add video compute shader render

Add video compute shader render. export CS_COMPOSITOR_RENDER=true to enable video compute shader render. Signed-off-by: James Zhu --- src/gallium/auxiliary/vl/vl_compositor.c | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git

[Mesa-dev] [PATCH 5/6] gallium\auxiliary\vl: Add debug option CS_COMPOSITOR_RENDER

Add debug option CS_COMPOSITOR_RENDER to enable/diable video compositor compute shader render through system environment variable. Signed-off-by: James Zhu --- src/gallium/auxiliary/vl/vl_compositor.c | 5 + 1 file changed, 5 insertions(+) diff --git

[Mesa-dev] [PATCH] anv/cmd_buffer: check for NULL framebuffer

This can happen when we record a VkCmdDraw in a secondary buffer that was created inheriting from the primary buffer, but with the framebuffer set to NULL in the VkCommandBufferInheritanceInfo. CC: Jason Ekstrand --- src/intel/vulkan/gen7_cmd_buffer.c | 13 +++-- 1 file changed, 11

[Mesa-dev] [Bug 105371] r600_shader_from_tgsi - GPR limit exceeded - shader requires 360 registers

https://bugs.freedesktop.org/show_bug.cgi?id=105371 --- Comment #22 from amonpaike --- good and bad news... I've just tested the latest blender build with the latest mesa-devel (February 1 2019) driver.. the standard settings situation remained predominantly the same. the good news is that if

[Mesa-dev] [Bug 102565] u_debug_stack.c:114: undefined reference to `_Ux86_64_getcontext'

https://bugs.freedesktop.org/show_bug.cgi?id=102565 --- Comment #5 from Gert Wollny --- The change that triggered the problem was that I added a test program that linked against libgallium.a but not against libunwind.so and the fix was to add these link flags directly to the test program link

[Mesa-dev] [Bug 102565] u_debug_stack.c:114: undefined reference to `_Ux86_64_getcontext'

https://bugs.freedesktop.org/show_bug.cgi?id=102565 --- Comment #4 from taiyang...@126.com --- (In reply to Nicolai Hähnle from comment #3) > Patch is pushed to master, commit c4741bbb6fb98f78551f9e42ae570dcc924e0031. How to see the detail changes??? i come across the same problem. -- You are

[Mesa-dev] [Bug 109531] implicit declaration of function ‘ac_nir_get_max_workgroup_size

https://bugs.freedesktop.org/show_bug.cgi?id=109531 Mike Lothian changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #1 from

[Mesa-dev] [Bug 109531] implicit declaration of function ‘ac_nir_get_max_workgroup_size

https://bugs.freedesktop.org/show_bug.cgi?id=109531 Samuel Pitoiset changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [Mesa-dev] [PATCH] radv: take LDS into account for compute shader occupancy stats

Fixed. On 2/1/19 2:57 PM, Mike Lothian wrote: Hi I think you've left a few references to the old ac_nir_get_max_workgroup_size FAILED: src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_nir_to_llvm.c.o x86_64-pc-linux-gnu-gcc -m32 -Isrc/amd/vulkan/9198681@@vulkan_radeon@sha -Isrc/amd/vulkan

Re: [Mesa-dev] [PATCH] radv: take LDS into account for compute shader occupancy stats

Hi I think you've left a few references to the old ac_nir_get_max_workgroup_size FAILED: src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_nir_to_llvm.c.o x86_64-pc-linux-gnu-gcc -m32 -Isrc/amd/vulkan/9198681@@vulkan_radeon@sha -Isrc/amd/vulkan -I../mesa-/src/amd/vulkan -Isrc/../include

[Mesa-dev] [PATCH v2] egl/dri2: try to bind old context if bindContext failed

Before this change, if bindContext() failed then dri2_make_current() would rebind the old EGL context and surfaces and return EGL_BAD_MATCH. However, it wouldn't rebind the DRI context and surfaces, thus leaving it in an inconsistent and unrecoverable state. After this change, dri2_make_current()

[Mesa-dev] [Bug 109531] implicit declaration of function ‘ac_nir_get_max_workgroup_size

https://bugs.freedesktop.org/show_bug.cgi?id=109531 Bug ID: 109531 Summary: implicit declaration of function ‘ac_nir_get_max_workgroup_size Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux

Re: [Mesa-dev] [PATCH] intel/compiler: update validator to account for half-float exec type promotion

On Fri, 2019-02-01 at 12:34 +0100, Iago Toral wrote: > On Fri, 2019-01-25 at 12:54 -0800, Francisco Jerez wrote: > > Iago Toral writes: > > > > > On Thu, 2019-01-24 at 11:45 -0800, Francisco Jerez wrote: > > > > Iago Toral writes: > > > > > > > > > On Wed, 2019-01-23 at 06:03 -0800, Francisco

Re: [Mesa-dev] [PATCH] intel/compiler: update validator to account for half-float exec type promotion

On Fri, 2019-01-25 at 12:54 -0800, Francisco Jerez wrote: > Iago Toral writes: > > > On Thu, 2019-01-24 at 11:45 -0800, Francisco Jerez wrote: > > > Iago Toral writes: > > > > > > > On Wed, 2019-01-23 at 06:03 -0800, Francisco Jerez wrote: > > > > > Iago Toral Quiroga writes: > > > > > > > >

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

On 1/2/19 8:34 pm, Eero Tamminen wrote: 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

Re: [Mesa-dev] [PATCH] radv: take LDS into account for compute shader occupancy stats

Reviewed-by: Bas Nieuwenhuizen On Fri, Feb 1, 2019 at 12:07 PM Timothy Arceri wrote: > > Ported from d205faeb6c96. > --- > src/amd/vulkan/radv_nir_to_llvm.c | 6 +++--- > src/amd/vulkan/radv_private.h | 3 +++ > src/amd/vulkan/radv_shader.c | 10 -- > 3 files changed, 14

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

Hi Carsten, On 2019/01/31, Carsten Haitzler wrote: > On Wed, 30 Jan 2019 18:33:35 + Emil Velikov > said: > > You might want to hold off on this. My bugfix was actually patched out by > partly > removing some of it. The void ptr math should never have been there and wasn't > in the final

[Mesa-dev] [PATCH] radv: take LDS into account for compute shader occupancy stats

Ported from d205faeb6c96. --- src/amd/vulkan/radv_nir_to_llvm.c | 6 +++--- src/amd/vulkan/radv_private.h | 3 +++ src/amd/vulkan/radv_shader.c | 10 -- 3 files changed, 14 insertions(+), 5 deletions(-) diff --git a/src/amd/vulkan/radv_nir_to_llvm.c

[Mesa-dev] [ANNOUNCE] mesa 18.3.3

Mesa 18.3.3 is now available. In this release we have: A memory leak fix in the etnaviv driver, better NEON assembly code in vc4 and couple of stability improvements to the radeonsi driver. Another memory leak affecting all gallium drivers have also been addressed. The time required to compile

Re: [Mesa-dev] [PATCH] ac/radv/radeonsi: add ac_get_num_physical_sgprs() helper

Reviewed-by: Samuel Pitoiset On 2/1/19 11:28 AM, Timothy Arceri wrote: --- src/amd/common/ac_gpu_info.h | 6 ++ src/amd/vulkan/radv_device.c | 2 +- src/amd/vulkan/radv_shader.c | 4 ++-- src/amd/vulkan/radv_shader.h | 6 --

[Mesa-dev] [PATCH] ac/radv/radeonsi: add ac_get_num_physical_sgprs() helper

--- src/amd/common/ac_gpu_info.h | 6 ++ src/amd/vulkan/radv_device.c | 2 +- src/amd/vulkan/radv_shader.c | 4 ++-- src/amd/vulkan/radv_shader.h | 6 -- src/gallium/drivers/radeonsi/si_shader.c | 7 +++ 5 files changed, 12

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

https://bugs.freedesktop.org/show_bug.cgi?id=109242 --- Comment #35 from Bas Nieuwenhuizen --- Not sure the fix from the bug would affect a rx 570, but this has been fixed in radeonsi as well: commit 5183e794affbbbf7dc959332619b0852c21536d6 Author: Marek Olšák Date: Mon Jan 14 18:24:08 2019

Re: [Mesa-dev] [PATCH v5] etnaviv: fix resource usage tracking across different pipe_context's

Hi, On Wed, Jan 30, 2019 at 05:28:14AM +0100, Marek Vasut wrote: > From: Christian Gmeiner > > A pipe_resource can be shared by all the pipe_context's hanging off the > same pipe_screen. > > Signed-off-by: Christian Gmeiner > Signed-off-by: Marek Vasut > To: mesa-dev@lists.freedesktop.org >

Re: [Mesa-dev] [PATCH 09/19] radv: use the new attachments array in CmdEndRenderPass()

On Fri, Feb 1, 2019 at 8:52 AM Samuel Pitoiset wrote: > > > On 1/31/19 11:16 AM, Bas Nieuwenhuizen wrote: > > On Tue, Jan 29, 2019 at 10:16 PM Samuel Pitoiset > > wrote: > >> That shouldn't change anything as we check if the last > >> subpass id is the final subpass. > >> > >> Signed-off-by:

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

https://bugs.freedesktop.org/show_bug.cgi?id=109242 --- Comment #34 from madc...@atlas.cz --- I hate to make noise about a closed issue but I believe I have been seeing a GPU hang very similar to what is described here in Witcher 3 fights. I can reproduce it only when the game is run through

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

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 the dist built. Notable in the

[Mesa-dev] [PATCH v2 1/4] radv: gather more info about push constants

This is needed in order to inline some push constants when possible. This also adds a new helper for initializing the pass. v2: - use MIN2/MAX2 - use UINT8_MAX Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_nir_to_llvm.c | 2 ++ src/amd/vulkan/radv_private.h | 2 ++

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

On Wed, 30 Jan 2019 18:33:35 + Emil Velikov said: You might want to hold off on this. My bugfix was actually patched out by partly removing some of it. The void ptr math should never have been there and wasn't in the final patch. I'm talking about: +void *cpu2 = cpu + 8;