When working on a parser, it's very easy to accidentally introduce
new shift/reduce conflicts. Failing the build guarantees they'll
be noticed and fixed.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/glsl_parser.yy b/sr
The single remaining shift/reduce conflict was the classic ELSE problem:
292 selection_rest_statement: statement . ELSE statement
293 | statement .
ELSE shift, and go to state 479
ELSE [reduce using rule 293 (selection_rest_statement)]
$default redu
Fixes "Uninitialized scalar field" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/r600/sb/sb_pass.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/sb/sb_pass.h
b/src/gallium/drivers/r600/sb/sb_pass.h
index c7272ba..c3
All four URB packets need to be programmed together in order for the GPU
state to be valid. Putting them in separate BEGIN..ADVANCE blocks is
risky: if we're nearing the end of a batch, the batch could be flushed
inbetween two of the commands, causing the URB programming to be split
into two batch
Reviewed-by: Chris Forbes
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 07/12/2013 11:24 AM, Matt Turner wrote:
On Fri, Jul 12, 2013 at 11:10 AM, Matt Turner wrote:
Previously, vec3 b = {{ 1.0, 2.0, 3.0 }} would cause a segfault because
the we dereferenced the constructor_type field which was NULL.
Arrays, structs, and matrices were unaffected.
This is a bad
On Thu, Jun 27, 2013 at 11:13:37PM +0200, Klemens Baum wrote:
Pushed, thanks for the patch! Sorry for the delay.
-Tom
> ---
> configure.ac | 41 ++---
> 1 file changed, 26 insertions(+), 15 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 68
On 07/12/2013 06:25 PM, Paul Berry wrote:
So this patch reworks things so that instead of having a separate
function for each shader type and GLSL version, we have a function for
constants, one for uniforms, one for varyings, and one for the special
variables that are specific to each shader type
On 07/13/2013 06:21 AM, Vinson Lee wrote:
Fixes "Uninitialized scalar field" reported by Coverity.
Pushed, thanks.
Vadim
Signed-off-by: Vinson Lee
---
src/gallium/drivers/r600/sb/sb_shader.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/sb/s
Fixes "Uninitialized scalar field" reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/r600/sb/sb_shader.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/sb/sb_shader.h
b/src/gallium/drivers/r600/sb/sb_shader.h
index ca9d29e..040
On Fri, Jul 12, 2013 at 6:44 PM, Kenneth Graunke wrote:
> On 07/12/2013 06:04 PM, Carl Worth wrote:
>>
>> Carl Worth writes:
>>>
>>> From: Matt Turner
>>>
>>> Reviewed-by: Kenneth Graunke
>>> (cherry picked from commit fcaa48d9cc8937e0ceb59dfd22ef5b6e6fd1a273)
>>>
>>> Conflicts (resolved by Car
On 07/12/2013 06:25 PM, Paul Berry wrote:
GL 3.2 and GLSL 1.50 specify that several builtin variables
(e.g. gl_FrontColor) are available only in the compatibility profile.
GL 3.1 and GLSL 1.40 make a similar stipulation (except phrased in
terms of ARB_compatibility).
Previous versions of GLSL ma
On 07/12/2013 06:04 PM, Carl Worth wrote:
Carl Worth writes:
From: Matt Turner
Reviewed-by: Kenneth Graunke
(cherry picked from commit fcaa48d9cc8937e0ceb59dfd22ef5b6e6fd1a273)
Conflicts (resolved by Carl Worth ):
src/glsl/ast_to_hir.cpp
[Oops. I meant to pass the --compose option
On Fri, Jul 12, 2013 at 5:24 PM, Vinson Lee wrote:
> Fixes "Uninitialized pointer field" defect reported by Coverity.
>
> Signed-off-by: Vinson Lee
> ---
> src/glsl/ast.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/glsl/ast.h b/src/glsl/ast.h
> index 9b119ed..c
GL 3.2 and GLSL 1.50 specify that the ftransform() function is
available only in the compatibility profile. GL 3.1 and GLSL 1.40
make a similar stipulation (except phrased in terms of
ARB_compatibility).
Previous versions of GLSL make no such stipulation. However, since GL
versions 3.1 and above
GL 3.2 and GLSL 1.50 specify that several builtin variables
(e.g. gl_FrontColor) are available only in the compatibility profile.
GL 3.1 and GLSL 1.40 make a similar stipulation (except phrased in
terms of ARB_compatibility).
Previous versions of GLSL make no such stipulation. However, since GL
v
Needed for the patch that follows.
---
src/glsl/glsl_parser_extras.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index 7f478df..ad8b063 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras
When the core profile is active, there is no fixed function fragment
shader functionality. However, we still need to generate a dummy
fragment shader program in case the back-end expects it (e.g. to cover
the case where GL_RASTERIZER_DISCARD is active and the client hasn't
supplied a fragment shad
Previously, we had a separate function for setting up the built-in
variables for each combination of shader stage and GLSL version
(e.g. generate_110_vs_variables to generate the built-in variables for
GLSL 1.10 vertex shaders). The functions called each other in ad-hoc
ways, leading to unexpected
https://bugs.freedesktop.org/show_bug.cgi?id=66809
Marek Olšák changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |nouveau@lists.freedesktop.o
Carl Worth writes:
> From: Matt Turner
>
> Reviewed-by: Kenneth Graunke
> (cherry picked from commit fcaa48d9cc8937e0ceb59dfd22ef5b6e6fd1a273)
>
> Conflicts (resolved by Carl Worth ):
> src/glsl/ast_to_hir.cpp
[Oops. I meant to pass the --compose option to "git send-email" to add a
bit of
From: Matt Turner
Reviewed-by: Kenneth Graunke
(cherry picked from commit fcaa48d9cc8937e0ceb59dfd22ef5b6e6fd1a273)
Conflicts (resolved by Carl Worth ):
src/glsl/ast_to_hir.cpp
CC: mesa-sta...@lists.freedesktop.org
---
src/glsl/ast_to_hir.cpp | 19 ++-
1 file changed,
This should fix it:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=06b38dbab287026625de302e80e9806db206c43e
Marek
On Thu, Jul 11, 2013 at 10:15 PM, Vadim Girlin wrote:
> On 07/01/2013 05:53 AM, Marek Olšák wrote:
>>
>> The winsys should do this, because it measures how much time we spend
>> i
Fixes "Uninitialized pointer field" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/glsl/ast.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 9b119ed..c0350e7 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -307,7 +3
Brian Paul writes:
> Carl, it would be good if you could put all the above info in Mesa
> docs/. The devinfo.html page mentions the "This is a candidate for the
> stable branches" convention, etc. The docs/lists.html file describes
> all the mailing lists. And so on.
Great idea. Thanks for
execinfo.h is not available on OpenBSD.
Signed-off-by: Vinson Lee
---
src/mapi/glapi/gen/gl_gentable.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mapi/glapi/gen/gl_gentable.py
b/src/mapi/glapi/gen/gl_gentable.py
index a3c9898..5c35271 100644
--- a/src/mapi/glapi/ge
https://bugs.freedesktop.org/show_bug.cgi?id=66863
Priority: medium
Bug ID: 66863
Assignee: mesa-dev@lists.freedesktop.org
Summary: st_glsl_to_tgsi.cpp:2320:emit_block_mov: Assertion
`type->is_scalar() || type->is_vector()' failed.
Hi Jonathan,
Sorry for the delay. I've pushed this patch, thanks!
-Tom
On Wed, Jul 03, 2013 at 11:05:43AM +1000, Jonathan Liu wrote:
> Bump.
>
> On 4 June 2013 23:04, Jonathan Liu wrote:
> > The AC_CHECK_FILE macro can't be used for cross compiling as it will
> > result in "error: cannot chec
On 12.07.2013 16:19, Jose Fonseca wrote:
I admit I haven't fully understood what's being proposed yet. But just a few
quick words.
I always wanted to have a "present" method that ensures that the contents of a
resource is made visible to whatever the consumer is (full-screen flip, blit to prim
On 07/12/2013 12:25 PM, Fredrik Höglund wrote:
On Friday 12 July 2013, Chad Versace wrote:
On 07/11/2013 10:18 PM, Paul Berry wrote:
Another possibility that Chad suggested when I was talking to him this
afternoon is to just just return BAD_MATCH if the client supplies the
forward-compatibility
On Tue, Jul 02, 2013 at 10:44:37AM +0200, Niels Ole Salscheider wrote:
> Pass "cl_khr_fp64" preprocessor definition to clang
>
I've gone back and forth a few times on this patch, but I think it is
OK, because all it does is enable the prototypes for builtins that use
the double type. This is fin
On Friday 12 July 2013, Chad Versace wrote:
> On 07/11/2013 10:18 PM, Paul Berry wrote:
> > Another possibility that Chad suggested when I was talking to him this
> > afternoon is to just just return BAD_MATCH if the client supplies the
> > forward-compatibility flag when requesting a 3.0+ context.
On 12.07.2013 16:06, Jose Fonseca wrote:
> The tradition has been to use "C" suffix for conditional opcodes, instead of
> "_IF". That said, I don't feel too strongly either way.
>
Except the 'C' suffix usually (ok, we only have BREAKC) indicates a
single condition value where non-zero means tru
On Thu, Jul 11, 2013 at 1:38 AM, Ian Romanick wrote:
> On 07/08/2013 03:12 PM, Marek Olšák wrote:
>>
>> On Tue, Jul 2, 2013 at 10:02 PM, Ian Romanick wrote:
>>>
>>> 3. I'd like to make some adjustments to our process for picking patches
>>> back
>>> to the stable branch. The current process is o
On Fri, Jul 12, 2013 at 11:10 AM, Matt Turner wrote:
> Previously, vec3 b = {{ 1.0, 2.0, 3.0 }} would cause a segfault because
> the we dereferenced the constructor_type field which was NULL.
>
> Arrays, structs, and matrices were unaffected.
This is a bad commit message. Use this instead:
_mesa
On Thu, Jul 11, 2013 at 8:52 PM, Matt Turner wrote:
>> I believe that all this grammar is correct, but do we have tests for
>> spurious curly braces? Things like
>>
>> vec4 v = {{{1, 2, 3, 4}}};
>
> No, I'll write one.
Nice call on this test. For vectors _mesa_ast_set_aggregate_type would
wa
The series looks alright AFAICT.
The only request I have is the ability to disable the cache, so that we can
iron out any eventual bugs.
Another thing we eventually need to think about is thread safety. Though that's
not a new problem, so it can be addressed in a follow-on change.
Jose
-
Previously, vec3 b = {{ 1.0, 2.0, 3.0 }} would cause a segfault because
the we dereferenced the constructor_type field which was NULL.
Arrays, structs, and matrices were unaffected.
---
src/glsl/ast_function.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/glsl/ast_function.cpp b/
On 07/11/2013 10:18 PM, Paul Berry wrote:
On 11 July 2013 16:30, Ian Romanick wrote:
I believe you're right, that there's a bug in our implementation--it would
successfully compile this shader, and it shouldn't.
In fact, based on my discussion with Chad today, it sounds like we don't
have a
On Fri, Jul 12, 2013 at 10:12:39AM -0700, Ben Widawsky wrote:
> FWD'd from our internal list now that we have more insight.
> - Forwarded message from Ben Widawsky -
>
> Date: Thu, 11 Jul 2013 10:32:03 -0700
> From: Ben Widawsky
> To: linux-...@linux.intel.com
> Subject: intel_gpu_top br
On Fri, Jul 12, 2013 at 07:16:37PM +0200, Daniel Vetter wrote:
> On Fri, Jul 12, 2013 at 7:12 PM, Ben Widawsky
> wrote:
> > FWD'd from our internal list now that we have more insight.
> > - Forwarded message from Ben Widawsky
> > -
> >
> > Date: Thu, 11 Jul 2013 10:32:03 -0700
> > From:
On Fri, Jul 12, 2013 at 7:12 PM, Ben Widawsky
wrote:
> FWD'd from our internal list now that we have more insight.
> - Forwarded message from Ben Widawsky -
>
> Date: Thu, 11 Jul 2013 10:32:03 -0700
> From: Ben Widawsky
> To: linux-...@linux.intel.com
> Subject: intel_gpu_top broken for
https://bugs.freedesktop.org/show_bug.cgi?id=66858
Andrew Dunai changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=66833
--- Comment #6 from Laurent carlier ---
I cannot reproduce this with mesa-9.2 from git & llvm-3.4svn with a radeonsi
card (HD7870) but game segfault/terminate when i try to launch a new game.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=66833
--- Comment #5 from Vedran Rodic ---
As Chris Forbes already noticed on #intel-gfx (sorry, didn't get to see that),
the trace captured on Intel/Mesa machine shows the same problems when played
back on a machine with Geforce 9800GT with nVidia pro
https://bugs.freedesktop.org/show_bug.cgi?id=66858
--- Comment #1 from Brian Paul ---
That's my fault. But I believe this is the correct fix (undo the change to
that line):
--- a/src/gallium/drivers/nv30/nvfx_fragprog.c
+++ b/src/gallium/drivers/nv30/nvfx_fragprog.c
@@ -197,7 +197,7 @@ nvfx_fp_
https://bugs.freedesktop.org/show_bug.cgi?id=66858
Priority: medium
Bug ID: 66858
Assignee: mesa-dev@lists.freedesktop.org
Summary: Missing definition for NVFX_FP_OP_OPCODE_KILL_IF
Severity: normal
Classification: Unclassified
On 07/12/2013 12:46 AM, Andy Li wrote:
Hello everyone,
I have a question regarding to the OSMesa demo code.
I have installed OSMesa and trying to play around with the demo code.
I have complied the .c file and an executable file has created.
After I ran the executable file, a "Windows cursor (im
On 07/12/2013 08:06 AM, Jose Fonseca wrote:
The tradition has been to use "C" suffix for conditional opcodes, instead of
"_IF". That said, I don't feel too strongly either way.
I agree that the current naming is confusing. And I like the fact that the new
and old opcodes don't overlap, which
I admit I haven't fully understood what's being proposed yet. But just a few
quick words.
I always wanted to have a "present" method that ensures that the contents of a
resource is made visible to whatever the consumer is (full-screen flip, blit to
primary surface, a compositor, etc.). We have
The tradition has been to use "C" suffix for conditional opcodes, instead of
"_IF". That said, I don't feel too strongly either way.
I agree that the current naming is confusing. And I like the fact that the new
and old opcodes don't overlap, which means there is no way we inadvertently get
th
https://bugs.freedesktop.org/show_bug.cgi?id=66833
--- Comment #4 from Vedran Rodic ---
I've managed to capture the trace with the latest version of apitrace (sigh,
ubuntu should really update the in-distro one).
http://mjesec.ffzg.hr/~vrodic/dota/dota_linux.225278.trim.trace.bz2 (25MB bz2).
T
On 11 July 2013 12:06, Matt Turner wrote:
> On Mon, Jul 8, 2013 at 10:40 AM, Paul Berry
> wrote:
> > + const glsl_type *typ(const char *name)
>
> This must not be a typo, since it's consistent.
>
Heh, "type" is a reserved word in so many languages that I guess I assumed
it was reserved in C++
Looks good. Thanks for the update.
Jose
- Original Message -
> From: Roland Scheidegger
>
> srgb-to-linear is using 3rd degree polynomial for now which should be _just_
> good enough. Reverse is using some rational polynomials and is quite
> accurate,
> though not hooked into llvmpipe's
https://bugs.freedesktop.org/show_bug.cgi?id=66850
Priority: medium
Bug ID: 66850
Assignee: mesa-dev@lists.freedesktop.org
Summary: glGenerateMipmap crashes when using
GL_TEXTURE_2D_ARRAY with compressed internal format
Sever
55 matches
Mail list logo
