@woosh/meep-engine 3.16.0 → 3.17.0

package/src/shade/renderer/particles/optimizer/dag/particle_vector_pack.d.ts

@@ -0,0 +1,57 @@
+/**
+ * Turn the chosen values into the groups {@link ./particle_vector_lower.js} schedules, colours and
+ * emits.
+ *
+ * There is less here than the job sounds like, and that is the point. A packer over a graph of lanes
+ * needs superword grouping, lane-order search and a demand solver, all of it re-deriving a
+ * vectorisation that its own lift threw away — that was measured at eight hundred lines and it still
+ * lost. Here a value IS a vector, one value is one instruction, and every operand reads lanes of ONE
+ * value, so it is a base and a swizzle, always, with nothing to arrange and nothing to copy.
+ *
+ * The copies that remain are the ones the program really has: a `BUILD`, which is a vector assembled
+ * out of lanes of several others. Those come from a frontend's `vec4` constructor and from a load of
+ * record words that different stores wrote, and each is one `MOV` per lane until something coalesces
+ * them away.
+ */
+/**
+ * @param {import("./particle_vector_graph.js").ParticleVectorGraph} graph
+ * @param {import("./particle_vector_lift.js").ParticleLiftedVectorSection} section
+ * @param {import("./particle_vector_extract.js").ParticleValueExtraction} extraction
+ * @returns {import("./particle_vector_groups.js").ParticleValuePacking}
+ */
+export function pack_particle_vectors(graph: import("./particle_vector_graph.js").ParticleVectorGraph, section: import("./particle_vector_lift.js").ParticleLiftedVectorSection, extraction: import("./particle_vector_extract.js").ParticleValueExtraction): import("./particle_vector_groups.js").ParticleValuePacking;
+/**
+ * Which record words go in one `STORE_ATTR`: consecutive words, taken from one value, no more than
+ * the four an operand spans — and cut where the original stores cut, so that a `vec3` position and a
+ * `vec4` colour in adjacent words stay two stores.
+ *
+ * @param {Array<{word: number, place: {value: number, lane: number}, origin: number}>} stores
+ * @returns {Array<Array<{word: number, place: {value: number, lane: number}, origin: number}>>}
+ */
+export function chunk_stores(stores: Array<{
+    word: number;
+    place: {
+        value: number;
+        lane: number;
+    };
+    origin: number;
+}>): Array<Array<{
+    word: number;
+    place: {
+        value: number;
+        lane: number;
+    };
+    origin: number;
+}>>;
+/**
+ * The widest stretch of the file a coalition may claim — the runs it lays end to end, added up.
+ *
+ * A ceiling rather than a tuned number: swept over the library's effects, 4 costs `integrate` four
+ * instructions (a four-lane run plus a one-lane pool run is five slots) and everything from 6 upwards
+ * is identical. What actually limits a coalition is that the lanes one operand wants must fall inside
+ * ONE window of four, which no amount of room relaxes.
+ *
+ * @type {number}
+ */
+export const PARTICLE_VECTOR_COALITION_SLOTS: number;
+//# sourceMappingURL=particle_vector_pack.d.ts.map

package/src/shade/renderer/particles/optimizer/dag/particle_vector_pack.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"particle_vector_pack.d.ts","sourceRoot":"","sources":["../../../../../../../src/shade/renderer/particles/optimizer/dag/particle_vector_pack.js"],"names":[],"mappings":"AAMA;;;;;;;;;;;;;;GAcG;AAEH;;;;;GAKG;AACH,6CALW,OAAO,4BAA4B,EAAE,mBAAmB,WACxD,OAAO,2BAA2B,EAAE,2BAA2B,cAC/D,OAAO,8BAA8B,EAAE,uBAAuB,GAC5D,OAAO,6BAA6B,EAAE,oBAAoB,CA8OtE;AA4YD;;;;;;;GAOG;AACH,qCAHW,MAAM;IAAC,IAAI,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE;QAAC,KAAK,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAA;KAAC,CAAC;IAAC,QAAQ,MAAM,CAAA;CAAC,CAAC,GACzE,MAAM,MAAM;IAAC,IAAI,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE;QAAC,KAAK,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAA;KAAC,CAAC;IAAC,QAAQ,MAAM,CAAA;CAAC,CAAC,CAAC,CAsB9F;AAtaD;;;;;;;;;GASG;AACH,8CAFU,MAAM,CAEiC"}