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
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
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
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%
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
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
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
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:
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
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
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
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
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
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
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
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
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?
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
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
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,
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
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
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
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
24 matches
Mail list logo
