Re: [Mesa-dev] [PATCH v2] egl: check if colorspace/surface type is supported

On 05/03/2018 08:49 PM, Emil Velikov wrote: On 2 May 2018 at 17:23, Juan A. Suarez Romero wrote: According to EGL 1.4 spec, section 3.5.1 ("Creating On-Screen Rendering Surfaces"), if config does not support the colorspace or alpha format attributes specified in

[Mesa-dev] [PATCH] egl: add EGL_BAD_MATCH error case for surfaceless and android

Just like is done for other backends when suitable config is not found (added in fd4eba4929). Signed-off-by: Tapani Pälli --- src/egl/drivers/dri2/platform_android.c | 4 +++- src/egl/drivers/dri2/platform_surfaceless.c | 4 +++- 2 files changed, 6 insertions(+), 2

Re: [Mesa-dev] [PATCH 8/9] anv: elide relocations to pinned target bos

If I'm honest, I don't really like the way this patch worked out. It has the virtue of being fairly simple and a nice incremental change. However, it seems to me like we should be able to do better. That said, I don't really know how off-hand and this looks correct and gets us going. On Wed,

Re: [Mesa-dev] [PATCH 02/10] util: Add a virtual memory allocator

On Thu, May 3, 2018 at 6:12 PM, Kenneth Graunke wrote: > From: Jason Ekstrand > > This is simple linear-walk first-fit allocator roughly based on the > allocator in the radeon winsys code. This allocator has two primary > functional differences:

Re: [Mesa-dev] [PATCH 7/9] anv: use a separate pool for binding tables when soft pinning

On Wed, May 2, 2018 at 9:01 AM, Scott D Phillips wrote: > Soft pinning lets us satisfy the binding table address > requirements without using both sides of a growing state_pool. > > If you do use both sides of a state pool, then you need to read > the state pool's

Re: [Mesa-dev] [PATCH] mesa/main/readpix: Correct handling of packed floating point values

For those wondering why the dEQP CTS tests this fixes (for example dEQP-GLES3.functional.fragment_out.basic.float.r11f_g11f_b10f_lowp_float) pass outside the VM, it seems it's because the test cases read pixels with type = GL_FLOAT. virglrenderer always sets type = GL_UNSIGNED_INT_10F_11F_11F_REV

[Mesa-dev] [PATCH 02/16] ac: enable both RBs on Kaveri

From: Marek Olšák This can result in 2x increase in performance on non-harvested Kaveris. v2: don't do it on radeon Tested-by: Michel Dänzer --- src/amd/common/ac_gpu_info.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-)

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

Hi folks, I search a thread earlier that identified that someone could reproduce this problem. I don't have skills or tools to debug this, though I would not mind learning. I do other Open Software (gcc-gfortran) Anyway, when I followed the thread, it was not clear if a fix had been found

[Mesa-dev] [PATCH 05/10] i965: Introduce a "memory zone" concept on BO allocation.

We're planning to start managing the PPGTT in userspace in the near future, rather than relying on the kernel to assign addresses. While most buffers can go anywhere, some need to be restricted to within 4GB of a base address. This commit adds a "memory zone" parameter to the BO allocation

[Mesa-dev] [PATCH 07/10] i965: Prepare batchbuffer module for softpin support.

If EXEC_OBJECT_PINNED is set, we don't want to emit any relocations. We simply want to add the BO to the validation list, and possibly mark it as writeable. The new brw_use_pinned_bo() interface does just that. To avoid having to make every caller consider both the relocation and softpin cases,

[Mesa-dev] [PATCH 08/10] i965: Emit VF cache invalidates for 48-bit addressing bugs with softpin.

We'd like to start using soft-pin to assign BO addresses up front, and never move them again. Our previous plan for dealing with 48-bit VF cache bugs was to relocate vertex buffers to the low 4GB, so we'd never have addresses that alias in the low 32 bits. But that requires moving buffers

[Mesa-dev] [PATCH 01/10] i965: Set initial kflags on BO creation.

This simplifies kflag initialization, by creating a bufmgr-wide setting for initial kflags, and just applying it whenever we create a new BO. This also properly allows 48-bit addresses for imported BOs (via prime or flink), which I had missed in my earlier 48-bit support series. This will be

[Mesa-dev] [PATCH 09/10] i965: Softpin all buffers and never use relocations.

--- src/mesa/drivers/dri/i965/brw_bufmgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) This enables it for Broadwell (with a 64-bit kernel) and Skylake+ (with any kernel). Unfortunately, it doesn't enable it for Cherryview as that has a 32-bit GTT. We could switch that over as well,

[Mesa-dev] [PATCH 10/10] i965: Require softpin support for Cannonlake and later.

This isn't strictly necessary, but anyone running Cannonlake will already have Kernel 4.5 or later, so there's no reason to support the relocation model on Gen10+. This will let us avoid dealing with them for new features. --- src/mesa/drivers/dri/i965/brw_bufmgr.c | 4 1 file changed, 4

[Mesa-dev] [PATCH 04/10] i965: Dump validation list on INTEL_DEBUG=bat, submit.

This is really useful when debugging any sort of buffer management issues, so just printing it during INTEL_DEBUG=bat,submit seems reasonable. With bat, we're already spamming so much output that it doesn't really hurt. With submit, it's still easy to grep for the older information, and the new

[Mesa-dev] [PATCH 02/10] util: Add a virtual memory allocator

From: Jason Ekstrand This is simple linear-walk first-fit allocator roughly based on the allocator in the radeon winsys code. This allocator has two primary functional differences: 1) It cleanly returns 0 on allocation failure 2) It allocates addresses top-down

[Mesa-dev] [PATCH 06/10] i965: Add virtual memory allocator infrastructure to brw_bufmgr.

This introduces a new fast virtual memory allocator integrated with our BO cache bucketing. For larger objects, it falls back to the simple free-list allocator (util_vma). This puts the allocators in place but doesn't enable softpin yet. --- src/mesa/drivers/dri/i965/brw_bufmgr.c | 291

[Mesa-dev] [PATCH 03/10] util: Make vma.c support non-power-of-two alignments.

I want to use this in a bucketing allocator for i965. --- src/util/vma.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/util/vma.c b/src/util/vma.c index 3d61f6969ed..d6ee05988ef 100644 --- a/src/util/vma.c +++ b/src/util/vma.c @@ -88,7 +88,6 @@

Re: [Mesa-dev] [PATCH] swr: Fix include for createInstructionCombiningPass with llvm-7.0.

It would be nice to avoid the extra #if LLVM_VERSION_MAJOR and include InstCombine.h into the same #if below, as follows: --- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp +++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp @@ -69,6 +69,7 @@ using PassManager =

Re: [Mesa-dev] [PATCH 21/22] i965: Setup glsl uniforms by index rather than name matching

On 03/05/18 22:50, Neil Roberts wrote: Thanks for the feedback. I’ve implemented your suggestion as the top two patches on a branch here: https://github.com/Igalia/mesa/tree/nroberts/count-uniform-storage It also fixes a slight bug that it wasn’t passing down the uniform_storage_locs argument

[Mesa-dev] [Bug 106394] Black Mesa cannot compile shaders because of missing GL_EXT_gpu_shader4

https://bugs.freedesktop.org/show_bug.cgi?id=106394 --- Comment #2 from Timothy Arceri --- It looks like they are now using a compat profile which is unfortunate. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the

Re: [Mesa-dev] [PATCH v2 00/18] anv: add shaderInt16 support

Clayton Craft writes: > Quoting Iago Toral Quiroga (2018-04-30 07:18:08) >> This version addresses the feedback received to v1, which includes moving the >> bit-size lowering pass from intel to core NIR (patch 8) and a separate patch >> to add Intel's specific

Re: [Mesa-dev] [PATCH 6/9] anv: soft pin state pools

I commented on this in the office, but I think this whole thing would be cleaner if we just clearly documented address ranges in anv_private.h with a good comment. Something like #define LOW_HEAP_BASE_ADDRESS 4096 #define LOW_HEAP_SIZE ((3ull << 30) - 4096) #define DYNAMIC_STATE_POOL_ADDRESS

[Mesa-dev] [Bug 106394] Black Mesa cannot compile shaders because of missing GL_EXT_gpu_shader4

https://bugs.freedesktop.org/show_bug.cgi?id=106394 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED

[Mesa-dev] [Bug 106394] Black Mesa cannot compile shaders because of missing GL_EXT_gpu_shader4

https://bugs.freedesktop.org/show_bug.cgi?id=106394 Bug ID: 106394 Summary: Black Mesa cannot compile shaders because of missing GL_EXT_gpu_shader4 Product: Mesa Version: git Hardware: Other OS: All

[Mesa-dev] [AppVeyor] mesa master #7615 completed

Build mesa 7615 completed Commit 589622a2fe by Vinson Lee on 5/1/2018 6:57 AM: swr/rast: Fix WriteBitcodeToFile usage with llvm-7.0.\n\nFix build error after llvm-7.0svn r325155 ("Pass a reference to a module\nto the bitcode writer.").\n\n CXX

[Mesa-dev] [PATCH] radeon/vcn: fix mpeg4 msg buffer settings

From: Boyuan Zhang Previous bit-fields assignments are incorrect and will result certain mpeg4 decode failed due to wrong flag values. This patch fixes these assignments. Cc: 18.0 18.1 Signed-off-by: Boyuan Zhang

Re: [Mesa-dev] [PATCH 5/9] anv: Add vma_heap allocators in anv_device

On Wed, May 2, 2018 at 9:01 AM, Scott D Phillips wrote: > These will be used to assign virtual addresses to soft pinned > buffers in a later patch. > --- > src/intel/vulkan/anv_device.c | 75 ++ > >

Re: [Mesa-dev] [PATCH 02/17] i965/miptree: Zero-initialize CCS_D buffers

On Thu, May 03, 2018 at 12:40:49PM -0700, Jason Ekstrand wrote: > Good catch. Rb > Thanks! > On May 3, 2018 12:04:59 Nanley Chery wrote: > > > Before this patch, the aux_state was actually AUX_INVALID because the BO > > was never defined. This was fine on single slice

Re: [Mesa-dev] [PATCH 3/9] anv: remove unused field anv_queue::pool

Reviewed-by: Jason Ekstrand On Wed, May 2, 2018 at 9:01 AM, Scott D Phillips wrote: > The last use of the field was removed in 2015's ("48a87f4ba06 > anv/queue: Get rid of the serial") > --- > src/intel/vulkan/anv_device.c | 1 - >

Re: [Mesa-dev] [PATCH 2/9] util/set: add a set_clear function

Reviewed-by: Jason Ekstrand On Wed, May 2, 2018 at 9:01 AM, Scott D Phillips wrote: > Clear a set back to the state of having zero entries. > --- > src/util/set.c | 23 +++ > src/util/set.h | 3 +++ > 2 files changed, 26

Re: [Mesa-dev] [PATCH 02/17] i965/miptree: Zero-initialize CCS_D buffers

Good catch. Rb On May 3, 2018 12:04:59 Nanley Chery wrote: Before this patch, the aux_state was actually AUX_INVALID because the BO was never defined. This was fine on single slice miptrees because we would fast-clear the resource right after creation. For multi-slice

Re: [Mesa-dev] Lowering viewport transformation in NIR

On Thu, May 3, 2018 at 3:12 PM, Alyssa Rosenzweig wrote: > Hi all, > > Certain embedded GPUs do not implement coordinate transformation in > hardware. Instead, section 12.5 "Coordinate Transformation" of the ES > 3.2 specification is implemented in the vertex shader itself.

[Mesa-dev] Lowering viewport transformation in NIR

Hi all, Certain embedded GPUs do not implement coordinate transformation in hardware. Instead, section 12.5 "Coordinate Transformation" of the ES 3.2 specification is implemented in the vertex shader itself. Relevant examples include Midgard and vc4. To handle this, a lowering pass is needed to

[Mesa-dev] [PATCH 15/17] i965/blorp: Also skip the fast clear if the clear color differs

If the aux state is CLEAR and clear color value has changed, only the surface state must be updated. The bit-pattern in the aux buffer is exactly the same. --- src/mesa/drivers/dri/i965/brw_blorp.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git

[Mesa-dev] [PATCH 17/17] i965/blorp: Disable BLORP clear color updates

With the previous patches, we now update the indirect clear color buffer every time the clear color changes. Avoid redundant updates. --- src/mesa/drivers/dri/i965/brw_blorp.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c

[Mesa-dev] [PATCH 16/17] intel/blorp: Add a NO_UPDATE_CLEAR_COLOR batch flag

Allow callers to handle updating the indirect clear color buffer themselves. This can reduce the number of clear color updates in the case where a caller performs multiple fast clears with the same clear color. --- src/intel/blorp/blorp.h | 5 + src/intel/blorp/blorp_genX_exec.h | 6

[Mesa-dev] [PATCH 11/17] i965: Use set_clear_color for depth miptrees

Reduce code duplication now and prevent it in the following commits. --- src/mesa/drivers/dri/i965/brw_clear.c | 3 ++- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 13 - src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 5 - 3 files changed, 2 insertions(+), 19

[Mesa-dev] [PATCH 14/17] i965/clear: Drop a stale comment in fast_clear_depth

This comment made more sense when it was above the calls to intel_miptree_slice_set_needs_depth_resolve(). We stopped using these functions at commit 554f7d6d02931ea45653c8872565d21c1678a6da ("i965: Move depth to the new resolve functions"). --- src/mesa/drivers/dri/i965/brw_clear.c | 4 1

[Mesa-dev] [PATCH 08/17] i965: Prepare to delete intel_miptree_alloc_ccs()

We're going to delete intel_miptree_alloc_ccs() in the next commit. With that in mind, replace the use of this function in do_single_blorp_clear() with intel_miptree_alloc_aux() and move the delayed allocation logic to it's callers. --- src/mesa/drivers/dri/i965/brw_blorp.c | 2 +-

[Mesa-dev] [PATCH 12/17] i965/clear: Remove an early return in fast_clear_depth

Reduce complexity and allow the next patch to delete some code. With this change, clear operations will still be skipped and setting the aux_state will cause no side-effects. Remove the associated comment which implies an early return. Reviewed-by: Rafael Antognolli

[Mesa-dev] [PATCH 13/17] i965: Update the indirect buffer in set_clear_color

Although BLORP currently does the update when performing a fast clear, it's simpler to do it ourselves. Remove the dependency on BLORP. --- src/mesa/drivers/dri/i965/brw_clear.c | 37 --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 13 ++ 2 files

[Mesa-dev] [PATCH 10/17] Revert "i965: Make the miptree clear color setter take a gl_color_union"

This reverts commit 1d94aa19877fb702ffacacde28ad7253cce72c97. The next patch will make depth miptrees use the clear color setter that was originally being used for color miptrees. Go back to using the isl_color_value parameter because it's the same type as the fast_clear_color field used by color

[Mesa-dev] [PATCH 09/17] i965/miptree: Unify aux buffer allocation

There isn't much that changes between the aux allocation functions. Remove the duplicated code. --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 227 +++--- src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 9 - 2 files changed, 95 insertions(+), 141 deletions(-) diff

[Mesa-dev] [PATCH 06/17] i965/miptree: Drop the alloc_flags param from alloc_aux_buffer

We have enough information to determine the optimal flags internally. --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 29 +-- 1 file changed, 14 insertions(+), 15 deletions(-) diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c

[Mesa-dev] [PATCH 07/17] i965/miptree: Drop the mt param from alloc_aux_buffer

Drop an unused parameter. --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c index e065c2f62e0..1de381141ea 100644 ---

[Mesa-dev] [PATCH 02/17] i965/miptree: Zero-initialize CCS_D buffers

Before this patch, the aux_state was actually AUX_INVALID because the BO was never defined. This was fine on single slice miptrees because we would fast-clear the resource right after creation. For multi-slice miptrees on SKL+ however, this results in undefined behavior when accessing a non-base

[Mesa-dev] [PATCH 05/17] i965/miptree: Drop the name param from alloc_aux_buffer

A name of "aux-miptree" should be sufficient. --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c index

[Mesa-dev] [PATCH 04/17] i965/miptree: Initialize the indirect clear color to zero

The indirect clear color isn't correctly tracked in intel_miptree::fast_clear_color. The initial value of ::fast_clear_color is zero, while that of the indirect clear color is undefined or non-zero. Topi Pohjolainen discovered this issue with MCS buffers. This issue is apparent when fast-clearing

[Mesa-dev] [PATCH 03/17] i965/miptree: Move init_mcs into alloc_aux_buffer

Add infrastructure for initializing the clear color BO. --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 68 --- 1 file changed, 31 insertions(+), 37 deletions(-) diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c

[Mesa-dev] [PATCH 01/17] i965/miptree: Fix handling of uninitialized MCS buffers

Before this patch, if we failed to initialize an MCS buffer, we'd end up in a state in which the miptree thinks it has an MCS buffer, but doesn't. We also leaked the clear_color_bo if it existed. With this patch, we now free the miptree aux buffer resources and let intel_miptree_alloc_mcs() know

[Mesa-dev] [PATCH 00/17] i965: Avoid a redundant color buffer fast-clear

My main motivation for this series is to avoid one type of redundant fast-clears for color buffers (patch 15). In doing so, I take opportunities to improve the maintainability and performance of the affected code along the way. * Fix bugs that this series depends on for correct behavior (1-2). *

Re: [Mesa-dev] [PATCH v2 00/18] anv: add shaderInt16 support

Quoting Iago Toral Quiroga (2018-04-30 07:18:08) > This version addresses the feedback received to v1, which includes moving the > bit-size lowering pass from intel to core NIR (patch 8) and a separate patch > to add Intel's specific configuration for int16 (patch 9), and then it also > adds a few

Re: [Mesa-dev] [ANNOUNCE] mesa 18.1.0-rc2

On 3 May 2018 at 18:22, Dylan Baker wrote: > Quoting Emil Velikov (2018-05-03 03:40:47) >> Hi Dylan, >> >> A few small nitpicks: >> >> On 27 April 2018 at 22:07, Dylan Baker wrote: >> > Hi List, >> > >> s/List/list/ >> >> > Mesa 18.1.0-rc2 is now

Re: [Mesa-dev] [ANNOUNCE] mesa 18.1.0-rc2

Quoting Emil Velikov (2018-05-03 03:40:47) > Hi Dylan, > > A few small nitpicks: > > On 27 April 2018 at 22:07, Dylan Baker wrote: > > Hi List, > > > s/List/list/ > > > Mesa 18.1.0-rc2 is now available. There are 20 nominated patches, and no > > queued > > or rejected

Re: [Mesa-dev] [RFC PATCH] mesa/st/cb_clear: in st_Clear also validate the render state (needed by virgl)

Am Donnerstag, den 03.05.2018, 13:24 -0400 schrieb Ilia Mirkin: > > The api call is "clear", not "glClear in the context of whatever > random GL state there might be". When the gallium clear API is > invoked, the bound framebuffer needs to be cleared. This is how the > API works, this is how all

Re: [Mesa-dev] [PATCH v2] egl: check if colorspace/surface type is supported

On 2 May 2018 at 17:23, Juan A. Suarez Romero wrote: > According to EGL 1.4 spec, section 3.5.1 ("Creating On-Screen Rendering > Surfaces"), if config does not support the colorspace or alpha format > attributes specified in attrib_list (as defined for >

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

Reviewed-by: Bas Nieuwenhuizen On Thu, May 3, 2018 at 5:18 PM, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > To comply with an upcoming change in LLVM, see > https://reviews.llvm.org/D46051 > --- >

Re: [Mesa-dev] [RFC PATCH] mesa/st/cb_clear: in st_Clear also validate the render state (needed by virgl)

On Thu, May 3, 2018 at 1:15 PM, Gert Wollny wrote: > Am Donnerstag, den 03.05.2018, 12:51 -0400 schrieb Ilia Mirkin: >> >> virgl_clear implements a gallium API call which is meant to clear the >> surface. It sounds like virglrenderer does not properly implement >> that

Re: [Mesa-dev] [RFC PATCH] mesa/st/cb_clear: in st_Clear also validate the render state (needed by virgl)

Am Donnerstag, den 03.05.2018, 12:51 -0400 schrieb Ilia Mirkin: > > virgl_clear implements a gallium API call which is meant to clear the > surface. It sounds like virglrenderer does not properly implement > that > call. Either workaround your buggy "hardware" (i.e. virglrenderer) by > throwing

Re: [Mesa-dev] [PATCH] nv50/ir: fix printing of pixld

Reviewed-by: Ilia Mirkin [Can't apply now, but will tonight if no one beats me to it.] On Thu, May 3, 2018 at 1:02 PM, Rhys Perry wrote: > Signed-off-by: Rhys Perry > --- >

[Mesa-dev] [PATCH] nv50/ir: fix printing of pixld

Signed-off-by: Rhys Perry --- src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp index

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

Build mesa 7614 failed Commit 5d3caa1ca4 by Boyuan Zhang on 4/25/2018 3:49 PM: radeon/vcn: fix mpeg4 msg buffer settings\n\nPrevious bit-fields assignments are incorrect and will result certain mpeg4\ndecode failed due to wrong flag values. This patch fixes

Re: [Mesa-dev] [RFC PATCH] mesa/st/cb_clear: in st_Clear also validate the render state (needed by virgl)

On Thu, May 3, 2018 at 12:29 PM, Gert Wollny wrote: > Am Donnerstag, den 03.05.2018, 11:43 -0400 schrieb Ilia Mirkin: >> You're supposed to keep track of the bound state (usually in the >> context). After your clear() implementation is done, you have to undo >> all the

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

Hello list, The candidate for the Mesa 18.0.3 is now available. Currently we have: - 9 queued - 6 nominated (outstanding) - and 0 rejected patches The is a fairly short queue consisting of patches to fix leaks in RADV and Winsys, fix deadlock in internal queue, fix issues with ANV allocator,

Re: [Mesa-dev] [RFC PATCH] mesa/st/cb_clear: in st_Clear also validate the render state (needed by virgl)

Am Donnerstag, den 03.05.2018, 11:43 -0400 schrieb Ilia Mirkin: > You're supposed to keep track of the bound state (usually in the > context). After your clear() implementation is done, you have to undo > all the state you've messed up on your "hardware" (or mark it dirty > for revalidation).

[Mesa-dev] [PATCH 1/2] egl: declare dri2_glFlush using a macro

This is done to avoid having same code for multiple entrypoints, next patch wants to utilize glFinish. Signed-off-by: Tapani Pälli --- src/egl/drivers/dri2/egl_dri2.c | 44 + 1 file changed, 23 insertions(+), 21 deletions(-) diff

[Mesa-dev] [PATCH 2/2] egl: make eglWaitClient behave like glFinish

As defined by the spec: "All rendering calls for the currently bound context, for the current rendering API, made prior to eglWaitClient, are guaranteed to be executed before native rendering calls made after eglWaitClient which affect the read or draw surfaces associated with that

Re: [Mesa-dev] [RFC PATCH] mesa/st/cb_clear: in st_Clear also validate the render state (needed by virgl)

You're supposed to keep track of the bound state (usually in the context). After your clear() implementation is done, you have to undo all the state you've messed up on your "hardware" (or mark it dirty for revalidation). See for example

[Mesa-dev] [RFC PATCH] mesa/st/cb_clear: in st_Clear also validate the render state (needed by virgl)

A number of CTS tests from the dEQP-GLES3.functional.rasterizer_discard.* subset fail when the tests are run in a batch, because the GL_RASTERIZER_DISCARD state is enabled after running glClear and the disabled state issed after a number of draw commands is not properly send to the host. This

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

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

[Mesa-dev] [Bug 106337] eglWaitClient() doesn't work as documented using DRI2 backend

https://bugs.freedesktop.org/show_bug.cgi?id=106337 --- Comment #11 from Mike Gorchak --- > Yes that is a separate issue, please file another bug about that one. Done! Bug 106377. Thank you! -- You are receiving this mail because: You are the QA Contact for the

[Mesa-dev] [Bug 106377] eglWaitClient() doesn't work for surfaceless contexts

https://bugs.freedesktop.org/show_bug.cgi?id=106377 Bug ID: 106377 Summary: eglWaitClient() doesn't work for surfaceless contexts Product: Mesa Version: 18.0 Hardware: All OS: All Status: NEW Severity:

[Mesa-dev] [Bug 106337] eglWaitClient() doesn't work as documented using DRI2 backend

https://bugs.freedesktop.org/show_bug.cgi?id=106337 --- Comment #10 from Tapani Pälli --- (In reply to Mike Gorchak from comment #9) > Just checked generic path - all works fine, here is very minor fix to the > provided fix: > > + _eglLog(_EGL_WARNING, "DRI2: failed to

[Mesa-dev] [Bug 106337] eglWaitClient() doesn't work as documented using DRI2 backend

https://bugs.freedesktop.org/show_bug.cgi?id=106337 --- Comment #9 from Mike Gorchak --- Just checked generic path - all works fine, here is very minor fix to the provided fix: + _eglLog(_EGL_WARNING, "DRI2: failed to find glFlush entry point"); should be changed glFlush

Re: [Mesa-dev] [PATCH 21/22] i965: Setup glsl uniforms by index rather than name matching

Thanks for the feedback. I’ve implemented your suggestion as the top two patches on a branch here: https://github.com/Igalia/mesa/tree/nroberts/count-uniform-storage It also fixes a slight bug that it wasn’t passing down the uniform_storage_locs argument into the recursion. However I think my

[Mesa-dev] [Bug 104836] Missing library link breaks mesa on Debian/ia64

https://bugs.freedesktop.org/show_bug.cgi?id=104836 --- Comment #4 from Jason Duerstock --- Any updates on this? Is there a reason my proposed patch can't be accepted? -- You are receiving this mail because: You are the QA Contact for the

Re: [Mesa-dev] [PATCH 0/4] improve buffer cache and reuse

Hi, On 02.05.2018 21:19, James Xiong wrote: On Wed, 2 May 2018 14:18:21 +0300 Eero Tamminen wrote: [...] You're missing information on: * On which plaform you did the testing (affects variance) * how many test rounds you ran, and * what is your variance > I ran

Re: [Mesa-dev] [ANNOUNCE] mesa 18.1.0-rc2

Hi Dylan, A few small nitpicks: On 27 April 2018 at 22:07, Dylan Baker wrote: > Hi List, > s/List/list/ > Mesa 18.1.0-rc2 is now available. There are 20 nominated patches, and no > queued > or rejected patches. All patches applied cleanly, so no conflicts at all. Yay. >

Re: [Mesa-dev] [PATCH v3] i965: Fix ETC2/EAC GetCompressed* functions on Gen7 GPUs

Hi, On 02.05.2018 20:19, Matt Turner wrote: On Wed, May 2, 2018 at 9:13 AM, Eleni Maria Stea wrote: Gen 7 GPUs store the compressed EAC/ETC2 images in other non-compressed formats that can render. When GetCompressed* functions are called, the pixels are returned in the

Re: [Mesa-dev] [PATCH v2 2/3] mesa: actually support GLSL version overrides in compat profile

On 3 May 2018 at 00:10, Timothy Arceri wrote: > > > On 03/05/18 02:51, Emil Velikov wrote: >> >> On 2 May 2018 at 11:27, Timothy Arceri wrote: >>> >>> --- >>> src/mesa/main/version.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git

[Mesa-dev] [Bug 106187] Vulkan apps run on secondary GPU on multi-GPU system

https://bugs.freedesktop.org/show_bug.cgi?id=106187 --- Comment #10 from Christian König --- Just some technical feedback. (In reply to Bas Nieuwenhuizen from comment #9) > 1) Running on a GPU that is not connected to the display is slower. Arguably > we should

Re: [Mesa-dev] [PATCH v2 7.5/18] intel/compiler: support negate and abs of half float immediates

On Thu, 2018-05-03 at 08:39 +0200, Iago Toral wrote: > On Wed, 2018-05-02 at 17:57 -0700, Jason Ekstrand wrote: > > Reviewed-by: Jason Ekstrand > > > > Have I reviewed everything? Can we land shaderInt16 now? > > Yes, all patches are reviewed now, thanks Jason. > I'll

Re: [Mesa-dev] [PATCH] intel/genxml: recognize 0x, 0o and 0b when setting default value

Nice addition :) Reviewed-by: Lionel Landwerlin On 02/05/18 22:48, Caio Marcelo de Oliveira Filho wrote: Remove the need of converting values that are documented in hexadecimal. This patch would allow writing instead of ---

Re: [Mesa-dev] [PATCH 02/16] ac: enable both RBs on Kaveri

On 2018-05-02 09:11 PM, Marek Olšák wrote: > If you are shader-bound, you won't see any difference. In order to become > RB-bound, you need more work in RBs than shaders. Blending or MSAA might > help add that. Indeed, vblank_mode=0 glxgears -samples 8 shows a significant difference in

[Mesa-dev] [PATCH v4] i965: Fix ETC2/EAC GetCompressed* functions on Gen7 GPUs

Gen 7 GPUs store the compressed EAC/ETC2 images in other non-compressed formats that can render. When GetCompressed* functions are called, the pixels are returned in the non-compressed format that is used for the rendering. With this patch we store both the compressed and non-compressed versions

[Mesa-dev] [PATCH 1/2] mesa: add R10G10B10{A, X}2 to MESA <-> DRI format translations

This patch adds R10G10B10{A,X}2 MESA <-> DRI translation entries in the appropriate places for dri2 functions to accept them. BUG=https://crbug.com/776093 TEST=Compile and deploy mesa+this patch, then playback a VP9 Profile 2 video with sw decoder using crrev.com/c/897894. ---

[Mesa-dev] [PATCH 2/2] i965: add {X, A}BGR2101010 to |intel_image_formats|

This patch adds {X,A}BGR2101010 entries to the list of supported |intel_image_formats|. BUG=https://crbug.com/776093 TEST=Compile and deploy mesa this patch, then playback a VP9 Profile 2 video with sw decoder using crrev.com/c/897894. --- src/mesa/drivers/dri/i965/intel_screen.c | 6 ++ 1

Re: [Mesa-dev] [PATCH v2 7.5/18] intel/compiler: support negate and abs of half float immediates

On Wed, 2018-05-02 at 17:57 -0700, Jason Ekstrand wrote: > Reviewed-by: Jason Ekstrand > > Have I reviewed everything? Can we land shaderInt16 now? Yes, all patches are reviewed now, thanks Jason.I'll send the final set of patches to Jenkins one last time and push them

Re: [Mesa-dev] [PATCH 21/22] i965: Setup glsl uniforms by index rather than name matching

On 18/04/18 00:36, Alejandro Piñeiro wrote: From: Neil Roberts Previously when setting up a uniform it would try to walk the uniform storage slots and find one that matches the name of the given variable. However, each variable already has a location which is an index into