GLES 2.0 Shader program linking hang and crash

[thegrb93]

I'm not entirely sure if this is the right place, but I've encountered this strange issue I've posted more details here, https://www.raspberrypi.org/forums/viewtopic.php?f=68&t=215384

Seems android might also suffer from this?
https://stackoverflow.com/questions/43740848/after-call-gllinkprogram-the-app-freezes

"I experienced the same issue. The Nexus 7 (2013) was freezing when I called gllinkprogram(). I found that this only happened when I had 'if statements' in my shader. I was able to change both of my 'if statements' into 'conditional operators' and it worked.

E.g. (cond)? cond1:cond2"

Unfortunately his solution won't work for my shader. I was wondering if anyone has any suggestions?

[popcornmix]

What happens if you move the contents of the else clause before the if statement?
It looks like that would behave the same way.
Performance should be the same as shaders don't actually branch (both paths of if/else are processed and the result is conditionally assigned).

[thegrb93]

I tried your suggestion and got the same result, but I think I understand a little better now. I think with the else commented the compiler might be optimizing out code deeper within the shader that could be the actual cause. I'll test some more.

[thegrb93]

Yeah, it was optimizing out the call to Trace which is defined as

float Trace(vec3 ro, vec3 rd)
{
	float t = 0.0;
	float dist = 1.0;
	for (int i=0; i < traceDepth; i++)
	{
		if(abs(dist) < epsilon || t > drawDistance || t < 0.0)
			continue;
		dist = Isosurface(ro+rd*t);
		t = t+dist;
	}

	return t;//vec4(ro+rd*t,dist);
}

when I comment out this call, the if statements work

[thegrb93]

If I replace this function with a random noise function, then I get no issues. So I guess it doesn't like ray marching.

[popcornmix]

What is traceDepth?
Loops in shaders get unrolled and generally fail when size gets too large.
I imagine it would be more likely to work with traceDepth=1 compared to 20.

I've played with a lot of the shadertoy examples and haven't seen any ray marching ones simple enough to work.

Note: The firmware GLES driver is being replaced with the vc4 arm side driver (dtoverlay=vc4-kms-v3d / `dtoverlay=vc4-fkms-v3d``) which may behave better.
But I think you'll struggle to do ray marching expect at lower resolution or low framerate.

[thegrb93]

Yeah I was hoping to do 128x128x2 which I figured would be manageable.

traceDepth was 100 which explains the massive hang.

When I set it to 1, it only hangs for about 100ms but generates glGetError 0x505 at glDrawArrays. I'll test a little bit more to see if I can isolate whatever's causing that error to generate. The gpu should have 256MB of memory though so I can't imagine it running out on this simple program.

[popcornmix]

The shader compiler wasn't really designed for shaders of this complexity. Everything gets inlined and unrolled (so you'll have 100 copies of Isosurface), and typically the register allocation fails on large programs.

I believe the arm side vc4 driver doesn't have this register allocation issue so is more likely to handle larger programs.

[thegrb93]

All right, I'll definitely give that a shot. Thanks for all the helpful suggestions. I'll post the results of that soon.

[thegrb93]

I'm on the latest firmware and I'm sure I set up config.txt correctly, but can't initialize display. I think maybe I need X running. Tried on both the brcm and mesa libraries. Will try with X tomorrow.

With the brcm library, I get
* failed to add service - already in use?
and with mesa library, I get

libEGL warning: DRI3: xcb_connect failed
libEGL warning: DRI2: xcb_connect failed
libEGL warning: DRI2: xcb_connect failed
Failed to initialize EGL display: 3001

[popcornmix]

Yes, you'll need X running and you'll need to link with mesa libs rather than broadcom.
Also you don't need the dispmanx init stuff that was required with the broadcom driver.

[thegrb93]

Thanks. While waking up, I came up with a great idea. Since the geometry and camera will be static, I'll just precompute the depth and normal maps on the cpu and use them on the gpu as textures, that way performance is increased considerably and it hopefully fixes this issue.

If I need more performance or it still has issues, I'll give the new driver a try. Thanks again for all the help.

[thegrb93]

I've started working on it again and saw that there was no way to have floating point textures with the brcm driver, so I switched to mesa and got it working. However I'm still having trouble.

I'm getting GL_INVALID_VALUE with GL_RGBA32F, GL_RGB32F, GL_RGBA16F, GL_RGBA32F

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB32F, position.cols, position.rows, 0, GL_RGB, GL_FLOAT, position.data);

position.cols, position.rows are both 128 so that can't be the issue.

any ideas? I'll try doing the ray marching again instead of this method.

[thegrb93]

I noticed those enums were defined in a block labeled as GL_VERSION_3_0. I guess that's why. Then I guess there's no way to do floats in textures.

[thegrb93]

(Actually I just realized the geometry isn't static after all)
I got the ray marching working now though. The new driver works. Thanks!

[thegrb93]

Also I just found HALF_FLOAT_OES which I think I can use, but oh well the geometry isn't static.