Re: [Mesa-dev] [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

Hi Keith, If I read the patch correctly, the plane has been interpreted as the same as connector, and the stackIndex is the index of connector of current device. Is it by intentional? If the hardware don't have underlay/overlay supported, is it better to always report plane 0 rather than pretend

[Mesa-dev] [Bug 101747] Steam-Game Turmoil, Segfault on start

https://bugs.freedesktop.org/show_bug.cgi?id=101747 Timothy Arceri changed: What|Removed |Added Depends on||105797

[Mesa-dev] [PATCH v5 08/19] intel/blorp: Only copy clear color when doing a resolve.

We only need to copy the clear color from the state buffer to the inlined surface state when doing a resolve. Signed-off-by: Rafael Antognolli Reviewed-by: Jason Ekstrand Reviewed-by: Jordan Justen ---

[Mesa-dev] [PATCH v5 05/19] intel: Use Clear Color struct size.

The size of the clear color struct (expected by the hardware) is 8 dwords (isl_dev.ss.clear_value_state_size here). But we still need to track the size of the clear color, used when memcopying it to/from the state buffer. For that we keep isl_dev.ss.clear_value_size. v4: - Add struct to gen11

[Mesa-dev] [PATCH v5 10/19] i965/miptree: Add space to store the clear value in the aux surface.

Similarly to vulkan where we store the clear value in the aux surface, we can do the same in GL. v2: Remove unneeded extra function. v3: Use clear_value_state_size instead of clear_value_size. v4: - rename to clear_color_state_size - store clear_color_bo and clear_color_offset in the aux buf

[Mesa-dev] [PATCH v5 11/19] i965/miptree: Add new clear color BO for winsys aux buffers

Add an extra BO to store clear color when we receive the aux buffer from the window system. Since we have no control over the aux buffer size in this case, we need the new BO to store only the clear color. v5: - Better subject (Jordan). - Drop alignment from brw_bo_alloc(). Signed-off-by:

[Mesa-dev] [PATCH v5 13/19] i965/blorp: Update the fast clear value buffer.

On Gen10, whenever we do a fast clear, blorp will update the clear color state buffer for us, as long as we set the clear color address correctly. However, on a hiz clear, if the surface is already on the fast clear state we skip the actual fast clear operation and, before gen10, only updated the

[Mesa-dev] [PATCH v5 04/19] intel/genxml: Add Clear Color struct to gen10+.

v5: Split genxml changes into its own commit (Jason). Signed-off-by: Rafael Antognolli --- src/intel/genxml/gen10.xml | 8 src/intel/genxml/gen11.xml | 10 ++ 2 files changed, 18 insertions(+) diff --git a/src/intel/genxml/gen10.xml

[Mesa-dev] [PATCH v5 16/19] anv: Emit the fast clear color address, instead of value.

On Gen10+, instead of copying the clear color from the state buffer to the surface state, just use the address of the state buffer in the surface state directly. This way we can avoid the copy from state buffer to surface state. v4: - Remove use_clear_address from anv code. (Jason) - Use the

[Mesa-dev] [PATCH v5 09/19] intel/blorp: Update clear color state buffer during fast clears.

We always want to update the fast clear color during a fast clear on i965. On anv, we are doing that before a resolve, but by adding support to blorp, we can do a similar thing and update it during a fast clear instead. The goal is to remove some code from anv that does such update, and

[Mesa-dev] [PATCH v5 01/19] anv/image: Do not override lower bits of dword.

The lower bits seem to have extra fields in every platform but gen8 (even though we don't use them in gen9). So just go ahead and avoid using them for the address. v4: Use Jason's suggestion for comment explaining the change. v5: Fix aux_address comment in anv_private.h (Jason) Signed-off-by:

[Mesa-dev] [PATCH v5 00/19] Use clear color address in surface state.

Another revision, hopefully with all the last suggestions included. This revision of this series can be found here: https://cgit.freedesktop.org/~rantogno/mesa/log/?h=cnl/fast_clear_address_v5 Cc: Jason Ekstrand Cc: Jordan Justen Cc:

[Mesa-dev] [PATCH v5 06/19] intel/isl: Add support to emit clear value address.

gen10 can emit the clear color by setting it on a buffer somewhere, and then adding only the address to the surface state. This commit add support for that on isl_surf_fill_state, and if that is requested, skip setting the clear value itself. v2: Add assert to make sure we are at least on gen10.

[Mesa-dev] [PATCH v5 02/19] genxml: Preserve fields that share dword space with addresses.

Some instructions contain fields that are either an address or a value of some type based on the content of other fields, such as clear color values vs address. That works fine if these fields are in the less significant dword, the lower 32 bits of the address, because they get OR'ed with the

[Mesa-dev] [PATCH v5 03/19] intel/genxml: Use a single field for clear color address on gen10.

genxml does not support having two address fields with different names but same position in the state struct. Both "Clear Color Address" and "Clear Depth Address Low" mean the same thing, only for different surface types. To workaround this genxml limitation, rename "Clear Color Address" to

Re: [Mesa-dev] [PATCH] meson: fix warnings about comparing unlike types

On Thu, Mar 29, 2018 at 09:31:13AM -0700, Dylan Baker wrote: > In the old days (0.42.x), when mesa's meson system was written the > recommendation for handling conditional dependencies was to define them > as empty lists. When meson would evaluate the dependencies of a target > it would

Re: [Mesa-dev] [PATCH] meson: fix warnings about comparing unlike types

Quoting Caio Marcelo de Oliveira Filho (2018-03-29 11:13:51) > On Thu, Mar 29, 2018 at 09:31:13AM -0700, Dylan Baker wrote: > > In the old days (0.42.x), when mesa's meson system was written the > > recommendation for handling conditional dependencies was to define them > > as empty lists. When

Re: [Mesa-dev] [PATCH] intel/compiler: fix return statement warning in brw_regs_negative_equal()

I have a theory about this warning... I'll either have a patch or an R-b today. On 03/28/2018 06:48 PM, Brian Paul wrote: > Silence a gcc warning about missing return value in non-void function. > For some reason, gcc 5.4.0 (at least) can't deduce that all else/if > cases return a value. > --- >

Re: [Mesa-dev] [PATCH] meson: don't use compiler.has_header

This should be nominated for stable Quoting Dylan Baker (2018-03-12 11:23:23) > Meson's compiler.has_header is completely useless, it only checks that a > header exists, not whether it's usable. This creates problems if a > header contains a conditional #error declaration, like so: > > > #if

Re: [Mesa-dev] [PATCH 6/8] vbo: Readd the arrays argument to the legacy draw methods.

On 03/25/2018 12:42 PM, mathias.froehl...@gmx.net wrote: From: Mathias Fröhlich The legacy draw paths from back before 2012 contained a gl_vertex_array array for the inputs to be used for draw. So all draw methods from legacy drivers and evereything that goes through

[Mesa-dev] [PATCH v5 15/19] anv: Add a helper to extract clear color from the attachment.

Extract the code from color_attachment_compute_aux_usage, so we can later reuse it to update the clear color state buffer. Signed-off-by: Rafael Antognolli Reviewed-by: Jason Ekstrand Reviewed-by: Jordan Justen ---

[Mesa-dev] [PATCH v5 18/19] anv: Make blorp update the clear color.

Instead of updating the clear color in anv before a resolve, just let blorp handle that for us during fast clears. v5: Update comment about HiZ clear color (Jordan). Signed-off-by: Rafael Antognolli Reviewed-by: Jason Ekstrand Reviewed-by:

[Mesa-dev] [PATCH v5 14/19] i965/surface_state: Emit the clear color address instead of value.

On Gen10, when emitting the surface state, use the value stored in the clear color entry buffer by using a clear color address in the surface state. v4: Use the clear color offset from the clear_color_bo, when available. Signed-off-by: Rafael Antognolli Reviewed-by:

[Mesa-dev] [PATCH v5 17/19] anv: Use clear address for HiZ fast clears too.

Store the default clear address for HiZ fast clears on a global bo, and point to it when needed. Signed-off-by: Rafael Antognolli Reviewed-by: Jason Ekstrand Reviewed-by: Jordan Justen ---

[Mesa-dev] [PATCH v5 07/19] intel/blorp: Add support for fast clear address.

On gen10+, if surface->clear_color_addr is present, use it directly intead of copying it to the surface state. v4: Remove redundant #if clause for GEN <= 10 (Jason) v5: Move flush after the reloc, and keep lower bits (Topi). Signed-off-by: Rafael Antognolli

[Mesa-dev] [PATCH v5 19/19] intel: Remove use_clear_address flag from isl_surf_fill_state_info.

This flag was used while porting parts of the code to use the clear color address, but other parts were not ported yet. So isl had to be flexible enough to support both cases. Now that the code is using exclusively clear color address for everything Gen10+, we don't need it anymore.

[Mesa-dev] [PATCH v5 12/19] i965: Add aux_buf variable to simplify code.

In a follow up patch, we make use of clear_color_bo, which is in mt->mcs_buf or mt->hiz_buf. To avoid duplicating more code that does the same thing on both aux buffers, just use aux_buf already. v5: Add aux_buf to brw_wm_surface_state too. Signed-off-by: Rafael Antognolli

[Mesa-dev] [PATCH] meson: fix warnings about comparing unlike types

In the old days (0.42.x), when mesa's meson system was written the recommendation for handling conditional dependencies was to define them as empty lists. When meson would evaluate the dependencies of a target it would recursively flatten all of the arguments, and empty lists would be removed.

Re: [Mesa-dev] [PATCH] vbo: Use alloca for _vbo_draw_indirect.

On 03/28/2018 04:35 AM, mathias.froehl...@gmx.net wrote: From: Mathias Fröhlich Marek, you mean with the below patch as the 9-th change in the series? I would like to keep that change seprarate from #3 since patch #3 just moves the already existing impelentation to

Re: [Mesa-dev] [PATCH 06/61] nir/validator: Validate that all used variables exist

On Friday, March 23, 2018 2:42:12 PM PDT Jason Ekstrand wrote: > We were validating this for locals but nothing else. > --- > src/compiler/nir/nir_validate.c | 16 +--- > 1 file changed, 9 insertions(+), 7 deletions(-) > > diff --git a/src/compiler/nir/nir_validate.c

[Mesa-dev] [PATCH] nir: add support for 4 constant offsets in tg4

Nvidia hardware can do that natively so there is no need to lower that to four TG4s instructions. Signed-off-by: Karol Herbst --- src/compiler/glsl/glsl_to_nir.cpp | 25 ++--- src/compiler/nir/nir.h| 9 - src/compiler/nir/nir_print.c

[Mesa-dev] [AppVeyor] mesa master #7334 failed

Build mesa 7334 failed Commit 19e0dd1ad3 by Ian Romanick on 10/18/2017 3:59 PM: i965: Don't request GLSL IR lowering of gl_VertexID\n\nLet the lowering in NIR handle it instead.\n\nThis hurts one shader that occurs twice in shader-db (SynMark GSCloth)\non IVB

[Mesa-dev] [Bug 105730] [llvmpipe] 109 piglit failures, 19264 crashes on ppc (ppc64, mesa-18.0.0)

https://bugs.freedesktop.org/show_bug.cgi?id=105730 --- Comment #5 from erhar...@mailbox.org --- Created attachment 138435 --> https://bugs.freedesktop.org/attachment.cgi?id=138435=edit html summary from 'pigllit run all' (18.0.0) -- You are receiving this mail because: You are the QA Contact

[Mesa-dev] [PATCH] intel/compiler: Explicitly cast register type in switch

From: Ian Romanick brw_reg::type is "enum brw_reg_type type:4". For whatever reason, GCC is treating this as an int instead of an enum. As a result, it doesn't detect missing switch cases and it doesn't detect that flow can get out of the switch. This silences the

[Mesa-dev] [Bug 105730] [llvmpipe] 109 piglit failures, 19264 crashes on ppc (ppc64, mesa-18.0.0)

https://bugs.freedesktop.org/show_bug.cgi?id=105730 --- Comment #4 from erhar...@mailbox.org --- Created attachment 138432 --> https://bugs.freedesktop.org/attachment.cgi?id=138432=edit results from 'pigllit run all' (18.0.0) -- You are receiving this mail because: You are the QA Contact for

Re: [Mesa-dev] [PATCH] intel/compiler: Explicitly cast register type in switch

On 03/29/2018 12:32 PM, Ian Romanick wrote: From: Ian Romanick brw_reg::type is "enum brw_reg_type type:4". For whatever reason, GCC is treating this as an int instead of an enum. As a result, it doesn't detect missing switch cases and it doesn't detect that flow

[Mesa-dev] [Bug 103999] 4x MSAA with RG32F shows garbage on triangle edges

https://bugs.freedesktop.org/show_bug.cgi?id=103999 --- Comment #6 from Clément Guérin --- @maister could you host your apitrace and share it here? -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the

Re: [Mesa-dev] [PATCH, v2] CHROMIUM: configure.ac/meson.build: Fix -latomic test

On Thu, Mar 29, 2018 at 1:31 AM, Nicolas Boichat wrote: > From: Nicolas Boichat > > When compiling with LLVM 6.0, the test fails to detect that > -latomic is actually required, as the atomic call is inlined. > > In the code itself

Re: [Mesa-dev] [PATCH] intel/compiler: Explicitly cast register type in switch

On Thu, Mar 29, 2018 at 11:32 AM, Ian Romanick wrote: > From: Ian Romanick > > brw_reg::type is "enum brw_reg_type type:4". For whatever reason, GCC > is treating this as an int instead of an enum. As a result, it doesn't > detect missing switch

[Mesa-dev] [Bug 105730] [llvmpipe] 109 piglit failures, 19264 crashes on ppc (ppc64, mesa-18.0.0)

https://bugs.freedesktop.org/show_bug.cgi?id=105730 erhar...@mailbox.org changed: What|Removed |Added Summary|[llvmpipe] 116 piglit |[llvmpipe] 109 piglit

[Mesa-dev] [Bug 105775] F1 2017 crashes on GCN 1.0 cards

https://bugs.freedesktop.org/show_bug.cgi?id=105775 --- Comment #20 from Samuel Pitoiset --- FYI, I can actually reproduce the crash on Polaris, I will investigate tomorrow. Thansk for all the details. -- You are receiving this mail because: You are the QA Contact

Re: [Mesa-dev] [PATCH 1/2] gallium/util: Don't stub u_debug_stack on Android

On Thu, Mar 29, 2018 at 4:38 PM, Eric Engestrom wrote: > On Thursday, 2018-03-29 00:19:00 +0200, Stefan Schake wrote: >> The fallback path for no libunwind ends up being stubs for Android. >> Don't compile them in so we can provide our own implementation. >> >>

[Mesa-dev] [Bug 105738] commit f7ffa504a065dc2631fd38cc5fe885b277f4e7e7 causes artifacting in radv

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

Re: [Mesa-dev] [PATCH] intel/compiler: fix return statement warning in brw_regs_negative_equal()

Hi Brian, On 29 March 2018 at 02:48, Brian Paul wrote: > Silence a gcc warning about missing return value in non-void function. > For some reason, gcc 5.4.0 (at least) can't deduce that all else/if > cases return a value. A small brain dump: Guessing that's because of the

Re: [Mesa-dev] [PATCH] mesa: Inherit texture view multi-sample information from the original texture images.

On 27 March 2018 at 18:57, Brian Paul wrote: > LGTM. I guess we probably don't have much piglit coverage for texture_view > + MSAA. > > Reviewed-by: Brian Paul > I've pushed this, thanks for the review. A piglit test should be straightforward, but I'll

Re: [Mesa-dev] [PATCH] configure.ac: Fix -latomic test

Scrap this, I guess I should update meson.build, too. Will send v2 in a few minutes. On Thu, Mar 29, 2018 at 4:26 PM, Nicolas Boichat wrote: > From: Nicolas Boichat > > When compiling with LLVM 6.0, the test fails to detect that > -latomic is

Re: [Mesa-dev] [PATCH] gl.h: remove stale comment, trailing whitespace

Reviewed-by: Emil Velikov -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

https://bugs.freedesktop.org/show_bug.cgi?id=105320 --- Comment #3 from Samuel Pitoiset --- This should be fixed with https://cgit.freedesktop.org/mesa/mesa/commit/?id=4503ff760c794c3bb15b978a47c530037d56498e Note that it's a workaround because we are waiting for a

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

https://bugs.freedesktop.org/show_bug.cgi?id=105320 Samuel Pitoiset changed: What|Removed |Added Resolution|--- |FIXED

[Mesa-dev] [Bug 105775] F1 2017 crashes on GCN 1.0 cards

https://bugs.freedesktop.org/show_bug.cgi?id=105775 --- Comment #14 from Alex Smith --- The crash is in the game code so I don't think a Mesa backtrace would help. It looks like the dump file hasn't been attached properly - could you re-attach it so I can look at

[Mesa-dev] [PATCH] configure.ac: Fix -latomic test

From: Nicolas Boichat When compiling with LLVM 6.0, the test fails to detect that -latomic is actually required, as the atomic call is inlined. In the code itself (src/util/disk_cache.c), we see this pattern: p_atomic_add(cache->size, - (uint64_t)size); where cache->size

Re: [Mesa-dev] [PATCH] nvc0: drop image binding from BGR10A2 format

Did a CTS run on that. Things are looking better with it. No regressions. Tested-By: Karol Herbst On Thu, Mar 29, 2018 at 5:47 AM, Ilia Mirkin wrote: > Fixes a bunch of new CTS pbo tests that use that as an output format, > which the state tracker

[Mesa-dev] [ANNOUNCE] Mesa 17.3.8 release candidate

Hello list, The candidate for the Mesa 17.3.8 is now available. Currently we have: - 18 queued - 0 nominated (outstanding) - and 0 rejected patches The current queue consists of: In NIR we have a couple of patches to fix a crash when unrolling loops, as well as a fix for per_vertex_output

[Mesa-dev] [PATCH, v2] CHROMIUM: configure.ac/meson.build: Fix -latomic test

From: Nicolas Boichat When compiling with LLVM 6.0, the test fails to detect that -latomic is actually required, as the atomic call is inlined. In the code itself (src/util/disk_cache.c), we see this pattern: p_atomic_add(cache->size, - (uint64_t)size); where cache->size

Re: [Mesa-dev] [PATCH, v2] CHROMIUM: configure.ac/meson.build: Fix -latomic test

And now I left the CHROMIUM tag, sorry ,-( On Thu, Mar 29, 2018 at 4:31 PM, Nicolas Boichat wrote: > From: Nicolas Boichat > > When compiling with LLVM 6.0, the test fails to detect that > -latomic is actually required, as the atomic call is

[Mesa-dev] [PATCH v4] i965: initialize SPIR-V capabilities

Needed for ARB_gl_spirv. Those are not the same that the Intel vulkan driver. From the ARB_spirv_extensions spec: "3. If a new GL extension is added that includes SPIR-V support via a new SPIR-V extension does it's SPIR-V extension also get enumerated by the SPIR_V_EXTENSIONS_ARB query?.

[Mesa-dev] [Bug 105775] F1 2017 crashes on GCN 1.0 cards

https://bugs.freedesktop.org/show_bug.cgi?id=105775 --- Comment #18 from Jacob --- Created attachment 138416 --> https://bugs.freedesktop.org/attachment.cgi?id=138416=edit dmp when starting a race Just to chime in, when running everything on low at 1600x900

[Mesa-dev] [Bug 105775] F1 2017 crashes on GCN 1.0 cards

https://bugs.freedesktop.org/show_bug.cgi?id=105775 --- Comment #16 from Amarildo --- Created attachment 138415 --> https://bugs.freedesktop.org/attachment.cgi?id=138415=edit New dmp -- You are receiving this mail because: You are the assignee for the bug. You

[Mesa-dev] [Bug 105775] F1 2017 crashes on GCN 1.0 cards

https://bugs.freedesktop.org/show_bug.cgi?id=105775 --- Comment #15 from Amarildo --- Ah, I thought it was a RADV problem. I'll attach a new dump bellow. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the

[Mesa-dev] [Bug 105775] F1 2017 crashes on GCN 1.0 cards

https://bugs.freedesktop.org/show_bug.cgi?id=105775 --- Comment #17 from Alex Smith --- Thanks. The failing call is vkEndCommandBuffer. That matches with a few other crashes we have logged on GCN 1.0 cards. RADV devs, any ideas what might cause that to happen for

[Mesa-dev] [Bug 105775] F1 2017 crashes on GCN 1.0 cards

https://bugs.freedesktop.org/show_bug.cgi?id=105775 --- Comment #19 from Alex Smith --- Yes, same call failing there too. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the

Re: [Mesa-dev] [PATCH 06/61] nir/validator: Validate that all used variables exist

On Thu, Mar 29, 2018 at 2:19 PM, Kenneth Graunke wrote: > On Friday, March 23, 2018 2:42:12 PM PDT Jason Ekstrand wrote: > > We were validating this for locals but nothing else. > > --- > > src/compiler/nir/nir_validate.c | 16 +--- > > 1 file changed, 9

Re: [Mesa-dev] [PATCH] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass

Quoting Mike Lothian (2018-03-29 16:56:28) > Include llvm-c/Transforms/Utils.h with the newest LLVM 7 > > Fixes: 2dd4f35c7fc llvm-c: Split Utils out of Scalar.h I have no comment on the patch itself. JFYI, this tag ("Fixes") has specific meaning in mesa and should only refer to mesa commits (we

Re: [Mesa-dev] [PATCH] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass

On Fri, 30 Mar 2018, 01:42 Dylan Baker, wrote: > Quoting Mike Lothian (2018-03-29 16:56:28) > > Include llvm-c/Transforms/Utils.h with the newest LLVM 7 > > > > Fixes: 2dd4f35c7fc llvm-c: Split Utils out of Scalar.h > > I have no comment on the patch itself. > > JFYI, this

Re: [Mesa-dev] [PATCH 3/4] radeonsi: create load_const_buffer_desc_fast_path() helper

The driver should ignore the nir option on SI with LLVM <= 0x0500. Marek On Tue, Mar 27, 2018 at 12:19 AM, Timothy Arceri wrote: > This will be shared by the TGSI and NIR backends. For simplicity > we leave the SI LLVM 5.0 and lower work around only in the TGSI >

Re: [Mesa-dev] [PATCH] nir: s/uint/unsigned/ to fix MSVC/MinGW build

Looks good to me, though I wonder what broke it - must have been some include file reshuffling? Reviewed-by: Roland Scheidegger Am 30.03.2018 um 06:02 schrieb Brian Paul: > --- > src/compiler/glsl/glsl_to_nir.cpp | 2 +- > src/compiler/nir/nir_gather_info.c | 2 +- > 2

Re: [Mesa-dev] [PATCH] nir: s/uint/unsigned/ to fix MSVC/MinGW build

Reviewed-by: Neha Bhende From: Brian Paul Sent: Thursday, March 29, 2018 9:02:45 PM To: mesa-dev@lists.freedesktop.org Cc: Neha Bhende; Charmaine Lee Subject: [PATCH] nir: s/uint/unsigned/ to fix MSVC/MinGW build ---

Re: [Mesa-dev] [PATCH 4/4] radeonsi/nir: gather buffers declared more accurately and use const fast path

On 30/03/18 13:52, Marek Olšák wrote: On Tue, Mar 27, 2018 at 12:19 AM, Timothy Arceri > wrote: For now we skip SI && HAVE_LLVM < 0x0600 for simplicity. We also skip setting the more accurate masks for some builtin uniforms for now

Re: [Mesa-dev] [PATCH 4/4] radeonsi/nir: gather buffers declared more accurately and use const fast path

On Tue, Mar 27, 2018 at 12:19 AM, Timothy Arceri wrote: > For now we skip SI && HAVE_LLVM < 0x0600 for simplicity. We also skip > setting the more accurate masks for some builtin uniforms for now as > it causes some piglit regressions. > --- >

Re: [Mesa-dev] [PATCH 3/4] radeonsi: create load_const_buffer_desc_fast_path() helper

Ignore my comment on this patch. For patches 1 - 3: Reviewed-by: Marek Olšák Marek On Tue, Mar 27, 2018 at 12:19 AM, Timothy Arceri wrote: > This will be shared by the TGSI and NIR backends. For simplicity > we leave the SI LLVM 5.0 and lower work

[Mesa-dev] [PATCH] nir: s/uint/unsigned/ to fix MSVC/MinGW build

--- src/compiler/glsl/glsl_to_nir.cpp | 2 +- src/compiler/nir/nir_gather_info.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/compiler/glsl/glsl_to_nir.cpp b/src/compiler/glsl/glsl_to_nir.cpp index c4a6d52..dbb58d8 100644 --- a/src/compiler/glsl/glsl_to_nir.cpp +++

Re: [Mesa-dev] [PATCH, v2] CHROMIUM: configure.ac/meson.build: Fix -latomic test

On Fri, Mar 30, 2018 at 2:26 AM, Matt Turner wrote: > On Thu, Mar 29, 2018 at 1:31 AM, Nicolas Boichat > wrote: >> From: Nicolas Boichat >> >> When compiling with LLVM 6.0, the test fails to detect that >> -latomic is actually

[Mesa-dev] [PATCH] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass

Include llvm-c/Transforms/Utils.h with the newest LLVM 7 Fixes: 2dd4f35c7fc llvm-c: Split Utils out of Scalar.h Signed-of-by: Mike Lothian --- I don't have git commit rights If you're happy with this patch please can you commit it Cheers Mike ---

[Mesa-dev] [Bug 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

https://bugs.freedesktop.org/show_bug.cgi?id=105755 --- Comment #20 from Sergii Romantsov --- Created attachment 138422 --> https://bugs.freedesktop.org/attachment.cgi?id=138422=edit Issue with some bots head 2 -- You are receiving this mail because: You are

[Mesa-dev] [Bug 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

https://bugs.freedesktop.org/show_bug.cgi?id=105755 --- Comment #19 from Sergii Romantsov --- Created attachment 138420 --> https://bugs.freedesktop.org/attachment.cgi?id=138420=edit Issue with some bots head 1 -- You are receiving this mail because: You are

[Mesa-dev] [Bug 105807] [Regression, bisected]: 3D Rendering not working correctly in Warhammer 40k: Dawn of War II

https://bugs.freedesktop.org/show_bug.cgi?id=105807 Bug ID: 105807 Summary: [Regression, bisected]: 3D Rendering not working correctly in Warhammer 40k: Dawn of War II Product: Mesa Version: git Hardware: x86-64 (AMD64)

[Mesa-dev] [Bug 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

https://bugs.freedesktop.org/show_bug.cgi?id=105755 Sergii Romantsov changed: What|Removed |Added Attachment #138420|0 |1

[Mesa-dev] [Bug 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

https://bugs.freedesktop.org/show_bug.cgi?id=105755 Sergii Romantsov changed: What|Removed |Added Attachment #138422|0 |1

[Mesa-dev] [Bug 105807] [Regression, bisected]: 3D Rendering not working correctly in Warhammer 40k: Dawn of War II

https://bugs.freedesktop.org/show_bug.cgi?id=105807 --- Comment #1 from b...@besd.de --- Created attachment 138419 --> https://bugs.freedesktop.org/attachment.cgi?id=138419=edit Ingame Image -- You are receiving this mail because: You are the assignee for the bug. You are the

[Mesa-dev] [PATCH] radv: do not always disable dual quad mode when chip has RbPlus

For GFX9+ only, RadeonSI does this too. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_pipeline.c | 20 +--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c index

[Mesa-dev] [PATCH 4/4] radv: enable out-of-order rasterization when it's safe on VI+

This can be disabled with RADV_DEBUG=nooutoforder. No CTS regressions on Polaris, and all Vulkan games I tested look good as well. Expect small performance improvements for applications where out-of-order rasterization can be enabled by the driver. Loosely based on RadeonSI. Signed-off-by:

[Mesa-dev] [PATCH 1/4] radv: put more fields in radv_blend_state

Some will be used for further optimizations (ie. out-of-order rast). Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_pipeline.c | 33 +++-- 1 file changed, 15 insertions(+), 18 deletions(-) diff --git

[Mesa-dev] [PATCH 2/4] radv: scan which color blend attachments are enabled

With cb_target_enabled_4bit in order to have four bits per CB. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_pipeline.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c index

[Mesa-dev] [PATCH 3/4] radv: change blend_enable field to use four bits per CB

Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_pipeline.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c index 4960c50b72..e259b16318 100644 ---

Re: [Mesa-dev] [PATCH 00/61] nir: Move to using instructions for derefs

On Wed, Mar 28, 2018 at 9:41 PM, Jason Ekstrand wrote: > > On March 28, 2018 17:43:31 Rob Clark wrote: > > On Wed, Mar 28, 2018 at 8:16 PM, Jason Ekstrand > wrote: > On March 28, 2018 16:54:33 Rob Clark

Re: [Mesa-dev] [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

"Mao, David" writes: > Hi Keith, > If I read the patch correctly, the plane has been interpreted as the same as > connector, and the stackIndex is the index of connector of current device. > Is it by intentional? > If the hardware don't have underlay/overlay supported, is it

Re: [Mesa-dev] [PATCH 00/61] nir: Move to using instructions for derefs

On March 29, 2018 06:44:59 Rob Clark wrote: On Wed, Mar 28, 2018 at 9:41 PM, Jason Ekstrand wrote: On March 28, 2018 17:43:31 Rob Clark wrote: On Wed, Mar 28, 2018 at 8:16 PM, Jason Ekstrand wrote: On

[Mesa-dev] [PATCH v2] nvc0: restore image binding on RGB10A2, remove from BGR10A2

Fixes a bunch of new CTS pbo tests that use those as an output format, which the state tracker converts into buffer image writes. No part of the driver is ready for BGR10A2. It could probably be enabled on Maxwell+, but seems unnecessary. This error was introduced when flipping the displayable

[Mesa-dev] [PATCH 1/2] gallium/util: implement util_format_is_yuv

This adds a helper to check if a pipe format is in YUV color space. Drivers want to know about this, as YUV mostly needs special handling. Signed-off-by: Lucas Stach --- src/gallium/auxiliary/util/u_format.h | 12 1 file changed, 12 insertions(+) diff --git

Re: [Mesa-dev] [PATCH 08/12] etnaviv: support TX performance counters

Am Sonntag, den 25.03.2018, 22:30 +0200 schrieb Christian Gmeiner: > > Signed-off-by: Christian Gmeiner > --- >  src/gallium/drivers/etnaviv/etnaviv_query_pm.c | 63 > ++ >  src/gallium/drivers/etnaviv/etnaviv_query_pm.h | 10 >  2 files

[Mesa-dev] [PATCH 2/2] etnaviv: advertise YUV formats as external only

We only support importing YUV as OES external resources. This will change in the future, but for now this fixes the advertised capabilities in eglQueryDmaBufModifiersEXT. Signed-off-by: Lucas Stach --- src/gallium/drivers/etnaviv/etnaviv_screen.c | 2 +- 1 file changed,

Re: [Mesa-dev] [PATCH 1/2] gallium/util: Don't stub u_debug_stack on Android

On Thursday, 2018-03-29 00:19:00 +0200, Stefan Schake wrote: > The fallback path for no libunwind ends up being stubs for Android. > Don't compile them in so we can provide our own implementation. > > Signed-off-by: Stefan Schake > --- >

Re: [Mesa-dev] [PATCH v4] i965: initialize SPIR-V capabilities

On March 29, 2018 02:45:36 Alejandro Piñeiro wrote: Needed for ARB_gl_spirv. Those are not the same that the Intel vulkan driver. From the ARB_spirv_extensions spec: "3. If a new GL extension is added that includes SPIR-V support via a new SPIR-V extension does it's

Re: [Mesa-dev] [PATCH] intel/compiler: fix return statement warning in brw_regs_negative_equal()

On 03/29/2018 03:49 AM, Emil Velikov wrote: Hi Brian, On 29 March 2018 at 02:48, Brian Paul wrote: Silence a gcc warning about missing return value in non-void function. For some reason, gcc 5.4.0 (at least) can't deduce that all else/if cases return a value. A small