Re: [Mesa-dev] glsl2: optimizing unused struct assignments

[Aras Pranckevicius]

> Pushed a change that cleans up the shader you pasted.  Mostly.  There's
> still some junk in it that we could do better at.  Results below.

Very nice, thanks!


> By the way, it would be useful to get some examples of your shaders as
> shader_runner tests in piglit.  That makes them easy to analyze for
> optimization opportunities, and they serve as regression tests to make
> sure we don't break your shaders.  Would you be up for making some of
> those?

I don't quite know what piglit or shader_runner is... I guess it's
stuff here: http://cgit.freedesktop.org/piglit/tree/tests/shaders ?

I do have about 500 random shaders from Unity here:
http://github.com/aras-p/glsl-optimizer/tree/glsl2/src/glsl/optimizer-tests/
(the *-in.txt files), but to prepare them for piglit I'd have to think
up some instructions to draw something and inspect the pixel values,
right?


-- 
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH-RFC] draw: Rewrite primitive decomposer

[Henri Verbeet]

On 5 August 2010 18:51, Chia-I Wu  wrote:
> The GL rule is last vertex last for each primitive.  The D3D rule is first
> vertex first.  My idea is to have draw_decompose_tmp.h use a local variable,
> last_vertex_last, to select the rules.  In draw_gs_tmp.h and
> draw_so_emit_tmp.h, last_vertex_last is TRUE when the new settable flags is
> TRUE.  However, in draw_pt_decompse.h, where the rules no longer matter,
> last_vertex_last is set to !(flatshade && flatshade_first).
>
Doesn't ARB_provoking_vertex control that for GL?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl2: fix inlining with samplers (iterator next() were missing)

[Aras Pranckevicius]

Hi,

Attached patch fixes GLSL2 inlining where samplers are involved. Broke
with 199c441239762eec.

--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info


ir_function_inlining-looks-like-iterator-next-were-m.patch
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VTK Offscreen Segfaults

[Kevin H. Hobbs]

On 08/05/2010 07:07 PM, tom fogal wrote:
> Brian Paul  writes:
> [snip]
>   
>> My other hunch is something is duplicated in the libOSMesa and libGL
>> libraries that's causing things to blow up in general.
>> 
> Do note that both of these issues are from the pre-"-fvisibility=hidden
> by default" days, which I was hoping/thinking would fix
> things... haven't looked into it though.  It was also
> previous to Dan's recent 'change how libOSMesa is linked' fix
> (cbf30fce322506bd43692617de9d201533f41532)... but that commit is also
> required to fix a Mac linking issue, so I wouldn't advocate throwing it
> away for 7.8.
>   

Although I noticed the segfault with mesa configured and built with :

./autogen.sh \
  --with-driver=xlib \
  --disable-gallium \
  --without-demos
make -j 8

Because I have never been able to produce a working offscreen VTK with
mesa configured this way, and since -fvisibility=hidden was added the
./autogen.sh way did not even build VTK untill the
cbf30fce322506bd43692617de9d201533f41532 change. and that was about the
same time that offscreen rendering stopped working for me no matter how
I built mesa, my git bisect script uses :

make -j8  linux-x86-64-debug

so -fvisibility=hidden is not added to the command line of the builds in
the git bisection.



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29407] llvm 2.8 asserts: "Tried to create an integer operation on a non-integer type!"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29407

nobled  changed:

   What|Removed |Added

  Attachment #37590|0   |1
is obsolete||

--- Comment #4 from nobled  2010-08-06 04:46:42 PDT ---
Created an attachment (id=37630)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37630
 Review: https://bugs.freedesktop.org/review?bug=29407&attachment=37630

gallivm: Always use floating point operators for floating point values (v2)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29407] llvm 2.8 asserts: "Tried to create an integer operation on a non-integer type!"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29407

--- Comment #5 from nobled  2010-08-06 04:49:01 PDT ---
Created an attachment (id=37631)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37631
 Review: https://bugs.freedesktop.org/review?bug=29407&attachment=37631

llvmpipe: Use floating-point operators for floating-point types

These two patches together fix all the places that seemed to be going wrong.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29407] llvm 2.8 asserts: "Tried to create an integer operation on a non-integer type!"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29407

--- Comment #6 from steckde...@yahoo.fr 2010-08-06 05:53:16 PDT ---
Created an attachment (id=37636)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37636)
Output of glxgears when using llvmpipe

Hello,

Thank you for your patch, the situation improved, but one small error message
is still there : it seems you have replaced too many i32 instructions with
their f32 counterpart.

I attached the output of glxgears when running with llvmpipe to this bug
report. I have applied you two patches, and I run Mesa Master ("draw: Avoid
mixed declarations and code.").

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH-RFC] draw: Rewrite primitive decomposer

[Chia-I Wu]

On Fri, Aug 6, 2010 at 6:03 PM, Henri Verbeet  wrote:
> On 5 August 2010 18:51, Chia-I Wu  wrote:
>> The GL rule is last vertex last for each primitive.  The D3D rule is first
>> vertex first.  My idea is to have draw_decompose_tmp.h use a local variable,
>> last_vertex_last, to select the rules.  In draw_gs_tmp.h and
>> draw_so_emit_tmp.h, last_vertex_last is TRUE when the new settable flags is
>> TRUE.  However, in draw_pt_decompse.h, where the rules no longer matter,
>> last_vertex_last is set to !(flatshade && flatshade_first).
> Doesn't ARB_provoking_vertex control that for GL?
The decomposers are using the provoking convention to decide the
decomposition rule.  That is, tri_strip [0, 1, 2, 3] is decomposed to

  tri [0, 1, 2] and [2, 1, 3], when GL_LAST_VERTEX_CONVENTION
  tri [0, 1, 2] and [1, 3, 2], when GL_FIRST_VERTEX_CONVENTION

That is fine when GS is not active.  But when GS is active, and when
the second triangle is processed, gl_PositionIn[0] could be vertex 2
or vertex 1 depending on the convention.  Now that is not desirable.

The decomposers should not depend on the provoking convention to
decide how to decompose, at least for those decomposers before GS.

-- 
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): draw: Remove unnecessary vertex flag ANDs.

[Brian Paul]

On 08/05/2010 11:53 PM, Chia-I Wu wrote:

Module: Mesa
Branch: master
Commit: 642d5ba79abc6a231a5fdabb3454b9b082b0d7f8
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=642d5ba79abc6a231a5fdabb3454b9b082b0d7f8

Author: Chia-I Wu
Date:   Wed Aug  4 14:37:40 2010 +0800

draw: Remove unnecessary vertex flag ANDs.

Vertex flags are a contract between vcache and the pipeline.  They are
set only for the first vertex of a primitive.

---

  src/gallium/auxiliary/draw/draw_pipe.c |   34 ++-
  1 files changed, 15 insertions(+), 19 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe.c 
b/src/gallium/auxiliary/draw/draw_pipe.c
index 3421b82..070ac80 100644
--- a/src/gallium/auxiliary/draw/draw_pipe.c
+++ b/src/gallium/auxiliary/draw/draw_pipe.c
@@ -179,18 +179,17 @@ static void do_triangle( struct draw_context *draw,
 do_triangle( draw,  \
  i0,  /* flags */   \
  verts + stride * (i0 & ~DRAW_PIPE_FLAG_MASK),  \
-verts + stride * (i1 & ~DRAW_PIPE_FLAG_MASK),  \
-verts + stride * (i2 & ~DRAW_PIPE_FLAG_MASK) )
+verts + stride * (i1), \
+verts + stride * (i2) )


[...]


Could you add some assertions to verify that those indexes do not have 
any flag bits set?  I had to add the & ~MASK in the other places to 
fix bugs in the past.  And those bugs were quite difficult to isolate. 
 I'd rather not go through that again.


-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl2: do copy propagation to non-out call params

[Aras Pranckevicius]

Hi,

Attached patch improves GLSL2 copy propagation to non-out ir_call
parameters. Seems to improve optimizations in my tests.

-- 
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info


do-propagation-into-non-out-call-params.patch
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VTK Offscreen Segfaults

[Kevin H. Hobbs]

On 08/05/2010 06:30 PM, tom fogal wrote:
> 
> 
> Is your test multithreaded, by any chance?
> 

I can't really answer this : it's VTK's test.

When I run the test in gdb it tells me :

[Thread debugging using libthread_db enabled]

and when I quit from gdb gdb warns me that :

A debugging session is active.

Inferior 1 [process 30657] will be killed.

but I can't say if this is just part of the test somehow or if there are
actually multiple rendering threads...



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VTK Offscreen Segfaults

[tom fogal]

"Kevin H. Hobbs"  writes:
> On 08/05/2010 06:30 PM, tom fogal wrote:
> > Is your test multithreaded, by any chance?
> 
> I can't really answer this : it's VTK's test.
> 
> When I run the test in gdb it tells me :
> 
> [Thread debugging using libthread_db enabled]

No, then; you'd see:

  [New Thread 0x40800950 (LWP 25980)]

lines when threads get created, and

  [Thread 0x40800950 (LWP 25980) exited]

when they die.

-tom
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VTK Offscreen Segfaults

[tom fogal]

"Kevin H. Hobbs"  writes:
> On 08/05/2010 07:07 PM, tom fogal wrote:
> > Brian Paul  writes:
> >> My other hunch is something is duplicated in the libOSMesa and libGL
> >> libraries that's causing things to blow up in general.
> >>
> > Do note that both of these issues are from the
> > pre-"-fvisibility=3Dhidd= en by default" days, [. . .]
> 
> my git bisect script uses :
> 
> make -j8  linux-x86-64-debug
> 
> so -fvisibility=3Dhidden is not added to the command line of the
> builds in the git bisection.

Oh.  Can you add it into your bisect script and try again?

  sed -i "s,OPT_FLAGS = -g,OPT_FLAGS=-g -fvisibility=hidden," linux-x86-64-debug

Should do it.

-tom
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29420] New: Amnesia / HPL2 RendererFeatTest - not rendering correctly, segfaults

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29420

   Summary: Amnesia / HPL2 RendererFeatTest - not rendering
correctly, segfaults
   Product: Mesa
   Version: git
  Platform: Other
   URL: http://frictionalgames.com/forum/thread-3604-page-1.ht
ml
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: s...@whiz.se


Created an attachment (id=37638)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37638)
Screenshot of test 4

The developers of the upcoming game Amnesia have released an application to
test graphics compatibility, this does not render correctly in Mesa. 

Test 4 and onwards have problems, the app also segfaults shortly before it's
finished, which might or might not be driver-related. This behaviour is the
same on r300g, and on softpipe.

The test app, and comparison screenshots can be found here:
http://frictionalgames.com/forum/thread-3604-page-1.html 

I'm using git master, commit d38afcd2f286e924e0f9b7f484712ac19e3f98fc

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29420] Amnesia / HPL2 RendererFeatTest - not rendering correctly, segfaults

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29420

--- Comment #1 from Sven Arvidsson  2010-08-06 08:05:39 PDT ---
Created an attachment (id=37639)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37639)
Backtrace from the crash

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] gallium: Make printing info on debug builds default off

[Brian Paul]

On 08/05/2010 07:17 PM, Jakob Bornecrantz wrote:

This commit silences the printing off most of the debug information
when running debug builds. The big culprits are the the tgsi sanity
checker that gets run on all shaders on debug. All the options. And
finaly the cpu caps printer.

This came after a discussion on #dri-devel that --enable-debug should
just make it possible to use gdb and not print a ton of stuff to stderr.

My only hesitation is turning of the debug options since its rather
usefull to know which options you can play with.

Comments, acks and nacks please.


I'm OK with this (I'll probably set a bunch of the env vars in my 
.bashrc file).


But as long as you're looking at env vars, can you please check that 
they're all listed/documented somewhere?  Maybe in src/gallium/docs/


Thanks.

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29407] llvm 2.8 asserts: "Tried to create an integer operation on a non-integer type!"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29407

--- Comment #7 from steckde...@yahoo.fr 2010-08-06 08:14:55 PDT ---
Created an attachment (id=37640)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37640)
Compressed output of neverball when running with llvmpipe (4,7 MB uncompressed)

Hello,

I looked at the code and found the source of the bug I reported in my previous
comment. The line 231 in gallivm/lp_bld_arit.c uses the lp_type found in the
lp_build_context struct, without taking in account the ones of a and b.

When this function is called by draw_llvm_generate (line 737 of
draw/draw_llvm.c), this type is set as .floating=1 and .fixed=0, by
lp_build_context_init() I think.

This is wrong for this first addition, made just after the prolog of the LLVM
function. I made a quick and highly dirty hack to work around this issue :

diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index de99b00..8e40c35 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -734,7 +734,11 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant)

lp_build_context_init(&bld, builder, vs_type);

+   bld.type.fixed = 1;
+   bld.type.floating = 0;
end = lp_build_add(&bld, start, count);
+   bld.type.fixed = 0;
+   bld.type.floating = 1;

step = LLVMConstInt(LLVMInt32Type(), max_vertices, 0);

It's awful, but it works. I was able to see Glxgears running at 97 fps entirely
software rendered, on my AMD Athlon 64 L110 at 1,2Ghz, single core, without HT,
with 512Kb of cache. Good job, it is nearly seven times as fast as softpipe !

Unfortunately, I was not able to test llvmpipe with Neverball because some
errors are still there. I looked at your patch, and it is full of "if
(type.floating)", where type is the lp_type of the current lp_build_context.

Is it possible to use the LLVMValueRefs passed to all these functions to get
their type, and to choose the correct function for them ? It will be more
robust than assuming that all variables used in a shader are of the same type.

Note:

I found in the Core.h file of LLVM some interesting things : 

LLVMTypeRef LLVMTypeOf(LLVMValueRef Val);  // You get the type of the variable
LLVMTypeKind LLVMGetTypeKind(LLVMTypeRef Ty); // Now you have informations for
the type

// And here are the types :
typedef enum {
  LLVMVoidTypeKind,
  LLVMFloatTypeKind,
  LLVMDoubleTypeKind,
  LLVMX86_FP80TypeKind,
  LLVMFP128TypeKind,
  LLVMPPC_FP128TypeKind,
  LLVMLabelTypeKind,
  LLVMIntegerTypeKind, // The interesting one
  LLVMFunctionTypeKind,
  LLVMStructTypeKind,
  LLVMArrayTypeKind,
  LLVMPointerTypeKind,
  LLVMOpaqueTypeKind,
  LLVMVectorTypeKind,  // Here we don't known what is contained in the
vector
  LLVMMetadataTypeKind,
  LLVMUnionTypeKind
} LLVMTypeKind;

But I don't know if it's possible, and if it will be fast enough.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VTK Offscreen Segfaults

[Kevin H. Hobbs]

On 08/05/2010 06:50 PM, Brian Paul wrote:
> 
> Kevin, you seem to have identified two potential commits that caused
> trouble:
> 
> 91c37599f621a0ec498c0f0add14f16470ca852b
> and
> 36b3a8bd5a317ab297f44b19fd14c7e76ec2fc77
> 
> You should go to the head of the Mesa git tree and then undo each of
> those changes one by one (either git-revert or patch -R, etc) and
> re-test to be absolutely sure that one or the other is causing the
> segfault.
> 

reverting 91c37 results in :

Mesa: Mesa 7.9-devel DEBUG build Aug  6 2010 10:20:27
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
Mesa: Initializing x86-64 optimizations
RenderingCxxTests: main/renderbuffer.c:1902: _mesa_add_renderbuffer:
Assertion `bufferName == BUFFER_DEPTH || bufferName == BUFFER_STENCIL ||
fb->Attachment[bufferName].Renderbuffer == ((void *)0)' failed.
/home/kevin/kitware/os_bisect_script.sh: line 40: 14313 Aborted
(core dumped) /tmp/VTK_Build/bin/RenderingCxxTests TestOSConeCxx
-D /home/kevin/kitware/VTKData -T /tmp/VTK_Build/Testing/Temporary -V
Baseline/Rendering/TestOSConeCxx.png


I could not figure out how to revert ( without actually manually editing
) src/mesa/drivers/osmesa/osmesa.c so I reverted 36b3a 53a53 91c37 9b990
in reverse order as the were listed in :

git log src/mesa/drivers/osmesa/osmesa.c

The resulting build produced :

Mesa: Mesa 7.9-devel DEBUG build Aug  6 2010 10:59:59
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
Mesa: Initializing x86-64 optimizations
Mesa: User error: GL_INVALID_ENUM in glGetTexGenfv(coord)
/home/kevin/kitware/os_bisect_script.sh: line 40: 30622 Segmentation
fault  (core dumped) /tmp/VTK_Build/bin/RenderingCxxTests
TestOSConeCxx -D /home/kevin/kitware/VTKData -T
/tmp/VTK_Build/Testing/Temporary -V Baseline/Rendering/TestOSConeCxx.png

Which looks a lot like the error I get with HEAD.

The gdb session for this is :

$ gdb /tmp/VTK_Build/bin/RenderingCxxTests
GNU gdb (GDB) Fedora (7.1-24.fc13)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /tmp/VTK_Build/bin/RenderingCxxTests...done.
(gdb) run TestOSConeCxx \
  -D /home/kevin/kitware/VTKData \
  -T /tmp/VTK_Build/Testing/Temporary \
  -V Baseline/Rendering/TestOSConeCxx.png
Starting program: /tmp/VTK_Build/bin/RenderingCxxTests TestOSConeCxx
-D /home/kevin/kitware/VTKData   -T /tmp/VTK_Build/Testing/Temporary
-V Baseline/Rendering/TestOSConeCxx.png
[Thread debugging using libthread_db enabled]
Mesa: Mesa 7.9-devel DEBUG build Aug  6 2010 10:59:59
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
Mesa: Initializing x86-64 optimizations
Mesa: User error: GL_INVALID_ENUM in glGetTexGenfv(coord)

Program received signal SIGSEGV, Segmentation fault.
0x73c4ff79 in vbo_exec_EvalCoord1fv (u=0x203) at
vbo/vbo_exec_api.c:458
458vbo_exec_EvalCoord1f( u[0] );
Missing separate debuginfos, use: debuginfo-install glibc-2.12-2.x86_64
libICE-1.0.6-2.fc13.x86_64 libSM-1.1.0-7.fc12.x86_64
libX11-1.3.1-3.fc13.x86_64 libXau-1.0.5-1.fc12.x86_64
libXext-1.1-2.fc13.x86_64 libXt-1.0.7-1.fc13.x86_64
libgcc-4.4.4-2.fc13.x86_64 libstdc++-4.4.4-2.fc13.x86_64
libuuid-2.17.2-5.fc13.x86_64 libxcb-1.5-1.fc13.x86_64
(gdb) bt
#0  0x73c4ff79 in vbo_exec_EvalCoord1fv (u=0x203) at
vbo/vbo_exec_api.c:458
#1  0x73c3ddc3 in neutral_EvalCoord1fv (v=0x203) at
main/vtxfmt_tmp.h:79
#2  0x77b2f735 in vtkOpenGLRenderWindow::OpenGLInit (this=0x69d770)
at /tmp/VTK/Rendering/vtkOpenGLRenderWindow.cxx:241
#3  0x77b8ab02 in vtkXOpenGLRenderWindow::CreateOffScreenWindow
(this=0x69d770, width=300, height=300)
at /tmp/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:951
#4  0x77b8af81 in vtkXOpenGLRenderWindow::Initialize (this=0x69d770)
at /tmp/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1066
#5  0x77b8b387 in vtkXOpenGLRenderWindow::Start (this=0x69d770)
at /tmp/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1185
#6  0x77a51c51 in vtkRenderWindow::DoStereoRender
(this=0x69d770) at /tmp/VTK/Rendering/vtkRenderWindow.cxx:687
#7  0x77a51c22 in vtkRenderWindow::DoFDRender (this=0x69d770) at
/tmp/VTK/Rendering/vtkRenderWindow.cxx:676
#8  0x77a51622 in vtkRenderWindow::DoAARender (this=0x69d770) at
/tmp/VTK/Rendering/vtkRenderWindow.cxx:563
#9  0x77a50a32 in vtkRenderWindow::Render (this=0x69d770) at
/tmp/VTK/Rendering/vtkRenderWindow.cxx:376
#10 0x77b8dde7 in vtkXOpenGLRenderWindow::Render (this=0x69d770)
at /tmp/VTK/Rendering/vtkXOpenGLR

[Mesa-dev] [Bug 29420] Amnesia / HPL2 RendererFeatTest - not rendering correctly, segfaults

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29420

--- Comment #2 from Sven Arvidsson  2010-08-06 08:20:46 PDT ---
A lot of GLSL errors:

ERROR: Could not create texture 'LinearDepth'
ERROR: Frame buffer 'LinearDepth' is not complete! Incomplete draw buffer!
ERROR: Failed to compile GLSL shader
'/home/sa/Downloads/RendererFeatTest/core/shaders/deferred_ssao_blur_frag.glsl'!
ERROR: Couldn't create program 'deferred_ssao_blur_frag.glsl'
ERROR: Failed to compile GLSL shader
'/home/sa/Downloads/RendererFeatTest/core/shaders/deferred_ssao_blur_frag.glsl'!
ERROR: Couldn't create program 'deferred_ssao_blur_frag.glsl'
ERROR: Could not create texture 'EdgeSmoothLinearDepth'
ERROR: Frame buffer 'EdgeSmoothLinearDepth' is not complete! Incomplete draw
buffer!
ERROR: Failed to compile GLSL shader
'/home/sa/Downloads/RendererFeatTest/core/shaders/posteffect_bloom_blur_frag.glsl'!
ERROR: Couldn't create program 'posteffect_bloom_blur_frag.glsl'
ERROR: Failed to compile GLSL shader
'/home/sa/Downloads/RendererFeatTest/core/shaders/posteffect_bloom_blur_frag.glsl'!
ERROR: Couldn't create program 'posteffect_bloom_blur_frag.glsl'
ERROR: Failed to compile GLSL shader
'/home/sa/Downloads/RendererFeatTest/core/shaders/posteffect_radial_blur_frag.glsl'!
ERROR: Couldn't create program 'posteffect_radial_blur_frag.glsl'

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Gallium depth clamp support

[Marek Olšák]

On Mon, Jul 26, 2010 at 8:11 PM, Brian Paul  wrote:

> On 07/23/2010 03:27 PM, Roland Scheidegger wrote:
>
>> On 22.07.2010 01:27, Brian Paul wrote:
>>
>>> On 07/21/2010 05:19 PM, Marek Olšák wrote:
>>>
 On Thu, Jul 22, 2010 at 12:17 AM, Roland Scheidegger>>> >  wrote:

 Marek Olšák wrote:

 Hi,

 there is a new branch gallium-depth-clamp in the main repository
 which implements ARB_depth_clamp in Gallium. Wine uses this
 extension to disable clipping when it's requested from a D3D9
 app, so it's an important one.

 There is a new state "depth_clamp" in pipe_clip_state, and a new
 cap PIPE_CAP_DEPTH_CLAMP. If you think this feature should be
 mandatory in Gallium instead, it's ok with me. There are several
 reasons I put the enable bit in pipe_clip_state, but the most
 important one is that Z clipping must be disabled in hardware
 first for it to work. It also implements depth_clamp handling in
 cso_cache and wires up ARB_depth_clamp in st/mesa.

 The support in Draw has also been implemented, and both softpipe
 and llvmpipe pass piglit/depth_clamp and
 piglit/depth-clamp-range.


 http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-depth-clamp


 One thing I was wondering does it actually make sense to call it
 depth clamp? I think d3d10 name for once (which calls this
 functionality depth clip though of course this means enable/disable
 is reversed) makes more sense - this disables near/far plane
 clipping, hence the necessity to clamp to 0/1.
 I guess having this in clip state is ok - d3d10 puts depth clip into
 rasterizer state, but then again d3d10 doesn't have any clip
 state...


 Depth clip does sound better to me, but honestly I don't care how we
 call it. If you like the D3D naming, so be it.

>>>
>>> There's two aspects to the GL extension:
>>>   - near/far Z clipping
>>>   - fragment Z clamping during interpolation
>>>
>>> I think pipe_clip_state::depth_clamp should become
>>> pipe_clip_state::depth_clip.
>>>
>>> Then, I'd probably add the second part of this as
>>> pipe_rasterizer_state::depth_clamp to enable/disable fragment Z clamping.
>>>
>>> GL would set both pieces of state in tandem.  I think we should have
>>> two pieces of state to avoid interdependencies between clip state and
>>> rasterization state in the drivers.
>>>
>>> I'm not sure how this is expressed in Direct3D.
>>>
>>
>> d3d10 always clamps z to viewport min/max depth, regardless if depth
>> clipping is enabled or not (hmm does it really make a difference when
>> depth clipping is enabled? Maybe only for OGL rasterpos and similar
>> legacy stuff?).
>>
>
> I was also thinking of floating point Z buffers which don't necessarily
> clamp Z to [0,1].  You might want to disable Z clipping as well as fragment
> Z clamping.
>

Some new thoughts.

ARB_depth_buffer_float says there is always Z clamping to [0, 1], but the
range can be changed to pretty much anything using glDepthRange, and
ARB_depth_clamp doesn't specify any interaction with floating-point
zbuffers, meaning that Z clamping cannot be disabled in OpenGL. Furthermore,
I think all hardware clamps depth as it's more or less mandatory for polygon
offset, right?

So it's either to clip or not to clip, and clamping is enabled all the time,
regardless of the underlying zbuffer format.

Therefore, I will change pipe_clip_state::depth_clamp to depth_clip, as
Roland suggested, ok?

FWIW Draw clamps per-vertex depth in the offset stage (that's probably where
I saw it first), which, as we discussed, should be done per-fragment
instead.

-Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Gallium depth clamp support

[Keith Whitwell]

On Fri, 2010-08-06 at 08:29 -0700, Marek Olšák wrote:
> On Mon, Jul 26, 2010 at 8:11 PM, Brian Paul  wrote:
> 
> On 07/23/2010 03:27 PM, Roland Scheidegger wrote:
> On 22.07.2010 01:27, Brian Paul wrote:
> On 07/21/2010 05:19 PM, Marek Olšák wrote:
> On Thu, Jul 22, 2010 at 12:17 AM,
> Roland Scheidegger >  wrote:
> 
> Marek Olšák wrote:
> 
> Hi,
> 
> there is a new branch
> gallium-depth-clamp in the main
> repository
> which implements
> ARB_depth_clamp in Gallium. Wine uses
> this
> extension to disable clipping
> when it's requested from a D3D9
> app, so it's an important one.
> 
> There is a new state
> "depth_clamp" in pipe_clip_state, and
> a new
> cap PIPE_CAP_DEPTH_CLAMP. If
> you think this feature should be
> mandatory in Gallium instead,
> it's ok with me. There are several
> reasons I put the enable bit
> in pipe_clip_state, but the most
> important one is that Z
> clipping must be disabled in hardware
> first for it to work. It also
> implements depth_clamp handling in
> cso_cache and wires up
> ARB_depth_clamp in st/mesa.
> 
> The support in Draw has also
> been implemented, and both softpipe
> and llvmpipe pass
> piglit/depth_clamp and
> piglit/depth-clamp-range.
> 
> 
> 
> http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-depth-clamp
> 
> 
> One thing I was wondering does it
> actually make sense to call it
> depth clamp? I think d3d10 name
> for once (which calls this
> functionality depth clip though of
> course this means enable/disable
> is reversed) makes more sense -
> this disables near/far plane
> clipping, hence the necessity to
> clamp to 0/1.
> I guess having this in clip state
> is ok - d3d10 puts depth clip into
> rasterizer state, but then again
> d3d10 doesn't have any clip state...
> 
> 
> Depth clip does sound better to me,
> but honestly I don't care how we
> call it. If you like the D3D naming,
> so be it.
> 
> There's two aspects to the GL extension:
>   - near/far Z clipping
>   - fragment Z clamping during interpolation
> 
> I think pipe_clip_state::depth_clamp should
> become
> pipe_clip_state::depth_clip.
> 
> Then, I'd probably add the second part of this
> as
> pipe_rasterizer_state::depth_clamp to
> enable/disable fragment Z clamping.
> 
> GL would set both pieces of state in tandem.
>  I think we should have
> two pieces of stat

[Mesa-dev] [Bug 29407] llvm 2.8 asserts: "Tried to create an integer operation on a non-integer type!"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29407

--- Comment #8 from nobled  2010-08-06 09:17:33 PDT ---
Created an attachment (id=37642)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37642
 Review: https://bugs.freedesktop.org/review?bug=29407&attachment=37642

draw: Use the correct type

(In reply to comment #7)
> I looked at the code and found the source of the bug I reported in my previous
> comment. The line 231 in gallivm/lp_bld_arit.c uses the lp_type found in the
> lp_build_context struct, without taking in account the ones of a and b.
I'm pretty sure a and b *have* to both be the same type and be used with a
context that mentions what type they are. If they aren't then it's a bug in
draw_llvm_generate, not the patch...

*checks* Okay, it says 'start' and 'count' are both supposed to be
LLVMInt32Type, but it sets vs_type to lp_type_float_vec(32). Patch attached.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29420] Amnesia / HPL2 RendererFeatTest - not rendering correctly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29420

Sven Arvidsson  changed:

   What|Removed |Added

Summary|Amnesia / HPL2  |Amnesia / HPL2
   |RendererFeatTest - not  |RendererFeatTest - not
   |rendering correctly,|rendering correctly
   |segfaults   |

--- Comment #3 from Sven Arvidsson  2010-08-06 09:59:11 PDT ---
According to the game devs, the segfault is because of the shader failure.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): draw: Remove unnecessary vertex flag ANDs.

[Chia-I Wu]

On Fri, Aug 6, 2010 at 9:44 PM, Brian Paul  wrote:
> On 08/05/2010 11:53 PM, Chia-I Wu wrote:
>>
>> Module: Mesa
>> Branch: master
>> Commit: 642d5ba79abc6a231a5fdabb3454b9b082b0d7f8
>> URL:
>>  http://cgit.freedesktop.org/mesa/mesa/commit/?id=642d5ba79abc6a231a5fdabb3454b9b082b0d7f8
>>
>> Author: Chia-I Wu
>> Date:   Wed Aug  4 14:37:40 2010 +0800
>>
>> draw: Remove unnecessary vertex flag ANDs.
>>
>> Vertex flags are a contract between vcache and the pipeline.  They are
>> set only for the first vertex of a primitive.
>>
>> ---
>>
>>  src/gallium/auxiliary/draw/draw_pipe.c |   34
>> ++-
>>  1 files changed, 15 insertions(+), 19 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/draw/draw_pipe.c
>> b/src/gallium/auxiliary/draw/draw_pipe.c
>> index 3421b82..070ac80 100644
>> --- a/src/gallium/auxiliary/draw/draw_pipe.c
>> +++ b/src/gallium/auxiliary/draw/draw_pipe.c
>> @@ -179,18 +179,17 @@ static void do_triangle( struct draw_context *draw,
>>     do_triangle( draw,                                          \
>>                  i0,  /* flags */                               \
>>                  verts + stride * (i0 & ~DRAW_PIPE_FLAG_MASK),  \
>> -                verts + stride * (i1 & ~DRAW_PIPE_FLAG_MASK),  \
>> -                verts + stride * (i2 & ~DRAW_PIPE_FLAG_MASK) )
>> +                verts + stride * (i1),                         \
>> +                verts + stride * (i2) )
>
> [...]
>
>
> Could you add some assertions to verify that those indexes do not have any
> flag bits set?  I had to add the & ~MASK in the other places to fix bugs in
> the past.  And those bugs were quite difficult to isolate.  I'd rather not
> go through that again.
That is a good idea.  I've pushed a commit for that.  I should have done it for
this commit.

-- 
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29407] llvm 2.8 asserts: "Tried to create an integer operation on a non-integer type!"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29407

--- Comment #9 from José Fonseca  2010-08-06 11:37:20 PDT 
---
I like the direction of the nobled patches.

But that said, I can only accept the patches when they provoke no regressions
for llvm-2.6, regardless where the fault lies.

It appears the draw module needs two lp_bld_contexts: one for floating point
operations, other for the integer indices operations. It was indeed a
coincidence that things worked so far.

Making the lp_bld_add() automatically detect the incoming variables is *not*
the solution. That would only hide the problems and make it much harder to
debug later, especially because the lp_type is richer than LLVM native vector
types (e.g., fixed point, normalized values etc). Instead, we should add more
asserts like

  assert(lp_check_vec_type(bld->type, a));

to ensure the callers are using consistent types.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VTK Offscreen Segfaults

[Kevin H. Hobbs]

On 08/06/2010 10:47 AM, tom fogal wrote:
> "Kevin H. Hobbs"  writes:
>> 
>> my git bisect script uses :
>>
>> make -j8  linux-x86-64-debug
>>
>> so -fvisibility=3Dhidden is not added to the command line of the
>> builds in the git bisection.
> 
> Oh.  Can you add it into your bisect script and try again?
> 
>   sed -i "s,OPT_FLAGS = -g,OPT_FLAGS=-g -fvisibility=hidden," 
> linux-x86-64-debug
> 
> Should do it.
> 
> -tom
> 

I added this to my bisect script and did :

git clone git://anongit.freedesktop.org/git/mesa/mesa
cd mesa
git bisect start
git bisect bad
git bisect good cbf30fce322506bd43692617de9d201533f41532
# anything before this won't build with -fvisibility=hidden

What I got was :

91c37599f621a0ec498c0f0add14f16470ca852b is the first bad commit
commit 91c37599f621a0ec498c0f0add14f16470ca852b
Author: Brian Paul 
Date:   Fri Jul 2 18:18:15 2010 -0600

osmesa: remove old renderbuffer before adding new

Fixes fd.o bug 10966 when OSMesaMakeCurrent() was called twice.

NOTE: This is a candidate for the 7.8 branch.

:04 04 a4ba3e3942358d9f65e1776be65f6c777e2e9727
fc9d13a49f9091236be27945a3aafbcf347ea55f M  src
bisect run success

which is the same as before.



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] 7.8, round 2.

[tom fogal]

tom fogal  writes:
> tom fogal  writes:
> > the branch is at:
> > 
> >   git://people.freedesktop.org/~tfogal/mesa
> >   http://cgit.freedesktop.org/~tfogal/mesa/log/?h=7.8
>
> I'd like to push this to 'origin' tomorrow, if there are no
> complaints between now and then.

None heard.  I created a release notes file from the commits I at least
vaguely understood, and pushed 7.8 to origin.

I (obviously) want to push for a 7.8.3 release soon-ish, but I'd like
to see if we can figure out Kevin's issue beforehand.

-tom
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VTK Offscreen Segfaults

[Kevin H. Hobbs]

On 08/06/2010 03:15 PM, tom fogal wrote:
> 
> If you could build VTK with just a single GL library -- i.e. with just
> libOSMesa or just libGL, but not both -- and could reproduce the crash,
> that would rule out my symbol collision theory.  I am not sure how easy
> that is, though...
> 

That was shockingly easy... sort of.

I did my VTK build with both

-DOPENGL_gl_LIBRARY:FILEPATH=/tmp/mesa/lib64/libOSMesa.so
-DOSMESA_LIBRARY:FILEPATH=/tmp/mesa/lib64/libOSMesa.so

and I left off -fvisibility=hidden thinking that I want the symbols that
are now included in libOSMesa.so to be available to VTK.

and what do you know the test passed.

however I wanted to see if VTK is really built with only libOSMesa.so so
I did :

 $ ldd ../VTK_Build/bin/RenderingCxxTests | grep mesa
  libOSMesa.so.7 => /tmp/mesa/lib64/libOSMesa.so.7 (0x7fa97ff4a000)
  libGL.so.1 => /tmp/mesa/lib64/libGL.so.1 (0x7fa97bc7a000)

so it got pulled in somehow perhaps by libOSMesa.so itself?

If I do :

$ ldd ../mesa/lib64/libOSMesa.so | grep libGL.so
  libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x7f88ed2cf000)

because libOSMesa.so needs libGL.so and I have the nvidia drivers in my
dynamic linker path but VTK has an rpath set so...

What does all of this mean?





signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] glsl2: optimizing unused struct assignments

[Eric Anholt]

On Fri, 6 Aug 2010 09:46:17 +0200, Aras Pranckevicius  wrote:
> > Pushed a change that cleans up the shader you pasted.  Mostly.  There's
> > still some junk in it that we could do better at.  Results below.
> 
> Very nice, thanks!
> 
> 
> > By the way, it would be useful to get some examples of your shaders as
> > shader_runner tests in piglit.  That makes them easy to analyze for
> > optimization opportunities, and they serve as regression tests to make
> > sure we don't break your shaders.  Would you be up for making some of
> > those?
> 
> I don't quite know what piglit or shader_runner is... I guess it's
> stuff here: http://cgit.freedesktop.org/piglit/tree/tests/shaders ?
> 
> I do have about 500 random shaders from Unity here:
> http://github.com/aras-p/glsl-optimizer/tree/glsl2/src/glsl/optimizer-tests/
> (the *-in.txt files), but to prepare them for piglit I'd have to think
> up some instructions to draw something and inspect the pixel values,
> right?

Yeah.  It's hard to make sure things are really correct without testing
for actual pixel results.


pgpC1JRQIw2JR.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl2: do copy propagation to non-out call params

[Eric Anholt]

On Fri, 6 Aug 2010 16:13:48 +0200, Aras Pranckevicius  wrote:
> Hi,
> 
> Attached patch improves GLSL2 copy propagation to non-out ir_call
> parameters. Seems to improve optimizations in my tests.

Applied this and the inlining fix. Thanks!


pgpiY7g6XtTIe.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VTK Offscreen Segfaults

[tom fogal]

"Kevin H. Hobbs"  writes:
> On 08/06/2010 03:15 PM, tom fogal wrote:
> > If you could build VTK with just a single GL library -- i.e. with
> > just libOSMesa or just libGL, but not both -- and could reproduce
> > the crash,= that would rule out my symbol collision theory.  I am
> > not sure how easy= that is, though...
> 
> That was shockingly easy... sort of.
> 
> I did my VTK build with both
> 
> -DOPENGL_gl_LIBRARY:FILEPATH=3D/tmp/mesa/lib64/libOSMesa.so
> -DOSMESA_LIBRARY:FILEPATH=3D/tmp/mesa/lib64/libOSMesa.so
> 
> and I left off -fvisibility=3Dhidden thinking that I want the symbols
> that are now included in libOSMesa.so to be available to VTK.

Nah, the visibility thing only hides symbols that should be hidden
anyway; i.e. the vbo symbols and the like. gl* will always be available
regardless of the -fvisibility setting and regardless of which library
is being built/used.

> and what do you know the test passed.

Great!

> however I wanted to see if VTK is really built with only libOSMesa.so
> so I did :
>
>  $ ldd ../VTK_Build/bin/RenderingCxxTests | grep mesa  libOSMesa.so.7 =>
>  /tmp/mesa/lib64/libOSMesa.so.7 (0x7fa97ff4a000)  libGL.so.1 =>
>  /tmp/mesa/lib64/libGL.so.1 (0x7fa97bc7a000)
>
> so it got pulled in somehow perhaps by libOSMesa.so itself?
>
> If I do :
>
> $ ldd ../mesa/lib64/libOSMesa.so | grep libGL.so
>   libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x7f88ed2cf000)
>
> because libOSMesa.so needs libGL.so and I have the nvidia drivers in
> my dynamic linker path but VTK has an rpath set so...

Yeah... hrm, I thought Dan's change got rid of that, but maybe I
misunderstood it.

Could you rm /tmp/mesa/lib64/libGL.so* before building VTK?  My hunch
is that VTK is linking it in anyway; maybe it stuck around in cmake's
cache or something.

> What does all of this mean?

Well, it does appear to be some type of symbol resolution/overloading
issue.  However it seems to be with internal Mesa symbols.  Switching
to a single library -- that is, putting OSMesaCreateContext, etc. into
libGL directly, and getting rid of libOSMesa altogether -- seems like
it would be the solution, but I imagine there's some reason that's not
happening already.

Let's ping Dan (added to the CC list), he knows more about this kind
of thing than I do.  Dan, have you been following this thread?  The
working theory is that there is a symbol in both libOSMesa and libGL.
Something about the symbol existing in both is causing Badness during
linking; seemingly innocuous changes cause Kevin's test program to
jump into odd parts of Mesa (e.g. VBO code while doing initial matrix
setup).  The issue appears to be with internal symbols, but hidden
symbol visibility isn't helping.

-tom
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29407] llvm 2.8 asserts: "Tried to create an integer operation on a non-integer type!"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29407

nobled  changed:

   What|Removed |Added

  Attachment #37630|0   |1
is obsolete||

--- Comment #10 from nobled  2010-08-06 14:37:55 PDT ---
Created an attachment (id=37651)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37651
 Review: https://bugs.freedesktop.org/review?bug=29407&attachment=37651

gallivm: Always use floating point operators for floating point values (v3)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29407] llvm 2.8 asserts: "Tried to create an integer operation on a non-integer type!"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29407

nobled  changed:

   What|Removed |Added

  Attachment #37631|0   |1
is obsolete||

--- Comment #11 from nobled  2010-08-06 14:39:16 PDT ---
Created an attachment (id=37652)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37652
 Review: https://bugs.freedesktop.org/review?bug=29407&attachment=37652

llvmpipe: Always use floating-point operators for floating-point types

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29407] llvm 2.8 asserts: "Tried to create an integer operation on a non-integer type!"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29407

nobled  changed:

   What|Removed |Added

  Attachment #37642|0   |1
is obsolete||

--- Comment #12 from nobled  2010-08-06 14:42:19 PDT ---
Created an attachment (id=37653)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37653
 Review: https://bugs.freedesktop.org/review?bug=29407&attachment=37653

draw: Use the correct type for integers

With all three patches applied, I can't find any regressions using the
lp_test_blend/conv/format tests. Could other people test? (the patch for the
draw module at least could go in right now though.)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29407] llvm 2.8 asserts: "Tried to create an integer operation on a non-integer type!"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29407

--- Comment #13 from nobled  2010-08-06 14:47:54 PDT ---
(In reply to comment #12)
> Created an attachment (id=37653)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37653
 Review: https://bugs.freedesktop.org/review?bug=29407&attachment=37653

> draw: Use the correct type for integers
> 
> With all three patches applied, I can't find any regressions using the
> lp_test_blend/conv/format tests. Could other people test? (the patch for the
> draw module at least could go in right now though.)

Actually, even the regression I thought I found in comment #3 with just the
first patch wasn't a real regression; that format was already failing with llvm
2.7 (didn't test llvm 2.6).

BTW, upgrading to llvm 2.8 fixed every single other format test failure but
that one.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Merge of glsl2 branch to master

[Ian Romanick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As of today the glsl2 branch has three piglit regressions WRT master,
and there is only one crashing piglit tests.  As before, we have tested
swrast and i965.  For master I used commit 27041d7cb, and for glsl2 I
used commit c234d0b2.  The results are available at
http://people.freedesktop.org/~idr/results/.  The regressed tests cases are:

 * draw_buffers-05.vert - As mentioned previously, the spec is ambiguous
and Nvidia and AMD produce different results for this test.  Until the
spec ambiguity is resolved, I don't care about this failure.

* glsl1-texcoord varying - This test accesses gl_TexCoord[] using a
non-constant index without dimensioning the array. The new compiler
correctly rejects this shader. Nvidia accepts it, but I believe they're
going outside the spec (which they do a lot). I haven't tested this on
AMD or Apple yet. Is this shader from an application?  We've changed the
test in piglit commit c6146f121, but I think it still isn't quite right.

 * fbo-drawbuffers-maxtargets - Fails on i965 because we don' have loop
unrolling in the compiler or good array handling in the driver.  We'll
get loop unolling in the compiler first.  Proper array handling will
come to the driver once we move away from using Mesa IR.


I propose that we merge master to glsl2 on *Friday, August 13th* (one
week from today).  Barring unforeseen issues, I propose that we merge
glsl2 to master on *Monday, August 16th*.


I believe that all of the concerns people raised before have either been
resolved or are in the process of being resolved:

 * Jakob is testing the glsl2 branch on softpipe and (presumably)
llvmpipe (as per Michel Dänzer)

 * We merged master to our branch about a week ago, and we will do so
again (with a retest) before we merge the branch to master.  We would
like to perform these merges in just over a week (as per Dave Airlie).

 * We have not added any tests from mesa-demos to piglit.  They have
been run, and we can run them again before merging.  The ones that
people really care about should be added to piglit (as per Brian Paul).

 * Using MESA_GLX_FORCE_ALPHA=y seems to partially resolve the alpha
read-back issue with swrast but not completely (as per Brian Paul).

 * There have been some regressions reported in r300, but these look to
be manageable.  I don't have the bug numbers handy (as per Tom Stellard).

 * Geometry shaders and GLSL 1.30 support are at the top of our post-Q3
todo list.  Since all of the geometry shader extensions have explicit
dependencies on either GLSL 1.30 or GL_EXT_gpu_shader4, it's not clear
to me how Mesa current supports them.  Since none of the hardware
drivers currently expose this extension, it seems that it be missed if
we lose this functionality for a quarter or two (as per Zack Rusin).

 * talloc has been ported to Windows (as per José Fonseca).

Have I missed anyone or any issue that was raised?

Between now and the merge, we have the following items on our list:

 * Fix the couple of build bugs (#29207 and #29209) that have been reported.

 * Fix the regression in fbo-drawbuffers-maxtargets.

Between now and shipping Mesa 7.9, we have the following major items on
our list:

 * Implement GLSL ES support in the front-end.

 * Implement loop analysis so that we can implement some loop
optimizations and loop unroll for architectures (e.g., i915) that lack
branching.

 * More tests.  We're working with a couple applications to get some of
their shaders contributed to piglit for testing.  We'll see what happens
here.

As far as pushing for a Q3 release of Mesa 7.9 with the new compiler, I
don't think it's going to be a problem.  There are still some rough
spots, and there's still work to be done.  Overall, though, the new
compiler is much better than the existing compiler.  I think this meets
the criteria for a development release. :)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxci68ACgkQX1gOwKyEAw9r8wCfeq5u88pgyvBz+IhnBU75jRiO
HDIAnjtc+dWWQ+liGgKj1ns16pvfYDlj
=p/yn
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] glsl2: optimizing unused struct assignments

[Ian Romanick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Aras Pranckevicius wrote:

>> By the way, it would be useful to get some examples of your shaders as
>> shader_runner tests in piglit.  That makes them easy to analyze for
>> optimization opportunities, and they serve as regression tests to make
>> sure we don't break your shaders.  Would you be up for making some of
>> those?
> 
> I don't quite know what piglit or shader_runner is... I guess it's
> stuff here: http://cgit.freedesktop.org/piglit/tree/tests/shaders ?

Right.  Shader runner is takes a simple .ini-style file with shaders,
uniform values, draw calls, and pixel probes.  Look at the *.shader_test
files for examples.

> I do have about 500 random shaders from Unity here:
> http://github.com/aras-p/glsl-optimizer/tree/glsl2/src/glsl/optimizer-tests/
> (the *-in.txt files), but to prepare them for piglit I'd have to think
> up some instructions to draw something and inspect the pixel values,
> right?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxcjVUACgkQX1gOwKyEAw8ZJQCeLGOkpB5qcweZPG2uvqTAQrAq
KdcAnjvgDMGC+PeDOPw8mbAzreiLBBdD
=VrhY
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29163] [glsl2] glean/shaderAPI fail

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29163

Ian Romanick  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Ian Romanick  2010-08-06 15:40:26 PDT 
---
This should be fixed by the following commits:

commit 8d61a23b1a1d0d4b21f0fab64f6d863a8ee3d7f1
Author: Eric Anholt 
Date:   Thu Aug 5 16:00:46 2010 -0700

glsl2: Don't assert in a couple of places when encountering sampler arrays.

Fixes glean shaderAPI.

commit 658e25987fbec3b826f500baa6d4d936b9552b13
Author: Eric Anholt 
Date:   Thu Aug 5 15:54:56 2010 -0700

ir_to_mesa: Give the expected size for _mesa_add_attribute().

Fixes a failure in glean shaderAPI.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29044] GLSL compiler tracker

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29044

Bug 29044 depends on bug 29163, which changed state.

Bug 29163 Summary: [glsl2] glean/shaderAPI fail
https://bugs.freedesktop.org/show_bug.cgi?id=29163

   What|Old Value   |New Value

 Resolution||FIXED
 Status|NEW |RESOLVED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] r300 compiler vertex shader loops

[Tom Stellard]

Hi,

The two attached patches enable the hardware loop capabilities for
vertex shaders.  I haven't tested on an r300 card yet, but glsl-vs-loop
from piglit passes on my r500 card.  Nested loops don't work yet, I
think it is an issue with the branch emulation, but I'm not sure.

It would be helpful if someone could review the changes I made
especially to r300_emit.c, r300_state.c, and both r300_reg.h files to
make sure I'm doing things the right way.

Thanks.

-Tom
>From e4840078a870aafc2e395783da1a6be99b83cf97 Mon Sep 17 00:00:00 2001
From: Tom Stellard 
Date: Thu, 5 Aug 2010 21:03:55 -0700
Subject: [PATCH 1/2] r300/compiler: Correctly transform nested loops.

---
 .../dri/r300/compiler/radeon_emulate_loops.c   |   25 +++
 1 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_emulate_loops.c 
b/src/mesa/drivers/dri/r300/compiler/radeon_emulate_loops.c
index 24c3ae5..2a3306f 100644
--- a/src/mesa/drivers/dri/r300/compiler/radeon_emulate_loops.c
+++ b/src/mesa/drivers/dri/r300/compiler/radeon_emulate_loops.c
@@ -421,13 +421,9 @@ static int build_loop_info(struct radeon_compiler * c, 
struct loop_info * loop,
  * ENDLOOP;-> ENDLOOP
  *
  * @param inst A pointer to a BGNLOOP instruction.
- * @return If the loop can be unrolled, a pointer to the first instruction of
- * the unrolled loop.
- *Otherwise, A pointer to the ENDLOOP instruction.
- *Null if there is an error.
+ * @return 1 for success, 0 for failure
  */
-static struct rc_instruction * transform_loop(struct emulate_loop_state * s,
-   struct rc_instruction * inst)
+int transform_loop(struct emulate_loop_state * s, struct rc_instruction * inst)
 {
struct loop_info * loop;
 
@@ -437,10 +433,10 @@ static struct rc_instruction * transform_loop(struct 
emulate_loop_state * s,
loop = &s->Loops[s->LoopCount++];
 
if (!build_loop_info(s->C, loop, inst))
-   return NULL;
+   return 0;
 
if(try_unroll_loop(s->C, loop, -1)){
-   return loop->BeginLoop->Next;
+   return 1;
}
 
/* Reverse the conditional instruction */
@@ -465,14 +461,14 @@ static struct rc_instruction * transform_loop(struct 
emulate_loop_state * s,
break;
default:
rc_error(s->C, "loop->Cond is not a conditional.\n");
-   return NULL;
+   return 0;
}
 
/* Prepare the loop to be emulated */
rc_remove_instruction(loop->Brk);
rc_remove_instruction(loop->EndIf);
rc_insert_instruction(loop->EndLoop->Prev, loop->EndIf);
-   return loop->EndLoop;
+   return 1;
 }
 
 void rc_transform_loops(struct radeon_compiler *c,
@@ -482,16 +478,13 @@ void rc_transform_loops(struct radeon_compiler *c,
 
memset(s, 0, sizeof(struct emulate_loop_state));
s->C = c;
-   ptr = s->C->Program.Instructions.Next;
-   while(ptr != &s->C->Program.Instructions) {
+   for(ptr = s->C->Program.Instructions.Next;
+   ptr != &s->C->Program.Instructions; ptr = ptr->Next) {
if(ptr->Type == RC_INSTRUCTION_NORMAL &&
ptr->U.I.Opcode == RC_OPCODE_BGNLOOP){
-   ptr = transform_loop(s, ptr);
-   if(!ptr){
+   if (!transform_loop(s, ptr))
return;
-   }
}
-   ptr = ptr->Next;
}
 }
 
-- 
1.7.1

>From 0d51df6af40179ca0bb2162ef40d1082d817c152 Mon Sep 17 00:00:00 2001
From: Tom Stellard 
Date: Thu, 5 Aug 2010 10:19:00 -0700
Subject: [PATCH 2/2] r300/compiler: Implement hardware assisted loops for 
vertex shaders.

---
 src/gallium/drivers/r300/r300_emit.c   |   23 
 src/gallium/drivers/r300/r300_reg.h|   21 
 src/gallium/drivers/r300/r300_state.c  |4 +-
 src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c |2 +-
 src/mesa/drivers/dri/r300/compiler/r3xx_vertprog.c |  113 ++--
 .../drivers/dri/r300/compiler/r3xx_vertprog_dump.c |   14 +++
 src/mesa/drivers/dri/r300/compiler/radeon_code.h   |   14 +++
 .../dri/r300/compiler/radeon_emulate_loops.c   |8 +-
 .../dri/r300/compiler/radeon_emulate_loops.h   |3 +-
 src/mesa/drivers/dri/r300/r300_reg.h   |   21 
 10 files changed, 206 insertions(+), 17 deletions(-)

diff --git a/src/gallium/drivers/r300/r300_emit.c 
b/src/gallium/drivers/r300/r300_emit.c
index 17e180a..17981e5 100644
--- a/src/gallium/drivers/r300/r300_emit.c
+++ b/src/gallium/drivers/r300/r300_emit.c
@@ -936,6 +936,29 @@ void r300_emit_vs_state(struct r300_context* r300, 
unsigned size, void* state)
 OUT_CS_TABLE(data, 4);
 }
 }
+
+/* Emit flow control instructions. */
+if (code->num_fc_ops