Travis Lanier fra Qualcomm satte seg ned med XDA for et intervju om Kryo 485 CPU i Snapdragon 855 mobilplattformen og markedsføring av Hexagon 690 DSP.
Forrige måned avduket Qualcomm Snapdragon 855 mobilplattform. Snapdragon 855 er den mobile plattformen som vil drive de fleste Android-flaggskip-smarttelefoner i 2019. Qualcomm har gjort betydelige forbedringer fra år til år med sin neste generasjons mobilplattform. Den mobile Snapdragon 855-plattformen er bygget på en 7nm produksjonsprosess og tilbyr et imponerende 45% hopp i CPU-ytelse i forhold til Snapdragon 845. Forbedringene i beregningen over hele linja gjør at Qualcomm kan skryte av utmerket AI-ytelse på den nye Snapdragon 855. Det er mye informasjon å pakke ut her, og vi har gjort vårt beste for å vise hvordan Qualcomm har forbedret ytelse og AI på Snapdragon 855. Imidlertid hadde vi fortsatt spørsmål etter produktavdukingen, så vi satte oss ned med Travis Lanier, Senior Direktør for produktadministrasjon i Qualcomm, for å snakke om Kryo 485 CPU og AI på Qualcomms nye mobil plattform.
Mario Serrafero: "45% [hopp], det er som den største noensinne. La oss pakke det ut. Vi har A76-basen, 7nm – de er store bidragsytere. Det ser ut til at helt siden dere flyttet bort fra tilpassede kjerner, noen publikasjoner og publikum har ikke hatt mye peiling på hva Built on ARM-lisensen innebærer i forhold til hva den kan tillate deg å gjøre. Du har vært ganske hemmelighetsfull om hva det innebærer [også]. Nå på scenen for en av de første gangene du har, i hvert fall utover spørsmål og svar,... men for første gang har du vist hva noen av forbedringene var, og det er kult. Så vi lurte på om du ønsker å utvide hvordan Qualcomm stilte inn Kryo 485 for å presse mer [ut] av ARMs base, enten det er å utvide ting du har eksponert der borte eller noe du ikke har presentert."
Travis Lanier: "Så jeg kan egentlig ikke si for mye mer enn annet det som var i lysbildene mine. Kanskje vi kan det på et senere tidspunkt, så vi kan sette oss ned og få noen eksperter som faktisk har gjort jobben; Jeg kjenner snakkepunktene på høyt nivå. Men som du vet, er A76 allerede et design på høyt nivå – det er ganske bra. Og det er en av grunnene da vi så ARMs veikart. Så jeg mener, greit, kanskje vi burde jobbe tettere med disse gutta, for det så veldig sterkt ut. Og bare tilbake til kommentaren din om tilpasning versus ARM. Så ok, det er alle disse tingene du kan gjøre. Og hvis du gjør noe, og det må ha differensiering, så du kan gjøre noe hundre prosent eller samarbeide med dem. Og [som i] tidligere år, handler vi litt mer om integrering. Så busser, og hvordan vi koblet til systemet, deres sikkerhetsfunksjoner som vi legger inn i CPU-ene, hurtigbufferkonfigurasjoner. Nå som engasjementene har pågått lenger, var vi i stand til å gjøre en dypere tilpasning på denne. Og det var slik vi var i stand til å sette noen av disse tingene der inne, som større utførelsesvinduer, ikke sant, slik at du har mer instruksjoner under flyging, er forhåndshenting av data faktisk et av områdene der det skjer mest innovasjon i mikroprosessorindustrien akkurat nå. Mange av teknikkene for mange av disse tingene er ganske like, alle bruker en TAGE-grenprediktor i dag, akkurat hvor stor du sørger for den, folk vet hvordan de skal gjøre ute av drift, og videresending og alt det der for større cacher. Men forhåndshenting, det er fortsatt mye av, det er en av de mørke kunsttypene. Så det er fortsatt mye innovasjon på gang i det området. Så det er noe vi følte vi kunne hjelpe med.
Og så bare fordi vi føler at vi generelt gjør en bedre jobb med... vanligvis kan vi implementere et design raskere enn andre kan integrere en prosessnode. Og så når vi legger noen av disse tingene der, som når du går mer ut av drift, er det mer stress på designet ditt, ikke sant? Det er ikke gratis å legge til alle disse utførelsestingene der. Så, for å kunne gjøre det, og ikke ha et treff på din fmax. Ja, det er en del av engasjementet vi har med ARM, for eksempel hvordan fjerner du dem?"
Mario Serrafero: "Bare av nysgjerrighet, i presentasjonen, hadde du snakket om at effektivitetsforbedringer skulle komme fra forhåndshentingen, snakket du om strømeffektivitet, ytelsesforbedringer, litt av både?"
Travis Lanier: "Alle de ovennevnte. Så i sin natur gjør vi forhåndshenting – du har hentet ting i bufferen. Så når du har cachen som ikke gjør så mange minnetilganger, er det nå en bakside til forhåndshenting: Hvis du gjør for mye forhåndshenting, [bruker] du mer minne fordi du vet, [du] gjør for mye spekulativ forhåndshenting, men så langt som, hvis du har ting i og du drar de riktige tingene, så går du ikke ut i minnet for å hente det inn der. Så hvis du har en mer effektiv forhåndshenter, sparer du strøm og øker ytelsen."
Mario Serrafero: "Ok, kult, ja. Ja, jeg forventet ikke at du ville være i stand til å utvide mye mer utover det, men det er interessant at hvis du sier det nå tilpasser dere mer, og kanskje dere kan dele mer i fremtiden, så skal jeg holde øye med det. Så den andre typen head turner, i hvert fall blant folk jeg er omgitt av, er hovedkjernen. Så vi hadde forventet en slags mer fleksible klyngeordninger i et par år nå med [inkluderingen av DynamIQ] og at vi forventet at andre selskaper skulle gå bort fra [4+4]-ordningen. Så to spørsmål: Hva var motivet bak hovedkjernen? Hvordan gagner hovedkjernen brukeropplevelsen, fordi leserne våre vil gjerne vite hvorfor det bare er en ensom kjerne der borte, og også hvorfor den ikke er helt ensom? Ville ikke deling av kraftplanet med ytelsesklyngen på en måte redusere noe av nytten du kunne oppnå hvis du brukte DynamIQ og på en måte satt [det] alene?"
Travis Lanier: "Så la oss snakke om forskjellige klokker og forskjellige spenningsplan først. Så hver gang du legger til en klokke og hver gang du legger til en spenning, koster det penger. Så det er en grense for antall pinner du setter på pakken, det er flere PLLer du må ha for forskjellige klokker og det er bare økt kompleksitet. Så det er en avveining å gjøre ting. Vi gikk litt ekstremt på et tidspunkt; vi hadde fire forskjellige domener på fire forskjellige klokker, så vi hadde erfaring med det, og det var dyrt. Litt når du begynner å bli stor. LITT, du har de små kjernene på [den] lille klyngen og de trenger ikke helt den samme granulariteten, for å si det sånn, til en separat klokke mellom de små kjernene. Ja, det ligger litt i luften hva du gjør med dem. Så når du har en stor. LITT system, så har du omvendt disse store kjernene. Vel, ok, setter du hver av dem på en stor klokke? Vel, du kjører ikke på disse hele tiden, hvis du faktisk er i en lav nok situasjon der en ledig klokke vil kjøre på en liten kjerne uansett. Så egentlig er det sånn at to av dem er gode nok der.
Og så kommer du til der vi hadde denne primærkjernen, der ok, vel, vi har en egen klokkekjerne, som kan løpe opp til en høyere frekvens. Men disse andre kjernene, de andre ytelsesklyngene, kan ikke gå opp til samme høye frekvens. Så hvis du ønsker å få den fulle rettigheten til den kjernen, må du ha den tredje klokken for den. Så hva gjør denne kjernen? Vi berørte det litt. Store ting vil være [appstarteren] og nettsurfing. Og så hvorfor bare én kjerne? Ok, ting blir mer multithreaded nå. For eksempel beveger spillmotorer – jeg kommer tilbake til det om et sekund – veldig aggressivt mot flere tråder. Men hvis du ser på de fleste apper, selv om de har flere tråder, vil jeg bruke Pareto-regelen, som de fleste av dem, er 80 % av belastningen i én tråd. Så du kan starte en app, og den kan starte opp og lyse på alle 8 kjerner. Men mer enn sannsynlig er 80% av det i en dominerende tråd - det er i den ene kjernen. Nettsurfing er fortsatt først og fremst, vel, JavaScript, vil jeg si - nettsurfing har blitt litt bedre med multithreading der du kan ha flere bilder og du kan dekode dem. Men for eksempel JavaScript – [en] enkelt tråd kommer til å kjøre på én kjerne. Så det er et stort antall brukstilfeller som drar nytte av å ha denne ene kjernen som gikk veldig høyt.
Nå har vi tre kjerner som kjører litt på en lavere frekvens, men de er også mer strømeffektive. Og slik som når du – jeg vet ikke hvor mye du vet om implementering av kjerner – men når du begynner å nå toppen av frekvensen, og implementeringene av disse kjernene, det er en avveining i kraft, ting begynner å bli eksponentielle i de siste megahertz eller gigahertz som du ha. Ja, og så snakket jeg om for et sekund siden, hvor, hei, alle spill begynner å bli flertrådede, som alle andre Plutselig, hvis du ser tilbake, var det et par spill for ikke så lenge siden, og de bruker bare ett tråd. Men det er rart hvor raskt bransjen kan endre seg. Som det siste året, og et halvt år, har de bokstavelig talt begynt å bruke alle disse spillene i... Jeg har blitt begeistret over disse high fidelity-spillene. Og så mens mange ting, for akkurat som for seks måneder til et år siden, før, har det faktisk snudd over hele Kina. I Kina hører jeg "Jeg bryr meg egentlig ikke om store kjerner, gi meg en åtte av hva som helst, gi meg åtte av minste kjerner slik at jeg kan ha åtte kjerner." De har endret seg fordi de vil ha disse spillene, disse spillene krever store kjerner. Og nå får vi tilbakemeldinger fra partnere om at "nei, vi vil faktisk ha fire store kjerner," på grunn av alle de avanserte spillene som kommer ut. Og de kommer til å bruke alle disse kjernene.
Så når du spiller, spiller du ikke i 30 sekunder, eller 5 minutter, du spiller lenger. Så, det er fornuftig, vi har disse tre andre kjernene i de fleste av dine multithreaded big core use cases, de ønsker å ha litt mer strømeffektivitet. Det balanserer på en måte, du har denne kjernen med høyere ytelse når du trenger den for noen av disse tingene i noen av disse vedvarende tilfellene der de også har store kjerner og du har denne mer strømeffektive løsningen å pare med at. Det er sånn tankegang - det er litt uvanlig symmetri. Men forhåpentligvis svarer det på hvorfor [det er en] primærkjerne, hvorfor har du ikke separate klokker, og hvorfor har du ikke separate spenninger? Og så tror jeg at jeg berørte alle disse."
Mario Serrafero: "Nå, heterogen beregning. Det er det Qualcomm har understreket siden overgangen fra den gamle merkevaren til den mobile plattformen, og den typen [en] deskriptor, og også aggregeringsblokker fra å beskrive visse ytelsesmålinger som AI. Hvordan har denne utviklingen vært ved å bytte til en mer heterogen beregningsmetode? Alt fra design til utførelse til markedsføring, eller hva du kan berøre."
Travis Lanier: «Det går litt frem og tilbake. Men til syvende og sist må du ha disse motorene fordi navnet på spillet i mobil er strømeffektivitet. Nå ser du noen ganger at det går tilbake til en generalisering av og til. Hvis du går tilbake til originalen, selv for smarttelefoner, hadde funksjonstelefoner multimedia og kamera evner til en viss grad, så de har alle disse små dedikerte tingene fordi du ikke kunne gjør det. Hvis du går tilbake til telefonene som er bygget på ARM 9 eller en ARM 7, hadde de alle en maskinvareakselerasjonswidget for alt.
Men for å gi deg et eksempel, hvor noe ble generelt og nå de ber om maskinvare igjen, ville være JPEG. Det pleide å være en JPEG-akselerator. CPU-en ble til slutt god nok, og den var strømeffektiv nok, og JPEG-ene holdt seg på en måte samme størrelse som, hei, vet du hva, vi vil bare gå videre og gjøre det på CPU [som] det bare er lettere å gjøre den. Nå, ettersom bildene blir større og større, plutselig går folk, du vet, faktisk vil jeg at disse virkelig gigantiske bildefilstørrelsene skal akselereres. CPU-ene [er] på en måte enten ikke raske nok eller brenner for mye strøm. Det er bare plutselig at det er interesse for potensielt å ha JPEG-akseleratorer igjen. Så det er ikke alltid en rett linje hvordan ting går, da må du se på hva som skjer akkurat nå med Moores lov. Alle fortsetter å snakke om, hei, du er kanskje ikke død, men det går litt ned, ikke sant? Så hvis du ikke får den kraftøkningen, eller ytelsesøkningen fra hver neste node, hvordan fortsetter du å legge til mer funksjonalitet på telefonen hvis du ikke har det overhead? Så du kan bare sette den på CPU'en. Men hvis du ikke har mer takhøyde for CPU-en din, hvordan akselererer du disse tingene? Vel, svaret er at du legger alle disse spesialiserte kjernene og tingene mer effektivt. Og så det er den naturlige spenningen.
Du vil se folk bli tvunget til å gjøre disse tingene for vanlige funksjoner, siden kanskje ikke alle kommer til å være på blødningskanten. Men vi kommer absolutt til å prøve å bli der så lenge som mulig, men vi kan ikke tvinge fabrikkene til å flytte til neste node hvis den ikke nødvendigvis er der. Så det er derfor du må fokusere på kontinuerlig innovasjon og disse arkitekturene for å fortsette å få bedre ytelse og strømeffektivitet. Så det er vår styrke og vår bakgrunn."
Mario Serrafero: "Selv om det har vært denne overgangen til heterogen databehandling, fra Qualcomms side, mange publikummere og sikkert mange publikasjoner, absolutt mange entusiaster, overraskende nok, som du tror ville vite bedre, de tenker fortsatt på, vurderer og vurderer blokkene som separate enheter. De fokuserer fortsatt på "Jeg vil se CPU-tallene fordi jeg bryr meg om det." De vil se GPU-nummer fordi de liker spill, så videre og så videre. De anser dem ikke som kommuniserte deler av ett integrert produkt. Hvordan tror du at Qualcomm har, og er, og kan, knuse det paradigmet ettersom konkurrenter faktisk fortsetter å fokusere på den spesifikke blokk-for-blokk-typen av forbedringer i markedsføring? Nærmere bestemt, [vi vil] gå videre til nevrale nettverk, nevrale motor-ting senere."
Travis Lanier: «Jeg håper jeg kom inn på noe av det i dag. Vi fokuserer på for eksempel vedvarende spilling, så kanskje du scorer bra på alle gaming-benchmarkene. Folk blir besatt av det. Men det som egentlig betyr noe er at hvis du spiller spillet ditt, forblir bildene per sekund konsekvent der du vil at den skal være på det høyeste punktet for disse tingene? Jeg tror folk legger for mye vekt på et tall for en av disse blokkene. Det er så vanskelig, og jeg forstår ønsket om å gi meg ett tall som forteller meg hva det beste er. Det er bare så praktisk, spesielt i AI akkurat nå, det er bare galt. Selv med CPU-benchmarks, hva måler en CPU-benchmark? De måler alle forskjellige ting. Ta noen av referansene, som GeekBench har en haug med underkomponenter. Ser du noen noen gang rive i stykker og se på hvilken av disse underkomponentene som er mest relevant for det jeg faktisk gjør?"
Mario Serrafero: "Noen ganger gjør vi det."
Travis Lanier: "Kanskje dere gjør det. Dere er som en uteligger. Men som kanskje en CPU er bedre på dette og kanskje en er bedre på en annen. Det samme med SPEC, folk vil fremheve den ene SPEC, vel, ok, det er mange forskjellige arbeidsmengder innenfor det. Og det er ganske trange ting, men til og med SPEC, som vi faktisk bruker for å utvikle CPUer, hvis du ser på de faktiske arbeidsbelastningene, er de faktisk relevante? Det er flott for å sammenligne arbeidsmengder på arbeidsstasjoner, men driver jeg virkelig med molekylær modellering på telefonen min? Nei. Men igjen, det er poenget mitt er at de fleste av disse benchmarkene er nyttige på en eller annen måte, men du må forstå konteksten for hva [det er] for og hvordan du kommer dit. Og derfor er det veldig vanskelig å destillere ting ned til ett tall.
Og jeg ser dette spesielt – jeg svinger litt her – men jeg ser dette med AI akkurat nå, det er knallbra. Jeg ser at det er et par forskjellige ting som ikke vil få ett tall for AI. Og så mye som jeg snakket om CPU, og du har alle disse forskjellige arbeidsbelastningene, og du prøver å få ett tall. Holy moly, AI. Det er så mange forskjellige nevrale nettverk, og så mange forskjellige arbeidsbelastninger. Kjører du den i flytende komma, kjører du den i int, kjører den i 8 eller 16 bit presisjon? Og så det som har skjedd er at jeg ser folk prøver å lage disse tingene, og vel, vi valgte denne arbeidsmengden, og vi gjorde det i flytende komma, og vi skal vekte 50 % av testene våre på dette ene nettverket og to andre tester, og vi vil vekte dem på dette. Ok, er det noen som faktisk bruker den spesielle arbeidsmengden på nettet? Noen reelle applikasjoner? AI er fascinerende fordi den beveger seg så fort. Alt jeg forteller deg vil sannsynligvis være feil om en måned eller to. Så det er også det som er kult med det, fordi det endrer seg så mye.
Men det største er ikke maskinvaren i AI, det er programvaren. Fordi alle bruker det har, som, jeg bruker dette nevrale nettet. Og så i utgangspunktet er det alle disse multiplikatorene der. Har du optimalisert det bestemte nevrale nettverket? Og så optimaliserte du den for referansen, eller optimaliserer du den slik at noen vil si at du vet hva jeg har laget en benchmark som måler superoppløsning, det er en benchmark for en superoppløsning AI. Vel, de bruker dette nettverket, og de kan ha gjort det i flytende komma. Men hver partner vi engasjerer oss med, har vi enten klart å gjøre det 16 bit og/eller 8 bit og bruke et annet nettverk. Så betyr det at vi ikke er gode på superoppløsning, fordi dette arbeidet ikke samsvarer med det? Så mitt eneste poeng er at AI-benchmark[ing] er veldig komplisert. Synes du CPU og GPU er komplisert? AI er bare gal."
Mario Serrafero: "Ja, det er for mange typer nettverk, for mange parameteriseringer - forskjellig parameterisering fører til forskjellige konsekvenser, hvordan det beregnes."
Travis Lanier: "Det vil holde anmelderne opptatt."
Mario Serrafero: "Men som hvis du vil måle hele bredden av ting, er det mye vanskeligere. Men ja, ingen gjør det."
Mishaal Rahman: "Det er derfor dere fokuserer mer på brukstilfellene."
Travis Lanier: "Jeg tror til slutt, når du viser brukstilfeller, er det hvor god AI din er akkurat nå. Det kommer ned til programvaren, jeg tror den vil modnes litt mer om noen år. Men akkurat nå er det bare så mye programvare som må gjøres og deretter endringer som, ok, vel, dette nettverket er varmt og så som neste år, "Å, nei, vi fant et nytt nettverk som er mer effektivt i alle disse tingene," så da må du gjøre om programvare. Det er ganske sprøtt."
Mario Serrafero: "Apropos NN, du gjorde på en måte overgangen for meg, mindre vanskelig overgangstenkning for meg. Går videre til Hexagon. Dette er på en måte en av komponentene som er minst forstått, vil jeg si, av forbrukere, til og med de fleste entusiaster, absolutt mine kolleger. Du vet, spesielt med tanke på at den ikke ble introdusert som en AI-blokk, og liksom hele ideen om digital signalbehandling, du vet, når du introduserer noe den opprinnelige ideen holder seg på en måte, så hvis du gjør for å gjøre noe, ok, det er en nevral ting med den nevrale, nevrale, nevrale hjerneintelligensen, den henger på en måte med mennesker. De har AI maskinlæring nevrale, nevrale, nevrale etiketter for andre løsninger. Så vi vil kanskje gi deg en sjanse til å forklare utviklingen av Hexagon DSP, hvorfor du ikke har gått bort fra det type ingeniør-lyd navn som Hexagon DSP, vektorutvidelser og så videre som ikke er som markedsføring vennlig. Men ja, akkurat som kanskje som en rask oversikt over hvordan det har vært for deg i forkant av DSP å se det gå fra begynnelsen av bildebehandlingsarbeidet til den splitter nye tensorakseleratoren."
Travis Lanier: "Det er faktisk et interessant poeng fordi noen av konkurrentene våre faktisk har noe de vil kalle en nevral motor eller en nevral akselerator - det er faktisk en DSP, det er det samme. Så jeg antar at navnet er viktig, men du kom inn på et viktig poeng, og ærlig talt da vi la dette ut var det for bildebehandling, vi støttet tilfeldigvis 8 bit. Og jeg husker at vi presenterte på Hot Chips og Pete Warden fra Google sporet oss på en måte og sa: "Hei, dere...så dere støtter 8 bit, ikke sant?" Ja, det gjør vi. Og så derfra gikk vi umiddelbart ut og liker, hei, vi har alle [disse] prosjektene på gang. Det var da vi gikk og porterte TensorFlow til Hexagon, fordi det er som, hei, vi har en slik 8-bits støttet vektorprosessor der ute for å gjøre det, og det var på vår Hexagon DSP. Hvis jeg måtte gå om igjen, ville jeg sannsynligvis kalt den Hexagon Neural Signal Processor. Og vi har fortsatt den andre DSP-en, vi har skalære DSP-er, og det er en DSP i egentlig forstand. Og så kaller vi denne typen vektor-DSP. Kanskje vi burde gi det nytt navn, kanskje vi burde kalle det en nevral signalprosessor fordi vi sannsynligvis ikke gir oss selv så mye kreditt som vi burde for dette fordi, som jeg sa, noen mennesker de bare har vektor-DSP-er og de kaller det uansett, og de har ikke avslørt hva som helst Det er. Svarte jeg på spørsmålet ditt?"
Hexagon 690 Oversikt. Kilde: Qualcomm.
Mario Serrafero: "Så, ja, det stemmer nok det meste."
Travis Lanier: "Hva var det andre spørsmålet?"
Mario Serrafero: "Akkurat slik du så på en slik utvikling internt. Hvordan har det vært: opplevelsen, vanskelighetene, utfordringene, hva enn du vil fortelle oss om? Hvordan [har] du sett utviklingen fra begynnelsen av bildebehandlingen til tensorakseleratoren?"
Travis Lanier: "Det har vært litt frustrerende fordi det er som at det som får meg til å krype er at noen av pressen vil rekke opp hånden og si: "Qualcomm, hva du står bak! Hvorfor gjorde du ikke—Når kommer du til å bli som en dedikert nevral signalprosessor?» og jeg vil bare like banke hodet mitt. Jeg var som om vi var den første som hadde en vektorprosessor! Men når det er sagt, vi redigerer dette, og det vil sannsynligvis fortsette å være flere ting etter hvert som vi lærer mer om AI. Så, vi la til denne andre tingen, og ja, denne er - den gjør bare AI, den gjør ikke bildebehandling som en del av sekskantkomplekset, så du tilbyr... som vi fortsatt kaller det Hexagon DSP, kaller vi hele komplekset Hexagon-prosessoren [for] å prøve å få et fanget navn for hele hexagon-tingen nå. Vi la til ting som faktisk [er] mer direkte beregning, jeg burde ikke si direkte beregning, liker det har denne automatiske administrasjonen av hvordan du gjør dette høyere ordenskartet over hvor du multipliserer matriser."
Mario Serrafero: "Tensorer er faktisk ganske vanskelig for meg å vikle hodet rundt. Det er akkurat som om de på en måte vikler seg rundt seg selv også."
Travis Lanier: "Ja, jeg tenkte at jeg tok mine lineære algebratimer på college. Jeg gjorde det som mann, "Jeg håper jeg aldri trenger å gjøre det igjen!" Og de kom tilbake med hevn. Jeg antar at jeg tenkte: 'Å mann, differensialligninger og lineær algebra er tilbake med en hevn!'"
Mario Serrafero: "Jeg føler at mange av kollegene mine ikke har fått med meg dette. De tror fortsatt at det er dette mystifiserende aspektet ved NPU når det bare er en haug med matrisemultiplikasjon, punktprodukter, ikke-linearitetsfunksjoner, konvolusjoner, [og] så videre. Og jeg tror ikke personlig at den typen nevrale prosesseringsmotornavn hjelper, men det er det som er greia, ikke sant? Hvor mye av det blir enten ikke utvidet, tilslørt, liksom den underliggende matematikken skuffet, av navnekonvensjonene, og hva kan kanskje gjøres? Jeg vet ikke om du tenkte på dette. [Hva] kan gjøres for å informere folk om hvordan dette fungerer? Hvordan er det ikke akkurat som, hvorfor for eksempel, hvorfor DSP kan gjøre det de andre nye nevrale prosesseringsmotorene kan gjøre? Jeg mener, det er bare matematikk, men det ser ikke ut til at brukere, lesere, noen journalister forstår det. Hva kan – jeg sier ikke at det er Qualcomms ansvar – men hva tror du kan gjøres annerledes? Det er sannsynligvis mitt ansvar."
Travis Lanier: "Ærlig talt, jeg begynner å overgi meg. Kanskje vi bare må kalle ting «nevrale». Vi snakket nettopp om hvordan lineær algebra og differensialligninger fikk hodet til å snurre da vi begynte å se på disse ting, og så når du begynner å prøve å forklare det til folk som når du begynner å gjøre regresjonsanalysen, ser du på ligningene og sånt, folks hoder eksplodere. Du kan lære de fleste grunnleggende programmering, men når du begynner å lære dem hvordan tilbakepropagasjonsligningene fungerer, kommer de til å se på det, og hodene deres kommer til å eksplodere. Så ja, morsomme greier. De vil ikke se delvise derivater ..."
Mario Serrafero: "Kjeder av partielle derivater, ikke på tvers av skalarer, men på tvers av vektorer og inkludert ikke-lineære funksjoner."
Travis Lanier: "Lykke til med det! Ja, så det er vanskelig, og jeg vet ikke at de fleste vil vite om det. Men jeg prøver: Jeg legger inn en liten ting som: «Hei, alt vi gjør her er vektormatematikk. Vi har en vektorprosessor." Og jeg tror folk ser på det og tenker: "Ok, men jeg vil virkelig ha en nevral akselerator." "Tensor" er fortsatt matematisk, men jeg tror folk kan assosiere det litt mer med AI behandling."
Mario Serrafero: "Kan være som å bygge bro over gapet, det semantiske gapet."
Travis Lanier: "Til slutt tror jeg det har kommet ned til at vi sannsynligvis bare må finne på et annet navn."
All grafikk i denne artikkelen er hentet fra Travis Laniers presentasjon på Snapdragon Tech Summit. Du kan se presentasjonslysbildene her.