Re: [Bf-committers] segfault trying to run recent svn builds on fedora
Yes, compilation of this morning works again ;-) Peter 2012/11/1 Bassam Kurdali bas...@urchn.org thanks campbell, all is well now :) On Thu, 2012-11-01 at 15:28 +1100, Campbell Barton wrote: My mistake, fixed r51801. On Thu, Nov 1, 2012 at 3:15 PM, Bassam Kurdali bas...@urchn.org wrote: trying to pin down a segfault building here on fedora 17, 64 bit, intel processor and nvidia gfx card. revision 51753 builds fine, and runs. revision 51754 does not build revision 51758 and later build, however, I get a segfault on launch: (gdb) bt #0 0x00d57fea in RNA_def_property_enum_items () #1 0x00d5b3c8 in RNA_def_enum () #2 0x009dc5df in MESH_OT_select_similar () #3 0x008eefdf in WM_operatortype_append () #4 0x009d0710 in ED_operatortypes_mesh () #5 0x009013df in ED_spacetypes_init () #6 0x008f4269 in WM_init () #7 0x008e7194 in main () running with debug-all/factory-startup makes no difference. the segfault occurs before any prints. running a debug build *does not crash!!!* however, I do get the following on quit: Error: Not freed memory blocks: 2 IDProperty group len: 128 0x86a3148 uiAfterFunc len: 272 0x86a0e28 Blender quit not sure what is going on here, hopes it makes sense to somebody. oh btw, I'm using scons to build, here is my user-config.py: WITH_BF_CYCLES_CUDA_BINARIES = True BF_CYCLES_CUDA_BINARIES_ARCH = ['sm_21'] WITH_BF_PLAYER = False WITH_BF_OCIO = True WITH_BF_STATICOCIO = False BF_OCIO = '/usr/lib64' BF_OCIO_INC = '/usr/include/OpenImageIO' #BF_OCIO_LIB = 'OpenColorIO yaml-cpp tinyxml' BF_OCIO_LIBPATH = '/usr/lib64' ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Steam Greenligth
I Hope I am at the right place to make this suggestion. Steam has now since some Time Opened up there Platform for people and Normal Software. So has anyone considered to Send Blender to Greenligth? http://steamcommunity.com/greenlight/ I think it would be a great Opportunity to distribute Blender over Steam. Sincerely Jeremias Boos ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Steam Greenligth
The conditions are 'horrible', at least nothing for me. 2012/11/1 Jeremias Boos jeremias.b...@gmx.de I Hope I am at the right place to make this suggestion. Steam has now since some Time Opened up there Platform for people and Normal Software. So has anyone considered to Send Blender to Greenligth? http://steamcommunity.com/greenlight/ I think it would be a great Opportunity to distribute Blender over Steam. Sincerely Jeremias Boos ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] texture painting blend mode patch
For the float version of the blend funtion SSE2 will certainly provide a 20 to 40% gain, and (depending on the compilator and the images used) you might want to avoid code like this: if(test) temp=big float calculation; else temp=other big float calc; which is not pipeline friendly, and prefer: temp1 = big float calculation; temp2 = other big float calc; temp = test ? temp1 : temp2; I'm sorry if this is off-topic for the mailing list, but I'm really curious as to how the second method can be faster, as it seems really unintuitive. Is this something to keep in mind for specific kinds of operations/ data types or just a good rule of thumb in general? Floating point number calculations takes a lot of processor cycles. To compensate, modern processor execute instructions in pipeline, starting an instruction every CPU cycle (before the previous instruction is finished). This does not work very well with conditional branching, specially the branching that cannot be predicted reliably because it trigger a pipeline flush with is very slow. It is absolutely not a good rule of thumb it depend greatly on your compiler, compiler options, processor, the input data (images). All modern processor uses this pipe-lining feature but sometimes the big float calculation can be more expensive than a pipeline flush anyway, or the same branch is almost always taken so branch prediction does its job well. The first thing to check would be that the compiler (in release/optimized builds) optimize this line: temp = test ? temp1 : temp2; And use some arithmetic trick instead of a conditional jump, a little assembly knowledge is required but you might also use a macro to force your own trick. I think the trick would look like this: test_bool = (test==0); temp = test_bool * temp1 + (1-test_bool) * temp2; This article explains it quite in details, except it is for PPC which uses the fsel instruction instead of an arithmetic trick: http://www.altdevblogaday.com/2011/11/10/optimisation_lessons/ You are right it is out of topic, sorry for that.I responded anyway because I think it is something that might interest peoples in this list. Xavier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] texture painting blend mode patch
seems like whatever i had crashing it before isn't an issue anymore so i rewrote those functions that used the hsv to rgb code to use the ones in math_color. From: Xavier Thomas xavier.thomas.1...@gmail.com To: Fredrik hansson fredrikhansson_12...@yahoo.com; bf-blender developers bf-committers@blender.org Sent: Thursday, November 1, 2012 9:09 PM Subject: Re: [Bf-committers] texture painting blend mode patch My optimization comment was not specific to your patch and apply to existing blending modes as well. The module maintainer will ultimately decide but it is (almost) always better to write code that works and optimize later using that code as reference and using profiling information with real life data than optimizing blindly. So my advise is to stick with a first non optimized patch first. The rgb-hsv funtions are still duplicated, resolving this seems clearly higher priority to me. 2012/11/1 Fredrik hansson fredrikhansson_12...@yahoo.com converted the code from 8bit - float didn't do any of that optimizing should perhaps do that but i preferred to just get it working quickly and without getting any additional errors. i did notice a few things however while testing out the code. mainly that it felt like it always were in air brush mode making some of the brushes way to strong unless you had a huge spacing (not overlapping). as for if the hsv_to_rgb crashes well it did when i originally wrote the patch but just looked at the code and i see no reason at all for it to actually crash as you said its just 2 simple static functions. From: Xavier Thomas xavier.thomas.1...@gmail.com To: Fredrik hansson fredrikhansson_12...@yahoo.com; bf-blender developers bf-committers@blender.org Sent: Wednesday, October 31, 2012 8:25 PM Subject: Re: [Bf-committers] texture painting blend mode patch I a looked at the patch and effectively the code for float images is missing. Another thing that might need investigating is the rgb_to_hsv and hsv_to_rgb method, basically duplicated code because the origiginal version crash with threading! I think it might be better to fix the original, it should be basic static methods, I do no see any reason to crash. Not related to this patch specifically but it seems there is quite a room for optimisation. If I understood well, for each pixel that is painted on, IMB_blend_color() is called, and this function is only a big switch(blend_mode) that then call the method that blend the 2 colors. One possibly better way to do this is to cache a pointer to the apropriate method each time the blend mode is changed so the huge switch statement is not done for every pixel. Another way maybe to inline the blend funtions so we do a function call less for each pixel. For the float version of the blend funtion SSE2 will certainly provide a 20 to 40% gain, and (depending on the compilator and the images used) you might want to avoid code like this: if(test) temp=big float calculation; else temp=other big float calc; which is not pipeline friendly, and prefer: temp1 = big float calculation; temp2 = other big float calc; temp = test ? temp1 : temp2; but this is not always the case so don't optimise blindly. Xavier 2012/10/31 Fredrik hansson fredrikhansson_12...@yahoo.com oh right i think that might have been why it wasn't added before or something i guess i could take a look at writing the float versions quickly should be the same pretty much. From: Antony Riakiotakis kal...@gmail.com To: Fredrik hansson fredrikhansson_12...@yahoo.com; bf-blender developers bf-committers@blender.org Sent: Wednesday, October 31, 2012 4:39 PM Subject: Re: [Bf-committers] texture painting blend mode patch This looks cool! A little remark though, we would also need float versions for the functions to support float images properly. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Segmentation fault when rendering in viewport
Hi everyone, On this particular blend file I'm working on, when I render in the viewport Blender will crash with a segmentation fault. This only happens with a particular file so I've linked it here: https://docs.google.com/open?id=0B60uSqRHFFciMTVNY2d4VVRwRmc. It's 56MB. This happens on r51814, to reproduce just open the blend and change to viewport render in the bottom window. Thanks, JamesNZ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
