On 09/12/2017 11:37 AM, Christian König wrote:
Am 12.09.2017 um 17:32 schrieb Leo Liu:
On 09/12/2017 11:23 AM, Christian König wrote:
I don't think this is correct. A long long time ago I've came up
with this because the firmware didn't liked what you proposed below.
Since this change only
Am 12.09.2017 um 17:32 schrieb Leo Liu:
On 09/12/2017 11:23 AM, Christian König wrote:
I don't think this is correct. A long long time ago I've came up with
this because the firmware didn't liked what you proposed below.
Since this change only affects 720p video, so I did quite a bit tests
On 09/12/2017 11:23 AM, Christian König wrote:
I don't think this is correct. A long long time ago I've came up with
this because the firmware didn't liked what you proposed below.
Since this change only affects 720p video, so I did quite a bit tests on
720p video dec/enc, and haven't see any
On Tue, Sep 12, 2017 at 2:40 AM, Marathe, Yogesh
wrote:
> Hi Jason,
>
>
>
> On the asserts you’ve mentioned below, I assume we need to add them after
> ‘bufmgr->num_buckets++’ in add_bucket() as num_buckets could be 0 initially.
>
Yes, because otherwise bucket_for_size
Am Dienstag, den 12.09.2017, 12:26 +0100 schrieb Emil Velikov:
> On 12 September 2017 at 11:17, Gert Wollny
> wrote:
> >
> >
> > Is there a docker image available that resembles the travis-ci
> > build environment as it is set up in mesa/.travis.yml (i.e.
> > Ubuntu/Trusty
Reviewed-by: Emil Velikov
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
I don't think this is correct. A long long time ago I've came up with
this because the firmware didn't liked what you proposed below.
Instead we should rather fix the scaler to use the original width/height
of the video buffer and not the adjusted width/height of the resources.
Regards,
On Tue, 2017-09-12 at 16:08 +0100, Eric Engestrom wrote:
> On Wednesday, 2017-09-06 17:25:29 +0100, Emil Velikov wrote:
> > I'm not that much of an expert on things XCB, so perhaps a silly question.
> > Isn't the presence checked with the code just above the removed hunk?
> > Namely:
> >
> >
Signed-off-by: Eric Engestrom
---
src/amd/vulkan/radv_wsi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index aa44b7d78a..8a551c48bb 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
On Wednesday, 2017-09-06 17:25:29 +0100, Emil Velikov wrote:
> On 6 September 2017 at 17:17, Adam Jackson wrote:
> > On Fri, 2017-09-01 at 15:04 +0100, Eric Engestrom wrote:
> >> These fields were added in 2d94601582 but never used; hasPresent was
> >> never set, while the other
On 12 September 2017 at 15:38, Eric Engestrom wrote:
> Support for external egl drivers was dropped a few years ago.
>
> Fixes: 209360bbb91bb10346eb "egl/main: drop support for external egl drivers"
> Signed-off-by: Eric Engestrom
Thanks!
The function is only called from one place, which is hidden behind
the same `#ifdef DEBUG`.
Fixes: ca73c3358c91434e68ab "glsl: Mark functions static"
Signed-off-by: Eric Engestrom
---
src/compiler/glsl/ir_validate.cpp | 2 ++
1 file changed, 2 insertions(+)
diff
Support for external egl drivers was dropped a few years ago.
Fixes: 209360bbb91bb10346eb "egl/main: drop support for external egl drivers"
Signed-off-by: Eric Engestrom
---
docs/egl.html | 21 -
1 file changed, 21 deletions(-)
diff --git
On 09/12/2017 10:24 AM, Emil Velikov wrote:
Hi Leo,
On 12 September 2017 at 14:56, Leo Liu wrote:
In code:
template.height = align(tmpl->height / array_size,
VL_MACROBLOCK_HEIGHT);
...
template.height *= array_size;
It turns out the height will
https://bugs.freedesktop.org/show_bug.cgi?id=102665
--- Comment #3 from Gert Wollny ---
@Vinson: on Travis with the exact same version of g++ you reported (gcc (Ubuntu
4.8.4-2ubuntu1~14.04.3) 4.8.4 [1] the build runs through without modifying the
source (I had to enable
Hi Leo,
On 12 September 2017 at 14:56, Leo Liu wrote:
> In code:
> template.height = align(tmpl->height / array_size,
> VL_MACROBLOCK_HEIGHT);
> ...
> template.height *= array_size;
>
> It turns out the height will be aligned with 2*VL_MACROBLOCK_HEIGHT.
In code:
template.height = align(tmpl->height / array_size,
VL_MACROBLOCK_HEIGHT);
...
template.height *= array_size;
It turns out the height will be aligned with 2*VL_MACROBLOCK_HEIGHT.
The problematic case for example is when VA-API postproc scaling with
blit between
Signed-off-by: Eric Engestrom
---
src/gallium/drivers/swr/rasterizer/memory/StoreTile.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/memory/StoreTile.h
Commit b96313c0e1289b removed BRW_NEW_BLORP for a bunch of SURFACE_STATE
setup code, including render targets, on the basis that blorp invalidates
binding tables but not surface states, however, at least on Broadwell,
this seems to be causing a regression in a CTS test that seems related
to render
Reviewed-by: Marek Olšák
Marek
On Mon, Sep 11, 2017 at 3:37 PM, Ilia Mirkin wrote:
> It's obviously misformed, and it's triggering on
>
> dEQP-GLES31.functional.program_interface_query.program_input.type.separable_geometry.int
>
> and a few related
Reviewed-by: Marek Olšák
Marek
On Tue, Sep 12, 2017 at 12:35 PM, Samuel Pitoiset
wrote:
> This will allow us to use it from radv.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/common/ac_debug.c | 76
On 12 September 2017 at 11:17, Gert Wollny wrote:
>
>> > This doesn't seem right. GALLIUM_COMMON_LIB_DEPS already has
>> > $(LIBUNWIND_LIBS) so this change should not be needed.
>>
>> I already started looking at this, but haven't been able to figure
>> out why in this
The macro was only used a few times; let's use it everywhere,
simplifying the code.
I also uniformised the use of curly brackets by adding them around
all uses of the macro, removed a few unnecessary `else` after `return`,
and turned a ternary op into an `if`.
Signed-off-by: Eric Engestrom
https://bugs.freedesktop.org/show_bug.cgi?id=102665
--- Comment #2 from Emil Velikov ---
One option is to add space between the two >> - it's compatible with older C++
standards and part of Mesa already uses it.
Alternatively, move '&' one character to the right (again
On 12 September 2017 at 11:11, Tapani Pälli wrote:
> Fixes: d083bc1c4b ("anv: wire up vk_errorf macro to do debug reporting")
> Signed-off-by: Tapani Pälli
FWIW
Reviewed-by: Emil Velikov
-Emil
Useful to know which debug/perftest options were enabled when
a hang report is generated.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_debug.c | 25 +
src/amd/vulkan/radv_device.c | 14 ++
src/amd/vulkan/radv_private.h
Copied from dd_dump_dmesg().
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_debug.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/amd/vulkan/radv_debug.c b/src/amd/vulkan/radv_debug.c
index 741bf76f15..106c6e4f64 100644
---
Might be useful for checking if all descriptors are sets by
the application.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_debug.c | 181
1 file changed, 181 insertions(+)
diff --git a/src/amd/vulkan/radv_debug.c
This might be very useful in order to figure out where a shader
is stucked. This uses UMR to detect which instruction is executing
bad things.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_debug.c | 166
1 file
To dump some status MMIO registers when a hang is detected.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_radeon_winsys.h | 3 +++
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c | 11 +++
2 files changed, 14 insertions(+)
diff --git
Might report some useful information to help figuring out where
does the hang happened.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_debug.c | 57 +
1 file changed, 57 insertions(+)
diff --git
Only the disassembly is currently dumped.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_debug.c | 78 ++---
1 file changed, 73 insertions(+), 5 deletions(-)
diff --git a/src/amd/vulkan/radv_debug.c
To dump them when a hang is detected.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 32
src/amd/vulkan/radv_debug.c | 3 +++
2 files changed, 35 insertions(+)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_debug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/vulkan/radv_debug.c b/src/amd/vulkan/radv_debug.c
index fe9d9cfdba..4abdb6489e 100644
--- a/src/amd/vulkan/radv_debug.c
+++
This will allow us to use it from radv.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_debug.c | 76 ++
src/amd/common/ac_debug.h | 18 +++
src/gallium/drivers/radeonsi/si_debug.c | 96
When a GPU hang is detected in radv_gpu_hang_occured() we know
which command buffer is faulty but the bound pipelines might
have been updated during the execution.
The pointers to the radv_pipeline objects are emitted just
after the second trace ID, that way it would be easy to dump
the active
To share common code after every draw/compute calls.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c
Hi,
Currently, it's not easy to debug a GPU hang with radv because only a
trace file is generated (cf. RADV_TRACE_FILE). That file contains all
packets and commands emitted into the IB, that's useful but definitely
not enough. For example, the active shaders at the moment of the hang
are not
To improve GPU hangs detection when shaders are stucked.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 15 +++
src/amd/vulkan/radv_debug.h | 1 +
src/amd/vulkan/radv_device.c | 1 +
3 files changed, 17 insertions(+)
diff
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_debug.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/amd/vulkan/radv_debug.c b/src/amd/vulkan/radv_debug.c
index d52ba5d86d..052daaef2f 100644
--- a/src/amd/vulkan/radv_debug.c
+++
To dump the shader stats when a hang is detected.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 64 +-
src/amd/vulkan/radv_shader.c | 70 ++
On 12 September 2017 at 11:11, Tapani Pälli wrote:
> Fixes: d083bc1c4b ("anv: wire up vk_errorf macro to do debug reporting")
> Signed-off-by: Tapani Pälli
Reviewed-by: Daniel Stone
> > This doesn't seem right. GALLIUM_COMMON_LIB_DEPS already has
> > $(LIBUNWIND_LIBS) so this change should not be needed.
>
> I already started looking at this, but haven't been able to figure
> out why in this specific configuration GALLIUM_COMMON_LIB_DEPS seems
> to be empty, or at least it
Fixes: d083bc1c4b ("anv: wire up vk_errorf macro to do debug reporting")
Signed-off-by: Tapani Pälli
---
src/intel/vulkan/anv_private.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
Am Dienstag, den 12.09.2017, 09:56 +0300 schrieb Vadim Girlin:
> On 09/11/2017 07:09 PM, Emil Velikov wrote:
> Anyway, if num_arrays is 0 there, I suspect it can be a result of
> some other issue. At the very least it looks like a potential
> performance problem, because in that case we assume
Hi Jason,
On the asserts you’ve mentioned below, I assume we need to add them after
‘bufmgr->num_buckets++’ in add_bucket() as num_buckets could be 0 initially.
Another clarification on ~1%, we meant approx. 1% there, that’s an improvement
we saw in 3Dmark total not a degradation, we’ll
https://bugs.freedesktop.org/show_bug.cgi?id=102564
--- Comment #4 from Alex Granni ---
Sorry, I didn't mention that GPU Caps Viewer is 32-bit even if running on
64-bit Windows so it goes in \windows\syswow64 on a 64-bit Windows. The way I
get it to use Mesa is by copying
On 12/09/17 16:55, Jordan Justen wrote:
On 2017-09-11 21:44:32, Timothy Arceri wrote:
On 12/09/17 14:23, Ian Romanick wrote:
On 09/08/2017 01:59 AM, Kenneth Graunke wrote:
We shouldn't use SPIR-V for the shader cache.
The compilation process for GLSL is: GLSL -> GLSL IR -> NIR -> i965 IRs.
On 2017-09-10 17:15:48, Timothy Arceri wrote:
> Ccing list.
>
> On 11/09/17 09:50, Timothy Arceri wrote:
> > Hi Daniel,
> >
> > Here is the code that does the caching of tgsi in Gallium.
> >
> > https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_shader_cache.c
> >
> >
> >
On Tue, 2017-09-12 at 00:03 -0700, Kenneth Graunke wrote:
> On Monday, September 11, 2017 11:15:05 PM PDT Iago Toral Quiroga
> wrote:
> > This was a bugfix to the spec addressed in OpenGL 4.5 and there is
> > a CTS test to check this.
> >
> > Fixes:
> >
On Monday, September 11, 2017 11:15:05 PM PDT Iago Toral Quiroga wrote:
> This was a bugfix to the spec addressed in OpenGL 4.5 and there is
> a CTS test to check this.
>
> Fixes:
> KHR-GL45.shader_atomic_counters.negative-unsized-array
> ---
> src/compiler/glsl/ast_to_hir.cpp | 11 +++
>
On 09/11/2017 07:09 PM, Emil Velikov wrote:
On 11 September 2017 at 15:39, Gert Wollny wrote:
The assert checks whether pshader->num_arrays != 0, but the code
after the assert actually branches based on the same check.
Removing this assert fixes:
piglit
On 2017-09-11 21:44:32, Timothy Arceri wrote:
> On 12/09/17 14:23, Ian Romanick wrote:
> > On 09/08/2017 01:59 AM, Kenneth Graunke wrote:
> >>
> >> We shouldn't use SPIR-V for the shader cache.
> >>
> >> The compilation process for GLSL is: GLSL -> GLSL IR -> NIR -> i965 IRs.
> >> Storing the
On Monday, September 11, 2017 9:23:05 PM PDT Ian Romanick wrote:
> On 09/08/2017 01:59 AM, Kenneth Graunke wrote:
> > On Thursday, September 7, 2017 4:26:04 PM PDT Jordan Justen wrote:
> >> On 2017-09-06 14:12:41, Daniel Schürmann wrote:
> >>> Hello together!
> >>> Recently, we had a small
This was a bugfix to the spec addressed in OpenGL 4.5 and there is
a CTS test to check this.
Fixes:
KHR-GL45.shader_atomic_counters.negative-unsized-array
---
src/compiler/glsl/ast_to_hir.cpp | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/compiler/glsl/ast_to_hir.cpp
101 - 155 of 155 matches
Mail list logo