Thread: [Paracomp-devel] Crash in pcSystemFinalize
Brought to you by:
shreekumar
Menu
▾
▴
paracomp-devel
|
From: Stefan E. <eil...@gm...> - 2008-04-28 14:27:56
|
Me again,
With the simple compositing test in Equalizer I now get a segmentation
fault in pcSystemFinalize:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47310501091568 (LWP 9428)]
0x00002b0753802f84 in _dl_make_stack_executable () from /lib64/ld-
linux-x86-64.so.2
(gdb) where
#0 0x00002b0753802f84 in _dl_make_stack_executable () from /lib64/ld-
linux-x86-64.so.2
#1 0x00002b07537fe1e6 in _dl_rtld_di_serinfo () from /lib64/ld-linux-
x86-64.so.2
#2 0x00002b0754afb71d in dlerror () from /lib/libdl.so.2
#3 0x00002b0754afb25f in dlclose () from /lib/libdl.so.2
#4 0x00002aaaaab819a3 in pcSystemFinalize () from /opt/paracomp/lib64/
libparcomp.so
#5 0x00002b0753b304f0 in pcSystemFinalize ()
from /home/eilemann/Software/equalizer/trunk/src/./build/Linux/lib/
libeq.so
#6 0x00002b0753aec7f9 in eq::exit () from /home/eilemann/Software/
equalizer/trunk/src/./build/Linux/lib/libeq.so
#7 0x000000000040405c in main (argc=1, argv=0x7fff572b7918) at
test.cpp:79
OS: Ubuntu 6.10
HW: Opteron 248
I also get similar, disappointing performance results as on my Mac:
PC: 15 images: 11.431 ms (1601.83 MB/s)
Eq: 15 images: 9.207 ms (1988.76 MB/s)
Do I have to configure something in order to use the opteron 'plugin'?
Cheers,
Stefan.
--
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann
|
|
From: Shree K. <shr...@hp...> - 2008-04-28 14:47:48
|
Hi Stefan On Mon, 2008-04-28 at 14:27 +0000, Stefan Eilemann wrote: > Me again, > > With the simple compositing test in Equalizer I now get a segmentation > fault in pcSystemFinalize: ... > > OS: Ubuntu 6.10 > HW: Opteron 248 > Can you do a build with "release=0" (to enable debug symbols) and post the stack trace ? That would help me a bit. > > I also get similar, disappointing performance results as on my Mac: > > PC: 15 images: 11.431 ms (1601.83 MB/s) > Eq: 15 images: 9.207 ms (1988.76 MB/s) I think the slower code is primarily a difference in compiler optimization behaviour. I haven't found a good solution for this right now. The following approach looks like a sufficient workaround -- I'll make a special case for the pixel formats you are using (Currently this is going through some template expansion and I don't know why the performance is different. Once the format is special cased the results will match - because they are basically the same code :-) I'll do this tomorrow and update you. > Do I have to configure something in order to use the opteron 'plugin'? > That's not needed for depth compositing, since there is no special code. For alpha blending, it will get used automatically (provided it's found in PC_LIBRARY_PATH/composite). HTH -- Shree |
|
From: Stefan E. <eil...@gm...> - 2008-04-28 15:54:15
|
On 28. Apr 2008, at 16:46, Shree Kumar wrote: > Can you do a build with "release=0" (to enable debug symbols) and post > the stack trace ? That would help me a bit. I'ld love to, the only problem is that the debug build doesn't crash. Nice. Let me know how I can help. >> Do I have to configure something in order to use the opteron >> 'plugin'? >> > That's not needed for depth compositing, since there is no special > code. > For alpha blending, it will get used automatically (provided it's > found > in PC_LIBRARY_PATH/composite). Makes sense. I'll have to integrate/enable the alpha blending code then. Cheers, Stefan. -- http://www.eyescale.ch http://www.equalizergraphics.com http://www.linkedin.com/in/eilemann |
|
From: Shree K. <shr...@hp...> - 2008-04-29 04:11:09
|
On Mon, 2008-04-28 at 15:53 +0000, Stefan Eilemann wrote: > > Can you do a build with "release=0" (to enable debug symbols) and post > > the stack trace ? That would help me a bit. > > I'ld love to, the only problem is that the debug build doesn't crash. > Nice. > > Let me know how I can help. I have a feeling I sent you down the wrong path. This is a problem I am investigating. The basic issue is that any dlclose() causes a crash with newer GCC compilers() - 4.x I think. Can you check pcstub.c & let me know if one of the dlclose() calls is commented out ? I unintentionally checked in such a change to pcstub.c. Generally this problem manifests as a crash at pcSystemInitialize(). > > > >> Do I have to configure something in order to use the opteron > >> 'plugin'? > >> > > That's not needed for depth compositing, since there is no special > > code. > > For alpha blending, it will get used automatically (provided it's > > found > > in PC_LIBRARY_PATH/composite). > > Makes sense. I'll have to integrate/enable the alpha blending code then. Yes. That will get us to some more points of benchmarking :-) Regards -- Shree |
|
From: James S P. <jam...@ma...> - 2008-04-28 23:24:28
|
Shree, I think this is the same crash we've both seen when using gcc 4.1.2, see: [Paracomp-users] Paracomp crash when compiled in release mode James Stefan Eilemann wrote: > On 28. Apr 2008, at 16:46, Shree Kumar wrote: > >> Can you do a build with "release=0" (to enable debug symbols) and post >> the stack trace ? That would help me a bit. > > I'ld love to, the only problem is that the debug build doesn't crash. > Nice. > > Let me know how I can help. > > >>> Do I have to configure something in order to use the opteron >>> 'plugin'? >>> >> That's not needed for depth compositing, since there is no special >> code. >> For alpha blending, it will get used automatically (provided it's >> found >> in PC_LIBRARY_PATH/composite). > > Makes sense. I'll have to integrate/enable the alpha blending code then. > > > Cheers, > > Stefan. > -- ------------------------------------------------------------------------ James S. Perrin Visualization Research Computing Services The University of Manchester Kilburn Building, Oxford Road Manchester, M13 9PL t: +44 (0) 161 275 6945 e: jam...@ma... w: www.manchester.ac.uk/researchcomputing ------------------------------------------------------------------------ "The test of intellect is the refusal to belabour the obvious" - Alfred Bester ------------------------------------------------------------------------ |
|
From: Shree K. <shr...@hp...> - 2008-04-29 04:13:21
|
On Mon, 2008-04-28 at 23:23 +0000, James S Perrin wrote: > Shree, > > I think this is the same crash we've both seen when using gcc 4.1.2, see: > > [Paracomp-users] Paracomp crash when compiled in release mode > Right, you caught that correctly! This problem is quickly becoming a pain - I'll try to isolate this problem by writing some minimal code. Regards -- Shree |
|
From: Shree K. <shr...@hp...> - 2008-04-29 08:52:47
|
Stefan, James, I fixed the dlclose() related crash that you guys reported. Changes are both in the trunk & in shree/features/composite_binary branch. http://paracomp.svn.sourceforge.net/viewvc/paracomp?view=rev&revision=60 Hope that fixes the crashes for you! Cheers -- Shree On Tue, 2008-04-29 at 09:43 +0530, Shree Kumar wrote: > On Mon, 2008-04-28 at 23:23 +0000, James S Perrin wrote: > > Shree, > > > > I think this is the same crash we've both seen when using gcc 4.1.2, see: > > > > [Paracomp-users] Paracomp crash when compiled in release mode > > > Right, you caught that correctly! This problem is quickly becoming a > pain - I'll try to isolate this problem by writing some minimal code. > > Regards > -- Shree > |
|
From: Shree K. <shr...@hp...> - 2008-04-29 11:41:47
|
On Mon, 2008-04-28 at 14:27 +0000, Stefan Eilemann wrote: > OS: Ubuntu 6.10 > HW: Opteron 248 > > I also get similar, disappointing performance results as on my Mac: > > PC: 15 images: 11.431 ms (1601.83 MB/s) > Eq: 15 images: 9.207 ms (1988.76 MB/s) The performance difference beats me. Here is a test I did today : I compiled equalizer both with and without paracomp (essentially your latest commit). And ran the benchmark. Virtually no difference. Can you sending me the following - On your system, note down the command line that is used to compile compositor.cpp (from Equalizer). Also note the command line that is used to compile compositecpu.cpp (in Paracomp). Then send me both lines. Additionally, (if you can try this!), compile equalizer with optimization enabled & debug symbols enabled (equivalent to "-O<n> -g"). Do the same with Paracomp - by adding a "-g" to the "-O<n>". After that, run "objdump -dS compositor.o" and "objdump -dS build/compositecpu.os" and get me both outputs. That's the best approach I can think of at the moment... Thanks for your patience ! -- Shree |
|
From: Shree K. <shr...@hp...> - 2008-04-29 13:36:46
|
On Tue, 2008-04-29 at 12:20 +0000, Stefan Eilemann wrote: > If you set EQ_LOG_LEVEL to INFO, you should see a note that Paracomp > is used. Maybe for some reason it wasn't picked up on your system. > I depended on a warning from Paracomp (that pclib.conf) wasn't found for ensuring that Paracomp was indeed being used. > > > > > g++ -I.././build/Linux/include -O2 -g -m64 -fPIC -DLinux -DGLX - > DEQ_CHECK_THREADSAFETY -DEQ_USE_COMPRESSION -DGLEW_MX - > DEQ_USE_PARACOMP -Wall -Wnon-virtual-dtor -Wsign-promo -Wshadow -Wno- > unknown-pragmas -Wno-unused-parameter -Wno-write-strings -I/opt/ > paracomp/lib64/../include -m64 -fPIC -I/usr/X11R6/include - > DEQUALIZER_EXPORTS -DSUBDIR=\"./lib\" -c client/compositor.cpp -o .././ > obj/./lib/client/compositor.Linux.o > > g++ -o build/compositecpu.os -c -fPIC -O3 -g -Wall -DBUILD_x86_64 - > Ibuild -I. -I/home/eilemann/Software/paracomp/include -I/usr/mellanox/ > include -I/usr/local/ofed/include compositecpu.cpp > Seem the same to me. > > Additionally, (if you can try this!), compile equalizer with > > optimization enabled & debug symbols enabled (equivalent to "-O<n> - > > g"). > > Do the same with Paracomp - by adding a "-g" to the "-O<n>". > > > > After that, run "objdump -dS compositor.o" and "objdump -dS > > build/compositecpu.os" and get me both outputs. > Didn't see anything useful there :-( Turned out to be a more difficult exercise than I had expected. Ok - here is one more try. I have copied the equalizer depth compositing code itself into Paracomp (essentially a special case for debugging just this case) & comitted the change (rev 63). Can you try updating to that rev & run a quick performance test ? Thanks -- Shree |
|
From: Stefan E. <eil...@gm...> - 2008-04-29 14:00:33
|
On 29. Apr 2008, at 15:35, Shree Kumar wrote: > Ok - here is one more try. I have copied the equalizer depth > compositing > code itself into Paracomp (essentially a special case for debugging > just > this case) & comitted the change (rev 63). Can you try updating to > that > rev & run a quick performance test ? Shree, I have to go somewhere now. I'll probably send it to you tomorrow. Cheers, Stefan. -- http://www.eyescale.ch http://www.equalizergraphics.com http://www.linkedin.com/in/eilemann |
|
From: Shree K. <shr...@hp...> - 2008-05-13 11:25:24
|
Hi Stephen, On Tue, 2008-04-29 at 14:00 +0000, Stefan Eilemann wrote: > On 29. Apr 2008, at 15:35, Shree Kumar wrote: > > > Ok - here is one more try. I have copied the equalizer depth > > compositing > > code itself into Paracomp (essentially a special case for debugging > > just > > this case) & comitted the change (rev 63). Can you try updating to > > that > > rev & run a quick performance test ? > > Shree, > > I have to go somewhere now. I'll probably send it to you tomorrow. > Did you get to try this ? I have some time to look at it in the next few days. So any input from you would be useful. Thanks -- Shree |
|
From: Stefan E. <eil...@gm...> - 2008-05-13 11:34:18
|
On 13. May 2008, at 13:25, Shree Kumar wrote: > Did you get to try this ? I have some time to look at it in the next > few > days. So any input from you would be useful. Hi Shree, It seems my bad conscience carried over to you. I just remembered this, as I am currently integrating a patch for CPU-based assembly used in our volume renderer. As soon as I have checked this in, I'll get back to try PC. Iirc the crash was solved, and I was about to retest the performance issue. The last time I wanted to test it, sourceforge went down and then I promptly forgot it. :-/ I'll send you a link to the alpha-compositing patch. We do things not quite straight-forward in order to support colored backgrounds in eVolve. Basically we blend as if using glBlendFuncSeparate( GL_ONE, GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA ). Can I do this with ParaComp as well? Cheers, Stefan. -- http://www.eyescale.ch http://www.equalizergraphics.com http://www.linkedin.com/in/eilemann |
|
From: Stefan E. <eil...@gm...> - 2008-05-13 11:46:33
|
On 13. May 2008, at 13:34, Stefan Eilemann wrote: > I'll send you a link to the alpha-compositing patch. We do things > not quite straight-forward in order to support colored backgrounds > in eVolve. Basically we blend as if using > glBlendFuncSeparate( GL_ONE, GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA ). > > Can I do this with ParaComp as well? Here you go: <http://equalizer.svn.sourceforge.net/equalizer/?rev=1879&view=rev > Cheers, Stefan. -- http://www.eyescale.ch http://www.equalizergraphics.com http://www.linkedin.com/in/eilemann |
|
From: Shree K. <shr...@hp...> - 2008-05-16 15:55:26
|
Hi Stefan, Stefan Eilemann wrote: > On 13. May 2008, at 13:34, Stefan Eilemann wrote: > > >> I'll send you a link to the alpha-compositing patch. We do things >> not quite straight-forward in order to support colored backgrounds >> in eVolve. Basically we blend as if using >> glBlendFuncSeparate( GL_ONE, GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA ). >> >> Can I do this with ParaComp as well? >> > > Here you go: <http://equalizer.svn.sourceforge.net/equalizer/?rev=1879&view=rev > > > I just updated my sandbox to get the changes. I think it's fairly easy to add support for the sort of compositing you are looking for. I had a good look at the code : changing the blending equation is quite easy in the C code. In the assembly language code for x86_64, the number/type of instructions remain the same :-) Quick preliminary tests on my x86_64 desktop (these are with the wrong blending equation, but I expect the same to hold on the correct blending equation too) ------ Without Paracomp ------ ./Linux/test: Alpha first op: 66.7899 ms (394.778 MB/s) ./Linux/test: Alpha second op: 69.5435 ms (379.147 MB/s) ./Linux/test: Alpha 15 images: 307.675 ms (428.491 MB/s) -------- With Paracomp --------- ./Linux/test: Alpha first op: 40.5636 ms (650.021 MB/s) ./Linux/test: Alpha second op: 51.9242 ms (507.802 MB/s) ./Linux/test: Alpha 15 images: 152.929 ms (862.071 MB/s) -------------------------------------- Small note : test.cpp isn't using alpha blending in the "Alpha 15 images" case. This is due to a missing "true" parameter to assembleFramesCPU. In line 108, you need to add a true param to assembleFramesCPU() I'll change the blending function as an experiment on monday & send you some patches. Note to myself : How to provide the same functionality as a standardized function in paracomp. Cheers -- Shree |
|
From: Maxim M. <mak...@if...> - 2008-05-21 15:40:33
|
Thanks for patch, looks like it works well. Here are numbers I've got on my G5 (ppc) (-O2 was used). I used two sets of images: images from test directory and randomly created images of the same size. Reason for this is that resulted image after blending from initial images is completely empty, that means CPU prediction of results for "if" statements will always work and in the end it could work faster (it looks from numbers that it actually happens): Images in test directory --- with Paracomp --- ./Darwin/test: Alpha first op: 108.974 ms (241.959 MB/s) ./Darwin/test: Alpha second op: 105.008 ms (251.097 MB/s) ./Darwin/test: Alpha 15 images: 672.45 ms (196.053 MB/s) -- without --- ./Darwin/test: Alpha first op: 104.519 ms (252.272 MB/s) ./Darwin/test: Alpha second op: 88.7426 ms (297.12 MB/s) ./Darwin/test: Alpha 15 images: 494.496 ms (266.607 MB/s) My "random" images --- with Paracomp --- ./Darwin/test: Alpha first op: 114.453 ms (230.376 MB/s) ./Darwin/test: Alpha second op: 123.207 ms (214.008 MB/s) ./Darwin/test: Alpha 15 images: 800.529 ms (164.686 MB/s) -- without --- ./Darwin/test: Alpha first op: 115.309 ms (228.666 MB/s) ./Darwin/test: Alpha second op: 82.4361 ms (319.85 MB/s) ./Darwin/test: Alpha 15 images: 613.568 ms (214.868 MB/s) I included patch in revision 1917 but left paracomp blending compositing disabled since it works slower for me. Maybe results on "intel" will be different so we can enable it, that needs some more testing. Regards, Max On May 20, 2008, at 7:06 AM, Shree Kumar wrote: > Hi Stefan/Max, > > I've created a temporary extension PC_COMP_ALPHA_SORT2_HP which > provides the alpha blending support you need. > > The specifics of the extension may change later, but the changes > will be easy to make. Changes are in SVN - just update to get them. > The > test_compositeEXT sample is changed to show how to use the extension. > > Plus, attached is a patch which uses the new alpha blending > capability inside equalizer (includes a small change in the test > program too). > > Do let me know if the patch works for you. You'd want to check it > with the actual application (eVolve) too - to keep away blending > surprises ;-) > > Cheers > -- Shree > > Kumar, Shree (STSD) wrote: >> >> I just updated my sandbox to get the changes. I think it's fairly >> easy to add support >> for the sort of compositing you are looking for. I had a good look >> at the code : changing the blending equation >> is quite easy in the C code. In the assembly language code for >> x86_64, the number/type of instructions remain the same :-) >> >> Quick preliminary tests on my x86_64 desktop (these are with the >> wrong blending equation, but I expect the same to >> hold on the correct blending equation too) >> ------ Without Paracomp ------ >> ./Linux/test: Alpha first op: 66.7899 ms (394.778 MB/s) >> ./Linux/test: Alpha second op: 69.5435 ms (379.147 MB/s) >> ./Linux/test: Alpha 15 images: 307.675 ms (428.491 MB/s) >> -------- With Paracomp --------- >> ./Linux/test: Alpha first op: 40.5636 ms (650.021 MB/s) >> ./Linux/test: Alpha second op: 51.9242 ms (507.802 MB/s) >> ./Linux/test: Alpha 15 images: 152.929 ms (862.071 MB/s) >> -------------------------------------- >> >> Small note : test.cpp isn't using alpha blending in the "Alpha 15 >> images" case. This is due to a missing "true" parameter to >> assembleFramesCPU. In line 108, you need to add a true param to >> assembleFramesCPU() >> >> I'll change the blending function as an experiment on monday & send >> you some patches. >> >> Note to myself : How to provide the same functionality as a >> standardized function in paracomp. >> >> Cheers >> -- Shree |
|
From: Shree K. <shr...@hp...> - 2008-05-22 11:36:34
|
Hi Max, Maxim Makhinya wrote: > Thanks for patch, looks like it works well. > That's good to know. > Here are numbers I've got on my G5 (ppc) (-O2 was used). > I used two sets of images: images from test directory > and randomly created images of the same size. Reason for > this is that resulted image after blending from initial > images is completely empty, that means CPU prediction > of results for "if" statements will always work and in > the end it could work faster (it looks from numbers > that it actually happens): > > That's a good idea if there are "if" statements in the compositing. I've seen people have a preferrence for "level/predictable" performance, but that's another story. > > I included patch in revision 1917 but left paracomp blending > compositing disabled since it works slower for me. Maybe > results on "intel" will be different so we can enable it, that > needs some more testing. > > The performance difference shouldn't be too difficult to fix now. Basically on PPC you are running the generic CPU code for compositing in Paracomp. This uses a look up table. A 64k lookup table is not good with today's technology & compilers :-) I'll intimate you when I fix the performance. Then maybe you can can give it another try. With x86_64, the alpha blending is much faster with the SSE3 code we use. I'll report some results to you once I try out this version. Cheers -- Shree > > On May 20, 2008, at 7:06 AM, Shree Kumar wrote: > > >> Hi Stefan/Max, >> >> I've created a temporary extension PC_COMP_ALPHA_SORT2_HP which >> provides the alpha blending support you need. >> >> The specifics of the extension may change later, but the changes >> will be easy to make. Changes are in SVN - just update to get them. >> The >> test_compositeEXT sample is changed to show how to use the extension. >> >> Plus, attached is a patch which uses the new alpha blending >> capability inside equalizer (includes a small change in the test >> program too). >> >> Do let me know if the patch works for you. You'd want to check it >> with the actual application (eVolve) too - to keep away blending >> surprises ;-) >> >> Cheers >> -- Shree >> >> Kumar, Shree (STSD) wrote: >> >>> I just updated my sandbox to get the changes. I think it's fairly >>> easy to add support >>> for the sort of compositing you are looking for. I had a good look >>> at the code : changing the blending equation >>> is quite easy in the C code. In the assembly language code for >>> x86_64, the number/type of instructions remain the same :-) >>> >>> Quick preliminary tests on my x86_64 desktop (these are with the >>> wrong blending equation, but I expect the same to >>> hold on the correct blending equation too) >>> ------ Without Paracomp ------ >>> ./Linux/test: Alpha first op: 66.7899 ms (394.778 MB/s) >>> ./Linux/test: Alpha second op: 69.5435 ms (379.147 MB/s) >>> ./Linux/test: Alpha 15 images: 307.675 ms (428.491 MB/s) >>> -------- With Paracomp --------- >>> ./Linux/test: Alpha first op: 40.5636 ms (650.021 MB/s) >>> ./Linux/test: Alpha second op: 51.9242 ms (507.802 MB/s) >>> ./Linux/test: Alpha 15 images: 152.929 ms (862.071 MB/s) >>> -------------------------------------- >>> >>> Small note : test.cpp isn't using alpha blending in the "Alpha 15 >>> images" case. This is due to a missing "true" parameter to >>> assembleFramesCPU. In line 108, you need to add a true param to >>> assembleFramesCPU() >>> >>> I'll change the blending function as an experiment on monday & send >>> you some patches. >>> >>> Note to myself : How to provide the same functionality as a >>> standardized function in paracomp. >>> >>> Cheers >>> -- Shree >>> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Paracomp-devel mailing list > Par...@li... > https://lists.sourceforge.net/lists/listinfo/paracomp-devel > . > > |
|
From: Shree K. <shr...@hp...> - 2008-05-20 05:06:50
Attachments:
eq-pc-alpha-blend.patch
|
Hi Stefan/Max, I've created a temporary extension PC_COMP_ALPHA_SORT2_HP which provides the alpha blending support you need. The specifics of the extension may change later, but the changes will be easy to make. Changes are in SVN - just update to get them. The test_compositeEXT sample is changed to show how to use the extension. Plus, attached is a patch which uses the new alpha blending capability inside equalizer (includes a small change in the test program too). Do let me know if the patch works for you. You'd want to check it with the actual application (eVolve) too - to keep away blending surprises ;-) Cheers -- Shree Kumar, Shree (STSD) wrote: > I just updated my sandbox to get the changes. I think it's fairly easy > to add support > for the sort of compositing you are looking for. I had a good look at > the code : changing the blending equation > is quite easy in the C code. In the assembly language code for x86_64, > the number/type of instructions remain the same :-) > > Quick preliminary tests on my x86_64 desktop (these are with the wrong > blending equation, but I expect the same to > hold on the correct blending equation too) > ------ Without Paracomp ------ > ./Linux/test: Alpha first op: 66.7899 ms (394.778 MB/s) > ./Linux/test: Alpha second op: 69.5435 ms (379.147 MB/s) > ./Linux/test: Alpha 15 images: 307.675 ms (428.491 MB/s) > -------- With Paracomp --------- > ./Linux/test: Alpha first op: 40.5636 ms (650.021 MB/s) > ./Linux/test: Alpha second op: 51.9242 ms (507.802 MB/s) > ./Linux/test: Alpha 15 images: 152.929 ms (862.071 MB/s) > -------------------------------------- > > Small note : test.cpp isn't using alpha blending in the "Alpha 15 > images" case. This is due to a missing "true" parameter to > assembleFramesCPU. In line 108, you need to add a true param to > assembleFramesCPU() > > I'll change the blending function as an experiment on monday & send > you some patches. > > Note to myself : How to provide the same functionality as a > standardized function in paracomp. > > Cheers > -- Shree |
|
From: Shree K. <shr...@hp...> - 2008-05-13 11:57:28
|
Hi Stephen, On Tue, 2008-05-13 at 11:34 +0000, Stefan Eilemann wrote: > It seems my bad conscience carried over to you. I just remembered > this, as I am currently integrating a patch for CPU-based assembly > used in our volume renderer. As soon as I have checked this in, I'll > get back to try PC. Sure, do let me know. > Iirc the crash was solved, and I was about to retest the performance > issue. The last time I wanted to test it, sourceforge went down and > then I promptly forgot it. :-/ Is this happening with sourceforge often ? I've been away for more than a week now, so can't help wondering. > I'll send you a link to the alpha-compositing patch. We do things not > quite straight-forward in order to support colored backgrounds in > eVolve. Basically we blend as if using glBlendFuncSeparate( GL_ONE, > GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA ). Do you have the background as a separate image which you composite with the volume rendering in the end ? This is possible. Paracomp implements a back to front alpha blending. Images are assumed to have pre-multiplied alpha. Images contribute (1-alpha_front)*color to the images in front of them. Basically this is the the same as stock OpenGL. Cheers -- Shree |
|
From: Stefan E. <eil...@gm...> - 2008-05-13 12:44:02
|
On 13. May 2008, at 13:55, Shree Kumar wrote: > Is this happening with sourceforge often ? I've been away for more > than > a week now, so can't help wondering. The last years sourceforge has been fairly stable. This was the only time it bit me. >> I'll send you a link to the alpha-compositing patch. We do things not >> quite straight-forward in order to support colored backgrounds in >> eVolve. Basically we blend as if using glBlendFuncSeparate( GL_ONE, >> GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA ). > > Do you have the background as a separate image which you composite > with > the volume rendering in the end ? This is possible. Yes and no. We use the framebuffer to composite in the end, using glBlendFunc( GL_ONE, GL_SRC_ALPHA ). > Paracomp implements a back to front alpha blending. Images are assumed > to have pre-multiplied alpha. Images contribute (1-alpha_front)*color > to the images in front of them. Basically this is the the same as > stock > OpenGL. We'll look into it. Regarding the performance: I've retested on my Mac. It seems the performance problem is still there: Eq, rev 1880: ./Darwin/test: DB first op: 41.4328 ms (1272.77 MB/s) ./Darwin/test: DB second op: 28.1947 ms (1870.36 MB/s) ./Darwin/test: DB 15 images: 92.7198 ms (2843.75 MB/s) PC, rev 63: ./Darwin/test: DB first op: 39.5884 ms (1332.07 MB/s) ./Darwin/test: DB second op: 26.9765 ms (1954.83 MB/s) ./Darwin/test: DB 15 images: 87.6801 ms (3007.2 MB/s) PC, rev 62: ./Darwin/test: DB first op: 45.064 ms (1170.21 MB/s) ./Darwin/test: DB second op: 32.2106 ms (1637.17 MB/s) ./Darwin/test: DB 15 images: 111.401 ms (2366.88 MB/s) Cheers, Stefan. -- http://www.eyescale.ch http://www.equalizergraphics.com http://www.linkedin.com/in/eilemann |
|
From: Maxim M. <mak...@if...> - 2008-05-13 15:18:46
|
Hello,
I'm working with Stefan on equalizer, eVolve in particular.
On May 13, 2008, at 2:44 PM, Stefan Eilemann wrote:
>
> On 13. May 2008, at 13:55, Shree Kumar wrote:
>
>> Is this happening with sourceforge often ? I've been away for more
>> than
>> a week now, so can't help wondering.
>
> The last years sourceforge has been fairly stable. This was the
> only time it bit me.
>
>>> I'll send you a link to the alpha-compositing patch. We do things
>>> not
>>> quite straight-forward in order to support colored backgrounds in
>>> eVolve. Basically we blend as if using glBlendFuncSeparate( GL_ONE,
>>> GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA ).
>>
>> Do you have the background as a separate image which you composite
>> with
>> the volume rendering in the end ? This is possible.
>
> Yes and no. We use the framebuffer to composite in the end, using
> glBlendFunc( GL_ONE, GL_SRC_ALPHA ).
>
>> Paracomp implements a back to front alpha blending. Images are
>> assumed
>> to have pre-multiplied alpha. Images contribute (1-alpha_front)
>> *color
>> to the images in front of them. Basically this is the the same as
>> stock
>> OpenGL.
>
> We'll look into it.
Assuming that we have 1 background image (just "background" in the
text bellow) and several images (which contains alpha values) we want
to blend on to this background, there are two different strategies
in eVolve to obtain the result:
1) Blend sequentially all images back to front on to background (this
is our GPU based compositing at the moment);
2) Blend all images between each other and then blend resulted
image on to background (this is our CPU compositing; we have
background on GPU, so we blend images on CPU and then use GPU
blending once to get final result on GPU).
For the first strategy glBlendFunc(GL_ONE, GL_SRC_ALPHA) is used,
and if final image is in main memory not on GPU, I guess, Paracomp
compositing could be used without changes. For the second strategy
if we have background on GPU (form previous rendering or so) the
compositing is different.
To be able to blend our images on CPU and then blend resulted image on
to some background
glBlendFuncSeparate( GL_ONE, GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA )
has to be used. Using this function we get resulted image with
same properties as two input once:
1) we can blend it on to any background with
glBlendFunc(GL_ONE, GL_SRC_ALPHA), result will be as if we would
blend two of them sequentially with glBlendFunc(GL_ONE,
GL_SRC_ALPHA)
and
2) we can blend it with another slice using
glBlendFuncSeparate( GL_ONE, GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA )
and resulted image will have same properties.
glBlendFunc(GL_ONE, GL_SRC_ALPHA) cannot be used here to blend slices
one to another because such blending will not accumulate resulted
"amount of light which passes through the volume" correctly in our
case.
HTH,
Maxim Makhinya
|
|
From: Shree K. <shr...@hp...> - 2008-05-14 10:26:58
|
Hi Stephen, On Tue, 2008-05-13 at 12:44 +0000, Stefan Eilemann wrote: > Regarding the performance: I've retested on my Mac. It seems the > performance problem is still there: > > Eq, rev 1880: > ./Darwin/test: DB first op: 41.4328 ms (1272.77 MB/s) > ./Darwin/test: DB second op: 28.1947 ms (1870.36 MB/s) > ./Darwin/test: DB 15 images: 92.7198 ms (2843.75 MB/s) > > > PC, rev 63: > ./Darwin/test: DB first op: 39.5884 ms (1332.07 MB/s) > ./Darwin/test: DB second op: 26.9765 ms (1954.83 MB/s) > ./Darwin/test: DB 15 images: 87.6801 ms (3007.2 MB/s) > > PC, rev 62: > > ./Darwin/test: DB first op: 45.064 ms (1170.21 MB/s) > ./Darwin/test: DB second op: 32.2106 ms (1637.17 MB/s) > ./Darwin/test: DB 15 images: 111.401 ms (2366.88 MB/s) > PC rev 63 seems to be faster than Eq rev 1880. Am I missing something ? Of course, I'm still puzzled about the perf difference between Eq and rev 63 :-) -- Shree |
|
From: Shree K. <shr...@hp...> - 2008-05-14 11:10:37
|
Hi Maxim, On Tue, 2008-05-13 at 15:18 +0000, Maxim Makhinya wrote: > Hello, > > I'm working with Stefan on equalizer, eVolve in particular. > Nice to see you here. And welcome :-) Thanks for the explanations. > Assuming that we have 1 background image (just "background" in the > text bellow) and several images (which contains alpha values) we want > to blend on to this background, there are two different strategies > in eVolve to obtain the result: > > 1) Blend sequentially all images back to front on to background (this > is our GPU based compositing at the moment); > > 2) Blend all images between each other and then blend resulted > image on to background (this is our CPU compositing; we have > background on GPU, so we blend images on CPU and then use GPU > blending once to get final result on GPU). > > For the first strategy glBlendFunc(GL_ONE, GL_SRC_ALPHA) is used, > and if final image is in main memory not on GPU, I guess, Paracomp > compositing could be used without changes. I'm puzzled by the destination factor of GL_SRC_ALPHA. Are you guys using alpha as an "opacity" value ? (As opposed to classical volume rendering which uses alpha as transparency) Paracomp implements back to front blending with glBlendFunc(GL_ONE, ONE_MINUS_SRC_ALPHA). > For the second strategy > if we have background on GPU (form previous rendering or so) the > compositing is different. > To be able to blend our images on CPU and then blend resulted image on > to some background > glBlendFuncSeparate( GL_ONE, GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA ) > has to be used. Using this function we get resulted image with > same properties as two input once: > 1) we can blend it on to any background with > glBlendFunc(GL_ONE, GL_SRC_ALPHA), result will be as if we would > blend two of them sequentially with glBlendFunc(GL_ONE, > GL_SRC_ALPHA) > and > 2) we can blend it with another slice using > glBlendFuncSeparate( GL_ONE, GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA ) > and resulted image will have same properties. > > glBlendFunc(GL_ONE, GL_SRC_ALPHA) cannot be used here to blend slices > one to another because such blending will not accumulate resulted > "amount of light which passes through the volume" correctly in our > case. > Yes, the problem with glBlendFunc() is that the final alpha value is incorrect. BlendFuncSeparate is the only one which can get you the correct alpha value at the end. So that leaves me thinking what we could do. I'm eager to here about your usage of GL_SRC_ALPHA before I can think of a solution. Regards -- Shree |
|
From: Stefan E. <eil...@gm...> - 2008-05-14 11:14:58
|
On 14. May 2008, at 12:26, Shree Kumar wrote: > Hi Stephen, > > On Tue, 2008-05-13 at 12:44 +0000, Stefan Eilemann wrote: > >> Regarding the performance: I've retested on my Mac. It seems the >> performance problem is still there: >> >> Eq, rev 1880: >> ./Darwin/test: DB first op: 41.4328 ms (1272.77 MB/s) >> ./Darwin/test: DB second op: 28.1947 ms (1870.36 MB/s) >> ./Darwin/test: DB 15 images: 92.7198 ms (2843.75 MB/s) >> >> >> PC, rev 63: >> ./Darwin/test: DB first op: 39.5884 ms (1332.07 MB/s) >> ./Darwin/test: DB second op: 26.9765 ms (1954.83 MB/s) >> ./Darwin/test: DB 15 images: 87.6801 ms (3007.2 MB/s) >> >> PC, rev 62: >> >> ./Darwin/test: DB first op: 45.064 ms (1170.21 MB/s) >> ./Darwin/test: DB second op: 32.2106 ms (1637.17 MB/s) >> ./Darwin/test: DB 15 images: 111.401 ms (2366.88 MB/s) >> > > PC rev 63 seems to be faster than Eq rev 1880. Am I > missing something ? No - I think it is due to the fact that Eq supports different sizes between the images, which makes the code a bit more complex. > > > Of course, I'm still puzzled about the perf difference between Eq and > rev 63 :-) I assume you meant rev 62?! Cheers, Stefan. -- http://www.eyescale.ch http://www.equalizergraphics.com http://www.linkedin.com/in/eilemann |
|
From: Maxim M. <mak...@if...> - 2008-05-14 14:19:04
|
> Thanks for the explanations. > >> Assuming that we have 1 background image (just "background" in the >> text bellow) and several images (which contains alpha values) we want >> to blend on to this background, there are two different strategies >> in eVolve to obtain the result: >> >> 1) Blend sequentially all images back to front on to background (this >> is our GPU based compositing at the moment); >> >> 2) Blend all images between each other and then blend resulted >> image on to background (this is our CPU compositing; we have >> background on GPU, so we blend images on CPU and then use GPU >> blending once to get final result on GPU). >> >> For the first strategy glBlendFunc(GL_ONE, GL_SRC_ALPHA) is used, >> and if final image is in main memory not on GPU, I guess, Paracomp >> compositing could be used without changes. > > I'm puzzled by the destination factor of GL_SRC_ALPHA. Are you guys > using alpha as an "opacity" value ? (As opposed to classical volume > rendering which uses alpha as transparency) > > Paracomp implements back to front blending with glBlendFunc(GL_ONE, > ONE_MINUS_SRC_ALPHA). I think of alpha as amount of light that goes through the volume (i.e. transparency), so it is (1-opacity), colors are pre-multiplied with opacity, when glBlendFuncSeparate( GL_ONE, GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA ) is used, it is actually calculates new transparency as (1-SrcOpacity)*(1-DstOpacity), when GL_SRC_ALPHA used to blend images on to background that means FinalColor = SrcColor + BG_Color*SrcAlpha where: SrcAlpha = (1-SrcOpacity) and SrcColor (as I wrote above) pre-multiplied with opacity i.e. SrcColor = SrcColorOrig*SrcOpacity, so finally we have: FinalColor = SrcColorOrig*SrcOpacity + BG_Color*(1-SrcOpacity); In the formula above we see SrcOpacity twice, well, actually this is not the same value because it accumulates in color and alpha channels separately and it is slightly different due to rounding errors, but the general idea should be correct =) Regards, Max |
|
From: Shree K. <shr...@hp...> - 2008-05-16 10:27:45
|
Hi Max, On Wed, 2008-05-14 at 14:18 +0000, Maxim Makhinya wrote: > I think of alpha as amount of light that goes through the volume > (i.e. transparency), so it is (1-opacity), colors are pre-multiplied > with opacity, when > glBlendFuncSeparate( GL_ONE, GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA ) > is used, it is actually calculates new transparency as > (1-SrcOpacity)*(1-DstOpacity), when GL_SRC_ALPHA used to blend images > on to background that means FinalColor = SrcColor + BG_Color*SrcAlpha > where: SrcAlpha = (1-SrcOpacity) and SrcColor (as I wrote above) > pre-multiplied with opacity i.e. SrcColor = SrcColorOrig*SrcOpacity, > so finally we have: > FinalColor = SrcColorOrig*SrcOpacity + BG_Color*(1-SrcOpacity); > > In the formula above we see SrcOpacity twice, well, actually this is > not the same value because it accumulates in color and alpha channels > separately and it is slightly different due to rounding errors, but > the general idea should be correct =) > Ok got it. So you need the equivalent of glBlendFuncSeparate( GL_ONE, GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA ) as the blending function for images. As I mentioned earlier, Paracomp does the equivalent of glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA). This, unfortunately, won't yield the results you need (in either of the scenarios you mentioned earlier). Right now, it is not possible to pass parameters to the compositor to change the way the pixels are combined. We have a COMPOSITE_ALPHA_SORT operation which combines the pixels in the way I mentioned. Ideally, we should have ways of setting the source and destination factors. This asks for another extension to the API... -- Shree |
Thanks for helping keep SourceForge clean.
X