From: Adhemerval Zanella
This adds another rounding mode to the enum, which happens otherwise to
match SSE4.1's rounding modes. This should be safe as long as the
IROUND case never hits the SSE4.1 path.
Reviewed-by: Adam Jackson
Signed-off-by: Adhemerval Zanella
---
src/gallium/auxiliary/gal
From: Adhemerval Zanella
Reviewed-by: Adam Jackson
Signed-off-by: Adhemerval Zanella
---
src/gallium/auxiliary/gallivm/lp_bld_printf.c | 56 +++
1 file changed, 39 insertions(+), 17 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_printf.c
b/src/gallium/
On Mon, 2013-04-01 at 13:04 +1300, Chris Forbes wrote:
> @@ -38,6 +38,7 @@ struct cache_item
> {
> GLuint hash;
> void *key;
> + GLuint keysize;
> struct gl_program *program;
> struct cache_item *next;
> };
Since GLuint is 32 bits, this creates another hole in the struct on
LP
---
lib/Target/R600/AMDGPU.h | 1 +
lib/Target/R600/AMDGPUTargetMachine.cpp| 1 +
lib/Target/R600/MCTargetDesc/R600MCCodeEmitter.cpp | 21 +-
lib/Target/R600/R600ControlFlowFinalizer.cpp | 264 +
lib/Target/R600/R600Instructions.
https://bugs.freedesktop.org/show_bug.cgi?id=62999
Priority: medium
Bug ID: 62999
Assignee: mesa-dev@lists.freedesktop.org
Summary: glXChooseFBConfig with GLX_DRAWABLE_TYPE,
GLX_DONT_CARE fails
Severity: normal
Classifica
Sorry to post this here, but no one answered me on the mesa-users
mailing list.
A recent update of mesa-dri-drivers on Redhat 6 (upgraded 7 to 9),
removed the nouveau_dri.so file, which libGl uses. Does anyone know why
Redhat might have done this? I've looked through redhat's bugzilla, but
On Fri, Mar 29, 2013 at 12:32:19PM +, Mike Lothian wrote:
> Sorry that patch doesn't fix the build
>
> diff -Naur a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
On Sun, Mar 31, 2013 at 02:26:00PM +0200, Armin K. wrote:
> Dana 31.3.2013 14:21, Mike Lothian je napisao:
> >I've already posted this
> >
> >Clover seems to be working as well as it normally does
> >
> >
>
> Doh, and I thought I looked at mesa-dev for a patch. It's hard to
> find it on such high
On 03/29/2013 05:30 PM, Brian Paul wrote:
Has this bug been reported to the Topogun developer?
---
src/mesa/drivers/dri/common/drirc |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/common/drirc
b/src/mesa/drivers/dri/common/drirc
index a139
On 03/30/2013 04:26 AM, Dragomir Ivanov wrote:
I don't know OpenGL very much, but can uniforms be more than 10? So you
can have "[24]" where you will need +4, not +3.
The query gives back the name that is the base of the array, not the
declaration. No matter what size the array "foo" is, you'
https://bugs.freedesktop.org/show_bug.cgi?id=62999
--- Comment #1 from Brian Paul ---
Can you attach the output of glxinfo?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.
On Thu, Mar 28, 2013 at 06:47:37PM +0100, Vincent Lejeune wrote:
> ---
Don't forget about the change suggested by Vadim.
Reviewed-by: Tom Stellard
> lib/Target/R600/AMDGPU.h | 1 +
> lib/Target/R600/AMDGPUTargetMachine.cpp| 1 +
> lib/Target/R600/MCTar
On 03/29/2013 06:22 PM, Haixia Shi wrote:
If the active uniform is an array, then the length of the uniform name should
include the three extra characters for the "[0]" suffix, which is required by
the GL 4.2 spec to be appended to the uniform name in glGetActiveUniform().
Do we have a piglit t
On 04/01/2013 10:11 AM, Mark London wrote:
Sorry to post this here, but no one answered me on the mesa-users
mailing list.
A recent update of mesa-dri-drivers on Redhat 6 (upgraded 7 to 9),
removed the nouveau_dri.so file, which libGl uses. Does anyone know why
Redhat might have done this? I'v
https://bugs.freedesktop.org/show_bug.cgi?id=62999
--- Comment #2 from Alexander Monakov ---
(In reply to comment #1)
> Can you attach the output of glxinfo?
I don't want to sound arrogant, but I fail to see how that would be relevant.
In http://cgit.freedesktop.org/mesa/mesa/tree/src/glx/glxcm
On 03/31/2013 05:04 PM, Chris Forbes wrote:
Reported-by: `per` in #intel-gfx
The size of the cache key varies, so store the actual size as well as
the key blob itself, rather than just assuming it's the same as the size
passed in.
NOTE: This is a candidate for stable branches.
Signed-off-by: C
This is the second and final batch of refactors before the substantive
changes. These patches basically:
1. Move some code from ast_to_hir.cpp to a new file.
2. Change around a bunch of error checks around array dereferences.
___
mesa-dev mailing list
From: Ian Romanick
I love 800+ line switch-statements as much as the next guy... Future
commits will make changes to this part of the AST-to-HIR conversion, and
extracting this code will make that a bit easier.
Signed-off-by: Ian Romanick
---
src/glsl/Makefile.sources| 1 +
src/glsl/ast.
From: Ian Romanick
A future commit will try to use this function in a different file.
Signed-off-by: Ian Romanick
---
src/glsl/ast.h | 4
src/glsl/ast_to_hir.cpp | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index fcc6b45..3
From: Ian Romanick
That last consumer of the return value was changed to not use it by the
previous commit.
Signed-off-by: Ian Romanick
---
src/glsl/ast.h | 2 +-
src/glsl/ast_to_hir.cpp | 5 +
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/glsl/ast.h b/src/gls
From: Ian Romanick
Also, document the reason for not checking for type->is_array in some of
the bound-checking cases.
Signed-off-by: Ian Romanick
---
src/glsl/ast_array_index.cpp | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/src/glsl/ast_array_index.cpp
From: Ian Romanick
This puts all of the checks togeher for easier reading. It also means
that all the checks are blocked on array->type->is_array. Shortly this
will allow elimination of some is_error check work-arounds in this
function.
Signed-off-by: Ian Romanick
---
src/glsl/ast_array_inde
From: Ian Romanick
Check the type of the array operand and the index operand before doing
other checks. This simplifies the code a bit now (eliminating the
error_emitted parameter), and enables some later functional changes.
The shader
uniform float x[6];
uniform sampler2D s;
void main() { gl_
From: Ian Romanick
The error_emitted flag is used in semantic checking to prevent spurious
cascading errors. For example,
void foo(sampler2D s, float a)
{
float x = a + (1.2 + s);
...
}
should only generate a single error. Without the error_emitted flag for
the first error, "a + ..."
From: Ian Romanick
Previously the shader
uniform float x[6];
void main() { gl_Position.x = x[1.0]; }
would have generated the errors
0:2(33): error: array index must be integer type
0:2(36): error: array index must be < 6
Now only
0:2(33): error: array index must be integer type
will be gen
On 03/29/2013 02:13 PM, Paul Berry wrote:
Mesa constant-folds built-in functions by using a miniature GLSL
interpreter (see
ir_function_signature::constant_expression_evaluate_expression_list()).
This interpreter had a bug in its handling of array indexing, which
caused expressions like "m[i][j]"
https://bugs.freedesktop.org/show_bug.cgi?id=62999
--- Comment #3 from gurket...@googlemail.com ---
Dupe of bug 47478 .
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
h
https://bugs.freedesktop.org/show_bug.cgi?id=62999
gurket...@googlemail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
On Mon, Apr 01, 2013 at 05:42:43PM +0200, Vincent Lejeune wrote:
> ---
Reviewed-by: Tom Stellard
> lib/Target/R600/AMDGPU.h | 1 +
> lib/Target/R600/AMDGPUTargetMachine.cpp| 1 +
> lib/Target/R600/MCTargetDesc/R600MCCodeEmitter.cpp | 21 +-
> lib/Targe
On 04/01/2013 11:19 AM, Ian Romanick wrote:
On 04/01/2013 10:11 AM, Mark London wrote:
Sorry to post this here, but no one answered me on the mesa-users
mailing list.
A recent update of mesa-dri-drivers on Redhat 6 (upgraded 7 to 9),
removed the nouveau_dri.so file, which libGl uses. Does anyo
On 04/01/2013 11:30 AM, Ian Romanick wrote:
On 03/29/2013 02:13 PM, Paul Berry wrote:
Mesa constant-folds built-in functions by using a miniature GLSL
interpreter (see
ir_function_signature::constant_expression_evaluate_expression_list()).
This interpreter had a bug in its handling of array inde
On 03/12/2013 12:25 PM, Eric Anholt wrote:
I'd previously added the minimum names to understand my dumps, but this
makes dumps in general much easier to read.
Series is
Reviewed-by: Ian Romanick
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 20 +-
src/mesa/drivers/dri/i965/brw_sha
https://bugs.freedesktop.org/show_bug.cgi?id=62999
--- Comment #5 from Brian Paul ---
(In reply to comment #2)
> (In reply to comment #1)
> > Can you attach the output of glxinfo?
>
> I don't want to sound arrogant, but I fail to see how that would be relevant.
>
> In http://cgit.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=62999
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICAT
https://bugs.freedesktop.org/show_bug.cgi?id=47478
https://bugs.freedesktop.org/show_bug.cgi?id=62999 (dup of the above)
I don't have commit access so please push if OK.
From 3e23a23ec8a3bc36e13efc7cf95229e9e31955f1 Mon Sep 17 00:00:00 2001
From: Alexander Monakov
Date: Mon, 1 Apr 2013 23:00:10 +
https://bugs.freedesktop.org/show_bug.cgi?id=62999
Alexander Monakov changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
Btw where can I find some more info on stack_size ?
I assumed it should represent the amout of max stacked exec_mask,
but it looks like it is possible to have much more "manually" pushed exec_mask
level
than reported by nstack (iiuc a push count as much as a 1/4 of a loop level).
- Mail or
From: Tom Stellard
Building libradeonllvm as a shared object has led to a number of bugs
and build system complications, and I don't think it's necessary for
such a small library.
This library was originally changed to a shared object to work around
linker error in egl_static.so, but these appea
On Tue, Apr 2, 2013 at 3:11 AM, Mark London wrote:
> Sorry to post this here, but no one answered me on the mesa-users mailing
> list.
>
> A recent update of mesa-dri-drivers on Redhat 6 (upgraded 7 to 9), removed
> the nouveau_dri.so file, which libGl uses. Does anyone know why Redhat
> might h
On Mon, Apr 1, 2013 at 11:05 PM, Alexander Monakov wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=47478
> https://bugs.freedesktop.org/show_bug.cgi?id=62999 (dup of the above)
>
> I don't have commit access so please push if OK.
Hm, now I see that MATCH_EXACT is used only in special cases,
On 04/02/2013 12:48 AM, Vincent Lejeune wrote:
Btw where can I find some more info on stack_size ?
I assumed it should represent the amout of max stacked exec_mask,
but it looks like it is possible to have much more "manually" pushed exec_mask
level
than reported by nstack (iiuc a push count as
From: Brian Paul
---
src/gallium/auxiliary/draw/draw_pipe_pstipple.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
index e4c5e73..808c7cd 100644
--- a/src/gallium/auxiliary
From: Brian Paul
---
src/gallium/auxiliary/hud/font.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/hud/font.c b/src/gallium/auxiliary/hud/font.c
index 5c4a4d0..6747874 100644
--- a/src/gallium/auxiliary/hud/font.c
+++ b/src/galliu
From: Brian Paul
The VMware svga driver is picky about making sure the VBO is unmapped
before drawing.
---
src/gallium/auxiliary/hud/hud_context.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 60
Kenneth Graunke writes:
> On 03/20/2013 05:36 PM, Eric Anholt wrote:
>> For sampler messages, it depends on the target gen, and on gen4
>> SIMD16-sampler-on-SIMD8-execution we were returning 4 instead of 8 like we
>> should.
>>
>> NOTE: This is a candidate for the 9.1 branch.
>> ---
>> src/mesa
On 03/01/2013 02:05 AM, Aras Pranckevicius wrote:
Hi,
A fix for lower_jumps progress reporting, very much like similar in
c1e591eed:
http://cgit.freedesktop.org/mesa/mesa/commit/src/glsl/lower_variable_index_to_cond_assign.cpp?id=c1e591eed
Sorry for the lag... I just pushed this patch with min
Have you checked the font is rendered correctly? The font should be
transparent and the blend function reads the alpha channel to determine the
transparency, so A8 would be a better option. If that isn't an option
either, the fragment shader should do . swizzling.
Marek
On Tue, Apr 2, 2013 a
Oops. I always forget about that.
Reviewed-by: Marek Olšák
Marek
On Tue, Apr 2, 2013 at 12:46 AM, Brian Paul wrote:
> From: Brian Paul
>
> The VMware svga driver is picky about making sure the VBO is unmapped
> before drawing.
> ---
> src/gallium/auxiliary/hud/hud_context.c |3 +++
> 1
On 04/01/2013 06:18 PM, Marek Olšák wrote:
Have you checked the font is rendered correctly?
Yeah, it works fine.
The font should be
transparent and the blend function reads the alpha channel to
determine the transparency, so A8 would be a better option. If that
isn't an option either, the fr
Kenneth Graunke writes:
> On 03/20/2013 05:37 PM, Eric Anholt wrote:
>> This comes at a minor performance cost at the moment (-3.2% +/- 0.2%, n=14 on
>> my GM45 forced to load all uniforms through the varying-index path), but we
>> get a whole vec4 at a time to reuse in the next commit.
>>
>> NOT
I use a simple texturing fragment shader and the equation "src*a +
dst*(1-a)" for blending.
Sorry A8 is probably wrong too, because the text would be black (it's
(0,0,0,A), not (1,1,1,A)). I'll write a patch to use swizzling in the
fragment shader instead.
Marek
On Tue, Apr 2, 2013 at 2:33 AM,
This allows using L8 and R8 for the font if I8 isn't supported.
---
src/gallium/auxiliary/hud/hud_context.c | 36 +--
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
inde
If the active uniform is an array, then the length of the uniform name should
include the three extra characters for the "[0]" suffix, which is required by
the GL 4.2 spec to be appended to the uniform name in glGetActiveUniform().
This avoids the situation where the output buffer does not have en
Tests?
-- Sean Silva
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
54 matches
Mail list logo
