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
https://bugs.freedesktop.org/show_bug.cgi?id=39537
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
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 :-)
___
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 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 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 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/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 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 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
-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 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
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
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/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
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
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:
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
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(-)
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,
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
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=39490
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
-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
> -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?
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
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
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(-)
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 +
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
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
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.
>
33 matches
Mail list logo
