Branchless sky shader

[Jasper-Bekkers]

Right now this shader doesn't compile because it outputs a lot of error: OpCopyMemorySized (memcpy) without OpCapability Addresses and error: static_addr_of. However, this shader is a relatively complex workload that looks nice and doesn't have any branching in it, so it could be a nice show-case for the project.

Source: https://github.com/Tw1ddle/Sky-Shader/blob/master/src/shaders/glsl/sky.fragment

[repi]

cool!

[khyperia]

Changing

1. Vec3 to #[repr(simd)]
2. a few hacky bugfixes

gives... whatever this is supposed to be! \o/

[repi]

Maybe starting to become a red dawn on Mars? so a very specific sky shader :)

[Jasper-Bekkers]

Alright, it should look different but I hacked in an up and view vector so it probably looks wrong.

What does #[repr(simd)] do in this case?

[Jasper-Bekkers]

Actually - I think the sky function here may just be returning zero; I was outputting part of the vertex color still.

[khyperia]

What does #[repr(simd)] do in this case?

Hacky way to avoid the memcpys - vectors apparently use a different mechanism to copy than structs.

I probably won't get to implementing all those bugfixes properly before we opensource - some of them are kind of in-depth. Maybe if I high-priority it, but, there's a lot of other things on my plate.

Also yeah, I tried playing around with input values and whatnot, but couldn't get anything other than pure white output and pure black output.

[Jasper-Bekkers]

[khyperia]

I'd like this to either be a pristine example if we're going to put it as the main item in examples/example-shader, or it to be a second example. If it's the main item, I'd like all the vector/helper stuff to be in spirv-std (ideally with the same ops defined on f32x4, etc.), and some thought put into the design of the library. Seeing all this boilerplate as a first user experience isn't a great first impression.

The actual mathy bits/implementation look fine, though!

[khyperia]

I don't think it should be the final implementation

yeah, needs some work, but it's decent for a first hack-together!

implement pow and a few others on f32 directly

could do an extension trait, right?

[khyperia]

why repr(C) for all of these? why not repr(simd)?

[Jasper-Bekkers]

Was like this in glam - not sure if it matters much?

[khyperia]

it does indeed matter, repr(rust) or repr(c) gets translated to OpTypeStruct, repr(simd) gets translated to OpTypeVector and we really want to do that, right? (all the discussions around nvidia load/store perf and whatnot)

[Jasper-Bekkers]

Ah right, yeah I figured it'd be fine for now since our final store needs to happen through a f32x4 anyway, which is repr(simd). Let me take a look at a few of these, it might be nicer to remove the repr(C) indeed.

[Jasper-Bekkers]

could do an extension trait, right?

Oh of course. Hold on.

[khyperia]

FYI, filed #81 after seeing the horror that is acos_approx.

[repi]

Nice looks good! Will try and run locally also and poke at some more, but think we can get this in.

Added tiny suggestion

[Jasper-Bekkers]

FYI, filed #81 after seeing the horror that is acos_approx.

These kind of approximations are fairly common in graphics so it might be nice to have a crate later on with a bunch of these, or add them as _approx functions (potentially unsafe) to our std. However getting all of the GLExt builtins would be really nice.