Shader unsupported

Unity Engine
1

Hi,
Is there other way to write this for OpenGL ES 1.1?

This doesn’t work with ES 1.1:

Pass {
Blend SrcAlpha OneMinusSrcAlpha, One One
		Color[_Color]
		SetTexture [_MainTex]{ combine primary * texture}
		
	}
}

This works but it’s slow:

GrabPass { }
		Pass {

			SetTexture [_MainTex] {
			constantColor[_Color]
				combine texture * constant
			}
			SetTexture[_GrabTexture] {
			combine previous lerp(previous) texture, previous + texture
			}
		
		}

Thanks.

Doop:
http://forum.unity3d.com/threads/103646-Shader-not-working-on-iOS

2

It has worked fine for me. Did you change the buffer setting? (OpenGL ES 1.1 vs. 2.0 shouldn’t make any difference, though.)
http://answers.unity3d.com/questions/44333/what-shader-blending-modes-dont-work-on-ios.html

3

Thanks for reply.
I tried to change buffer settings and it doesn’t work. I am rendering to a rendertexture (which is RGBA8) so buffer shouldn’t be a problem.
When I switch to ES 2.0 it’s fine, it only doesn’t work with 1.1.
It works in editor with MBXlite simulation, but not on device.

4

What is the “, One One” in “Blend SrcAlpha OneMinusSrcAlpha, One One”? Is this a separate blend equation for the alpha component? (Is this officially documented anywhere?) If it is, you would need the possibility to specify a separate blend equation for the alpha component. This might or might not be supported by your OpenGL ES 1.1 hardware. (I’m not sure what the standard requires but I assume it only requires support for one single blend equation for colors and alpha.)

5

Yes, it is like when you use combine with seperate alpha. I think for combine it’s documented, but for blend not (I learned it from some sheder I found on the Internet).

6

Does the shader work without it? I.e. if you use: “Blend SrcAlpha OneMinusSrcAlpha” instead of “Blend SrcAlpha OneMinusSrcAlpha, One One”?

7

It works, but it doesn’t have the effect I’m trying to achive.

I am using rendertexture without clearing for a painting program and I need to render brush texture on it, but it makes rendertexture transparent with normal blending:
Blend SrcAlpha OneMinusSrcAlpha

So I need to use additive blending for alpha:
Blend SrcAlpha OneMinusSrcAlpha, One One

8

Thus, the problem might be that your hardware doesn’t support a separate blend equation for the alpha component. What about two passes with appropriate color masks to simulate it? I guess something like this:

Pass {
   ColorMask RGB
   Blend SrcAlpha OneMinusSrcAlpha
   Color[_Color]
   SetTexture [_MainTex] { combine primary * texture }
}
Pass {
   ColorMask A
   Blend One One
   Color[_Color]
   SetTexture [_MainTex] { combine primary * texture }
}
9

As long as you use a render texture, you will not get rid of “but its slow” anyway if you really run on OpenGL ES 1.1 hardware, because such hardware is always significantly capped and with you wasting a full render pass into a render texture (or at worst more than one) you are not getting away with lots of “remaining frames” anymore

Unsure what you intend to achieve in detail but if you can, generate a fallback shader that does not generate anything but has prebaked textures for OES 1.1

10

According to ANIV, we are talking about an additional full render pass for something like a brush sprite. Thus, I don’t think there is going to be any noticable effect on performance (unless we are talking about really large brushes, say screen-filling).

I am not sure what you mean by “waste”: I think you can use the verb “waste” only if my suggestion included unnecessary operations. But you didn’t present a working equivalent alternative; thus, I don’t think you are using the verb correctly.

11

Going by your definition its not used correctly.

But I used it more in the context of “we are talking about OES 1.1 here and as nothing else was stated I assumed that the target were fluent framerates, a thing multipass renders will relatively fast prevent from happening at all, especially when Android is included too” (I explicitely mention android cause there are a plentitude of Android OES 1.1 devices that have GPUs that are not even remotely comparable to the iOS 1st and 2nd gen OES 1.1 hardware performance wise) where I consider waste correct as in “wasted GPU cycles”

You are correct that I didn’t provide an equivalent to it, but thats more cause we are talking about DX7 class hardware here (and worse if Android is included) and the reasonable solution is, as little as I like it, “forget it and only do it on OpenGL ES 2.0 with a fake fallback replacement for OES 1.1 hardware”, cause multi pass and grab pass is definitely none (we are after all talking about GPUs here that are happy to have 2 texture units, they are nowhere as fancy and sophisticated as the 8 Texture Unit DX7 cards and alike you might have done FFP programming on in the past …)

12

Well, I’m no longer sure but I thought ANIV was using the grab only because ANIV couldn’t get the separate alpha blending to work. Without the grab the performance appeared to be fine. Thus, - at least for small brushes - the solution I proposed above would avoid the grab pass and only require an additional render pass for the brush. I think this kind of multipass rendering shouldn’t be a big problem (for small brushes). But maybe we should just wait for ANIV’s result. :slight_smile:

13

Thanks Martin,
Yes, I was using grab just for separate alpha and ColorMask is what I was looking for. I tested it on a device it runs at 60 fps (grab pass had 2 fps).

14

Great. :slight_smile:

15

No, it’s not documented yet. Previously, I’ve only seen it talked about here, and the link I gave above.

I haven’t tested with an iPad 2. Otherwise, there are only two GPUs in use in iOS, I tested with both of them, and they both work fine with it. As such, I don’t understand what ANIV is saying. If your shader worked for him, then his original would, only faster. Unless this is an Android/“mobile” thread, in which case I’m out of my element. I thought Unity only supported OpenGL ES 2.0 Android devices, though?

16

It is iOS program.
When I use my original shader I get “Unsupported: Graffiti” in xcode log and purple textures on screen.
Here is full code:

Shader "Custom/Graffiti" {
	Properties {
	_MainTex ("Particle Texture", 2D) = "white" {}
	_Color ("Main Color", COLOR) = (1,1,1,1)
	}
	
	SubShader {
	Pass {
		Blend SrcAlpha OneMinusSrcAlpha, One One
		Color[_Color]
		SetTexture [_MainTex]{ combine primary * texture}
			
		}
	}
}

Target platform is armv6 (OpenGL ES 1.1)
SDK Version: iOS latest
Target iOS Version: 3.1.3
I tested it on iPhone 1 and iPhone 4.

Do you use same code and settings?

It works when i delete “, One One”.

17

Unhappily the seperate alpha blending ops there fall under the “optional extensions” for OpenGL ES 1.1 (OpenGL ES Overview - The Khronos Group Inc) as such its a no go unless the platform implements it and the unity export has limitations of the platform up to date.

I’ve not been able to find any lead that the SGX530 (the OES 1.1 hardware in the first 2 generations of iOS) supports it so I assume that Unity will not allow it for iOS at all under ARMV6 constraints. Unsure if switching to ARMV6+ARMV7 with disabled OES 2.0 define changes anything but I would assume yes as the OES 1.1 support on ARMV7 devices has a few anomalies as its no real hardware OES 1.1

18

I tested again. I’m sorry to say that either Unity Tech or Apple has gimped this for you, sometime since January. I tested extensively in order to make that Unity Answers post. I assure you that the messages are lies. There are unsupported blend modes, but none of them are alpha-specific, as I outlined. I don’t know who authors the error messages. Who is responsible? I assume UT, considering the magenta.

I’d like to investigate the bug I logged about blending modes, 389595, to see if UT maybe said, “screw it, we’ll just disable everything but the most common ones”, but I can’t access fogbugz presently. Can any of you?

19

I just had a look into my paper copy of the “OpenGL ES Programming Guide for iPhone OS” by Apple (date: 2010-06-14; a newer version is probably available by Apple). We are talking about the optional extension “GL_OES_blend_func_separate” to OpenGL ES 1.1 (OpenGL ES 2.0 has this functionality built-in). According to my copy of that guide, that optional extension is supported with:

OpenGL ES 1.1 on PowerVR SGX
OpenGL ES 1.1 on the simulator

but it is not supported with

OpenGL ES 1.1 on PowerVR MBX

Thus, you have to actually test it on a device with a PowerVR MBX GPU(!), otherwise (i.e. in the simulator or on a PowerVR SGX GPU running OpenGL ES 1.1) it will be supported.

Maybe that clarifies the issue.

(By the way, I assume that Unity just asks the OpenGL driver whether the extension is available.)

20

I just tested on my 3GS and got magenta meshes with errors about lack of support. With the same project and settings, I got no such errors, in January, running in both OpenGL versions, with the MBXLite (iPod touch 2G) and SGX. ANIV and I concur that it’s not hardware-related, because the SGX devices, under 1.1, are not rendering correctly, whereas the document you found says they should. That document also lists lack of support on the MBXLite, though, which I recall as being untrue, though of course that’s fallible human memory. Regardless, someone is artificially gimping this.