Hi,
> -Original Message-
> Hi,
>
> On 09.06.2017 09:21, Marathe, Yogesh wrote:
> > I’m looking forward to set this brw->disable_throttling to true, I’m
> > actually observing adverse effect on performance benchmarks after I
> > force set that to true. What’s the expectation from
This fixes also the crashes seen on Android;
Tested-by: Tapani Pälli
On 06/10/2017 12:11 AM, Kenneth Graunke wrote:
The resolve code looks at the current color draw buffers. These are not
valid until intel_prepare_render() is called. You can end up with one
color
Ugh... Yeah, this is probably needed. I've got another patch in my tree
(I'll probably send that series tomorrow) which moves all of the resolve
stuff back to brw_draw.c and not intel_update_state.
Reviewed-by: Jason Ekstrand
On Fri, Jun 9, 2017 at 2:11 PM, Kenneth
On 10/06/17 12:43 AM, Aaron Watry wrote:
> On Wed, Jun 7, 2017 at 11:12 PM, Aaron Watry wrote:
>> On Wed, Jun 7, 2017 at 9:15 PM, Michel Dänzer wrote:
>>> On 08/06/17 03:42 AM, Marek Olšák wrote:
On Wed, Jun 7, 2017 at 4:10 PM, Aaron Watry
On 12/06/17 10:27, Dave Airlie wrote:
On 12 June 2017 at 10:04, Timothy Arceri wrote:
On 12/06/17 09:47, Dave Airlie wrote:
From: Dave Airlie
The max_array_access field applies to the first dimension, which means
we only want to set it for the 1D
On Saturday, June 3, 2017 11:11:39 AM PDT Thomas Helland wrote:
[snip]
> @@ -87,10 +102,18 @@ util_dynarray_trim(struct util_dynarray *buf)
> {
> if (buf->size != buf->capacity) {
>if (buf->size) {
> - buf->data = realloc(buf->data, buf->size);
> + if (buf->mem_ctx) {
On 12 June 2017 at 10:04, Timothy Arceri wrote:
> On 12/06/17 09:47, Dave Airlie wrote:
>>
>> From: Dave Airlie
>>
>> The max_array_access field applies to the first dimension, which means
>> we only want to set it for the 1D clip dist arrays.
>>
>>
On 12/06/17 09:47, Dave Airlie wrote:
From: Dave Airlie
The max_array_access field applies to the first dimension, which means
we only want to set it for the 1D clip dist arrays.
This fixes an ir_validate assert seen with
KHR-GL44.cull_distance.functional
on nouveau and
From: Dave Airlie
The max_array_access field applies to the first dimension, which means
we only want to set it for the 1D clip dist arrays.
This fixes an ir_validate assert seen with
KHR-GL44.cull_distance.functional
on nouveau and radeon with debug builds.
Signed-off-by:
Signed-off-by: Eric Engestrom
---
src/egl/drivers/dri2/platform_android.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
index 7a73419d14..629ee593d0 100644
---
This is completely untested, as I don't have access to an Android
test device, which is the only platform that can benefit from this
improvement so far.
Can someone run dEQP-EGL.functional.swap_buffers_with_damage.*
on Android for me?
Cheers,
Eric
---
Eric Engestrom (2):
egl: improve
Let's (try to) set damages before swapping buffers.
Signed-off-by: Eric Engestrom
---
src/egl/drivers/dri2/egl_dri2_fallbacks.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/egl/drivers/dri2/egl_dri2_fallbacks.h
b/src/egl/drivers/dri2/egl_dri2_fallbacks.h
index
On Sun, Jun 11, 2017 at 8:25 PM, Henri Verbeet wrote:
> On 7 June 2017 at 21:54, Marek Olšák wrote:
>> On Wed, Jun 7, 2017 at 2:07 AM, Marek Olšák wrote:
>>> On Wed, Jun 7, 2017 at 12:21 AM, Samuel Li wrote:
@@
fixes missrendering in TombRaider
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
fixes
KHR-GL44.gpu_shader5.precise_qualifier
KHR-GL45.gpu_shader5.precise_qualifier
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 14 ++
1 file changed, 14 insertions(+)
diff --git
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index 5c09fed05c..6835c4fa8c 100644
---
Only implemented for glsl->tgsi. Other converters just set precise to 0.
Signed-off-by: Karol Herbst
---
src/gallium/auxiliary/tgsi/tgsi_build.c | 3 +++
src/gallium/auxiliary/tgsi/tgsi_ureg.c| 14 +++---
src/gallium/auxiliary/tgsi/tgsi_ureg.h|
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index
Signed-off-by: Karol Herbst
---
src/gallium/auxiliary/tgsi/tgsi_dump.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_dump.c
b/src/gallium/auxiliary/tgsi/tgsi_dump.c
index f6eba7424b..b58e64511c 100644
---
Signed-off-by: Karol Herbst
---
src/gallium/auxiliary/tgsi/tgsi_build.c| 1 +
src/gallium/include/pipe/p_shader_tokens.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_build.c
all subexpression inside an ir_assignment needs to be tagged as precise.
Signed-off-by: Karol Herbst
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 80 --
1 file changed, 65 insertions(+), 15 deletions(-)
diff --git
Signed-off-by: Karol Herbst
---
src/gallium/auxiliary/tgsi/tgsi_text.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c
b/src/gallium/auxiliary/tgsi/tgsi_text.c
index 93a05568f4..c5fcb3283d 100644
Running Tomb Raider on Nouveau I found some flicker caused by ignoring precise
modifiers on variables inside Nouveau.
This series add precise/invariant handling to TGSI, which can be then used by
drivers to disable certain unsafe optimisations which may otherwise alter
calculations, which depend
On 7 June 2017 at 21:54, Marek Olšák wrote:
> On Wed, Jun 7, 2017 at 2:07 AM, Marek Olšák wrote:
>> On Wed, Jun 7, 2017 at 12:21 AM, Samuel Li wrote:
>>> @@ -790,6 +790,15 @@ static const char* r600_get_device_vendor(struct
>>>
Hello Marek,
thanks for chiming in.
Am Sonntag, den 11.06.2017, 16:15 +0200 schrieb Marek Olšák:
> Also, I don't know if people will like that it uses STL. I personally
> have no issue with that as long as it doesn't break apps (e.g. the
> STL shipped with apps should be the same as the STL
This series aims to fix hundreds of missing initializer warnings in generated
header files
when compiling with -Wextra
V1: Fix the old fashioned way by adding 0s where needed
V2: switch to designated initializers (Emil), didnt send
V3: add some layout so its easier to read and create a new
Fix missing initializer warning in egd_tables.h by adding appropriate
designated initializers in egd_tables.py
---
src/gallium/drivers/r600/egd_tables.py | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/r600/egd_tables.py
Fix missing initializer warning in vk_format_table.h by changing to a default
initializer in vk_format_table.py
and correct the autogenerated from message
---
src/amd/vulkan/vk_format_table.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Fix missing initializer warning in sid_tables.h by adding appropriate
designated initializers in sid_tables.py
---
src/amd/common/sid_tables.py | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/amd/common/sid_tables.py b/src/amd/common/sid_tables.py
index
https://bugs.freedesktop.org/show_bug.cgi?id=101334
--- Comment #15 from John ---
Created attachment 131879
--> https://bugs.freedesktop.org/attachment.cgi?id=131879=edit
trace
ooops
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are
https://bugs.freedesktop.org/show_bug.cgi?id=101334
--- Comment #14 from Grazvydas Ignotas ---
Looks like you attached the wrong file.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=101334
--- Comment #13 from John ---
Created attachment 131878
--> https://bugs.freedesktop.org/attachment.cgi?id=131878=edit
trace
The ML patch worked!
Here's the trace.
Thank you!
--
You are receiving this mail
If it's copied from i965, it must be correct, right? ;) It probably is.
Reviewed-by: Marek Olšák
Marek
On Sat, Jun 10, 2017 at 6:52 AM, Timothy Arceri wrote:
> Based on the same logic in the i965 driver 2f225f61451abd51 and
> 16060c5adcd4.
>
> perf
Hi Bas,
Have you tested piglit on radeonsi with this?
Marek
On Sat, Jun 10, 2017 at 10:05 PM, Bas Nieuwenhuizen
wrote:
> Slightly faster than bpermute, and seems supported since at least
> LLVM 3.9.
>
> v2: Since this supersedes bpermute, remove the bpermute code.
>
Reviewed-by: Bas Nieuwenhuizen
We shouldn't chain when use_ib_bos is false and embed secondary
command buffers directly in the primary buffer as well, so no handling
of chaining is needed.
On Sun, Jun 11, 2017 at 4:03 PM, Grazvydas Ignotas wrote:
>
Also, I don't know if people will like that it uses STL. I personally
have no issue with that as long as it doesn't break apps (e.g. the STL
shipped with apps should be the same as the STL shipped with the
distribution).
Marek
On Sun, Jun 11, 2017 at 4:12 PM, Marek Olšák
https://bugs.freedesktop.org/show_bug.cgi?id=101334
--- Comment #12 from Grazvydas Ignotas ---
Created attachment 131877
--> https://bugs.freedesktop.org/attachment.cgi?id=131877=edit
trace everything
I've sent a patch that should fix trace dumping for SI:
Hi Gert,
Have you measured the CPU overhead of the new code?
Marek
On Sat, Jun 10, 2017 at 1:15 AM, Gert Wollny wrote:
> Dear all,
>
> as I wrote before, I was looking into the temporary register renaming.
>
> This series of patches implements a new approach that achieves
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #76 from omerfarukdoga...@hotmail.com ---
This problem happens when a tooltip was previously shown with a multi-line
content and the current tooltip has smaller number of lines than the previous
one. Check this topic for detailed
Fixes trace dumping crash for SI or when RADV_DEBUG=noibs is set.
Fixes: 97dfff5410 "radv: Dump command buffer on hang."
Signed-off-by: Grazvydas Ignotas
---
Not sure if chained buffer dumping can be done for !use_ib_bos,
returning NULL in _get_cpu_addr() just skips that.
On Sat, Jun 10, 2017 at 5:27 AM, Brian Paul wrote:
> Some drivers require that the vertex buffers be unmapped prior to
> drawing. This change unmaps the stream_uploader buffer after we've
> uploaded the zero-stride attributes (unless the driver supports
> rendering with mapped
Signed-off-by: Boyan Ding
---
src/gallium/auxiliary/hud/hud_driver_query.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_driver_query.c
b/src/gallium/auxiliary/hud/hud_driver_query.c
index
Reviewed-by: Marek Olšák
Marek
On Sat, Jun 10, 2017 at 5:27 AM, Brian Paul wrote:
> ---
> src/gallium/auxiliary/util/u_upload_mgr.c | 54
> +--
> 1 file changed, 29 insertions(+), 25 deletions(-)
>
> diff --git
Some performance counters in nouveau uses non-integer type in AMD_perfmon,
but they are currently returning int values. One reason behind this is
that gallium hud, which is one of the users of the counters, only supports
integers. This series tries to fix problem in both parts -- making nouveau
Signed-off-by: Boyan Ding
---
.../drivers/nouveau/nvc0/nvc0_query_hw_metric.c| 70 +-
1 file changed, 42 insertions(+), 28 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c
https://bugs.freedesktop.org/show_bug.cgi?id=101334
--- Comment #11 from John ---
Created attachment 131874
--> https://bugs.freedesktop.org/attachment.cgi?id=131874=edit
gdb backtrace
Well, I've been able to get a backtrace thanks to screen.
That looks more
https://bugs.freedesktop.org/show_bug.cgi?id=101334
--- Comment #10 from John ---
I'm not sure if it's thanks to debug, but now I get something in dmesg, not
that helpful I'm afraid:
[ 141.325269] raytracing[2417]: segfault at 8 ip 7fd0b21e74d2 sp
7ffc604d5520
https://bugs.freedesktop.org/show_bug.cgi?id=101334
--- Comment #9 from Grazvydas Ignotas ---
Is the process still alive when you ssh to the system with a hung GPU? If it
is, you could attach gdb and try to get a backtrace of a hung thread.
You can try at least a few other
https://bugs.freedesktop.org/show_bug.cgi?id=101378
--- Comment #1 from freedesk...@ca.sh13.net ---
Sorry, copy/paste error, the first two lines are from another unrelated error.
The correct error message is just this part:
0:18(33): error: parameter `interpolant` must be a shader input
https://bugs.freedesktop.org/show_bug.cgi?id=101378
Bug ID: 101378
Summary: interpolateAtSample check for input parameter is too
strict
Product: Mesa
Version: 17.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
On 11/06/17 07:59, Jacob Lifshay wrote:
On Sat, Jun 10, 2017 at 3:25 PM Jose Fonseca > wrote:
I don't see how to effectively tack triangle setup into the vertex
shader: vertex shader applies to vertices, where as triangle setup and
https://bugs.freedesktop.org/show_bug.cgi?id=101374
--- Comment #2 from cosiek...@o2.pl ---
Thank you for a quick response. I'm using mesa and I'm also affected. But I'm
using r600. Maybe r600 vs radeonsi?
Computer Information:
Manufacturer: Unknown
Model: Unknown
Form Factor:
On Sat, Jun 10, 2017 at 3:25 PM Jose Fonseca wrote:
> I don't see how to effectively tack triangle setup into the vertex
> shader: vertex shader applies to vertices, where as triangle setup and
> bining applies to primitives. Usually, each vertex gets transformed
> only
53 matches
Mail list logo