Re: [Mesa-dev] static version of osmesa is missing llvm symbols, bug?
Guys, Thanks for the feedback and for continued support of static linking. I will file the bug reports. Burlen On 03/12/2014 06:30 AM, Brian Paul wrote: On 03/11/2014 06:48 PM, Emil Velikov wrote: On 12/03/14 00:08, Burlen Loring wrote: yep, I'm using 10.1.0 and also noticed the same in 9.2.2. In that case "it wasn't me" ;-) in short static linking is essential for reasonable performance of parallel applications on Cray systems. In this scenario the application is duplicated across 100s/1000s of compute nodes which share a remote-parallel file system (Lustre/GPFS). As a dynamically linked application starts, shared library loading hit's the file system hard. However, Cray suggests users run static linked executables. Their application launcher bypasses the file system and copies statically linked executable directly into a ram fs onto the set of compute nodes that a given job is scheduled to run on. This avoids file system contention that would be introduced by a parallel application's shared library loading. I maintain and support ParaView and interactive OpenGL based rendering application on NERSC's Crays. Given that this is an interactive application, having a reasonable startup time is important. Users have complained and I've observed times when using shared libraries when app startup takes more than 30 min! if we build fully static executable startup time is reduced to seconds. For me statically linked mesa is important, which is why I want to report this. Without OSMesa we can't use these systems, and the new llvmpipe OSMesa state tracker has been really awesome, allowing us to do things we couldn't in the past without GPUs. I hope that you don't discontinue static link support. Had some additional patches that cleans up mesa's build a bit further but I guess I'll bring back (classic and gallium) static osmesa first. Especially considering the numbers you've quoted. We have experienced some segfaults in llvmpipe OSMesa in the static linked version (bt shows SEGV at create_jit_texture_type.isra.1@draw_llvm.c:128). If I can reproduce this off the Cray I will file a bug report. Thought I'd mention in case you can confirm that there is a known issue with the static link. AFAIK static linking with llvm is a bit of a hit and miss. For that reason mesa 10.2 may be building against shared llvm. Then again I do not work on that part of mesa, so take this with a pinch of salt. Brian Paul is the only person that I've seen working/bug fixing osmesa so I'm guessing that he'll take a look in due time. Meanwhile it may be worth filing bug report(s) for these two boogers :-) Yes, please file bugs with as much info as possible. I don't think I can help with the static build issue (my autocon/make knowledge is pretty thin). I'd be happy to look into the LLVM segfault though (when I have time). -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] static version of osmesa is missing llvm symbols, bug?
yep, I'm using 10.1.0 and also noticed the same in 9.2.2. in short static linking is essential for reasonable performance of parallel applications on Cray systems. In this scenario the application is duplicated across 100s/1000s of compute nodes which share a remote-parallel file system (Lustre/GPFS). As a dynamically linked application starts, shared library loading hit's the file system hard. However, Cray suggests users run static linked executables. Their application launcher bypasses the file system and copies statically linked executable directly into a ram fs onto the set of compute nodes that a given job is scheduled to run on. This avoids file system contention that would be introduced by a parallel application's shared library loading. I maintain and support ParaView and interactive OpenGL based rendering application on NERSC's Crays. Given that this is an interactive application, having a reasonable startup time is important. Users have complained and I've observed times when using shared libraries when app startup takes more than 30 min! if we build fully static executable startup time is reduced to seconds. For me statically linked mesa is important, which is why I want to report this. Without OSMesa we can't use these systems, and the new llvmpipe OSMesa state tracker has been really awesome, allowing us to do things we couldn't in the past without GPUs. I hope that you don't discontinue static link support. We have experienced some segfaults in llvmpipe OSMesa in the static linked version (bt shows SEGV at create_jit_texture_type.isra.1@draw_llvm.c:128). If I can reproduce this off the Cray I will file a bug report. Thought I'd mention in case you can confirm that there is a known issue with the static link. Thanks Burlen On 03/11/2014 03:13 PM, Emil Velikov wrote: On 11/03/14 20:31, Burlen Loring wrote: Hi All, Hi Burlen When I make a static build of mesa with osmesa+llvm, all of the llvm related symbols are undefined in the resulting libOSMesa.a archive. There is an "la" file produced that lists the dependencies, however shouldn't those all be linked into the installed archive? for reference see my configure line below. Earlier today I have pushed a patch [1] for mesa that completely disabled static building for all of mesa. While that may not be the reason for the problem you're seeing (afaics you're using mesa 10.1.0 and my patch just made it into master) it would be great if you can let us know what the your use case of static OSMesa is, so that we can evaluate the situation. Many thanks Emil P.S. With the commit [1] --enable-static --disable-shared will produce an warning message and will fall back to --disable-static --enable-shared. [1] http://cgit.freedesktop.org/mesa/mesa/commit/?id=a6efbac9fb502c4f0166e7a0680b6828e1f6926c Burlen Mesa-10.1.0$make distclean; autoreconf -fi; ./configure CXXFLAGS="-O2 -g -fPIC -DDEFAULT_SOFTWARE_DEPTH_BITS=31" CFLAGS="-O2 -g -fPIC -DDEFAULT_SOFTWARE_DEPTH_BITS=31" --enable-static=yes --enable-shared=no --disable-xvmc --disable-glx --disable-dri --with-dri-drivers= --with-gallium-drivers=swrast --enable-texture-float --disable-shared-glapi --disable-egl --with-egl-platforms= --enable-gallium-osmesa --enable-gallium-llvm=yes --with-llvm-prefix=/work/apps/llvm/3.2/ --prefix=/work/apps/mesa-10.1.0-a && make -j2 && make -j4 install ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] static version of osmesa is missing llvm symbols, bug?
Hi All, When I make a static build of mesa with osmesa+llvm, all of the llvm related symbols are undefined in the resulting libOSMesa.a archive. There is an "la" file produced that lists the dependencies, however shouldn't those all be linked into the installed archive? for reference see my configure line below. Burlen Mesa-10.1.0$make distclean; autoreconf -fi; ./configure CXXFLAGS="-O2 -g -fPIC -DDEFAULT_SOFTWARE_DEPTH_BITS=31" CFLAGS="-O2 -g -fPIC -DDEFAULT_SOFTWARE_DEPTH_BITS=31" --enable-static=yes --enable-shared=no --disable-xvmc --disable-glx --disable-dri --with-dri-drivers= --with-gallium-drivers=swrast --enable-texture-float --disable-shared-glapi --disable-egl --with-egl-platforms= --enable-gallium-osmesa --enable-gallium-llvm=yes --with-llvm-prefix=/work/apps/llvm/3.2/ --prefix=/work/apps/mesa-10.1.0-a && make -j2 && make -j4 install ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] DEFAULT_SOFTWARE_DEPTH_BITS=31
On 11/07/2013 08:45 AM, burlen wrote: On 11/07/2013 08:14 AM, Brian Paul wrote: On 11/07/2013 09:09 AM, burlen wrote: On 11/07/2013 06:42 AM, Brian Paul wrote: On 11/06/2013 04:59 PM, burlen wrote: On 11/06/2013 12:58 PM, Brian Paul wrote: On 11/06/2013 12:34 PM, burlen wrote: When I build osmesa with --with-osmesa-bits=32 I notice that I get 31 bits by way of the compile line define -DDEFAULT_SOFTWARE_DEPTH_BITS=31. What's the story with the number 31? Is 31 bits really better than 32? IIRC, 32 bit Z never worked properly because of float->int conversion problems and such. I think I found that 31 bits worked though. It's been a long time... I'm using OSMesa with VTK for rendering on systems that do not have graphics hardware. I need higher than default depth buffer with OSMesa to prevent z-buffer fighting artifacts in some cases when rendering in parallel. I found that --with-osmesa-bits=32 does the trick. however when building osmesa with 32 bits, most line rendering fails. Here is a representative image diff from our regression suite that shows an example of the bug https://urldefense.proofpoint.com/v1/url?u=http://open.cdash.org/testDetails.php?test%3D216532438%26build%3D3087854&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=%2BYxiKNKy6tM2b9uufQKWyLEbSfkSZWpC8Kv9gQu9jJs%3D%0A&s=0f54945a95ef4530f46e70322823ee22159a9400fe3fae6b9c4a324a93ee3c00 <https://urldefense.proofpoint.com/v1/url?u=http://open.cdash.org/testDetails.php?test%3D216532438%26build%3D3087854&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=RSWC%2F0O7rDfFjJWLpUVeoSImwj8RMeWUaKnhSM%2Fx2Nk%3D%0A&s=11a634d8629f9a7fc613440fd0337a158f6951974892d2427bae4b5f570ad641> , there are 80 other failed tests, the ones I examined were all the same. Experimenting with --with-osmesa-bits options, I've found that using 32 causes the issue, while using 8 , 16 or not using it all doesn't. Do you have any idea about this? I set DEFAULT_SOFTWARE_DEPTH_BITS=32 and tried a few demo programs and they look OK so far. Could you possibly create an apitrace of one of the failing cases? did you set DEFAULT_SOFTWARE_DEPTH_BITS=32 or --with-osmesa-bits=32? --with-osmesa-bits=16 also sets depth bits to 31, and that case doesn't have the problem. so seems that it's something other than the depth bits about the --with-osmesa-bits=32 build. I did -DDEFAULT_SOFTWARE_DEPTH_BITS=32 I'll see about the apitrace I'm not actually sure what it'll do with OSMesa. But if you can get anything and I can make a text dump of the GL calls that'll help. apitrace crashes hard with OSMesa. Works fine when I use my ATI drivers though. Not sure what the deal is, but looks like that may be a dead end. I learned from the apitrace mailing list apitrace is currently incompatible with OSMesa. -DDEFAULT_SOFTWARE_DEPTH_BITS=32, doesn't trigger the issue, you'll need --with-osmesa-bits=32. I filed an official bug report so it doesn't get lost. Thanks Burlen ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] DEFAULT_SOFTWARE_DEPTH_BITS=31
On 11/07/2013 08:14 AM, Brian Paul wrote: On 11/07/2013 09:09 AM, burlen wrote: On 11/07/2013 06:42 AM, Brian Paul wrote: On 11/06/2013 04:59 PM, burlen wrote: On 11/06/2013 12:58 PM, Brian Paul wrote: On 11/06/2013 12:34 PM, burlen wrote: When I build osmesa with --with-osmesa-bits=32 I notice that I get 31 bits by way of the compile line define -DDEFAULT_SOFTWARE_DEPTH_BITS=31. What's the story with the number 31? Is 31 bits really better than 32? IIRC, 32 bit Z never worked properly because of float->int conversion problems and such. I think I found that 31 bits worked though. It's been a long time... I'm using OSMesa with VTK for rendering on systems that do not have graphics hardware. I need higher than default depth buffer with OSMesa to prevent z-buffer fighting artifacts in some cases when rendering in parallel. I found that --with-osmesa-bits=32 does the trick. however when building osmesa with 32 bits, most line rendering fails. Here is a representative image diff from our regression suite that shows an example of the bug https://urldefense.proofpoint.com/v1/url?u=http://open.cdash.org/testDetails.php?test%3D216532438%26build%3D3087854&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=%2BYxiKNKy6tM2b9uufQKWyLEbSfkSZWpC8Kv9gQu9jJs%3D%0A&s=0f54945a95ef4530f46e70322823ee22159a9400fe3fae6b9c4a324a93ee3c00 <https://urldefense.proofpoint.com/v1/url?u=http://open.cdash.org/testDetails.php?test%3D216532438%26build%3D3087854&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=RSWC%2F0O7rDfFjJWLpUVeoSImwj8RMeWUaKnhSM%2Fx2Nk%3D%0A&s=11a634d8629f9a7fc613440fd0337a158f6951974892d2427bae4b5f570ad641> , there are 80 other failed tests, the ones I examined were all the same. Experimenting with --with-osmesa-bits options, I've found that using 32 causes the issue, while using 8 , 16 or not using it all doesn't. Do you have any idea about this? I set DEFAULT_SOFTWARE_DEPTH_BITS=32 and tried a few demo programs and they look OK so far. Could you possibly create an apitrace of one of the failing cases? did you set DEFAULT_SOFTWARE_DEPTH_BITS=32 or --with-osmesa-bits=32? --with-osmesa-bits=16 also sets depth bits to 31, and that case doesn't have the problem. so seems that it's something other than the depth bits about the --with-osmesa-bits=32 build. I did -DDEFAULT_SOFTWARE_DEPTH_BITS=32 I'll see about the apitrace I'm not actually sure what it'll do with OSMesa. But if you can get anything and I can make a text dump of the GL calls that'll help. apitrace crashes hard with OSMesa. Works fine when I use my ATI drivers though. Not sure what the deal is, but looks like that may be a dead end. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] DEFAULT_SOFTWARE_DEPTH_BITS=31
On 11/07/2013 06:42 AM, Brian Paul wrote: On 11/06/2013 04:59 PM, burlen wrote: On 11/06/2013 12:58 PM, Brian Paul wrote: On 11/06/2013 12:34 PM, burlen wrote: When I build osmesa with --with-osmesa-bits=32 I notice that I get 31 bits by way of the compile line define -DDEFAULT_SOFTWARE_DEPTH_BITS=31. What's the story with the number 31? Is 31 bits really better than 32? IIRC, 32 bit Z never worked properly because of float->int conversion problems and such. I think I found that 31 bits worked though. It's been a long time... I'm using OSMesa with VTK for rendering on systems that do not have graphics hardware. I need higher than default depth buffer with OSMesa to prevent z-buffer fighting artifacts in some cases when rendering in parallel. I found that --with-osmesa-bits=32 does the trick. however when building osmesa with 32 bits, most line rendering fails. Here is a representative image diff from our regression suite that shows an example of the bug http://open.cdash.org/testDetails.php?test=216532438&build=3087854 <https://urldefense.proofpoint.com/v1/url?u=http://open.cdash.org/testDetails.php?test%3D216532438%26build%3D3087854&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=RSWC%2F0O7rDfFjJWLpUVeoSImwj8RMeWUaKnhSM%2Fx2Nk%3D%0A&s=11a634d8629f9a7fc613440fd0337a158f6951974892d2427bae4b5f570ad641> , there are 80 other failed tests, the ones I examined were all the same. Experimenting with --with-osmesa-bits options, I've found that using 32 causes the issue, while using 8 , 16 or not using it all doesn't. Do you have any idea about this? I set DEFAULT_SOFTWARE_DEPTH_BITS=32 and tried a few demo programs and they look OK so far. Could you possibly create an apitrace of one of the failing cases? did you set DEFAULT_SOFTWARE_DEPTH_BITS=32 or --with-osmesa-bits=32? --with-osmesa-bits=16 also sets depth bits to 31, and that case doesn't have the problem. so seems that it's something other than the depth bits about the --with-osmesa-bits=32 build. I'll see about the apitrace Thanks Burlen ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] DEFAULT_SOFTWARE_DEPTH_BITS=31
On 11/06/2013 12:58 PM, Brian Paul wrote: On 11/06/2013 12:34 PM, burlen wrote: When I build osmesa with --with-osmesa-bits=32 I notice that I get 31 bits by way of the compile line define -DDEFAULT_SOFTWARE_DEPTH_BITS=31. What's the story with the number 31? Is 31 bits really better than 32? IIRC, 32 bit Z never worked properly because of float->int conversion problems and such. I think I found that 31 bits worked though. It's been a long time... I'm using OSMesa with VTK for rendering on systems that do not have graphics hardware. I need higher than default depth buffer with OSMesa to prevent z-buffer fighting artifacts in some cases when rendering in parallel. I found that --with-osmesa-bits=32 does the trick. however when building osmesa with 32 bits, most line rendering fails. Here is a representative image diff from our regression suite that shows an example of the bug http://open.cdash.org/testDetails.php?test=216532438&build=3087854 , there are 80 other failed tests, the ones I examined were all the same. Experimenting with --with-osmesa-bits options, I've found that using 32 causes the issue, while using 8 , 16 or not using it all doesn't. Do you have any idea about this? Thanks Burlen ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] DEFAULT_SOFTWARE_DEPTH_BITS=31
When I build osmesa with --with-osmesa-bits=32 I notice that I get 31 bits by way of the compile line define -DDEFAULT_SOFTWARE_DEPTH_BITS=31. What's the story with the number 31? Is 31 bits really better than 32? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 9.2.2 OSMesa classic 80 new regressions in VTK
On 11/05/2013 09:42 AM, Ian Romanick wrote: On 11/05/2013 09:32 AM, burlen wrote: Upgrading from 9.2.0 to 9.2.2 with OSMesa classic I'm seeing 80 new regressions in VTK. http://open.cdash.org/viewTest.php?onlyfailed&buildid=3087854 click "Failed" to see an image diff. Maybe related to line rendering? Any chance a mesa developer could investigate? Can you bisect? OK, by git bisect I've noticed that this isn't a regression in between 9.2 and 9.2.2! The problem is because in my latest dashboard builds I'm using --with-osmesa-bits=32 which is how I usually deploy osmesa because we zbuffer precision issues in the past. Removing this option this tests all pass again. Unfortunately I don't know how long this option has been a problem since the few VTK dashboards that test Mesa have never as far as I know built withh 32 bits. :-( does this help you guys at all? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] 9.2.2 OSMesa classic 80 new regressions in VTK
Upgrading from 9.2.0 to 9.2.2 with OSMesa classic I'm seeing 80 new regressions in VTK. http://open.cdash.org/viewTest.php?onlyfailed&buildid=3087854 click "Failed" to see an image diff. Maybe related to line rendering? Any chance a mesa developer could investigate? Burlen ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 9.2 release candidate 1
Hi Ian and All, I tested the release candidate's llvmpipe OS Mesa on VTK's regression suite. it did fairly well 99% pass, however there are some regressions and segv's compared to OS Mesa in 9.1.5, which passes 100%. (data below) There's a volunteer who graciously runs nightly regression suite nightly against various Mesa builds and makes these dashboards public[1]. Here's the list of failed tests for last night's OS Mesa run (on 2.1 Mesa 9.3.0-devel (git-ff3cb37)) , http://open.cdash.org/viewTest.php?onlyfailed&buildid=3003558. visit the above link, if you click on red "failed" links, you can see an image diff, or in the case of tests failed with status "OTHER_FAULT" a stack trace. How nice is that? Have you considered using VTK for pre-release validation? I'd never suggest that it be your only validation, for one thing it's only using OpenGL 2.1 + common extensions, so it won't give anywhere near complete coverage of Open GL. But, the nice thing about VTK is the level of testing that it goes through. Because of this it could be used as a reference by comparing regression test results using Mesa against those attained with recent NVIDIA hardware + drivers, which provide 100% coverage in VTK and 100% of the tests pass, or even between various Mesa renderers as some are less buggy than others. it's quite easy to set up and run and the web interface is very helpful for examining the results displaying image diffs etc. btw, historically VTK has only used OpenGL 1.1 features with OS Mesa. In VTK master branch VTK will now take advantage of whatever Open GL features Mesa provides with OS Mesa. We've also made an attempt to visit any features that were specifically disabled because of bugs in Mesa. We've added a build flag VTK_IGNORE_GLDRIVER_BUGS that will enable all such features for validation of new Mesa releases. If you're curious about which Mesa was used in a given VTK dashboard submission look at the output of the LoadOpenGLExtension test it prints out OpenGL's vendor, version, renderer strings. Thanks for all the great work, I'm looking forward to the 9.2.0 release. Burlen [1] http://open.cdash.org/index.php?project=VTK&filtercount=1&showfilters=1&field1=buildname/string&compare1=63&value1=Mesa here's info about my test run of your release candidate: mesa config ./configure --disable-xvmc --disable-glx --disable-dri --with-dri-drivers= --with-gallium-drivers=swrast --enable-texture-float --disable-shared-glapi --disable-egl --with-egl-platforms= --enable-gallium-llvm --with-llvm-prefix=/work/apps/llvm/3.2 --enable-osmesa --prefix=/work/apps/mesa-9.2.0 --with-osmesa-bits=32 VTK git b3e976b 1633: GL_VENDOR: VMware, Inc. 1633: GL_VERSION: 2.1 Mesa 9.2.0-rc1 1633: GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.2, 128 bits) 99% tests passed, 10 tests failed out of 1827 Total Test time (real) = 542.40 sec The following tests FAILED: 693 - vtkFiltersHybridPython-largeImageOffset (OTHER_FAULT) 694 - vtkFiltersHybridPython-largeImageParallel (OTHER_FAULT) 706 - vtkFiltersHybridTcl-largeImageOffset (SEGFAULT) 707 - vtkFiltersHybridTcl-largeImageParallel (SEGFAULT) 1562 - vtkRenderingCorePython-TestOpacity2 (Failed) 1573 - vtkRenderingCoreTcl-TestOpacity2 (Failed) 1690 - vtkRenderingOpenGLCxx-TestTransformCoordinateUseDouble (Failed) 1726 - vtkRenderingParallelCxx-MPI-TestPShadowMapPass (Failed) 1778 - vtkRenderingVolumePython-cursor3D (OTHER_FAULT) 1811 - vtkViewsInfovisCxx-TestConeLayoutStrategy (Failed) Errors while running CTest here's output from one of the above that segv's for the rc but not the other versions of Mesa that we have coverage for. $ctest -R vtkFiltersHybridPython-largeImageOffset --verbose UpdateCTestConfiguration from :/work/ext/ParaView/sqtk-pv/vtk-build-mesa-9.2.0/DartConfiguration.tcl Parse Config file:/work/ext/ParaView/sqtk-pv/vtk-build-mesa-9.2.0/DartConfiguration.tcl Add coverage exclude regular expressions. Add coverage exclude: vtk.*TCLInit.cxx Add coverage exclude: vtk[^\.]+(Java|Python|Tcl).cxx Add coverage exclude: .*vtkOpenGLState.* Add coverage exclude: .*Testing.Cxx.*cxx Add coverage exclude: .*Testing.Cxx.*h Add coverage exclude: .*moc_.*cxx Add coverage exclude: .*/Utilities/.* Add coverage exclude: .*/ThirdParty/.* UpdateCTestConfiguration from :/work/ext/ParaView/sqtk-pv/vtk-build-mesa-9.2.0/DartConfiguration.tcl Parse Config file:/work/ext/ParaView/sqtk-pv/vtk-build-mesa-9.2.0/DartConfiguration.tcl Test project /work/ext/ParaView/sqtk-pv/vtk-build-mesa-9.2.0 Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 693 Start 693: vtkFiltersHybridPython-largeImageOffset 693: Test command: /work/ext/ParaVi
