Hi Tom,
To me Brecht didnt mention he'd prefer licensing as BSD. We just
agreed on putting it all under BF copyright, with our standard gpl
headers.
BSD will for sure be more attractive for the industry to copy and use,
but if that gives back useful contributions is quite disputable. For
Hi,
before taking this too much off the ground, wouldn't it be better to
just stick to OpenCL right from the beginning?
I think if this is too much tightened to CUDA from the beginning, we
won't see an OpenCL port afterwards.
I haven't looked at the architecture of cycles yet and to which
Another question is, why not to take an OpenCL renderer which is allready quite
usable and go on from it?
there has been recently a new release of smalluxgpu renderer,
and in the accompanying forum a wish for direct integration into blender was
mentioned.
Hi, @Vilem Novak
Regarding to SLG, it has been developed as a test platform for ported GPU
algorithms to be integrated latter in LuxRender, even now SLG is going to be
a more serious effort, is unclear how it is going to driven, or if it will
keep being a test platform. Besides the orientation of
2011/4/29 Vilem Novak pildano...@post.cz:
Another question is, why not to take an OpenCL renderer which is allready
quite usable and go on from it?
there has been recently a new release of smalluxgpu renderer,
and in the accompanying forum a wish for direct integration into blender was
+1 on both. GPL for render part, BSD for API - is that possible, after
all, all of the other stuff in the code (which will be statically
compiled with the cycles code base) is GPL.. ?
On Fri, Apr 29, 2011 at 5:18 AM, Ton Roosendaal t...@blender.org wrote:
Hi Tom,
To me Brecht didnt mention
Hi,
Brecht designed the system to be transparent for openCL, CUDA and CPU
usage.
OpenCL needs a bit more work, but will be a target to solve asap. :)
-Ton-
Ton Roosendaal Blender Foundation t...@blender.org
Hi,
On 04/28/11 12:28, Brecht Van Lommel wrote:
Actually, anything on this list is open to be implemented by others.
From the point of view of the core engine, if implemented well they
can fit in right away. I guess the first ones go from a couple of days
to a week, once you are familiar with
Hi,
Had meeting with Brecht on this today; the API is currently rna-via-c+
+, similar to python api but much faster. How to make such an API
BSD or define license exceptions for it, I honestly don't know yet.
A working bypass is to just code it via pipe() though, basically only
data has to
make fails in latest OpenSuSE 11.4 with this
[ 31%] Building C object
source/blender/imbuf/CMakeFiles/bf_imbuf.dir/intern/jp2.c.o
/home/zanqdo/Storage/Blender/blender-cycles/blender/source/blender/imbuf/intern/jp2.c:43:22:
fatal error: openjpeg.h: No such file or directory
compilation terminated.
Use ccmake as with it you can set the paths of your includes
On 30/04/11 15:27, Daniel Salazar - 3Developer.com wrote:
make fails in latest OpenSuSE 11.4 with this
[ 31%] Building C object
source/blender/imbuf/CMakeFiles/bf_imbuf.dir/intern/jp2.c.o
11 matches
Mail list logo
