Travis Lanier fra Qualcomm satte sig ned med XDA til et interview om Kryo 485 CPU'en i Snapdragon 855 mobilplatformen og markedsføring af Hexagon 690 DSP.
I sidste måned afslørede Qualcomm Snapdragon 855 mobil platform. Snapdragon 855 er den mobile platform, der vil drive de fleste Android-flagskibssmartphones i 2019. Qualcomm har foretaget væsentlige forbedringer fra år til år med deres næste generations mobile platform. Snapdragon 855-mobilplatformen er bygget på en 7nm-fremstillingsproces og tilbyder et imponerende 45% spring i CPU-ydeevne i forhold til Snapdragon 845. Forbedringerne i beregningerne over hele linjen giver Qualcomm mulighed for at prale af fremragende AI-ydeevne på den nye Snapdragon 855. Der er en masse information at pakke ud her, og vi har gjort vores bedste for at vise hvordan Qualcomm har forbedret ydeevne og kunstig intelligens på Snapdragon 855. Vi havde dog stadig vores egne spørgsmål efter produktafsløringen, så vi satte os ned med Travis Lanier, Senior Director of Product Management hos Qualcomm, for at tale om Kryo 485 CPU og AI på Qualcomms nye mobil platform.
Mario Serrafero: "45 % [hop], det er ligesom det største nogensinde. Lad os pakke det ud. Vi har A76-basen, 7nm - det er store bidragydere. Det ser ud til, at lige siden I flyttede væk fra brugerdefinerede kerner, nogle publikationer og publikum har ikke haft meget af en anelse om, hvad Built on ARM-licensen indebærer i forhold til, hvad den kan tillade dig at gøre. Du har været ret hemmelighedsfuld med hensyn til, hvad det indebærer [også]. Nu på scenen for en af de første gange, du har, i hvert fald ud over Q&A, ...men for første gang har du vist, hvad nogle af forbedringerne var, og det er fedt. Så vi spekulerede på, om du kunne tænke dig at uddybe, hvordan Qualcomm tunede Kryo 485 for at presse mere [ud] af ARMs base, uanset om det er en udvidelse af de ting, du har afsløret derovre, eller noget, du ikke har præsenteret."
Travis Lanier: "Så jeg kan egentlig ikke sige for meget mere end andet, hvad der var i mine slides. Måske kan vi på et senere tidspunkt, så vi kan sætte os ned og få nogle eksperter, der rent faktisk har udført arbejdet; Jeg kender diskussionspunkterne på højt niveau. Men som du ved, er A76 allerede et design på højt niveau – det er ret godt. Og det er en af grundene til, at vi så ARMs køreplan. Så jeg tænker, okay, måske skulle vi arbejde tættere sammen med disse fyre, for det så meget stærkt ud. Og bare tilbage til din kommentar om tilpasning versus ARM. Så okay, der er alle disse ting, du kan gøre. Og hvis du laver noget, og det skal have differentiering, så du kan gøre noget hundrede procent eller samarbejde med dem. Og [som i] tidligere år, handler vi lidt mere om integration. Så busser, og hvordan vi tilsluttede systemet, deres sikkerhedsfunktioner, som vi satte ind i CPU'erne, cache-konfigurationer. Nu hvor engagementerne har varet længere, var vi i stand til at lave en dybere tilpasning på denne. Og det var sådan, vi var i stand til at lægge nogle af disse ting derind, som større [uden for drift] udførelsesvinduer, ikke sandt, så du har mere instruktioner under flyvning, er dataforhentning faktisk et af de områder, hvor der sker mest innovation i mikroprocessorindustrien lige nu. Mange af teknikkerne til mange af disse ting er ret ens, alle bruger en TAGE-gren forudsigelse i dag, lige hvor stor du leverer den, ved folk hvordan man laver ude af drift og videresendelse og alt det der til større caches. Men forhåndshentning er der stadig en masse af, det er en af de mørke kunst-ting. Så der foregår stadig en masse innovation i det rum. Så det er noget, vi følte, vi kunne hjælpe med.
Og så bare fordi vi føler, at vi generelt gør et bedre stykke arbejde med... normalt kan vi implementere et design hurtigere end andre kan integrere en procesknude. Og så når vi lægger nogle af disse ting derind, som når du går mere ud af drift, er det mere stress på dit design, ikke? Det er ikke gratis at tilføje alle disse udførelsesting derinde. Så for at kunne gøre det, og ikke have et hit på din fmax. Ja, det er en del af det engagement, vi har med ARM, som hvordan fjerner man dem?"
Mario Serrafero: "Bare af nysgerrighed havde du i præsentationen talt om, at effektivitetsforbedringer ville komme fra forhåndshentningen, talte du om strømeffektivitet, ydeevneforbedringer, lidt af begge?"
Travis Lanier: "Alt ovenstående. Så i sagens natur udfører vi forhåndshentning - du har trukket ting i cachen. Så når du har cachen, der ikke laver så mange hukommelsesadgange, er der nu en bagside til pre-hentning: Hvis du laver for meget pre-fetching, [bruger] du mere hukommelse, fordi du ved, [du] laver for meget spekulativ forhåndshentning, men så vidt, hvis du har ting i, og du trækker de rigtige ting, så går du ikke ud i hukommelsen for at trække det ind der. Så hvis du har en mere effektiv forhenter, sparer du strøm, og du øger ydeevnen."
Mario Serrafero: "Okay, fedt, ja. Ja, jeg havde ikke forventet, at du ville være i stand til at udvide meget mere ud over det, men det er interessant, at hvis du siger det nu tilpasser I mere, og måske er I i stand til at dele mere i fremtiden, så holder jeg øje med det. Så den anden slags head turner, i det mindste blandt folk, jeg er omgivet af, er den primære kerne. Så vi havde forventet en slags mere fleksible klyngearrangementer i et par år nu med [inkluderingen af DynamIQ] og at vi forventede, at andre virksomheder ville bevæge sig væk fra [4+4-arrangementet]. Så to spørgsmål: Hvad var motivet bag den primære kerne? Hvordan gavner den primære kerne brugeroplevelsen, fordi vores læsere gerne vil vide, hvorfor der bare er en ensom kerne derovre, og også hvorfor den ikke er helt ensom? Ville deling af kraftplanet med ydeevneklyngen ikke på en måde afbøde noget af den nytte, du kunne opnå, hvis du brugte DynamIQ og på en måde sidde [det] alene?"
Travis Lanier: "Så lad os først tale om forskellige ure og forskellige spændingsplaner. Så hver gang du tilføjer et ur og hver gang du tilføjer en spænding, koster det penge. Så der er en grænse for antallet af stifter du sætter på pakken, der er flere PLL'er du skal have til forskellige ure og der er bare øget kompleksitet. Så der er en afvejning til at gøre tingene. Vi gik lidt ekstremt på et tidspunkt; vi havde fire forskellige domæner på fire forskellige ure, så det havde vi erfaring med, og det var dyrt. Lidt når man begynder at blive stor. LIDT, du har de små kerner på [den] lille klynge, og de har ikke helt brug for den samme granularitet, så at sige, af et separat ur mellem de små kerner. Ja, det ligger lidt i luften, hvad man gør med dem. Så når du har en stor. LILLE system, så har du omvendt disse store kerner. Nå, okay, sætter du hver af dem på et stort ur? Nå, du kører ikke på dem hele tiden, hvis du faktisk er i en lav nok situation, hvor et ubesat ur alligevel vil køre på en lille kerne. Så egentlig er det sådan at to af dem er gode nok der.
Og så kommer du til, hvor vi havde denne primære kerne, hvor okay, ja, vi har en separat urkerne, som kan løbe op til en højere frekvens. Men disse andre kerner, de andre ydeevneklynger, kan ikke gå op til den samme høje frekvens. Så hvis du vil have den fulde ret til den kerne, skal du have det tredje ur til det. Så hvad gør denne kerne? Det berørte vi lidt. Store ting vil være [appstarteren] og web-browsing. Og hvorfor så kun én kerne? Okay, tingene bliver mere flertrådede nu. For eksempel bevæger spilmotorer - det vender jeg tilbage til om et sekund - meget aggressivt mod flere tråde. Men hvis du ser på de fleste apps, selvom de har flere tråde, vil jeg bruge Pareto-reglen, ligesom de fleste af dem, er 80% af belastningen i én tråd. Så du kan lave [en] app-start, og den kan tænde og lyse på alle 8 kerner. Men mere end sandsynligt er 80% af det i en dominerende tråd - det er i den ene kerne. Webbrowsing er stadig primært, ja javascript, vil jeg sige - webbrowsing er blevet en lille smule bedre med multithreading, hvor du kan have flere billeder, og du kan afkode dem. Men for eksempel JavaScript – [en] enkelt tråd kommer til at køre på én kerne. Så der er et stort antal use cases, der har gavn af at have denne ene kerne, der gik rigtig højt.
Nu har vi tre kerner, der kører lidt på en lavere frekvens, men de er også mere strømeffektive. Og så gerne, når du – jeg ved ikke hvor meget du ved om implementering af kerner – men når du begynder at ramme toppen af frekvensen, og implementeringerne af disse kerner, der er en afvejning af magt, tingene begynder at blive eksponentielle i de sidste par megahertz eller gigahertz, som du har. Ja, og så talte jeg om for et sekund siden, hvor hey, alle spil begynder at blive flertrådede, ligesom alle andre pludselig, hvis du ser tilbage, var der et par spil for ikke så længe siden, og de bruger bare et tråd. Men det er mærkeligt, hvor hurtigt branchen kan ændre sig. Ligesom i det seneste år, halvandet år, er de bogstaveligt talt begyndt at sætte alle disse spil ind i... Jeg er blevet begejstret over disse high fidelity-spil. Og så mens en masse ting, ligesom for seks måneder til et år siden, før, faktisk er vendt over hele Kina. I Kina hører jeg "Jeg er ligeglad med store kerner, giv mig en otte af hvad som helst, giv mig otte af mindste kerner, så jeg kan have otte kerner." De har ændret sig, fordi de vil have disse spil, disse spil kræver store kerner. Og nu får vi feedback fra partnere om, at "nej, vi vil faktisk have fire store kerner," på grund af alle de avancerede spil, der kommer ud. Og de kommer til at bruge alle disse kerner.
Så når du spiller, spiller du ikke i 30 sekunder, eller 5 minutter, du spiller i længere tid. Så det giver mening, vi har disse tre andre kerner i de fleste af dine multithreaded big core use cases, de ønsker at have en lille smule mere strømeffektivitet. Det balancerer på en måde, du har denne kerne med højere ydeevne, når du har brug for den til nogle af disse ting inden for nogle af disse vedvarende tilfælde, hvor de også har store kerner, og du har denne mere strømeffektive løsning at parre med at. Det er sådan en tankegang – det er lidt af en usædvanlig symmetri. Men forhåbentlig svarer det på, hvorfor [der er en] primær kerne, hvorfor har du ikke separate ure, og hvorfor har du ikke separate spændinger? Og så tror jeg, jeg rørte ved alle dem."
Kryo 485 CPU-kernekonfiguration. Kilde: Qualcomm.
Mario Serrafero: "Nu, heterogen beregning. Det er det, Qualcomm har understreget siden overgangen fra den gamle branding til den mobile platform, og den slags [en] deskriptor, og også aggregerende blokke fra at beskrive visse præstationsmålinger som f.eks. AI. Hvordan har den udvikling været ved skiftet til en mere heterogen beregningsmetode? Alt fra design til udførelse til markedsføring, eller hvad du nu kan røre ved."
Travis Lanier: "Det går lidt frem og tilbage. Men i sidste ende er du nødt til at have disse motorer, fordi navnet på spillet i mobil er strømeffektivitet. Nu ser du nogle gange, at det går tilbage til en generalisering en gang imellem. Hvis du går tilbage til din originale, selv for smartphones, havde feature-telefoner multimedie og kamera kapaciteter til en vis grad, og så har de alle disse små dedikerede ting, fordi du ikke kunne gør det. Hvis du går tilbage til de telefoner, der er bygget på ARM 9 eller en ARM 7, havde de alle en hardwareaccelerationswidget til alt.
Men for at give dig et eksempel, hvor noget gik generelt, og så nu beder de om hardware igen, ville være JPEG. Der plejede at være en JPEG accelerator. CPU'en blev til sidst god nok, og den var strømeffektiv nok, og JPEG'erne forblev ligesom samme størrelse som, hey, ved du hvad, vi vil bare gå videre og gøre det på CPU'en [da] det bare er nemmere at gøre det. Nu, efterhånden som billeder bliver større og større, pludselig går folk, du ved, faktisk, jeg ønsker, at disse virkelig gigantiske fotofilstørrelser skal accelereres. CPU'erne [er] på en måde enten ikke hurtige nok eller forbrænder for meget strøm. Det er lige pludselig, at der er interesse for potentielt at have JPEG-acceleratorer igen. Så det er ikke altid en lige linje, hvordan tingene går, så skal du se på, hvad der foregår lige nu med Moores lov. Alle bliver ved med at tale om, hey, du er måske ikke død, men det går lidt langsommere, ikke? Så hvis du ikke får det power boost eller ydeevne boost fra hver næste node, hvordan fortsætter du med at sætte mere funktionalitet på telefonen, hvis du ikke har det overhead? Så du kan bare sætte det på CPU'en. Men hvis du ikke har mere frihøjde til din CPU, hvordan accelererer du så disse ting? Nå, svaret er, at du sætter alle disse specialiserede kerner og ting mere effektivt. Og så er det den naturlige spænding.
Du vil se folk blive tvunget til at gøre disse ting for almindelige funktioner, da måske ikke alle vil være på den blødende kant. Men vi vil bestemt prøve at blive der så længe som muligt, men vi kan ikke tvinge fabs til at flytte til den næste node, hvis den ikke nødvendigvis er der. Så det er derfor, du skal fokusere på kontinuerlig innovation og disse arkitekturer for fortsat at få bedre ydeevne og strømeffektivitet. Så det er vores styrke og vores baggrund."
Mario Serrafero: "Selvom der har været dette skift til heterogen databehandling, fra Qualcomms side, mange publikummer og bestemt mange publikationer, bestemt mange entusiaster, overraskende nok, som du tror ville vide bedre, de tænker stadig på, betragter og vurderer blokkene som separate enheder. De fokuserer stadig på, "Jeg vil gerne se CPU-tallene, fordi jeg bekymrer mig om det." De vil gerne se GPU-numre, fordi de kan lide spil, så videre og så videre. De betragter dem ikke som kommunikerede dele af ét integreret produkt. Hvordan tror du, at Qualcomm har, og er og kan knuse det paradigme, da konkurrenter rent faktisk bliver ved med at fokusere på den specifikke blok-for-blok form for forbedringer i marketing? Specifikt, [vi vil] gå videre til de neurale netværk, neurale motor-ting senere."
Travis Lanier: "Jeg håber, jeg kom ind på noget af det i dag. Vi fokuserer på for eksempel vedvarende gaming, så måske scorer du godt på alle gaming benchmarks. Folk bliver besat af det. Men det, der virkelig betyder noget, er, at hvis du spiller dit spil, forbliver dine billeder per sekund så konsekvent, hvor du vil have det på det højeste punkt for disse ting? Jeg tror, folk lægger alt for meget vægt på et tal for en af disse blokke. Det er så svært, og jeg forstår det ønske om at give mig et nummer, der fortæller mig, hvad det bedste er. Det er bare så praktisk, især i AI lige nu, det er bare skørt. Selv med CPU-benchmarks, hvad måler et CPU-benchmark? De måler alle forskellige ting. Tag ethvert af benchmarks, som GeekBench har en masse underkomponenter. Ser du nogen nogensinde rive fra hinanden og se på, hvilken af disse underkomponenter der er mest relevant for det, jeg rent faktisk laver?"
Mario Serrafero: "Nogle gange gør vi det."
Travis Lanier: "Det gør I måske. I fyre er som en outlier. Men som måske er en CPU bedre til dette og måske er en bedre til en anden. Det samme med SPEC, folk vil fremhæve den ene SPEC, okay, der er mange forskellige arbejdsbelastninger inden for det. Og det er ret stramme ting, men selv SPEC, som vi faktisk bruger til at udvikle CPU'er, hvis man ser på de faktiske arbejdsbelastninger, er de faktisk relevante? Det er fantastisk til at sammenligne arbejdsstationsarbejdsbelastninger, men laver jeg virkelig molekylær modellering på min telefon? Nej. Men igen, det er min pointe, at de fleste af disse benchmarks er nyttige på en eller anden måde, men du er nødt til at forstå konteksten af, hvad [det er] til, og hvordan du når dertil. Og så er det virkelig svært at destillere tingene ned til ét tal.
Og jeg ser dette især - jeg drejer lidt her - men jeg ser det her med AI lige nu, det er narret. Jeg kan se, at der er et par forskellige ting, der ikke ville få ét nummer for AI. Og så meget som jeg talte om CPU, og du har alle disse forskellige arbejdsbelastninger, og du prøver at få ét nummer. Holy moly, AI. Der er så mange forskellige neurale netværk og så mange forskellige arbejdsbelastninger. Kører du det i floating point, kører du det i int, kører det i 8 eller 16 bit præcision? Og så det, der er sket, er, at jeg ser folk forsøge at skabe disse ting, og jamen, vi valgte denne arbejdsbyrde, og vi gjorde det i flydende komma, og vi vil vægte 50 % af vores tests på dette ene netværk og to andre tests, og vi vægter dem på det her. Okay, er der faktisk nogen der bruger den særlige arbejdsbyrde på det net? Nogen rigtige applikationer? AI er fascinerende, fordi den bevæger sig så hurtigt. Alt, hvad jeg fortæller dig, vil sandsynligvis være forkert om en måned eller to. Så det er også det, der er fedt ved det, for det ændrer sig så meget.
Men den største ting er ikke hardwaren i AI, det er softwaren. Fordi alle bruger det har, ligesom, jeg bruger dette neurale net. Og så dybest set er der alle disse multiplikatorer derinde. Har du optimeret det specifikke neurale netværk? Og så optimerede du den til benchmark, eller optimerer du den, så nogle mennesker vil sige, du ved hvad jeg har lavet et benchmark, der måler super opløsning, det er et benchmark på en super opløsning AI. Nå, de bruger dette netværk, og de kan have gjort det i floating point. Men hver partner, vi engagerer os med, har vi enten formået at gøre det 16 bit og/eller 8 bit og bruge et andet netværk. Betyder det så, at vi ikke er gode til super opløsning, fordi dette arbejde ikke matcher det? Så min eneste pointe er, at AI-benchmark[ing] er virkelig kompliceret. Synes du, at CPU og GPU er kompliceret? AI er bare skør."
Mario Serrafero: "Ja, der er for mange typer netværk, for mange parametreringer - forskellig parametrering fører til forskellige påvirkninger, hvordan det beregnes."
Travis Lanier: "Det vil holde anmelderne travlt."
Mario Serrafero: "Men ligesom, hvis du vil måle hele det brede af ting, ja, det er meget sværere. Men ja, ingen gør det."
Mishaal Rahman: "Det er derfor, I fokuserer mere på use cases."
Travis Lanier: "Jeg tror i sidste ende, at når først du viser use cases, så er det så god din AI lige nu. Det kommer ned til softwaren, jeg tror den vil modnes lidt mere om nogle år. Men lige nu er der bare så meget softwarearbejde, der skal udføres, og så ændringer som, Okay, jamen, dette netværk er varmt og derefter som næste år, "Åh, nej, vi fandt et nyt netværk, der er mere effektivt i alle disse ting," så så skal du gå om software. Det er ret skørt."
Mario Serrafero: "Apropos NN, du gjorde på en måde overgangen for mig, mindre akavet overgangstænkning for mig. Går videre til Hexagon. Dette er en af de komponenter, der er mindst forstået, vil jeg sige, af forbrugere, selv de fleste entusiaster, helt sikkert mine kolleger. Du ved, især i betragtning af, at det ikke blev introduceret som en AI-blok, og ligesom hele ideen om digital signalbehandling, du ved, når du introducerer noget den originale idé hænger lidt sammen, så hvis du gør for at gøre noget, okay, det er en neural ting med den neurale, neurale, neurale hjerneintelligens, den hænger lidt sammen med mennesker. De har AI machine learning neurale, neurale, neurale etiketter til andre løsninger. Så vi vil måske give dig en chance for at forklare udviklingen af Hexagon DSP, hvorfor du ikke er gået væk fra det slags engineering-lyd navne som Hexagon DSP, vektorudvidelser og så videre, der ikke er som markedsføring venlige. Men ja, lige som måske som en hurtig gennemgang af, hvordan det har været for dig i spidsen for DSP at se det gå fra begyndelsen af billedbehandlingen til den helt nye tensoraccelerator."
Travis Lanier: "Det er faktisk et interessant punkt, fordi nogle af vores konkurrenter faktisk har noget, de vil kalde en neural motor eller en neural accelerator - det er faktisk en DSP, det er det samme. Så jeg gætter på, at navnet er vigtigt, men du kom ind på et vigtigt punkt, og helt ærligt, da vi lagde det her ud, var det til billeddannelse, vi tilfældigvis understøttede 8 bit. Og jeg kan huske, at vi præsenterede på Hot Chips, og Pete Warden fra Google opsporede os på en måde og sagde: "Hey, du...så I understøtter 8 bit, hva?" Ja, det gør vi. Og så derfra gik vi straks ud og kunne lide, hej, vi har alle disse projekter i gang. Det var da, vi gik og porterede TensorFlow til Hexagon, for det er ligesom, hej, vi har sådan en 8 bit understøttet vektorprocessor derude til at gøre det, og det var på vores Hexagon DSP. Hvis jeg skulle gå om igen, ville jeg nok kalde det Hexagon Neural Signal Processor. Og vi har stadig den anden DSP, vi har skalære DSP'er, og det er en DSP i egentlig forstand. Og så kalder vi denne slags vektor DSP. Måske skulle vi omdøbe det, måske skulle vi kalde det en neural signalprocessor, fordi vi sandsynligvis ikke giver os selv så meget kredit som vi burde for dette, fordi, som jeg sagde, nogle mennesker har bare vektor-DSP'er, og de kalder det hvad som helst, og de har ikke afsløret noget som helst det er. Har jeg svaret på dit spørgsmål?"
Hexagon 690 Oversigt. Kilde: Qualcomm.
Mario Serrafero: "Så, ja, det er nok rigtigt det meste."
Travis Lanier: "Hvad var det andet spørgsmål?"
Mario Serrafero: "Lige hvordan du så den udvikling internt. Hvordan har det været: oplevelsen, vanskelighederne, udfordringerne, hvad end du vil fortælle os om? Hvordan [har] du set udviklingen fra billedbehandlingens begyndelse til tensoracceleratoren?"
Travis Lanier: "Det har været lidt frustrerende, fordi det er som om, at det, der får mig til at ryste mig, er som om nogle af pressen vil række hånden op og sige: "Qualcomm, hvad er du så bagud! Hvorfor gjorde du ikke - Hvornår vil du blive som en dedikeret neural signalprocessor?" og jeg vil bare gerne banke mit hoved. Jeg var, som om vi var den første, der havde en vektorprocessor! Men når det er sagt, vi redigerer dette, og der vil sandsynligvis fortsætte med at være flere ting, efterhånden som vi lærer mere om AI. Så vi tilføjede denne anden ting, og ja, denne er - den gør kun AI, den laver ikke billedbehandling som en del af sekskantkomplekset, så du tilbyder... som vi stadig kalder det Hexagon DSP, kalder vi hele komplekset for Hexagon-processoren [for at] prøve at få et fanget navn til hele hexagon-tinget nu. Vi tilføjede ting, som faktisk [er] mere direkte beregning, jeg skulle ikke sige direkte beregning, som det har denne automatiske styring af, hvordan du laver dette kort af højere orden over, hvor du multiplicerer matricer."
Mario Serrafero: "Tensorer er faktisk ret svære for mig at vikle mit hoved om. Det er i hvert fald ligesom, at de også omgiver sig selv."
Travis Lanier: "Ja, jeg tænkte, at jeg tog mine lineære algebratimer på college. Jeg gjorde det som en mand, "Jeg håber, jeg aldrig behøver at gøre det igen!" Og de kom tilbage med hævn. Jeg tror, jeg tænkte: 'Åh mand, differentialligninger og lineær algebra er tilbage med en hævn!'"
Mario Serrafero: "Jeg føler, at mange af mine kolleger ikke har indhentet dette. De tror stadig, at der er dette mystificerende aspekt ved NPU'en, når det bare er en masse matrixmultiplikation, prikprodukter, ikke-linearitetsfunktioner, foldninger, [og] så videre. Og jeg tror ikke personligt, at den slags neurale processeringsmotornavn hjælper, men det er sagen, ikke? Hvor meget af det bliver enten ikke udvidet, sløret, en slags underliggende matematik skovlet af navnekonventionerne, og hvad kan man måske gøre? Jeg ved ikke, om du tænkte over det her. [Hvad] kan der gøres for at informere folk om, hvordan dette fungerer? Hvordan er det ikke ligesom, hvorfor for eksempel, hvorfor DSP'en kan gøre, hvad de andre nye neurale behandlingsmotorer kan gøre? Jeg mener, det er bare matematik, men det ser ikke ud til, at brugere, læsere, nogle journalister forstår det. Hvad kan - jeg siger ikke, at det er Qualcomms ansvar - men hvad tror du kunne gøres anderledes? Det er nok mit ansvar."
Travis Lanier: "Helt ærligt, jeg begynder at overgive mig. Måske skal vi bare kalde tingene "neurale". Vi har lige talt om, hvordan lineær algebra og differentialligninger fik vores hoveder til at snurre, da vi begyndte at se på disse ting, og så når du begynder at prøve at forklare det til folk, som når du begynder at lave regressionsanalysen, så ser du på ligningerne og sådan noget, folks hoveder eksplodere. Du kan lære de fleste mennesker grundlæggende programmering, men når du begynder at lære dem, hvordan tilbagepropageringsligningerne fungerer, vil de se på det, og deres hoveder kommer til at eksplodere. Så ja, sjove ting. De ønsker ikke at se delvise derivater..."
Mario Serrafero: "Kæder af partielle derivater, ikke på tværs af skalarer, men på tværs af vektorer og inklusive ikke-lineære funktioner."
Travis Lanier: "Held og lykke med det! Ja, så det er svært, og jeg ved ikke, at de fleste mennesker ønsker at vide det. Men jeg prøver: Jeg indsætter en lille ting som: "Hey, alt, hvad vi laver her, er vektormatematik. Vi har en vektorprocessor." Og jeg tror, at folk ser på det og siger: "Okay, men mand, jeg vil virkelig have en neural accelerator." "Tensor" er stadig matematisk, men jeg tror, at folk måske forbinder det lidt mere med AI forarbejdning."
Mario Serrafero: "Det kunne være som at bygge bro over kløften, den semantiske kløft."
Travis Lanier: "I sidste ende tror jeg, det er kommet ned på, at vi nok bare skal finde på et andet navn."
Al grafik i denne artikel er hentet fra Travis Laniers præsentation på Snapdragon Tech Summit. Du kan se præsentationsdiasene her.