Travis Lanier van Qualcomm sprak met XDA voor een interview over de Kryo 485 CPU op het Snapdragon 855 mobiele platform en de marketing van de Hexagon 690 DSP.
Vorige maand onthulde Qualcomm de Leeuwebek 855 mobiel platform. De Snapdragon 855 is het mobiele platform dat in 2019 de meeste Android-vlaggenschip-smartphones zal aandrijven. Qualcomm heeft jaar-op-jaar aanzienlijke verbeteringen aangebracht met hun mobiele platform van de volgende generatie. Het mobiele platform Snapdragon 855 is gebouwd op een 7nm-productieproces en biedt een indrukwekkende sprong van 45% in CPU-prestaties ten opzichte van de Snapdragon 845. Dankzij de verbeteringen in de berekeningen over de hele linie kan Qualcomm bogen op uitstekende AI-prestaties op de nieuwe Snapdragon 855. Er valt hier veel informatie uit te pakken en we hebben ons best gedaan om dit te laten zien hoe Qualcomm de prestaties en AI heeft verbeterd op de Leeuwebek 855. We hadden echter nog steeds onze eigen vragen na de productonthulling, dus gingen we om de tafel zitten met Travis Lanier, Senior Directeur Product Management bij Qualcomm, om te praten over de Kryo 485 CPU en AI op de nieuwe mobiele telefoon van Qualcomm platform.
Mario Serrafero: "45% [sprong], het is de grootste ooit. Laten we dat uitpakken. We hebben de A76-basis, 7 nm – die leveren een grote bijdrage. Het lijkt erop dat sinds jullie afstand hebben gedaan van aangepaste kernen, sommige publicaties en doelgroepen Ik heb nog geen idee wat de Built on ARM-licentie inhoudt in termen van wat deze kan toestaan jij te doen. Je bent behoorlijk geheimzinnig geweest over wat dat inhoudt. Nu sta je voor een van de eerste keren op het podium, in ieder geval na de Q&A's, ...maar voor de eerste keer heb je laten zien wat enkele verbeteringen waren, en dat is cool. We vroegen ons dus af of je zou willen uitleggen hoe Qualcomm de Kryo 485 heeft afgesteld om meer [uit] te halen ARM's basis, of dat nu een uitbreiding is van de dingen die je daar hebt blootgelegd of iets dat je niet hebt gepresenteerd.
Travis Lanier: "Ik kan dus niet veel meer zeggen dan wat er in mijn slides stond. Misschien kunnen we dat op een toekomstige datum doen, zodat we om de tafel kunnen zitten en een aantal experts kunnen vragen die het werk daadwerkelijk hebben gedaan; Ik ken de gespreksonderwerpen op hoog niveau. Maar zoals je weet is de A76 al een ontwerp van hoog niveau: het is behoorlijk goed. En het is een van de redenen waarom we de routekaart van ARM zagen. Dus ik denk: oké, misschien moeten we nauwer met deze jongens samenwerken, omdat het er erg sterk uitzag. En even teruggaand naar uw opmerking over maatwerk versus ARM. Dus oké, er zijn al deze dingen die je kunt doen. En als je iets doet, en het moet gedifferentieerd zijn, dan kun je iets honderd procent doen of met hen samenwerken. En [net als in] voorgaande jaren gaan we iets meer over integratie. Dus bussen, en hoe we op het systeem zijn aangesloten, hun beveiligingsfuncties die we in de CPU's hebben gestopt, cacheconfiguraties. Nu de opdrachten langer duren, hebben we hier een diepere aanpassing aan kunnen doen. En zo konden we een aantal van deze dingen erin stoppen, zoals grotere uitvoeringsvensters, dus je hebt meer instructies tijdens de vlucht, is het vooraf ophalen van gegevens eigenlijk een van de gebieden waar de meeste innovatie plaatsvindt in de microprocessorindustrie direct. Veel van de technieken voor veel van deze dingen zijn redelijk vergelijkbaar, iedereen gebruikt tegenwoordig een TAGE-vertakkingsvoorspeller, Hoe groot je het ook inricht, mensen weten hoe ze out-of-order moeten doen, en doorsturen en al dat soort dingen voor grotere caches. Maar vooraf ophalen, er zijn er nog steeds veel, het is een van die donkere kunstachtige dingen. Er vindt dus nog steeds veel innovatie plaats op dat gebied. Dus dat was iets waarvan we dachten dat we ermee konden helpen.
En dan alleen maar omdat we het gevoel hebben dat we het over het algemeen beter doen met... meestal kunnen wij een ontwerp sneller implementeren dan anderen een procesknooppunt kunnen integreren. En dus als we een aantal van deze dingen erin stoppen, bijvoorbeeld als je meer in de fout gaat, komt er meer nadruk te liggen op je ontwerp, toch? Het is niet gratis om al deze uitvoeringsdingen daarin toe te voegen. Dus om dat te kunnen doen, en geen hit op je te krijgen fmax. Ja, dat maakt deel uit van de betrokkenheid die we hebben bij ARM, hoe krijg je ze voor elkaar?'
Mario Serrafero: "Gewoon uit nieuwsgierigheid had u in de presentatie gesproken over de komende efficiëntieverbeteringen van het vooraf ophalen, had je het over energie-efficiëntie, prestatieverbeteringen, een beetje beide?"
Travis Lanier: "Alle bovenstaande. Dus van nature zijn we bezig met vooraf ophalen: je hebt dingen uit de cache gehaald. Dus als de cache niet zoveel geheugentoegang doet, is er een keerzijde aan het vooraf ophalen: als je te veel vooraf ophaalt, [gebruikt] u meer geheugen omdat u Weet je, [je] doet te veel speculatief prefetchen, maar voor zover, als je dingen erin hebt en je de juiste dingen haalt, dan ga je niet naar het geheugen om het erin te halen daar. Dus als je een efficiëntere prefetcher hebt, bespaar je energie en verhoog je de prestaties."
Mario Serrafero: "Oké, leuk, ja. Ja, ik had niet verwacht dat je nog veel meer zou kunnen uitbreiden, maar het is interessant dat als je dat zegt nu zijn jullie meer aan het aanpassen en misschien kunnen jullie in de toekomst meer delen, dan zal ik daar een oogje op houden. Dus het andere soort blikvanger, tenminste onder de mensen door wie ik omringd ben, is de belangrijkste kern. We verwachtten dus al een paar jaar een soort flexibelere clusterregelingen met [de] opname van DynamIQ en we verwachtten dat andere bedrijven afstand zouden nemen van [de] 4+4-regeling. Dus twee vragen: wat was het motief achter de kernkern? Hoe komt de primaire kern ten goede aan de gebruikerservaring, omdat onze lezers graag willen weten waarom er daar maar een eenzame kern is, en ook waarom het niet helemaal een eenzame kern is? Zou het delen van het energieniveau met het prestatiecluster niet een deel van de hulpprogramma's verminderen die je zou kunnen verkrijgen als je DynamIQ zou gebruiken en het een beetje op zichzelf zou laten staan?"
Travis Lanier: "Laten we het dus eerst hebben over verschillende klokken en verschillende spanningsvlakken. Dus elke keer dat je een klok toevoegt en elke keer dat je een spanning toevoegt, kost het geld. Er is dus een limiet aan het aantal pinnen dat je op de verpakking plaatst, er zijn meer PLL's die je nodig hebt voor verschillende klokken en de complexiteit is alleen maar toegenomen. Er is dus een afweging tussen het doen van dingen. Op een gegeven moment gingen we nogal extreem; we hadden vier verschillende domeinen op vier verschillende klokken, dus daar hadden we ervaring mee en het was duur. Een soort van wanneer je groot begint te worden. LITTLE, je hebt de kleine kernen op [het] kleine cluster en ze hebben niet echt dezelfde granulariteit nodig, om zo te zeggen, van een aparte klok tussen de kleine kernen. Ja, het hangt een beetje in de lucht wat je ermee doet. Dus als je een grote hebt. KLEIN systeem, dan heb je omgekeerd deze grote kernen. Nou, oké, zet je ze allemaal op een grote klok? Nou, daar ben je niet de hele tijd mee bezig, als je je feitelijk in een situatie bevindt die laag genoeg is, waarin een onbezette klok toch op een kleine kern zal draaien. Dus eigenlijk zijn er twee goed genoeg daar.
En dan kom je op het punt waar we deze primaire kern hadden, waar we een aparte klokkern hebben, die naar een hogere frequentie kan lopen. Maar deze andere kernen, de andere prestatieclusters, kunnen niet dezelfde hoge frequentie bereiken. Dus als je het volledige recht op die kern wilt krijgen, moet je daarvoor een derde klok hebben. Dus wat doet deze kern? Daar hebben we het een beetje over gehad. Grote dingen zullen [het] app-opstartprogramma en surfen op het web zijn. En waarom dan maar één kern? Oké, de dingen worden nu meer multithreaded. Game-engines – daar kom ik zo meteen op terug – bewegen zich bijvoorbeeld zeer agressief in de richting van meer threads. Maar als je naar de meeste apps kijkt, zelfs als ze meerdere threads hebben, gebruik ik de Pareto-regel, zoals de meeste van hen: 80% van de belasting zit in één thread. U kunt dus [een] app starten, en deze kan op alle acht kernen worden geactiveerd en oplichten. Maar meer dan waarschijnlijk zit 80% ervan in één dominante draad: het zit in die ene kern. Browsen op het web is nog steeds in de eerste plaats JavaScript, zou ik zeggen. Browsen op het web is een beetje beter geworden met multithreading, waarbij je meerdere afbeeldingen kunt hebben en deze kunt decoderen. Maar bijvoorbeeld JavaScript: [een] enkele thread zal op één kern draaien. Er is dus een groot aantal gebruiksscenario's die baat hebben bij het hebben van deze ene kern die erg hoog is gegaan.
Nu hebben we drie kernen die een beetje op een lagere frequentie draaien, maar ze zijn ook energiezuiniger. En dus, telkens wanneer je – ik weet niet hoeveel je weet over de implementatie van kernen – maar telkens wanneer je de top van de frequentie begint te bereiken, en de implementaties van deze kernen, er is een afweging in macht, dingen beginnen exponentieel te worden in die laatste paar megahertz of gigahertz die je hebben. Ja, en daar sprak ik zojuist over, waar alle games multithreaded beginnen te worden, zoals alle Als je terugkijkt, waren er plotseling een paar games, niet zo lang geleden, en ze gebruiken er maar één draad. Maar het is raar hoe snel de sector kan veranderen. Net als in het afgelopen anderhalf jaar zijn ze letterlijk begonnen met het stoppen van al deze spellen in... Ik ben enthousiast geworden over deze hifi-spellen. En dus terwijl veel dingen, net als zes maanden tot een jaar geleden, voorheen over heel China zijn gegaan. In China hoor ik: "Ik geef niet echt om grote kernen, geef me een acht van wat dan ook, geef me acht van de kleinste kernen, zodat ik acht kernen kan hebben." Ze zijn veranderd omdat ze deze spellen willen, deze spellen vereisen grote kernen. En nu krijgen we feedback van partners dat “nee, we willen eigenlijk vier grote kernen”, vanwege alle geavanceerde games die uitkomen. En ze gaan al deze kernen gebruiken.
Dus als je gamet, game je niet gedurende 30 seconden, of 5 minuten, je gamet langer. Het is dus logisch dat we deze drie andere kernen hebben in de meeste van uw multithreaded grote kerngebruiksscenario's, ze willen een beetje meer energie-efficiëntie hebben. Het is een beetje in evenwicht, je hebt een kern met hogere prestaties als je die nodig hebt voor sommige van deze dingen in sommige van deze aanhoudende gevallen waarin ze ook grote kernen hebben en je deze energiezuinigere oplossing hebt om mee te combineren Dat. Dat is een beetje de manier van denken: het is een beetje een ongebruikelijke symmetrie. Maar hopelijk beantwoordt dit waarom [er een] primaire kern is, waarom heb je geen aparte klokken en waarom heb je geen aparte spanningen? En dus denk ik dat ik ze allemaal heb aangeraakt."
Kryo 485 CPU-kernconfiguratie. Bron: Qualcomm.
Mario Serrafero: "Nu, heterogeen computergebruik. Dat is wat Qualcomm benadrukt sinds de overstap van de oude branding naar het mobiele platform: en dat soort [een] descriptor, en ook het aggregeren van blokken voor het beschrijven van bepaalde prestatiestatistieken, zoals AI. Hoe heeft die evolutie plaatsgevonden bij de overstap naar een meer heterogene computeraanpak? Van ontwerp tot uitvoering tot marketing, of wat je maar kunt bedenken."
Travis Lanier: “Het gaat een beetje heen en weer. Maar uiteindelijk moet je deze motoren hebben, want de naam van het spel op mobiel is energie-efficiëntie. Nu zie je soms dat het af en toe terugkeert naar een generalisatie. Als je teruggaat naar het origineel, hadden featurephones, zelfs voor smartphones, multimedia en camera capaciteiten tot op zekere hoogte en dus hebben ze al deze kleine toegewijde dingen omdat jij dat niet kon doe het. Als je teruggaat naar de telefoons die op de ARM 9 of een ARM 7 zijn gebouwd, hadden ze allemaal voor alles een hardwareversnellingswidget.
Maar om je een voorbeeld te geven: iets ging algemeen en nu vragen ze weer om hardware: JPEG. Vroeger was er een JPEG-versneller. De CPU werd uiteindelijk goed genoeg en was energiezuinig genoeg en de JPEG's bleven min of meer hetzelfde dezelfde grootte dat, hé, weet je wat, we gaan gewoon door en doen het op de CPU [omdat] het gewoon gemakkelijker is om te doen Het. Nu foto's groter en groter worden, willen mensen ineens, weet je, eigenlijk, dat deze werkelijk gigantische fotobestandsgroottes worden versneld. De CPU's [zijn] niet snel genoeg of verbruiken te veel stroom. Het is gewoon plotseling dat er interesse is om mogelijk weer JPEG-versnellers te hebben. Het is dus niet altijd een rechte lijn hoe dingen gaan, dan moet je kijken naar wat er nu aan de hand is met de wet van Moore. Iedereen blijft maar praten over: hé, je bent misschien niet dood, maar het gaat een beetje langzamer, toch? Dus als u niet die powerboost of prestatieverbetering krijgt van elk volgend knooppunt, hoe kunt u dan doorgaan met het toevoegen van meer functionaliteit aan de telefoon als u die overhead niet heeft? Je zou het dus gewoon op de CPU kunnen zetten. Maar als je niet meer ruimte hebt voor je CPU, hoe versnel je deze dingen dan? Het antwoord is: je plaatst al deze gespecialiseerde kernen en dergelijke efficiënter. En dus is het die natuurlijke spanning.
Je zult zien dat mensen gedwongen worden om deze dingen te doen voor algemene functies, omdat misschien niet iedereen op het randje zit. Maar we gaan zeker proberen daar zo lang mogelijk te blijven, maar we kunnen de fabrieken niet dwingen naar het volgende knooppunt te verhuizen als dat er niet noodzakelijkerwijs is. Daarom moet je je concentreren op voortdurende innovatie en deze architecturen om betere prestaties en energie-efficiëntie te blijven krijgen. Dat is dus onze kracht en onze achtergrond."
Mario Serrafero: "Ook al heeft er een overstap naar heterogeen computergebruik plaatsgevonden, van de kant van Qualcomm zijn er veel doelgroepen en zeker veel publicaties, zeker Veel enthousiastelingen, verrassend genoeg, van wie je denkt dat ze het beter zouden weten, beschouwen, beschouwen en evalueren de blokken nog steeds als afzonderlijke blokken entiteiten. Ze concentreren zich nog steeds op: "Ik wil de CPU-cijfers zien, omdat ik daar om geef." Ze willen GPU-nummers zien omdat ze van games houden, enzovoort. Ze beschouwen ze niet als gecommuniceerde onderdelen van één integraal product. Hoe denk je dat Qualcomm dat paradigma heeft, en kan, en kan vernietigen, terwijl concurrenten zich daadwerkelijk blijven concentreren op dat specifieke blok-voor-blok soort verbeteringen in marketing? Concreet gaan we later verder met de neurale netwerken en de neurale motor."
Travis Lanier: "Ik hoop dat ik daar vandaag iets van heb besproken. Wij richten ons bijvoorbeeld op duurzaam gamen, dus wellicht scoor jij goed op alle gaming benchmarks. Mensen raken daar geobsedeerd door. Maar waar het werkelijk om gaat, is dat als je een game speelt, je frames per seconde consistent op de plek blijven waar je wilt dat het op het hoogste punt is voor deze dingen? Ik denk dat mensen veel te veel waarde hechten aan een getal voor een van deze blokken. Het is zo moeilijk, en ik begrijp het verlangen om mij één nummer te geven dat mij vertelt wat het beste is. Het is gewoon zo handig, vooral op dit moment in AI, het is gewoon gek. Wat meet een CPU-benchmark, zelfs met CPU-benchmarks? Ze meten allemaal verschillende dingen. Neem een van de benchmarks, zoals GeekBench een aantal subcomponenten heeft. Zie je ooit iemand uit elkaar scheuren en kijken welke van deze subcomponenten het meest relevant is voor wat ik eigenlijk doe?"
Mario Serrafero: "Soms wel."
Travis Lanier: "Misschien wel. Jullie zijn net een uitbijter. Maar misschien is de ene CPU hier beter in, en misschien de andere beter. Hetzelfde geldt voor SPEC, mensen zullen die ene SPEC benadrukken, nou ja, daar zitten veel verschillende werklasten in. En het zijn behoorlijk krappe dingen, maar zelfs SPEC, die we feitelijk gebruiken voor het ontwikkelen van CPU's, als je naar de werkelijke werklast kijkt, zijn ze dan eigenlijk relevant? Het is geweldig om de werklast van werkstations te vergelijken, maar doe ik echt moleculaire modellering op mijn telefoon? Nee. Maar nogmaals, dat is mijn punt: de meeste van deze benchmarks zijn op de een of andere manier nuttig, maar je moet de context begrijpen van waar [het voor is] en hoe je daar komt. En dus is het erg moeilijk om dingen tot één getal te herleiden.
En ik zie dit vooral – ik draai hier een beetje rond – maar ik zie dit nu met AI, het is gek. Ik zie dat er een aantal verschillende dingen zijn die niet één nummer voor AI zouden krijgen. En dus, net zoals ik het had over CPU, en je hebt al deze verschillende werklasten, en je probeert één getal te krijgen. Heilige moly, AI. Er zijn zoveel verschillende neurale netwerken en zoveel verschillende werklasten. Voer je het uit in drijvende komma, voer je het uit in int, voer je het uit met 8 of 16 bit precisie? En wat er dus is gebeurd, ik zie dat mensen deze dingen proberen te creëren en, nou ja, we kozen voor deze werklast, en we deden het in drijvende komma, en we gaan 50% van onze tests op dit ene netwerk en twee andere tests wegen, en we zullen ze wegen op dit. Oké, gebruikt iemand überhaupt die specifieke werklast op dat net? Zijn er echte toepassingen? AI is fascinerend omdat het zo snel beweegt. Alles wat ik je vertel, zal over een maand of twee waarschijnlijk onjuist zijn. Dus dat is ook het leuke eraan, omdat het zo veel verandert.
Maar het belangrijkste is niet de hardware in AI, maar de software. Omdat iedereen het gebruikt, gebruik ik dit neurale net. En dus staan er eigenlijk al deze vermenigvuldigers op. Heb je dat specifieke neurale netwerk geoptimaliseerd? En zo heb je die voor de benchmark geoptimaliseerd, of optimaliseer je die, zodat sommige mensen zullen zeggen: jij weet je wat ik heb een benchmark gemaakt die superresolutie meet, het is een benchmark voor een superresolutie AI. Welnu, ze gebruiken dit netwerk en misschien hebben ze het in drijvende komma gedaan. Maar elke partner waarmee we samenwerken, is erin geslaagd om het 16 bit en/of 8 bit te doen en een ander netwerk te gebruiken. Betekent dit dat we niet goed zijn in superresolutie, omdat dit werk daar niet bij past? Mijn enige punt is dus dat AI-benchmarks erg ingewikkeld zijn. Denk je dat CPU en GPU ingewikkeld zijn? AI is gewoon gek.”
Mario Serrafero: "Ja, er zijn te veel soorten netwerken, te veel parameterisaties - verschillende parameterisaties leiden tot verschillende gevolgen, hoe deze worden berekend."
Travis Lanier: "Het zal reviewers bezig houden."
Mario Serrafero: ‘Maar als je de hele breedte van de dingen wilt meten, dan is dat een stuk moeilijker. Maar ja, niemand doet het."
Mishaal Rahman: "Daarom concentreren jullie je meer op de gebruiksscenario's."
Travis Lanier: "Ik denk dat als je eenmaal gebruiksscenario's laat zien, je AI op dit moment zo goed is. Het komt neer op de software, ik denk dat deze over een paar jaar nog wat volwassener zal worden. Maar op dit moment is er zoveel softwarewerk dat moet worden gedaan en dan veranderen er dingen als: 'Oké, dit netwerk is hot en dan' zoals volgend jaar: "Oh nee, we hebben een nieuw netwerk gevonden dat efficiënter is in al deze dingen", dus dan moet je het opnieuw doen software. Het is behoorlijk gek."
Mario Serrafero: ‘Over NN gesproken, jij hebt de transitie min of meer voor mij gedaan, en minder lastig transitiedenken voor mij. We gaan verder naar de Zeshoek. Dit is een van de componenten die volgens mij het minst wordt begrepen door consumenten, zelfs door de meeste enthousiastelingen, en zeker door mijn collega's. Weet je, vooral gezien het feit dat het niet werd geïntroduceerd als een AI-blok, en net als het hele idee van digitale signaalverwerking, weet je, als je iets introduceert dat originele idee blijft hangen, dus als je iets doet, oké, het is een neuraal iets met de neurale, neurale, neurale hersenintelligentie, het blijft een beetje hangen bij mensen. Ze hebben de AI machine learning neurale, neurale, neurale labels voor andere oplossingen. Dus we willen je misschien een kans geven om de evolutie van de Hexagon DSP uit te leggen, waarom je daar niet van bent afgeweken soort technisch klinkende namen zoals Hexagon DSP, vectorextensies, enzovoort die niet lijken op marketing vriendelijk. Maar ja, misschien net als een kort overzicht van hoe het voor jou is geweest in de voorhoede van DSP om het te zien evolueren van het begin van de beeldvormingswerklast naar de gloednieuwe tensorversneller."
Travis Lanier: "Het is eigenlijk een interessant punt, omdat sommige van onze concurrenten eigenlijk iets hebben dat ze een neurale motor of een neurale versneller noemen - het is eigenlijk een DSP, het is hetzelfde. Dus ik denk dat de naam belangrijk is, maar je hebt een belangrijk punt aangestipt en eerlijk gezegd, toen we dit naar buiten brachten, was het voor beeldvorming, we ondersteunden toevallig 8 bit. En ik herinner me dat we presenteerden bij Hot Chips en Pete Warden van Google ons opspoorde en zei: "Hé, jij... dus jullie ondersteunen 8 bit, hè?" Ja, dat doen we. En dus gingen we meteen op pad en zeiden: hé, we hebben al [deze] projecten aan de gang. Dat is het moment waarop we TensorFlow naar Hexagon hebben geport, omdat het is alsof we een 8-bits ondersteunde vectorprocessor hebben om dat te doen, en die stond op onze Hexagon DSP. Als ik het helemaal opnieuw zou moeten doen, zou ik het waarschijnlijk de Hexagon Neural Signal Processor noemen. En we hebben nog steeds de andere DSP, we hebben scalaire DSP's en dat is een DSP in de meest ware zin van het woord. En dan noemen we dit soort een vector-DSP. Misschien moeten we het een andere naam geven, misschien moeten we het een neurale signaalprocessor noemen, omdat we onszelf waarschijnlijk niet zoveel lof geven als we zouden doen. zou hiervoor moeten zijn, omdat, zoals ik al zei, sommige mensen gewoon vector-DSP's hebben en het hoe dan ook noemen, en ze hebben niets onthuld het is. Heb ik je vraag beantwoord?"
Hexagon 690 Overzicht. Bron: Qualcomm.
Mario Serrafero: "Dus ja, dat klopt waarschijnlijk voor het grootste deel."
Travis Lanier: "Wat was de tweede vraag?"
Mario Serrafero: ‘Net hoe je die ontwikkeling intern zag. Hoe was het: de ervaring, de moeilijkheden, de uitdagingen, waar je ons ook over wilt vertellen? Hoe [heb je] de evolutie gezien vanaf het begin van de beeldverwerking tot de tensorversneller?"
Travis Lanier: "Het was een beetje frustrerend, want het ding dat me doet ineenkrimpen is dat een deel van de pers zijn hand opsteekt en zegt: 'Qualcomm, waar loop je zo achter! Waarom heb je niet... Wanneer krijg je een speciale neurale signaalprocessor?' en ik wil gewoon op mijn hoofd slaan. Het leek alsof we de eerste waren met een vectorprocessor! Maar dat gezegd hebbende, we bewerken dit en er zullen waarschijnlijk nog meer dingen gebeuren naarmate we meer leren over AI. Dus we hebben nog iets toegevoegd en ja, dit is: het doet alleen AI, het doet geen beeldverwerking als onderdeel van het zeshoekcomplex, dus je biedt aan … aangezien we het nog steeds de Hexagon DSP noemen, noemen we het hele complex de Hexagon-processor [om] te proberen een vastgelegde naam te krijgen voor het hele hexagon-ding nu. We hebben dingen toegevoegd die eigenlijk directer berekenen, ik zou niet zeggen direct berekenen, zoals dit heeft dit automatische beheer van hoe u deze hogere orde kaart maakt van waar u zich vermenigvuldigt matrixen."
Mario Serrafero: "Tensoren zijn eigenlijk best moeilijk voor mij om mijn hoofd omheen te wikkelen. Het is toch net alsof ze zich ook een beetje om zich heen wikkelen.
Travis Lanier: "Ja, ik dacht dat ik mijn lessen lineaire algebra op de universiteit had gevolgd. Ik deed dat als man: "Ik hoop dat ik dat nooit meer hoef te doen!" En ze kwamen terug met wraak. Ik denk dat ik dacht: 'Oh man, differentiaalvergelijkingen en lineaire algebra zijn terug van weggeweest!'"
Mario Serrafero: "Ik heb het gevoel dat veel van mijn collega's dit nog niet hebben ingehaald. Ze denken nog steeds dat er een raadselachtig aspect aan de NPU zit als het alleen maar een hoop matrixvermenigvuldigingen, puntproducten, niet-lineariteitsfuncties, convoluties, enzovoort is. En ik denk persoonlijk niet dat dat soort naam voor de neurale verwerkingsmotor helpt, maar dat is het punt, toch? Hoeveel ervan wordt niet uitgebreid, verduisterd, de onderliggende wiskunde weggevaagd door de naamgevingsconventies, en wat kan er misschien worden gedaan? Ik weet niet of je hierover hebt nagedacht. [Wat] kan er worden gedaan om mensen te informeren over hoe dit werkt? Hoe het niet alleen is, waarom bijvoorbeeld, waarom de DSP kan doen wat de andere nieuwe neurale verwerkingsmotoren kunnen doen? Ik bedoel, het is gewoon wiskunde, maar het lijkt erop dat gebruikers, lezers en sommige journalisten dat niet begrijpen. Wat kan – ik zeg niet dat het de verantwoordelijkheid van Qualcomm is – maar wat zou er volgens jou anders kunnen worden gedaan? Het is waarschijnlijk mijn verantwoordelijkheid."
Travis Lanier: "Eerlijk gezegd begin ik me over te geven. Misschien moeten we de dingen gewoon 'neuraal' noemen. We hadden het er net over hoe lineaire algebra en differentiaalvergelijkingen ons hoofd deden duizelen toen we ernaar gingen kijken Dus als je dat aan mensen probeert uit te leggen, zoals wanneer je de regressieanalyse begint te doen, kijk je naar de vergelijkingen en zo, de hoofden van mensen ontploffen. Je kunt de meeste mensen basisprogrammering leren, maar als je ze begint te leren hoe de backpropagation-vergelijkingen werken, zullen ze daarnaar kijken en hun hoofden zullen ontploffen. Dus ja, leuke dingen. Ze willen geen gedeeltelijke afgeleiden zien..."
Mario Serrafero: "Ketenen van gedeeltelijke afgeleiden, niet over scalairen maar over vectoren en inclusief niet-lineaire functies."
Travis Lanier: "Succes daarmee! Ja, dus het is moeilijk en ik weet niet dat de meeste mensen dat willen weten. Maar ik probeer het: ik stop er iets in als: 'Hé, het enige wat we hier doen is vectorwiskunde. We hebben een vectorprocessor.” En ik denk dat mensen daarnaar kijken en zeggen: 'Oké, maar man, ik wil echt een neurale gaspedaal." ‘Tensor’ is nog steeds wiskundig, maar ik denk dat mensen dat misschien wat meer associëren met AI verwerken."
Mario Serrafero: "Het zou zoiets kunnen zijn als het overbruggen van de kloof, de semantische kloof."
Travis Lanier: "Uiteindelijk komt het er denk ik op neer dat we waarschijnlijk gewoon een andere naam moeten verzinnen."
Alle afbeeldingen in dit artikel zijn afkomstig van de presentatie van Travis Lanier op de Snapdragon Tech Summit. U kunt de presentatiedia's bekijken hier.