GLSL Question

Hi, I have been googling, searching and reading up on this and found no real answers

  1. In a GLSL shader, I read that swizzling can be slow does that mean using varname.xy is bad always ?
    or is it bad only when its used out of order like varname.xz ?

  2. performance wise is using “varname.xy” the same exact thing as “vec2 ( varname )” ? ( varname being a vec4 )
    Is there any reason to use one way over the other ?

Regards
EL

It’s slow when you use low precision vectors. The exception is .rgb, in the fragment shader. There’s normally no point in using lowp in the vertex shader.

Yes.

Personally, I only use vecn(… as a constructor. The type and parens clutter everything up and don’t even convey meaning. I wish the non-constructor use didn’t exist; can anyone provide an example of when it beats out swizzle notation?

Id just like to add one small extra to Jessy’s excellent advice. Try to avoid any swizzling on UV coords in a fragment shader because it will stop the hardware from being able to pre fetch the texture. At least I believe this is the case for GLES.

It’s not GLES-specific. It is true of PowerVR hardware, though. See page 58.

Thanks for the info !

One more question if you all done mind.

Would this be faster casting to vec 3 and multiplying then back to vec4

gl_FragColor = vec4 ( dcolor * vec3 ( texture2D ( _MainTex, tc ) ), 1.0 );

or would it be more efficient to w/o the conversions , make dcolor a vec4
and just multiply.

gl_FragColor = texture2D ( _MainTex, tc ) * dcolor;

Ive run a few tests and I dont see a noticeable difference in a test apps speed.
and in that PvrUniScoEditor it shows 6 cycles for both ways. Just wondering
if there is some difference or one way is better then the other ?

Depends on the precision. I’m assuming you’re using lowp. lowp operations should be equally fast on 3- or 4-vectors. I’d make the decision based on where dcolor (that variable name could use some work) comes from.

Ive been making dcolor mediump vec3 or vec4, i found using lowp sometimes does not work on a few android devices and model turns purple ( but lowp always seems to work on ios )

Maybe you should duplicate the SubShader and put the one with lowp first. No reason to eat the battery on iOS.

I thought of doing just that, but how would it know one is for IOS and one for Android ? ( because they both should work, but im guessing the android problem is a bug in the gfx drivers )

I already duplicated the Subshader in CG ( so it runs on windows ), i havent tested that yet to see if it picks that one on android, maybe it will

Sure, but if the one that should, doesn’t, then the slow one will, according to your observations.

Does the proper subshader get picked at runtime or compile time ? ( i thought it would be compile time )

How could that happen? Unity doesn’t know what it’s going to be running on.

I mean when you pick build android or build iOS install, it knows then at least the platform ?

Sure, but Android is supposed to be able to run an OpenGL ES 2.0 shader. Unity doesn’t know about every driver bug or broken GPU out there. If something becomes a big problem for a lot of people, I’m sure they’ll put failsafes in, but it’s unlikely that we, writing in GLSL, will be able to take advantage of them.

Thats what i mean, i dont think it would know to pick the right subshader ( one with lowp and one with mediump ), since its a device specific bug and rare and it “should” work.

I’m not following you. Unity tests the subshaders at runtime, and runs the first one that is supported. If it’s solid magenta, that’s Unity’s way of telling you that no subshaders are supported.

Ahh thats the answer i was looking for. sorry for being unclear im still waking up.

Going to test this right now.

EDIT: lowp now works on same device that did not before. wierd