Re: [Mesa-dev] [PATCH 4/4] virgl: work around bad assumptions in virglrenderer

Good Morning, > > One thing, may be. Do you want to add some documentation beside the > > git log message why we do something surprising like replicating out > > the > > buffers and assigning new buffer indices? Just something that allows > > a reader to get an idea why non straight forward

[Mesa-dev] [Bug 108946] High memory usage in Black Mesa

https://bugs.freedesktop.org/show_bug.cgi?id=108946 --- Comment #7 from MGG --- Hello Ian, I see your point about glDeleteShader, but due that the trace includes a game crash, I thinks it is quite possible that the api call is not present because the engine wasn't able to run any resource

[Mesa-dev] [PATCH] radv/xfb: fix counter buffer bounds checks.

From: Dave Airlie If we gave this function 0 counter buffers, we'd still try and access pCounterBuffers[0] as this check was incorrect. Fixes crash with ext_transform_feedback-pipeline-basic-primgen on zink on radv. Fixes: 677b496b6 (radv: fix begin/end transform feedback with 0 counter

Re: [Mesa-dev] Let's talk about -DDEBUG

On 12/12/18 4:13 PM, Dylan Baker wrote: > Quoting Rob Clark (2018-12-12 15:52:47) >> On Wed, Dec 12, 2018 at 6:25 PM Dylan Baker wrote: >>> >>> In the autotools discussion I've come to realize that we also need to talk >>> about >>> the -DDEBUG guard. It seems that there are two different uses,

Re: [Mesa-dev] [RFC PATCH 09/14] anv: Validate the list of BOs from the block pool.

On Wed, Dec 12, 2018 at 7:15 PM Rafael Antognolli < rafael.antogno...@intel.com> wrote: > On Mon, Dec 10, 2018 at 01:49:43PM -0600, Jason Ekstrand wrote: > > On Fri, Dec 7, 2018 at 6:06 PM Rafael Antognolli < > rafael.antogno...@intel.com> > > wrote: > > > > We now have multiple BOs in the

Re: [Mesa-dev] Let's talk about -DDEBUG

On Wed, Dec 12, 2018 at 6:45 PM Marek Olšák wrote: > On Wed, Dec 12, 2018 at 7:35 PM Rob Clark wrote: > >> On Wed, Dec 12, 2018 at 7:14 PM Dylan Baker wrote: >> > >> > Quoting Rob Clark (2018-12-12 15:52:47) >> > > On Wed, Dec 12, 2018 at 6:25 PM Dylan Baker >> wrote: >> > > > >> > > > In the

[Mesa-dev] [PATCH v2 06/10] nir: simplify the loop analysis trip count code a little

Here we create a helper is_supported_terminator_condition() and use that rather than embedding all the trip count code inside a switch. The new helper will also be used in a following patch. --- src/compiler/nir/nir_loop_analyze.c | 176 +++- 1 file changed, 95

[Mesa-dev] [PATCH v2 09/10] nir: pass nir_op to calculate_iterations()

Rather than getting this from the alu instruction this allows us some flexibility. In the following pass we instead pass the inverse op. --- src/compiler/nir/nir_loop_analyze.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git

[Mesa-dev] [PATCH v2 01/10] nir: add guess trip count support to loop analysis

This detects an induction variable used as an array index to guess the trip count of the loop. This enables us to do a partial unroll of the loop, with can eventually result in the loop being eliminated. v2: check if the induction var is used to index more than a single array and if so get

[Mesa-dev] [PATCH v2 05/10] nir: unroll some loops with a variable limit

For some loops can have a single terminator but the exact trip count is still unknown. For example: for (int i = 0; i < imin(x, 4); i++) ... Shader-db results radeonsi (all affected are from Tropico 5): Totals from affected shaders: SGPRS: 200 -> 208 (4.00 %) VGPRS: 164 -> 148 (-9.76

[Mesa-dev] [PATCH v2 02/10] nir: add new partially_unrolled bool to nir_loop

In order to stop continuously partially unrolling the same loop we add the bool partially_unrolled to nir_loop, we add it here rather than in nir_loop_info because nir_loop_info is only set via loop analysis and is intended to be cleared before each analysis. Also nir_loop_info is never cloned.

[Mesa-dev] [PATCH v2 07/10] nir: add helper to return inversion op of a comparision

This will be used to help find the trip count of loops that look like the following: while (a < x && i < 8) { ... i++; } Where the NIR will end up looking something like this: vec1 32 ssa_0 = load_const (0x /* 0.00 */) vec1 32 ssa_1 = load_const (0x0008

[Mesa-dev] [PATCH v2 03/10] nir: add partial loop unrolling support

This adds partial loop unrolling support and makes use of a guessed trip count based on array access. The code is written so that we could use partial unrolling more generally, but for now it's only use when we have guessed the trip count. We use partial unrolling for this guessed trip count

[Mesa-dev] [PATCH v2 08/10] nir: add get_induction_and_limit_vars() helper to loop analysis

This helps make find_trip_count() a little easier to follow but will also be used by a following patch. --- src/compiler/nir/nir_loop_analyze.c | 41 ++--- 1 file changed, 26 insertions(+), 15 deletions(-) diff --git a/src/compiler/nir/nir_loop_analyze.c

[Mesa-dev] [PATCH v2 10/10] nir: find induction/limit vars in iand instructions

This will be used to help find the trip count of loops that look like the following: while (a < x && i < 8) { ... i++; } Where the NIR will end up looking something like this: vec1 32 ssa_0 = load_const (0x /* 0.00 */) vec1 32 ssa_1 = load_const (0x0008

[Mesa-dev] [PATCH v2 04/10] nir: calculate trip count for more loops

This adds support to loop analysis for loops where the induction variable is compared to the result of min(variable, constant). For example: for (int i = 0; i < imin(x, 4); i++) ... We add a new bool to the loop terminator struct in order to differentiate terminators with this exit

[Mesa-dev] V2 More loop unrolling

V2: - When guessing trip count in patch 1 check if the induction var is used in more than a single loop and get the smallest array size if so (Suggested by Jason). - A bunch of reviewed patches have been pushed Some piglit tests: https://patchwork.freedesktop.org/series/53712/

Re: [Mesa-dev] [RFC PATCH 09/14] anv: Validate the list of BOs from the block pool.

On Mon, Dec 10, 2018 at 01:49:43PM -0600, Jason Ekstrand wrote: > On Fri, Dec 7, 2018 at 6:06 PM Rafael Antognolli > wrote: > > We now have multiple BOs in the block pool, but sometimes we still > reference only the first one in some instructions, and use relative > offsets in

Re: [Mesa-dev] Let's talk about -DDEBUG

On Wed, Dec 12, 2018 at 7:35 PM Rob Clark wrote: > On Wed, Dec 12, 2018 at 7:14 PM Dylan Baker wrote: > > > > Quoting Rob Clark (2018-12-12 15:52:47) > > > On Wed, Dec 12, 2018 at 6:25 PM Dylan Baker > wrote: > > > > > > > > In the autotools discussion I've come to realize that we also need >

Re: [Mesa-dev] Let's talk about -DDEBUG

On Wed, Dec 12, 2018 at 7:14 PM Dylan Baker wrote: > > Quoting Rob Clark (2018-12-12 15:52:47) > > On Wed, Dec 12, 2018 at 6:25 PM Dylan Baker wrote: > > > > > > In the autotools discussion I've come to realize that we also need to > > > talk about > > > the -DDEBUG guard. It seems that there

Re: [Mesa-dev] Let's talk about -DDEBUG

Quoting Rob Clark (2018-12-12 15:52:47) > On Wed, Dec 12, 2018 at 6:25 PM Dylan Baker wrote: > > > > In the autotools discussion I've come to realize that we also need to talk > > about > > the -DDEBUG guard. It seems that there are two different uses, and thus two > > different asks about it: >

[Mesa-dev] [Bug 32211] [GLSL] lower_jumps with continue-statements in for-loops prevents loop unrolling

https://bugs.freedesktop.org/show_bug.cgi?id=32211 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [Mesa-dev] Let's talk about -DDEBUG

On Wed, Dec 12, 2018 at 6:25 PM Dylan Baker wrote: > > In the autotools discussion I've come to realize that we also need to talk > about > the -DDEBUG guard. It seems that there are two different uses, and thus two > different asks about it: > > - Nine (and RadeonSI?) use -DDEBUG to hide

[Mesa-dev] Let's talk about -DDEBUG

In the autotools discussion I've come to realize that we also need to talk about the -DDEBUG guard. It seems that there are two different uses, and thus two different asks about it: - Nine (and RadeonSI?) use -DDEBUG to hide generic debugging - NIR and Intel (at least) use -DDEBUG to hide really

Re: [Mesa-dev] last call for autotools

Quoting Axel Davy (2018-12-12 14:31:34) > On 12/12/2018 23:06, Dylan Baker wrote: > > Quoting Marek Ol\u0161k (2018-12-12 13:07:10) > >> On Wed, Dec 12, 2018 at 3:52 PM Rob Clark wrote: > >> > >> On Wed, Dec 12, 2018 at 3:45 PM Marek Ol\u0161k > >> wrote: > >> > > >> > On Wed,

Re: [Mesa-dev] last call for autotools

Quoting Marek Olšák (2018-12-12 14:27:21) > On Wed, Dec 12, 2018 at 5:14 PM Dylan Baker wrote: > > Quoting Marek Olšák (2018-12-12 12:42:01) > > Most assertions and checks are enabled, because NDEBUG is not defined, > but > > DEBUG is not defined either, which is a Mesa-specific

Re: [Mesa-dev] last call for autotools

On 12/12/2018 23:06, Dylan Baker wrote: Quoting Marek Olšák (2018-12-12 13:07:10) On Wed, Dec 12, 2018 at 3:52 PM Rob Clark wrote: On Wed, Dec 12, 2018 at 3:45 PM Marek Olšák wrote: > > On Wed, Dec 12, 2018 at 3:37 PM Rob Clark wrote: >> >> On Wed, Dec 12, 2018 at

Re: [Mesa-dev] last call for autotools

On Wed, Dec 12, 2018 at 5:14 PM Dylan Baker wrote: > Quoting Marek Olšák (2018-12-12 12:42:01) > > Most assertions and checks are enabled, because NDEBUG is not defined, > but > > DEBUG is not defined either, which is a Mesa-specific definition. > > > > The default debug build for autotools is

Re: [Mesa-dev] last call for autotools

Quoting Marek Olšák (2018-12-12 12:42:01) > Most assertions and checks are enabled, because NDEBUG is not defined, but > DEBUG is not defined either, which is a Mesa-specific definition. > > The default debug build for autotools is debugoptimized (-g -O2 -DDEBUG). > meson > changed that behavior

Re: [Mesa-dev] last call for autotools

Quoting Marek Olšák (2018-12-12 13:07:10) > On Wed, Dec 12, 2018 at 3:52 PM Rob Clark wrote: > > On Wed, Dec 12, 2018 at 3:45 PM Marek Olšák wrote: > > > > On Wed, Dec 12, 2018 at 3:37 PM Rob Clark wrote: > >> > >> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen > >>

Re: [Mesa-dev] last call for autotools

On Wed, Dec 12, 2018 at 3:52 PM Rob Clark wrote: > On Wed, Dec 12, 2018 at 3:45 PM Marek Olšák wrote: > > > > On Wed, Dec 12, 2018 at 3:37 PM Rob Clark wrote: > >> > >> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen > >> wrote: > >> > > >> > On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák

Re: [Mesa-dev] last call for autotools

On Wed, Dec 12, 2018 at 3:45 PM Marek Olšák wrote: > > On Wed, Dec 12, 2018 at 3:37 PM Rob Clark wrote: >> >> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen >> wrote: >> > >> > On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák wrote: >> > > >> > > There are 2 issues with meson: >> > > * -DDEBUG

Re: [Mesa-dev] [PATCH 2/2] radv: don't check if format is depth in radv_image_can_enable_hile()

Reviewed-by: Bas Nieuwenhuizen for both. On Wed, Dec 12, 2018 at 2:13 PM Samuel Pitoiset wrote: > > This is always TRUE if htile_size is not 0. > > Signed-off-by: Samuel Pitoiset > --- > src/amd/vulkan/radv_image.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git

Re: [Mesa-dev] last call for autotools

On Wed, Dec 12, 2018 at 3:37 PM Rob Clark wrote: > On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen > wrote: > > > > On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák wrote: > > > > > > There are 2 issues with meson: > > > * -DDEBUG is not present in debugoptimized builds. > > > > Do people expect

Re: [Mesa-dev] last call for autotools

Most assertions and checks are enabled, because NDEBUG is not defined, but DEBUG is not defined either, which is a Mesa-specific definition. The default debug build for autotools is debugoptimized (-g -O2 -DDEBUG). meson changed that behavior by removing -DDEBUG. Autotools doesn't have what meson

Re: [Mesa-dev] last call for autotools

On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen wrote: > > On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák wrote: > > > > There are 2 issues with meson: > > * -DDEBUG is not present in debugoptimized builds. > > Do people expect -DDEBUG for debugoptimized? I would think that debug > optimized

Re: [Mesa-dev] last call for autotools

On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák wrote: > > There are 2 issues with meson: > * -DDEBUG is not present in debugoptimized builds. Do people expect -DDEBUG for debugoptimized? I would think that debug optimized would be an optimized build with debug symbols, but not expensive checks &

Re: [Mesa-dev] last call for autotools

There are 2 issues with meson: * -DDEBUG is not present in debugoptimized builds. * meson ignores CFLAGS with --reconfigure, for example: CFLAGS="-DDEBUG" meson --reconfigure ... doesn't update CFLAGS. Marek On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker wrote: > Meson 0.49.0 has been out for a

Re: [Mesa-dev] [PATCH v2 00/29] nir: Use a 1-bit data type for booleans

This series has been moved to a merge request: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1 Please do all review there. --Jason On Thu, Dec 6, 2018 at 1:45 PM Jason Ekstrand wrote: > This is a v2 of my series to switch NIR over to 1-bit Booleans. The first > version of the

Re: [Mesa-dev] [RFC PATCH 0/5] last call for autotools (meson travis fixes)

On Wed, 12 Dec 2018 at 17:13, Dylan Baker wrote: > > Quoting Emil Velikov (2018-12-12 04:16:51) > > On Wed, 12 Dec 2018 at 07:45, Rhys Kidd wrote: > > > > > > Emil and Dylan, > > > > > > I took a go at addressing the limited number of remaining meson-based > > > travis-ci errors. This series

[Mesa-dev] [Bug 108933] Unreal Tournament (UT99) segfault on opengl init

https://bugs.freedesktop.org/show_bug.cgi?id=108933 --- Comment #14 from i...@yahoo.com --- I'm still puzzled by a number of things related to this bug and the export of "__dynamic_cast". If I rename it to "__dyn_cast_old" in Core.so, the game exits with "undefined __dyn_cast_old". It does so

Re: [Mesa-dev] [PATCH 2/2] Fix typo preventing xxf86vm being used in meson build

Quoting Jon Turney (2018-12-11 07:15:10) > Also add now needed xxf86vm to the dependencies of libGL > > Signed-off-by: Jon Turney > --- > src/glx/meson.build | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/glx/meson.build b/src/glx/meson.build > index

Re: [Mesa-dev] [PATCH] genxml: Consistently use a numeric "MOCS" field

On Wed, Dec 12, 2018 at 11:09 AM Jason Ekstrand wrote: > On Tue, Dec 11, 2018 at 10:31 PM Kenneth Graunke > wrote: > >> When we first started using genxml, we decided to represent MOCS as an >> actual structure, and pack values. However, in many places, it was more >> convenient to use a

Re: [Mesa-dev] [RFC PATCH 0/5] last call for autotools (meson travis fixes)

Quoting Emil Velikov (2018-12-12 04:16:51) > On Wed, 12 Dec 2018 at 07:45, Rhys Kidd wrote: > > > > Emil and Dylan, > > > > I took a go at addressing the limited number of remaining meson-based > > travis-ci errors. This series applies on top of the work Dylan circulated > > yesterday, and which

Re: [Mesa-dev] [PATCH] genxml: Consistently use a numeric "MOCS" field

On Tue, Dec 11, 2018 at 10:31 PM Kenneth Graunke wrote: > When we first started using genxml, we decided to represent MOCS as an > actual structure, and pack values. However, in many places, it was more > convenient to use a numeric value rather than treating it as a struct, > so we added

Re: [Mesa-dev] [RFC PATCH 5/5] meson: libfreedreno depends upon libdrm (for fence support)

Thanks for looking into these. I've gone ahead and added the Fixes and Emil's rb, plus my rb and pushed *this* patch to master. I've pulled all of the others except the "delete me" fixup into my branch (since I'll drop that patch before sending out the v2, that's just to make travis turn around

Re: [Mesa-dev] [PATCH] genxml: Consistently use a numeric "MOCS" field

Reviewed-by: Kristian H. Kristensen On Tue, Dec 11, 2018 at 9:25 PM Jordan Justen wrote: > > Reviewed-by: Jordan Justen > > On 2018-12-11 20:23:06, Kenneth Graunke wrote: > > When we first started using genxml, we decided to represent MOCS as an > > actual structure, and pack values. However,

Re: [Mesa-dev] [PATCH v2 1/6] mesa: wire up InvalidateFramebuffer

Hello, On 12.12.18 16:48, Rob Clark wrote: diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c index 23e49396199..442435655fa 100644 @@ -4695,14 +4754,23 @@ _mesa_InvalidateNamedFramebufferSubData(GLuint framebuffer, invalidate_framebuffer_storage(ctx, fb, numAttachments,

Re: [Mesa-dev] [RFC PATCH 0/5] last call for autotools (meson travis fixes)

On Wed, Dec 12, 2018 at 6:19 AM Emil Velikov wrote: > On Wed, 12 Dec 2018 at 07:45, Rhys Kidd wrote: > > > > Emil and Dylan, > > > > I took a go at addressing the limited number of remaining meson-based > > travis-ci errors. This series applies on top of the work Dylan circulated > > yesterday,

Re: [Mesa-dev] [PATCH v2 5/6] mesa/st: use invalidate_surface() for scissored clears

On Wed, Dec 12, 2018 at 10:54 AM Ilia Mirkin wrote: > > On Wed, Dec 12, 2018 at 10:49 AM Rob Clark wrote: > > > > Now that we have pipe_context::invalidate_surface(), we can also > > use this to hint to driver about scissored clears (which use draw_vbo()). > > This is useful in particular for

Re: [Mesa-dev] [PATCH v2 4/6] mesa/st: wire up Discard{Sub}Framebuffer

On 12/12/2018 08:48 AM, Rob Clark wrote: > Signed-off-by: Rob Clark > --- > src/mesa/state_tracker/st_cb_fbo.c | 39 ++ > 1 file changed, 39 insertions(+) > > diff --git a/src/mesa/state_tracker/st_cb_fbo.c > b/src/mesa/state_tracker/st_cb_fbo.c > index

Re: [Mesa-dev] [PATCH v2 5/6] mesa/st: use invalidate_surface() for scissored clears

On Wed, Dec 12, 2018 at 10:49 AM Rob Clark wrote: > > Now that we have pipe_context::invalidate_surface(), we can also > use this to hint to driver about scissored clears (which use draw_vbo()). > This is useful in particular for tilers because the driver can avoid > bringing (some) tiles back

[Mesa-dev] [PATCH v2 5/6] mesa/st: use invalidate_surface() for scissored clears

Now that we have pipe_context::invalidate_surface(), we can also use this to hint to driver about scissored clears (which use draw_vbo()). This is useful in particular for tilers because the driver can avoid bringing (some) tiles back into the tile buffer from system memory. Signed-off-by: Rob

[Mesa-dev] [PATCH v2 1/6] mesa: wire up InvalidateFramebuffer

And before someone actually starts implementing DiscardFramebuffer() lets rework the interface to something that is actually usable. Signed-off-by: Rob Clark Reviewed-by: Ian Romanick --- src/mesa/main/dd.h | 5 ++- src/mesa/main/fbobject.c | 77 +---

[Mesa-dev] [PATCH v2 2/6] mesa: wire up InvalidateSubFramebuffer

Signed-off-by: Rob Clark Reviewed-by: Ian Romanick --- src/mesa/main/dd.h | 3 +++ src/mesa/main/fbobject.c | 43 +++- 2 files changed, 45 insertions(+), 1 deletion(-) diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h index 1214eeaa474..c7112677223

[Mesa-dev] [PATCH v2 3/6] gallium: add pipe->invalidate_surface()

A new API to implement glInvalidateFramebuffer() and friends. It is similar to invalidate_resource() but can be used to invalidate a specific layer/level, so it is suitable to use for user FBOs in addition to window system framebuffer. Signed-off-by: Rob Clark ---

[Mesa-dev] [PATCH v2 6/6] freedreno: support invalidate_surface

Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/a6xx/fd6_gmem.c | 3 +- .../drivers/freedreno/freedreno_batch.c | 1 + .../drivers/freedreno/freedreno_batch.h | 8 +- .../drivers/freedreno/freedreno_draw.c| 99 ---

[Mesa-dev] [PATCH v2 4/6] mesa/st: wire up Discard{Sub}Framebuffer

Signed-off-by: Rob Clark --- src/mesa/state_tracker/st_cb_fbo.c | 39 ++ 1 file changed, 39 insertions(+) diff --git a/src/mesa/state_tracker/st_cb_fbo.c b/src/mesa/state_tracker/st_cb_fbo.c index 8901a8680ef..6f46ca03f3c 100644 ---

[Mesa-dev] [Bug 108900] Non-recoverable GPU hangs with GfxBench v5 Aztec Ruins Vulkan test

https://bugs.freedesktop.org/show_bug.cgi?id=108900 keramidasc...@gmail.com changed: What|Removed |Added CC||keramidasc...@gmail.com --

[Mesa-dev] [PATCH] etnaviv: drop redundant ctx function parameter

There is no need to have an extra ctx paramter as all the other parameters carry all the needed information. Signed-off-by: Christian Gmeiner --- src/gallium/drivers/etnaviv/etnaviv_shader.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git

[Mesa-dev] [Bug 108996] Leaks buffer when closing wayland window

https://bugs.freedesktop.org/show_bug.cgi?id=108996 Sjoerd Simons changed: What|Removed |Added QA Contact|mesa-dev@lists.freedesktop. |etnaviv@lists.freedesktop.o

[Mesa-dev] [Bug 109039] [CLOVER][CLANG-SVN] build failure CodeGenOptions.h: No such file or directory

https://bugs.freedesktop.org/show_bug.cgi?id=109039 Yurii Kolesnykov changed: What|Removed |Added Keywords||patch -- You are receiving this

[Mesa-dev] [PATCH 1/2] radv: check if addrlib enabled HTILE in radv_image_can_enable_htile()

When hile_size is 0, we can't enable HTILE. This doesn't change anything, except not calling radv_image_alloc_htile(). Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_image.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/amd/vulkan/radv_image.c

[Mesa-dev] [PATCH 2/2] radv: don't check if format is depth in radv_image_can_enable_hile()

This is always TRUE if htile_size is not 0. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_image.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c index b1044639fdf..9b7564985a6 100644 --- a/src/amd/vulkan/radv_image.c +++

[Mesa-dev] [Bug 109021] Kaveri no fix perfomance

https://bugs.freedesktop.org/show_bug.cgi?id=109021 --- Comment #4 from Dmitry --- I also think. But I measured the FPS before and after the Mesa and kernel update. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the

[Mesa-dev] [Bug 109039] [CLOVER][CLANG-SVN] build failure CodeGenOptions.h: No such file or directory

https://bugs.freedesktop.org/show_bug.cgi?id=109039 Yurii Kolesnykov changed: What|Removed |Added CC||r...@yurikoles.com --- Comment #1

[Mesa-dev] [Bug 109021] Kaveri no fix perfomance

https://bugs.freedesktop.org/show_bug.cgi?id=109021 --- Comment #3 from Samuel Pitoiset --- This code is shared by RadeonSI and RADV, so I assume that commit should also help RADV. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the

[Mesa-dev] [Bug 109021] Kaveri no fix perfomance

https://bugs.freedesktop.org/show_bug.cgi?id=109021 --- Comment #2 from Dmitry --- Have 7850К earlier, it was stated the wrong number of render backends. https://www.phoronix.com/scan.php?page=news_item=AMD-Kaveri-Mesa-18.2-Boost This should have been fixed in the new kernel version and Mesa

[Mesa-dev] [Bug 109021] Kaveri no fix perfomance

https://bugs.freedesktop.org/show_bug.cgi?id=109021 --- Comment #1 from Samuel Pitoiset --- I'm sorry but I don't understand what your report means. What are you talking about? And what fix? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for

Re: [Mesa-dev] [RFC PATCH 0/5] last call for autotools (meson travis fixes)

On Wed, 12 Dec 2018 at 07:45, Rhys Kidd wrote: > > Emil and Dylan, > > I took a go at addressing the limited number of remaining meson-based > travis-ci errors. This series applies on top of the work Dylan circulated > yesterday, and which can be seen here: > > > Could you help me debug my WIP

Re: [Mesa-dev] [PATCH 41/59] intel/compiler: split is_partial_write() into two variants

On Wed, Dec 12, 2018 at 09:48:20AM +0100, Iago Toral wrote: > On Tue, 2018-12-11 at 18:59 +0200, Pohjolainen, Topi wrote: > > On Fri, Dec 07, 2018 at 03:30:11PM +0200, Pohjolainen, Topi wrote: > > > On Tue, Dec 04, 2018 at 08:17:05AM +0100, Iago Toral Quiroga wrote: > > > > This function is used

Re: [Mesa-dev] [RFC PATCH 5/5] meson: libfreedreno depends upon libdrm (for fence support)

On Wed, 12 Dec 2018 at 07:45, Rhys Kidd wrote: > > Error message building freedreno Gallium driver with meson: > > ../src/gallium/drivers/freedreno/freedreno_fence.c:27:21: fatal error: > libsync.h: No such file or directory >\#include > This is a good fix regardless of the rest. Fixes:

Re: [Mesa-dev] [RFC PATCH 0/5] last call for autotools (meson travis fixes)

On Wed, 12 Dec 2018 at 08:44, Samuel Pitoiset wrote: > > What's the point of maintaining Travis? Shouldn't we just drop it in > favour of Gitlab CI? IIRC, Igalia worked on it. > Personally I'm the more the merrier kind of person. It allows wider (and crazier) testing catching more corner-cases.

[Mesa-dev] [Bug 109039] [CLOVER][CLANG-SVN] build failure CodeGenOptions.h: No such file or directory

https://bugs.freedesktop.org/show_bug.cgi?id=109039 Bug ID: 109039 Summary: [CLOVER][CLANG-SVN] build failure CodeGenOptions.h: No such file or directory Product: Mesa Version: git Hardware: x86-64 (AMD64)

[Mesa-dev] [Bug 108967] DRM : eglCreatePbufferSurface failed with error EGL_BAD_MATCH

https://bugs.freedesktop.org/show_bug.cgi?id=108967 --- Comment #6 from Tapani Pälli --- (In reply to Vishwanath Chandapur from comment #5) > As of now we are still getting same error "eglCreatePbufferSurface failed > with error EGL_BAD_MATCH" > > And we are using "EGL_KHR_surfaceless_context"

[Mesa-dev] [Bug 109021] Kaveri no fix perfomance

https://bugs.freedesktop.org/show_bug.cgi?id=109021 Michel Dänzer changed: What|Removed |Added QA Contact||mesa-dev@lists.freedesktop.

Re: [Mesa-dev] [PATCH 4/4] virgl: work around bad assumptions in virglrenderer

On Wed, 2018-12-12 at 06:18 +0100, Mathias Fröhlich wrote: > Erik, > > On Tuesday, 11 December 2018 15:29:49 CET Erik Faye-Lund wrote: > > On Tue, 2018-12-11 at 15:26 +0100, Erik Faye-Lund wrote: > > > Virglrenderer does the wrong thing when given an instance > > > divisor; > > > it tries to use

[Mesa-dev] [Bug 108967] DRM : eglCreatePbufferSurface failed with error EGL_BAD_MATCH

https://bugs.freedesktop.org/show_bug.cgi?id=108967 --- Comment #5 from Vishwanath Chandapur --- As of now we are still getting same error "eglCreatePbufferSurface failed with error EGL_BAD_MATCH" And we are using "EGL_KHR_surfaceless_context" API .Is there any way we can check in mesa is using

Re: [Mesa-dev] [PATCH] intel/blorp: Assert that we don't re-layout a compressed surface

Reviewed-by: Lionel Landwerlin On 12/12/2018 03:35, Jason Ekstrand wrote: ping On Thu, Apr 5, 2018 at 12:50 PM Jason Ekstrand > wrote: ---  src/intel/blorp/blorp_blit.c | 3 +++  1 file changed, 3 insertions(+) diff --git

[Mesa-dev] [Bug 108967] DRM : eglCreatePbufferSurface failed with error EGL_BAD_MATCH

https://bugs.freedesktop.org/show_bug.cgi?id=108967 --- Comment #4 from Tapani Pälli --- (In reply to Vishwanath Chandapur from comment #3) > I have enabled surfaceless as you mentioned but got same ERROR. > > configure: > prefix: /usr > exec_prefix: /usr >

Re: [Mesa-dev] [PATCH 08/15] anv/android: support import/export of AHardwareBuffer objects

On 12/12/2018 08:34, Tapani Pälli wrote: On 12/11/18 3:05 PM, Lionel Landwerlin wrote: On 27/11/2018 10:53, Tapani Pälli wrote: v2: add support for non-image buffers (AHARDWAREBUFFER_FORMAT_BLOB) v3: properly handle usage bits when creating from image v4: refactor, code cleanup (Jason) v5:

Re: [Mesa-dev] [PATCH v2] docs: Document GitLab merge request process (email alternative)

On Tue, 2018-12-11 at 18:06 -0600, Jason Ekstrand wrote: > Ping? > > I see about 5 acks/reviews, 3 of which are from Intel which doesn't > exactly seem like overwhelming consensus. However, we also haven't > had any debate in a while. Oh, absolutely, I'm very much a supporter of tring this out!

Re: [Mesa-dev] [PATCH v3] mesa: Fix GLES2 OES float texture framebuffer rendering.

On Wed, 2018-12-12 at 09:27 +0200, Tapani Pälli wrote: > > On 12/12/18 8:42 AM, Tapani Pälli wrote: > > > > On 12/12/18 5:05 AM, Nick Kreeger wrote: > > > This change enables GLES2 to render float/half-float textures to > > > a > > > framebuffer when the appropriate OES extensions are available.

[Mesa-dev] [Bug 108967] DRM : eglCreatePbufferSurface failed with error EGL_BAD_MATCH

https://bugs.freedesktop.org/show_bug.cgi?id=108967 --- Comment #3 from Vishwanath Chandapur --- I have enabled surfaceless as you mentioned but got same ERROR. configure: prefix: /usr exec_prefix: /usr libdir: /usr/lib includedir:

Re: [Mesa-dev] [RFC PATCH 0/5] last call for autotools (meson travis fixes)

Am Mi., 12. Dez. 2018 um 09:44 Uhr schrieb Samuel Pitoiset : > > What's the point of maintaining Travis? Shouldn't we just drop it in > favour of Gitlab CI? IIRC, Igalia worked on it. > Until Gitlab CI is ready for public use I like the idea that my wip mesa branches @github run through Travis

Re: [Mesa-dev] [PATCH] mesa: ES2 glReadPixels support for OES float extensions.

On 12/12/18 7:10 AM, Nick Kreeger wrote: The OES extensions for float/half-float allow glReadPixels to read GL_RGBA values as GL_FLOAT for both floats and half-floats. This patch ensures that ES2 context versions allows this if at least one of the extensions is present. Reading the extension

Re: [Mesa-dev] [PATCH 41/59] intel/compiler: split is_partial_write() into two variants

On Tue, 2018-12-11 at 18:59 +0200, Pohjolainen, Topi wrote: > On Fri, Dec 07, 2018 at 03:30:11PM +0200, Pohjolainen, Topi wrote: > > On Tue, Dec 04, 2018 at 08:17:05AM +0100, Iago Toral Quiroga wrote: > > > This function is used in two different scenarios that for 32-bit > > > instructions are the

Re: [Mesa-dev] [RFC PATCH 0/5] last call for autotools (meson travis fixes)

What's the point of maintaining Travis? Shouldn't we just drop it in favour of Gitlab CI? IIRC, Igalia worked on it. On 12/12/18 8:45 AM, Rhys Kidd wrote: Emil and Dylan, I took a go at addressing the limited number of remaining meson-based travis-ci errors. This series applies on top of the

Re: [Mesa-dev] [PATCH v2] docs: Document GitLab merge request process (email alternative)

Personally, I will continue to use the list, at least for a simplicity point of view. I'm not sure if using a new tool will improve quality and code review process. Though, if the majority reports that is really nice to use, I will probably change my mind. Not a strong reject. On 12/6/18

Re: [Mesa-dev] [PATCH 08/15] anv/android: support import/export of AHardwareBuffer objects

On 12/11/18 3:05 PM, Lionel Landwerlin wrote: On 27/11/2018 10:53, Tapani Pälli wrote: v2: add support for non-image buffers (AHARDWAREBUFFER_FORMAT_BLOB) v3: properly handle usage bits when creating from image v4: refactor, code cleanup (Jason) v5: rebase to b43f955037c changes,