Inlägg

Inlägg som Yoshman har skrivit i forumet
Skrivet av lillaankan_i_dammen:

Det största problem med linux tycker jag att det konstigt nog inte finns en riktigt bra rdp klient. Det är några halvdana som håller samma låga kvalite som androids, där t.om microsofts i ndroid är dålig jämfört emot den inbyggda i windows.

Testat NX Nomachine? Bästa RDP jag någonsin kört och numera finns denna även till Windows och MacOS (men inte testat dessa).

Fast vad ska man med RDP till nu för tiden? Det som behöver en UI över nätverk 2020 är väl ändå webbaserat och resten kör man via kommandotolken över SSH!

Skrivet av Aka_The_Barf:

Win finns väll redan som stöder arm? Iallafall på vissa mobila enheter?
Finns det några fördelar med x86 alls? Kan väll inte ha klarat sig såhär länge för att det är värdelöst?

Du missar en extremt viktigt detalj här: "ARM" är för generellt för 32-bit ARM var bättre än x86 på vissa saker men sämre på andra, det finns tekniska orsaker till varför 32-bit ARM aldrig skalades upp till samma prestandanivå som x86.

Fanns de som trodde 32-bit ARM skulle ta över också, själv såg jag aldrig hur det skulle gå till då man låg rejält efter x86 i prestanda per kärna. Det bl.a. p.g.a. designbeslut i 32-bit ISA som gjorde det extremt svårt att designa väldigt "breda" (hög IPC) CPUer med 32-bit ARM. Detta problem är definitivt löst i ARM64!

Det har bara gått 10 år sedan ARM64 lanserades. ARM64 är inte en utökning av 32-bit ARM, det är helt ISA designad helt från scratch där man bl.a. försökt tittat på vad som hindrade tidigare CPUer från att skalas upp sett till mängd utförd arbete per cykel. Endera lyckades ARM extremt bra med detta, alternativt är AMD/Intel totalt värdelös på CPU-design då Apple redan nu har en CPU som utför ~80 % mer per cykel ställt mot Zen2/Skylake medan ARM har en som utför ~30 % mer (och man har lanserat Cortex X1 som förväntas utföra ~60 % mer per cykel).

Rocket Lake förväntas öka IPC lika mycket som Ice Lake (Sunny Cove), d.v.s. 18-20 %. Det lägger dem fortfarande efter ARM Cortex A77 som lanserades maj 2019 och som kan implementeras på ~1/3 av kretsytan av Zen 2 på samma TSMC 7 nm process.

Vad x86 designerna fortfarande har som klar fördel är att de kan klockas betydligt högre, 4,5 - 5 GHz mot ~3 GHz för ARM (gäller både Apples och ARM Cortex A). Går självklart att designa en ARM64 CPU som klockar lika högt, men frågan är hur mycket IPC man får offra för det samt hur mycket man förlorar i perf/W. Så för desktop (d.v.s. där perf/W är rätt irrelevant) har x86 fortfarande ledning, för bärbara och servers har man tappat den (och ser inte hur de skulle kunna få tillbaka den där).

Som redan påpekats är programvara långt viktigare än HW, så även här. Windows ARM stöd är bedrövligt just nu, så ingen behöver känna direkt oro över att x86 försvinner i närtid. Min undran är: varför skulle man inte vilja att x86 ersätts även på Windows då ARM64 rimligen är tekniskt bättre (alt så är Apple och ARM brutalt mycket mer kompetenta i CPU-design jämfört med AMD och Intel, vilket för mig känns rätt osannolikt givet hur mycket mer erfarenhet de två senare har).

Sätter vi Zen2/Skylake som "baseline" borde detta gälla när vi går in i 2021

  • Intel har något med ~20 % högre IPC på desktopsidan/server (och förväntar mig att Rocket Lake klockar ~5 GHz, den är poänglös annars) och ~25 % högre IPC på bärbara (och här verkar man nu också fått ordning på maxfrekvens, ryktet säger 4,7 GHz max boost)

  • AMD har något med, enligt rykten, 15-20 % högre IPC på desktop/server. Väldigt lite har sagts om frekvenser

  • Apple lär ha något med minst 80 % högre "IPC" då det är vad man har med A13, om man håller sin tidigare relativa ökning borde man hamna på ~100 % högre IPC vilket betyder att även vid 3 GHz är man snabbare än någon i dag existerande CPU (oavsett ISA)

  • ARM Cortex X1 förväntas som sagt hamna på ~60 % högre "IPC" och klocka "upp till 3,3 GHz" enligt ARM

Kanske Intel/AMD håller igen (hur troligt är det?), men ser ändå rätt mycket ut som x86 har fundamentala begränsningar. Självklart har alla CPU-designer fundamentala begränsningar, "väggen" verkar dock flyttad en hyfsad bit med ARM64.

Intel har aldrig behövt sin ledning i processteknik så mycket som nu, men tyvärr för dem är det lite småproblem där. De kanske reder upp detta och i så fall kan man eventuellt återta ledning i absolut enkeltrådprestanda. Intel har faktiskt pratat om att efterföljaren till Willow Cove, Golden Cove, ska få hela 50 % högre IPC jämfört med Skylake. Vi får se om något år vad som händer!

Skrivet av Petterk:

@Yoshman: Min poäng är dock att det inte finns någon vettig uppdelning mellan dessa koncept. Alla moderna GPUer (Intel, AMD och Nvidia) och nästa generations konsoler (AMD) är dessutom TBIM, oavsett vad du använder för APIer och extensions.

Vet inte hur det är idag, men ~2011 kunde bara PowerVR köra "order independent hidden surface removal", idag kan såklart Apple göra dito, då deras arkitektur bara är en fortsättning både när det gäller drivrutiner och hårdvara. Både Mali och Adreno har därför beskrivits som IMR i litteratur, även om det inte handlar inte om ren IMR internt. Du kan ha TBR internt utan alla fördelar med TBDR-arkitekturer som PowerVR. ARM börja inte prata om TBDR fören Mali-T600/700/800 och framåt, men det betyder ju inte att det är likställt Apple.

Så vitt jag vet kan ingen annan GPU än PowerVR och Apples än idag köra "order independent hidden surface removal" (tbd-hsr). ARM kallar Malis arkitektur sedan T600/700/800 för "Tile-based deferred rasterization with hierarchical tiling". I någon mån kan man fortfarande räkna Adreno och Mali till "Tile-based deferred rasterization", vilket inte kan likställas med Apples arkitektur.

Tilingfunktioner exponeras numera även på PC:ns GPUer, så väl som i nästa generationens konsoler. För de som inte skriver drivrutiner eller utvecklar GPUer betyder det inte särskilt mycket, för de som optimerar programvara så måste de fortfarande följa olika guider för olika GPUer och olika generationer från samma tillverkare. TBDR är bara en del av PowerVRs och Apples koncept, så det kommer ske fragmentering vilket som. De närmsta åren kommer säkert de som porterar spel dessutom uppmanas att skeppa Universal.

Om jag förstått beskrivningarna rätt så är den tekniskt relevanta skillnaden hur olika GPUer hanterar övergången till rastreringssteget i denna bild (denna för Vulkan men samma gäller ju för DX12 och Metal). De gula stegen är helt dynamiska medan de gröna stegen är "fixed-function" och därmed alltid har vissa saker som händer

Mobil GPUerna, de som måste hanteras som "tile-based", ser inte bara som en cache att samla ihop exakt hela scenen innan rastrering startar utan de skriver ut mellanläget i RAM om så behövs. För Maxwell, gen11 och vilken AMD-generation som nu börjar köra med "tiles" är det "bara en cache", så för den gäller fortfarande den första bilden i mitt föregående inlägg men det som markeras "fifo" är relativt stort och hanteras i "tiles".

Så även för Maxwell är det fortfarande positivt att generera geometri via tesselering, det medför mindre cache-hit rate vid rastrering men där finns ändå bandbredden att hantera situationen. Att det bara är en cache för Maxwell/Pascal syns bl.a. i att tile-storleken är helt dynamiskt och för små trianglar verkar man inte ens använda "tiles".

För de GPUer som i grunden är "tile-based" finns inget alternativ (undantaget Adreno men verkar inte var speciellt effektivt om den inte kör med tiles), tile-storleken är fix och får inte geometrin plats i cache så spiller den ut i RAM -> försämrar effektiviteten men finns inget alternativ då bandbredden att köra något annat saknas (framförallt givet de höga upplösningar mobiler normalt kör med).

Den här diskussionen utmynnande i något positivt för egen del i alla fall. Har haft på "att-göra-listan" att sätta mig i Vulkan, har nu satt igång bl.a. för att testa det vi diskuterat här på Nvidia, Intel och Mali (är de jag har på enheter som stödjer Vulkan, får sätta mig i Metal när den ARM-baserade Mac:en är inhandlad).

Skrivet av Petterk:

@Yoshman: Enligt ARM så kör de TBIM, möjligt att de gått över till ren TBDR på senare GPUer också, och de har definitivt exponerat mer för utvecklare. Möjligt att de kan köra båda precis som Qualcomm. Hur som helst tiling-features och interna funktioner finns där på alla moderna GPUer, så det är inget stort skifte mellan olika plattformar längre, men alla GPUer är unika och det är inget som alla som är inblandade i projekten behöver hålla koll på utan de som har koll får kommunicera med sitt team. Det är förmodligen bara PowerVR och Apple som har "order independent hidden surface removal", så jag är inte säker på att man kan beskriva senare Malis som likställda med Apples GPUer heller.

Olika features på olika plattformar är inget konstigt, och i det stora hela betyder inte proprietära extensions till olika APIer särskilt mycket för ett spel eller en applikation i stort. Det är fortfarande väldigt mycket av GPU-arkitekturen som spelutvecklare inte exponeras för.

Större titlar för ARM-macar kommer porteras från Windows eller konsol-versionerna, så jag väntar mig inte det blir awesome.

Apples GPUer kommer förändras med tiden som alla andra också, så de kommer skapa fragmentering i sitt eget ekosystem. Därför inte allt är exponerat eller betydelsefullt för applikations och spelutvecklare för den delen, och därför de kommer behöva stödja olika feature-set hur som helst.

Tror jag ser hur vi helt pratar förbi varandra nu, vilket förstärks av att namngivning används inkonsekvent.

Även din länk har ju en referens till där Mali helst bör använda på ett sätt som inte är logiskt konsekvent med "normal" immediate mode forward rendering (och samma sak gäller Apples GPUer)

"An important aspect of the tile based rendering strategy that Mali uses, is that the tilebuffer is cleared each time you start processing a new tile. When the framebuffer content has to be preserved, from the previous frame, that is, EGL_SWAP_BEHAVIOR set to EGL_BUFFER_PRESERVED, this imposes a performance impact because the previous content has to be loaded for each tile before new content can be processed for that tile."

I Metal och även Vulkan finns allt fler finesser man kan använda sig av för att i större utsträckning utnyttja styrkorna i mobil GPUers tile-design. Som t.ex. att låta vissa bufferttyper vara transient, d.v.s. ett scratchpad minne som aldrig skrivs ut till RAM (vilket det i normalfallet skulle behöva göras för att fungera på ett "normalt" sätt).

Vad jag kan hitta har Mali, HW-mässigt, alltid använt sig av tiles av 16x16 pixels samma gäller även för PowerVR och Apples GPU-design. Qualcomms Adreno är här uddafågeln som HW-mässigt även stödjer den traditionella modellen som använd på dagens konsoler och PC.

"Immediate renderering" är inte en referens till HW-design, det är en referens till API-design. Motsatsen är inte tiles eller "deferred rendering", utan "retained rendering". Nu är det definitivt enklare att hantera skillnader i HW-design när man kör "retained rendering" den modellen används också på flera ställen, bl.a. presentationslagret för iOS och MacOS.

Men DX, OpenGL, Vulkan och Metal är alla exempel på "Immediate renderering" APIer.

Vad PC GPUer implementerar är denna modell

medan alla de GPUer som använder sig av tiles kör med denna modell. Notera att den viktiga skillnaden här är att "Immediate rendering" APIer rent logiskt fungerar så att varje kommando tar effekt direkt, men i praktiken fungerar ingen modern GPU på det sättet då det är ineffektivt (väldigt lågt cacheutnyttjande och därmed enorma bandbredds och strömkrav).

De GPUer som är "tile based" har ett extra stop precis när man går över till "screen-space", innan fragment shaders. Logiskt sett kan man helt ignorera den detaljen, praktiskt sett måste man ta hänsyn till detta då vissa saker som är dyrt på en traditionell GPU är väldigt billigt i denna modell och vice versa.

För att förvirra än mer finns ju också "forward rendering" och "deferred rendering" där det senare konceptuellt är samma sak som HW-mässiga tiles, men här refererar "deferred" till en annan del i pipeline (i detta fall är det ljussättning som är "deferred", så en delmängd av fragment shading).

Forward rendering för PC-titlar
Deferred rendeding för PC-titlar

Enda poängen är egentligen: jag tror det är bra för MacBook-serien att Apple-utvecklarna helt kan förutsätta att GPU-HW är tile-based. Detta då denna modell är optimal för GPUer som måste dela RAM-bandbredd med CPU och har väldigt lågt TDP-tak. Det gör också att Apple helt kan designa Metal runt en modell som är optimalt för den här typen av GPU-design!

Intel/AMD kan inte riktigt ta steget ditt för sina iGPUer då normalfallet för PC är dGPU när man pratar om 3D-prestanda, DX11/DX12 är helt designad runt GPUer med traditionell design.

I övriga program används ju ändå "retained rendering", så de kommer inte ha några problem med ändringen i MacOS.

Skrivet av Petterk:

@Yoshman: Fast Mali är IMR/TBIMR precis som nästa generations konsoler och nuvarande generationens grafikkort. Optimeringar är det få som jobbar med spelutvecklingen som behöver bry sig om, de flesta kommer jobba mot spelmotorn och inte optimera spelmotorn mot olika APIer, och du har ju inte olika spelmotorer för olika GPUer. Om en GPU är TBIMR eller TBDR är inget utvecklare behöver bry sig om i någon större mening, någon form av tilebaserad rendering finns där vilket som.

Enligt ARM gäller detta för Mali

"Mali GPUs use tile-based deferred rendering."

För både Unity och Unreal-engine måste man förstå vad som är lämpligt och inte lämpligt att göra när man kör med TBDR. Så även om man går via spelmotorer går det fortfarande inte att ignorera beskaffenheten i underliggande HW, i alla fall inte om man vill ha någon form av effektivitet.

Det verkar som vissa, t.ex. Qualcomms GPUer, kan köras i IMR läge. Men det kommer fungerar bara för väldigt enkla fall då dessa enkla kretsar inte har vare sig TDP-utrymmet eller RAM-bandbredden att hantera IMR på ett vettigt sätt.

Apple beskriver saker som är möjligt i Metal på deras GPUer, men inte på dagens Mac:ar då de inte använder sig av TBDR. D.v.s. i vissa lägen är IMR vs TBDR inte bara en prestandamässig leaky-abstraction utan det påverkar även hur man kan använda Metal!

"macOS GPUs have an immediate mode rendering (IMR) architecture. On IMR GPUs, a deferred lighting renderer can only be implemented with at least two render passes. "

"Single-Pass Deferred Lighting on iOS and tvOS GPUs" [möjligen enbart p.g.a. HW-stöd för TBDR]

Ännu ett exempel på där denna abstraktion läcker ända upp i applikationer.

Hade inte problemen ovan funnits är jag övertygad att både Intel och AMD skulle köra TBDR på deras integrerade GPUer. Nu är det inte vettig för "ingen" skulle anpassa PC-spel för detta då IMR är vettigare på dGPUer!

Tror därför Apple kan ha något riktigt värdefullt på gång då de kan diktera saker på en helt annan nivå än andra. MBA/MBP lär knappast bli några high-end gaming laptops nu heller, men det kommer antagligen fungerar betydligt bättre än tidigare att spela de spel som trots allt kommer just därför att man nu enbart behöver bry sig om TBDR och det är optimalt för bärbara datorer!

Skrivet av Petterk:

Det hela är nog egentligen inte så intressant för de som inte skriver drivrutiner till grafikkretsar. Mycket av det behöver inte applikations eller spelutvecklare bry sig om.

Logiskt sett stämmer det, praktiskt sett måste spelutvecklarna ta hänsyn till om man utvecklar för IMR eller TBDR. Att inte göra det är lite som att köra Mario Kart och inte alls anpassa sin körstil vare sig man kör baby Mario på en go-cart eller Bowser på en tung motorcykel. Det är samma knappar på kontrollen, men de två konfigurationerna har väldigt olika styrkor och svagheter!

En sak Metal ger är standardiserade sätt att utnyttja tekniker som är HW-accelererade i Apples TBDR baserade GPUer, t.ex. som att kunna deklarera Z-buffer som transiten (när scenen är renderad finns inte Z-data någonstans då den bara behövdes per tile). I det läget ger ju TBDR och IMR faktiskt inte ens samma slutresultat.

Även Vulkan gör det möjligt att utnyttja specifika TBDR-finesser, vilket illustreras här

MSAA kan utföras både med IMR och TBDR, fast det är nästan gratis i det senare fallet och relativt dyrt i det förra.
Omvänt gäller för tesselering, det kan göra väldigt billigt i IMR med är problematiskt för TBDR då det blåser upp mängden data som måste sparas i de två separata steg som TBDR har och IMR saknar

Kostnaden för den röda boxen påverkas väldigt mycket med ökad mängd trianglar, medan det påverkar IMR långt mindre.

Så för riktigt enkla titlar behöver man inte bry sig, det är ju trots allt samma API som används. För mer avancerade titlar är det kritiskt att ta styrkor/svagheter i beaktande på applikationsnivå.

SweClockers borde gå till GB5 så fort det bara är möjligt.

GB4 har sina poänger, men i praktiken måste man bryta ut det hela i heltalstester, flyttalstester samt minnestester. Just minnestesterna i GB4 har visat sig leda till att slutpoängen inte alls blir representativ av systemets faktiskt prestanda.

Vidare har GB4 tyvärr ett visst beroende på OS. I GB5 har man tagit bort minnestesterna, i stället har man större "working-set" vilket ger en långt bättre bild av faktiskt prestanda. Man har också fixat problemet att olika OS ger olika resultat, det är nu väldigt snarlik prestanda med samma system körandes Windows, Linux eller MacOS!

Ställer man din och min dator mot varandra i GB4 ser man hur snett det blir. Din har långt snabbare RAM (jag använder min primärt för programmering, kompileringshastigheten är i praktiken helt oberoende av RAM-hastighet så prioriterar stabilitet över RAM-hastighet + i alla fall min 3900X klockar lite högre med lägre RAM-hastighet vilket ger bättre kompileringsprestanda!).

Men då min kör Linux och långsammare RAM klockar den lite högre -> bättre heltalsprestanda och flyttalsprestanda men långt sämre RAM-prestanda.

https://browser.geekbench.com/v4/cpu/15616114

Här är lite olika delar utbrutet

ID : 15615940.gb4 (din dator) Processor : AMD Ryzen 9 3900X Cores : 12 Threads : 24 Frequency : 4412 MHz Int score : 5586 Fp score : 5749 Mem score : 8069 ID : 15616114.gb4 (min dator) Processor : AMD Ryzen 9 3900X 12-Core Processor Cores : 12 Threads : 24 Frequency : 4530 MHz Int score : 6138 Fp score : 6263 Mem score : 5526

Skrivet av the squonk:

Hoppas verkligen på Zen 3 nu när flaskhalsen verkligen är identifierad som cache/minne/IF, det är där jag hoppas på stora förbättringar så att Intel inte kan rida på sin ringbuss något mer.

Själva Zen kärnorna är betydligt mer kraftfulla än Core kärnor, även om Rocket Lake förväntas komma ikapp på den fronten(men tappa den höga klocken)

Hur är Zen-kärnorna betydligt mer kraftfulla?

Rent teoretiskt är det extremt snarlikt

  • Båda kan avkoda maximalt 4 x86 instruktioner per cykel, faktum är att Skylake och framåt kan avkoda 5 instruktioner i speciella fall

  • Båda kan leverera upp till 6 st "interna" instruktioner från front-end till back-end. Nu ser inte de interna instruktioner exakt lika ut, men de är i praktiken väldigt snarlika (d.v.s. man bryter upp typiskt CISC-instruktioner en eller fler RISC-lika interna instruktioner)

  • Båda kan färdigställa upp till 8 st "interna" instruktioner per cykel

  • Båda har totalt 4 st heltals ALU (som även hanterar hopp instruktioner)

  • Zen 2 har likt Haswell och senare möjlighet att köra AVX-instruktioner med full bredd

  • Jämför man optimal schemaläggning av instruktioner i kompilatorer när man kompilerar specifikt för Skylake eller Zen/Zen 2 får man i praktiken identiskt resultat, AMD har gjort helt rätt här då Intel är dominanten och AMD har skapat en design som fungerar bra på samma fall som Intel då allt är anpassat för det

Om det bara handlade om spel borde vi inte se de resultat som Phoronix och TechPowerUp uppvisar i icke-spel tester, d.v.s. Skylake och Zen 2 verkar prestera väldigt snarlikt per cykel i heltal medan Zen 2 har en liten IPC-fördel i flyttal.

Förhoppningsvis blir Zen 3 minst det lyft på 15-20 % som det ryktas om. För Sunny Cove har redan 18-20 % högre IPC jämfört med Skylake, men det åts ju i princip upp av en maxfrekvens på 3,9 GHz. Svårt att se Rocket Lake klocka lägre än 5,0 GHz givet att Tiger Lake U (Willow Cove) verkar nå 4,7 GHz på 15 W TDP och 10 nm+. Det positiva ur AMDs synvinkel här är att Rocket Lake är Sunny Cove samt att Willow Cove endast verkar få 4-5 % högre IPC över Sunny Cove.

Skrivet av the squonk:

Har testat Linux massor, ända sen Red Hat 5.0, har ibland kört det som primär OS. Men här går jag mot strömmen och säger att Windows har blivit bättre, inte så mycket som lockar med Linux längre.

Dödsstöten var med Covid-19 när jag skulle köra FAH, det visade sig att FAH klienten inte fungerar i moderna Linux distar. Testade flera stycken. Man måste använda en gammal dist. SÅ det blev Windows igen, körde som mest fem CPU AVX klienter och fem GPU klienter samtidigt. Kom upp i 102 miljoner poäng innan sommaren blev för varm och jag stängde ned.

Inte jättesugen på Linux för tillfället.

Nog för att det finns massor med anledningar att inte köra Linux, men F@H borde inte vara en av dem.
Kör som sagt Ubuntu 20.04, får väl ändå anses som "modern". Hämtade senaste versionen av F@H här
https://foldingathome.org/alternative-downloads/

Fungerar då direkt på både den bärbara (enbart CPU då den saknar CUDA-stöd) och en av de stationära (både CPU och GPU via CUDA).

Skrivet av Herr Kantarell:

Alltid intressanta inlägg från dig Yoshman

Det är inte bara så enkelt att säga TDP. Utan det handlar också om kiselyta. Just GPU beräkningsenheter brukar ha låga klockfrekvenser. Har man säg 8 st sådana så tar det stop någonstans även om vi i teorin skulle kunna kyla bort mer effekt.

Det finns ju exempel på grafikkort där det med fler enheter presterar bättre än ett med färre trots att de ligger på snarlik TDP och det med färre enheter är klockat högre.

Du får gärna utveckla vad som är för och nackdelar med TBDR

Har ingen hands-on erfarenhet av TBDR, det är på "TODO" listan över saker att testa när jag köper en ARM-baserad Mac

Har däremot läst en hel del om TBDR, bl.a. därför att jag läste så mycket om vad dess fördelar är att det lät för bra för att vara sant. För om det inte fanns nackdelar, varför skulle då någon köra IMR? Nvidia och AMD är väldigt kompetenta när det kommer till GPU-design, de har trots allt valt att stanna med IMR.

Fördelen med TBDR är primärt väldigt bra perf/W och möjlighet till långt mindre krav på hög RAM-bandbredd. TBDR kan effektivt hantera hög upplösning samt man kan utföra MSAA väldigt billigt.

Men det finns aldrig några gratisluncher, akilleshälen hos TBDR (från vad jag kunnat läsa mig till) är att vissa populära post-processing algoritmer behöver tillgång till hela bilden, inte bara en tile, och fungerar därmed i praktiken inte alls. Och även om man effektivt kan hantera höga upplösningar (perfekt match för moderna mobiler och pekplattor) så skalar TBDR sämre med komplex geometri jämfört med IMR.

Dagens rätt komplexa spel har av rätt naturliga skäl gått i en riktning som lämpar sig bättre på IMR. De enklare spel vi typiskt hittar på mobiler/pekplattor visar i stället styrkorna hos TBDR.

Spontant känns det också som raytracing måste passa IMR långt bättre än TBDR, detta då det finns väldigt lite korrelation mellan startpunkten hos en stråle och dess vidare färd genom scenen.

En av de absolut mest energikrävande uppgifterna i moderna CPU/GPUer är dataförflyttning, TBDR är hårdoptimerad för att minimera just detta vilket är orsaken till dess perfekta match för enheter med låg TDP. Men vissa avancerade tekniker har i princip noll datalokalitet, de kan därför inte effektivt hantera med hjälp av olika former av cache utan man måste ha en stor rejäl motor! Det finns helt klart fall där "there's no replacement for displacement" även i datorvärlden! Men tror att många ändå klarar sig hur bra som helst med liten turboladdad motor, d.v.s. TBDR

Skrivet av Lars Celander:

En bekant, en hängiven sportfantast, berättade hur Janne Stenbeck en gång hade sagt till honom att om han hade lagt lika mycket tid på att tjäna pengar eller jaga damer som han la på sin sport, hade han varit både stenrik och sönderknullad.

Jag tycker det finns en viss livsklokhet här: Man får det man satsar på att få.

Jag läser frågan från TS i grund och botten som en fråga om karriärplanering, vad han vill hålla på med längre fram. Om han vill ha "street cred" inför andra nördar så är säkert C++ ett utomordentligt bra alternativ. Är det annat som är mer intressant så kanske inte C++ fungerar lika bra.

Om ditt mål är att bli legendarisk programmerare, ska du då lägga dina ägg där det ger "street cred" hos de vars stöd du lär behöva. Eller ska du spendera dem på saker som möjligen får dig invald till big-brother cast:en

Mer seriöst: ärligt talat tror jag det är mindre viktigt vilken av dessa utbildningar TS väljer, nog mer viktigt att välja en och slutföra det hen påbörjat! Som jag skrev, personligen är jag färgad av hur min karriär inom programmering startade, den hade helt klart hjälp från spelprogrammeringen (och demo-hackande på Atari ST och Amiga 500...).

Tror man kan bli besviken av allt för mycket planerande. Planer har en tendens att visa sig värdelösa så fort stridens första skott avlossas, med tillräckligt god träning kan man göra det bästa av den situation som uppstår. Nästan alla utbildning är bra utbildning, mindre viktigt exakt vad man läst för ska man jobba inom något likt IT-branchen lär man utbilda sig hela arbetslivet ändå eller bli en 🦕

På jobbet har jag kör Linux sedan 2002, initialt Debian, sedan Gentoo för att från 2006 och första LTS releasen hoppa mellan Ubuntu LTS släpp.

Hemma växlar det mellan Windows, MacOS och Ubuntu. Hade en rätt lång period, från 2006 fram till 2014 helt utan Windows-dator (spelade enbart på konsol). För tillfället är det ändå Ubuntu 20.04 som är primärt OS, både hemma och på jobbet. Kommer bli MacOS så fort Apple lanserar sina ARM-baserade Mac:ar

Fast för egen del skulle jag säga att "primärt OS" är numera webbläsaren. Helt övertygad att jag skulle kunna klara både arbetet och det jag gör hemma från en Chromebook. Alla tunga lyft, CPU-mässigt, har jag sedan länge utfört via SSH. Hemma har jag min 3900X dator på behörigt avstånd (kör medföljande fläkt och den låter inte roligt under last), specifikt i källaren, körandes Ubuntu server 20.04. Men är ändå den datorn som används för saker som kompilering och andra CPU-tunga uppgifter, huvuddatorn används primärt som en tunn klient som bara behöver driva runt webbläsare, textredigerare och andra lättare uppgifter.

Bärbar dator och Linux kan vara utmanande, men kör man Intel iGPU och undviker alla former av dGPU fungerar det ofta riktigt bra. Dell Latitude samt Lenovo Thinkpad brukar vara väldigt säkra kort, sitter själv just nu med en Dell Latitude 7400 (är den jag anser vara "primär dator" just nu) som fungerar kalas med Ubuntu.

Skrivet av Petterk:

Klart API:t fungerar på Intel och AMD?

Final Cut Pro X och DaVinci Resolve använder lite mer än ren videoacceleration.

Utan dedikerat kisel kommer de konkurrera med Intels och AMDs integrerade grafik mer eller mindre, där båda konkurrenterna har börjat gå mot större integrerade GPUer än tidigare. Det förbättras ju över tiden, men det tar nog ett tag innan de slår Vega II och dylikt även med sina egna applikationer utvecklade av Apple.

Självklart fungerar Metal (APIet) även på Intel/AMD GPUer. Men om man nu säger att alla GPUer, vare sig det är på iOS eller MacOS, så kommer folk förutsätta att trix likt detta alltid är möjligt

"Since iOS 10 Metal also supports memoryless render targets that have no RAM backing. These surfaces exist only in tile-local memory and only for the duration of a single pass. The benefit of this feature is that no load/store bandwidth is used when using the surface. Depth textures are a good use case for memoryless render targets as they are usually not used as textures for future passes (unless they are shadow maps, of course)."

Möjligt att ovan logiskt sett fungerar även på Intel/AMD, men man kommer inte få avsedd effekt då HW-stödet saknas.

Förutsätter att de program du nämner har mer avancerat stöd än ren videoacceleration. Historiskt har det varit rätt skralt med detta, framförallt på PC, så även om GPU-kraften sjunker lite i närtid kan ändå applikationsprestanda öka om man faktiskt utnyttjar de funktioner som finns betydligt bättre.

Vad jag förstått finns vissa av dessa program redan på iPad Pro och presterar riktigt bra där. Det borde rimligen bara vara möjligt om iOS versionen redan idag utnyttjar tillgängligt kisel bättre än vad som är fallet på PC.

Sedan: GPUer är relativt "lätta" att skala upp just då uppgiften de gör är så skalbart över kärnor. Apple är en av världens absolut rikaste företag, de borde kunna lägga erforderliga FoU-resurser för att skapa en bra GPU (för GPGPU) om de bara anser att det är en marknad värd att behålla. I det korta loppet kan man ju fortsätta köra AMDs dGPU, de lär knappast ta bort PCIe på Mac Pro.

Skrivet av Petterk:

@Yoshman: I ren metal-prestanda?

Och hur spelar det någon roll för något förutom spel?
Och om Apple går all-in på TBDR, fungerar det ens på AMD/Intel GPUer?

Om man använt en 16" MBP märker man att datorn kan vara rätt tyst, i alla fall fram till att man startar något som tvingar igång dGPU-delen. Så själv skulle jag kunna betala extra för att slippa dGPU i en sådan dator, men nu löser det sig själv!

Skrivet av Lars Celander:

Så om du är en fena på C++ är du både en mycket duktig/tålig/härdad programmerare men också jävligt korkad i ett större perspektiv.

Man kan också se det som att man är pragmatiker. För om du lyfter lite på stenarna så kommer du se att världen (tyvärr kanske) är i grunden byggd på C++ (OS-kärnor är byggd på C, deras user-land är primärt C för bibliotek och C++ för applikationer).

C++ är allt för komplicerat och hoppas själv det kommer ersättas, men just nu är det något man bara måste kunna om man vill jobba med utveckling av normala desktop program, med infrastruktur. Kompilatorer är primärt C++, FaceBook, Google, Microsoft har alla plattformar som i grunden är byggd i C++ då inget annat tidigare kunde ge prestandan och kontroll som behövs (enda som idag kan axla det är Rust, men där saknas infrastruktur i form av bibliotek och så).

Sedan är det långtifrån alla som kommer jobba med den typen av programvara, man kan definitivt jobba hela sin karriär inom helt andra saker!

Skrivet av Petterk:

@Yoshman: Med tanke på att Apples GPUer troligen fortfarande är baserade på PowerVR/IMG så tar det nog ett tag innan de slår Vega II. Särskilt om de inte ska ha något dedikerat kisel då.

Fast slår dem i vad?

AMDs primära problem med deras GPUer är att de har bedrövligt programvarustöd, drivrutiner för 3D-grafik är bra, men stannar ungefär där. Spelar ingen roll hur bra kislet kan prestanda om det saknas stöd för att använda det.

En av Apples styrkor är att de är väldigt duktiga på att erbjuda ramverk kring sitt kisel så det faktiskt kan användas. En stark GPU som i.o.f.s. har bra stöd i spel men annars rätt ofta används som en överdesignad bitblitter kommer bli rejält omkörd av dagens iGPUer, även de som används i mobiler, om programmen faktiskt är skrivna så de utnyttjar det kisel som finns.

MacOS är ingen spelplattform. Om man ta bort det ur ekvationen, vad finns då kvar där Apples GPUer rimligen kommer vara en flaskhals? Framförallt om de används effektivt tack vare bra integration med programvara.

Även för Intel/AMD hade det varit långt mer optimalt att använda TBDR i deras iGPUer, faktum är att Intel sedan gen-11 internt översätter IMR till något de kallar Position Only Tile Based rendering.

TBDR har självklart också nackdelar, är därför IMR fortfarande är det som används på PC-sidan och konsoler. För där har man möjlighet till hög TDP och framförallt väldigt hög minnesbandbredd.

Skrivet av filbunke:

Man kan ju alltid köra linux eller windows på dem.

Värre blir det med de nya arm-modellerna, apple kommer att låsa möjligheten att installera andra operativsystem på dem, så när stödet för nyare mac-os försvinner för modellen så har man snart en pappersvikt, dock någorlunda snyggt designad.

Linux fungerar rätt uselt redan på dagens x86-baserade MBP, har gjort det under flera år.

Windows "fungerar", men det har alltid fungerat mycket sämre än MacOS bl.a. p.g.a. att drivarna för Windows tendera sakna vissa funktioner och uppdateras väldigt sällan. Man köper helt enkelt inte en Mac om man inte avser köra MacOS på den!

Stödet för att utveckla mot Linux är ändå riktigt bra på MacOS. Bl.a. så är Docker designat så att man faktiskt kör Linux-containers på MacOS, finns egentligen inget container-stöd för MacOS (varför bry sig om det då "ingen" kör MacOS på servers?).

Så för oss som tror på ARM på servers/datacenter, system som kommer köra Linux, är faktiskt kommande ARM64 baserade Mac den bästa utvecklingsplattformen man kan ha för ARM64 på Linux

Apples lansering av CPU för MacBook-serien är för mig det mest spännande som hänt på minst ett decennium. Tror många grovt underskattar just hur snabb Apples CPU redan är, det stora frågetecknet handlar hur mycket till man kan pressa upp prestanda när TDP går från något som är lämpligt för mobiler/pekplattor till bärbara datorer och stationära.

Det är faktiskt inte en självklarhet att man kan skruva upp enkeltrådprestanda speciellt mycket för en (av flera) anledning till att Apples CPUer utför så brutalt mycket per CPU-cykel jämfört med AMD/Intels modeller är att Apple gått väldigt wide-and-shallow i sin design. Kortare pipeline ger bättre IPC, men begränsar möjligheten att klocka högt.

Så för kommande MacPro handlar det kanske mer hur många CPU-kärnor de väljer att trycka in, för har ARM en gigantiskt fördel då varje kärna tar färre transistorer och drar mindre ström för att utföra samma mängd jobb per cykel som en x86. Finns ju redan monolitiska ARM-server med hela 80-kärnor (som tar mindre ström och mindre kretsyta än Intels 28-kärnors Xeons).

Apples marknadsandel är större nu än när man gick från PowerPC till x86, men om man tittar på den övergången övergavs i praktiken PowerPC rätt snabbt, framförallt av 3:e-partstillverkare. Om motsvarande händer nu hänger nog mycket på just hur mycket bättre Apples nya CPUer kommer prestera, ju större gap ju snabbare kommer övergång ske.

På GPU-sidan finns ju en till teknisk anledning varför övergången kan bli rätt snabb. Tile Based Deferred Rendinging (TBDR) har massor med fördelar när man är TDP-begränsad, men det finns också fördelar med Immediate Mode Rendering (IMR) om man har möjlighet till massiv RAM-bandbredd och hög TDP. Det krävs lite olika strategier i applikationerna för att optimera för respektive modell, Apple har ju nu helt valt sida här så frågan är varför någon skulle lägga resurser på IMR om man siktar på MacOS?

Sen angående prestanda. Dels tror jag folk underskattar prestandan hos Apples GPUer, framförallt då en GPU är långt enklare att skala uppåt än en CPU då arbetet GPUer normalt gör skalar nära nog perfekt med fler kärnor -> har man mer TDP-utrymme är det bara att lägga mer kisel på GPU-delen för i princip linjär skalning.

Dels, hur mycket GPU-kraft behövs egentligen i professionella applikationer (d.v.s inte spel och inte maskininlärning, det senare har Apple en ännu bättre lösning än GPGPU i form av NPU)? En fördel MacOS haft för t.ex. videoredigering är att GPGPU-acceleration implementerades långt tidigare och i större utsträckning än på PC (även om det nu också börjar hända på PC-sidan).

Även en rätt medioker GPU demolerar en CPU i uppgifter som lämpar sig för GPGPU-acceleration. Senaste versionen av Adobe Premier har fått utökat stöd för GPGPU, "The new version 14.2 of Premiere Pro will leverage NVENC to boost encoding by over 5 times compared to CPU.".

Så om Apple bara arbetar med de stora 3:e-parts tillverkarna så de använder deras kisel (GPGPU och NPU) så kommer det ge en klar prestandafördel om man så ställer Ipad Pro mot desktop x86 med dGPUer då de senare helt enkelt har rätt begränsad utnyttjandegrad av den beräkningskraft som primärt sitter i dGPUn.

Håller helt med @Mindfighter, om det var jag som anställde så vill jag ha folk som faktiskt kan programmera, inte någon som vet hur man tar sig igenom ett gäng Wizards i Visual Studio.

Så oavsett vad jobbet handlar om är "spelprogrammerare" ett gigantiskt plus då

  • folk brukar lära sig det för de är genuint intresserade av programmering

  • då allt mer går mot "molnet" betalar man i förlängningen faktiskt betalar per spenderad klockcykel, spelprogrammerare brukar behöva lära sig vettiga strateger för att optimera kod, d.v.s. inte idiotoptimera allt för det ger en oläslig dynga, utan ha magkänsla för var flaskhalsar tenderar uppstå

  • nog för att jag hoppas att C++ kommer bli ersatt av något bättre snart, t.ex. Rust, visar ändå kunskap i C++ att man inte är rädd att ta sig an de riktigt svåra problemen

Nu är jag färgad av att min ingång i IT-branchen. Har en civing i kemiteknik, men insåg när jag riktade in mig mot beräkningskemi att programmeringsdelen faktiskt var roligare än kemidelen. Var en enorm hjälp när jag sökte de första jobben att ha egenutvecklade fullt användbara spel att visa upp som bevis på även kemitekniker kan programmera, kommentarerna redan då var: spelprogrammerare är ett stort plus då vi vet att spelprogrammering är svårt!

Att sedan jobba som spelprogrammerare är något du måste tänka igenom själv. Det är en konkurrensutsatt bransch med pressade löner. Men menar att det är rätt utbildning oavsett vad du ska jobba med senare för tror den gör dig till bästa programmerare av det som listas ovan.

Skrivet av heretic16:

Jag kör bara Java för att Vaadin är skrivet i Java. Orkar inte HMTL, CSS, JavaScript samt PHP om man kan göra allt i Java.

Du menar att i Raspberry Pi så kan jag styra GPIO pinnarna igenom terminalen? Då kanske jag kan använda processbuilder för detta? Styra och läsa utav?

Det är fullt möjligt att styra GPIO-pinnar via terminalen, problemet är att det är ännu en i raden av APIer som är markerat: använd inte, utan kör "rätt" sätt vilket är /dev/gpiochipN där det officiella hjälpbiblioteket är just libgpiod.

Eftersom du ändå delat upp det hela i två program, ett som kör en webbserver och en som kommunicerar med GPIO, varför inte skriva det andra i python3 för det kommer handla om en handfull rader kod?

Känner bara till fyra officiella "bindings" till det rekommenderade sättet att köra GPIO just nu, C, C++ och Python3 är alla implementerade i libgpiod som kommer från kernel.org. Ovanpå det finns också en för Rust (är den jag använt mest själv, dels gillar jag Rust och dels presterar det faktiskt något bättre än C och C++ varianten).

Förutsatt att du kör något Debian-derivat borde detta räcka för att installera den officiella modulen för Python3

$ sudo apt install python3-libgpiod

Här har du ett exempel på hur man konfigurerar en specifik I/O-pinne och läser/skriver dess värde.

sysfs

Om du absolut måste köra Java verkar det nu som det du faktiskt väntar på inte ens är släppt än. Det "gamla" officiella sättet att hantera GPIO i Linux har en stor fördel för dig, det går att använda från Java helt utan något 3:e-parts bibliotek!

Nackdelen med denna metod är att den är långsam. Långsam här betyder: du kan inte göra saker som behöver reagera på sub-millisekundnivå. Att slå av/på någon brytare eller liknande är dock inga problem alls.

Dokumentationen för sysfs hittar du här. Vad man gör är att konfigurera kärnan så den skapar ett gäng filer under /sys/class/gpio/gpioN/..., behövs bara läsa/skriva text för att sätta riktning och tillstånd på pinnen.

Eclipse

Visade sig att Eclipse faktiskt har stöd för remote-debugging, instruktioner hittar du här.

Normalt binder debug-agenten till localhost, så du måste göra detta för att kunna koppla upp dig från din PC till RPi

$ java -Xdebug -Xrunjdwp:transport=dt_socket,address=0:8000,server=y,suspend=y ClassWithMain

i.e. lägg till det rödmarkerade, något som inte är med i länken för remote-debug med Eclipse.

Modellen ovan är ett vanligt sätt att debugga mikrokontrollers och andra typer av inbyggda system. Nackdelen över modellen som VS-Code använder är att det är upp till dig att manuellt säkerställa att det som körs "remote" faktiskt matchar den kod du har lokalt på din PC. Brukar bli rätt "intressant" att riktigt förstå vad som händer när dessa är ur synk, (har hänt ett par gånger då jag jobbat rätt mycket med embdded ).

Fast om du gör det som beskrivs ovan kan du faktiskt lika gärna köra webbservern direkt på din PC under utveckling (bara kopiera över allt när det fungerar som tänkt) och sedan låta det programmet kommunicerar över TCP till RPi där programmet som hanterar pinnarna kör. I den färdiga versionen bör du dock binda GPIO-programmet till localhost i stället för 0.0.0.0.