All posts related to V3
By dvhouw
#375736
Thank you man!
Running the maxwell.exe -opencl:off command lets me start up maxwell without problems.
Without -opencl:off it crashes.

Now I disabled the fast multilight preview and maxwell works like before.

So what was causing this problems, my graphics cards then?
User avatar
By Brany
#375742
It seems that your graphics card is the problem. It's hard to say because we can't test your graphics card here :P

I tried maxwell over 3 graphics cards, and all of them gave me different behaviours and issues :(. Maybe OpenCL needs a couple more years to be an actual standard.
Last edited by Brany on Mon Dec 30, 2013 11:24 am, edited 1 time in total.
User avatar
By Rafal SLEK
#375931
Same here. MBP 2.53GHz from 2010, NVIDIA GeForce GT 330M 512MB.
There is no "crash" but "freeze". I've tried it several times and had to restart computer.
By balt
#377158
Hi guys,

just upgraded and was hoping to use the fast multi light on my 2013 MacBook pro, but Maxwell freezes for a long time, and even longer time then nothing happens when I enable it. Here's the output from the console. Does that mean it's just too slow to be useable on that machine? Or is there some bug in the OpenCL 1.1 implementation perhaps?

GPU available: GeForce GT 650M (OpenCL 1.1)
===================== New session opened at 25/January/2014 18:56:48 =====

MAXWELL RENDER (M~R). Engine version 3.0.0.0
(C) 2004-2013. Licensed to Next Limit Technologies

/Applications/Maxwell 3/Maxwell.app/Contents/MacOS/maxwell -mxs:/Users/balt/Documents/3D_local/NNG/rb-neue-nationalgalerie-v01-02_tmp.mxs -display -o:/Users/balt/Documents/3D_local/NNG/rb-neue-nationalgalerie-v01-02.png -p:low

--------------------------------------------------------------------------
LICENSE INFO
License found in standard license path : /Users/balt/Maxwell/maxwell_license.lic
License type: FULL SUITE
License name: Balthasar Indermuehle
Company: Balthasar Indermuehle
Expiration date: permanent
Issued by: NEXTLIMIT
License checked out from server ID: 192.168.0.8

--------------------------------------------------------------------------
SYSTEM INFO
Num processors: ( logical: 8, physical: 8 )
Maxwell Root folder :/Applications/Maxwell 3
Host ID: 28cfe917135b
Low Priority Enabled

--------------------------------------------------------------------------
Found 5 procedural extensions in /Applications/Maxwell 3/extensions
MaxwellHair
MaxwellParticles
MaxwellVolumetric
MGrassH
MGrassP
Found 5 geometry loader extensions in /Applications/Maxwell 3/extensions
MaxwellMesher
MaxwellSea
MWObjectAlembic
RFMeshes
RWMeshes
Found 4 geometry modifier extensions in /Applications/Maxwell 3/extensions
MaxwellCloner
MaxwellGrass
MaxwellScatter
SubdivisionModifier
Found 10 texture extensions in /Applications/Maxwell 3/extensions
Brick
Checker
Circle
Gradient3
Gradient
Grid
Marble
Noise
Voronoi
WireframeTexture
Found 7 material modifier extensions in /Applications/Maxwell 3/extensions
AGS
Opaque
Transparent
Metal
Translucent
Car Paint
Hair
--------------------------------------------------------------------------


[25/January/2014 18:56:48] Reading MXS:/Users/balt/Documents/3D_local/NNG/rb-neue-nationalgalerie-v01-02_tmp.mxs
[25/January/2014 18:56:48] MXS file read successfully

CPU ID used: 14922

[25/January/2014 18:56:48] Checking scene dependencies..
[25/January/2014 18:56:48] Dependency found: textures/concrete-09_s050-g010.jpg
[25/January/2014 18:56:48] Dependency found: textures/concrete-09_b005.jpg
[25/January/2014 18:56:48] Dependency found: textures/concrete-09_d100.jpg
[25/January/2014 18:56:48] Dependency found: textures/granite001.jpg
[25/January/2014 18:56:48] Dependency found: textures/number-50.jpg
[25/January/2014 18:56:48] Dependency found: textures/Water_Pool.jpg
[25/January/2014 18:56:48] Dependency found: textures/Google Earth Snapshot.jpg
[25/January/2014 18:56:48] Dependency found: textures/FloorsPortuguese0042_2_S.jpg
[25/January/2014 18:56:48] Dependency found: textures/tinos001.jpg
[25/January/2014 18:56:48] Dependency found: textures/2012-06-04_1519.png
[25/January/2014 18:56:48] Dependency found: textures/1846 Low Sun Nice Clouds.hdr
[25/January/2014 18:56:48] Checking Data
[25/January/2014 18:56:48] Loading Bitmaps & Preprocessing Data
DEBUG: - Preprocessing data.
DEBUG: - Preprocessing scene modifiers.
DEBUG: - Loading geometry extensions.
DEBUG: - Preprocessing MXS references.
DEBUG: - Pretessellating meshes with displacement.
DEBUG: - Initializing data.
DEBUG: - Preprocessing geometry.
DEBUG: - Preprocessing materials.
DEBUG: - Preprocessing additional parameters.
DEBUG: - Initializing render engine.
DEBUG: - Initializing multilight data.
DEBUG: - Multilight enabled.
[25/January/2014 18:56:52] Starting voxelization.

Scene Info:
Image output: /Users/balt/Documents/3D_local/NNG/rb-neue-nationalgalerie-v01-02.png
MXI output: /Users/balt/Documents/3D_local/NNG/rb-neue-nationalgalerie-v01-02.mxi

Geometry:
- Num Objects: 6037
- Num Meshes: 3285
- Num Triangles: 225706
- Num Vertexes: 124241
- Num Normals: 27235
- Num Materials: 31

Camera: Scene 8

Render settings:

- Engine version : 3.0.0.0
- Using RS1 engine
- Desired rendering time : 9999
- Desired sampling level : 25.000000
- Using 8 threads
- Multilight type: Intensity
- Save lights in separate files:No
- Motion blur: enabled
- Displacement: enabled
- Dispersion: enabled
- Illumination layers:
. . direct layer: true
. . indirect layer: true
. . direct caustic reflection layer: true
. . direct caustic refraction layer: true
. . indirect caustic reflection layer: true
. . indirect caustic refraction layer: true

[25/January/2014 18:56:52] Start Voxelization
[25/January/2014 18:56:53] End Voxelization
[25/January/2014 18:56:53] Voxelization done.
[25/January/2014 18:56:53] Start Rendering

Start writing MXI file...
End writing MXI file...
[25/January/2014 18:56:57] MXI successfully renamed.
By balt
#377248
Apparently my "highest end" Macbook Pro only features a ridiculous 1GB of VRAM. Not surprising it doesn't have enough space.

Still, a graceful fail instead of maxwell crashing would be more appropriate. How about you check if the scene fits in the available VRAM, and if it doesn't, say something to the effect of "Your video card sucks, get a real computer and call again"...

Cheers

- Balt
User avatar
By Brany
#377253
There are two problems here:
- We can't know the amount of GPU memory available (maybe the total memory, but not the MB unused), so we can't anticipate a memory request bigger than the GPU memory available.
- In theory, when you request memory to the GPU, and there is no memory enough available, OpenCL returns an error so we can control it and return a message to the user, but some graphics cards doesn't handle this well and just crash the application instead of return and error, some cards even starts to show garbage on the screen and you must restart your computer. Unfortunately this is out of our control :(
By balt
#377256
Hi Brany,

Are you saying that the (very fundamental) clCreateBuffer call is buggy on some platforms? I very much doubt that, this is a fundamental memory allocation call in OpenCL. As per the OpenCL programming paradigm, you need to know how much space you need before you allocate it… hence any call to clCreateBuffer will return an error if there's not enough space. So unlike my first suggestion where you check "is it gonna fit", you can just keep allocating memory, but then if it fails, you should get back to the user stating that it failed during clCreateBuffer (or whatever allocation call you're using).

Don't get me wrong, I'm not criticising your programmers, OpenCL is very tricky stuff to be working with, especially if you're propping it on top of an application that was not originally built to support it. I'm empathising… :-)

Cheers

- Balt
User avatar
By Brany
#377259
balt wrote:hence any call to clCreateBuffer will return an error if there's not enough space. So unlike my first suggestion where you check "is it gonna fit", you can just keep allocating memory, but then if it fails, you should get back to the user stating that it failed during clCreateBuffer (or whatever allocation call you're using).
That was my first thought, but it's not so easy. clCreateBuffer only creates the buffer object, not allocates the actual buffer memory you requested. http://stackoverflow.com/questions/1690 ... on-failure:

"clCreateBuffer will not actually create a buffer on the device. This makes sense, since at the time of creation the driver does not know which device will use the buffer (recall that a context can have multiple devices). The buffer will be created on the actual device when you enqueue a write or when you launch a kernel that takes the buffer as a parameter."

If clCreateBuffer returns CL_MEM_OBJECT_ALLOCATION_FAILURE, it means that it is not enough memory to create the object itself, not the buffer, because the buffer will be allocated later.

The actual opencl calls that fails when there is not enough memory running fast multilight are clEnqueueNDRangeKernel and clEnqueueWriteBuffer. The problem, as I said, is that with some cards I get an error code from that opencl calls, as I expected, so I can stop fast multilight preview and show some error info to the user, but other cards just crash or starts going crazy. OpenCL is very tricky, and the differences between AMD/NVIDIA/INTEL and WIN/LINUX/OSX implementations are desperating :P

ok thanks for explaining. actually I do copy the T[…]

Sketchup 2026 Released

Fernando wrote: " Now that Maxwell for Cinema[…]

Hello Gaspare, I could test the plugin on Rhino 8[…]

Hello Blanchett, I could reproduce the problem he[…]