Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Pokud je to pravda, tak by mě zajímalo, co tím AMD sleduje. Pokud mezi jádry nebude zásadní výkonnostní rozdíl, tak je otázkou, proč si vůbec komplikovat život dvěma druhy jader. To, že by měl být Zen4D nějak výrazně úspornější se mi taky nezdá, respektive proč rovnou neudělat Zen5D? Možná chtějí šetřit výrobní kapacity (Zen4D čiplet na 5nm, Zen5 na 3nm a centrální IO na 12+nm?), ale...
Alespoň zatím nic nenaznačuje, že by mobilní APU měla přejít na čiplety (ono je to energeticky náročnější, propojení má nějakou spotřebu samo o sobě).
právě ten údajný 6nm IO dává smysl jedině u těch mobilních produktů, kvůli spotřebě. Jinak co se týká desktopu a serverů vzhledem k prodloužené smlouvě s GloFo až do konce roku 2024 vypadá na IO die od arabů
Zatím od nich AMD může brát centrální čiplety, ale i celé procesory (stále se vyrábí i původní 14nm Epyc). Pozvolna mohou přejít na paměti, jejichž výrobu GF loni avizovala (HBM2, HBM2E, LPDDR4X, GDDR6…). Mohou to být i podložky (interposer), které se vyrábějí na starších procesech. Proč by od GF AMD nemohla brát třeba interposer s integrovanou SRAM? Nevím, jestli je to aktuální, ale dříve byly procesy GF vyhlášené tím, že (přinejmenším u čipů od AMD) vykazovaly výrazně vyšší denzitu SRAM než procesy/procesory Intelu. Myslím, že je stále dost toho, co o dění v GF nevíme - mohou existovat nějaké speciální dohody na míru.
no nejspíš budou brát nové IO die s HBM a 2,5D interposerem (které GloFo vyvinulo spolu s 12nmLP+ procesem) pro Milan -X a verzi bez HBM pro Zen 4 (Genoa a Raphael). Teda aspoň mě to přijde logické vzhledem k nové WSA, ale třeba se pletu.
Jo tak, přehlédl jsem, že řeč je o APU. Pak to pochopitelně kombinovat nemůžou. Tím pádem mi ale dává smysl nižší spotřeba (ale opět viz můj původní příspěvek) nebo menší velikost (ve smyslu úspory celkové plochy), ale opět - proč ne rovnou Zen5D? Je ale příjemné vidět, jak se x86 stále posouvá. :)
právě že můžou. Podle těch informací to vypadá, že výkonné procesory budou postavené pouze na Zen 5 jádrech (Granite Ridge), zatímco APU (Strix Point) bude kombinovat big-little jádra na dvou ruzných architekturách ( a dvou různých procesech ?) s údajným 6nm IO die od TSMC, takže z toho mi logicky vychází, že ani to APU už nebude monolit
Zen5 má mať, podľa prvých únikov, IPC o 40% vyššie ako Zen4.
To je v súlade s autorom
> s ohledem na očekávatelný rozdíl jedené generace
>Zenu rozhodně nepůjde o rozdíl násobků IPC,
Ale 40% je nárast IPC medzi Zen4 a Zen2 alebo rozdiel medzi Zen a Bulldozer podľa plánu (reál +52%)
Takže to význam má..
Jake uniky to jsou? Muzete je zdokumentovat? Link na ten unik, nebo alespon clanek/forum kde se to probira?
A vysvetlim vam jak 5 letemu znovu... narust vykonu mezi Bulldozerem a Zen1 nemuzete brat jako nejaky nastup trendu. Bulldozer mel hromady uzkych hrdel a spatnych reseni. Z tech nejvetsich jmenuju: nedosazene planovane takty, spatny planovac (AMD to melo brat jako 4 jadra s SMT, a ne 8 jader - to udelali kvuli marketingu), spatne predpovidani, spatna sprava instrukcni fronty... Zadny ze Zenu uz ale netrpi takovym prusvihem, cili rikat ze kdyz se to podarilo jednou pri prechodu na Zen je indikace toho, ze se to nejspis podari i pri prechodu jedne generace Zen na dalsi je HOVADINA!!! Kazdy kdo to pouziva ma v hlave exkrementy!
Energeticka efektivita neni linearni. Kazda architeltura ma nejake optimum v urcite kombinaci frekvence a spotreby.
Takze napr. Zen4D muze byt maximalne efektivni pri frekcenci 2GHz, kdezto Zen5 jadro pri 4.5-5GHz.
Takovahle kombinace jim muze dovolit lepsi rizeni spotreby, nez by dovolilo jen proste nastavovani taktu(power stavu) pro jednotliva jadra, jak je tomu doted.
A stejny instrukcni set znamena vyrazne mensi naroky na planovac.
Vyznam by som hladal v klasickej formulke "x nm proces firmy XXXX poskytuje v porovnani s x+y nm procesom o zz% mensiu spotrebu pri rovnakej frekvencii, alebo o vv% vyssie frekvencie pri rovnakej spotrebe". Proste shrinknu zen4 na mensi proces, cim ziskaju nejake % TDP k dobru a tie mozu presypat do energetickeho balicka zen5, ktory s tymi Wattmi nalozi lepsie (meritko performance per watt).
Da sa tak ziskat krapet lepsi many-thread (partial load) vykon. Na single thread to asi vplyv nema, pretoze tam bude obmedzenim len tolko, kolko elektriny dokaze spalit jedno jadro bez sebedestrukcie a lepsia spotreba v nizkom loade, kedy sa mozu vsetky thready presuflovat na zen4 jadra, ktore budu zrat menej.
Ak urobia die shrink Zenu4 kvoli nejakemu medzigeneracnemu produktu, trebars nejakemu mobilnemu APU, ziskaju tie jadra v podstate zadarmo.
SLC Infiniti cache, nástup DDR5 a nahrazení Vegy RDNA2 architekturou. Budoucnost vypadá pro APU hráče nádherně. :)
Možná slovíčkaření, ale co to znamená v tomto kontextu SLC? Dle mne Second Level Cache, ale to je v rozporu s uváděním L4 (Fourth Level Cache). Single Level Cell (SSD) neodpovídá této úrovni HW a nic jiného mě kromě Mercedesu nenapadá.
System Level Cache?
To jako fakt nebo domněnka ? Co já si pamatuji, tak bývávalo L1, L2, L3 ... LL . System cache byla každá z nich ...
"SLC znamená System Level Cache a označuje cache nejvyšší úrovně, ke které mají přístup všechny (nebo alespoň všechny významné) komponenty SoC / APU. V našem kontextu tedy jak GPU, tak CPU."
z minulého odkazovaného článku z dubna (https://diit.cz/clanek/infinity-cache-pro-apu-amd-nejspis-chysta-neco-le...)
Děkuji za dovzdělání.
Marketingové oddělení Apple nás má pořád, co učit :-) Ale jo, dává to smysl ...
Jestli to není jen fantazie, tak to vypadá velmi dobře... hlavně ta systémová cache L4 v APU by mohla značně pomoci výkonem nejen integrované grafice. Konečně by mohli dotáhnout tu slibovanou HSA (heterogenní systémovou architekturu) do plného hUMA (heterogennous unified memory access), zajištěné koherence cache a mapování přes virtuální adresy jak CPU, tak GPU a dalších akcelerátorů na čipu. Nejen v rámci normálního běhu, ale i přes hypervisor (vCPU, vGPU, vXXX...).
Vlastně ani nevím, jak jsou na tom z hlediska HSA dnešní AMD APU, protože po několika letech slibů, kdy to pořád nechodilo, a jediné co bylo, že si AMD furt vymýšlela nové a nové názvy (Fusion architecture, HSA, hUMA, ...) a skutek utek... nakonec to z jejich marketingu coby hlavní výhoda APU zmizelo beze stopy (možná úplně ne, přestal jsem prostě ty lži o HSA sledovat). Tehdy jsem to potřeboval do jednoho projektu, bylo by to moc šikovné, "ale dopadlo to jako vždycky", takže jsme to museli udělat postaru komplikovaně přes Intel + Nvidia karty a CUDA (protože ani OpenCL ještě nebylo dost stabilní a implementované a vývojová podpora těchto věcí u AMD včetně placeného supportu byla... vzdali jsme to cirka v roce 2016; a CUDA byla "po ruce a každý s tím uměl"). Prostě mám na AMD sliby ve směru integrace CPU/GPU vypěstovanou alergii. :-D
Jelikož nevíme, jak bude vypadat Zen4, těžko komentovat kombinaci Zen5+Zen4... Je ale jisté, že cesta ke zvýšení ST výkonu CPU vede jen přes zvýšení IPC, takže to při x86-64/AMD64 ISA povede k obřím jádrům (protože ISA...). Dokud nebude nějaká zlomová polovodičová technologie a nepovede se překonat 5 GHz meze, tak jinudy cesta nevede...
> Tehdy jsem to potřeboval do jednoho projektu, bylo by to moc šikovné, "ale dopadlo to jako vždycky"
Ja sam jsem nad HSA delal jeden projekt. Myslenka nebyla spatna, ale byli tam jiste zasadni problemy. Hardware: v prvni verzi (s APU Kaveri) nebylo vsechno implementovano, az v dalsi (Carrizo) to bylo dotazeno. Software: tady byl vetsi prusvih. HSAIL - intermediate language - mel nejake umele (a velice nizke) limity, treba pocet virtualnich registru, takze pomerne snadno si narazil na spilling (a vykon sel do kytek). Treba LLVM IR tenhle problem nema. A samozrejme, HSAIL pridalo dalsi stupen kompilace - HSAIL binarka se pak musela jeste kompilovat do finalni GPU binarky.
Takze AMD se na to pomerne rychle vysralo, a presli na styl Zdrojak -> GPU binarka (komplet vynechali HSAIL). Co se tyce HSA (runtime) tak ta kniznice existuje a pouziva ji ROCm interne. Jinak je ale HSA defacto mrtve. Teoreticky muzes tu knihovnu pouzit primo, ale nema to smysl - ROCm i CUDA umi sdileny virtualni address space.
Nejvetsi problemy s HSA byly dve, 1) je to pomerne opruzni pouzivat, 2) neni zas tak moc problemu kde by heterogenni exekuce mela zasadni prinos. Nebo mozna jen zatim nikdo s necim zasadnim neprisel.
AMD je bohuzel v softwarove oblasti (myslim Linux) porad ponekud chaoticka. Hlavne "vypocetni" oblast. Treba posledni dobou se na OpenCL zcela vytoto, a misto toho propaguji ROCM (jejich klon CUDA), ktery ale ma zasadni problem - podporuje velmi malo hardwaru i verzi Linuxu. V oblasti grafiky je to mnohem lepsi - vlastne az na jednu vyjimku (existence 3 Vulkan driveru v Linuxu) je vsechno "vyreseno", ve smyslu existuje stabilni a vykonni open-source support.
Jj. Dodnes vidím rudě, když slyším HSA. :-D
AMD mělo mnoho let (2002-2009) děsný bordel v ovladačích grafiky obecně. Děs a běs. Dělal jsem na tom zobrazení videa (mnoha videí současně) na vícemonitorových konfiguracích a byl to horor. Na wokenicích přes DirectX9, z čehož se používala jen volání DirectDraw, nic jiného. A v určité verzi ovladačů fungovalo něco, pak zase o 5 verzí dále přestalo, a naopak se objevily dávno odstraněné chyby... Ti z***i neměli snad ani žádnou správu verzí. Akceleraci dekódování videa slibovali léta (pokud tam aspoň nějaká byla, byl to zamčený mpeg2) bez realizace (až po cca 10-ti letech s tím opravdu začali a to ještě příšerně - jednou chodilo 8 streamů současně, v další verzi jen 2, pak třeba 4 - prostě podle toho, jak se jejich programátoři vyspali). AMD podpora OpenCL nebo nového ROCM, to je další temná kapitola. Předtím to bylo "CTM" (close to metal) a další marketingové pojmy, nikdy nefungující. Prostě a jasně, pokud to není na těžbu nebo hry, Nvidia je jediná odpověď.
Jo, dlouho meli v ovladacich bordel; ted alespon ty ovladace funguji docela rozumne. Bohuzel v tom zbytku okolo - ROCM, OpenCL atd - je porad zmatek.
> Ti z***i neměli snad ani žádnou správu verzí
Pokud si dobre vzpominam, meli dva separatni teamy na vyvoj GPU ovladacu, a ty vydavali ovladace na stridacku, takze meli defacto dve paralelni vetve zdrojaku, a bugy se nahodne prevalovali mezi nema :D
Jj.
Bylo to zkrátka příšerné, něco takového vyvíjet a nasazovat. Navíc jsme neměli žádnou kontrolu nad tím, jak si klient updatoval/upgradoval ovladače grafiky a systém (wokenice), a tak přicházela četná překvapení, nejlépe ve tři ráno. Třeba že z čistajasna nešla žádná videa na jiných než primárních monitorech. Nebo že jich místo 30-ti najednou jelo jen jedno (4, 8). Nebo že videookno při přetažení z primárního na další monitory zakouslo ovladač grafiky nebo rovnou vedlo k BSOD. Takových věcí bylo nepočítaně.
Větší prasárnu, než ovladače grafiky od AMD jsem zkrátka nikdy neviděl. Proto ve mně některé marketingové triky AMD dlouho vyvolávaly záchvaty zuřivosti. :-D
Nvidie je sice také konzerva s hnijícími červy, ale proti software pro AMD GPU je to pětihvězdičková restaurace. Že má AMD možná lepší nebo vyspělejší GPU hardware, je úplně na nic, když se s tím nedá pracovat. A to se bohužel týká dodnes třeba i karet pro OpenGL nasazení třeba v CAD oblasti. AMD APU by na spoustu věcí stačilo, ale je k ničemu, když z výkresu svévolně zmizí nějaké čáry při zobrazení. I když si AMD nechá udělat nějakou tu "profi" certifikaci a připíše si za název "pro", tak se nedá spolehnout, že v příští verzi ovladačů a knihoven to bude fungovat.
Fungují? Poslední AMD ovladače mi u RX480 zbortí systém po návratu ze sleep módu.
:-D
Sorry, ale neodolal jsem.
Je zvláštní, jak firma jako AMD dokáže být špičková v hardware a naprosto nemožná v software.
Copak ovladače na GPU, OpenGL/CL a ty další věci, ale oni léta nedokázali ani patchnout základní libc/glibc/libc++ knihovny, aby to poznávalo jejich procesory a nejelo jenom ve fosilním módu jako MMX/SSE1, no maximálně jako Hasswell. Jestli je něco fakt na vystřílení celého týmu do posledního z***a, tak tohle jo.
3 Vulkan ovládače ale umožňujú, ak je tam aj PRO driver prepínať RADV, AMDVLK a AMDPRO Vulkan ovládače on the fly.
To je pravda, Vulkan ma ICD takze clovek muze mit implementaci v systemu kolik chce.
Pomerne zásadne sa to ale vylepšuje práve teraz
AMD Preparing More Linux Code For The Frontier Supercomputer
Written by Michael Larabel in AMD on 27 May 2021 at 08:37 PM EDT.
Frontier as the first US exascale supercomputer being commissioned by Oak Ridge National Laboratory and the Department of Energy. while being powered by AMD CPUs/GPUs is in the process of seeing more Linux kernel changes for bringing up the new platform.
https://www.phoronix.com/scan.php?page=news_item&px=AMD-VMA-Changes-Fron...
Inac ja len tak skromne, ze predpoklad, ze ak dve jadra roznej architektury nepodporuju vsetky podmnoziny tej istej instrukcnej sady, tak ani jadra, ktore by ich inac podporovat mohli, ich podporovat nemozu, je na celej ciare chybny. Podporovat ich mozu a dokonca to cele aj bude fungovat. Predpokladam, ze dokonca ani tak odflaknuta vec ako scheduler vo Widliach by s tym nemal zasadny problem. On totizto scheduler vie, ake vlastnosti jednotlive jadra podporuju (maximalne tak moze predpokladat, ze vsetky jadra podporuju to, co prve, to je potom kapusta Microsoftu, aby si to vyriesil) a zaroven pomerne dobre vie, ktore "rozsirene" vlastnosti instrukcnej sady ktore vlakno pouziva. Uz od cias MMX a prvych SSE sa to pouziva na to, aby sa usetril cas pri prepinani uloh a nezalohovali sa MMX registre, ak ich proces nepouziva. Muselo sa to riesit aj preto, lebo procesy pouzivajuce MMX invalidovali interny stav FPU a to rozbijalo ine procesy, ktore nepouzivali MMX ale zato pouzivali FPU. Predpokladam, ze podobne to bude aj s SSE (nie s tym, ze je to odflaknute, ale ze scheduler v skutocnosti vie, ktore vlakno co z procesora realne pouziva).
Riesenie v takom pripade je pomerne jednoduche. Ked vlakno zacne pouzivat napr. AVX512, kym bezi na Atome, scheduler dostane illegal instruction trap, zisti, ze aha, AVX512, premigruje thread na velke jadro, poznaci si, ze pouziva AVX512 (to si musi aj tak, aby vedel, ze ma zalohovat pri prepinani aj AVX registre) a potom proste taketo vlakno uz na Atom nenascheduluje. Jednoduchy dosledok bude ten, ze ak sa take vlakno vyskytne, aj v minimalnej zatazi zostane aspon jedno velke jadro bezat, aby tieto AVX vyuzivajuce vlakna mali kde bezat. Ziadna raketova veda.
Tohle je teoreticky ideální řešení, které se bohužel pravděpodobně nikdy nestane. A pokud, tak se do této situace odvětví doklepe až už budou mít AVX-512 i Atomy, a už to bude stejně jedno. Není to totiž problém scheduleru OS (tam to jde udělat přesně jak píšeš), ale všeho ostatního.
Naprostá drtivá většina všech standardních knihoven programovacích jazyků dnes funguje tak, že při inicializaci otestují přítomnost SSE/AVX/AVX512 a dle toho vyberou rutiny, které používají po zbytek života procesu. Tyhle rutiny jsou hlavně i blbé memset/memcpy, takže i vlákno, které jinak nic vektorově nepočítá, použije AVX512. protože neustále se něco nuluje nebo přesouvá. Tzn. během prvního zlomku sekundy by všechny vlákna scheduler přesunul na velká jádra, a nic by se nevyřešilo.
Jasně, ideálním řešením by tedy bylo tyto instrukce používat/nepoužívat per-thread, ne globálně, a nechat aplikaci rozhodnout, který thread vyžaduje výkon a který může být "efficient". A to vyžaduje přepsat relevantní část VŠECH knihoven a udělat úpravy ve VŠECH aplikacích. Nebo alespoň významné většiny, aby to mělo sebemenší efekt. A to vůbec nevidím reálně.
Jinak, co tak různě sleduju úniky a informace o např. Alder Lake, tak CPU umožňuje v BIOSu dostupnost malých jader zapnout nebo vypnout. A pouze jsou-li vypnuté, pak CPU zpřístupňuje AVX-512. Tedy v CPUID. Co se stane, pokud je použije software připíchnutý na velké jádro, to nejspíš zatím nikdo nezkoušel.
Je fajn, že sa chystá kopec nových vecí, ako Zen4 a Zen5, ale v poslednej dobe je to stále len fantazírovanie a čakanie na nové produkty. Mňa skôr zaujíma, čo môžem mať reálne v PC, NTB, takže okrem veľkých plánov by bolo fajn, aby AMD skompletizovala a dodala na trh aspoň súčasnú generáciu Zen3 od lowendu (5400G), cez mainstream (Ryzen 5600) až po TR a EPYC. S nejakým Zen5 môžu mazať med okolo úst akcionárom, ja som chcel 5600G alebo 5700G a doteraz nie je jasné či sa dostanú na trh. A nejaký Zen5??? Dajte mi vedieť, keď budú von prvé nezávislé testy a mimozemšťan bude škriekať, že má všetko skladom.
Moje řeč. Tyhle vzdušné zámky, že za rok a půl bude Zen4 a za čas potom Zen5, mě čím dál více otravují - když se nedá koupit ani pojebaný levný Athlon s dvěma či čtyřmi jádry, ještě na 12 nm z GloFo. Když už se všude žvaní, jak AMD je vázána smlouvami na odběr od GloFo, že to má jako kámen na krku, tak by aspoň mohli vyrobit nějaké ty laciné staré verze na úrovni Zen1 nebo Zen1+, na spoustu věcí by to úplně stačilo. Stejně většinou je potřeba upgradovat nějaké 6-10 let staré "kancelářské" Intel Pentium nebo ještě větší a starší vykopávky, kde vyšší výkon než Zen1 dvoj až čtyřjádro není potřeba, s nějakou základní integrovanou grafikou, případně aspoň nějakou akcelerací dekódování videa.
A když už se tedy AMD budou jak je vidět dalších pár let kopat nudou do zadku místo vydávání nových procesorů, tak by mohli konečně dát do kupy ovladače a podpůrný software. Že jim trvalo léta, než dokopali tak stupidní věc, jako updatovat základní Glibc knihovny, aby to poznávalo procesor a používalo něco modernějšího než MMX/SSA je ostuda. Ovladače grafiky, OpenGL/OpenCL a fůra dalších nedodělků...
Ještě jsem chtěl dodat, že mě AMD tímhle vyloženě se*ou. Nedělají nic pro low-end, a pokud něco jo, nejde to koupit.
Tuhle jsem řešil náhradu nějakých klientských stanic, kde běžely 10+ let staré Intel vykopávky, a nakonec jsme tam dali - i když bychom rádi použili AMD řešení s rezervou výkonu - moooc pěkné Intel desky s Pentiem N řady 4000. Sakumprásk pasivně chlazený mainboard i s procesorem a chladičem za 2 400 Kč, no nekup to za ty peníze. Žere to v idle cirka 9W, maximálně asi 30W. Místo zdroje k tomu je píchnuté falešné žluťácké "PicoPSU-like" na malé destičce za 120 Kč a žluťácký 12V externí zdrojík za 150 Kč. Vše pasivní a tiché... a výkonově úplně dostatečné. 2-4-jádro AMD APU by bylo sice lepší, no ale není. Bylo toho kolem 300 kusů, takže výsledek byla dosti značná úspora nákladů - tím pádem se za stejné peníze mohly obnovit všechny klienty, na rozdíl od ušlechtilých korporátních nabídek nebo nějakých hotových mini-PC.
Co na těch klientech běží? Když vidím, jak dokážou naši zákazníci zasekat i I5, tak N4000 bych jim fakt nedával...
Naštěstí jen linuxová instalace, udělaná z Debianu. Takový "tenký klient", lokálně tam jede jen Chromium, aplikace jsou webové z intranetu z linuxových serverů nebo přes RDP z wokenicových serverů. Plus konferenční video aplikace, firemní na bázi WebRTC, takový jednoduchý kecálek, udělané to je dost surově v Electronu (nebo v NW.js, už nevím, no prostě webově s JavaScriptem a node.js). Slabá zátěž, kterou zvládaly bezvadně i prastaré Athlony64x2 s nějakou základní Nvidií grafikou (kvůli kodekům videa) a další obdobné zkameněliny od Intelu. Ten N4000 to dává s prstem v nose.
Takhle udělané to je hlavně proto, že jde o právní/nemovitostní firmu, a tak nechtějí mít žádná data nekontrolovaně na klientech, všechno musí být na chráněných serverech. A na plnotučné VDI (třeba Vmware Horizon) nechtějí vyšpulit peníze, jsou to kolenovrti. Přes to RDP to samozřejmě není úplně ono, nějaký lag tam je, ale jsou na to zvyklí a nevadí jim to. Klienty jsou bezdiskové, jede to přes PXE boot ze sítě a používá se lokální RAMdisk. Vcelku bezproblémové, skoro nulové potíže s provozem. Je to vlastně dost bastl, ale chodí to už roky.
V porovnání s nějakými W10 hrůzami je to fantazie.
@kvolaa: Teď koukám na czc a mají tu skladem (více než 5 ks):
- R3 1200 (4j) za cca 1750 Kč
- R5 1600 (6j) za cca 3150 Kč
Asi nová zavážka, takže koupit se dá. Viz odkaz níže:
https://www.czc.cz/procesory/produkty?q-c-1-f_2025182=sAM4%20socket&q-c-...
To nejsou APU:).
APU to nejsou, no ale kdyby to bylo, také by se o tom dalo uvažovat. Jenže to řešení s N4000 bylo mnohem levnější a stačí, no takže tak.
Počkajme si na zajtrajší livestream AMD (Computex 2021), má sa síce točiť okolo HPC, ale môžno utrúsi aj o iných produktoch...začína sa šuškať, že práve Ryzen 5000G mieria do Retail-u. Uvidíme čo je na tom pravdy.
Až za 3 dlouhé roky?! Lisa asi v AMD zavedla školení o inkluzi a rozmanitosti a chytří asiati se raději vrátili domů.
Možná část mančaftu musela na povinnou operaci z chlapečka na holčičku, aby zachovali povinné genderové kvóty. Kromě mančaftu musí nově mít i ženčaft. Vlastně lidočaft, protože staré názvy jsou maskulinně toxické. Proto to zdržení. :-D
Konecne biglittle nad kterym neohrnu nos. AMD jede, borci!
Doufám, že si amd tyhle hybridy ještě rozmyslí. Na papíře huj, v reálu fuj.
ASCII zase tapetuje. Zajímalo by mě jakou má motivaci a kolik mu je let :)
V pripade dusevniho vyvoje je vek pouze jednim z parametru a nikoli ten nejdulezitejsi. :-)
:)
Ty jo, tady je od ASCII nehorázně nablito. To se nedá číst.
Ty v*le, ten pomatenec je zpatky :))
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.