00:10 <bloom> Taking a peak at fsin/fcos

00:10 <bloom> Observation 1: the asm of fcos is identical to fsin, except the first instruction

00:10 <bloom> 8: ba05c0021810 fmadd $r1, r0.discard, u0, 0.25

00:10 <bloom> vs

00:10 <bloom> fadd r1, r0, u0

00:10 <bloom> *fmul

00:10 <bloom> This corresponds to the trig identity cos(x) = sin(x + pi/2) = sin(x + tau/4), so we expect that u0 = 2pi = tau

00:14 <bloom> er, no, we want the reciprocal of that. units are hard

00:14 <bloom> anyway, sure enough checking the memory dump u0 = 0x3E22F983, and

00:14 <bloom> struct.unpack('f', bytes([0x83, 0xF9, 0x22, 0x3E])) = 0.15915493667125702

00:14 <bloom> 1.0 / math.tau = 0.15915494309189535

00:15 <bloom> So the first thing we do in either sin or cos is divide by tau to change from radians to "times around the circle"

00:15 <bloom> and for cos we just push forward by 90 degrees.

00:16 <bloom> Observation 2: The next few instructions are the sequence floor/fsub. We immediately recognize this as the fract(...) function. This is again what we'd expect -- fsin/fcos are periodic, with period 2pi, which is now period 1 after the above change of units.

00:16 <bloom> The last four instructions are where things get mysterious.

00:17 <bloom> There are special one-op instructions dparametrized as 0b1010 and 0b1110... call them F and G

00:18 <bloom> and reading off, we see take that angle 0 <= x < 1 and calculate... G(F(4 * x)) * F(4 * x)

00:18 <bloom> and somehow that equals sin?

00:19 <bloom> The multiplication by four is just another change of units. Now the fraction is angle within a quadrant, and the integer part is the quadrant. This is natural enough given the quadrant (anti)symmetries we have with sin.

00:20 <bloom> All we're doing is a series of reductions to make G and F as simple as possible. Or rather, as small as possible -- they're probably lookup tables.

00:21 <bloom> At this point we have two options:

00:21 <bloom> 1. Just call F and G sin_pt_1 and sin_pt_2 and call it a day. Who cares?

00:21 <bloom> 2. Using a compute shader test (I believe dougallj has a script for this), run each op in isolation and dump the results. Then plot them and see what happens.

00:23 <bloom> (There's no magic for tan. It's just computing fsin and fcos and dividing them. Just looks funny due to aggressive scheduling.)

00:28 <dougall> yeah, maybe 1 is the way to go for now? (i do have a script that i have technically done something like this with, but it'll be a lot easier once we've made more progress on everything else)

00:28 <bloom> dougall: sure

00:28 <bloom> I was secretly hoping there would be Taylor series involved

00:29 <bloom> The lowering for Bifrost is super cute

00:29 <dougall> but yeah, it's a nice self-contained challenge for anyone interested in numerics if people want to try :)

00:30 <bloom> dougall: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/panfrost/bifrost/bifrost_compile.c#L1471-1517 this was fun to write

00:32 <dougall> haha nice!

00:44 <bloom> patches incoming

01:05 <bloom> Patches sent

01:14 <dougall> looks great!

01:20 <bloom> thanks!

01:20 <bloom> no clue on the extended fields, although IIRC you have a clever way to determine those that I don't :p

01:24 <bloom> also, I still can't get over the fact the shaders are keyed to formats

01:24 <bloom> I am not ok with this

01:24 <dougall> what does 'keyed to formats' mean?

01:26 <bloom> The code of the vertex shader depends on the format of the vertex attributes,

01:26 <bloom> likewise the code of the fragment shader depends on the format of the framebuffer

01:26 <bloom> That means you *can't* compile shaders up front,

01:27 <bloom> rather you have to wait until the app is actually drawing things and potentially have to recompile many times with different shader "keys" - combinations of "leaky" state

01:27 <bloom> ("shader variants")

01:28 <bloom> a number of architectures are specificalluy designed to eliminate all shader variants in e.g. core OpenGL ES

01:28 <bloom> Apple has gone the other end... why? well, because they can - Metal requires all this info at pipeline create time anyway, so why not use it? /s

01:29 <dougall> ah, that makes sense, thanks

02:25 <chrisf> only trouble for GL. we know this upfront for vulkan too

02:26 <bloom> chrisf: still means a lot more recompiles if the app swaps things in the pipeline

02:30 <chrisf> may be feasible to patch it?

02:31 <chrisf> is just the shader epilog that's affected?

02:34 <bloom> tbd

02:41 <bloom> I've just compiled my first shader (from GLSL down to AGX machine code) with Mesa :)

02:41 <dougall> :o

02:42 <bloom> it's gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0), don't get too excited :p

02:44 <bloom> doing all that dev on linux, let's see if it works on macos too :-p

02:52 <bloom> It does not work. Down the debug hole.

02:52 <bloom> Glaring problems include missing a stop instruction :-p

02:58 <bloom> Also, while obviously I can't enforce this, I kindly ask y'all not to make a splash about that before I can get around to blogging ;-P

03:01 <bloom> ok, stop/trap implemented

03:02 <bloom> ok, now it doesn't fault but there are crazy colours, guessing I screwd up the register alloc

03:04 <bloom> ofc I don't know the regalloc field for FS...

03:06 <bloom> Yep, there it is.

03:08 <bloom> First shader compiled from GLSL with mesa running successfully on the hardware

03:08 <bloom> not bad seeing as I started writing the compiler yesterday :p

03:15 <dougall> haha awesome!

03:15 <bloom> ld_vary is up next at which point I can start writing real shaders and implementing the heaps of ALU needed for anything interesting

03:15 <bloom> thanks :)

03:56 <bloom> have ld_var emitted but some cmdbuf work remains to use it in the demo..

16:38 <chrisf> bloom: you seem to be making a ton of progress

16:39 <bloom> :)

17:42 <dhewg> woot, sounds like a milestone to me!