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.
>
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 ty
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
spec/glsl-1.20/compiler/built-in-functions/outerProduct-bv
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
Signed-off-by: Chad Versace
---
src/glsl/glsl_types.cpp | 304 +
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
---
src/glsl/ir_function.cpp |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
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
src/gl
On 07/26/2011 09:52 PM, Zhao, Jian J wrote:
>> -Original Message-
>> From: mesa-dev-bounces+jian.j.zhao=intel@lists.freedesktop.org
>> [mailto:mesa-dev-bounces+jian.j.zhao=intel@lists.freedesktop.org] On
>> Behalf Of Ian Romanick
>> Sent: Wednesday, July 27, 2011 12:59 AM
>> To: M
> -Original Message-
> From: mesa-dev-bounces+jian.j.zhao=intel@lists.freedesktop.org
> [mailto:mesa-dev-bounces+jian.j.zhao=intel@lists.freedesktop.org] On
> Behalf Of Ian Romanick
> Sent: Wednesday, July 27, 2011 12:59 AM
> To: Marty Jack
> Cc: =?windows-1252?Q?Kristian_H=F8gsber?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
https://bugs.freedesktop.org/show_bug.cgi?id=39490
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
> 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 defined for depth
> >> and stencil values
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.
Note: This is a candidate for the 7.10 and 7.11 branches.
Signed-off-by: Chad Versace
---
src/glsl/ir_fun
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
---
src/glsl/ir_function.cpp | 27 +--
1 files changed,
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
---
src/glsl/ir_function.cpp |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
That looks like it:
Reviewed-by: Jeremy Huddleston
Tested-by: Jeremy Huddleston
You can probably revert the --dereference one as well.
On Jul 26, 2011, at 12:09 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Cc: Jeremy Huddleston
> Cc: Andreas Radke
> ---
> Please let me know if this pa
https://bugs.freedesktop.org/show_bug.cgi?id=39570
Summary: glx-multithread lock during piglit test
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority:
Hi List,
This is just some good news. Recently, I wrote to this list [1]
announcing that as of Firefox 6, we were able to safely detect driver
versions, and consequently many recent system, including Mesa >= 7.10,
were whitelisted. At that time, unfortunately, we were blacklisting Gallium.
T
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 aligned when we weren't. This led to an
> assertion failure in brw_update_renderbuffer_surface with tile_y != 0.
>
> Simply compute tile_x and t
From: Ian Romanick
Cc: Jeremy Huddleston
Cc: Andreas Radke
---
Please let me know if this patch fixes the issue once and for all.
Makefile |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index c142a93..48e779c 100644
--- a/Makefile
+++ b/Makefil
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 defined for depth
>> and stencil values. Frankly I'm not
On 26 July 2011 02:21, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/25/2011 01:23 PM, Henri Verbeet wrote:
>> Without this we'd miss an update when doing a sequence like {COLOR0, COLOR1},
>> {COLOR0}, {COLOR0, COLOR1}.
>
> Is there a piglit test to reproduce this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/26/2011 05:52 AM, Marty Jack wrote:
> Line 1243 of configure.ac says
> if test "x$enable_dri" = xyes; then
> and enable_dri is nowhere defined. In RC2 the equivalent line said
> if test "$mesa_driver" = dri; then
> I do not know what the
On Tue, Jul 26, 2011 at 11:05 AM, Bryan Cain wrote:
> On Mon, Jul 25, 2011 at 9:54 PM, Ian Romanick wrote:
>> The only changes in the 7.11 branch (until the final release) should be
>> low-risk fixes for significant bugs. Other than updates to the release
>> notes and changing the version, RC3 s
On Mon, Jul 25, 2011 at 9:54 PM, Ian Romanick wrote:
> The only changes in the 7.11 branch (until the final release) should be
> low-risk fixes for significant bugs. Other than updates to the release
> notes and changing the version, RC3 should represent 7.11 final.
Would my patches for making G
On 07/26/2011 07:30 AM, Bryan Cain wrote:
On Mon, Jul 25, 2011 at 1:50 PM, Jose Fonseca wrote:
I have no objection FWIW.
Jose
- Original Message -
This is a revised version of my previous patches. Patch 1
incorporates
Brian's feedback, and patch 2 is unchanged from before. I did te
On 07/25/2011 04:39 PM, Eric Anholt wrote:
The FF VS generation happens just after the FF FS generation in
state.c, so the ctx->VP._Current value is for the previous state
update's vertex shader, not the one that will be chosen as a result of
this state update. The vertexShader and vertexProgram
On 07/25/2011 04:39 PM, Eric Anholt wrote:
We have to make it through this loop processing the color multiple
times, so we can't go overwriting it on our first color buffer.
---
src/gallium/drivers/softpipe/sp_quad_blend.c | 16
1 files changed, 12 insertions(+), 4 deletions
On Mon, Jul 25, 2011 at 1:50 PM, Jose Fonseca wrote:
> I have no objection FWIW.
>
> Jose
>
> - Original Message -
>> This is a revised version of my previous patches. Patch 1
>> incorporates
>> Brian's feedback, and patch 2 is unchanged from before. I did test
>> patch 2
>> without patc
On 26/07/2011 00:12, Marek Olšák wrote:
---
configure.ac | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
Tested-by: Jon TURNEY
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/li
On 26/07/2011 00:16, Marek Olšák wrote:
sorry for the late reply. I have just sent a patch to ML which should
fix this. See:
http://lists.freedesktop.org/archives/mesa-dev/2011-July/009867.html
Please let me know if that works for you.
Yes, that fixes it. Thanks very much :-)
___
Line 1243 of configure.ac says
if test "x$enable_dri" = xyes; then
and enable_dri is nowhere defined. In RC2 the equivalent line said
if test "$mesa_driver" = dri; then
I do not know what the appropriate test is.
This results in gbm_dri not being compiled, results in gbm_dri_backend not
https://bugs.freedesktop.org/show_bug.cgi?id=39537
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=39537
Summary: Build error at get vlVaGetVtable
Product: Mesa
Version: git
Platform: Other
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
33 matches
Mail list logo
