Följ Black Week på SweClockers

AMD lanserar Ryzen 5 7600X3D – exklusivt för Microcenter i USA

Permalänk
Datavetare
Skrivet av Alexraptor:

Nja, alltså håller ändå inte riktigt med att det är begränsat till svärmbeteenden. Det vanligaste i spel är ju faktiskt att alla fiender, så länge man inte pratar om scriptat beteende, i grund och botten använder en och samma algoritm, ofta i form av FSM, Behavior Tree eller GOAP, osv.

Grundprincipen med ECS är att entiteter hanteras som renodlad data där den logiska koden läggs upp som system som då itererar över alla instanser av entiteters datakomponenenter, vilket kan då effektivt bearbetas med parallellisering, jobs, burst, osv. Om man utgår från att man använder ett BT så betyder detta att varje entitet kan ha sitt eget träd som en datakomponent, som i sin tur innehåller en unik uppsättning noder. När träden sedan exekveras av Systemet, så kommer de att producera olika resultat för varje entitet, i enlighet med dess träd och noduppsättningar.

Att det är DOD + Burst står för den största vinningeni prestanda argumenterar jag inte emot, min ursprungliga argumentation handlade helt enkelt om att det faktiskt går att programmera spel så att de effektivt kan nyttja alla kärnor.

Beteendeträd är fullt möjligt att implementera inom ramen för SIMD, men det blir inte effektivt. Ett beteendeträd är ju ett sätt att beskriva en tillståndsmaskin.

SIMD är bara effektivt om det enda som skiljer mellan olika element är indata medan samma algorithm appliceras på allt. Det kan låta väldigt restriktivt, men fungerar t.ex. hur bra som helst att ha olika position, hastighet och acceleration för varje entitet vilket rätt använt kan ge ett resultat som ser bra ut.

SIMD faller ihop om det finns allt för många olika tillstånd i det som hanteras. Säg att man har 10k saker och ett beteendeträd med 10 olika tillstånd, man potentiellt då köra beräkningarna för alla 10 tillstånd för alla 10k entiteter för att sedan slänga bort 9/10 av beräkningarna. Det blir logiskt rätt, men pajar lite poängen med att köra SIMD.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Alexraptor:

Svårt att parallelisera? Ja!
Inga stora steg i framtiden? Skulle snarare säga att det är tvärtom.

Vi står faktiskt inför ett paradigm-skifte med dataorienterad programmering och ECS (Entity Component System) som resulterar i att det blir lättare att skriva parallelliserad kod. Men visst huvudtråden förblir ändå en begränsande faktor, eftersom arbeten måste startas och synkas med den, detta för att det är enbart huvudtråden som får ha åtkomst att göra ändringar i minnet.

Men när programmerare väl vänjer sig vid dataorienterad programmering, så kan vi förvänta oss ändå ganska enorma framsteg.

Här är ett eget exempel på vad man kan åstadkomma med ECS på en 16-kärning Ryzen 5950x.
https://youtu.be/2JMyz7CpECs?si=rQBp5dcCqo2KZBef

Bifogar även en bild from HWMonitor som visar hur effektivt mitt demo nyttjar ALLA kärnor och trådar på CPU:n.
<Uppladdad bildlänk>

Nu förvirrar du mig mycket med vad du menar är nytt.

ECS är väl inget nytt? Det har väl de flesta spelmotorer använt sig av de senaste 10-20 åren? Det implementerades någon gång innan 2000 första gången i ett kommersiellt spel. Det kanske är nytt för Unity, men det är väl bara komposition i grunden. Jag tror prestandavinsten här är att Unity ändrat sin motor, för den har väl aldrig varit något man skulle vända sig till ifall man vill ha prestanda. Den har kört genom mono innan, men kan nu kompilera till mer effektiv AOT i stället för JIT. Jag vet inte hur Unity har gjort innan, men det är definitivt AOT till native byte code nu.

Dataorienterad programmering kan betyda mycket. Vad menar du exakt med det? Det är det vi sysslade med innan OOP. Att parallelisera fysikberäkniningar över många hårdvarutrådar är inte något nytt, oavsett om man använder object eller pekare till arrays med structar i minnet. När man kodade i C och asm så var det allt man hade.

Frostbite och många andra spelmotorer gjorde sina optimeringar för >4 kärnor för länge sedan.

Visa signatur

Hur många datorer är för många?

Permalänk
Medlem

@Yoshman Har du, eller någon annan, djupare insikt i hur SIMD hanteras i x86? Om jag tar AVX-512 som exempel så kan den arbeta på 8 st int64_t (512/64) eller 64 st char (512/8) samtidigt. Hämtas denna 512-bits data in som vanligt från minnet och cachas, eller kringgås cachen? Kanske jobbar den direkt ut mot minnesbussen? Min fundering grundar sig i att om processorn skall göra en massiv beräkning (flera AVX-512 anrop) så borde väl cachen vara ganska tom på användbara data efter en sådan operation?

Permalänk
Datavetare
Skrivet av mc68000:

@Yoshman Har du, eller någon annan, djupare insikt i hur SIMD hanteras i x86? Om jag tar AVX-512 som exempel så kan den arbeta på 8 st int64_t (512/64) eller 64 st char (512/8) samtidigt. Hämtas denna 512-bits data in som vanligt från minnet och cachas, eller kringgås cachen? Kanske jobbar den direkt ut mot minnesbussen? Min fundering grundar sig i att om processorn skall göra en massiv beräkning (flera AVX-512 anrop) så borde väl cachen vara ganska tom på användbara data efter en sådan operation?

Just då man kan använda SIMD på stor mängd data så finns det två klasser av load/store instruktioner.

En "vanlig" i bemärkelsen att den samverkar med CPU-cache som skalära load/stores. En som i praktiken säger till CPUn: du bör nog inte cache:a detta, för det kommer vara rätt mycket och/eller kommer inte använda samma data inom kort (att använda data i två olika spel-frames ligger rätt mycket i "inte inom kort").

Den senare klassen av load/store kallas i x86 SIMD-världens för "non-temporal memory accesses". Exempel

Sen som extra info till diskussionen ovan: en trevlig sak med AVX512 (oavsett om man använder 128, 256 eller 512 bitars instruktioner) är att man där lagt till lite funktioner som gör följande typ av kod mindre ineffektivt (men fortfarande inte optimalt med divergerande kod-pather för SIMD)

if (some_predicate(data)) transformation_a(data); else transformation_b(data);

Detta går även att göra med SSE/AVX, men ger mer overhead. Kör man med ISPC (något bl.a. UE4/UE5 använder internt) slipper man bry sig om dessa skillnader, ISPC är "CUDA for x86_64/ARM64 SIMD"

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Skrivet av jOnÄTÄn:

Om behovet av 8 kärnor uppstår om2-3 år kan du ju byta till en beg 9700x eller 9900x rätt billigt. Alternativt köra på framtidens motsvarighet och även få en förhoppningsvis stor boost per kärna. De allra flesta spelarna klarar sig fint med ryzen 5 eller core i5.
Däremot tycker jag det är dags för amd att öka ryzen 5 till 8c16t och ha 6c12t till ryzen 3 istället. Men det lär inte hända så länge de säljer bra.

Det lär inte hända förrän Intel kommer med något bra som på riktigt kan konkurrera med AMD. Kanske blir det Arrow Lake?

Permalänk
Moderator
Moderator

Även Mindfactory (tysk hårdvarusida, en av Europas största) kommer sälja 7600X3D, till det facila priset av 329€. Med frakt via en mellanhand bör priset alltså landa på 4 000:- för en svensk köpare. Inte särskilt hett när man med 7800X3D kan få 33% fler kärnor för 10% fler pengar.

Visa signatur