Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
I just peeked into the freedreno code, and noticed that it had some
undocumented debug-code. Perhaps it could make sense to document it,
like this?
src/gallium/docs/source/debugging.rst | 4
1 file changed, 4 insertions(+)
diff --git
On Mon, Mar 25, 2013 at 6:25 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
I just peeked into the freedreno code, and noticed that it had some
undocumented debug-code. Perhaps it could make sense to document it,
like this?
src/gallium
On Mon, Mar 25, 2013 at 6:36 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Mar 25, 2013 at 6:25 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
I just peeked into the freedreno code, and noticed that it had some
undocumented debug
On Mon, Mar 25, 2013 at 9:28 PM, Rob Clark robdcl...@gmail.com wrote:
On Mon, Mar 25, 2013 at 3:27 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Mar 25, 2013 at 6:36 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Mar 25, 2013 at 6:25 PM, Erik Faye-Lund kusmab...@gmail.com wrote
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
Here you go, a version of the patch prepared for git-am
src/gallium/docs/source/debugging.rst | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/docs/source/debugging.rst
b/src/gallium/docs/source/debugging.rst
index
Ping? Anything wrong with it?
On Tue, Mar 26, 2013 at 2:48 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
Here you go, a version of the patch prepared for git-am
src/gallium/docs/source/debugging.rst | 4
1 file changed, 4
On Thu, Apr 4, 2013 at 4:32 PM, Brian Paul bri...@vmware.com wrote:
On 04/04/2013 05:20 AM, Erik Faye-Lund wrote:
Ping? Anything wrong with it?
Looks OK to me. Do you need someone to commit for you?
Well, I don't have commit access. But I was expecting to see rob pick
it up and push
On Thu, Sep 5, 2013 at 12:22 AM, Kenneth Graunke kenn...@whitecape.org wrote:
+#define B0(X) ir_function_signature *_##X();
+#define B1(X) ir_function_signature *_##X(const glsl_type *);
+#define B2(X) ir_function_signature *_##X(const glsl_type *, const glsl_type
*);
+#define B3(X)
diff --git a/src/glsl/ir_builder.cpp b/src/glsl/ir_builder.cpp
index e12ae3c..31a457d 100644
--- a/src/glsl/ir_builder.cpp
+++ b/src/glsl/ir_builder.cpp
@@ -264,6 +264,46 @@ abs(operand a)
return expr(ir_unop_abs, a);
}
+ir_expression *neg(operand a)
+{
+ return expr(ir_unop_neg,
On Mon, Sep 9, 2013 at 1:31 PM, Roland Scheidegger srol...@vmware.com wrote:
I'm not really convinced of this idea.
There's already PIPE_CAP_MIXED_COLORBUFFER_FORMATS which is sort of
similar - a requirement of ARB_fbo, but it isn't used to determine
support of ARB_fbo or not (my guess is
The preprocessor currently eats multiple #else directives
int the same #if(def) ... #endif block. While I haven't been able
to find anything that explicitly disallows it, it's nonsensical
and should probably not be allowed.
Add checks to reject the code.
---
I'm not entirely sure why
On Mon, Sep 23, 2013 at 10:35 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
The preprocessor currently eats multiple #else directives
int the same #if(def) ... #endif block. While I haven't been able
to find anything that explicitly disallows it, it's nonsensical
and should probably
On Mon, Sep 30, 2013 at 11:01 AM, Henri Verbeet hverb...@gmail.com wrote:
On 30 September 2013 02:18, Dave Airlie airl...@gmail.com wrote:
So this led me to look at the spec and the mesa code, and I noticed it
appears at some point maybe around 3.1 that FBOs are no longer
considered shared
On Mon, Sep 23, 2013 at 11:02 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Sep 23, 2013 at 10:35 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
The preprocessor currently eats multiple #else directives
int the same #if(def) ... #endif block. While I haven't been able
to find anything
On Mon, Oct 21, 2013 at 4:05 PM, Chris Healy cphe...@gmail.com wrote:
I have a headless platform I need OpenGL to work on that does not have X.
It is x86 with Intel HD 4000 graphics.
Ultimately, I'm just wanting to use OpenGL to render to memory for encoding
to H.264 and streaming.
I'm
On Tue, Oct 22, 2013 at 2:58 AM, Chris Healy cphe...@gmail.com wrote:
On Mon, Oct 21, 2013 at 2:03 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Oct 21, 2013 at 4:05 PM, Chris Healy cphe...@gmail.com wrote:
I have a headless platform I need OpenGL to work on that does not have
X
On Thu, Oct 24, 2013 at 2:19 AM, Matt Turner matts...@gmail.com wrote:
A few Serious Sam 3 shaders affected:
instructions in affected programs: 4384 - 4344 (-0.91%)
---
src/glsl/opt_algebraic.cpp | 12
1 file changed, 12 insertions(+)
diff --git
On Thu, Oct 24, 2013 at 2:19 AM, Matt Turner matts...@gmail.com wrote:
No shader-db changes, but seems like a good idea.
---
src/glsl/opt_algebraic.cpp | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 3bf0689..1ce9e2d
Why is this tagged as i965/fs, when everything seems to happen in the
glsl-optimizer?
On Thu, Oct 24, 2013 at 5:53 PM, Eric Anholt e...@anholt.net wrote:
I noticed this in a shader in Unigine Heaven that was spilling. While it
doesn't really reduce register pressure, it shaves a few
On Fri, Nov 1, 2013 at 10:16 AM, Tapani Pälli tapani.pa...@intel.com wrote:
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/shaderapi.c | 46 +++---
1 file changed, 39 insertions(+), 7 deletions(-)
diff --git
On Fri, Nov 1, 2013 at 11:35 AM, Tapani Pälli tapani.pa...@intel.com wrote:
On 11/01/2013 12:21 PM, Erik Faye-Lund wrote:
On Fri, Nov 1, 2013 at 10:16 AM, Tapani Pälli tapani.pa...@intel.com
wrote:
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/shaderapi.c | 46
On Fri, Nov 1, 2013 at 1:08 PM, Tapani Pälli tapani.pa...@intel.com wrote:
On 11/01/2013 12:38 PM, Erik Faye-Lund wrote:
On Fri, Nov 1, 2013 at 11:35 AM, Tapani Pälli tapani.pa...@intel.com
wrote:
On 11/01/2013 12:21 PM, Erik Faye-Lund wrote:
On Fri, Nov 1, 2013 at 10:16 AM, Tapani Pälli
Sorry for the late reply.
On Fri, Nov 1, 2013 at 4:14 PM, Tapani tapani.pa...@intel.com wrote:
On 11/01/2013 03:31 PM, Erik Faye-Lund wrote:
Won't using the git-sha1 as a compatibility-criteria cause issues for
developers with local changes? I'm not so worried about
On Wed, Nov 6, 2013 at 7:49 PM, Paul Berry stereotype...@gmail.com wrote:
On 6 November 2013 09:35, Erik Faye-Lund kusmab...@gmail.com wrote:
Sorry for the late reply.
On Fri, Nov 1, 2013 at 4:14 PM, Tapani tapani.pa...@intel.com wrote:
On 11/01/2013 03:31 PM, Erik Faye-Lund wrote
On Mon, Dec 2, 2013 at 11:08 PM, Andreas Hartmetz ahartm...@gmail.com wrote:
Hello,
I've been lurking for a while, this seems to be my first post.
While trying to make some easy (ha) improvements in radeonsi I looked
around in all the surrounding code to get a good picture of how things
On Tue, Dec 10, 2013 at 1:41 AM, Christopher Corsi cco...@g.clemson.edu wrote:
Currently it can do rasterize with TL,
texturing, bit-blits, and handle a subset of functionality needed for OpenGL
(scissor, blend modes, etc.). Shader support is planned.
AFAIK, Gallium3D requires support for
doesn't mean *this* slow? :)
Should I resend the patch, with the #elseif fix squashed in?
On 09/23/2013 01:35 PM, Erik Faye-Lund wrote:
The preprocessor currently eats multiple #else directives
int the same #if(def) ... #endif block. While I haven't been able
to find anything that explicitly
The preprocessor currently accepts multiple else/elif-groups
per if-section. The GLSL-preprocessor is defined by the C++
specification, which defines the following parse-rule:
if-section:
if-group elif-groups(opt) else-group(opt) endif-line
This clearly only allows a single else-group,
fine. So:
Tested-by: Erik Faye-Lund kusmab...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Jan 1, 2014 at 3:57 PM, Lauri Kasanen c...@gmx.com wrote:
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 28921be..2c33ddf 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++
On Fri, Jan 3, 2014 at 4:49 PM, Lauri Kasanen c...@gmx.com wrote:
No measurable overhead when off (glxgears within 0.5%).
Signed-off-by: Lauri Kasanen c...@gmx.com
---
src/gallium/drivers/radeon/r600_pipe_common.c | 32
+++
On Sun, Jan 5, 2014 at 12:42 AM, Maxence Le Doré
maxence.led...@gmail.com wrote:
From: Maxence Le Doré Maxence Le Doré
Huh, user.email not configured properly?
static void
+micro_fma(union tgsi_exec_channel *dst,
+ const union tgsi_exec_channel *src0,
+ const union
On Tue, Jan 7, 2014 at 12:12 AM, Brian Paul bri...@vmware.com wrote:
Evidently, there's some other definition of min and max that
causes MSVC to choke on these function names. Renaming to min2()
and max2() fixes things.
Wouldn't it be easier to just make sure NOMINMAX is defined before
On Tue, Jan 7, 2014 at 3:59 PM, Brian Paul bri...@vmware.com wrote:
On 01/06/2014 05:22 PM, Erik Faye-Lund wrote:
On Tue, Jan 7, 2014 at 12:12 AM, Brian Paul bri...@vmware.com wrote:
Evidently, there's some other definition of min and max that
causes MSVC to choke on these function names
On Tue, Jan 7, 2014 at 4:11 PM, Brian Paul bri...@vmware.com wrote:
On 01/07/2014 08:03 AM, Erik Faye-Lund wrote:
Why was this pushed out prematurely, then? Reviewing within two hours
seems to be reasonable, no?
I got Kenneth's R-b so I pushed it. I saw no reason to wait. Also, I don't
On Tue, Jan 7, 2014 at 6:46 PM, Maxence Le Doré
maxence.led...@gmail.com wrote:
Indeed, this patch compiles on linux but may break complilation at
least on MSVC version 1400.
I'm planing to install visual studio 2005 on a ms xp or seven virtual
machine to check the behavior when compiling in
On Wed, Jan 8, 2014 at 6:27 PM, jfons...@vmware.com wrote:
}
-
+
+ if (0) {
+ debug_printf( bbox: (%i, %i) - (%i, %i)\n,
+ bbox.x0, bbox.y0,
+ bbox.x1, bbox.y1);
+ }
+
if (!u_rect_test_intersection(setup-draw_regions[viewport_index],
On Wed, Jan 8, 2014 at 6:30 PM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
This example is very useful to understand the rasterization of lines.
And with this change, points too.
Adding a key / command-line option to switch modes is left for a future
opportunity
On Fri, Jan 10, 2014 at 10:33 AM, Lauri Kasanen c...@gmx.com wrote:
On Fri, 10 Jan 2014 03:57:45 +0100
srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
OpenGL does whole-point clipping, that is a large point is either fully
clipped or fully unclipped (the latter means
On Wed, Jan 15, 2014 at 7:07 AM, Michel Dänzer mic...@daenzer.net wrote:
On Die, 2014-01-14 at 00:22 +0100, Marek Olšák wrote:
I think the format conversion functions should look like:
#ifdef BIG_ENDIAN
case PIPE_FORMAT_A8B8G8R8_UNORM:
return hw_format_for_R8G8B8A8_UNORM;
...
On Fri, Jan 17, 2014 at 9:22 AM, Christian König
deathsim...@vodafone.de wrote:
But as a general note on writing patches: Please limit the subject line to a
sane length! Something between 60 and 80 chars should be ok.
Indeed. The regex patterns are nice to have. But please, put them in
the
On Mon, Jan 20, 2014 at 8:18 AM, Eric Anholt e...@anholt.net wrote:
---
src/glsl/opt_algebraic.cpp | 36
1 file changed, 36 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 6b0d992..4aa49e5 100644
---
On Mon, Jan 20, 2014 at 8:18 AM, Eric Anholt e...@anholt.net wrote:
---
src/glsl/opt_algebraic.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 332f0b7..6b0d992 100644
--- a/src/glsl/opt_algebraic.cpp
+++
On Mon, Jan 20, 2014 at 5:39 PM, Eric Anholt e...@anholt.net wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Mon, Jan 20, 2014 at 8:18 AM, Eric Anholt e...@anholt.net wrote:
---
src/glsl/opt_algebraic.cpp | 36
1 file changed, 36 insertions
On Mon, Jan 27, 2014 at 5:13 PM, Tom Stellard t...@stellard.net wrote:
From: Tom Stellard thomas.stell...@amd.com
The caller can use this boolean to parameter to tell the pipe-loader
Boolean to parameter? A superfluous to, perhaps?
___
mesa-dev
2^-64 and the binary version equals
2^+64, let's assume the value in scientific notation is a typo
and implement this using the value from the binary version
instead.
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
I've also e-mailed NVIDIA's contact as listed in the specification,
but I
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 26 --
1 file changed, 4 insertions(+), 22 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 3d37eaa..96809cd
2^-64 and the binary version equals
2^+64, let's assume the value in scientific notation is a typo
and implement this using the value from the binary version
instead.
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 4 ++--
src/gallium/docs/source
On Thu, Feb 6, 2014 at 5:30 PM, Brian Paul bri...@vmware.com wrote:
On 02/06/2014 09:09 AM, Erik Faye-Lund wrote:
In the specification text of NV_vertex_program1_1, the upper
limit of the RCC instruction is written as 1.884467e+19 in
scientific notation, but as 0x5F80 in binary
On Fri, Feb 7, 2014 at 4:15 PM, Brian Paul bri...@vmware.com wrote:
On 02/07/2014 05:45 AM, Erik Faye-Lund wrote:
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 26 --
1 file changed, 4 insertions(+), 22 deletions
On Fri, Feb 7, 2014 at 6:34 AM, Connor Abbott cwabbo...@gmail.com wrote:
- It turns out that the original advantage of a tree-based IR, to be
able to automatically generate pattern-matching code for optimizing
certain code patterns, only really matters for CPU's with weird
instruction sets
On Thu, Feb 6, 2014 at 5:09 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
In the specification text of NV_vertex_program1_1, the upper
limit of the RCC instruction is written as 1.884467e+19 in
scientific notation, but as 0x5F80 in binary. But the binary
version translates to 1.84467e+19
On Tue, Mar 4, 2014 at 10:12 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
There is little gain in printing whenever a folder is created.
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/auxiliary/Makefile.am | 8
src/glsl/Makefile.am | 4 ++--
On Tue, Mar 4, 2014 at 10:12 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
There is little point in echoing everything that the script does
to stdout. Wrap it in AM_V_GEN so that a reasonable message is
printed as a indication of it's invocation.
Signed-off-by: Emil Velikov
On Wed, Mar 5, 2014 at 12:42 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 05/03/14 10:13, Erik Faye-Lund wrote:
On Tue, Mar 4, 2014 at 10:12 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
There is little point in echoing everything that the script does
to stdout. Wrap it in AM_V_GEN
On Mon, Mar 10, 2014 at 11:54 PM, Matt Turner matts...@gmail.com wrote:
Cuts two instructions out of SynMark's Gl32VSInstancing benchmark.
---
src/glsl/opt_algebraic.cpp | 8
1 file changed, 8 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index
On Tue, Mar 11, 2014 at 2:50 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Mar 10, 2014 at 11:54 PM, Matt Turner matts...@gmail.com wrote:
Cuts two instructions out of SynMark's Gl32VSInstancing benchmark.
---
src/glsl/opt_algebraic.cpp | 8
1 file changed, 8 insertions
On Tue, Mar 11, 2014 at 7:27 PM, Eric Anholt e...@anholt.net wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Tue, Mar 11, 2014 at 2:50 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Mar 10, 2014 at 11:54 PM, Matt Turner matts...@gmail.com wrote:
Cuts two instructions out
On Wed, Mar 12, 2014 at 12:00 AM, Eric Anholt e...@anholt.net wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Tue, Mar 11, 2014 at 7:27 PM, Eric Anholt e...@anholt.net wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Tue, Mar 11, 2014 at 2:50 PM, Erik Faye-Lund kusmab...@gmail.com
On Wed, Mar 12, 2014 at 1:32 AM, Eric Anholt e...@anholt.net wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Wed, Mar 12, 2014 at 12:00 AM, Eric Anholt e...@anholt.net wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Tue, Mar 11, 2014 at 7:27 PM, Eric Anholt e...@anholt.net wrote
On Fri, Mar 14, 2014 at 7:57 PM, David Heidelberger
david.heidelber...@ixit.cz wrote:
---
src/gallium/include/pipe/p_config.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/include/pipe/p_config.h
b/src/gallium/include/pipe/p_config.h
index d603681..cd6f560
On Tue, Mar 18, 2014 at 3:18 PM, David Heidelberger
david.heidelber...@ixit.cz wrote:
Dne 2014-03-18 13:43, Erik Faye-Lund napsal:
On Fri, Mar 14, 2014 at 7:57 PM, David Heidelberger
david.heidelber...@ixit.cz wrote:
---
src/gallium/include/pipe/p_config.h | 2 +-
1 file changed, 1
It seems the subject has a typo, and ARG - ARB would be appropriate.
On Wed, Mar 19, 2014 at 10:30 PM, Rafal Mielniczuk
rafal.mielnicz...@gmail.com wrote:
Signed-off-by: Rafal Mielniczuk rafal.mielnicz...@gmail.com
---
src/mesa/main/extensions.c | 1 +
1 file changed, 1 insertion(+)
diff
On Fri, Mar 28, 2014 at 8:25 AM, Eric Anholt e...@anholt.net wrote:
I was looking at a bug report about old software, and wanted to see what
development branch a quoted commit was on:
anholt@eliezer:anholt/src/mesa-release% git describe
97217a40f97cdeae0304798b607f704deb0c3558
On Tue, May 6, 2014 at 6:51 AM, Patrick McMunn doctorwho...@gmail.com wrote:
I'm using some older hardware - an ATI Radeon 9200 - which can only handle
up to OpenGL 1.2. I was wondering if it's possible to use the hardware
renderer generally and have the driver hand off the handling of
On Fri, May 30, 2014 at 9:22 PM, Eric Anholt e...@anholt.net wrote:
However, talking yesterday about SSA and vector representations, we
again failed to come up with anything that sounded compelling -- it
appears that SSA is going to make obvious optimizations like dead code
elimination in a
On Thu, Jun 12, 2014 at 3:11 AM, Carl Worth cwo...@cworth.org wrote:
Previously, the test suite was expecting the compiler to allow a redefintion
of a macro with whitespace added, but gcc is more strict and allows only for
changes in the amounts of whitespace, (but insists that whitespace exist
On Mon, Jul 7, 2014 at 7:18 PM, Matt Turner matts...@gmail.com wrote:
On Mon, Jul 7, 2014 at 6:57 AM, Abdiel Janulgue
abdiel.janul...@linux.intel.com wrote:
v2: Check that the base type is float (Ian Romanick)
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
On Tue, Jul 8, 2014 at 8:22 AM, Matt Turner matts...@gmail.com wrote:
On Mon, Jul 7, 2014 at 11:00 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Jul 7, 2014 at 7:18 PM, Matt Turner matts...@gmail.com wrote:
This comment tripped me up for a second. This really means that you've
found
On Tue, Jul 8, 2014 at 5:44 PM, Roland Scheidegger srol...@vmware.com wrote:
Am 08.07.2014 08:22, schrieb Matt Turner:
On Mon, Jul 7, 2014 at 11:00 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Jul 7, 2014 at 7:18 PM, Matt Turner matts...@gmail.com wrote:
This comment tripped me up
On Sat, Jul 19, 2014 at 4:59 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
+TGSI_SEMANTIC_TESSCOORD
+
+
+For tessellation evaluation shaders, this semantic label indicates the
+coordinates of the vertex being processed. This is available in XYZ; W is
+undefined.
+
+ This corresponds to
On Tue, Aug 5, 2014 at 11:22 PM, Carl Worth cwo...@cworth.org wrote:
Kenneth Graunke kenn...@whitecape.org writes:
I agree that this is pretty bogus.
I'm coming around to thinking it's totally bogus.
How about emitting a warning in the RETURN_TOKEN ('#') case?
Thanks for the review, and
On Fri, Aug 8, 2014 at 12:29 AM, Carl Worth cwo...@cworth.org wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
Note that '$' is a bit different, as it's not a part of the
preprocessor's character set, so using it might be interpreted as
undefined behavior.
Right. That could easily go either
On Thu, Aug 7, 2014 at 10:31 AM, ville.syrj...@linux.intel.com wrote:
diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
index c61a748..f414ea3 100644
--- a/src/mesa/main/texformat.c
+++ b/src/mesa/main/texformat.c
case GL_ALPHA12:
case GL_ALPHA16:
On Fri, Aug 15, 2014 at 11:57 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Fri, Aug 15, 2014 at 10:52:50AM +0200, Erik Faye-Lund wrote:
On Thu, Aug 7, 2014 at 10:31 AM, ville.syrj...@linux.intel.com wrote:
diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
index
On Tue, Sep 9, 2014 at 7:30 PM, Ian Romanick i...@freedesktop.org wrote:
On 09/08/2014 01:10 AM, Tapani Pälli wrote:
From: Kalyan Kondapally kalyan.kondapa...@intel.com
According to GLSL-ES Spec(i.e. 1.0, 3.0), gl_Position value is undefined
after the vertex processing stage if we don't write
On Thu, Sep 11, 2014 at 12:32 AM, Ian Romanick i...@freedesktop.org wrote:
On 09/10/2014 01:53 PM, Erik Faye-Lund wrote:
On Tue, Sep 9, 2014 at 7:30 PM, Ian Romanick i...@freedesktop.org wrote:
On 09/08/2014 01:10 AM, Tapani Pälli wrote:
From: Kalyan Kondapally kalyan.kondapa...@intel.com
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 609d94b..7b089fa 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -266,30 +265,32 @@
On Thu, Sep 11, 2014 at 1:27 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp
b/src/mesa/main/uniform_query.cpp
index 609d94b..7b089fa 100644
--- a/src/mesa/main
On Thu, Sep 11, 2014 at 2:00 PM, Tapani Pälli tapani.pa...@intel.com wrote:
On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i...@freedesktop.org wrote:
diff --git a/src/mesa/main/uniform_query.cpp
b/src/mesa/main/uniform_query.cpp
index 609d94b
On Thu, Aug 28, 2014 at 9:58 AM, Tapani Pälli tapani.pa...@intel.com wrote:
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains NULL.
Signed-off-by: Tapani Pälli
On Thu, Sep 11, 2014 at 8:35 PM, Ian Romanick i...@freedesktop.org wrote:
On 09/11/2014 05:09 AM, Erik Faye-Lund wrote:
On Thu, Sep 11, 2014 at 2:00 PM, Tapani Pälli tapani.pa...@intel.com wrote:
On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick i
On Thu, Sep 11, 2014 at 8:39 PM, Ian Romanick i...@freedesktop.org wrote:
On 08/28/2014 12:58 AM, Tapani Pälli wrote:
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains NULL.
-by: Erik Faye-Lund kusmab...@gmail.com
---
I noticed that glsl-const-folding-01 failed due to a pretty inaccurate
result for atan(1.0) * 4.0.
The result should be pi, but we only produce 3.141298. The new
approximation gets us to 3.141580, which is at least better than before.
I also tried using
On Wed, Sep 24, 2014 at 12:39 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
This fixes the following piglit test:
shaders/glsl-const-folding-01
Forgot to mention: no piglit regressions seen on Ivybridge.
___
mesa-dev mailing list
mesa-dev
On Wed, Sep 24, 2014 at 4:10 AM, Ian Romanick i...@freedesktop.org wrote:
On 09/23/2014 03:39 PM, Erik Faye-Lund wrote:
Our current atan()-approximation is pretty inaccurate at 1.0, so
let's try to improve the situation by doing a direct approximation
without going through atan.
This new
On Wed, Sep 24, 2014 at 1:35 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
Hm. Don't I need to expand this last immediate to a vector of
type-components() size as well?
If so, this patch should go on top:
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index
On Thu, Sep 25, 2014 at 4:54 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Wed, Sep 24, 2014 at 1:35 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
Hm. Don't I need to expand this last immediate to a vector of
type-components() size as well?
If so, this patch should go on top:
diff --git
-by: Erik Faye-Lund kusmab...@gmail.com
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/builtin_functions.cpp | 65 +++---
1 file changed, 55 insertions(+), 10 deletions(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl
On Fri, Sep 26, 2014 at 6:11 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
Our current atan()-approximation is pretty inaccurate at 1.0, so
let's try to improve the situation by doing a direct approximation
without going through atan.
This new implementation uses an 11th degree polynomial
On Fri, Oct 10, 2014 at 12:22 PM, Timothy Arceri t_arc...@yahoo.com.au wrote:
On Mon, 2014-10-06 at 17:03 +0200, Erik Faye-Lund wrote:
On Fri, Sep 26, 2014 at 6:11 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
Our current atan()-approximation is pretty inaccurate at 1.0, so
let's try
On Fri, Oct 10, 2014 at 8:44 PM, Olivier Galibert galib...@pobox.com wrote:
Applied.
Thanks :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sun, Nov 2, 2014 at 7:32 PM, David Heidelberg da...@ixit.cz wrote:
v2: rename and extend support with code for C11 and MSVC (thanks to Brian)
Signed-off-by: David Heidelberg da...@ixit.cz
---
src/gallium/auxiliary/util/u_dump.h | 6 ++
src/gallium/auxiliary/util/u_dump_defines.c
On Fri, Nov 14, 2014 at 3:39 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
Hello all,
This is an old question that I had laying around - why doesn't mesa use
a more conventional numbering for the development/rc releases ?
Eg.
mesa 10.4.0-rc1 - 10.3.99.901
mesa 10.4.0-rc2 - 10.3.99.902
On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner matts...@gmail.com wrote:
On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
So when checking/building sse code we have three possibilities:
1
On Mon, Nov 17, 2014 at 3:50 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Mon, Nov 17, 2014 at 9:44 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner matts...@gmail.com wrote:
On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin imir...@alum.mit.edu wrote
On Sun, Feb 1, 2015 at 10:17 PM, Eric Anholt e...@anholt.net wrote:
This could be done in a separate pass like we do in GLSL IR, but it seems
to me like having the definitions of the transformations in the two
directions next to each other makes a lot of sense.
---
On Fri, Feb 6, 2015 at 1:11 PM, Iago Toral ito...@igalia.com wrote:
Hi,
Eduardo and I have been looking into a few dEQP test failures that deal
with wide line rendering. There are a few of them that fail because of
how clipping is implemented for this case.
The problem in these cases seems
On Sat, Feb 7, 2015 at 6:16 AM, Eric Anholt e...@anholt.net wrote:
No change on shader-db on i965.
---
src/glsl/nir/nir_opt_algebraic.py | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/glsl/nir/nir_opt_algebraic.py
b/src/glsl/nir/nir_opt_algebraic.py
index
On Tue, Feb 3, 2015 at 2:28 AM, Matt Turner matts...@gmail.com wrote:
Unclear circumstances lead to undefined symbols on x86.
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=536916
A comment[1] on the gentoo bug-tracker suggest doing something along
these lines instead (untested)...
[1]:
1 - 100 of 746 matches
Mail list logo
