Fantastic thanks!
This series is,
Reviewed-by: Edward O'Callaghan
On 2015-12-31 13:30, Nicolai Hähnle wrote:
From: Nicolai Hähnle
---
src/gallium/drivers/radeon/r600_pipe_common.c | 12
src/gallium/drivers/radeon/r600_pipe_common.h | 2 ++
2 files changed, 14 insertions(+)
d
From: Roland Scheidegger
Back in the day (before 24678700edaf5bb9da9be93a1367f1a24cfaa471) the values
were not actually in a struct but even then I can't see why we didn't simply
align the values. Especially since it's trivial to do so.
(Not that it actually matters since the code is pretty much
On 30.12.2015 13:44, Krzysztof A. Sobiecki wrote:
Nicolai Hähnle writes:
On 30.12.2015 08:42, Krzysztof A. Sobiecki wrote:
Nicolai Hähnle writes:
On 29.12.2015 14:27, Krzysztof A. Sobiecki wrote:
From: Krzysztof Sobiecki
ALIGN_DIVUP is a driver specific(r600g) macro that duplicates DIV_
---
si-report.py | 51 +--
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/si-report.py b/si-report.py
index bb6ea6d..3156639 100755
--- a/si-report.py
+++ b/si-report.py
@@ -37,12 +37,6 @@ def get_str(value, suffix = ' %'):
else
For Gallium-based drivers, this is required for receiving shader information
via debug messages.
---
run.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/run.c b/run.c
index 82d8c91..685f830 100644
--- a/run.c
+++ b/run.c
@@ -435,6 +435,7 @@ main(int argc, char **argv)
EGL_CONTEXT_OP
---
si-report.py | 90 +---
1 file changed, 32 insertions(+), 58 deletions(-)
diff --git a/si-report.py b/si-report.py
index 9df2012..bb6ea6d 100755
--- a/si-report.py
+++ b/si-report.py
@@ -43,34 +43,6 @@ def get_value_str(value, prefix, su
No need to report details of those errors, but complain when errors are
encountered so they aren't ignored.
---
si-report.py | 38 +-
1 file changed, 33 insertions(+), 5 deletions(-)
diff --git a/si-report.py b/si-report.py
index e4aea40..9df2012 100755
--- a/s
Benefit from recent changes to Mesa master which allows correct reporting
in multi-threaded runs, and generally more robust reporting when comparing
different runs, e.g. that differ in the set of tests that were run.
Parsing also becomes much faster because we (a) do not recompile regexes in
the i
From: Nicolai Hähnle
This will allow us to send shader debug info via the context's debug callback.
---
src/gallium/drivers/r600/evergreen_compute.c | 2 +-
src/gallium/drivers/r600/r600_llvm.c | 3 ++-
src/gallium/drivers/r600/r600_llvm.h | 2 ++
src/gallium/drivers/r600/r600
From: Nicolai Hähnle
The output via stderr is very helpful for ad-hoc debugging tasks, so that
remains
unchanged, but having the information available via debug messages as well
will allow the use of parallel shader-db runs.
Shader stats are always provided (if the context is a debug context, t
From: Nicolai Hähnle
Now that the functions gets a context pointer, it can determine IR and ASM
dumping by itself.
The dump parameter is still required because we cannot easily tell the shader
type at this point (one might argue that the separate enable flags for the
different types offer little
From: Nicolai Hähnle
---
src/gallium/drivers/radeon/r600_pipe_common.c | 12
src/gallium/drivers/radeon/r600_pipe_common.h | 2 ++
2 files changed, 14 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 9a
From: Nicolai Hähnle
This will allow us to send shader debug info via the context's debug callback.
---
src/gallium/drivers/radeonsi/si_compute.c | 4 ++--
src/gallium/drivers/radeonsi/si_shader.c| 19 +++
src/gallium/drivers/radeonsi/si_shader.h| 6 +++---
From: Nicolai Hähnle
Diagnostics sent during code generation and the every error message reported
by LLVMTargetMachineEmitToMemoryBuffer are disjoint reporting mechanisms. We
take care of both and also send an explicit message indicating failure at the
end, so that log parsers can more easily tel
Am 30.12.2015 um 10:59 schrieb Oded Gabbay:
> On Wed, Dec 30, 2015 at 1:17 AM, Roland Scheidegger
> wrote:
>> The idea looks right to me.
>> Though frankly I don't like our current setup code too much - in
>> particular the mix between c, assembly, and jit code, with some
>> duplication (plus the
Am 30.12.2015 um 21:26 schrieb Matt Turner:
> The OpenGL specifications for these functions say:
>
>The result will be undefined if or is negative, or if
>the sum of and is greater than the number of bits
>used to store the operand.
>
> Therefore passing bits=32, offset=0 is legal
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Signed-off-by: Jordan Justen
---
src/mesa/main/bufferobj.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index e0639c8..8eae72c 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -3911,6 +3911,10
Signed-off-by: Jordan Justen
---
src/mesa/main/program_resource.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/src/mesa/main/program_resource.c b/src/mesa/main/program_resource.c
index b7e25fe..0176c8e 100644
--- a/src/mesa/main/program_resource.c
+++ b/s
On Wed, Dec 30, 2015 at 6:57 PM, Timothy Arceri wrote:
> Reviewed-by: Timothy Arceri
>
> Piglit test?
I'll leave that to whoever added the extension. Or a volunteer :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.or
Reviewed-by: Timothy Arceri
Piglit test?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Signed-off-by: Ilia Mirkin
---
src/glsl/glcpp/glcpp-parse.y | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index 2fd4cf0..ef1a657 100644
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -2506,6 +2506,9 @@
On Wed, 2015-12-30 at 08:49 -0500, Ilia Mirkin wrote:
> On Wed, Dec 30, 2015 at 6:26 AM, Kenneth Graunke <
> kenn...@whitecape.org> wrote:
> > varying_matches::record tries to compute the number of components
> > in
> > each varying, which varying_matches::assign_locations uses to
> > assign
> > lo
This is optional for now in the transition period, but optimally all
backends that support indirect draws would switch over to it and we can
remove the support for indirect in the "regular" draw function.
This should allow a backend to properly support ARB_multi_draw_indirect
and ARB_indirect_para
On Tue, Dec 29, 2015 at 5:35 PM, Roland Scheidegger wrote:
> Am 29.12.2015 um 23:04 schrieb Ilia Mirkin:
>> Hooks up the new system values, passes the drawid in.
>>
>> Signed-off-by: Ilia Mirkin
>> ---
>> src/mesa/state_tracker/st_draw.c | 1 +
>> src/mesa/state_tracker/st_extensions.c
On Wed, Dec 30, 2015 at 3:26 PM, Matt Turner wrote:
> The OpenGL specifications for these functions say:
>
>The result will be undefined if or is negative, or if
>the sum of and is greater than the number of bits
>used to store the operand.
>
> Therefore passing bits=32, offset=0 i
Shifting into the sign bit if undefined, as is shifting by 32.
---
src/glsl/ir_constant_expression.cpp | 10 +-
src/glsl/nir/nir_opcodes.py | 6 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/glsl/ir_constant_expression.cpp
b/src/glsl/ir_constant_expres
The OpenGL specifications for these functions say:
The result will be undefined if or is negative, or if
the sum of and is greater than the number of bits
used to store the operand.
Therefore passing bits=32, offset=0 is legal and defined in GLSL.
But the earlier DX11/SM5 bfi/ibfe/u
On Mon, Nov 2, 2015 at 10:12 AM, Tapani Pälli wrote:
>
>
> On 11/02/2015 09:16 AM, Ilia Mirkin wrote:
>>
>> On Mon, Nov 2, 2015 at 1:58 AM, Tapani Pälli
>> wrote:
>>>
>>> Patch changes linker to allocate gl_shader_variable instead of using
>>> ir_variable. This makes it possible to get rid of ir_
Nicolai Hähnle writes:
> On 30.12.2015 08:42, Krzysztof A. Sobiecki wrote:
>> Nicolai Hähnle writes:
>>
>>> On 29.12.2015 14:27, Krzysztof A. Sobiecki wrote:
From: Krzysztof Sobiecki
ALIGN_DIVUP is a driver specific(r600g) macro that duplicates DIV_ROUND_UP
functionality.
>
I spotted this while looking for what needs updating in future platforms.
I'm too lazy to go through the git logs, but it was probably missed by Jason
when all the brw refactoring happened.
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/i965/brw_context.c | 2 +-
src/mesa/drivers/dri/i96
On Wed, Dec 30, 2015 at 10:32 AM, Rob Clark wrote:
> diff --git a/src/mesa/drivers/dri/i965/brw_nir.c
> b/src/mesa/drivers/dri/i965/brw_nir.c
> index e031173..a8bed70 100644
> --- a/src/mesa/drivers/dri/i965/brw_nir.c
> +++ b/src/mesa/drivers/dri/i965/brw_nir.c
> @@ -405,42 +405,8 @@ brw_nir_lowe
Am 30.12.2015 um 10:57 schrieb Oded Gabbay:
> On Wed, Dec 30, 2015 at 3:18 AM, Roland Scheidegger
> wrote:
>> Am 29.12.2015 um 17:12 schrieb Oded Gabbay:
>>> This file provides a portability layer that will make it easier to convert
>>> SSE-based functions to VMX/VSX-based functions.
>>>
>>> All
On 30.12.2015 08:42, Krzysztof A. Sobiecki wrote:
Nicolai Hähnle writes:
On 29.12.2015 14:27, Krzysztof A. Sobiecki wrote:
From: Krzysztof Sobiecki
ALIGN_DIVUP is a driver specific(r600g) macro that duplicates DIV_ROUND_UP
functionality.
Replacing it with DIV_ROUND_UP eliminates this probl
Am 30.12.2015 um 10:46 schrieb Oded Gabbay:
> On Wed, Dec 30, 2015 at 1:11 AM, Roland Scheidegger
> wrote:
>>
>> So, if I see that right, you will automatically generate binaries using
>> power8 instructions if compiled on power8 capable box, which then won't
>> run on boxes not supporting power8
From: Rob Clark
Note these are a bit uglier, due to avoidance of GNU C extensions. But
drivers which do not need to be built with compilers that don't support
the extension can wrap these macros with their own.
Signed-off-by: Rob Clark
---
So I can re-use in ir3.
src/glsl/nir/nir.h
On Wed, Dec 30, 2015 at 6:26 AM, Kenneth Graunke wrote:
> varying_matches::record tries to compute the number of components in
> each varying, which varying_matches::assign_locations uses to assign
> locations. With varying packing, it uses glsl_type::component_slots()
> to come up with a reasona
Nicolai Hähnle writes:
> On 29.12.2015 14:27, Krzysztof A. Sobiecki wrote:
>> From: Krzysztof Sobiecki
>>
>> ALIGN_DIVUP is a driver specific(r600g) macro that duplicates DIV_ROUND_UP
>> functionality.
>> Replacing it with DIV_ROUND_UP eliminates this problems.
>
> Those macros are actually sli
On Wed, Dec 30, 2015 at 6:26 AM, Kenneth Graunke wrote:
> Quads need to respect winding order, too - not just triangles.
Double-checked the spec, looks like that's right. And hopefully the FE
will complain if you attempt to set it on lines.
>
> Fixes rendering in GFXBench 4.0's tessellation benc
Quads need to respect winding order, too - not just triangles.
Fixes rendering in GFXBench 4.0's tessellation benchmark.
Signed-off-by: Kenneth Graunke
Cc: Ilia Mirkin
---
src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
No regression
varying_matches::record tries to compute the number of components in
each varying, which varying_matches::assign_locations uses to assign
locations. With varying packing, it uses glsl_type::component_slots()
to come up with a reasonable value.
Without varying packing, it fell back to an open-code
On Wed, Dec 30, 2015 at 1:17 AM, Roland Scheidegger wrote:
> The idea looks right to me.
> Though frankly I don't like our current setup code too much - in
> particular the mix between c, assembly, and jit code, with some
> duplication (plus the lots of transpose everywhere). There's likely
> opti
On Wed, Dec 30, 2015 at 3:18 AM, Roland Scheidegger wrote:
> Am 29.12.2015 um 17:12 schrieb Oded Gabbay:
>> This file provides a portability layer that will make it easier to convert
>> SSE-based functions to VMX/VSX-based functions.
>>
>> All the functions implemented in this file are prefixed us
On Wed, Dec 30, 2015 at 1:11 AM, Roland Scheidegger wrote:
>
> So, if I see that right, you will automatically generate binaries using
> power8 instructions if compiled on power8 capable box, which then won't
> run on boxes not supporting power8? Is that really what you want?
> Maybe some runtime
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Ilia Mirkin
> Sent: Tuesday, December 29, 2015 5:39 PM
> To: Marta Lofstedt
> Cc: mesa-dev@lists.freedesktop.org; Romanick, Ian D
> Subject: Re: [Mesa-dev] [PATCH] i965/gen8: Always use
>
46 matches
Mail list logo
