Jeu Videz votre presse-papier - Page 999

{% endblock %}

beuargl

float sr3 = rand(1.5, 2.5);
pointer sr6 = ParticleContextS;
float3 sr8 = VelocitySampler.samplePosition(sr6);
float vr17 = scene.Time;
int3 sr11 = CParticleNodeSamplerData_Shape_577F3ED7.sampleParametricCoords(sr6);
pointer ir0 = ParticleContextI;
float3 sr15 = CParticleNodeSamplerData_Shape_577F3ED7.samplePosition(sr11, ir0);
float3 sr32 = xform_L2W(sr8, 2, ir0);
float3 sr34 = xform_L2W(sr15, 3, ir0);
n112__Size = 1.570795e-01;
n112__Color = float4(1.0);
float sr97 = rcp(sr3);
InvLife = sr97;
internal_vr18 = vr17;
internal_sr4 = sr3;
internal_sr38 = sr32;
internal_vr39 = float3(0.0, -4.905, 0.0);
internal_sr41 = sr34;
internal_vr48 = 1.234;
internal_vr29 = float3(0.0, -9.810, 0.0);
internal_vr54 = 0.5;
float sr95 = internal_vr18; // 1.46 us, 5.1 cycles/particle
float sr4 = internal_sr4; // 0.59 us, 1.8 cycles/particle
float3 sr38 = internal_sr38; // 4.10 us, 10.8 cycles/particle
float3 sr41 = internal_sr41; // 3.51 us, 8.5 cycles/particle
float vr23 = scene.Time; // 0.59 us, 0.5 cycles/particle
float sr100 = vr23 - sr95; // 2.34 us, 6.6 cycles/particle
float sr36 = sr100 / sr4; // 1.46 us, 3.7 cycles/particle
float sr105 = sr100 * sr100; // 1.17 us, 2.3 cycles/particle
float3 sr109 = sr100.xxx; // 4.39 us, 11.0 cycles/particle
float3 sr39 = sr38 * sr109; // 1.17 us, 3.6 cycles/particle
float3 sr110 = sr105.xxx; // 2.34 us, 6.3 cycles/particle
float3 sr111 = float3(0.0, -4.905, 0.0) * sr110; // 0.88 us, 2.2 cycles/particle
float3 sr42 = sr41 + sr39; // 0.88 us, 2.6 cycles/particle
float3 sr44 = sr42 + sr111; // 0.59 us, 1.0 cycles/particle
pointer ir7 = ParticleContextI; // 0.59 us, 0.5 cycles/particle
float3 sr48 = CParticleNodeSamplerData_Turbulence_E38247D0.sample(sr44, ir7); // 102.11 us, 265.3 cycles/particle
float3 sr58 = sr44 - sr48; // 0.88 us, 1.9 cycles/particle
float sr64 = CParticleNodeSamplerData_Curve_0240AFF7.sample(sr36); // 8.48 us, 22.8 cycles/particle
float sr116 = sr100 * 0.2; // 0.59 us, 1.2 cycles/particle
float sr117 = sr116 - 0.1; // 0.59 us, 1.1 cycles/particle
float sr119 = 0.2 + sr117; // 0.59 us, 1.8 cycles/particle
float3 sr120 = sr119.xxx; // 2.34 us, 5.8 cycles/particle
float3 sr70 = sr58 / sr120; // 2.34 us, 5.8 cycles/particle
float3 sr69 = CParticleNodeSamplerData_Turbulence_E38247D0.sample(sr70, ir7); // 95.67 us, 249.7 cycles/particle
float3 sr72 = sr69 * float3(0.2); // 0.88 us, 1.8 cycles/particle
float3 sr121 = sr117.xxx; // 2.34 us, 6.3 cycles/particle
float3 sr73 = sr72 * sr121; // 0.88 us, 1.1 cycles/particle
float sr74 = rand(0.0, 1.0); // 3.51 us, 9.4 cycles/particle
int sr75 = sr74 > 0.05; // 1.17 us, 2.7 cycles/particle
int sr76 = select(0, 1, sr75); // 0.88 us, 2.1 cycles/particle
float sr77 = float(sr76); // 0.88 us, 2.4 cycles/particle
float3 sr78 = sr77.xxx; // 1.76 us, 4.2 cycles/particle
float3 sr79 = sr73 / sr78; // 2.34 us, 5.6 cycles/particle
float3 sr80 = sr58 + sr79; // 0.59 us, 1.2 cycles/particle
float sr82 = sr64 * 0.5; // 0.59 us, 0.9 cycles/particle
float3 sr84 = sr82.xxx; // 1.46 us, 4.7 cycles/particle
float3 sr85 = sr84 + sr80; // 0.59 us, 0.9 cycles/particle
n112__Position = sr85; // 2.05 us, 5.4 cycles/particle

ca fait bcp de cycles toussa

http://www.pagemac.com/projects/rfid/arduino_wiegand

setFrameStyle(Sunken | StyledPanel);

-----------
squalyl> oui mais c'est l'interet de ce profiler, pour spot ces problemes la ^^
apres, ca met a genoux les cores hyperthreades, faut diviser par deux pour avoir les "vrais" cycles.
mais meme, y a des trucs qui devraient pas prendre si cher (genre les swizzle), apres le rand c'est un mersenne twister qui tourne derriere, donc ca reste correct, et la turbulence, c'est de base ultra hardcore, c'est un des trucs les plus couteux a calculer qu'on aie :/

c'est plutot un truc comme ca qui m'étonne:

float3 sr78 = sr77.xxx; // 1.76 us, 4.2 cycles/particle
un field access par rapport un div:
float3 sr79 = sr73 / sr78; // 2.34 us, 5.6 cycles/particle

alu de ouf versus acces non aligné?

---

http://www.lemonde.fr/sciences/article/2017/01/10/un-rapport-sexuel-entre-un-singe-et-une-biche-observe-au-japon_5060322_1650684.html

Bon, soutenances finies, je vais pouvoir reprendre mes essais de tessellation

squalyl> ouai les swizzle donc ^^
code du swizzle pas terrible tout simplement
nos swizzles doivent pouvoir gerer x y z w 0 et 1, du coup c'est le symptome d'un code qui se veut quand meme semi-generique et qui peut pas (et veut pas!) specialiser toutes les combinaisons possibles, donc il y a une specialisation par dimension, mais a chaque iteration, pour chaque composante de destination, il y a une indirection memoire, c'est pas unroll, pas de SIMD, bref, ca prend cher.

sinon, tous les buffers sont cache-line aligned, mais en l'occurence, vu que ca c'est des loads scalaires qui sont fait, ca change rien (c'est de toutes facons tout le temps au moins aligned a 4 bytes).

bon jsuis pas trop sense montrer des screens mais juste un bout ca passe jpense
on voit bien les hits (de porc) sur un fx plus simple qui applique juste une velocity+accel simple:



en bleu c'est du spawn, on s'en fout.
les lignes jaunes c'est run a l'update

les 3 loads du debut prennent ultra cher, la data est froide, c'est le cout des cache misses (et pour les float3 du packing, les data d'origine sont en float4 avec un 'w' de padding, et sont recompactees au moment du load en float3, mais le coup du shuffling est infime compare au cache, donc quasiment toute la barre qu'on voit, c'est les cache misses (pas de false-sharing non plus, on a un algo qui place les buffers en memoire pour minimiser l'aliasing).
les swizzle (.xxx) prennent ultra cher compare aux autres ops.
et pour chaque operation, il y a des loads et des stores, c'est pas un asm compile tel quel qui passe par des registres HW, chaque instruction s'execute sur un gros batch (des blocs de ~1K elements), donc load toutes les operandes, fait l'op, et les re-store derriere pour l'op d'apres.
le store final n'utilise pas de non-temporal stores, et unpack l'array de float3 en array de float4
sinon quasiment toutes les ops a part swizzles et load sont unroll en AVX (il y a un hot dispatch au runtime entre SSE2 et plus si la machine le supporte, mais la en l'occurence ma machine c'est un i7 qui gere l'AVX, donc AVX)

Avec les non-temporal stores ca donne ca:



^^

./29951 Sympa ^^

Je suppose que c'est un débuggeur in-house?

oui. c'est que 10% du truc, il est trop bien :> et on a encore plein d'idees.
jpeux pas montrer le reste pour le coup.
(mais en gros, debugger fait pour debug bcp de data (on a fait des tests avec plusieurs millions de particules, du coup autant de millions de float3 run pour chacune de ces instructions), il te fait des stats sur les distributions des resultats des instructions suivant la data qui passe dans la sim, qui te permet de rapidement faire des recherches de valeurs (genre trouver des inf/nan) dans les resultats, qui run CPU/GPU simultanement et te permet de spot les divergences de sim, de mettre des breakpoints et de step sur chaque instruction, bref, plutot content du resultat ouai )

squalyl> tiens, si tu veux rire:
ligne #28 & #29



(m'enfin oui l'i7 a un ALU de porc de toutes facons ^^)

WTF ces rapports de ouf

ah c'est sur CPU en plus meme pas GPU

(sinus en 3 cycles cpu wow )

tin c'est badass, moi qui me sentait heureux avec le débuggeur de la pipeline graphique directx sur visual studio

LCWO

DOS/4GW FTW!!! #DOSGaming pic.twitter.com/9MpfmMRxLI

— Anatoly Shashkin ? (@dosnostalgic) December 3, 2016

AOCJYR-10.000MHz-M5625LF

http://danstonchat.com/18313.html
(pour Folco)

Erf

Une preuve de plus que l'Univers tel que nous le connaissons est une simulation: un alligator qui a chargé sans sa texture.
(via @Gally ) pic.twitter.com/6bE3xBkZvn

— -Boulet- (@Bouletcorp) January 12, 2017

Wow à ce point-là c'est fou ! La vidéo mérite le coup d'oeil, mais comme c'est Facebook j'ai l'impression qu'on ne peut pas l'afficher directement ici

Mais si, mais si :


(bon je sais pas pendant combien de temps ça va marcher, par contre )