The latest Unity 5.1 RC and compute shaders

I dont know if im the only problem having this issue but anything using compute shaders and the new RC is pretty broken, as in the pink sheen of death or crashes the editor or just doesnt do anything. Am I the only one having this problem?

Sorry if repeat post, i did use search

 

Maybe it be better make a post in the BETA section of the forum, so the 5.1 team can have a look.
A screenshot would be helpful also.

 

I'm also having some problems with the new compute shader compiler, my complex shaders with many kernels take longer to compile or do not compile at all, and the inspector UI is removed, only the "compiled code" option is visible....why? I will try to split up my kernels and hope it will work then, however that is not optimal, because I have my dependency-functions, which I now have to copy to each separate compute shader.

 

I'm getting the following error messages, and I'm not sure how to solve it, because the same compute shader was working in unity 5.0:


help!?

 

Is there something needing adding to the shader code now that compute shaders can be viewed in edit mode?

 

ok, I think I found the issue:

[numthreads(128,1,1)]
void WritePrimitivesToVolume(uint3 id : SV_DispatchThreadID)
{

uint numStructs, stride;
primitiveBuffer.GetDimensions(numStructs,stride);
if(id.x < numStructs){

volume3dRW[id] = 1;​

}​

}

^This is not working anymore in unity5.1 (in unity5.0 it worked), my workaround looks like this:

uint primitiveBufferCount;

[numthreads(128,1,1)]
void WritePrimitivesToVolume(uint3 id : SV_DispatchThreadID)
{

if(id.x < primitiveBufferCount){

volume3dRW[id] = 1;​

}​

}

 

I also had a more complex shader with a for-loop and "continue;", which didn't compile, it just takes forever and than it gets a timeout error (see the screenshot above).
For now I will go back to unity5.0, I hope the unity team will improve the shader compiler or at least bring it back to the same level as before...I think the main problem is, that it tries to compile it for gles3 too... it would be great if I could exclude gles3 from the compiling process! (as we can do with the cg shaders)
Cheers!

Edit: I will try out #pragma exclude_renderers glcore , hope that also works with compute shaders.
Edit: No, it's not working.... Shader warning in 'ClusterDualContouringCS.compute': 'exclude_renderers' : unknown pragma ignored at line 25 (on )

 

Having the exact same issues with Unity 5.1.1
The compute shader compiler just does not finish compiling. In 5.0.2 it took maybe 3 minutes, now it does not finish after 20 minutes.. Good point CKahler with the loop! I have pretty complex kernels with many loops (partly unrolled). I will go back to Unity 5.0, too, since it does not seem like there is a quick fix for this.

 

@hicks: thanks for testing it with Unity 5.1.1 !
I hope there will be some feedback from a dev about this issue soon, because if they will keep the shader compiler like this, I can't continue my project with new versions/features...

 

@CKahler yeah, me too! I would really like to use the new DrawProceduralIndirect comand buffer..

 

There is an issue tracker thread that might help us, that the problems with the compute shader compiler will be fixed:
http://issuetracker.unity3d.com/iss...te-shader-fails-to-import-and-crashes-5-dot-1

So please vote!

 

"Fixed in future release". Looking forward to it! Would be interesting to know in which release.

 

5.1.1patch2 just came out, so check it

 

Not fixed for me. The issue is said to be fixed in the release notes of the latest patch (http://unity3d.com/unity/qa/patch-releases?version=5.1) but it still hangs on complex shaders!

Added well-known console output.. Again, in Unity 5.0.3 everything's working fine!

It shows exactly the same behaviour as before. In the release notes, it says that they increased the timeout for the compiler. This is not the problem here! The compiler seems to be trapped somewhere because I don't see changes in the process resources. After a few minutes, it stays at 13% CPU usage (1 of 8 cores) and a few hundred MB of RAM. Those numbers will be fixed forever (hours) until you stop the process or close Unity. During normal compilation work, those numbers are constantly changing. For me, it seems like the compiler is trapped in a loop or something...

 

For me it worked! All in all, I'm happy with the new released patch and it's running faster than before! Thanks unity devs for being so quick!
@ Hicks: maybe we can help you when you post some parts of your code?

 

@CKahler thanks, but I don't really want to publish much code right now because I am writing my master thesis about this.
Are you using many kernels in one compute shader? Are you using the unroll command? I have 4 nested for-loops with [unroll(3)] and [unroll(4)]. It's looping through neighbors in kind of a flat 3D texture and 4 channels. Maybe I could optimize this algorithm but it's still very experimental so I wanted to go the straightforward way first. :/

 

Did you try to comment out the unrolls?
(It takes much longer to compile if everything has to be unrolled, often unrolls not really help at all with the performance.)
I used many kernels, but I now have split them up, because the profiler only shows the names of the compute shader name, but when it's split up you can profile each kernel. However, I don't think that's the reason for your problem, I think the loops or some buffer read might cause the problem (sometimes saving buffers to local groupshared variables helps). You should really comment out parts of your shader that might cause the compiler errors and then try to rewrite or split them up...when you send your compute shader in as a bug report, the devs might help you with it. (I don't think they will copy your code or make it public)

 

@CKahler thank you, I will try that sometime soon. I don't want to waste too much time to adjust my code for Unity, when it was working correctly with a previous version. I already submitted it with a bug report about a week ago. No answer yet :/
By the way, how do you profile it? Unity Profiler only shows the API call, except you call GetData right after Dispatch.

 

When you select the GPU part in the top of the profiler you can select the function that runs the dispatch functions and see on the right side the ms of each compute shader. (That's what I meant)... I also read that it is possible to debug shaders via visual studio + some plugin, but never tried, I'm also not sure if it's compute shaders or only cg shaders... I have to investigate that further at some point. Cheers!

 

Oh wow.. I'm feeling super stupid right now.. I just tested it on a second machine again with the newest patch release (5.1.2p1). It still does not compile with the same error messages..
BUT I obviously never tried just pressing play and see what happens. Turns out it works for my target platform (Windows with DX11) in spite of those errors!

I noticed the new variants in the inspector when selecting a compute shader with the inspector in debug mode. In Unity 5.0 there was just one variant (target renderer 2, target level 0). In Unity 5.1 there were four variants for a working compute shader (like when creating a new one) and only two with my failing CS. I guess the compiler fails during the second (target renderer 18, target level 0) or third (target renderer 17, target level 12) compilation. But it seems like the first one (probably Win DX11) works! So only the new platforms (probably due to OpenGL translation) are failing.

So, Unity, please add some options to manually define the target platforms we want our compute shaders compiled for.

 

@hicks I have exactly the same problem and I keep developing on a 5.0 version only for that reason. The major problem is that it take ages to compile a single shader (like 10-15 minutes sometimes) just to tell me that it has internal error communicating with the compute shader. I've already reported a bug since some weeks now, but nobody's looking at it so far. My application is albeit unable to run with theses errors, even if I'm just trying to run it with windows/DX11 profile.
I've also seen your question about the active profiles, which really make sense here ... do you have a workaround for this, or are you still stuck with the problem?