Crash rendering with OSL #42210

New Issue

Shane Ambler · 2014-10-13T19:24:46+02:00

Shane Ambler commented

2014-10-13 19:24:46 +02:00

Changes to the ShaderClosure struct have bitten again, refer to previous bug #41123

I am now running FreeBSD 10.1 RC2, the same crash happens on 9.3 (only 64 bit tested)

To fix I applied the following

diff --git a/intern/cycles/kernel/kernel_types.h b/intern/cycles/kernel/kernel_types.h
index ca1210f..637d024 100644
--- a/intern/cycles/kernel/kernel_types.h
+++ b/intern/cycles/kernel/kernel_types.h
@@ -553,7 +553,7 @@ typedef enum AttributeStandard {
 typedef struct ShaderClosure {
 	ClosureType type;
 	float3 weight;
-#ifndef __APPLE__
+#if !defined(__APPLE__) && !defined(__FreeBSD__)
 	float sample_weight;
 #endif
 	float data0;
@@ -562,7 +562,7 @@ typedef struct ShaderClosure {
 
 	float3 N;
 	float3 T;
-#ifdef __APPLE__
+#if defined(__APPLE__) || defined(__FreeBSD__)
 	float sample_weight;
 - endif
 - ifdef __OSL__

Does the location of sample_weight need to vary based on platform? or can all be the same.

For reference I am compiling blender (and almost everything) with clang 3.4.1, I have not had any luck building blender with OSL if most dependencies are built using gcc.

Changes to the ShaderClosure struct have bitten again, refer to previous bug #41123 I am now running FreeBSD 10.1 RC2, the same crash happens on 9.3 (only 64 bit tested) To fix I applied the following ``` diff --git a/intern/cycles/kernel/kernel_types.h b/intern/cycles/kernel/kernel_types.h index ca1210f..637d024 100644 --- a/intern/cycles/kernel/kernel_types.h +++ b/intern/cycles/kernel/kernel_types.h @@ -553,7 +553,7 @@ typedef enum AttributeStandard { typedef struct ShaderClosure { ClosureType type; float3 weight; -#ifndef __APPLE__ +#if !defined(__APPLE__) && !defined(__FreeBSD__) float sample_weight; #endif float data0; @@ -562,7 +562,7 @@ typedef struct ShaderClosure { float3 N; float3 T; -#ifdef __APPLE__ +#if defined(__APPLE__) || defined(__FreeBSD__) float sample_weight; - endif - ifdef __OSL__ ``` Does the location of sample_weight need to vary based on platform? or can all be the same. For reference I am compiling blender (and almost everything) with clang 3.4.1, I have not had any luck building blender with OSL if most dependencies are built using gcc.

Shane Ambler commented

2014-10-13 19:24:46 +02:00

Changed status to: 'Open'

jens verwiebe was assigned by Shane Ambler

2014-10-13 19:24:46 +02:00

Shane Ambler commented

2014-10-13 19:24:46 +02:00

Added subscriber: @sambler

jens verwiebe was unassigned by Sergey Sharybin

2014-10-14 09:41:35 +02:00

Sergey Sharybin self-assigned this 2014-10-14 09:41:35 +02:00

Sergey Sharybin commented

2014-10-14 09:41:35 +02:00

Added subscriber: @jensverwiebe

Sergey Sharybin commented

2014-10-14 09:41:35 +02:00

This issue requires much deeper investigation. I don't want the code to become more hairy in here, it's something wrong with wither alignment in cycles side and it might be some bugs in osl side as well.

Sergey Sharybin commented

2014-11-03 09:49:03 +01:00

Ok, so now we know what's happening here. All that structure re-alignment are just red-herrings, doesn't fix anything and a dead-end to go for sure.

What's happening in fact is that CBSDFClosure and it's derivative classes uses ShaderClosure structure. Members of this structures are expected to be 16 bytes aligned when building kernel with SSE2 and above. What OSL does is it allocates the closures in a pool, totally ignoring alignment flags.

This makes some compiler assumptions to be wrong (i.e. for me it uses sse2 intrinsics to copy sc.N when flattening the graph. For sure this might easily lead to nasty crashes.

Proper solution would be to make sure our closure classes are 16 bytes aligned. This we can't do from our side, so i've send a pull-request to OSL folks: https://github.com/imageworks/OpenShadingLanguage/pull/428

Ok, so now we know what's happening here. All that structure re-alignment are just red-herrings, doesn't fix anything and a dead-end to go for sure. What's happening in fact is that `CBSDFClosure` and it's derivative classes uses `ShaderClosure` structure. Members of this structures are expected to be 16 bytes aligned when building kernel with SSE2 and above. What OSL does is it allocates the closures in a pool, totally ignoring alignment flags. This makes some compiler assumptions to be wrong (i.e. for me it uses sse2 intrinsics to copy `sc.N` when flattening the graph. For sure this might easily lead to nasty crashes. Proper solution would be to make sure our closure classes are 16 bytes aligned. This we can't do from our side, so i've send a pull-request to OSL folks: https://github.com/imageworks/OpenShadingLanguage/pull/428

Sergey Sharybin commented

2014-12-03 16:53:02 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2014-12-03 16:53:02 +01:00

Sergey Sharybin commented

2014-12-03 16:53:02 +01:00

I've committed a proper fix at 4cb0e25, the issue now should be gone.

Thanks for the report, closing it now.

I've committed a proper fix at 4cb0e25, the issue now should be gone. Thanks for the report, closing it now.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Crash rendering with OSL #42210