On 03/12/2013 12:25 PM, Eric Anholt wrote:
This is a more aggressive version of the old brw_optimize() path.
Reduces cycles spent in the vertex shader on minecraft by 18.6% +/- 10.0%
(n=15).
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 109 +++
From: Adhemerval Zanella azane...@linux.vnet.ibm.com
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 a...@redhat.com
Signed-off-by:
From: Adhemerval Zanella azane...@linux.vnet.ibm.com
Reviewed-by: Adam Jackson a...@redhat.com
Signed-off-by: Adhemerval Zanella azane...@linux.vnet.ibm.com
---
src/gallium/auxiliary/gallivm/lp_bld_printf.c | 56 +++
1 file changed, 39 insertions(+), 17 deletions(-)
diff
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
LP64.
---
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 +
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
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 traffic
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
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'll
https://bugs.freedesktop.org/show_bug.cgi?id=62999
--- Comment #1 from Brian Paul bri...@vmware.com ---
Can you attach the output of glxinfo?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
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 thomas.stell...@amd.com
lib/Target/R600/AMDGPU.h | 1 +
lib/Target/R600/AMDGPUTargetMachine.cpp| 1 +
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
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?
https://bugs.freedesktop.org/show_bug.cgi?id=62999
--- Comment #2 from Alexander Monakov amona...@gmail.com ---
(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
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:
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
From: Ian Romanick ian.d.roman...@intel.com
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 ian.d.roman...@intel.com
---
From: Ian Romanick ian.d.roman...@intel.com
A future commit will try to use this function in a different file.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/ast.h | 4
src/glsl/ast_to_hir.cpp | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git
From: Ian Romanick ian.d.roman...@intel.com
That last consumer of the return value was changed to not use it by the
previous commit.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/ast.h | 2 +-
src/glsl/ast_to_hir.cpp | 5 +
2 files changed, 2 insertions(+), 5
From: Ian Romanick ian.d.roman...@intel.com
Also, document the reason for not checking for type-is_array in some of
the bound-checking cases.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/ast_array_index.cpp | 17 -
1 file changed, 8 insertions(+), 9
From: Ian Romanick ian.d.roman...@intel.com
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
From: Ian Romanick ian.d.roman...@intel.com
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
From: Ian Romanick ian.d.roman...@intel.com
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
From: Ian Romanick ian.d.roman...@intel.com
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=62999
gurket...@googlemail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, Apr 01, 2013 at 05:42:43PM +0200, Vincent Lejeune wrote:
---
Reviewed-by: Tom Stellard thomas.stell...@amd.com
lib/Target/R600/AMDGPU.h | 1 +
lib/Target/R600/AMDGPUTargetMachine.cpp| 1 +
lib/Target/R600/MCTargetDesc/R600MCCodeEmitter.cpp |
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
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
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 ian.d.roman...@intel.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 20 +-
https://bugs.freedesktop.org/show_bug.cgi?id=62999
--- Comment #5 from Brian Paul bri...@vmware.com ---
(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
https://bugs.freedesktop.org/show_bug.cgi?id=62999
Alexander Monakov amona...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
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 amona...@gmail.com
Date: Mon, 1
https://bugs.freedesktop.org/show_bug.cgi?id=62999
Alexander Monakov amona...@gmail.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
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
From: Tom Stellard thomas.stell...@amd.com
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
On Tue, Apr 2, 2013 at 3:11 AM, Mark London m...@psfc.mit.edu 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
On Mon, Apr 1, 2013 at 11:05 PM, Alexander Monakov amona...@gmail.com 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
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 bri...@vmware.com
---
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
---
From: Brian Paul bri...@vmware.com
---
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
---
From: Brian Paul bri...@vmware.com
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
Kenneth Graunke kenn...@whitecape.org 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.
---
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
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
Oops. I always forget about that.
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Tue, Apr 2, 2013 at 12:46 AM, Brian Paul brian.e.p...@gmail.com wrote:
From: Brian Paul bri...@vmware.com
The VMware svga driver is picky about making sure the VBO is unmapped
before drawing.
---
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
Kenneth Graunke kenn...@whitecape.org 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
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,
52 matches
Mail list logo
