Re: [Bf-committers] Blender 2.67b release AHOY!
Hi Ton, This is a good lesson for me. I am very sorry for what happened. With Respect Bartek Skorupa www.bartekskorupa.com On 31 maj 2013, at 10:21, Ton Roosendaal t...@blender.org wrote: Hi Bartek, For our releases we try to keep everyone stick to only add crucial fixes in the last weeks before a release, and certainly for an 'a' update. I've just checked a few of your commits, but it appears to be regular maintenance and development work as well. Add-ons in a release should go via the same ruling as the rest of code. I am not following the add-on tracker commit mails though, might well be happening already :) Anyway - perfect releases don't exist. I propose to add a short note on the download page about the Node Efficiency Tools and link to where the update can be loaded. We're now 3 weeks after the 2.67 release too, with a bi-monthly cycle a next release would happen within 5-6 six weeks anyway. Let's try to do better next time, and just communicate well about unfortunate errors. -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 30 May, 2013, at 20:36, Bartek Skorupa (priv) wrote: Hi, It seems that I made a mistake that I would like to apologize for. On May 27th I made a list of my commits that I wanted to be included in 2.67b release. It is all related to node_efficiency_tools.py add on. In trunk the version is ok, but in my list I omitted one very important commit that removed one syntax error. My list was as follows: Here's the list of commits: 4514, 4515, 4534, 4537, 4538 and 4541 I ommited commit 4539 that was: Revision: 4539 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-extensionsrevision=4539 Author: bartekskorupa Date: 2013-05-17 17:45:56 + (Fri, 17 May 2013) Log Message: --- Bug fix. Simple syntax error. Sorry Modified Paths: -- trunk/py/scripts/addons/node_efficiency_tools.py Modified: trunk/py/scripts/addons/node_efficiency_tools.py === --- trunk/py/scripts/addons/node_efficiency_tools.py 2013-05-17 17:20:20 UTC (rev 4538) +++ trunk/py/scripts/addons/node_efficiency_tools.py 2013-05-17 17:45:56 UTC (rev 4539) @@ -1124,7 +1124,7 @@ valid = False if (space.type == 'NODE_EDITOR' and space.node_tree is not None and -context.active_node is not None and +context.active_node is not None ): valid = True return valid Because this commit was omitted now in official release we have syntax error. This is my mistake. I did fix the bug, but when creating list of commits to be included I omitted this very important one. I am very sorry for that. Is there any way of fixing this at this point? With Respect Bartek Skorupa www.bartekskorupa.com On 29 maj 2013, at 19:51, Campbell Barton ideasma...@gmail.com wrote: Lets hope this is the last 2.67 release :) Information for platform maintainers: tag: blender-2.67b-release tag revision: 57123 addons revision: 4542 locale revision: 1888 To avoid doing a full checkout of svn. # first ensure no local changes svn revert -R . # check for no additional source files svn st # switch to the release tag svn switch https://svn.blender.org/svnroot/bf-blender/tags/blender-2.67b-release/blender For reference, list of revs merged: http://wiki.blender.org/index.php/User:Ideasman42/267b_bugfix ___ 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
[Bf-committers] Cuda 5.5 Release Candidate available
Hi there, I just saw that NVidia has released the Cuda 5.5 RC for registered Cuda devs. It supports VS 2012 now... So I can begin testing with cuda binaries compiled with VS2012 without having to cheat ;) /Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cuda 5.5 Release Candidate available
Hi, I tested the 5.5 Toolkit already, and unfortunately it still gives a big slowdown for Cycles rendering. So updating to 5.5 is not a solution for our official releases. :( Thomas Am 03.06.2013 10:54, schrieb Jürgen Herrmann: Hi there, I just saw that NVidia has released the Cuda 5.5 RC for registered Cuda devs. It supports VS 2012 now... So I can begin testing with cuda binaries compiled with VS2012 without having to cheat ;) /Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cuda 5.5 Release Candidate available
Hmm, unfortunately it's the only clean solution for vs 2012 :( The other solution is to trick nvcc by either using the vc9 platform toolkit to compile cycles cuda kernel or to manually edit some files to force compilation with vs 2012. Both gave me random crashes I could not reproduce with 100% reliability. /Jürgen Am 03.06.2013 um 11:12 schrieb Thomas Dinges blen...@dingto.org: Hi, I tested the 5.5 Toolkit already, and unfortunately it still gives a big slowdown for Cycles rendering. So updating to 5.5 is not a solution for our official releases. :( Thomas Am 03.06.2013 10:54, schrieb Jürgen Herrmann: Hi there, I just saw that NVidia has released the Cuda 5.5 RC for registered Cuda devs. It supports VS 2012 now... So I can begin testing with cuda binaries compiled with VS2012 without having to cheat ;) /Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ 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] Problems with projects.blender.org subscriptions
Hi Mitchell, We found out that (probably due to a bug) over 600 people were monitoring the tracker, which caused the system to send out 600 mails for every change in the tracker. That caused the mail queue to get stuck, with a load of bounces. Result was also that many updates for reports you want (when you post on a bug or subscribe to it) didn't get sent even. For that reason the monitoring feature got disabled now. It only send mails when you assign yourself to a bug, or post on a report. Obviously we should look at restoring useful features, but meanwhile people are also checking on a good replacement for the trackers... -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 2 Jun, 2013, at 21:01, Mitchell Stokes wrote: I used to be subscribed to the BGE tracker on blender.projects.org so I would be notified of any changes to that tracker (and thus any new bugs). However, lately I have not been getting any notifications, and when I went to check on the tracker today, there were at least ten new bugs that I wasn't notified about. I tried looking around for a way to resubscribe (I don't remember how I did this the last time), but without luck. Has this (very useful) feature been disabled? Or did something break with the tracker? --Mitchell ___ 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] Cuda 5.5 Release Candidate available
I just had a look on the nvcc compiler options we use to compile cuda binaries. First of all we still use --opencc-options that are ignored by nvcc 5.0 and 5.5 when compiling for sm_20 and up. Maybe we should see if there are nvcc optimization options we can use to regain speed when using Cuda 5.0+. /Jürgen Am 03. Juni 2013 um 11:39 schrieb Jürgen Herrmann shadow...@me.com: Hmm, unfortunately it's the only clean solution for vs 2012 :( The other solution is to trick nvcc by either using the vc9 platform toolkit to compile cycles cuda kernel or to manually edit some files to force compilation with vs 2012. Both gave me random crashes I could not reproduce with 100% reliability. /Jürgen Am 03.06.2013 um 11:12 schrieb Thomas Dinges blen...@dingto.org: Hi, I tested the 5.5 Toolkit already, and unfortunately it still gives a big slowdown for Cycles rendering. So updating to 5.5 is not a solution for our official releases. :( Thomas Am 03.06.2013 10:54, schrieb Jürgen Herrmann: Hi there, I just saw that NVidia has released the Cuda 5.5 RC for registered Cuda devs. It supports VS 2012 now... So I can begin testing with cuda binaries compiled with VS2012 without having to cheat ;) /Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ 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] [PATCH] Fix crash in rna_access.c
Hello, a user has reported a crash in rna_access.c on http://bugzilla.redhat.com at B/ #969043. I have create the attached patch for fixing this issue. It may be nice, if anyoune can get a look on it. Best Regards: Jochen Schmitt diff -up blender-2.67a/source/blender/makesrna/intern/rna_access.c.rna blender-2.67a/source/blender/makesrna/intern/rna_access.c --- blender-2.67a/source/blender/makesrna/intern/rna_access.c.rna 2013-06-03 17:18:37.070246295 +0200 +++ blender-2.67a/source/blender/makesrna/intern/rna_access.c 2013-06-03 17:37:49.453608060 +0200 @@ -1273,8 +1273,9 @@ void RNA_property_enum_items_gettexted(b int totitem = 0; /* count */ - for (i = 0; (*item)[i].identifier; i++) - totitem++; + if (*item) + for (i = 0; (*item)[i].identifier; i++) + totitem++; nitem = MEM_callocN(sizeof(EnumPropertyItem) * (totitem + 1), enum_items_gettexted); ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [PATCH] Fix crash in rna_access.c
On Tue, Jun 4, 2013 at 2:28 AM, Jochen Schmitt joc...@herr-schmitt.de wrote: Hello, a user has reported a crash in rna_access.c on http://bugzilla.redhat.com at B/ #969043. I have create the attached patch for fixing this issue. It may be nice, if anyoune can get a look on it. Best Regards: Jochen Schmitt diff -up blender-2.67a/source/blender/makesrna/intern/rna_access.c.rna blender-2.67a/source/blender/makesrna/intern/rna_access.c --- blender-2.67a/source/blender/makesrna/intern/rna_access.c.rna 2013-06-03 17:18:37.070246295 +0200 +++ blender-2.67a/source/blender/makesrna/intern/rna_access.c 2013-06-03 17:37:49.453608060 +0200 @@ -1273,8 +1273,9 @@ void RNA_property_enum_items_gettexted(b int totitem = 0; /* count */ - for (i = 0; (*item)[i].identifier; i++) - totitem++; + if (*item) + for (i = 0; (*item)[i].identifier; i++) + totitem++; nitem = MEM_callocN(sizeof(EnumPropertyItem) * (totitem + 1), enum_items_gettexted); Hi, Id like to be able to redo the bug but the I couldn't find a link to the report. Assume this is the bug you meant? https://bugzilla.redhat.com/show_bug.cgi?id=969043 It links to another report - but nothing blender related. -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [PATCH] Fix crash in rna_access.c
On Tue, Jun 04, 2013 at 03:17:14AM +1000, Campbell Barton wrote: Hi, Id like to be able to redo the bug but the I couldn't find a link to the report. Assume this is the bug you meant? https://bugzilla.redhat.com/show_bug.cgi?id=969043 It links to another report - but nothing blender related. The correct link is: https://bugzilla.redhat.com/show_bug.cgi?id=969843 Best Regards: Jochen Schmitt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] massive cuda speed improvements with Cuda 5.0/5.5
Hi there, I did some tests with cuda 5.0 and 5.5 today and changed the nvcc optimization flags for cycles_kernel_cuda. I found out the following: - --opencc-options is deprecated for sm_20 and up and should be removed from compiler options - Stating -O3 and use_fast_math as nvcc options brings massive speedup on my system (more below) - We shouldnt complain about new cuda toolsets that are slow, we should find a solution as we cant use old software forever To the speedups: Example 1: system: i7-3820 @ 3.60GHz, GeForce GTK 660 Blender (cycles_cuda_kernel) compiled with standard settings: Mike_pan file took 02:06.60 to render Blender (cycles_cuda_kernel) compiled with O3 use-fast-math: Mike_pan took 01:39:93 There is no optical difference in the render results: Image1: http://www.pasteall.org/pic/52757 Image2: http://www.pasteall.org/pic/52758 I bet theres more potential in there. /Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] massive cuda speed improvements with Cuda 5.0/5.5
Hi Jurgen, How does this times compare between CUDA 5.0 and 5.5? (is this a speedup from 5.5 but a slowdown in relation with 5.0? or it's an overall speed up ?) -- Dalai 2013/6/3 Jürgen Herrmann shadow...@me.com: Hi there, I did some tests with cuda 5.0 and 5.5 today and changed the nvcc optimization flags for cycles_kernel_cuda. I found out the following: - “--opencc-options “ is deprecated for sm_20 and up and should be removed from compiler options - Stating “-O3” and “—use_fast_math” as nvcc options brings massive speedup on my system (more below) - We shouldn’t complain about new cuda toolsets that are slow, we should find a solution as we can’t use old software forever… To the speedups: Example 1: system: i7-3820 @ 3.60GHz, GeForce GTK 660 Blender (cycles_cuda_kernel) compiled with standard settings: Mike_pan file took 02:06.60 to render Blender (cycles_cuda_kernel) compiled with –O3 –use-fast-math: Mike_pan took 01:39:93 There is no optical difference in the render results: Image1: http://www.pasteall.org/pic/52757 Image2: http://www.pasteall.org/pic/52758 I bet there’s more potential in there. /Jürgen ___ 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] massive cuda speed improvements with Cuda 5.0/5.5
Hi Dalai, I tested 5.5 on a different system I don't have access to this machine right now, I'll deliver the complete benchmark results tomorrow. I plan to compare on as many different configurations with 32 and 64 bit and different cuda versions. This will take some time but I think it's worth it. ;) /Jürgen Am 03.06.2013 um 20:50 schrieb Dalai Felinto dfeli...@gmail.com: Hi Jurgen, How does this times compare between CUDA 5.0 and 5.5? (is this a speedup from 5.5 but a slowdown in relation with 5.0? or it's an overall speed up ?) -- Dalai 2013/6/3 Jürgen Herrmann shadow...@me.com: Hi there, I did some tests with cuda 5.0 and 5.5 today and changed the nvcc optimization flags for cycles_kernel_cuda. I found out the following: - “--opencc-options “ is deprecated for sm_20 and up and should be removed from compiler options - Stating “-O3” and “—use_fast_math” as nvcc options brings massive speedup on my system (more below) - We shouldn’t complain about new cuda toolsets that are slow, we should find a solution as we can’t use old software forever… To the speedups: Example 1: system: i7-3820 @ 3.60GHz, GeForce GTK 660 Blender (cycles_cuda_kernel) compiled with standard settings: Mike_pan file took 02:06.60 to render Blender (cycles_cuda_kernel) compiled with –O3 –use-fast-math: Mike_pan took 01:39:93 There is no optical difference in the render results: Image1: http://www.pasteall.org/pic/52757 Image2: http://www.pasteall.org/pic/52758 I bet there’s more potential in there. /Jürgen ___ 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] platform maintainers: request to update exr lib to 2.0
Hi again, The new OIIO libraries don't make any difference. OIIO depends on OpenEXR and not the other way around. So although that could I can't see how they would change things. I remember when you first uploaded the libraries you forgot a header file (which I'm using in the code). I wonder if it's related and the first release build is buggy. The ideal would be to rebuild OpenEXR for release and hope it fixes the problem. If you don't want to commit the libs without knowing they will fix the problem you can put them on blender.org ftp incoming folder. (or poke me on IRC and we can find a solution). (or checkout the svn code for multiview, it should be easy to reproduce the problem in your windows station) Thanks, Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/6/2 Jürgen Herrmann shadow...@me.com: Hi Dalai, Thomas Dinges asked me to downgrade OIIO to 1.1.11 just today. Please try to do a SVN update on your libs and compile again using these. These problems are strange... I will have a closer look on this tomorrow. /Jürgen Am 02.06.2013 um 20:16 schrieb Dalai Felinto dfeli...@gmail.com: Hi Jurgen, I think the problem is the release library. Even with cmake+msvc the exr sample image fails when I build release. And I just tested with the 1.2 oiio libraries and I still get the same error with scons+msvc debug. Remember that you forgot to include a header in your first commit of the library? I wonder if that was somehow also missing when you built it. I don't know. -- Dalai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi Dalai, I can recompile the libs tomorrow. I'll contact you when I am done. I doubt that this will change anything though. The header that was missing wasn't installed by the CMake build routine it was not missing at compile time. It was just omitted by the install script. But nevertheless I'll try to recompile them for you. Otherwise we should try to report a bug to the OpenEXR devs. It could be an error in the libs. /Jürgen Am 03.06.2013 um 20:58 schrieb Dalai Felinto dfeli...@gmail.com: Hi again, The new OIIO libraries don't make any difference. OIIO depends on OpenEXR and not the other way around. So although that could I can't see how they would change things. I remember when you first uploaded the libraries you forgot a header file (which I'm using in the code). I wonder if it's related and the first release build is buggy. The ideal would be to rebuild OpenEXR for release and hope it fixes the problem. If you don't want to commit the libs without knowing they will fix the problem you can put them on blender.org ftp incoming folder. (or poke me on IRC and we can find a solution). (or checkout the svn code for multiview, it should be easy to reproduce the problem in your windows station) Thanks, Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/6/2 Jürgen Herrmann shadow...@me.com: Hi Dalai, Thomas Dinges asked me to downgrade OIIO to 1.1.11 just today. Please try to do a SVN update on your libs and compile again using these. These problems are strange... I will have a closer look on this tomorrow. /Jürgen Am 02.06.2013 um 20:16 schrieb Dalai Felinto dfeli...@gmail.com: Hi Jurgen, I think the problem is the release library. Even with cmake+msvc the exr sample image fails when I build release. And I just tested with the 1.2 oiio libraries and I still get the same error with scons+msvc debug. Remember that you forgot to include a header in your first commit of the library? I wonder if that was somehow also missing when you built it. I don't know. -- Dalai ___ 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] [PATCH] Fix Build issue on non-x86 arches
Hello,
I have got the following patch from another Fedora developer which should
solve build issues on non-x86 arches.
It may be nice, if anyone have a look on it.
Best Regards:
Jochen Schmitt
diff -up blender-2.67a/intern/cycles/util/util_system.cpp.non-x86
blender-2.67a/intern/cycles/util/util_system.cpp
--- blender-2.67a/intern/cycles/util/util_system.cpp.non-x862013-05-26
14:48:10.0 +0200
+++ blender-2.67a/intern/cycles/util/util_system.cpp2013-05-26
14:48:27.0 +0200
@@ -199,7 +199,12 @@ bool system_cpu_support_sse3()
#else
-bool system_cpu_support_optimized()
+bool system_cpu_support_sse2()
+{
+ return false;
+}
+
+bool system_cpu_support_sse3()
{
return false;
}
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] massive cuda speed improvements with Cuda 5.0/5.5
Thanks for testing. I've also been doing some experimenting with
compile flags and other things here. So far it seems I can make my
650M render a few percentages faster compared to CUDA 4.2, but 460 GT
is still considerably slower with the BMW scene (2m30s with 5.5
compared to 2m01s with 4.2), and 580 GTX had a similar difference. It
seems you are testing with a 6xx card so that makes sense.
Patch attached for those who want to test this with 5.0/5.5.
On Mon, Jun 3, 2013 at 8:46 PM, Jürgen Herrmann shadow...@me.com wrote:
Hi there,
I did some tests with cuda 5.0 and 5.5 today and changed the nvcc
optimization flags for cycles_kernel_cuda.
I found out the following:
- “--opencc-options “ is deprecated for sm_20 and up and should be
removed from compiler options
- Stating “-O3” and “—use_fast_math” as nvcc options brings massive
speedup on my system (more below)
- We shouldn’t complain about new cuda toolsets that are slow, we
should find a solution as we can’t use old software forever…
To the speedups:
Example 1:
system: i7-3820 @ 3.60GHz, GeForce GTK 660
Blender (cycles_cuda_kernel) compiled with standard settings:
Mike_pan file took 02:06.60 to render
Blender (cycles_cuda_kernel) compiled with –O3 –use-fast-math:
Mike_pan took 01:39:93
There is no optical difference in the render results:
Image1: http://www.pasteall.org/pic/52757
Image2: http://www.pasteall.org/pic/52758
I bet there’s more potential in there.
/Jürgen
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
diff --git a/intern/cycles/device/device_cuda.cpp
b/intern/cycles/device/device_cuda.cpp
index f32c6dd..27978b9 100644
--- a/intern/cycles/device/device_cuda.cpp
+++ b/intern/cycles/device/device_cuda.cpp
@@ -46,6 +46,7 @@ public:
mapdevice_ptr, bool tex_interp_map;
int cuDevId;
bool first_error;
+ vectorCUstream cuStreams;
struct PixelMem {
GLuint cuPBO;
@@ -205,6 +206,12 @@ public:
if(cuda_error_(result, cuCtxCreate))
return;
+ const int num_streams = 8;
+ cuStreams.resize(num_streams);
+
+ for(int i = 0; i num_streams; i++)
+ cuStreamCreate(cuStreams[i], 0);
+
cuda_pop_context();
}
@@ -212,6 +219,9 @@ public:
{
task_pool.stop();
+ for(int i = 0; i cuStreams.size(); i++)
+ cuStreamDestroy(cuStreams[i]);
+
cuda_push_context();
cuda_assert(cuCtxDetach(cuContext))
}
@@ -514,7 +524,7 @@ public:
}
}
- void path_trace(RenderTile rtile, int sample)
+ void path_trace(RenderTile rtile, int sample, CUstream stream)
{
if(have_error())
return;
@@ -575,9 +585,9 @@ public:
cuda_assert(cuFuncSetCacheConfig(cuPathTrace,
CU_FUNC_CACHE_PREFER_L1))
cuda_assert(cuFuncSetBlockShape(cuPathTrace, xthreads,
ythreads, 1))
- cuda_assert(cuLaunchGrid(cuPathTrace, xblocks, yblocks))
+ cuda_assert(cuLaunchGridAsync(cuPathTrace, xblocks, yblocks,
stream))
- cuda_assert(cuCtxSynchronize())
+ //cuda_assert(cuCtxSynchronize())
cuda_pop_context();
}
@@ -882,12 +892,35 @@ public:
void thread_run(DeviceTask *task)
{
if(task-type == DeviceTask::PATH_TRACE) {
- RenderTile tile;
+ vectorRenderTile concurrent_tiles(cuStreams.size());
+ vectorbool have_tile(cuStreams.size());
/* keep rendering tiles until done */
- while(task-acquire_tile(this, tile)) {
- int start_sample = tile.start_sample;
- int end_sample = tile.start_sample +
tile.num_samples;
+ while(1) {
+ int start_sample = -1;
+ int end_sample = -1;
+
+ for(int i = 0; i concurrent_tiles.size();
i++) {
+ RenderTile tile = concurrent_tiles[i];
+
+ if(task-acquire_tile(this, tile)) {
+ have_tile[i] = true;
+
+ if(start_sample == -1) {
+ start_sample =
tile.start_sample;
+ end_sample =
tile.start_sample + tile.num_samples;
+ }
+ else {
+
Re: [Bf-committers] [PATCH] Fix crash in rna_access.c
On Tue, Jun 4, 2013 at 3:59 AM, Jochen Schmitt joc...@herr-schmitt.de wrote: On Tue, Jun 04, 2013 at 03:17:14AM +1000, Campbell Barton wrote: Hi, Id like to be able to redo the bug but the I couldn't find a link to the report. Assume this is the bug you meant? https://bugzilla.redhat.com/show_bug.cgi?id=969043 It links to another report - but nothing blender related. The correct link is: https://bugzilla.redhat.com/show_bug.cgi?id=969843 Best Regards: Jochen Schmitt Hi Jochen, I can't redo the crash, from the backtrace I would guess that its a certain button in the interface that triggers the problem, but after going over all buttons window types, French language isn't crashing anywhere. So we really need an example blend file setup which crashes when enabling translations. Also, Id prefer these issues get handled in our bug tracker to avoid noise on the mailing list. -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] massive cuda speed improvements with Cuda 5.0/5.5
Hi Brecht, you're welcome ;) I think I'll have to include these compiler flag optimizations into vs2012 builds otherwise these builds will be significantly slower than other compilers :( Cycles has two problems when it comes to windows/vs2012 builds: 1. It is much slower on CPU 2. It is slower with cuda, if we don't use opt flags. As long as MinGW OpenMP isn't fixed we have to stick to vs2008/cuda 4.2 or find a decent solution for VS2012/Cuda 5.5. As blender seems to be used mostly by windows users this isn't optimal. /Jürgen Am 03.06.2013 um 21:20 schrieb Brecht Van Lommel brechtvanlom...@pandora.be: Thanks for testing. I've also been doing some experimenting with compile flags and other things here. So far it seems I can make my 650M render a few percentages faster compared to CUDA 4.2, but 460 GT is still considerably slower with the BMW scene (2m30s with 5.5 compared to 2m01s with 4.2), and 580 GTX had a similar difference. It seems you are testing with a 6xx card so that makes sense. Patch attached for those who want to test this with 5.0/5.5. On Mon, Jun 3, 2013 at 8:46 PM, Jürgen Herrmann shadow...@me.com wrote: Hi there, I did some tests with cuda 5.0 and 5.5 today and changed the nvcc optimization flags for cycles_kernel_cuda. I found out the following: - “--opencc-options “ is deprecated for sm_20 and up and should be removed from compiler options - Stating “-O3” and “—use_fast_math” as nvcc options brings massive speedup on my system (more below) - We shouldn’t complain about new cuda toolsets that are slow, we should find a solution as we can’t use old software forever… To the speedups: Example 1: system: i7-3820 @ 3.60GHz, GeForce GTK 660 Blender (cycles_cuda_kernel) compiled with standard settings: Mike_pan file took 02:06.60 to render Blender (cycles_cuda_kernel) compiled with –O3 –use-fast-math: Mike_pan took 01:39:93 There is no optical difference in the render results: Image1: http://www.pasteall.org/pic/52757 Image2: http://www.pasteall.org/pic/52758 I bet there’s more potential in there. /Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers cuda_5.5_tests.txt ___ 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] massive cuda speed improvements with Cuda 5.0/5.5
Hi all, As long as MinGW OpenMP isn't fixed it is fixed in http://tdm-gcc.tdragon.net/download ( see openmp download ) and patch to any other MinGW version for gomp library can be found here http://netcologne.dl.sourceforge.net/project/tdm-gcc/Sources/TDM%20Sources/gcc-4.7.1-tdmsrc-1.zip not sure how useful it is, but still - there is a patch which can be applied. Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] massive cuda speed improvements with Cuda 5.0/5.5
Hi Jürgen, Am 03.06.2013 20:46, schrieb Jürgen Herrmann: - “--opencc-options “ is deprecated for sm_20 and up and should be removed from compiler options This option should not be harmful, we just kept it in for sm_1x architecture. Although I am not sure if sm_1x still builds at all, we dropped official support for it with Blender 2.67, so probably can be removed. - Stating “-O3” and “—use_fast_math” as nvcc options brings massive speedup on my system (more below) We cannot use fast math everywhere, I remember that Brecht changed the code to only use fast math functions selectively, to avoid some precision problems. http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=47133 But that could not be valid with Toolkit 5.x anymore, needs further tests. - We shouldn’t complain about new cuda toolsets that are slow, we should find a solution as we can’t use old software forever… True, but still it's sad that an upgrade causes all those problems. :) Thanks for testing! Thomas -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] massive cuda speed improvements with Cuda 5.0/5.5
Hi Brecht, this looks very promising. On my Geforce 540M (Windows x64, driver 320.20) I get those render times with the BMW scene (100 Samples, 128x128 tiles). Vanilla Trunk (Toolkit 4.2): 2.29 minutes Vanilla Trunk (Toolkit 5.5 RC): 3.54 minutes Trunk + patch (Toolkit 5.5 RC): 3.00 minutes So, that is definitely much better. :) Best regards, Thomas Am 03.06.2013 21:20, schrieb Brecht Van Lommel: Thanks for testing. I've also been doing some experimenting with compile flags and other things here. So far it seems I can make my 650M render a few percentages faster compared to CUDA 4.2, but 460 GT is still considerably slower with the BMW scene (2m30s with 5.5 compared to 2m01s with 4.2), and 580 GTX had a similar difference. It seems you are testing with a 6xx card so that makes sense. Patch attached for those who want to test this with 5.0/5.5. -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] massive cuda speed improvements with Cuda 5.0/5.5
hi it is fixed in http://tdm-gcc.tdragon.net/download ( see openmp download ) and patch to any other MinGW version for gomp library can be found here http://netcologne.dl.sourceforge.net/project/tdm-gcc/Sources/TDM%20Sources/gcc-4.7.1-tdmsrc-1.zip can Antony maybe check this and enable openmp correctly and solves the mingw64 problem, this could be the answer guys! Regards Yousef Harfoush ba...@msn.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] massive cuda speed improvements with Cuda 5.0/5.5
hi again i had time so i did some tests with a simple smoke scene: gcc 4.7.1 wingw64 with openmp NOT compiled took 1:46 s gcc 4.7.1 wingw64 with openmp COMPILED crashes gcc 4.7.1 wingw64 with replacing the fixed dlls from the site and openmp COMPILED took 0:25 s it seems the problem has been fixed :) i hope some one DO a full blender regression test. Regards Yousef Harfoush ba...@msn.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] massive cuda speed improvements with Cuda 5.0/5.5
Sounds promising! If that really works we could just drop the whole MSVC stuff and build with mingw ;) Am 04.06.2013 um 04:09 schrieb Yousef Hurfoush ba...@msn.com: hi again i had time so i did some tests with a simple smoke scene: gcc 4.7.1 wingw64 with openmp NOT compiled took 1:46 s gcc 4.7.1 wingw64 with openmp COMPILED crashes gcc 4.7.1 wingw64 with replacing the fixed dlls from the site and openmp COMPILED took 0:25 s it seems the problem has been fixed :) i hope some one DO a full blender regression test. Regards Yousef Harfoush ba...@msn.com ___ 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
