Re: [Bf-committers] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous
The issue here is that basically slowdown depends on particular hardware configuration, tile settings and device used to render (GPU/CPU). Meaning, on modern CPU i've noticed around 20% slowdown peak, which is not that bad as 100%. So what i'm trying to say here, is that if we'll provide information up to 100% slower it might just scary artists and they wouldn't use the option at all, even though for their configuration slowdown wouldn't be so bad. What about more neutral (in my opinion): could lead to significant slowdown? On Thu, Nov 13, 2014 at 12:22 AM, Simon Repp simon@fdpl.foundation wrote: Dear Renderistas, I only recently found out that progressive refinement in Cycles rendering (which the corresponding checkbox's tooltip describes to be somewhat slower than bucket rendering) in fact can impose performance penalties of over 100% (aka the same amount of samples takes more than twice as long to render). Now I don't know if this is just a personal flawed interpretation of the english language on my part, but when reading somewhat slower I didn't realize what I was really in for, and in retrospect I'd rather not reconstruct how many days my poor laptop spent in excess to render some projects I did in the past. I'd hereby like to propose a change of this tooltip to something less ambiguous, lest anyone else falls into that same trap that I have - My proposal for this would be to include actual figures describing the possible speed penalty that progressive refinement can impose, that is, something along the lines of renders [a]% to [b]% slower depending on the scene, where figures [a] and [b] are ideally derived from real world data we gather (or already have?) about how much speed penalty progressive refinement can impose in different scenes. Alternatively, only stating up to [x]% slower would work as well I guess, as the main point is to make people aware that it _can_ possibly affect render times _significantly_. If the proposal to include figures is not agreeable for some reason, I would at least ask for a more indicative wording than somewhat slower, which even after consulting multiple dictionaries I'm not sure if there is an official interpretation for. (One dictionary suggests quite as a synoym, another slightly ...) I'd still prefer the figures though, no one looks up terms in the dictionary while using Blender and I am probably not the worst offender at massacring and misunderstanding the english language in the Blender community, and it doesn't get less ambiguous than numbers anyway, so I say we use them here? :) Best, Simon ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous
Just by the way, it's even more noticeable with GPU rendering - I've seen it roughly 300% slower often. could lead to significant slowdown sounds good to me. On 13 November 2014 11:06, Sergey Sharybin sergey@gmail.com wrote: The issue here is that basically slowdown depends on particular hardware configuration, tile settings and device used to render (GPU/CPU). Meaning, on modern CPU i've noticed around 20% slowdown peak, which is not that bad as 100%. So what i'm trying to say here, is that if we'll provide information up to 100% slower it might just scary artists and they wouldn't use the option at all, even though for their configuration slowdown wouldn't be so bad. What about more neutral (in my opinion): could lead to significant slowdown? On Thu, Nov 13, 2014 at 12:22 AM, Simon Repp simon@fdpl.foundation wrote: Dear Renderistas, I only recently found out that progressive refinement in Cycles rendering (which the corresponding checkbox's tooltip describes to be somewhat slower than bucket rendering) in fact can impose performance penalties of over 100% (aka the same amount of samples takes more than twice as long to render). Now I don't know if this is just a personal flawed interpretation of the english language on my part, but when reading somewhat slower I didn't realize what I was really in for, and in retrospect I'd rather not reconstruct how many days my poor laptop spent in excess to render some projects I did in the past. I'd hereby like to propose a change of this tooltip to something less ambiguous, lest anyone else falls into that same trap that I have - My proposal for this would be to include actual figures describing the possible speed penalty that progressive refinement can impose, that is, something along the lines of renders [a]% to [b]% slower depending on the scene, where figures [a] and [b] are ideally derived from real world data we gather (or already have?) about how much speed penalty progressive refinement can impose in different scenes. Alternatively, only stating up to [x]% slower would work as well I guess, as the main point is to make people aware that it _can_ possibly affect render times _significantly_. If the proposal to include figures is not agreeable for some reason, I would at least ask for a more indicative wording than somewhat slower, which even after consulting multiple dictionaries I'm not sure if there is an official interpretation for. (One dictionary suggests quite as a synoym, another slightly ...) I'd still prefer the figures though, no one looks up terms in the dictionary while using Blender and I am probably not the worst offender at massacring and misunderstanding the english language in the Blender community, and it doesn't get less ambiguous than numbers anyway, so I say we use them here? :) Best, Simon ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ 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] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous
If it is really 100% or 300% slower then that sounds like a fixable issue. I'm not sure why it would be this slow, it would be good to find out why, but one thing that would speed it up is to render more samples at a the time and redraw less often as the current sample increases. Due to the way Monte Carlo integration works, one sample barely makes any visible difference in noise after a while anyway. Maybe something like: num_samples_at_once = sqrt(max(current_sample - 4, 1)) On Nov 13, 2014 10:13 AM, Greg Zaal gregzzm...@gmail.com wrote: Just by the way, it's even more noticeable with GPU rendering - I've seen it roughly 300% slower often. could lead to significant slowdown sounds good to me. On 13 November 2014 11:06, Sergey Sharybin sergey@gmail.com wrote: The issue here is that basically slowdown depends on particular hardware configuration, tile settings and device used to render (GPU/CPU). Meaning, on modern CPU i've noticed around 20% slowdown peak, which is not that bad as 100%. So what i'm trying to say here, is that if we'll provide information up to 100% slower it might just scary artists and they wouldn't use the option at all, even though for their configuration slowdown wouldn't be so bad. What about more neutral (in my opinion): could lead to significant slowdown? On Thu, Nov 13, 2014 at 12:22 AM, Simon Repp simon@fdpl.foundation wrote: Dear Renderistas, I only recently found out that progressive refinement in Cycles rendering (which the corresponding checkbox's tooltip describes to be somewhat slower than bucket rendering) in fact can impose performance penalties of over 100% (aka the same amount of samples takes more than twice as long to render). Now I don't know if this is just a personal flawed interpretation of the english language on my part, but when reading somewhat slower I didn't realize what I was really in for, and in retrospect I'd rather not reconstruct how many days my poor laptop spent in excess to render some projects I did in the past. I'd hereby like to propose a change of this tooltip to something less ambiguous, lest anyone else falls into that same trap that I have - My proposal for this would be to include actual figures describing the possible speed penalty that progressive refinement can impose, that is, something along the lines of renders [a]% to [b]% slower depending on the scene, where figures [a] and [b] are ideally derived from real world data we gather (or already have?) about how much speed penalty progressive refinement can impose in different scenes. Alternatively, only stating up to [x]% slower would work as well I guess, as the main point is to make people aware that it _can_ possibly affect render times _significantly_. If the proposal to include figures is not agreeable for some reason, I would at least ask for a more indicative wording than somewhat slower, which even after consulting multiple dictionaries I'm not sure if there is an official interpretation for. (One dictionary suggests quite as a synoym, another slightly ...) I'd still prefer the figures though, no one looks up terms in the dictionary while using Blender and I am probably not the worst offender at massacring and misunderstanding the english language in the Blender community, and it doesn't get less ambiguous than numbers anyway, so I say we use them here? :) Best, Simon ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ 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
Re: [Bf-committers] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous
Brecht, it's multiple factors being involved here, starting from CPU cache coherence issues (which we can't easily predict) ending with less efficient buffers update (we might be saving all the passes after each of the samples in case of progressive refine, which we can fix). But yeah, should have asked for a demo file in the original file :) So do you guys have a demo .blend file which demonstrates such a major slowdown? Brecht, we can (and actually should) do several samples per tile, but i'd prefer log(). not sqrt() perhaps. Other idea to improve cache coherence would be to use left-to-right, bottom-to-top tile scheduling. That gives few %% of speedup, and AFAIR we don't fallback to such a scheduling in progressive refine. And even after the tweaks, we should probably replace somewhat to something more deterministic in the tooltip. On Thu, Nov 13, 2014 at 10:58 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: If it is really 100% or 300% slower then that sounds like a fixable issue. I'm not sure why it would be this slow, it would be good to find out why, but one thing that would speed it up is to render more samples at a the time and redraw less often as the current sample increases. Due to the way Monte Carlo integration works, one sample barely makes any visible difference in noise after a while anyway. Maybe something like: num_samples_at_once = sqrt(max(current_sample - 4, 1)) On Nov 13, 2014 10:13 AM, Greg Zaal gregzzm...@gmail.com wrote: Just by the way, it's even more noticeable with GPU rendering - I've seen it roughly 300% slower often. could lead to significant slowdown sounds good to me. On 13 November 2014 11:06, Sergey Sharybin sergey@gmail.com wrote: The issue here is that basically slowdown depends on particular hardware configuration, tile settings and device used to render (GPU/CPU). Meaning, on modern CPU i've noticed around 20% slowdown peak, which is not that bad as 100%. So what i'm trying to say here, is that if we'll provide information up to 100% slower it might just scary artists and they wouldn't use the option at all, even though for their configuration slowdown wouldn't be so bad. What about more neutral (in my opinion): could lead to significant slowdown? On Thu, Nov 13, 2014 at 12:22 AM, Simon Repp simon@fdpl.foundation wrote: Dear Renderistas, I only recently found out that progressive refinement in Cycles rendering (which the corresponding checkbox's tooltip describes to be somewhat slower than bucket rendering) in fact can impose performance penalties of over 100% (aka the same amount of samples takes more than twice as long to render). Now I don't know if this is just a personal flawed interpretation of the english language on my part, but when reading somewhat slower I didn't realize what I was really in for, and in retrospect I'd rather not reconstruct how many days my poor laptop spent in excess to render some projects I did in the past. I'd hereby like to propose a change of this tooltip to something less ambiguous, lest anyone else falls into that same trap that I have - My proposal for this would be to include actual figures describing the possible speed penalty that progressive refinement can impose, that is, something along the lines of renders [a]% to [b]% slower depending on the scene, where figures [a] and [b] are ideally derived from real world data we gather (or already have?) about how much speed penalty progressive refinement can impose in different scenes. Alternatively, only stating up to [x]% slower would work as well I guess, as the main point is to make people aware that it _can_ possibly affect render times _significantly_. If the proposal to include figures is not agreeable for some reason, I would at least ask for a more indicative wording than somewhat slower, which even after consulting multiple dictionaries I'm not sure if there is an official interpretation for. (One dictionary suggests quite as a synoym, another slightly ...) I'd still prefer the figures though, no one looks up terms in the dictionary while using Blender and I am probably not the worst offender at massacring and misunderstanding the english language in the Blender community, and it doesn't get less ambiguous than numbers anyway, so I say we use them here? :) Best, Simon ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org
Re: [Bf-committers] Multisample issue on Linux/X11/GLX
Hi Cédric, could you check if this patch resolves the problem? https://developer.blender.org/D894 On Wed, Nov 12, 2014 at 9:45 PM, Sergey Sharybin sergey@gmail.com wrote: Thanks a good catch! And actually, seems Campbell saw this email before me and was trying to fix it. On Wed, Nov 12, 2014 at 6:06 PM, Cédric PAILLE cedricpai...@gmail.com wrote: Found ! In GHOST_WindowX11.cpp, XCreateWindow(...) didn''t get the good XVisual (I've made one with glXChooseVisual(...), like in GHOST_ContextGLX.cpp) and it works. 2014-11-12 17:16 GMT+01:00 Cédric PAILLE cedricpai...@gmail.com: Hi, I've no message in the terminal about multisample, but after some researches, it seems that it's broken since GHOST has been re-factored recently. I've an old version of Blender (2.69) that works correctly. I'm trying to fix it, but it doesn't seem obvious... Cheers 2014-11-12 16:14 GMT+01:00 Sergey Sharybin sergey@gmail.com: This is a video driver feature, which might be disabled by nvidia on some platforms (assuming you're using nvidia driver). Also, are there any messages regarding multisample in the console? P.S. There was a demo application in qt, which might be the fastest way to figure out if the issue is in blender itself or in video driver/X11/etc. On Wed, Nov 12, 2014 at 12:02 PM, Cédric PAILLE cedricpai...@gmail.com wrote: Hi, I've spent a long time trying to resolve a problem with the 3D viewport's multisample. I just can't get it to work on a CentOS 6.5 from sources (It's working if I download the binaries from the Blender's website). I've tried compiling with the latest GLEW library, with the internal GLEW, with GHOST_SDL compilation flag, and it's always the same, multisample just doesn't work. If I ask openGL for samples (using *glGetIntegerv* (GL_SAMPLES, samples) ) it always returns 0. Does anyone have an idea on how to debug this problem ? System : CentOS 6.5, Nvidia Quadro K2000 with latest drivers. -- Cédric PAILLE. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Cédric PAILLE. -- Cédric PAILLE. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Propose to reduce default feature set (*nix dev builds)
This is mainly for Linux/BSD developers (releases remain unchanged). Its getting increasingly difficult to build Blender on Linux, (LLVM, ffmpeg, OpenCollada...) these issue's can't always be fixed on our side. With newer developers a failed build with a cryptic error message (guys in #blendercoders can't even help with), is quite off putting.. Proposing a limited feature-set by default with CMake (again official builds from blender.org are unchanged) https://developer.blender.org/T42569 -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multisample issue on Linux/X11/GLX
Hi Barton, It works perfectly ! Thank you 2014-11-13 12:06 GMT+01:00 Campbell Barton ideasma...@gmail.com: Hi Cédric, could you check if this patch resolves the problem? https://developer.blender.org/D894 On Wed, Nov 12, 2014 at 9:45 PM, Sergey Sharybin sergey@gmail.com wrote: Thanks a good catch! And actually, seems Campbell saw this email before me and was trying to fix it. On Wed, Nov 12, 2014 at 6:06 PM, Cédric PAILLE cedricpai...@gmail.com wrote: Found ! In GHOST_WindowX11.cpp, XCreateWindow(...) didn''t get the good XVisual (I've made one with glXChooseVisual(...), like in GHOST_ContextGLX.cpp) and it works. 2014-11-12 17:16 GMT+01:00 Cédric PAILLE cedricpai...@gmail.com: Hi, I've no message in the terminal about multisample, but after some researches, it seems that it's broken since GHOST has been re-factored recently. I've an old version of Blender (2.69) that works correctly. I'm trying to fix it, but it doesn't seem obvious... Cheers 2014-11-12 16:14 GMT+01:00 Sergey Sharybin sergey@gmail.com: This is a video driver feature, which might be disabled by nvidia on some platforms (assuming you're using nvidia driver). Also, are there any messages regarding multisample in the console? P.S. There was a demo application in qt, which might be the fastest way to figure out if the issue is in blender itself or in video driver/X11/etc. On Wed, Nov 12, 2014 at 12:02 PM, Cédric PAILLE cedricpai...@gmail.com wrote: Hi, I've spent a long time trying to resolve a problem with the 3D viewport's multisample. I just can't get it to work on a CentOS 6.5 from sources (It's working if I download the binaries from the Blender's website). I've tried compiling with the latest GLEW library, with the internal GLEW, with GHOST_SDL compilation flag, and it's always the same, multisample just doesn't work. If I ask openGL for samples (using *glGetIntegerv* (GL_SAMPLES, samples) ) it always returns 0. Does anyone have an idea on how to debug this problem ? System : CentOS 6.5, Nvidia Quadro K2000 with latest drivers. -- Cédric PAILLE. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Cédric PAILLE. -- Cédric PAILLE. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Cédric PAILLE. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multisample issue on Linux/X11/GLX
Oh, just add : #include X11/Xutil.h in GHOST_WindowX11.h to avoid a compilation crash and it's OK. Cheers. 2014-11-13 13:50 GMT+01:00 Cédric PAILLE cedricpai...@gmail.com: Hi Barton, It works perfectly ! Thank you 2014-11-13 12:06 GMT+01:00 Campbell Barton ideasma...@gmail.com: Hi Cédric, could you check if this patch resolves the problem? https://developer.blender.org/D894 On Wed, Nov 12, 2014 at 9:45 PM, Sergey Sharybin sergey@gmail.com wrote: Thanks a good catch! And actually, seems Campbell saw this email before me and was trying to fix it. On Wed, Nov 12, 2014 at 6:06 PM, Cédric PAILLE cedricpai...@gmail.com wrote: Found ! In GHOST_WindowX11.cpp, XCreateWindow(...) didn''t get the good XVisual (I've made one with glXChooseVisual(...), like in GHOST_ContextGLX.cpp) and it works. 2014-11-12 17:16 GMT+01:00 Cédric PAILLE cedricpai...@gmail.com: Hi, I've no message in the terminal about multisample, but after some researches, it seems that it's broken since GHOST has been re-factored recently. I've an old version of Blender (2.69) that works correctly. I'm trying to fix it, but it doesn't seem obvious... Cheers 2014-11-12 16:14 GMT+01:00 Sergey Sharybin sergey@gmail.com: This is a video driver feature, which might be disabled by nvidia on some platforms (assuming you're using nvidia driver). Also, are there any messages regarding multisample in the console? P.S. There was a demo application in qt, which might be the fastest way to figure out if the issue is in blender itself or in video driver/X11/etc. On Wed, Nov 12, 2014 at 12:02 PM, Cédric PAILLE cedricpai...@gmail.com wrote: Hi, I've spent a long time trying to resolve a problem with the 3D viewport's multisample. I just can't get it to work on a CentOS 6.5 from sources (It's working if I download the binaries from the Blender's website). I've tried compiling with the latest GLEW library, with the internal GLEW, with GHOST_SDL compilation flag, and it's always the same, multisample just doesn't work. If I ask openGL for samples (using *glGetIntegerv* (GL_SAMPLES, samples) ) it always returns 0. Does anyone have an idea on how to debug this problem ? System : CentOS 6.5, Nvidia Quadro K2000 with latest drivers. -- Cédric PAILLE. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Cédric PAILLE. -- Cédric PAILLE. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Cédric PAILLE. -- Cédric PAILLE. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
On 13/11/14 11:31, Campbell Barton wrote: This is mainly for Linux/BSD developers (releases remain unchanged). Its getting increasingly difficult to build Blender on Linux, (LLVM, ffmpeg, OpenCollada...) these issue's can't always be fixed on our side. With newer developers a failed build with a cryptic error message (guys in #blendercoders can't even help with), is quite off putting.. Proposing a limited feature-set by default with CMake (again official builds from blender.org are unchanged) https://developer.blender.org/T42569 Hi, This is a bad idea, the whole point on dev builds is for us to spot problems, if you start turning off features just so things can compile that is sweeping issues under the carpet. If it's getting hard to build that means you need to work on build instructions/build system. And if its an upstream issue, communication needs to go upstream. Being demotivated if not a reason to start turning off fundamental features. After all ffmpeg and opencollada would not really be seen as option features (by a lot of people), and the same can be said of llvm, and they certainly are not optional when we need to spot bug/issues. I mean what is next stop supporting Linux because its harder to build. Well you could just as easily make that argument for the entire windows build system. It's more often than not the one with problems, so we should obviously throw it in the canal yes? Obviously that would not be done. *marches off all huffy like* Terry Wallwork ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] SDL library upgrade
Hi, This is actually coming from a conversation with Martijn about switching to SDL-2.0 on Windows, but we need to make everyone informed. So basically the need of upgrade on Windows is caused by some issues happening with SDL-1.2 (which is currently used for all platforms) on Windows 8. So switching to SDL-2.0 would make more windows users happy with blender. But we need to keep libraries in sync for the release, which means OSX and Linux maintainers would need to do modifications to the release environment and libraries. It shouldn't be hard, because SDL-2.0 was out for quite some time now and Blender itself is totally ready for it. So the proposal would be: - Martijn takes care of SDL-2.0 on Windows. If needed Sergey helps him. - Jens would need to take care of OSX - Sergey takes care of Linux builds, for this we'll need to finish the SDL wrangler patch (which makes SDL libraries load on runtime and if library is not found Blender still works, just doesn't allow to use SDL for sound and joystick). What does it mean for artists? Well, for OSX and Windows they wouldnt' see any difference (apart from some some solved issues). Neither those who runs existing builds, nor those who compiles blender themselves. For Linux users it'll mean in order to use SDL (sound and joystick) SDL2 is to be installed. If this library is not installed, blender WILL run, just wouldn't let use SDL functionality. This doesn't seem difficult to install if needed, even for current Debian stable (which tends to be quite old) there's an official backport for SDL2. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
The thing is, it's just a proposal to change default behavior, which would be something inbetween of current feature-full make and `make light` (which already exists and cuts everything possible). For experienced developers it doesn't matter to use `make release` instead of `make` (they're wrapping all this steps into a script most of the time anyway). For new developers just be able to type `make` and have working blender without need to struggle with weirdo dependencies is what's this proposal is about. On Thu, Nov 13, 2014 at 2:05 PM, AIBlender aiblen...@gmail.com wrote: On 13/11/14 11:31, Campbell Barton wrote: This is mainly for Linux/BSD developers (releases remain unchanged). Its getting increasingly difficult to build Blender on Linux, (LLVM, ffmpeg, OpenCollada...) these issue's can't always be fixed on our side. With newer developers a failed build with a cryptic error message (guys in #blendercoders can't even help with), is quite off putting.. Proposing a limited feature-set by default with CMake (again official builds from blender.org are unchanged) https://developer.blender.org/T42569 Hi, This is a bad idea, the whole point on dev builds is for us to spot problems, if you start turning off features just so things can compile that is sweeping issues under the carpet. If it's getting hard to build that means you need to work on build instructions/build system. And if its an upstream issue, communication needs to go upstream. Being demotivated if not a reason to start turning off fundamental features. After all ffmpeg and opencollada would not really be seen as option features (by a lot of people), and the same can be said of llvm, and they certainly are not optional when we need to spot bug/issues. I mean what is next stop supporting Linux because its harder to build. Well you could just as easily make that argument for the entire windows build system. It's more often than not the one with problems, so we should obviously throw it in the canal yes? Obviously that would not be done. *marches off all huffy like* Terry Wallwork ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] SDL library upgrade
Hi, In general I do not think we should be to dogmatic in terms of library versions across platforms. Run-time loading is however a cool solution and I guess it fits really well for SDL. Blender has been ready for this for some time thanks to Campbell but I am unsure if we are actively using the improvements SDL2 brings like joystick hot-plugging etc. Quick questions: What is the state of the wrangler ? Other then that it seems a very doable and worthwhile goal (for the next release ?) Martijn On Thu, Nov 13, 2014 at 2:24 PM, Sergey Sharybin sergey@gmail.com wrote: Hi, This is actually coming from a conversation with Martijn about switching to SDL-2.0 on Windows, but we need to make everyone informed. So basically the need of upgrade on Windows is caused by some issues happening with SDL-1.2 (which is currently used for all platforms) on Windows 8. So switching to SDL-2.0 would make more windows users happy with blender. But we need to keep libraries in sync for the release, which means OSX and Linux maintainers would need to do modifications to the release environment and libraries. It shouldn't be hard, because SDL-2.0 was out for quite some time now and Blender itself is totally ready for it. So the proposal would be: - Martijn takes care of SDL-2.0 on Windows. If needed Sergey helps him. - Jens would need to take care of OSX - Sergey takes care of Linux builds, for this we'll need to finish the SDL wrangler patch (which makes SDL libraries load on runtime and if library is not found Blender still works, just doesn't allow to use SDL for sound and joystick). What does it mean for artists? Well, for OSX and Windows they wouldnt' see any difference (apart from some some solved issues). Neither those who runs existing builds, nor those who compiles blender themselves. For Linux users it'll mean in order to use SDL (sound and joystick) SDL2 is to be installed. If this library is not installed, blender WILL run, just wouldn't let use SDL functionality. This doesn't seem difficult to install if needed, even for current Debian stable (which tends to be quite old) there's an official backport for SDL2. -- With best regards, Sergey Sharybin ___ 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] Propose to reduce default feature set (*nix dev builds)
Hi, @Terry, I would like to point out that most developers I know already build with a very very reduced feature set anyway. Blender in general is ridiculously difficult to build if only as a result of its large number of dependencies and things like boost/C++ ABI stuff adding to that. I think OpenEXR and Ilmbase libs should maybe not be disabled by default as it is the highest fidelity output format and not *that* bad compared with the rest of the list. I would disable by default: - WITH_OPENCOLLADA - WITH_OPENCOLORIO - WITH_CYCLES_OSL - WITH_CODEC_FFMPEG - WITH_SDL - WITH_NDOF - WITH_BUILDINFO - WITH_GAMEENGINE - WITH_JACK - WITH_IMAGE_REDCODE - WITH_IMAGE_PSD Maybe it would be good to also have the opposite WITH_FULL_RELEASE_BUILD that just enables all this and is not cached ? Martijn On Thu, Nov 13, 2014 at 2:05 PM, AIBlender aiblen...@gmail.com wrote: On 13/11/14 11:31, Campbell Barton wrote: This is mainly for Linux/BSD developers (releases remain unchanged). Its getting increasingly difficult to build Blender on Linux, (LLVM, ffmpeg, OpenCollada...) these issue's can't always be fixed on our side. With newer developers a failed build with a cryptic error message (guys in #blendercoders can't even help with), is quite off putting.. Proposing a limited feature-set by default with CMake (again official builds from blender.org are unchanged) https://developer.blender.org/T42569 Hi, This is a bad idea, the whole point on dev builds is for us to spot problems, if you start turning off features just so things can compile that is sweeping issues under the carpet. If it's getting hard to build that means you need to work on build instructions/build system. And if its an upstream issue, communication needs to go upstream. Being demotivated if not a reason to start turning off fundamental features. After all ffmpeg and opencollada would not really be seen as option features (by a lot of people), and the same can be said of llvm, and they certainly are not optional when we need to spot bug/issues. I mean what is next stop supporting Linux because its harder to build. Well you could just as easily make that argument for the entire windows build system. It's more often than not the one with problems, so we should obviously throw it in the canal yes? Obviously that would not be done. *marches off all huffy like* Terry Wallwork ___ 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] SDL library upgrade
I would hate making SDL2 a mandatory package to be installed before you can even start blender. That'd be just undiscussable stupid. Can even add period here. The status of the wrangler is so-called works for me (tm), the patch is under review now https://developer.blender.org/D878 Hereby, linux department reports ready to go SDL-2.0 ;) On Thu, Nov 13, 2014 at 2:39 PM, Martijn Berger martijn.ber...@gmail.com wrote: Hi, In general I do not think we should be to dogmatic in terms of library versions across platforms. Run-time loading is however a cool solution and I guess it fits really well for SDL. Blender has been ready for this for some time thanks to Campbell but I am unsure if we are actively using the improvements SDL2 brings like joystick hot-plugging etc. Quick questions: What is the state of the wrangler ? Other then that it seems a very doable and worthwhile goal (for the next release ?) Martijn On Thu, Nov 13, 2014 at 2:24 PM, Sergey Sharybin sergey@gmail.com wrote: Hi, This is actually coming from a conversation with Martijn about switching to SDL-2.0 on Windows, but we need to make everyone informed. So basically the need of upgrade on Windows is caused by some issues happening with SDL-1.2 (which is currently used for all platforms) on Windows 8. So switching to SDL-2.0 would make more windows users happy with blender. But we need to keep libraries in sync for the release, which means OSX and Linux maintainers would need to do modifications to the release environment and libraries. It shouldn't be hard, because SDL-2.0 was out for quite some time now and Blender itself is totally ready for it. So the proposal would be: - Martijn takes care of SDL-2.0 on Windows. If needed Sergey helps him. - Jens would need to take care of OSX - Sergey takes care of Linux builds, for this we'll need to finish the SDL wrangler patch (which makes SDL libraries load on runtime and if library is not found Blender still works, just doesn't allow to use SDL for sound and joystick). What does it mean for artists? Well, for OSX and Windows they wouldnt' see any difference (apart from some some solved issues). Neither those who runs existing builds, nor those who compiles blender themselves. For Linux users it'll mean in order to use SDL (sound and joystick) SDL2 is to be installed. If this library is not installed, blender WILL run, just wouldn't let use SDL functionality. This doesn't seem difficult to install if needed, even for current Debian stable (which tends to be quite old) there's an official backport for SDL2. -- With best regards, Sergey Sharybin ___ 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 -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
I think I agree with Martijn except for making WITH_CODEC_FFMPEG default in the list to enable. Without WITH_CODEC_FFMPEG, only AVI jpeg and AVI (and frameserver format (what is that?)) export options are available which result in relatively huge file sizes. Aside WITH_CODEC_FFMPEG i think the rest can be disabled by default On Thursday, November 13, 2014, Martijn Berger martijn.ber...@gmail.com wrote: Hi, @Terry, I would like to point out that most developers I know already build with a very very reduced feature set anyway. Blender in general is ridiculously difficult to build if only as a result of its large number of dependencies and things like boost/C++ ABI stuff adding to that. I think OpenEXR and Ilmbase libs should maybe not be disabled by default as it is the highest fidelity output format and not *that* bad compared with the rest of the list. I would disable by default: - WITH_OPENCOLLADA - WITH_OPENCOLORIO - WITH_CYCLES_OSL - WITH_CODEC_FFMPEG - WITH_SDL - WITH_NDOF - WITH_BUILDINFO - WITH_GAMEENGINE - WITH_JACK - WITH_IMAGE_REDCODE - WITH_IMAGE_PSD Maybe it would be good to also have the opposite WITH_FULL_RELEASE_BUILD that just enables all this and is not cached ? Martijn On Thu, Nov 13, 2014 at 2:05 PM, AIBlender aiblen...@gmail.com javascript:; wrote: On 13/11/14 11:31, Campbell Barton wrote: This is mainly for Linux/BSD developers (releases remain unchanged). Its getting increasingly difficult to build Blender on Linux, (LLVM, ffmpeg, OpenCollada...) these issue's can't always be fixed on our side. With newer developers a failed build with a cryptic error message (guys in #blendercoders can't even help with), is quite off putting.. Proposing a limited feature-set by default with CMake (again official builds from blender.org are unchanged) https://developer.blender.org/T42569 Hi, This is a bad idea, the whole point on dev builds is for us to spot problems, if you start turning off features just so things can compile that is sweeping issues under the carpet. If it's getting hard to build that means you need to work on build instructions/build system. And if its an upstream issue, communication needs to go upstream. Being demotivated if not a reason to start turning off fundamental features. After all ffmpeg and opencollada would not really be seen as option features (by a lot of people), and the same can be said of llvm, and they certainly are not optional when we need to spot bug/issues. I mean what is next stop supporting Linux because its harder to build. Well you could just as easily make that argument for the entire windows build system. It's more often than not the one with problems, so we should obviously throw it in the canal yes? Obviously that would not be done. *marches off all huffy like* Terry Wallwork ___ Bf-committers mailing list Bf-committers@blender.org javascript:; http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org javascript:; http://lists.blender.org/mailman/listinfo/bf-committers -- +Rexford http://google.com/+Nkansahrexford | Africa Center http://africacenter.net | WiR https://outreach.wikimedia.org/wiki/Wikipedian_in_Residence | WikiAfrica http://wikiafrica.net | User:Nkansahrexford http://en.wikipedia.org/wiki/User:Nkansahrexford ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
On 13/11/14 13:39, Sergey Sharybin wrote: The thing is, it's just a proposal to change default behavior, which would be something inbetween of current feature-full make and `make light` (which already exists and cuts everything possible). For experienced developers it doesn't matter to use `make release` instead of `make` (they're wrapping all this steps into a script most of the time anyway). For new developers just be able to type `make` and have working blender without need to struggle with weirdo dependencies is what's this proposal is about. On Thu, Nov 13, 2014 at 2:05 PM, AIBlender aiblen...@gmail.com wrote: On 13/11/14 11:31, Campbell Barton wrote: This is mainly for Linux/BSD developers (releases remain unchanged). Its getting increasingly difficult to build Blender on Linux, (LLVM, ffmpeg, OpenCollada...) these issue's can't always be fixed on our side. With newer developers a failed build with a cryptic error message (guys in #blendercoders can't even help with), is quite off putting.. Proposing a limited feature-set by default with CMake (again official builds from blender.org are unchanged) https://developer.blender.org/T42569 Hi, This is a bad idea, the whole point on dev builds is for us to spot problems, if you start turning off features just so things can compile that is sweeping issues under the carpet. If it's getting hard to build that means you need to work on build instructions/build system. And if its an upstream issue, communication needs to go upstream. Being demotivated if not a reason to start turning off fundamental features. After all ffmpeg and opencollada would not really be seen as option features (by a lot of people), and the same can be said of llvm, and they certainly are not optional when we need to spot bug/issues. I mean what is next stop supporting Linux because its harder to build. Well you could just as easily make that argument for the entire windows build system. It's more often than not the one with problems, so we should obviously throw it in the canal yes? Obviously that would not be done. *marches off all huffy like* Terry Wallwork ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers I understand the reasoning behind it Sergey, but if new people want to build Blender they should get something which is approaching a feature complete build, otherwise what is the point of using a Dev build. The other reason this worries me is that assume you do make a simplified options build, and then a new user decides they need OSL/BLENDERPLAYER/FFMPEG/OCIO/LLVM (all of which are not unreasonable features to wants (especially ffmpeg and OSL), so what do they do, they turn the options back on. Then they notice there is an error in compiling, but this error could have gone unnoticed for a longer time because by default the option that would shown these errors are disabled. At this point they aren't just going to go oh well that options broken I will turn it off (and nor should they, it should reported and fixed). No, what they are going to do and what I will definitely do is complain to you Devs to fix it. We already have issues with entire features and options vanishing from Blender because someone made a code change and forget some important piece of UI code or missed a tab in python or whatever. Yes the Blender Devs are quick to fix these issues because they get noticed (usually quickly). I would not bet a lot of money on this being the case with feature that is disabled by default. So in summary if you the turn the options off, the people who use the features will turn them back on and when they break they will just ask you to fix them. At this point you are back where you started. With the added disadvantage that now the error could be harder to fix. Don't give Blender a lobotomy, it has the features it has for reason, working major features are important especially for dev builds. Terry Wallwork Terry Wallwork ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
On Thu, Nov 13, 2014 at 2:05 PM, AIBlender aiblen...@gmail.com wrote: On 13/11/14 11:31, Campbell Barton wrote: This is mainly for Linux/BSD developers (releases remain unchanged). Its getting increasingly difficult to build Blender on Linux, (LLVM, ffmpeg, OpenCollada...) these issue's can't always be fixed on our side. With newer developers a failed build with a cryptic error message (guys in #blendercoders can't even help with), is quite off putting.. Proposing a limited feature-set by default with CMake (again official builds from blender.org are unchanged) https://developer.blender.org/T42569 Hi, This is a bad idea, the whole point on dev builds is for us to spot problems, it can also be for developers to start working on Blender. if you start turning off features just so things can compile that is sweeping issues under the carpet. Buildbot's will continue to run with a complete feature set. If it's getting hard to build that means you need to work on build instructions/build system. And if its an upstream issue, communication needs to go upstream. Being demotivated if not a reason to start turning off fundamental features. You assume this is some laziness and if we wanted we could spend time to resolve issues like this. We regularly get new devs in IRC who pastebin strange errors we never saw before and its unlikely we can help them resolve. After all ffmpeg and opencollada would not really be seen as option features (by a lot of people), and the same can be said of llvm, and they certainly are not optional when we need to spot bug/issues. This is just defaults, so builds are more likely to work out-of-the box. if you know what OSL/FFMPEG/FFTW/LLVM... etc mean and need them, you can of course enable them. I mean what is next stop supporting Linux because its harder to build. Well you could just as easily make that argument for the entire windows build system. Windows uses pre-compiled libs, While we do have problems reported its not normally related to using some unknown library version. It's more often than not the one with problems, so we should obviously throw it in the canal yes? Obviously that would not be done. *marches off all huffy like* Terry Wallwork ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
Addressing this: I understand the reasoning behind it Sergey, but if new people want to build Blender they should get something which is approaching a feature complete build, otherwise what is the point of using a Dev build. Why would motion tracker developer want to deal with LLVM? Why new modifier guy would want to deal with Boost? Why compositor or dependency graph guys need to worry about any of external dependencies? This could be continued.. For sure at some point developer would need to be able to compile feature-complete blender, but forcing him to solve all the dependencies from the very beginning is really scary for new developers. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
As one of the non-core developers, I'd just like to lend a supportive note to this idea. Who knows how many potential developers have been turned away because they failed at the very first step and either didn't know where to turn for help, or couldn't be bothered because of the initial sour taste of not being able to build. I started with the Windows development environment for Blender, and it all went smoothly. I now use Linux (and some MacOS) for development. The first time getting it to build on Linux was quite hard. Subsequent times have also sometimes been difficult, and it is only because I was more experienced in Blender development that I could tell what module had the problem and knew that there was an easy way to make progress - turn that module off, and if I really need that module, come back to figuring out the problem later. As Campbell and Sergey said, my subsequent experience as a developer is that a particular developer only needs a small part of Blender to work, and there is not much point including the rest of the modules while working. The only problems that are likely to show up would be caught by what should be a strong recommendation to 'make release' before committing code to the repository. - Howard On Thu, Nov 13, 2014 at 6:32 AM, Sergey Sharybin sergey@gmail.com wrote: Addressing this: I understand the reasoning behind it Sergey, but if new people want to build Blender they should get something which is approaching a feature complete build, otherwise what is the point of using a Dev build. Why would motion tracker developer want to deal with LLVM? Why new modifier guy would want to deal with Boost? Why compositor or dependency graph guys need to worry about any of external dependencies? This could be continued.. For sure at some point developer would need to be able to compile feature-complete blender, but forcing him to solve all the dependencies from the very beginning is really scary for new developers. -- With best regards, Sergey Sharybin ___ 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] Propose to reduce default feature set (*nix dev builds)
On 13/11/14 14:24, Campbell Barton wrote: On Thu, Nov 13, 2014 at 2:05 PM, AIBlender aiblen...@gmail.com wrote: On 13/11/14 11:31, Campbell Barton wrote: This is mainly for Linux/BSD developers (releases remain unchanged). Its getting increasingly difficult to build Blender on Linux, (LLVM, ffmpeg, OpenCollada...) these issue's can't always be fixed on our side. With newer developers a failed build with a cryptic error message (guys in #blendercoders can't even help with), is quite off putting.. Proposing a limited feature-set by default with CMake (again official builds from blender.org are unchanged) https://developer.blender.org/T42569 Hi, This is a bad idea, the whole point on dev builds is for us to spot problems, it can also be for developers to start working on Blender. if you start turning off features just so things can compile that is sweeping issues under the carpet. Buildbot's will continue to run with a complete feature set. If it's getting hard to build that means you need to work on build instructions/build system. And if its an upstream issue, communication needs to go upstream. Being demotivated if not a reason to start turning off fundamental features. You assume this is some laziness and if we wanted we could spend time to resolve issues like this. We regularly get new devs in IRC who pastebin strange errors we never saw before and its unlikely we can help them resolve. After all ffmpeg and opencollada would not really be seen as option features (by a lot of people), and the same can be said of llvm, and they certainly are not optional when we need to spot bug/issues. This is just defaults, so builds are more likely to work out-of-the box. if you know what OSL/FFMPEG/FFTW/LLVM... etc mean and need them, you can of course enable them. I mean what is next stop supporting Linux because its harder to build. Well you could just as easily make that argument for the entire windows build system. Windows uses pre-compiled libs, While we do have problems reported its not normally related to using some unknown library version. It's more often than not the one with problems, so we should obviously throw it in the canal yes? Obviously that would not be done. *marches off all huffy like* Terry Wallwork ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers Hi Campbell, it can also be for developers to start working on Blender. Devs who work with Blender should be able to build the complete Blender if they can't it's not a good sign. Buildbot's will continue to run with a complete feature set. Normal users care about Buildbot, people who build from source don't give a damn about buildbot. I want builds from git source. Which means its need to work with all features, I can't test if you lot decide to disable them and then complain when we turn them back on and can't get them to work because you don't understand how to fix an error. You assume this is some laziness and if we wanted we could spend time to resolve issues like this. We regularly get new devs in IRC who pastebin strange errors we never saw before and its unlikely we can help them resolve. I don't assume laziness I assume that they are important features which need to be enabled and working for us to do our job of keeping Blender features working and being able to tell you devs a feature causes a seg fault or whatever other issues arise. This is just defaults, so builds are more likely to work out-of-the box. if you know what OSL/FFMPEG/FFTW/LLVM... etc mean and need them, you can of course enable them. Why turn off fudamental features, if you don't need them a Dev can turn them off. It does not sit right that someone who is potentially going to be a developer for Blender needs to start disabling features to get their compiles to work. In the end devs are going to have to get their code to work with fully activated versions of Blender. OSL shouldn't even be optional for example and would never be optional in a release build and I assume this means LLVM would not be either. Windows uses pre-compiled libs, While we do have problems reported its not normally related to using some unknown library version. Can't comment on this one I don't use windows. I do know Linux can have many different versions of libraries installed, so maybe make install deps install specific local version on Linux. In the end all features have to work for release, so it should have to work with Dev builds, otherwise why have Dev builds at all. As Devs with the understanding and the bigger brains , you are stuck with fixing problems with compile/build systems because, we normal types can't do it. But if you value normal people being able to report bugs quickly to you about Blender features, then we need Blender to compile with all important features enabled
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
I don't see the problem here. As outlined, a full version can still be build easily and as the buildbot continues to build the full feature set, there is no risk that things fall apart. If there is a bug in, let's say OSL building, the buildbot will fail and we will notice it. It should not matter if you have to type in make or make-light or make-full or whatever. Of course the default behavior (make) should be documented well in the wiki, so people see what to expect. Apart from that, this is really not a big deal. Am 13.11.2014 um 16:03 schrieb AIBlender: Normal users care about Buildbot, people who build from source don't give a damn about buildbot. I want builds from git source. Which means its need to work with all features, I can't test if you lot decide to disable them and then complain when we turn them back on and can't get them to work because you don't understand how to fix an error. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
On 13/11/14 14:32, Sergey Sharybin wrote: Addressing this: I understand the reasoning behind it Sergey, but if new people want to build Blender they should get something which is approaching a feature complete build, otherwise what is the point of using a Dev build. Why would motion tracker developer want to deal with LLVM? Why new modifier guy would want to deal with Boost? Why compositor or dependency graph guys need to worry about any of external dependencies? This could be continued.. For sure at some point developer would need to be able to compile feature-complete blender, but forcing him to solve all the dependencies from the very beginning is really scary for new developers. If for every new dev you started turning off features because they get confused you end up with a very limited version of Blender. Any dev working on advanced features should be able to compile full versions of Blender, and that Ideally should be because a seasoned Dev has made Blender work with all feature enabled out of the box. Errors when features are turned back on are going to get reported and need fixing anyways, so may as well keep it working from the very beginning with all features on. Anyways my point is clear on this, sorry if it come across as aggressive but, turning off features is just hiding problems, and for people like me it will just mean I turn the features back on a complain a lot more forcefully if I get errors that run out of control because some feature was disabled because of some scared dev. Terry Wallwork ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
+1 to the proposed idea on top of that it would be nice to have a 'make release' or similar option to mimic the settings used in the release build. It's worthy noting that the current CMake default settings are already different than the release options (e.g., BlenderPlayer is not built by default). The idea presented here only brings this a step further. Regards, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-11-13 13:14 GMT-02:00 AIBlender aiblen...@gmail.com: On 13/11/14 14:32, Sergey Sharybin wrote: Addressing this: I understand the reasoning behind it Sergey, but if new people want to build Blender they should get something which is approaching a feature complete build, otherwise what is the point of using a Dev build. Why would motion tracker developer want to deal with LLVM? Why new modifier guy would want to deal with Boost? Why compositor or dependency graph guys need to worry about any of external dependencies? This could be continued.. For sure at some point developer would need to be able to compile feature-complete blender, but forcing him to solve all the dependencies from the very beginning is really scary for new developers. If for every new dev you started turning off features because they get confused you end up with a very limited version of Blender. Any dev working on advanced features should be able to compile full versions of Blender, and that Ideally should be because a seasoned Dev has made Blender work with all feature enabled out of the box. Errors when features are turned back on are going to get reported and need fixing anyways, so may as well keep it working from the very beginning with all features on. Anyways my point is clear on this, sorry if it come across as aggressive but, turning off features is just hiding problems, and for people like me it will just mean I turn the features back on a complain a lot more forcefully if I get errors that run out of control because some feature was disabled because of some scared dev. Terry Wallwork ___ 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] Propose to reduce default feature set (*nix dev builds)
As a non-devel user I'm against the idea for exactly the reasons Terry is mentioning in his last email. It would be a hell for artists to set the compilation options to have the last git version working. Regards, Vicente On 13 November 2014 15:36, Dalai Felinto dfeli...@gmail.com wrote: +1 to the proposed idea on top of that it would be nice to have a 'make release' or similar option to mimic the settings used in the release build. It's worthy noting that the current CMake default settings are already different than the release options (e.g., BlenderPlayer is not built by default). The idea presented here only brings this a step further. Regards, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-11-13 13:14 GMT-02:00 AIBlender aiblen...@gmail.com: On 13/11/14 14:32, Sergey Sharybin wrote: Addressing this: I understand the reasoning behind it Sergey, but if new people want to build Blender they should get something which is approaching a feature complete build, otherwise what is the point of using a Dev build. Why would motion tracker developer want to deal with LLVM? Why new modifier guy would want to deal with Boost? Why compositor or dependency graph guys need to worry about any of external dependencies? This could be continued.. For sure at some point developer would need to be able to compile feature-complete blender, but forcing him to solve all the dependencies from the very beginning is really scary for new developers. If for every new dev you started turning off features because they get confused you end up with a very limited version of Blender. Any dev working on advanced features should be able to compile full versions of Blender, and that Ideally should be because a seasoned Dev has made Blender work with all feature enabled out of the box. Errors when features are turned back on are going to get reported and need fixing anyways, so may as well keep it working from the very beginning with all features on. Anyways my point is clear on this, sorry if it come across as aggressive but, turning off features is just hiding problems, and for people like me it will just mean I turn the features back on a complain a lot more forcefully if I get errors that run out of control because some feature was disabled because of some scared dev. Terry Wallwork ___ 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
Re: [Bf-committers] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous
This reminds me of https://developer.blender.org/D301, with a appropriate choice of samples taken per update. As far as I remember, it reduced the slowdown when using progressive from 30% to 6% for me. Am 13.11.2014 10:58 schrieb Brecht Van Lommel brechtvanlom...@pandora.be: If it is really 100% or 300% slower then that sounds like a fixable issue. I'm not sure why it would be this slow, it would be good to find out why, but one thing that would speed it up is to render more samples at a the time and redraw less often as the current sample increases. Due to the way Monte Carlo integration works, one sample barely makes any visible difference in noise after a while anyway. Maybe something like: num_samples_at_once = sqrt(max(current_sample - 4, 1)) On Nov 13, 2014 10:13 AM, Greg Zaal wrote: Just by the way, it's even more noticeable with GPU rendering - I've seen it roughly 300% slower often. could lead to significant slowdown sounds good to me. On 13 November 2014 11:06, Sergey Sharybin wrote:The issue here is that basically slowdown depends on particular hardware configuration, tile settings and device used to render (GPU/CPU). Meaning, on modern CPU i've noticed around 20% slowdown peak, which is not that bad as 100%. So what i'm trying to say her e, is that if we'll provide information up to 100% slower it might just scary artists and they wouldn't use the option at all, even though for their configuration slowdown wouldn't be so bad. What about more neutral (in my opinion): could lead to significant slowdown? On Thu, Nov 13, 2014 at 12:22 AM, Simon Repp wrote: Dear Renderistas, I only recently found out that progressive refinement in Cyclesrendering (which the corresponding checkbox's tooltip describes to besomewhat slower than bucket rendering) in fact can impose performancepenalties of over 100% (aka the same amount of samples takes more thantwice as long to render). Now I don't know if this is just a personal flawed interpretation of theenglish language on my part, but when reading somewhat slower I didn'trealize what I was really in for, and in retrospect I'd rather notreconstruct how ma ny days my poor laptop spent in excess to render someprojects I did in the past. I'd hereby like to propose a change of this tooltip to something lessambiguous, lest anyone else falls into that same trap that I have - Myproposal for this would be to include actual figures describing thepossible speed penalty that progressive refinement can impose, that is,something along the lines of renders [a]% to [b]% slower depending onthe scene, where figures [a] and [b] are ideally derived from realworld data we gather (or already have?) about how much speed penaltyprogressive refinement can impose in different scenes. Alternatively,only stating up to [x]% slower would work as well I guess, as the mainpoint is to make people aware that it _can_ possibly affect render times_significantly_. If the proposal to include figures is not agreeable for some reason, Iwould at least ask for a more indicative wording than somewhat slower,which even after consulting multiple dictionaries I'm not sure if thereis an official interpretation for. (One dictionary suggests quite as asynoym, another slightly ...) I'd still prefer the figures though, noone looks up terms in the dictionary while using Blender and I amprobably not the worst offender at massacring and misunderstanding theenglish language in the Blender community, and it doesn't get lessambiguous than numbers anyway, so I say we use them here? :) Best,Simon ___Bf-committers mailing listBf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blend er.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 mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
You'd simply have to type in another command, e.g. make-full instead of make. Come on guys. ;) Am 13.11.2014 um 16:58 schrieb Vicente Carro: As a non-devel user I'm against the idea for exactly the reasons Terry is mentioning in his last email. It would be a hell for artists to set the compilation options to have the last git version working. Regards, Vicente On 13 November 2014 15:36, Dalai Felinto dfeli...@gmail.com wrote: +1 to the proposed idea on top of that it would be nice to have a 'make release' or similar option to mimic the settings used in the release build. It's worthy noting that the current CMake default settings are already different than the release options (e.g., BlenderPlayer is not built by default). The idea presented here only brings this a step further. Regards, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-11-13 13:14 GMT-02:00 AIBlender aiblen...@gmail.com: On 13/11/14 14:32, Sergey Sharybin wrote: Addressing this: I understand the reasoning behind it Sergey, but if new people want to build Blender they should get something which is approaching a feature complete build, otherwise what is the point of using a Dev build. Why would motion tracker developer want to deal with LLVM? Why new modifier guy would want to deal with Boost? Why compositor or dependency graph guys need to worry about any of external dependencies? This could be continued.. For sure at some point developer would need to be able to compile feature-complete blender, but forcing him to solve all the dependencies from the very beginning is really scary for new developers. If for every new dev you started turning off features because they get confused you end up with a very limited version of Blender. Any dev working on advanced features should be able to compile full versions of Blender, and that Ideally should be because a seasoned Dev has made Blender work with all feature enabled out of the box. Errors when features are turned back on are going to get reported and need fixing anyways, so may as well keep it working from the very beginning with all features on. Anyways my point is clear on this, sorry if it come across as aggressive but, turning off features is just hiding problems, and for people like me it will just mean I turn the features back on a complain a lot more forcefully if I get errors that run out of control because some feature was disabled because of some scared dev. Terry Wallwork ___ 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 mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
On Thu, Nov 13, 2014 at 5:20 PM, Thomas Dinges blen...@dingto.org wrote: You'd simply have to type in another command, e.g. make-full instead of make. Come on guys. ;) Initial proposal suggests we have a `make release` ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous
Here's a blend which renders (coincidentally) 2.7x slower when using progressive refine: http://gregzaal.com/ss/progressive_refine_speed.blend (44 MB) Rendering on GPU - 2x gtx 570, win7 64 bit, blender 2.72.2 (5cce2e1) Progressive refine off: 139 seconds Progressive refine on: 377 seconds Render res: 1200x1400 (tile size: 240x234, top to bottom) Cheers, Greg On 13 November 2014 12:49, Sergey Sharybin sergey@gmail.com wrote: Brecht, it's multiple factors being involved here, starting from CPU cache coherence issues (which we can't easily predict) ending with less efficient buffers update (we might be saving all the passes after each of the samples in case of progressive refine, which we can fix). But yeah, should have asked for a demo file in the original file :) So do you guys have a demo .blend file which demonstrates such a major slowdown? Brecht, we can (and actually should) do several samples per tile, but i'd prefer log(). not sqrt() perhaps. Other idea to improve cache coherence would be to use left-to-right, bottom-to-top tile scheduling. That gives few %% of speedup, and AFAIR we don't fallback to such a scheduling in progressive refine. And even after the tweaks, we should probably replace somewhat to something more deterministic in the tooltip. On Thu, Nov 13, 2014 at 10:58 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: If it is really 100% or 300% slower then that sounds like a fixable issue. I'm not sure why it would be this slow, it would be good to find out why, but one thing that would speed it up is to render more samples at a the time and redraw less often as the current sample increases. Due to the way Monte Carlo integration works, one sample barely makes any visible difference in noise after a while anyway. Maybe something like: num_samples_at_once = sqrt(max(current_sample - 4, 1)) On Nov 13, 2014 10:13 AM, Greg Zaal gregzzm...@gmail.com wrote: Just by the way, it's even more noticeable with GPU rendering - I've seen it roughly 300% slower often. could lead to significant slowdown sounds good to me. On 13 November 2014 11:06, Sergey Sharybin sergey@gmail.com wrote: The issue here is that basically slowdown depends on particular hardware configuration, tile settings and device used to render (GPU/CPU). Meaning, on modern CPU i've noticed around 20% slowdown peak, which is not that bad as 100%. So what i'm trying to say here, is that if we'll provide information up to 100% slower it might just scary artists and they wouldn't use the option at all, even though for their configuration slowdown wouldn't be so bad. What about more neutral (in my opinion): could lead to significant slowdown? On Thu, Nov 13, 2014 at 12:22 AM, Simon Repp simon@fdpl.foundation wrote: Dear Renderistas, I only recently found out that progressive refinement in Cycles rendering (which the corresponding checkbox's tooltip describes to be somewhat slower than bucket rendering) in fact can impose performance penalties of over 100% (aka the same amount of samples takes more than twice as long to render). Now I don't know if this is just a personal flawed interpretation of the english language on my part, but when reading somewhat slower I didn't realize what I was really in for, and in retrospect I'd rather not reconstruct how many days my poor laptop spent in excess to render some projects I did in the past. I'd hereby like to propose a change of this tooltip to something less ambiguous, lest anyone else falls into that same trap that I have - My proposal for this would be to include actual figures describing the possible speed penalty that progressive refinement can impose, that is, something along the lines of renders [a]% to [b]% slower depending on the scene, where figures [a] and [b] are ideally derived from real world data we gather (or already have?) about how much speed penalty progressive refinement can impose in different scenes. Alternatively, only stating up to [x]% slower would work as well I guess, as the main point is to make people aware that it _can_ possibly affect render times _significantly_. If the proposal to include figures is not agreeable for some reason, I would at least ask for a more indicative wording than somewhat slower, which even after consulting multiple dictionaries I'm not sure if there is an official interpretation for. (One dictionary suggests quite as a synoym, another slightly ...) I'd still prefer the figures though, no one looks up terms in the dictionary while using Blender and I am probably not the worst offender at massacring and misunderstanding the english language in the Blender community, and it doesn't get less ambiguous than numbers anyway, so I say we use them here? :)
Re: [Bf-committers] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous
Ah CUDA.. I'll have a look into it tomorrow. On Thu, Nov 13, 2014 at 6:17 PM, Greg Zaal gregzzm...@gmail.com wrote: Here's a blend which renders (coincidentally) 2.7x slower when using progressive refine: http://gregzaal.com/ss/progressive_refine_speed.blend (44 MB) Rendering on GPU - 2x gtx 570, win7 64 bit, blender 2.72.2 (5cce2e1) Progressive refine off: 139 seconds Progressive refine on: 377 seconds Render res: 1200x1400 (tile size: 240x234, top to bottom) Cheers, Greg On 13 November 2014 12:49, Sergey Sharybin sergey@gmail.com wrote: Brecht, it's multiple factors being involved here, starting from CPU cache coherence issues (which we can't easily predict) ending with less efficient buffers update (we might be saving all the passes after each of the samples in case of progressive refine, which we can fix). But yeah, should have asked for a demo file in the original file :) So do you guys have a demo .blend file which demonstrates such a major slowdown? Brecht, we can (and actually should) do several samples per tile, but i'd prefer log(). not sqrt() perhaps. Other idea to improve cache coherence would be to use left-to-right, bottom-to-top tile scheduling. That gives few %% of speedup, and AFAIR we don't fallback to such a scheduling in progressive refine. And even after the tweaks, we should probably replace somewhat to something more deterministic in the tooltip. On Thu, Nov 13, 2014 at 10:58 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: If it is really 100% or 300% slower then that sounds like a fixable issue. I'm not sure why it would be this slow, it would be good to find out why, but one thing that would speed it up is to render more samples at a the time and redraw less often as the current sample increases. Due to the way Monte Carlo integration works, one sample barely makes any visible difference in noise after a while anyway. Maybe something like: num_samples_at_once = sqrt(max(current_sample - 4, 1)) On Nov 13, 2014 10:13 AM, Greg Zaal gregzzm...@gmail.com wrote: Just by the way, it's even more noticeable with GPU rendering - I've seen it roughly 300% slower often. could lead to significant slowdown sounds good to me. On 13 November 2014 11:06, Sergey Sharybin sergey@gmail.com wrote: The issue here is that basically slowdown depends on particular hardware configuration, tile settings and device used to render (GPU/CPU). Meaning, on modern CPU i've noticed around 20% slowdown peak, which is not that bad as 100%. So what i'm trying to say here, is that if we'll provide information up to 100% slower it might just scary artists and they wouldn't use the option at all, even though for their configuration slowdown wouldn't be so bad. What about more neutral (in my opinion): could lead to significant slowdown? On Thu, Nov 13, 2014 at 12:22 AM, Simon Repp simon@fdpl.foundation wrote: Dear Renderistas, I only recently found out that progressive refinement in Cycles rendering (which the corresponding checkbox's tooltip describes to be somewhat slower than bucket rendering) in fact can impose performance penalties of over 100% (aka the same amount of samples takes more than twice as long to render). Now I don't know if this is just a personal flawed interpretation of the english language on my part, but when reading somewhat slower I didn't realize what I was really in for, and in retrospect I'd rather not reconstruct how many days my poor laptop spent in excess to render some projects I did in the past. I'd hereby like to propose a change of this tooltip to something less ambiguous, lest anyone else falls into that same trap that I have - My proposal for this would be to include actual figures describing the possible speed penalty that progressive refinement can impose, that is, something along the lines of renders [a]% to [b]% slower depending on the scene, where figures [a] and [b] are ideally derived from real world data we gather (or already have?) about how much speed penalty progressive refinement can impose in different scenes. Alternatively, only stating up to [x]% slower would work as well I guess, as the main point is to make people aware that it _can_ possibly affect render times _significantly_. If the proposal to include figures is not agreeable for some reason, I would at least ask for a more indicative wording than somewhat slower, which even after consulting multiple dictionaries I'm not sure if there is an official interpretation for. (One dictionary suggests quite as a synoym, another slightly ...) I'd still prefer the figures though, no one looks up terms in the dictionary
Re: [Bf-committers] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous
The tooltip of the UV unwrapping method (when using u-unwrap) also says: ..., while being somewhat slower. I always wondered about this.. maybe change it as well? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
Let me protest a bit about that idea. I love to compile full-blown blender right off the bat, having all it's options enabled, with all deps and plugins. This is something very desirable, to have FULL version of everything (and not thinking maybe I missed something). So, I understand the need of shortening compilation process by devs, as it is saving time. But why not to reverse this proposal then? Let's do this instead: - lets define a new limited target for make, say 'make barebone' or 'make-light' or whatever. It is already doable by hand, by -D definitions and, as Sergey said, most devs already scripted it. So what's the problem? Let devs use this way of barebone compilation, not the end-users. As as an end user (and as a wannabe-dev) I would love to have all features enabled and accessible by default, without any hassle and without the need of additional configuration steps. Even make-something is non-standard and should be avoided for casual users. Devs can use all sort of make-o-magick commands, leaving users undisturbed and letting them compiling all things by default. Just my two cents, peace! regards Pio Piotr Polski Kurs Blendera: http://polskikursblendera.pl, YT: /user/piotao?feature=guide FB: /polskikursblendera TW: /piotao 2014-11-13 17:25 GMT+01:00 Campbell Barton ideasma...@gmail.com: On Thu, Nov 13, 2014 at 5:20 PM, Thomas Dinges blen...@dingto.org wrote: You'd simply have to type in another command, e.g. make-full instead of make. Come on guys. ;) Initial proposal suggests we have a `make release` ___ 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] Propose to reduce default feature set (*nix dev builds)
On Thu, Nov 13, 2014 at 9:48 PM, Piotr Arlukowicz pio...@polskikursblendera.pl wrote: Let me protest a bit about that idea. I love to compile full-blown blender right off the bat, having all it's options enabled, with all deps and plugins. This is something very desirable, to have FULL version of everything (and not thinking maybe I missed something). So, I understand the need of shortening compilation process by devs, as it is saving time. But why not to reverse this proposal then? Let's do this instead: - lets define a new limited target for make, say 'make barebone' or 'make-light' or whatever. It is already doable by hand, by -D definitions and, as Sergey said, most devs already scripted it. So what's the problem? Let devs use this way of barebone compilation, not the end-users. As as an end user (and as a wannabe-dev) I would love to have all features enabled and accessible by default, without any hassle and without the need of additional configuration steps. Even make-something is non-standard and should be avoided for casual users. Devs can use all sort of make-o-magick commands, leaving users undisturbed and letting them compiling all things by default. Just my two cents, peace! regards Pio Piotr Polski Kurs Blendera: http://polskikursblendera.pl, YT: /user/piotao?feature=guide FB: /polskikursblendera TW: /piotao 2014-11-13 17:25 GMT+01:00 Campbell Barton ideasma...@gmail.com: On Thu, Nov 13, 2014 at 5:20 PM, Thomas Dinges blen...@dingto.org wrote: You'd simply have to type in another command, e.g. make-full instead of make. Come on guys. ;) Initial proposal suggests we have a `make release` ___ 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 -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
When I switched from Ubuntu to Fedora it took me about 2 weeks on and off to get a successful build again, afterwards I had a full working build but I was 50% down on motivation and 100% out of free time for that month to get into actual coding again. Who knows what would have happened in those two weeks if I had actually coded? (and afterwards in that altered timeline ...!?) In that sense I really like the idea, though I would prefer the inverse implementation: 'make' for the full build, 'make simple' (or so) as a (prominently documented!!) simpler way for dev newcomers to have at hand if the full build process is discouraging or blocking actual development. I suggest the inverse implementation because sometimes building the full thing actually works like a charm (it did for me on Ubuntu), so you'd get the full thing for free in that case - and initially failing and retrying can also lead to important discoveries, for instance my 2 week odyssey to building Blender on Fedora actually revealed a major bug in the dependency installer script, which I could fix together with mont29's help then. Either way it's implemented, thumbs up, I like it!! On 11/13/2014 12:31 PM, Campbell Barton wrote: This is mainly for Linux/BSD developers (releases remain unchanged). Its getting increasingly difficult to build Blender on Linux, (LLVM, ffmpeg, OpenCollada...) these issue's can't always be fixed on our side. With newer developers a failed build with a cryptic error message (guys in #blendercoders can't even help with), is quite off putting.. Proposing a limited feature-set by default with CMake (again official builds from blender.org are unchanged) https://developer.blender.org/T42569 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous
Here's the scene I initially used to test this: IMAGE http://fdpl.foundation/prog-vs-nonprog-suzanne-volumetric-dof-displacement.png (10MB) BLEND http://fdpl.foundation/prog-vs-nonprog-suzanne-volumetric-dof-displacement.blend (1MB) I rendered on CPU - i7-2920XM quad-core (2.50GHz, 8MB cache), fedora 20 64 bit, blender 2.72b official release Non-Progressive: 61 seconds Progressive: 165 seconds Super coincidentally also 2.7x slower :D Cheers, Simon On 11/13/2014 11:49 AM, Sergey Sharybin wrote: Brecht, it's multiple factors being involved here, starting from CPU cache coherence issues (which we can't easily predict) ending with less efficient buffers update (we might be saving all the passes after each of the samples in case of progressive refine, which we can fix). But yeah, should have asked for a demo file in the original file :) So do you guys have a demo .blend file which demonstrates such a major slowdown? Brecht, we can (and actually should) do several samples per tile, but i'd prefer log(). not sqrt() perhaps. Other idea to improve cache coherence would be to use left-to-right, bottom-to-top tile scheduling. That gives few %% of speedup, and AFAIR we don't fallback to such a scheduling in progressive refine. And even after the tweaks, we should probably replace somewhat to something more deterministic in the tooltip. On Thu, Nov 13, 2014 at 10:58 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: If it is really 100% or 300% slower then that sounds like a fixable issue. I'm not sure why it would be this slow, it would be good to find out why, but one thing that would speed it up is to render more samples at a the time and redraw less often as the current sample increases. Due to the way Monte Carlo integration works, one sample barely makes any visible difference in noise after a while anyway. Maybe something like: num_samples_at_once = sqrt(max(current_sample - 4, 1)) On Nov 13, 2014 10:13 AM, Greg Zaal gregzzm...@gmail.com wrote: Just by the way, it's even more noticeable with GPU rendering - I've seen it roughly 300% slower often. could lead to significant slowdown sounds good to me. On 13 November 2014 11:06, Sergey Sharybin sergey@gmail.com wrote: The issue here is that basically slowdown depends on particular hardware configuration, tile settings and device used to render (GPU/CPU). Meaning, on modern CPU i've noticed around 20% slowdown peak, which is not that bad as 100%. So what i'm trying to say here, is that if we'll provide information up to 100% slower it might just scary artists and they wouldn't use the option at all, even though for their configuration slowdown wouldn't be so bad. What about more neutral (in my opinion): could lead to significant slowdown? On Thu, Nov 13, 2014 at 12:22 AM, Simon Repp simon@fdpl.foundation wrote: Dear Renderistas, I only recently found out that progressive refinement in Cycles rendering (which the corresponding checkbox's tooltip describes to be somewhat slower than bucket rendering) in fact can impose performance penalties of over 100% (aka the same amount of samples takes more than twice as long to render). Now I don't know if this is just a personal flawed interpretation of the english language on my part, but when reading somewhat slower I didn't realize what I was really in for, and in retrospect I'd rather not reconstruct how many days my poor laptop spent in excess to render some projects I did in the past. I'd hereby like to propose a change of this tooltip to something less ambiguous, lest anyone else falls into that same trap that I have - My proposal for this would be to include actual figures describing the possible speed penalty that progressive refinement can impose, that is, something along the lines of renders [a]% to [b]% slower depending on the scene, where figures [a] and [b] are ideally derived from real world data we gather (or already have?) about how much speed penalty progressive refinement can impose in different scenes. Alternatively, only stating up to [x]% slower would work as well I guess, as the main point is to make people aware that it _can_ possibly affect render times _significantly_. If the proposal to include figures is not agreeable for some reason, I would at least ask for a more indicative wording than somewhat slower, which even after consulting multiple dictionaries I'm not sure if there is an official interpretation for. (One dictionary suggests quite as a synoym, another slightly ...) I'd still prefer the figures though, no one looks up terms in the dictionary while using Blender and I am probably not the worst offender at massacring and misunderstanding the english language in the Blender community, and it doesn't get less ambiguous than numbers anyway, so I say we use them here? :) Best, Simon ___ Bf-committers mailing list
Re: [Bf-committers] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous
It crashes my blender build like a charm, here's the small backtrace (sorry but it's so short it won't hurt I think): # Blender 2.72 (sub 2), Commit date: 2014-11-11 20:44, Hash c932edb # backtrace /home/piotao/bin/blender() [0x9b85ec] /home/piotao/bin/blender() [0x9b8884] /lib/x86_64-linux-gnu/libc.so.6(+0x36c30) [0x7fbbdc168c30] /home/piotao/bin/blender() [0x160ebde] /home/piotao/bin/blender(_ZN3ccl9CPUDevice13thread_shaderERNS_10DeviceTaskE+0x8f) [0x146ad6f] /home/piotao/bin/blender(_ZN3ccl13TaskScheduler10thread_runEi+0x28) [0x151e928] /home/piotao/bin/blender(_ZN3ccl6thread3runEPv+0x19) [0x151fd99] /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182) [0x7fbbdcb0a182] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fbbdc22cfbd] Rendering don't work either as F12 or as Shift-Z. Maybe somebody can find this helpful. cheers! pio Piotr Arłukowicz, BFCT *Polski Kurs Blendera*: *http://polskikursblendera.pl http://polskikursblendera.pl*, YT: /user/piotao?feature=guide, FB: /polskikursblendera, TW: /piotao 2014-11-13 22:24 GMT+01:00 Simon Repp simon@fdpl.foundation: Here's the scene I initially used to test this: IMAGE http://fdpl.foundation/prog-vs-nonprog-suzanne-volumetric-dof-displacement.png (10MB) BLEND http://fdpl.foundation/prog-vs-nonprog-suzanne-volumetric-dof-displacement.blend (1MB) I rendered on CPU - i7-2920XM quad-core (2.50GHz, 8MB cache), fedora 20 64 bit, blender 2.72b official release Non-Progressive: 61 seconds Progressive: 165 seconds Super coincidentally also 2.7x slower :D Cheers, Simon ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous
Might not be the reason for your crash, but please take note that in my example scene I enabled the experimental featureset for rendering (because: material based displacement). So in a way it could be ok that it crashes, if such a thing can be said :D. o/ Greets!! On 11/13/2014 10:46 PM, PKB wrote: It crashes my blender build like a charm, here's the small backtrace (sorry but it's so short it won't hurt I think): # Blender 2.72 (sub 2), Commit date: 2014-11-11 20:44, Hash c932edb # backtrace /home/piotao/bin/blender() [0x9b85ec] /home/piotao/bin/blender() [0x9b8884] /lib/x86_64-linux-gnu/libc.so.6(+0x36c30) [0x7fbbdc168c30] /home/piotao/bin/blender() [0x160ebde] /home/piotao/bin/blender(_ZN3ccl9CPUDevice13thread_shaderERNS_10DeviceTaskE+0x8f) [0x146ad6f] /home/piotao/bin/blender(_ZN3ccl13TaskScheduler10thread_runEi+0x28) [0x151e928] /home/piotao/bin/blender(_ZN3ccl6thread3runEPv+0x19) [0x151fd99] /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182) [0x7fbbdcb0a182] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fbbdc22cfbd] Rendering don't work either as F12 or as Shift-Z. Maybe somebody can find this helpful. cheers! pio Piotr Arłukowicz, BFCT *Polski Kurs Blendera*: *http://polskikursblendera.pl http://polskikursblendera.pl*, YT: /user/piotao?feature=guide, FB: /polskikursblendera, TW: /piotao 2014-11-13 22:24 GMT+01:00 Simon Repp simon@fdpl.foundation: Here's the scene I initially used to test this: IMAGE http://fdpl.foundation/prog-vs-nonprog-suzanne-volumetric-dof-displacement.png (10MB) BLEND http://fdpl.foundation/prog-vs-nonprog-suzanne-volumetric-dof-displacement.blend (1MB) I rendered on CPU - i7-2920XM quad-core (2.50GHz, 8MB cache), fedora 20 64 bit, blender 2.72b official release Non-Progressive: 61 seconds Progressive: 165 seconds Super coincidentally also 2.7x slower :D Cheers, Simon ___ 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] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous
Please don't do bug reports in the mailing list, and put it on the developer.blender.org instead. On Thu, Nov 13, 2014 at 10:53 PM, Simon Repp simon@fdpl.foundation wrote: Might not be the reason for your crash, but please take note that in my example scene I enabled the experimental featureset for rendering (because: material based displacement). So in a way it could be ok that it crashes, if such a thing can be said :D. o/ Greets!! On 11/13/2014 10:46 PM, PKB wrote: It crashes my blender build like a charm, here's the small backtrace (sorry but it's so short it won't hurt I think): # Blender 2.72 (sub 2), Commit date: 2014-11-11 20:44, Hash c932edb # backtrace /home/piotao/bin/blender() [0x9b85ec] /home/piotao/bin/blender() [0x9b8884] /lib/x86_64-linux-gnu/libc.so.6(+0x36c30) [0x7fbbdc168c30] /home/piotao/bin/blender() [0x160ebde] /home/piotao/bin/blender(_ZN3ccl9CPUDevice13thread_shaderERNS_10DeviceTaskE+0x8f) [0x146ad6f] /home/piotao/bin/blender(_ZN3ccl13TaskScheduler10thread_runEi+0x28) [0x151e928] /home/piotao/bin/blender(_ZN3ccl6thread3runEPv+0x19) [0x151fd99] /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182) [0x7fbbdcb0a182] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fbbdc22cfbd] Rendering don't work either as F12 or as Shift-Z. Maybe somebody can find this helpful. cheers! pio Piotr Arłukowicz, BFCT *Polski Kurs Blendera*: *http://polskikursblendera.pl http://polskikursblendera.pl*, YT: /user/piotao?feature=guide, FB: /polskikursblendera, TW: /piotao 2014-11-13 22:24 GMT+01:00 Simon Repp simon@fdpl.foundation: Here's the scene I initially used to test this: IMAGE http://fdpl.foundation/prog-vs-nonprog-suzanne-volumetric-dof-displacement.png (10MB) BLEND http://fdpl.foundation/prog-vs-nonprog-suzanne-volumetric-dof-displacement.blend (1MB) I rendered on CPU - i7-2920XM quad-core (2.50GHz, 8MB cache), fedora 20 64 bit, blender 2.72b official release Non-Progressive: 61 seconds Progressive: 165 seconds Super coincidentally also 2.7x slower :D Cheers, Simon ___ 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 -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
On Thu, Nov 13, 2014 at 10:00 PM, Simon Repp simon@fdpl.foundation wrote: When I switched from Ubuntu to Fedora it took me about 2 weeks on and off to get a successful build again, afterwards I had a full working build but I was 50% down on motivation and 100% out of free time for that month to get into actual coding again. Who knows what would have happened in those two weeks if I had actually coded? (and afterwards in that altered timeline ...!?) In that sense I really like the idea, though I would prefer the inverse implementation: 'make' for the full build, 'make simple' (or so) as a (prominently documented!!) simpler way for dev newcomers to have at hand if the full build process is discouraging or blocking actual development. We have `make lite`, its referenced in the linux build docs and in `make help`. http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Linux/Ubuntu/CMake#Automatic_CMake_Setup Its probably worth mentioning that this can be used to get up and running quickly. I suggest the inverse implementation because sometimes building the full thing actually works like a charm (it did for me on Ubuntu), so you'd get the full thing for free in that case - and initially failing and retrying can also lead to important discoveries, for instance my 2 week odyssey to building Blender on Fedora actually revealed a major bug in the dependency installer script, which I could fix together with mont29's help then. Either way it's implemented, thumbs up, I like it!! On 11/13/2014 12:31 PM, Campbell Barton wrote: This is mainly for Linux/BSD developers (releases remain unchanged). Its getting increasingly difficult to build Blender on Linux, (LLVM, ffmpeg, OpenCollada...) these issue's can't always be fixed on our side. With newer developers a failed build with a cryptic error message (guys in #blendercoders can't even help with), is quite off putting.. Proposing a limited feature-set by default with CMake (again official builds from blender.org are unchanged) https://developer.blender.org/T42569 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
Committed the changed defaults for CMake: https://developer.blender.org/rBbf63e348a2c481fa523466a86dd52cedadc62bc8 Noted in build docs: http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Linux/cmake#Automatic_CMake_Setup Existing builds won't change their configurations, but we'll need to make sure distro package maintainers use the options in: https://developer.blender.org/diffusion/B/browse/master/build_files/cmake/config/blender_full.cmake On Fri, Nov 14, 2014 at 12:23 AM, Campbell Barton ideasma...@gmail.com wrote: On Thu, Nov 13, 2014 at 10:00 PM, Simon Repp simon@fdpl.foundation wrote: When I switched from Ubuntu to Fedora it took me about 2 weeks on and off to get a successful build again, afterwards I had a full working build but I was 50% down on motivation and 100% out of free time for that month to get into actual coding again. Who knows what would have happened in those two weeks if I had actually coded? (and afterwards in that altered timeline ...!?) In that sense I really like the idea, though I would prefer the inverse implementation: 'make' for the full build, 'make simple' (or so) as a (prominently documented!!) simpler way for dev newcomers to have at hand if the full build process is discouraging or blocking actual development. We have `make lite`, its referenced in the linux build docs and in `make help`. http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Linux/Ubuntu/CMake#Automatic_CMake_Setup Its probably worth mentioning that this can be used to get up and running quickly. I suggest the inverse implementation because sometimes building the full thing actually works like a charm (it did for me on Ubuntu), so you'd get the full thing for free in that case - and initially failing and retrying can also lead to important discoveries, for instance my 2 week odyssey to building Blender on Fedora actually revealed a major bug in the dependency installer script, which I could fix together with mont29's help then. Either way it's implemented, thumbs up, I like it!! On 11/13/2014 12:31 PM, Campbell Barton wrote: This is mainly for Linux/BSD developers (releases remain unchanged). Its getting increasingly difficult to build Blender on Linux, (LLVM, ffmpeg, OpenCollada...) these issue's can't always be fixed on our side. With newer developers a failed build with a cryptic error message (guys in #blendercoders can't even help with), is quite off putting.. Proposing a limited feature-set by default with CMake (again official builds from blender.org are unchanged) https://developer.blender.org/T42569 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Revising the testbuild branch
How to make a build now? After I click on 'Force Build' I land in a page saying: Authorization Failed. You are not allowed to perform this action. And for the records, in the future it would help to have the outcome of such an important discussion re-sent to the list as an email on its own (instead of a reply in a 11-email long thread) ... I just pushed 'testbuild' back to the servers :( [and deleted it after, but still, the notification commits will be all over everyone's email boxes]. Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-10-16 8:16 GMT-03:00 Bastien Montagne montagn...@wanadoo.fr: Hi devs, So, we resurrected testbuild as 'experimental-build', getting rid of the issues that caused last week's shutdown of this tool (i.e. builds publicly available from builder.b.o., and confusing name with testbuilds done during release process). Note this tool implies commit access to our main git repository. Here are the steps to follow to make an experimental build: * Checkout the 'experimental-build' branch, merge master in, squash-apply your code to it, revert last commit, and push to origin (see below[1] for an concrete example); * Go to one of the buildbot's builders' page (e.g. https://builder.blender.org/builders/linux_glibc211_x86_64_scons) - note you'll need to do that for all platforms you want to build on. * Select 'experimental-build' instead of 'master' in the branch dropdown, copy-paste the exact hash of your squashed-commit of your patch into 'revision' field, and force the build. * Go to the experimental 'hidden' sub-folder of https://builder.blender.org/download/ and download your builds from there asap. * DO NOT SHARE ABOVE LINK PUBLICLY! It's your responsibility to distribute your builds (e.g. through graphicall, dropbox, whatever), 'official' blender site should not be involved in this. Note that the next experimental build on the same builder will replace current one, so builder.b.o is not a reliable storage for such builds anyway! Quite obviously, let's try not to abuse the feature! :) Happy Blending, Bastien [1] Typical git commands to make an experimental build: $ git checkout experimental-build $ git merge origin/master $ git merge --squash mywippatch $ git commit $ git revert HEAD $ git push origin $ git checkout master Le 12/10/2014 10:39, Sergey Sharybin a écrit : Think we should agree on some better name then and deploy? On Sun, Oct 12, 2014 at 9:19 AM, Bastien Montagne montagn...@wanadoo.fr wrote: Good catch, this seems to work fine! :) Le 12/10/2014 08:26, Sergey Sharybin a écrit : Did you try using public_html/testbuilds instead? There's also a code in the template which lusts the dirs, could comment that out. On Oct 11, 2014 11:27 PM, Bastien Montagne montagn...@wanadoo.fr wrote: Following Sergey's suggestion (put testbuilds in a separate dir) I fought a bit with my local version of buildbot to get it running again. In the end, looks like a very simple change is enough, in master_unpack.py, something like: diff --git a/build_files/buildbot/master_unpack.py b/build_files/buildbot/master_unpack.py index ecacf3b..f5c8493 100644 --- a/build_files/buildbot/master_unpack.py +++ b/build_files/buildbot/master_unpack.py @@ -116,7 +116,7 @@ if platform == '': sys.exit(1) # extract -directory = 'public_html/download' +directory = 'public_html/download' if branch == 'master' else 'public_html/download/testbuilds' try: zf = z.open(package) public_html/download/testbuilds must be created beforehand of course. On my local web buildbot UI, that dir is automatically listed under the download page… Not sure whether we consider that as safe enough for users not to mess with it? Guess we can find a way to hide it, otherwise. As a side note, do not think listing those builds publically is needed at all, they are replaced by next one so dev has to 'backup' them anyway. And yes, probably renaming could be nice too… 'experimental' sounds good to me. Bastien Le 11/10/2014 20:26, Sergey Sharybin a écrit : It _had been_ discussed several times at least. Starting from discussion in #lbendercoders between me, Dan, Bastien and even Ton. Then once it was all set up (and i believe some discussion happened in the ML as well). Once all the changes to the infrastructure were done it was announced in the ML: http://lists.blender.org/pipermail/bf-committers/2014-July/043948.html In such a situation it's real weird to have a post-factum it should have never been done this way. As an addition to the previous suggestion: - We can as well just put a REAL HUGE BANNER on top of the experimental builds just to stress once again that they're experimental if it'll be considered useful to have those builds listed to public. - We can rename testbuild to something like devbuild (as developer-build) or experimental to prevent
Re: [Bf-committers] Revising the testbuild branch
That's not the first time I have these 100+ e-mails from the testbuild branch in my inbox. Can't we do something about this? ... Am 14.11.2014 um 04:47 schrieb Dalai Felinto: How to make a build now? After I click on 'Force Build' I land in a page saying: Authorization Failed. You are not allowed to perform this action. And for the records, in the future it would help to have the outcome of such an important discussion re-sent to the list as an email on its own (instead of a reply in a 11-email long thread) ... I just pushed 'testbuild' back to the servers :( [and deleted it after, but still, the notification commits will be all over everyone's email boxes]. Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-10-16 8:16 GMT-03:00 Bastien Montagne montagn...@wanadoo.fr: Hi devs, So, we resurrected testbuild as 'experimental-build', getting rid of the issues that caused last week's shutdown of this tool (i.e. builds publicly available from builder.b.o., and confusing name with testbuilds done during release process). Note this tool implies commit access to our main git repository. Here are the steps to follow to make an experimental build: * Checkout the 'experimental-build' branch, merge master in, squash-apply your code to it, revert last commit, and push to origin (see below[1] for an concrete example); * Go to one of the buildbot's builders' page (e.g. https://builder.blender.org/builders/linux_glibc211_x86_64_scons) - note you'll need to do that for all platforms you want to build on. * Select 'experimental-build' instead of 'master' in the branch dropdown, copy-paste the exact hash of your squashed-commit of your patch into 'revision' field, and force the build. * Go to the experimental 'hidden' sub-folder of https://builder.blender.org/download/ and download your builds from there asap. * DO NOT SHARE ABOVE LINK PUBLICLY! It's your responsibility to distribute your builds (e.g. through graphicall, dropbox, whatever), 'official' blender site should not be involved in this. Note that the next experimental build on the same builder will replace current one, so builder.b.o is not a reliable storage for such builds anyway! Quite obviously, let's try not to abuse the feature! :) Happy Blending, Bastien [1] Typical git commands to make an experimental build: $ git checkout experimental-build $ git merge origin/master $ git merge --squash mywippatch $ git commit $ git revert HEAD $ git push origin $ git checkout master Le 12/10/2014 10:39, Sergey Sharybin a écrit : Think we should agree on some better name then and deploy? On Sun, Oct 12, 2014 at 9:19 AM, Bastien Montagne montagn...@wanadoo.fr wrote: Good catch, this seems to work fine! :) Le 12/10/2014 08:26, Sergey Sharybin a écrit : Did you try using public_html/testbuilds instead? There's also a code in the template which lusts the dirs, could comment that out. On Oct 11, 2014 11:27 PM, Bastien Montagne montagn...@wanadoo.fr wrote: Following Sergey's suggestion (put testbuilds in a separate dir) I fought a bit with my local version of buildbot to get it running again. In the end, looks like a very simple change is enough, in master_unpack.py, something like: diff --git a/build_files/buildbot/master_unpack.py b/build_files/buildbot/master_unpack.py index ecacf3b..f5c8493 100644 --- a/build_files/buildbot/master_unpack.py +++ b/build_files/buildbot/master_unpack.py @@ -116,7 +116,7 @@ if platform == '': sys.exit(1) # extract -directory = 'public_html/download' +directory = 'public_html/download' if branch == 'master' else 'public_html/download/testbuilds' try: zf = z.open(package) public_html/download/testbuilds must be created beforehand of course. On my local web buildbot UI, that dir is automatically listed under the download page… Not sure whether we consider that as safe enough for users not to mess with it? Guess we can find a way to hide it, otherwise. As a side note, do not think listing those builds publically is needed at all, they are replaced by next one so dev has to 'backup' them anyway. And yes, probably renaming could be nice too… 'experimental' sounds good to me. Bastien Le 11/10/2014 20:26, Sergey Sharybin a écrit : It _had been_ discussed several times at least. Starting from discussion in #lbendercoders between me, Dan, Bastien and even Ton. Then once it was all set up (and i believe some discussion happened in the ML as well). Once all the changes to the infrastructure were done it was announced in the ML: http://lists.blender.org/pipermail/bf-committers/2014-July/043948.html In such a situation it's real weird to have a post-factum it should have never been done this way. As an addition to the previous suggestion: - We can as well just put a REAL HUGE BANNER on top of the experimental builds just to stress once again
