Hi, I have been googling, searching and reading up on this and found no real answers
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 ?
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 ?
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.
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 )
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 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.