Skrivet av Aleshi:
Du får nog skriva ut lite i klarspråk. Hur mycket vikt ska vi lägga på att det finns ML-instruktioner? Finns det skäl att tro att det har några faktiska användbara funktioner i nuläget. Eller är det bara något vi ser inför RDNA2? Det har ju hänt förrut att de har haft stöd för instruktioner som inte fungerat tillfredsställande eller aktiverats på ett meningsfullt sätt.
Det är en bra fråga. Just Navi12 verkar mest vara menad för workstation-saker eller så vad jag kan se. Många uppdateringar handlar om SR-IOV och sånt. Det marknadsförs som:
"3D Content Creation: Design, animate and render complex 3D models with workstation-class graphics."
"Video Editing: Edit, composite and encode seamlessly while using up to four 4K displays"
Denoising för ray tracing var som sagt den enda funktionen som jag hittat som utnyttjas av Apple. Men RT för workstation och RT för spel är ganska annorlunda. För spel så kan det vara allt från 0.25-1 ray per pixel , medan för workstation så gäller oftast hundratals till tiotusentals rays per pixel. Det finns inte heller några specifika krav för hur lång tid denoising ska ta, bara resultatet är ungefär lika bra och reducerar antalet rays som behövs för att få det. I spel så är det svårt att få in det tidsmässigt, även för Turing (finns inga spel som använder tensor cores för denoising), men kanske det kan komma att ändras till Ampere. Man kan alltid hoppas.
Så hur mycket vikt ska läggas på det? Det säger oss inte så mycket, men det kan även vara en del av AMDs strategi framåt. Det kan konstateras att Navi12 har stöd för de mixed-FMA enheter som beskrivs i whitepaper för RDNA, uppdateringar kallar det för "Navi with DLOPS" / "Navi DL" , den har hårdvarufixar som inte finns i varken Navi10 eller Navi14. Jag skulle tro att ML är något som används, med tanke på att de tagit fram kortet just för det.
Skrivet av Aleshi:
nVidia har ju massa dedikerade tensorkärnor. Det har vi ju inte i några nuvarande produkter från AMD. Finns det spekulationer om hur de gör? Kommer de ha dedikerade enheter till det eller kommer de lösa det på annat sätt? Går det ens praktiskt att bygga tensor-funktionalitet i de vanliga SPs? För jag ser inte riktigit hur de ska gå till väga utan dedikerade tensor-kärnor. Jag får intrycket av att ML-instruktioner utan tensor-kärnor inte riktigt tillför något avgörande.
Hur de gör nu: I SPs med FMA-enheter som är uppdelade. 2x Fp16 , 4x int8 , 8x int4 , det var iallafall så de gjorde i vega. Instruktionerna till Navi heter dock inte helt samma. Har ingen aning om vad skillnaden är mellan t.ex dot2 och dot2c. Om jag inte minns fel så har NVIDIA:s tensor cores 2x eller 4x mer ALU:s än Navi , så de bör vara snabbare. Det är nog meningen att de ska vara långsammare, men ta upp mindre plats.
Till RDNA2 finns det spekulationer om att de byggt in något som kan liknas tensor cores i videocodec:en (varför de nu helt plötsligt har två stycken). Det är inte säkert att de är kraftfullare än tensor cores, men de har egna resurser att arbeta med och kan köras parallellt. I vissa fall kan det vara bättre än att vara snabbare. Det finns en sak som kan tyda på det. Microsoft beskriver att SDR=>HDR tar inte upp någon tid från CPU, GPU eller minne. Vilket låter otroligt, men om man tänker på patentet så är det inte omöjligt. Det får vi kanske se när den väl släpps. Vad som talar emot är dock att de inte använder ML-denosing i deras RDNA2 demo. De kan dock vilja hålla tyst om det för att inte sänka Navi eller höja NVIDIA ännu mer. Svårt att veta.
Skrivet av Aleshi:
Och angående Ray Tracing. Inget pekar på officiellt stöd för Ray Tracing innan RDNA2 som jag förstått kommunikationen från AMD. Så vad har vi för nytta med instruktionerna? Kan det vara det jag spekulerade om med ML-instruktionerna? Att de finns där men kommer inte vara meningsfulla innan RDNA2? Borde väl ha varit mer väsen kring det hela om det kommer redan med dessa kretsar tänker jag.
Vad tror du förövrigt om AMDs metod för att hantera Ray Tracing i TMU:er? Är det något vi ska se positivt på eller är det ett dåligt tecken?
Det kommer inget officiellt stöd för ray tracing innan RDNA2, men Navi12 är inte menad för DXR eller VK_KHR_ray_tracing. Instruktionerna till Navi12, image_bvh_intersect_ray , talar om att givet en stråle, kolla om en bounding box beskärs av den. Image är dock mest intressant, då det anspelar på att den använder sig av image loads (via texturenheterna). Vilket hade även passat med patentet för RT-enheter i TMU:n. Så vägarna finns där i RDNA1, men RT-enheterna kommer först till RDNA2. För kort utan HWRT så verkar de använda sig av batch intersection, och för Navi12 så kan de utnyttja WGP-mode. ML-instruktionerna spelar roll för att denoisa pro appar, men inte spel. Det kan vara en bra anledning till att inte göra så mycket väsen kring det. De vill nog inte säga att NVIDIA kan ha en poäng.
RT i TMU:s är på samma sätt som i Turing, eller iallafall så nära man kommer. Det är en black box, som vi egentligen inte kan se hur den fungerar. AMD sa att det ska gå att skriva egen kod för traversal till deras lösning. Så den bör tillåta flexibilitet och experimentering utanför DXR, vilket kan vara bra i många fall. Vet dock inte om de även har fixed-function traversal också (patentet säger att det kan ha det) som Turing. Vi får se när det väl släpps.
Skrivet av Aleshi:
Som jag förstått det så vet du ju inte heller riktigt. Men det känns som att du är så pass mycket mer påläst än mig att dina spekulationer i frågan kan vara väldigt värda ändå.
Jag kan inte veta saker innan de väl släpps. Men om jag ser en massa stjärnor snurra kring ett objekt som man inte kan se så landar den första tanken på att det finns ett svart hål däromkring. Det behöver inte vara det, men kan vara det. Fast i just det här fallet handlar det mer om ML och ray tracing.
Säg till om jag missat eller behöver utveckla något.
Det verkar ha släppts en hel drös andra RT patent idag från AMD. Jag ska ta en titt på dem senare och se om jag hittar något bra.