These fixes are candidates for the stable branches.
Chad Versace (4):
glsl: Document parameters_lists_match()
glsl: Refactor ast_function.cpp:type_compare() into a glsl_type
method
glsl: Fix illegal implicit type conversions
glsl: Fix implicit conversions in array constructors
The function's parameter do not indicate which parameter list belongs to
the function signature and which is the actual parameter list. So clarify
this in a Doxygen comment.
Signed-off-by: Chad Versace c...@chad-versace.us
---
src/glsl/ir_function.cpp |6 ++
1 files changed, 6
On a subsequent commit, ast_function_expression::hir() will need access to
type_compare(), but it is defined in a different file. So refactor
type_compare() into glsl_type::implicit_conversion_compare().
CC: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Chad Versace c...@chad-versace.us
glsl_type::implicit_conversion_compare() allowed the following illegal
implicit conversions:
bool - float
bvecN - vecN
int - uint
ivecN - uvecN
uint - int
uvecN - ivecN
Fixes Piglit
Array constructors obey narrower conversion rules than other constructors,
but process_array_constructor() was incorrectly applying the broader
rules. From page 33 (page 39 of the pdf) of the GLSL 1.20 spec, Section
5.4.4 Array Constructors:
Each argument must be the same type as the element
On 07/26/2011 05:43 PM, Ian Romanick wrote:
On 07/26/2011 04:08 PM, Chad Versace wrote:
type_compare() allowed the following illegal implicit conversions:
bool - float
bvecN - vecN
Fixes Piglit tests
spec/glsl-1.20/compiler/built-in-functions/outerProduct-bvec*.vert.
Does this
These fixes are candidates for the 7.10 and 7.11 branches.
(v1 of the series contained an Eclipse reformatting bomb).
Chad Versace (4):
glsl: Document parameters_lists_match()
glsl: Refactor ast_function.cpp:type_compare() into a glsl_type
method
glsl: Fix illegal implicit type
On a subsequent commit, ast_function_expression::hir() will need access to
type_compare(), but it is defined in a different file. So refactor
type_compare() into glsl_type::implicit_conversion_compare().
CC: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Chad Versace c...@chad-versace.us
glsl_type::implicit_conversion_compare() allowed the following illegal
implicit conversions:
bool - float
bvecN - vecN
int - uint
ivecN - uvecN
uint - int
uvecN - ivecN
Fixes Piglit
On 07/26/2011 11:35 PM, Chad Versace wrote:
These fixes are candidates for the stable branches.
Chad Versace (4):
glsl: Document parameters_lists_match()
glsl: Refactor ast_function.cpp:type_compare() into a glsl_type
method
glsl: Fix illegal implicit type conversions
glsl:
Array constructors obey narrower conversion rules than other constructors,
but process_array_constructor() was incorrectly applying the broader
rules. From page 33 (page 39 of the pdf) of the GLSL 1.20 spec, Section
5.4.4 Array Constructors:
Each argument must be the same type as the element
Looks good to me too, and since there were no complaints, pushed.
Thanks.
2011/7/25 Tobias Droste tdro...@gmx.de:
Signed-off-by: Tobias Droste tdro...@gmx.de
Acked-by: Jakob Bornecrantz wallbra...@gmail.com
Reviewed-by: Marek Olšák mar...@gmail.com
---
On 26 July 2011 16:08, Chad Versace c...@chad-versace.us wrote:
The parameters were named 'a' and 'b', but there was no documentation
indicating which was being converted to which. So rename 'a' - 'to' and
'b' - 'from'.
Also add a Doxygen comment.
Signed-off-by: Chad Versace
On Tue, 26 Jul 2011 12:10:20 -0700, Chad Versace c...@chad-versace.us wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
On 07/25/2011 05:06 PM, Kenneth Graunke wrote:
The apitrace dump in bug #34009 managed to fool the draw_offset check
into thinking that we were tile
The constant used in the radians() function didn't have enough
precision, causing a relative error of 1.676e-5, which is far worse
than the precision of 32-bit floats. This patch reduces the relative
error to 1.14e-9, which is the best we can do in 32 bits.
Fixes piglit tests
On 07/27/2011 01:25 AM, Roland Scheidegger wrote:
On 07/26/2011 01:49 AM, Roland Scheidegger wrote:
(Strange thought sent that before - mail client going crazy...)
Resolving color buffers is pretty well defined (for standard
msaa
at
least). I have no idea how that's supposed to be
The previous formula for asin(x) was algebraically equivalent to:
sign(x)*(pi/2 - sqrt(1-|x|)*(A + B|x| + C|x|^2))
where A, B, and C were arbitrary constants determined by a curve fit.
This formula had a worst case absolute error of 0.00448, an unbounded
worst case relative error, and a
On Fri, 2011-07-22 at 18:49 -0700, Eric Anholt wrote:
---
src/glsl/Makefile |1 +
src/mesa/Makefile |5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/glsl/Makefile b/src/glsl/Makefile
index 005b51d..c20a6c9 100644
--- a/src/glsl/Makefile
+++
The previous formula for atan(x,y) returned a value of +/- pi whenever
|x|0.0001, and used a formula based on atan(y/x) otherwise. This
broke in cases where both x and y were small (e.g. atan(1e-5, 1e-5)).
This patch modifies the formula so that it returns a value of +/- pi
whenever |x|1e-8*|y|,
On 07/25/2011 07:08 PM, Eric Anholt wrote:
This was done in the old codegen path, but not the new one.
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
We were neglecting to load dvdx and dvdy. v is not optional.
Fixes piglit tests tex-grad-0[12345].frag on Broadwater/Crestline.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
The purpose of the (irb-draw_offset 4095) != 0 check was to ensure
that we don't have XYy offsets into a tile, since Gen4 hardware doesn't
support that. However, it's insufficient: there are cases where
draw_offset 4095 is 0 but we still have a Y-offset. This leads to an
assertion failure in
On 07/27/2011 11:08 AM, Paul Berry wrote:
The constant used in the radians() function didn't have enough
precision, causing a relative error of 1.676e-5, which is far worse
than the precision of 32-bit floats. This patch reduces the relative
error to 1.14e-9, which is the best we can do in 32
I forgot to mention:
Fixes piglit tests {vs,fs}-asin-float and {vs,fs}-atan-*
On 27 July 2011 15:15, Paul Berry stereotype...@gmail.com wrote:
The previous formula for asin(x) was algebraically equivalent to:
sign(x)*(pi/2 - sqrt(1-|x|)*(A + B|x| + C|x|^2))
where A, B, and C were arbitrary
On Sat, 23 Jul 2011 11:58:22 -0600, Brian Paul brian.e.p...@gmail.com wrote:
On Sat, Jul 23, 2011 at 9:14 AM, Eric Anholt e...@anholt.net wrote:
On Fri, 22 Jul 2011 14:06:48 -0600, Brian Paul bri...@vmware.com wrote:
On 07/22/2011 01:32 PM, Eric Anholt wrote:
On Thu, 23 Jun 2011 19:08:51
On Wed, Jul 27, 2011 at 7:29 PM, Eric Anholt e...@anholt.net wrote:
On Sat, 23 Jul 2011 11:58:22 -0600, Brian Paul brian.e.p...@gmail.com wrote:
On Sat, Jul 23, 2011 at 9:14 AM, Eric Anholt e...@anholt.net wrote:
On Fri, 22 Jul 2011 14:06:48 -0600, Brian Paul bri...@vmware.com wrote:
On
Fixes Piglit tests:
spec/glsl-1.20/compiler/built-in-functions/outerProduct-bvec*.vert
spec/glsl-1.20/compiler/structure-and-array-operations/array-ctor-implicit-conversion-bool-float.vert
This method checks if a source type is identical to or can be implicitly
converted to a target type according to the GLSL 1.20 spec, Section 4.1.10
Implicit Conversions.
The following commits use the method for a bugfix:
glsl: Fix implicit conversions in non-constructor function calls
Context
---
In ast_function_expression::hir(), parameter_lists_match() checks if the
function call's actual parameter list matches the signature's parameter
list, where the match may require implicit conversion of some arguments.
To check if an implicit conversion exists between individual
The function is no longer used and has been replaced by
glsl_type::can_implicitly_convert_to().
Note: This is a candidate for the 7.10 and 7.11 branches.
CC: Ian Romanick ian.d.roman...@intel.com
CC: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
Array constructors obey narrower conversion rules than other constructors
[1] --- they use the implicit conversion rules [2] instead of the scalar
constructor conversions [3]. But process_array_constructor() was
incorrectly applying the broader rules.
To fix this, first check (with
The function used a variable named 'score', which was an outright lie.
A signature matches or it doesn't; there is no fuzzy scoring.
CC: Ian Romanick ian.d.roman...@intel.com
CC: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
src/glsl/ir_function.cpp |
32 matches
Mail list logo
