On Mon, Jul 02, 2012 at 06:44:37AM -0700, Jose Fonseca wrote:
> But I think that this fix is too ad-hoc, and I suspect it may
> introduce other regressions.
>
> If I understood the problem correctly, the issue here is that some
> drivers want system values in floats, others want in
> integers. Rig
Daniel Vetter writes:
> - Separate out the depth stall from the depth count write, workarounds
> say that a depth stall needs to be preceeded with a non-zero
> post-sync op.
> - Implement the cs stall workaround like the kernel does.
It looks like these are actually not required for ivb, acc
On 2 July 2012 15:12, Vadim Girlin wrote:
> On Mon, 2012-07-02 at 14:19 -0700, Paul Berry wrote:
> > On 2 July 2012 13:45, Vadim Girlin wrote:
> >
> > > On Mon, 2012-07-02 at 10:08 -0700, Paul Berry wrote:
> > > > On 2 July 2012 08:04, Vadim Girlin wrote:
> > > > On Sun, 2012-06-24 at 1
On 07/02/2012 05:33 PM, Ian Romanick wrote:
> On 07/02/2012 04:00 PM, Brian Paul wrote:
>
> Won't this cause a constant and a non-constant to generate a different
> value? The implementation of round() used in constant folding really
> needs to be the same as the one used by the code generator.
Fixes piglit layout-std140.
---
src/glsl/glsl_types.cpp| 220
src/glsl/glsl_types.h | 13 +++
src/glsl/link_uniforms.cpp | 34 ++-
src/glsl/linker.cpp|2 +
src/glsl/linker.h |3 +
5 files changed, 270 insertion
---
src/mesa/main/uniform_query.cpp | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index b5499ea..816c277 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@
This is a requirement for std140 uniform blocks, and optional for
packed/shared blocks.
---
src/glsl/opt_dead_code.cpp |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/glsl/opt_dead_code.cpp b/src/glsl/opt_dead_code.cpp
index 0578f17..de8475f 100644
--- a/src/glsl/
This is a requirement for std140 uniform blocks, and optional for
packed/shared blocks.
---
src/glsl/linker.cpp |7 +++
1 file changed, 7 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 7adee32..4267602 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
This attempts error-checking, but the layout isn't done yet.
---
src/glsl/link_uniforms.cpp | 61 +
src/glsl/linker.cpp | 82 +--
src/glsl/linker.h |6 +++
src/mesa/main/mtypes.h | 34
Now we can actually return information on uniforms in uniform blocks
in the new queries.
---
src/glsl/ir_uniform.h | 34 ++
src/glsl/link_uniforms.cpp | 41 -
2 files changed, 74 insertions(+), 1 deletion(-)
diff --g
This doesn't do anything with the uniform block declarations yet, so
usage of those uniforms finds them to be undeclared.
---
src/glsl/ast.h | 28 +++
src/glsl/ast_to_hir.cpp | 11 +
src/glsl/glsl_lexer.ll |5 +-
src/glsl/glsl_parser.yy | 122
At this point in the linking, we've totally lost track of the struct
gl_uniform_buffer that this pointed to in the original unlinked
shader, so we do a nasty n^2 walk to find it the new one based on the
variable name.
Note that these point into the shader's list of gl_uniform_buffers,
not the link
We'll need to propagate the UBO fields to the uniform storage records
before we can handle the other pnames.
---
src/mesa/main/uniform_query.cpp | 62 +++
src/mesa/main/uniforms.c|1 +
src/mesa/main/uniforms.h|7 +
3 files changed,
Now that we finally have a list of uniform blocks in the linked shader
program, we can tell what their indices are.
Fixes piglit GL_ARB_uniform_buffer_object/getuniformblockindex.
---
src/mesa/main/uniforms.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/src/m
We're going to need this structure to cross-validate the uniform
blocks between shader stages, since unused ir_variables might get
dropped. It's also the place we store the RowMajor qualifier, which
is not part of the GLSL type (since that would cause a bunch of type
equality checks to fail).
---
This is a single entrypoint that maps from a series of names to the
indices of those names within the active uniforms list. Each index is
like glGetUniformLocation()'s return value, except that it doesn't
encode an array offset.
---
src/mesa/main/uniforms.c | 35
With the upcoming GL_ARB_uniform_buffer_object changes, the only
other caller that will want the cooked value is state_tracker.
---
src/mesa/main/uniform_query.cpp| 25 +++--
src/mesa/main/uniforms.c |7 ++-
src/mesa/main/uniforms.h
Fixes piglit layout-*-non-uniform and layout-*-within-block.
---
src/glsl/ast.h |6 ++
src/glsl/ast_to_hir.cpp | 36 +---
src/glsl/glsl_parser.yy |2 ++
src/glsl/glsl_parser_extras.cpp |1 +
4 files changed, 42 inse
I've been trying to derive from this for UBO support, and the slightly
obfuscated types were putting me over the edge.
---
src/glsl/ast.h |6 +-
src/glsl/glsl_parser.yy |6 +++---
src/glsl/glsl_parser_extras.cpp |2 +-
3 files changed, 9 insertions(+), 5 de
---
src/glsl/glsl_parser.yy |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index e688b48..248376b 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -1100,13 +1100,8 @@ layout_qualifier_id_list:
The got_one variable was set iff one of the bits in flags.i was set.
---
src/glsl/glsl_parser.yy | 31 ++-
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 5ca8740..e688b48 100644
--- a/src/glsl/gls
From: Vincent Lejeune
---
src/glsl/glsl_parser_extras.cpp |1 +
src/glsl/glsl_parser_extras.h |2 ++
2 files changed, 3 insertions(+)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 02c3986..c19b6f9 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++
Here's a new pile of UBO stuff. It gets things through the linker and
answers some more API queries. It doesn't include the driver backend
yet. I have some WIP code that's getting a lot of rendering to work,
so I'm pretty convinced that this chunk of code won't require a lot of
work. However, I
On 07/02/2012 04:00 PM, Brian Paul wrote:
Won't this cause a constant and a non-constant to generate a different
value? The implementation of round() used in constant folding really
needs to be the same as the one used by the code generator. Right?
---
src/gallium/auxiliary/tgsi/tgsi_exe
On 07/02/2012 03:59 PM, Brian Paul wrote:
> The GLSL round() and roundEven() functions were both generating the
> ir_unop_round_even instruction but the GLSL spec allows some leeway for
> implementing round(). This change allows drivers to take advantage of
> that. For i965, they still equate to
ROUND and TRUNC are implemented with one function to reduce code duplication.
---
src/gallium/drivers/svga/svga_tgsi_insn.c | 69 ++---
1 files changed, 53 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi_insn.c
b/src/gallium/drivers/svga/s
Converting CMP to SLT+LRP didn't work when src2 or src3 was Inf/NaN.
That's the case for GLSL sqrt(0). sqrt(0) actually happens in many
piglit auto-generated tests that use the distance() function.
v2: remove debug/devel code, per Jose
---
src/gallium/drivers/svga/svga_tgsi_insn.c | 73 +++
Was previously implemented with FLOOR.
Fixes quite a few piglit tests of float->int conversion, integer
division, etc.
v2: clean up left over debug/devel code, per Jose
---
src/gallium/drivers/svga/svga_tgsi_insn.c | 55 -
1 files changed, 54 insertions(+), 1 deletio
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 29 -
1 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 4c5e9d1..c4413e7 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec
This instructions lets drivers implement GLSL's round() and roundEven()
differently if they need or want to. For now, ROUNDEVEN just does whatever
ROUND did.
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c |3 ++-
src/gallium/auxiliary/tgsi/tgsi_exec.c |1 +
src/gallium
The GLSL round() and roundEven() functions were both generating the
ir_unop_round_even instruction but the GLSL spec allows some leeway for
implementing round(). This change allows drivers to take advantage of
that. For i965, they still equate to the same thing.
---
src/glsl/builtins/ir/round.ir
On Mon, 2012-07-02 at 14:19 -0700, Paul Berry wrote:
> On 2 July 2012 13:45, Vadim Girlin wrote:
>
> > On Mon, 2012-07-02 at 10:08 -0700, Paul Berry wrote:
> > > On 2 July 2012 08:04, Vadim Girlin wrote:
> > > On Sun, 2012-06-24 at 11:18 +0200, Olivier Galibert wrote:
> > > > Tha
On 2 July 2012 13:45, Vadim Girlin wrote:
> On Mon, 2012-07-02 at 10:08 -0700, Paul Berry wrote:
> > On 2 July 2012 08:04, Vadim Girlin wrote:
> > On Sun, 2012-06-24 at 11:18 +0200, Olivier Galibert wrote:
> > > That old bug was hidden but the clipper always interpolating
> >
On Mon, 2012-07-02 at 10:08 -0700, Paul Berry wrote:
> On 2 July 2012 08:04, Vadim Girlin wrote:
> On Sun, 2012-06-24 at 11:18 +0200, Olivier Galibert wrote:
> > That old bug was hidden but the clipper always interpolating
> in 3d
> > space no matter what it should
On 07/01/2012 11:37 AM, nobled wrote:
On Fri, Jun 22, 2012 at 11:26 PM, Brian Paul
wrote:
Module: Mesa
Branch: master
Commit: cbffaf20e9e6154310ba68bb2b44adc37ba83bcd
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=cbffaf20e9e6154310ba68bb2b44adc37ba83bcd
Author: Brian Paul
Date:
Daniel Vetter writes:
> ... and the hardware seems to take the lenght of the pipe control
> command to indicate whether the write is 64bit or 32bit. Which makes
> sense for immediate writes.
>
> I've discovered this by writing a pattern into the query object bo and
> noticing that the high 32bits
On 2 July 2012 08:04, Vadim Girlin wrote:
> On Sun, 2012-06-24 at 11:18 +0200, Olivier Galibert wrote:
> > That old bug was hidden but the clipper always interpolating in 3d
> > space no matter what it should have been doing. Now that the
> > interpolation has been fixed, the bug shows up.
> >
>
Kenneth Graunke writes:
> Commit 0c005bd7 intended to make ir_loop_jump::mode public, but also
> accidentally added a new pointer to the enclosing loop. Furthermore, it
> tried to initialize the new field by adding "this->loop = loop;" to the
> constructor, but since there is no loop parameter,
On 07/02/2012 09:21 AM, Marek Olšák wrote:
ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH_WITH_RETVAL calls FLUSH_VERTICES, which
is not what we want.
This fixes a breakage in classic drivers, introduced in:
62b971673950148eb949ba23d7fdc47debea16f0
vbo: first ASSERT_OUTSIDE_BEGIN_END then FLUSH, not
ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH_WITH_RETVAL calls FLUSH_VERTICES, which
is not what we want.
This fixes a breakage in classic drivers, introduced in:
62b971673950148eb949ba23d7fdc47debea16f0
vbo: first ASSERT_OUTSIDE_BEGIN_END then FLUSH, not the other way around
It should fix:
https://
On 07/02/2012 01:16 AM, Daniel Vetter wrote:
> On Sun, Jul 01, 2012 at 07:59:56PM -0700, Kenneth Graunke wrote:
>> On 06/26/2012 07:28 AM, Daniel Vetter wrote:
>>> ... and the hardware seems to take the lenght of the pipe control
>>> command to indicate whether the write is 64bit or 32bit. Which ma
On Sun, 2012-06-24 at 11:18 +0200, Olivier Galibert wrote:
> That old bug was hidden but the clipper always interpolating in 3d
> space no matter what it should have been doing. Now that the
> interpolation has been fixed, the bug shows up.
>
> Fixes bugzilla 51364.
>
> Signed-off-by: Ol
FWIW, r600g passes the test and this commit has no effect on the driver.
Marek
On Mon, Jul 2, 2012 at 1:24 PM, Jose Fonseca wrote:
> This would affect not only llvmpipe but all gallium drivers, even those not
> using draw module.
>
> Can other gallium driver maintainers acknowledge this patch a
- Original Message -
> On Fri, Jun 29, 2012 at 03:09:23PM -0700, Stéphane Marchesin wrote:
> > I do, but it fixes a regression, so unless you have a fix, it's the
> > way to
> > go. If you have a fix I'll happily test it :)
>
> Just between us, revert on small regressions may not be opti
I pushed that. Thanks.
Jose
- Original Message -
> Don't know if it's old gcc(s) or 32bit but I can't build current
> master -
>
> ../../src/gallium/auxiliary/util/u_math.h:385: error: integer
> constant
> is too large for 'long' type
>
> Looks like I need ULL on the constants in
> d069
This would affect not only llvmpipe but all gallium drivers, even those not
using draw module.
Can other gallium driver maintainers acknowledge this patch also fixes their
test with their drivers?
Jose
- Original Message -
> That old bug was hidden but the clipper always interpolating
On Sun, Jul 01, 2012 at 08:10:49PM -0700, Kenneth Graunke wrote:
> On 06/26/2012 07:28 AM, Daniel Vetter wrote:
> > Similar treatment to the depth count pipe_control writes
> > - Add the CS_STALL workaround, timestamp writes are non-zero post-sync
> > ops, too.
> > - Also ensure that we write the
On Sun, Jul 01, 2012 at 07:59:56PM -0700, Kenneth Graunke wrote:
> On 06/26/2012 07:28 AM, Daniel Vetter wrote:
> > ... and the hardware seems to take the lenght of the pipe control
> > command to indicate whether the write is 64bit or 32bit. Which makes
> > sense for immediate writes.
> >
> > I'v
48 matches
Mail list logo
