Consider the following code:
dp4(8) g8<1>.xF g1<4,4,1>Fg5<4,4,1>F { align16 WE_normal 1Q };
mov(8) m3<1>.xF g8<4,4,1>.xF { align16 WE_normal 1Q };
Thanks to our existing compute-to-MRF code, this becomes:
dp4(8) m3<1>.xF g1<4,4,1>Fg5<4,4,1>F { align16 WE_normal 1
Fix uninitialized scalar field defects reported by Coverity.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Vinson Lee
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/s
- Original Message -
> Jose Fonseca writes:
>
> > - Original Message -
> >> On Wed, Apr 18, 2012 at 07:34:15AM -0700, Jose Fonseca wrote:
> >> > - Original Message -
> >> > > On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez
> >> > > wrote:
> >> > > > Jose Fonseca
On Wed, Apr 18, 2012 at 06:40:32PM -0700, Eric Anholt wrote:
> +mat3 inverse(mat3 m)
> +{
> + mat3 adj;
> + adj[0][0] = + (m[1][1] * m[2][2] - m[2][1] * m[1][2]);
> + adj[1][0] = - (m[1][0] * m[2][2] - m[2][0] * m[1][2]);
> + adj[2][0] = + (m[1][0] * m[2][1] - m[2][0] * m[1][1]);
> + adj[
---
src/gallium/drivers/r300/Makefile.am |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/r300/Makefile.am
b/src/gallium/drivers/r300/Makefile.am
index af352aa..c4ee08c 100644
--- a/src/gallium/drivers/r300/Makefile.am
+++ b/src/gallium/drivers/r300/Ma
I didn't check any other drivers besides r300g. I hope CFLAGS is not the only
variable containing the -O2 flag...
---
src/gallium/drivers/r600/Makefile.am |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/r600/Makefile.am
b/src/gallium/drivers/r600/Make
On 04/17/2012 11:49 PM, Vinson Lee wrote:
Fix uninitialized pointer field defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/glsl/opt_array_splitting.cpp |1 +
1 file changed, 1 insertion(+)
diff --git a/src/glsl/opt_array_splitting.cpp b/src/glsl/opt_array_splitting.cpp
inde
On 04/18/2012 06:40 PM, Eric Anholt wrote:
This takes advantage of the builtin compiler to generate IR into a
string, the same way we read GLSL for function prototypes for our
profiles.
---
src/glsl/builtins/tools/generate_builtins.py | 20
1 file changed, 16 insertions(
This takes advantage of the builtin compiler to generate IR into a
string, the same way we read GLSL for function prototypes for our
profiles.
---
src/glsl/builtins/tools/generate_builtins.py | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/glsl/built
This lets ir_reader eat the output of builtin_compiler on actual
function definitions.
---
src/glsl/ir_reader.cpp |2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/ir_reader.cpp b/src/glsl/ir_reader.cpp
index 7ce683e..03dbb67 100644
--- a/src/glsl/ir_reader.cpp
+++ b/src/glsl/ir_re
This is taken from the ogl-math project, with Inverse renamed to adj
(since it's not actually the inverse), transposed, and our types
plugged in.
Fixes piglit inverse tests.
---
src/glsl/Makefile |2 +-
src/glsl/builtins/glsl/inverse.glsl | 105 +
I keep getting lost in the Makefile trying to figure out what to edit
to work on builtin_compiler or glsl_compiler.
---
src/glsl/main.cpp |9 +
1 file changed, 9 insertions(+)
diff --git a/src/glsl/main.cpp b/src/glsl/main.cpp
index 3231b1b..64c2496 100644
--- a/src/glsl/main.cpp
+++
On 2012-04-18 09:48-0400, Adam Jackson wrote:
On Tue, 2012-04-17 at 23:53 +1000, jupiter@gmail.com wrote:
On 2012-04-17 09:34-0400, Adam Jackson wrote:
>Note that neither one of the above libraries is mentioned in your ldd
>output, which means libGL was linked incorrectly. What method did y
Tom Stellard writes:
> On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote:
>> Jose Fonseca writes:
>>[...]
>> > and how would this scheme work, e.g., if a driver wanted to consume
>> > GLSL IR in the future.
>>
>> Hm, I'm not convinced that letting a driver consume GLSL IR would be
https://bugs.freedesktop.org/show_bug.cgi?id=48899
--- Comment #2 from Andrew Randrianasulu 2012-04-18 17:19:42
UTC ---
Mesa's compilation line was:
make distclean && ./autogen.sh --prefix=/usr/X11R7 --disable-egl
--enable-gallium-llvm --with-gallium-drivers="i915 nouveau r600 r300 swrast"
--en
https://bugs.freedesktop.org/show_bug.cgi?id=48899
--- Comment #1 from Andrew Randrianasulu 2012-04-18 17:18:08
PDT ---
Created attachment 60288
--> https://bugs.freedesktop.org/attachment.cgi?id=60288
glxinfo log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=48899
Bug #: 48899
Summary: llvmpipe doesn't work with wine 1.5.2 and 3Dmark2001se
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Jose Fonseca writes:
> - Original Message -
>> On Wed, Apr 18, 2012 at 07:34:15AM -0700, Jose Fonseca wrote:
>> > - Original Message -
>> > > On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote:
>> > > > Jose Fonseca writes:
>> > > > >[...]
>> > > > > I think that an
Ok, great. Do you have any idea if RENDERBUFFER_SAMPLES will return the lie or
0/1?
-Jeff
- Original Message -
From: "Eric Anholt"
To: "Jeff Gilbert" , "Benoit Jacob"
Cc: mesa-dev@lists.freedesktop.org
Sent: Wednesday, April 18, 2012 3:07:17 PM
Subject: Re: [Mesa-dev] WebGL WG interest
I was just looking at this. The release notes say the "ARM backend
has basic support for integer code", but even that appears to be
broken, at least for vector types. For the first case of
lp_test_conv, with this IR:
define void @test(<8 x i16>*, <4 x i32>*) {
entry:
%2 = getelementptr <8 x i1
It depends how much of the spec its in violation of.
Hopefully, querying GL_RENDERBUFFER_SAMPLES on the RB should show it with 0 or
1 sample(s). Per spec, this is not okay, since RENDERBUFFER_SAMPLES is
guaranteed to be >= the 'samples' value used at allocation, but at least 0 or 1
would reflec
Hello,
Is it possible to use llvmpipe enabled mesa for ARM cortex-9. ??
If yes,then please give me info.
If no,then when it will be possible.
Thanks
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
On Wed, 18 Apr 2012 15:43:07 -0700 (PDT), Jeff Gilbert
wrote:
> Ok, great. Do you have any idea if RENDERBUFFER_SAMPLES will return the lie
> or 0/1?
It returns the lie.
pgpCRp8B2gGnI.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev
On Wed, 18 Apr 2012 03:32:46 -0700 (PDT), Jeff Gilbert
wrote:
> It depends how much of the spec its in violation of.
>
> Hopefully, querying GL_RENDERBUFFER_SAMPLES on the RB should show it
> with 0 or 1 sample(s). Per spec, this is not okay, since
> RENDERBUFFER_SAMPLES is guaranteed to be >= t
On 04/18/2012 11:28 AM, Mathias Fröhlich wrote:
Hi,
The attached change uses the array object factory for gl_array_objects. This
prevents crashes when deriving from gl_array_object.
The change should be orthogonal to Mareks posted changes.
Please Review.
From 2f8f27281f44142edd258a62eff6be
Hi,
On Wednesday, April 18, 2012 10:49:41 Brian Paul wrote:
> From: Brian Paul
>
> The field wasn't actually used before and it's not used now either.
> But this is a more logical place for it and will hopefully allow
> doing smarter draw/array validation (per array object) in the future.
Revi
- Original Message -
> On Wed, Apr 18, 2012 at 10:05:58AM -0700, Jose Fonseca wrote:
> > This idea of passing GLSL IR assumes that GLSL IR would grow to be
> > generic enough to represent any shader, and not just GLSL derived
> > ones.
>
> What would be missing from a IR covering GLSL 4.2?
Hi,
The attached change uses the array object factory for gl_array_objects. This
prevents crashes when deriving from gl_array_object.
The change should be orthogonal to Mareks posted changes.
Please Review.
Thanks
Mathias>From 2f8f27281f44142edd258a62eff6be1fe7f413d8 Mon Sep 17 00:00:00 2001
Hi,
On Wednesday, April 18, 2012 10:41:56 Brian Paul wrote:
> Yes. I actually started some work on that a while back but never got
> back to it. I don't think there'd be any harm in moving the field so
> I'll go dig up that patch.
>
> My goal was to explore having an st_array_object subclass o
On Wed, Apr 18, 2012 at 10:05:58AM -0700, Jose Fonseca wrote:
> This idea of passing GLSL IR assumes that GLSL IR would grow to be
> generic enough to represent any shader, and not just GLSL derived
> ones.
What would be missing from a IR covering GLSL 4.2? Some types maybe?
OG.
__
- Original Message -
> On Wed, Apr 18, 2012 at 07:34:15AM -0700, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> > > On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote:
> > > > Jose Fonseca writes:
> > > >
> > > > > Francisco,
> > > > >
> > > > > Sorry for
- Original Message -
> Jose Fonseca writes:
>
> > Francisco,
> >
> > Sorry for the delay reviewing this, but I haven't been able to
> > dedicate some time until now.
> >
> > Overall, it's a great piece of work! Just a few relatively minor
> > comments/requests.
> >
>
> Hi Jose, thanks
- Original Message -
> On Wed, Apr 18, 2012 at 5:06 PM, Jose Fonseca
> wrote:
> > Marek,
> >
> > Sorry for not noticing earlier ( I haven't been able to keep up
> > with mesa traffic lately), but I'm afraid this and the 10/10 are
> > not ok, as on several operating systems, namely, Windows
From: Brian Paul
The field wasn't actually used before and it's not used now either.
But this is a more logical place for it and will hopefully allow
doing smarter draw/array validation (per array object) in the future.
---
src/mesa/main/arrayobj.c |1 -
src/mesa/main/attrib.c |3 ++-
On 04/18/2012 10:28 AM, Mathias Fröhlich wrote:
Hi,
On Wednesday, April 18, 2012 18:22:48 Marek Olšák wrote:
BTW, the gl_array_attrib::NewState field is assigned to but never used
anywhere. Want to remove it too?
Hi Brian,
I didn't remove it because I thought it would be useful in the futu
On Wed, Apr 18, 2012 at 5:06 PM, Jose Fonseca wrote:
> Marek,
>
> Sorry for not noticing earlier ( I haven't been able to keep up with mesa
> traffic lately), but I'm afraid this and the 10/10 are not ok, as on several
> operating systems, namely, Windows WDDM, it is illegal to flush a command
Hi,
On Wednesday, April 18, 2012 18:22:48 Marek Olšák wrote:
> > BTW, the gl_array_attrib::NewState field is assigned to but never used
> > anywhere. Want to remove it too?
>
> Hi Brian,
>
> I didn't remove it because I thought it would be useful in the future.
> I wouldn't oppose somebody els
Hi,
That's actually a nice cleanup. There's a plenty potential for speeding up
this area, but I did not find time to complete what I had/have in mind!
For the series:
Reviewed-by: Mathias Fröhlich
Thanks!
Mathias
___
mesa-dev mailing list
mesa-dev@
On Wed, Apr 18, 2012 at 5:02 PM, Brian Paul wrote:
> On 04/18/2012 08:16 AM, Marek Olšák wrote:
>>
>> ---
>> src/mesa/state_tracker/st_context.h | 12 ++--
>> 1 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/mesa/state_tracker/st_context.h
>> b/src/mesa/state_trac
Am 18.04.2012 14:02, schrieb Vijay:
> Hello,
> Can we use llvmpipe for arm architecture.(Specifically ARM cortexA-9) ??
>
> I tried & found below error.
>
> Unhandled instruction encoding format!
> UNREACHABLE executed at ARMCodeEmitter.cpp:534!
> Aborted
>
> Version used : llvmpipe3.0,Mesa-8.0
On Wed, Apr 18, 2012 at 07:34:15AM -0700, Jose Fonseca wrote:
>
>
> - Original Message -
> > On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote:
> > > Jose Fonseca writes:
> > >
> > > > Francisco,
> > > >
> > > > Sorry for the delay reviewing this, but I haven't been able
Marek,
Sorry for not noticing earlier ( I haven't been able to keep up with mesa
traffic lately), but I'm afraid this and the 10/10 are not ok, as on several
operating systems, namely, Windows WDDM, it is illegal to flush a command
buffer with a buffer mapped.
Jose
- Original Message ---
On Thu, Apr 12, 2012 at 4:13 AM, Brian Paul wrote:
> On Wed, Apr 11, 2012 at 9:38 AM, Marek Olšák wrote:
>> This makes u_vbuf_mgr call the driver instead of the other way around.
>> ---
>> src/gallium/auxiliary/util/u_vbuf.c | 35
>> ++---
>> src/gallium/auxiliary
On 04/18/2012 08:16 AM, Marek Olšák wrote:
---
src/mesa/state_tracker/st_context.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_context.h
b/src/mesa/state_tracker/st_context.h
index da03719..3d41ab5 100644
--- a/src/mesa/state_t
- Original Message -
> On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote:
> > Jose Fonseca writes:
> >
> > > Francisco,
> > >
> > > Sorry for the delay reviewing this, but I haven't been able to
> > > dedicate some time until now.
> > >
> > > Overall, it's a great piece o
On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote:
> Jose Fonseca writes:
>
> > Francisco,
> >
> > Sorry for the delay reviewing this, but I haven't been able to dedicate
> > some time until now.
> >
> > Overall, it's a great piece of work! Just a few relatively minor
> > comment
---
src/mesa/vbo/vbo_context.c|7 ++-
src/mesa/vbo/vbo_context.h|4
src/mesa/vbo/vbo_exec_array.c |3 ++-
src/mesa/vbo/vbo_exec_draw.c |3 ++-
src/mesa/vbo/vbo_save_draw.c |3 ++-
5 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/src/mesa/vbo/vb
---
src/mesa/vbo/vbo_context.c|3 +--
src/mesa/vbo/vbo_context.h|1 -
src/mesa/vbo/vbo_exec_api.c |6 --
src/mesa/vbo/vbo_exec_array.c |6 +++---
src/mesa/vbo/vbo_exec_draw.c |3 ++-
src/mesa/vbo/vbo_save.c |6 --
src/mesa/vbo/vbo_save_draw.c |
It's not nice when you have several variables pointing to the same array
and you wanna ask your editor "where is this used" and you only get an answer
for one of the four currval, legacy_currval, generic_currval, mat_currval,
which is quite useless, because you never see the whole picture.
Let's g
---
src/mesa/vbo/vbo_context.h |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/src/mesa/vbo/vbo_context.h b/src/mesa/vbo/vbo_context.h
index 1a1cc92..cae2407 100644
--- a/src/mesa/vbo/vbo_context.h
+++ b/src/mesa/vbo/vbo_context.h
@@ -71,10 +71,6 @@ struct vbo_context {
It's already done in _mesa_validate_Draw* and it's not needed to do it again
unless I am missing something.
---
src/mesa/vbo/vbo_exec_array.c | 20
1 files changed, 0 insertions(+), 20 deletions(-)
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
i
---
src/mesa/main/state.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index 627bf83..6efc45a 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -627,7 +627,16 @@ _mesa_set_varying_vp_inputs( struct
This is a frequently-updated state and _NEW_ARRAY already causes revalidation
of the vbo module. It's kinda counter-productive to recompute arrays
in the vbo module if _NEW_ARRAY is set and then set _NEW_ARRAY again.
---
src/mesa/main/ff_fragment_shader.cpp |2 +-
src/mesa/main/mtypes.h
This moves the RebindArrays flag into the vbo module, consolidates the code,
and adds missing vbo_draw_method calls.
Also with this change, the vertex arrays are not needlessly recalculated twice.
The issue with the old code was:
- If recalculate_input_bindings updates vp_varying_inputs, _NEW_ARRA
---
src/mesa/main/state.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index b019266..2e9f021 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -561,8 +561,10 @@ _mesa_update_state_locked( struct gl_contex
---
src/mesa/state_tracker/st_context.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_context.h
b/src/mesa/state_tracker/st_context.h
index da03719..3d41ab5 100644
--- a/src/mesa/state_tracker/st_context.h
+++ b/src/mesa/state_tracke
On Tue, 2012-04-17 at 23:53 +1000, jupiter@gmail.com wrote:
> On 2012-04-17 09:34-0400, Adam Jackson wrote:
> >Note that neither one of the above libraries is mentioned in your ldd
> >output, which means libGL was linked incorrectly. What method did you
> >use to build Mesa?
>
> The default o
Hi everybody,
first of all I apologize if this is not the right place for this
question but I couldn't find
any answer in other places and I think this is a good question about
DRI. I also apologize
for the length of the question!
For a security application I'm developing I need direct access to t
- Original Message -
> Hello,
> Can we use llvmpipe for arm architecture.(Specifically ARM cortexA-9)
> ??
It has never been tried before, so have no idea how close it is of working.
> I tried & found below error.
>
> Unhandled instruction encoding format!
> UNREACHABLE executed at ARM
Hello,
Can we use llvmpipe for arm architecture.(Specifically ARM cortexA-9) ??
I tried & found below error.
Unhandled instruction encoding format!
UNREACHABLE executed at ARMCodeEmitter.cpp:534!
Aborted
Version used : llvmpipe3.0,Mesa-8.0
Any hint or info will be helpfull.
Thanks..
___
https://bugs.freedesktop.org/show_bug.cgi?id=48788
Michel Dänzer changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
61 matches
Mail list logo
