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.
'' víte, naučili jsme se, že pokaždé, když něco řekneme, lidé si to zapamatují. ''
jo tak tohle se fakt povedlo.. ((((:
Byl jsi rychlejší. Taky je to to co mě zaujalo nejvíc. Ale vysvětluje to chování Intelu naprosto ve všem ;)
Já nevím proč, to četl "... že pokaždé když něco řekneme, lidé nám nevěří."
Odpověď lidí Intelu: "Víte, naučili jsme se, že pokaždé, když něco řeknete, tak lžete."
Nelžou, tomu se říká marketing :D
Chápu to správně, že rozdíl mezi lží a marketingem spočívá v tom, že marketing začíná na M?
Tak není náhoda že když ve slově "láska" čtyři písmena vyměníš a jedno vynecháš dostaneš "pivo" :D
Ja by som si skor tipol, ze ked im zacalo horiet pod ritou, tak si vsimli, ze s RBAR dokazu podat aspon nejaky seriozny vykon. Tak proste akekolvek optimalizacie ovladaca na zonglovanie s memory bankami hodili zo stola. Ono to asi chce netrivialnu logiku a preskladavanie operacii, ak chce clovek tu priepustnost vyuzit naplno. Ak driver pristupuje do VRAM uplne nahodne a kazdu chvilu si prepina, ktoru cast VRAM ma namapovanu cez PCIe do adresneho priestoru procesora, tak je sanca, ze zbernica stravi podstatne mnozstvo casu cakanim na flushnutie TX bufferov, aby mohlo byt okno premapovane. Mat celu VRAM namapovanu naraz je oproti tomu obrovsky luxus (ale to platilo vzdy o bankovanom pristupe).
Cize by som povedal, ze sa na to v Inteli proste vysrali. Kedze integrovane grafiky sharuju RAM s procesorom, ziadnu heuristiku ani reordering operacii na optimalizaciu pristupu asi nikdy v driveri nemali. S RBAR sa to v podstate sprava, ako keby to stale sharovalo RAM s procesorom a banked access spravili "od lesa".
Intel slíbil dál už není třeba číst.
Přesně, posledních 10let cokoliv Intel slíbí tak je zaručená lež.
Měli by si ten marketing fakt už začít hlídat, akorát pošpiňuje celou firmu tím průjmem co neustále produkuje.
Ale ono je asi i možné že se jim tak koupel v hovnech už zalíbila.
"Měli by si ten marketing fakt už začít hlídat, akorát pošpiňuje celou firmu tím průjmem co neustále produkuje."
Když má firma místo pořádných produktů sračky, tak se marketing přizpůsobil slovním průjmem :-)
"AMD zveřejnila technologii Smart Access Memory, která jako vůbec první začala resizable BAR využívat, v listopadu 2020."
Jenom bych dodal: zverejnila a zacala propagovat ano, ale realne je SAM jenom schopnost driveru vyuzivat RBAR, a samotny RBAR je jen specificka featura PCIE 3.0 ktera byla dostupna mnohem drive. Lze dohledat commity od AMD v linux kernelu z let 2015-2016 ktere se prave timhle zabyvali, i kdyz IIRC jenom na nektere tehdejsi Radeony. Jedine co se stalo v 2020 bylo, ze AMD protlacilo zapnuti RBAR do vsech BIOSu v "consumer" segmentu, a zacalo pouzivat v driverech.
Jo a to prohlaseni o tom ze RBAR funguje jenom na intel platforme protoze nevimco, je totalni nesmysl. Je to featura PCIE, pokud ma platforma implementovane PCIE splnujici standard, tak to proste musi fungovat, a z hlediska driveru je to stejne. A hlavne je to cele nesmysl i z obchodniho hlediska, akorat tim odradi cast potencialnich zakazniku.
Vsetkych 5 potencialnych zakaznikov?
„realne je SAM jenom schopnost driveru vyuzivat RBAR“
Fígl je v tom, že není. Ono to opravdu potřebuje značné optimalizace nad rámec formálního zprovoznění, aby to přinášelo výkon navíc. Viz přes půl roku času, který potřeboval Intel na implementaci nebo situace u Nvidie, kde to funguje pro pár her, pro které to vyladili a pro ostatní je to v profilech vypnuté, i když je resizable BAR jako takový povolen.
Hm... Takže ono to potřebuje značné optimalizace nad rámec formálního zprovoznění, ale zároveň to z nějakého záhadného důvodu Intelu výrazně zvedá výkon na hardwaru, který s tím absolutně nemohl v době návrhu počítat, protože byl cílený na rok 2020 a v době, kdy to AMD představilo, byl ten čip dávno hotový.
Hm...
Kde jsem psal o potřebě zohlednění při návrhu hardwaru?
Takže text: „I kdybychom si pohrávali s myšlenkou, že Intel napadlo využití resizable BAR o několik let (potřebných k integraci do hardwaru) dříve než AMD, reálné události nasvědčují opaku. Pokud by skutečně Intel dlouhodobě pracoval na grafických čipech, které pro své fungování vyžadují podporu resizable BAR, musel by logicky své platformy na něco takového připravit. Jenže trvalo půl roku po ohlášení AMD Smart Access Memory / Resizable Bar (listopad 2020), než Intel vůbec připustil záměr podporovat Resizable Bar na svých platformách (ohlášeno v květnu 2021):
Zatímco je podpora resizable BAR aktuálně omezená na základní desky společnosti Asus, samotný Intel pracuje na vlastní podpoře, která by měla být rozšířena napříč jeho portfoliem, tudíž méně restriktivní.
--- PCGuide, květen 2021
Pokud by Intel připravoval GPU, které vyžaduje platformu podporující resizable BAR, jistě by na jeho podpoře nezačal pracovat půl roku poté, co byla uvedena konkurencí, ale v předstihu.“
vlastně vysvětluje, že tvrzení Intelu je nesmysl, protože reBar je softwarová fíčůra?
A že Intel nemohl záměrně navrhnout řadič optimalizovaný na to, aby adresoval najednou víc než 4 GB paměti, přestože to bylo už ve standardu PCIE 3.0?
A tvrzení, že „Podpora je totiž nutná jak na straně výrobce procesoru (obsahuje PCIe řadič), tak na straně výrobce desky (musí použít kód od výrobce procesoru a zahrnout jej do BIOSu, otestovat atd.) až po výrobce grafického jádra, které musí tzv. Resizable BAR podporovat na úrovni hardwaru i na úrovni softwaru (ovladačů).“
už teda neplatí?
Promiň, ale máš úžasný talent míchat naprosto nesouvisející věci a dělat z toho mylné závěry.
„A tvrzení, že „Podpora je totiž nutná jak na straně výrobce procesoru (obsahuje PCIe řadič), tak na straně výrobce desky (musí použít kód od výrobce procesoru a zahrnout jej do BIOSu, otestovat atd.) až po výrobce grafického jádra, které musí tzv. Resizable BAR podporovat na úrovni hardwaru i na úrovni softwaru (ovladačů).“
už teda neplatí?“
Ovšem že platí. Nikde tam ale není ani slovo o tom, že Resizable BAR vyžaduje podporu na úrovni hardwaru paměťového řadiče. Resizable BAR je součástí specifikace PCIe 3.0, takže co se týče hardwaru, je vyžadován kompatibilní PCIe řadič. Což nesouvisí s řadičem pamětí.
„Hele, a proč teda vlastně nemohl Intel navrhnout paměťový řadič pro použití s resizable BAR, že se tak ptám?“
1. O tom je článek. Stručně: V době, kdy Intel napadlo, že by mohl začít resizable BAR podporovat, byl hardware ARC dávno hotový, takže těžko mohl cokoli na těchto GPU s ohledem a resizable BAR navrhovat.
2. Resizable BAR je specifikace PCIe řadiče. Dotaz dává stejný smysl jako otázka, proč by Sony nemohla vyrobit DVD mechaniku s ohledem na API Vulkan.
Moment, odkud máš informaci, kdy Intel napadlo podporovat resizable BAR?
A kdy ho to teda napadlo?
Resizable BAR nemá nic společného s rozsahem podporovaným řadičem pamětí.
Takže tím chceš říct, že paměťový řadič se nedá optimalizovat pro použití s reBAR, protože je to vlastnost sběrnice/řadiče PCIe?
A proč nemohl Intel plánovat využití reBARu, který je už ve specifikacích PCIe 3.0 (někdy od roku 2008)?
Odkud máš to info, kdy Intel napadlo využít reBAR?
Vysvětlíš mi polopaticky, proč nemůže být paměťový řadič Arc navržený pro použití s resizable BAR, jestliže resizable BAR je součástí specifikace PCIe 3.0 od roku 2008?
Nemáš celý ten „důkaz“ proti Intelu postavený jen na úvaze, že kdyby měl Intel v plánu využívat reBAR na svých kartách, které uvede za dva roky, tak zprovoznění reBAR napříč všemi čipsety dvou generací tak, aby fungoval s konkurenčními Radeony a GeForce, netrvá šest měsíců, že ne?
reBAR je vlastnost, ktora je viac relevantna k SW / driveru, nez ku GPU.
Old schoolovy pristup k VRAM na grafike pouzival nieco ako "banky". Takze nebola cela VRAM pre CPU dostupna naraz, ale mal pristup k nejakemu malemu useku, dajme tomu 32MB kusu. Nemohol si moc zvolit velkost toho useku, ale mohol si zvolit, kde vo VRAM ten usek bude namapovany. Takze si mohol driver povedat, ze napr. bude mat k dispozicii 32MB kus VRAM od 0 do 32MB, alebo od 128 do 160MB z celych 4GB na grafike. Atd.
To je relevantne z toho dovodu, ze niekde v tej VRAM mas naalokovane rozne buffery. Najzakladnejsie pravidlo zneje tak, ze buffery alokujes vo VRAM tak, aby boli blizko grafickemu cipu, ktory s nimi potrebuje pracovat rychlo.
Ak ale nevidis celu VRAM naraz, je to problem. Pretoze pri renderingu mozes napr. potrebovat zmenit nejake veci tu a tam. Tu v nejakom bufferi zmenit uhol natocenia podla animacie, tam zmenit nejake parametre, tu vytvorit dalsi drobny objekt po explozii, atd. Nie su to datove prenosy, ktore by boli velke, ale je ich vela. A deju sa kazdy frame. Moze to byt napr. tak, ze v animacii chces zmenit 10 000 roznych malych konstant, ktore dokopy maju 40kB. Ale su rozhadzane hore-dole po celej VRAM, takze kvoli nim trebar urobit aj 10 000 presunov pristupoveho okna. No a ak mas 60 fps, to ti zrazu sposobi 600 000 (0,6 miliona) prepinani kontextu za sekundu.
Aplikacia ako taka nevidi fyzicke adresy, kam sa data alokuju. Vie si akurat povedat, ci budu staticke, bude do nich iba zapisovat, alebo ich aj citat a podla toho sa driver rozhodne, ci ich naalokuje do hlavnej RAM, alebo do VRAM. Vseobecne staticke write-only data sa alokuju do VRAM, pretoze sa nepredpoklada, ze by sa zapisovali casto (a teda ze latencia nie je relevantny parameter). Lenze ak mas napr. nejake buffery atributov pre shadery, ktore ti ukazuju polohy a natocenia jednotlivych fragmentov po vybuchu, to je buffer, do ktoreho CPU zapisuje pri kazdom frame.
A tu je kamen urazu. Ak mas taketo buffery rozhadzane hore-dole po VRAM, ktora ma napriklad 4GB, ale do tej pamate mozes pristupovat len cez 32MB velke okno, tak driver musi potencialne pred kazdym pristupom skontrolovat, ci balik dat, ktory chce zapisat, je cez okno pristupny. Ak nie, musi pockat, kym skoncia vsetky zapisy do VRAM, prestavit okno tak, aby videl data, ktore zapisuje a az potom moze obnovit zapis. To cakanie na synchronizaciu potom dost zabija realnu prenosovu rychlost, pretoze namiesto toho, aby sa prenasali data, sa caka, kym prenos skonci, potom sa prekonfiguruje okno a potom sa robi zapis dalsi. Neviem, ci PCIe ma moznost presun okna pipelinovat so zapismi nejakou formou memory barriers. Ale tipujem, ze nie. Je to context switch a context switche su vseobecne drahe.
Co sa v takom pripade da spravit je, ze driver ma implementovanu nejaku logiku, ktora budto preusporiadava fyzicke zapisy do takeho poradia, aby boli zoskupene podla toho, kde sa cielove data nachadzaju, t.j. najprv pozapisuje vsetko v prvom banku, potom sa prepne na dalsi potrebny, atd. alebo si data vo VRAM preusporiada tak, aby boli dostupne s mensim poctom prepinania bankov. V realite je to najskor kombinacia oboch. Znova zopakujem, ze graficky SW dostava +- meaningless handle, nie skutocne adresy. Takze ak sa data vo VRAM presuvaju, graficky SW to nechava chladnym.
reBAR umoznuje zvacsit si toto okno na podstatne vacsiu cast VRAM, pripadne ju pokryt celu. Takze mozem pristupy robit v +- uplne lubovolnom poradi, alebo si ich musim planovat len minimalne a dosiahnem maximalneho vyuzitia zbernice. Kedze praca s oknom je svojim sposobom optimalizacia, nikdy sa nevyuzije 100% vyuzitia prenosovej kapacity. To je dovod, preco vacsina hier s reBAR bezi lepsie. To, o kolko lepsie bezia zalezi od toho, ako je engine postaveny. Ak je postaveny tak, ze na vyznamnej casti HW dochadza k nadmernemu poctu context switchov, potom zapnutie reBAR moze hru zrychlit.
Preco ale niektore hry spomalia? Herni vyvojari (resp. dnes skor autori enginov) su si vedomi problemu s context switchami a snazia sa na enginy optimalizovat. Iny problematicky context switch je napriklad ak na texturovacej jednotke chces zacat pouzivat inu texturu. To musis vsetky texturovacie operacie zastavit, potom mozes zmenit texturu a potom mozes zacat texturovat znova. Sposob, ako to obist je jednoduchy - zlepis viac textur do jednej a vytvoris tzv. texture dictionary. Vyzera to ako plagat s texturami. A na povrchoch potom pouzivas iba male casti z nej. Vies tak otexturovat viac roznych povrchov bez toho, aby si prepinal kontext na texturovacej jednotke a rozdiel vo vykone moze byt aj niekolko nasobny. Podobne mozu niektore enginy optimalizovat, (alebo skor "optimalizovat") pre male okno. Tato optimalizacia potom narazi na to, ze driver potom musi pracovat s objektom, ktory nie je vseobecne optimalny. Taky texture dictonary je super, lebo nemusis menit kontext, ale zasa ti vo vysledku moze vzniknut hovadsky velka textura napr. 16k x 16k bodov, s ktorou sa vo vseobecnosti manipuluje ako s jednym nedelitelnym monolitom (aj ked AMD vie strankovanie). To potom moze napr. rozbit veci na strane alokacie pamate, kde alokator pracuje efektivnejsie s mensimi kuskami, ako s jednou velkou obludou.
Preco tymto integrovane grafiky Intelu netrpeli? Tie nepouzivali dedikovanu VRAM, ktora je "on-chip", ale pristupovali k hlavnej systemovej RAM. Tam je koordinacia trocha ina, pretoze GPU tu figuruje podobne ako CPU ako bus-master a ma v zasade pristup k celej (namapovanej) RAM. Mapping tu funguje ako security feature, aby shadery beziace na GPU nemali pristup k uplne akemukolvek kusu RAM a kvoli virtualizacii. Z pohladu CPU (a drivera) sa jednalo o zapis do pamate ako kazdy iny, takze ziadne okna ani optimalizacie nebolo treba riesit.
Tym, ze Intel svoje GPU strcil na separatnu kartu a dal mu privatnu VRAM, mu nastal problem v tom, ze driver si zrazu nemohol zapisovat kedy chcel a kam chcel. Teda mohol, ale malo to performance penalty. A ked v Inteli riesili, co s tym, tak zistili, ze ak zapnu reBAR, cely problem mozu bud uplne, alebo do znacnej miery eliminovat bez toho, aby implementovali nejaku logiku zoskupovania alokacii alebo preusporiadania zapisov. Ak reBAR nie je zapnuty, rovnaky kod bez optimalizacii saha do pamate v nahodnom poradi a to sposobuje na hre zavisle prepady vykonu sposobene cakanim na synchronizaciu na zbernici.
No, a preco nie je reBAR zapnuty aj inde? To zasa tipujem pojde na vrub toho, ze tak ako vsetko ostatne to cele bude masakralne zabugovane. AMD a nVidia mali moznost a cas to testovat na velkom mnozstve chipsetov a hier a vychytat pripadne bugy. Intel s ostatnymi problemami, ktore s driverom riesi, nemal cas najst vsetky bugy vo vsetkych implementaciach podpory reBAR, tak proste poriesil len svoje chipsety.
Tohle nějak neřeší jádro pudla, teda no-xovy úvahy, že Intel nemohl s reBAR pracovat, dokud nás tím neoblažilo AMD, protože to přece na deskách začal podporovat až šest měsíců po AMD.
Tohle mi připadá spíš jako argument, že s reBAR počítali, než jako že by plánovali vydávat dedikované grafiky bez něj. :D
Toto je argument, ktory riesi, ze to nie je vec, ktoru treba riesit na GPU. Teoreticky, ak pouzili radic, ktory podporuje vacsie adresne okno ako je nejaky default (ale tu zasa strielam od boku, neviem, aka tam je podpora), tak nemuseli menit nic. Ak ho nepouzili, nieco menit museli.
Na druhej strane, reBAR je ficura, ktora nejaky ten piatok existuje, PCIe 3 tu s nami nejaky ten piatok je. Je mozne, ze kym AMD neupozornilo na to, ze nieco take existuje, v Inteli o tom nemali ponatia. Kludne, celkom seriozne. Pripadne mali, ale brali to tak, ze je to aj tak vsade rozbite a neda sa to povolit.
Jenomže to taky nevyvrací možnost, že je paměťový řadič Intelu optimalizovaný pro využití reBAR (nebo většího adresního prostoru).
No-x se pokouší dokázat, že to není možné, protože přece Intel přišel s reBAR až po AMD.
Hm, ještě koukám na to video, on je možná problém v tom, že nic nedokazuje, ale prostě jenom převyprávěl to, co v tom videu plácá ten mamlas, aniž by řešil, jestli je to pravda.
OK, napisem to este raz a jednoduchsie.
Na dedikovanej grafike je VRAM aj GPU na tej istej strane PCIe. Z pohladu GPU je reBAR uplne irelevantne, pretoze drvivu vacsinu svojich requestov riesi priamou cestou do VRAM a po ziadnom PCIe nejde. Ked dojde VRAM na grafike, tak sa do toho musia zapocitat latencie PCIe / DDR a performance ide do kopru, ale to ide na akejkolvek grafike a bez ohladu na to, ci reBAR povoleny je, alebo nie. Teda radic je v tomto uplne nepodstatny.
Z druhej strany je to cele len o tom, aky velky kus dedikovanej VRAM vidi CPU v jednom momente (pretoze bez reBAR ju nikdy nevidi celu naraz). Moze to byt 2/4/32/...MB kus, alebo to mozu byt radovo GB (s reBAR). Toto je dolezite len pri operaciach, ktore sa musia robit zhruba tak kazdy frejm, t.j. aktualizacia transformacnych matic a (napr. osvetlovacich) atributov. To su tie veci, za ktorymi GPU caka na CPU. Bez reBAR sa na to zjednodusene mozno pozerat tak, ze bud je kazdy pristup do dedikovanej VRAM potencialne penalizovany potrebou presmerovat viditelny kus VRAM tak, aby som mal z CPU pristup k tomu kusu VRAM, kde menene data sedia (to je ta BAR cas v reBAR, znamena to Base Address Register, register obsahujuci bazovu adresu). Alebo sa alokacia pamate ovladacom vo VRAM, resp. pristupy preusporiadaju tak, aby bol pocet presunov okna co najmensi. Tu zasa radic nemozno na reBAR optimalizovat, lebo tak zhruba nie je co. Cely reBAR je len o tom, ci PCIe interface umozni zmenit velkost (to je to re v reBAR a znamena `resizable`) toho okna, alebo nie. Ak je velkost fixna (a mala), je to pruser. Ak je velka, pruser to nie je.
Co je mozne optimalizovat, je driver. Ak reBAR mam, optimalizovat zhruba nemusim, pretoze sa viem pomerne lahko nutnosti prepinat okno vyhnut. V idealnom pripade uplne. Ak reBAR nemam, tak musim riesit pamatove alokacie do VRAM a/alebo preusporiadavanie pristupov tak, aby som mal dobru "reference of locality". Je to problem dost podobny optimalizacii cache hits pri CPU.
Intel dlhe roky ziadne dedikovane GPU nerobil, teda nikdy nemal VRAM za PCIe (i970 snad bola AGP karta). Tym padom toto ich drivery nikdy riesit nemuseli (tym padom predpokladam, ze to ani nikdy neimplementovali, nemali by to kde pouzit). Aj z pohladu drivera, aj z pohladu CPU aj z pohladu GPU bola pamat lokalna (GPU bolo cez PCIe nadratovane ako bus master).
Predpokladam, ze kedze reBAR je vlastnost pritomna v PCIe3, tak kazdy PCIe3-compliant radic to umoznuje zapnut. Potom je len otazka toho, ci je tato funkcia vyvedena zo zariadenia von, i.e. ci zariadenie tu funkciu umoznuje zapnut a nastavit. Dalsia otazka potom je, ako velmi su zmrsene BIOSy a ako moc sa rozpadnu, ak sa to niekto zapnut pokusi. Tipoval by som, ze dost :)
Zasluha AMD / nVidie tu moze byt v tom, ze dosli a zacali do vyrobcov kopat, aby si to v BIOSoch fixli (to moze byt ten odkaz na to, kde sa pise, ze AMD tlacila na vyrobcov, nech je podpora vsade zapnuta. to moze byt marketstina pre to, ze tlacili na vyrobcov nech si to fixnu, lebo to chcu aj realne zacat pouzivat). Intel sa mohol chciet pokusit o to iste, ale s nulovym track recordom mu mozno vyrobcovia povedali len "haha, nie". Alebo sa o to nesnazili a povedali si, ze zabezpecia funkcnu podporu iba na Intelich chipsetoch (ktore mali pod kontrolou spolu s ich BIOSmi). A tym padom to zapinaju iba tam, lebo iba tam su si isti, ze to nebude mat ziadne unexpected bugy.
AKK je toto vysvetlenie spravne (co nevieme a nikdy vediet nebudeme), tak by som naopak povedal, ze je to dokaz toho, ze Intel prisiel na to, ze vykon ich zariadenia je srackovy a potrebuju helfnut od reBAR este skor, nez to AMD s nVidiou u vyrobcov dosiek vybavila. A ked s tym AMD vyrukovala, tak zauradovalo Intelie marketingove oddelenie a urobilo z pruseru akoze uspech, pretoze nieco, co Intel musel podporovat preto, aby mal aspon ako-tak konkurencie schopny vykon oznacili za juuuj, ved to aj my budeme podporovat.
Ona by ta podpora mozno dnes sla zapnut aj na AMDcku a ficalo by to bez problemov, ale menezment sa boji, pretoze to nie je otestovane a museli by to supportovat. A to by znamenalo hafo zdrojov navyse, ktore nemaju. Bolia ich ine veci, ktore nefunguju ani tam, kde funguje reBAR.
„bud je kazdy pristup do dedikovanej VRAM potencialne penalizovany potrebou presmerovat viditelny kus VRAM tak, aby som mal z CPU pristup k tomu kusu VRAM, kde menene data sedia (to je ta BAR cas v reBAR, znamena to Base Address Register, register obsahujuci bazovu adresu). Alebo sa alokacia pamate ovladacom vo VRAM, resp. pristupy preusporiadaju tak, aby bol pocet presunov okna co najmensi.“
A nic z tohoto procesu se nedá na straně paměťového řadiče karty a cache urychlit hardwarově? Všechno musí řešit softwarově driver?
Co když Intel prostě tohle (a optimalizace na straně ovladačů) obešel tak, že už od počátku počítal s tím, že do paměti poleze po velkých blocích právě proto, že nechtěl řešit tyhle optimalizace, které existují v podstatě jen proto, že se to tak dělalo běžně před dvaceti lety? Notabene když má zkušenosti s tím, jak to funguje, když to na IGP nemusí řešit. A tím, že tvrdí, že je to moderní řadič, říká, že to prostě neměl v plánu řešit, protože už to dnes není nutné dělat?
A jediná změna, kterou udělal, je, že se s AMD a Nvidií dohodli na nějakém obecně fungujícím řešení namísto proprietárního?
> A nic z tohoto procesu se nedá na straně paměťového řadiče karty a cache urychlit hardwarově? Všechno musí řešit softwarově driver?
Neda, pretoze to, ake velke kusy pamate skoncia v akom poradi alokovane na akych miestach VRAM je dosledok toho, co presne aplikacia (cez driver) s pamatou robi. To, aky velky bordel tam nakoniec bude, zalezi od toho, co presne graficky engine robi (a v akom stave je VRAM v case, ked sa spusta) Je to problem zhruba ekvivalentny pokusu o defragmentaciu RAM pri dynamickej alokacii pamate. Ista vyhoda je tu v tom, ze aplikacia nedostane surovy pointer na RAM, ale dostane iba ID objektu. Teda driver ma sancu ten objekt vo VRAM presunut bez toho aby rozbil koncovu aplikaciu. IMHO to aj robit musi, pretoze z hintov, ktore aplikacia driveru da sa dopredu neda povedat, ako casto k tomu bude pristupovat. Takze driver si musi sledovat pristupy k objektom z aplikacie a relokovat ich vo VRAM tak, aby mal vysledok co najvyssi vykon.
Potreba optimalizacii pri nedostupnosti reBAR nejde obist. Ide sa na nu vysrat, dosledkom je potom prepad vykonu. Optimalizovat hardwareovo to nejde, pretoze ake velke bloky a kde v pamati budu, to zalezi od beziaceho SW. Ide podporovat reBAR, potom je sumafuck, kde tie data su. Ide to ale optimalizovat softwareovo. To je presne to, co si myslim, ze v Intelich ovladacoch chyba, pretoze to nikdy nepotrebovali.
Motivacia Intelu je dnes bohuzial nevystopovatelna. Je mozne, ze Intel to cele spachal v dobe, ked si naivne myslel, ze ak vyda dGPU a nove CPU, moze prevalcovat trh. Mozno si mysleli, ze ak rovno vydaju dGPU, ktore vyuziva reBAR a reBAR budu podporovat len na Intelich procesoroch / chipsetoch, vysledkom bude vendor lock-in a ludia si kupia kvoli dostupnemu inteliemu dGPU aj intelacky procak a fosnu.
To je to, z čeho bych Intel podezříval spíš. Že s reBARem počítali a chtěli zabít dvě mouchy jednou ranou – ušetřit si námahu, a zároveň mít vyšší výkon na deskách Intelu.
Ne že by nechtěně vyrobili zprovozněním reBARu podstatně výkonnější kartu, než měli původně v plánu bez něj.
To sa dnes uz nedozvieme, pretoze tie graficke karty vysli s niekolkorocnym spozdenim. Takze to, co my teraz vieme o tej grafike povedat, je dostupne o niekolko rokov neskor, nez sa o tom rozhodlo. Teda my to vnimame v kontexte uplne ineho stavu, nez v akom sa tie rozhodnutia robili.
Tak u předchozí generace dedikovaných grafik (DG1 - je to přímo iGPU, ale v samostatném čipu s odděleným TDP, takže se nedělí s CPU) to tak bylo, že si usnadnil práci. V Linuxu snad ani nedokázala jet jako normální GPU, jen jako virtuální ve VM.
A vůbec už nechápu to tvrzení, že:
„Jenže trvalo půl roku po ohlášení AMD Smart Access Memory / Resizable Bar (listopad 2020), než Intel vůbec připustil záměr podporovat Resizable Bar na svých platformách (ohlášeno v květnu 2021)“
Když v lednu 2021 vycházely testy na Radeonech https://www.overclock3d.net/reviews/cpu_mainboard/resizable_bar_tested_w..., v březnu testy GeForce na Asusáckých deskách s Intelem, a minimálně v dubnu už mělo podporu MSI (na čipsetech od řad 300–600) i Gigabyte.
https://www.msi.com/blog/improve-performance-with-resizable-bar-now-avai...
To jako že to výrobci desek na procesorech a čipsetech intelu zprovoznili sami, aniž by se na tom Intel jakkoliv podílel?
Co je tuto?
https://www.techspot.com/news/88620-intel-bring-resizable-bar-11th-gen-r...
No, tu predpokladam, ze sa jedna o podporu Intelu v radicoch. Kedze u intelu co generacia CPU, to nove chipsety a to nove BIOSy, tak zrejme podpora v 11th gen znamena, ze publikovany atribut o podpore reBAR bude ACPI v BIOSe pre dany chipset (resp. jeho jadre, pretoze jadro BIOSu vzdy dodava vyrobca chipsetu, potazmo procesora, u AMD sa to vola AGESA) podporovany. Pre vyrobcu dosky to znamena, ze je to featura, ktora bude podporovana automaticky.
Ta ficura sa da backportnut aj do starsich BIOSov pre starsie chipsety pre starsie CPU, ale musi to urobit vyrobca dosky. To je praca navyse. Zaroven je to praca, ktoru urobia a neuvidia za nu peniaze, pretoze nove dosky na 3-4 generacie stare procesory sa (speci v pripade Intelu) zas tak moc nepredavaju.
BIOS to podporovat musi, pretoze napr. ak si resiznem okno na pristup k VRAM na grafike, BIOS musi pocitat s tym, ze ten adresny rozsah nesmie priradit ziadnemu inemu zariadeniu, inac by doslo ku konfliku. Ak boli roky BIOSy pisane s tym, ze adresne okno ma fixnu velkost podla toho, co ohlasuje zariadenie, viem si predstavit, ze z toho nastal celkom slusny bordel.
Mně šlo spíš o tu časovou posloupnost tvrzení, že „trvalo půl roku po ohlášení SAM... než Intel vůbec připustil záměr podporovat Resizable Bar na svých platformách (ohlášeno v květnu 2021)“, když už v lednu 2021 byla na prvních platformách Intelu funkční podpora a už v dubnu byla široká podpora napříč významnými výrobci desek a pro několik generací čipsetů.
No to moze byt prave dosledok toho, ze podpora v januari 2021 bola implementovana vyrobcami dosak na vlastne triko. Takze zobrali core BIOSu od Intelu, ktory si s reBAR moc nerozumel a podporu reBAR tam pridali sami. Potom ju mohli backportovat aj na starsie platformy, ak ten BIOS trebars vychadzal z kompatibilneho coru.
V maji 2021 sa Intel rozhodol, ze podporu (hoc pre ten isty chipset, kde uz podpora existovala od vyrobcov dosak) prida priamo do coru BIOSu pre niektore chipsety. To znamena, ze BIOS, ktory bude na takom core zalozeny, bude podporu pre reBAR automaticky obsahovat nezavisle na tom, ci sa vyrobca dosky rozhodol to podporovat, alebo nie.
Predpokladam, ze podpora reBAR od vyrobcov dosak potom bola v konflikte s tym, co dodal Intel a vyrobcovia museli svoj kod povypinat ak chceli integrovat aktualizovany core. Z coho boli urcite vsetci zucastneni strasne nadseni. Hlavne ak im predtym Intel na dotaz ci hodla reBAR v dohladnej dobe podporovat odpovedal, ze to nema na roadmapach :)
(takyto scenar inac podporuje tvrdenie, ze Intel o vyuziti reBAR povodne vobec neuvazoval, dovod mohol byt kludne taky, ze nejakemu menezerovi to prislo ako zbytocne komplikovane ziskat support od vyrobcov BIOSov na taku ficuru. Ze lahsie bude urobit optimalizacie v driveri.)
Nikoliv.
https://www.tomshardware.com/news/intel-talks-resizable-bar-for-11th-gen...
Explicitně řečeno, že to Intel podporuje a že na tom spolupracuje s AMD a Nvidií. Už na začátku února 2021. O tom, že by sám poprvé připustil podporu až v květnu, nemůže být absolutně řeč.
Jak si vlastně vysvětluješ skutečnost, že s využitím technologie, o které Intel ani neuvažoval, dokud s tím nepřišlo AMD, a jeho grafiky s ní nikdy nepočítaly, získávají až čtyřicet procent výkonu navíc?
Tím, že mají obrovskou kliku?
Téměř každý úspěch Intelu se stal jen díky tomu že "měli kliku", tak snad z toho lehce vyplývá že tohle je ten samý případ.
Ventyl Ti to vysvetlil - preto, leb prešli z IGP do PEG.
Eeee? Co to má společného s válcováním silnic? dGPU nepřešly z IGP do PEG. dGPU měly být odjakživa pro PEG.
Tym, ze Inteli driver nikdy nedostal optimalizacie pre rozumne rychly beh v rezime, ked reBAR nie je aktivny. Alebo ich dostal, ale su mizerne, pripadne by aj fungovali, ale boli zabugovane, tak ich museli vypnut (co by zasa nebolo az tak prekvapive, boli nie tak davne doby ked aj tak trivialna vec ako vypisovanie textu bola v intelich driveroch masakralne zabugovana a pomala).
To pořád neznamená, že nepočítal s reBARem. To pořád spíš znamená, že nepočítal s režimem bez reBAR.
Připadá mi absurdní představa, že by navrhovali GPU, u kterého nepočítají s reBAR, chtějí to udělat klasickou cestou, pak zjistí, že jim to nejde, a zároveň náhodou zjistí, že je v PCIe deset let stará fíčůra, kterou nehodlali využít, ale čistě náhodou jim zvedá výkon o deset až čtyřicet procent, a fixnou tím gigantický problém, který mají.
Ono to az tak absurdne byt nemusi. Nevieme ako daleko siaha vyklad tvrdenia, ze ujo Pat si myslel, ze na dedikovane grafiky bude stacit trocha upravit driver na iGPU.
Zopakujem sa este raz a este strucnejsie. Pre GPU samotne, pre VRAM a pre firmware na strane GPU je reBAR +- irelevantna vec. reBAR je relevantny len a jedine pri pristupe CPU (driver) do VRAM. A relevantne vykonnostne dopady ma len ak sa take pristupy deju pri kazdom renderovanom frame.
Hele, a proč teda vlastně nemohl Intel navrhnout paměťový řadič pro použití s resizable BAR, že se tak ptám?
Protože je to Intel a intel je 100let za opicema
No, rikal jsem si, ze tomu zase AMDecko dalo na frak. Je to normalni, aby zrusili podporu DirectX8? Jako hezky,ze se to da emulovat, ale kdyz bych si chtel zahrat starsi hru, tak to pres emulaci bude zbytecne zrat energii, protoze je to energeticky narocnejsi to emulovat.
Pak se teda ozval Intel, ze oni zrusili i DirectX9, jako jim hrablo definitivne? Sice chapu, ze nejsou schopni udelat ovladace na DirectX12, tak tezko muzeme chtit starsi DirectX9, aby fungovaly, ale proste je to Intel, to snad ani nema cenu dal komentovat. Proste jedno vim jiste, procesor od Intelu si nekoupim a grafiku uz tuplem ne. To uz snad radsi to AMDecko, kdyby to nahodou NVidia nezvladla po energeticke strance, ale uvidime.
Asi by ses divil co třeba Windows všechno emuluje.
Hw má postupem času mnohem lepší energetickou efektivitu a je to i díky tomu, že se zbavuje nativní podpory zastaralých konceptů. Jestli něco je nebo není energeticky náročnejší záleží na konkrétním případě.
DirectX 8 ve Windows 10+ už u většiny her nefunguje takjakotak.
Pro tvé překvapení, na Linuxu se všechen DirectX emuluje přes vulkan, a světě div se výkon je průměrně jen on 0-10% horší.. v některých emulovaných hrách a na AMD grafice bývá výkon pod Linuxem dokonce lepší jak nativně ve Windows pod DirectX.
Ve kterých konkrétně? To může znamenat i spíše to, že něco není implementované a nebo, že to funguje jinak a následný obraz na Linuxu tedy vypadá jinak nebo hůř než ve Windows.
Spozoroval jsem akorát, že některý starý hry se softwarovým renderováním přes Direct2D/GDI jedou na Linuxu lépe. Ale jestli to je tím, že Wine zahazuje některá volání a nebo, že se renderování nějak prožene přes gpu a je to rychlejší, to je otázka. Programy běžící skrz WinAPI jedou pod Wine výrazně pomaleji, natož ty které navíc kreslí do okna grafiku přes GDI.
> To může znamenat i spíše to, že něco není implementované
Taky to muze znamenat, ze 1) linux kernel umi lip zachazet s hardwarem (staci si porovnat vykon threadripperu pod oba OS), nebo 2) optimalizace driveru na kterych se pracuje, se dostanou mnohem driv do distribuce u linuxich driveru nez u windowsich driveru. Treba velke optimalizace OpenGL v AMDckovem 22.7.1 windowsim driveru byli uz davno predtim pritomne v Linuxu. Moje osobni zkusenost je, ze Dying Light 1 bezel mnohem lip na Linuxu - nativni binarka, nikoliv WINE, pouzivajici OpenGL (ale tohle bylo pred existenci 22.7.1 driveru, takze mozna ted uz bezi stejne na obou).
1) Hry převážně stojí na grafickém výkonu, mají grafické karty lepší podporu a výkon v Linuxu? To by pak nemusely padat hlášky typu: "NVidia fuck you". Ale jinak ano, třeba W11 jsou extrémně zprasený v několika rovinách a navíc mají problematický přístup k hw, např. - latence L3 cache u Zen 3 (už nepamatuju jestli to byl reálný problém nebo chyba měření).
2) Může být, akorát v případě emulace je dost nepravděpodobný, že optimalizace driverů smaže výkonnostní propad
Porovnávat výkon mezi OS a nebo ještě lépe mezi platformami je složitý, ukazatel FPS v podobě čísla je hodně zavádějící. Důležité je, jestli to vizuálně vypadá stejně, jestli jsou shodný latence (propady snímků, update fyziky, ovládání, audio..), jak přesné jsou floating point a další výpočty, co je akcelerované a co ne (MSVC klidně vyplivne úplně něco jiného než gcc pod Linuxem), jestli datové soubory mají stejnou velikost, jak je řešená vertikální synchronizace atd.
Uh oh, floating point je vec hardware-u. Tam je presnost dana. Je na to norma, vola sa IEEE 754.
Torvaldsov prostrednik sa stoporil skor kvoli pristupu, ktory nVidia mala k vyvoju SW. To, ze dlhe roky drzala ich drivery uzavrete bolo sprevadzane tym, ze sa snazila paralelne vyvijat uzavrete implementacie pre veci, ktore sa inac vyvijali v kerneli ako otvorene a zdielane. Jedna z veci bol tusim memory manager pre UMS grafiku. Ale to casom padlo. Jedna z komplikacii bola, ze nVidia na Linuxe nikdy (co viem) oficialne v driveroch nepodporovala beh na UEFI. Ono to povacsinou fungovalo, ale oficialne to nikdy supportovane nebolo. Dalsia vec, ktora nikdy supportovana nebola, ale dlhu dobu ani nefungovala, bolo standalone OpenGL ES. nVidia podporovala OpenGL / ES iba ako X11 extension. To bol problem pre Wayland, ktory je postaveny na OpenGL ES ale nepouziva X11 ako podvozok. Takze Wayland (ani ziaden iny cisto OpenGL ES software) bez X11 na nVidii pouzivat neslo. A zaroven hadzali vsetky mozne klacky pod nohy vyvojarom Nouveau, takze nVidiacky hardware je s opensource drivermi pouzitelny len marginalne (IMHO skor nepouzitelny).
A urcite by sa nasli aj dalsie dovody, ako napr CUDA samotna.
No to né. Kompilátor může normy softwarově podporovat skrz standardy C/C++, ale je čistě na tobě jak máš floating point implementovatný a/nebo jakou používáš přesnost. I kdybych používal IEEE 754 xy skrz kompilátor, Windows aplikace může mít proměnné single a Linuxová double. Každá verze bude fungovat jinak a jiná bude i hardwarová náročnost. Při kompilaci to bude přepínat jeden jediný příkaz skrz makro, zbytek kódu bude 100% identický.
Dříve například ATI/NVidie viditelně podváděli v benchmarcích tím, že jeli různou přesnost. Jediný rozdíl je, že od té doby se naučili podvádět skrytě :) Nebo třeba PS1 uměla jen fixed point, takže vertexy na obrazovce chaoticky poskakovaly sem a tam.
To už je hodně dávno, co se podvádělo s přesností výpočtů. A byla to klasicky jen NVidie, která místo 32bit vnucovala 16bit. ATI měla natvrdo 24bit, což bylo ok pro min. požadavky DX9. V dnešní době jsou výpočty všude stejné, podle té normy, jak byla uvedena výše. Těch výpočtů je totiž tolik, že by se rychle naakumulovaly chyby. Mimochodem jeden z testů kvality zobrazení je právě test kumulace chyby výpočtů, takže byste to o té GPU hned věděli z (pořádné) recenze.
W T F?
Nevidel som runtime, kde by float bol inac velky ako 32bitov a double inac velky ako 64 bitov. Jedina discrepance (ktora je dokonca v rozpore s tym, co pozaduje standard pre C) je, ze long je na 64-bitovom MSVC 32-bitovy. To bolo velmi hlupe rozhodnutie Microsoftu z dob zaciatku 64-bitovych aplikacii, aby zabezpecili kompatibilitu. Vsade inde je na 64-bitovom targete long 64-bitovy. To sposobuje sem-tam problemy, ale na take veci mame zasa uint64_t / int64_t.
Alebo sa bavime o tom, ze autor aplikacie si deliberately Linuxovu verziu skompiluje s floatami a widliu s doublami, alebo naopak? To akoze technicky mozne je, ale netusim, kto by to preco robil a co by tym ziskal? Skor to viac problemov narobi, nez nieco riesi. Napriklad to totalne zabije prenositelnost dat z takej aplikacie medzi platformami.
Ta uvaha o energetickej efektivite je dost derava. DX9 je vec tesne po roku 2000, resp. Windows XP. Aj ta najpodradnejsia integrovana grafika Intelu asi bude nasobne vykonnejsia, nez cokolvek, co slo v roku 2000 zohnat. Takze aj keby sa pri tom stratilo 50% vykonu, stale to pobezi na nasobne vyssom framerate, nez to kedy malo sancu bezat na nativnom HW v dobe vydania.
on je to trochu problém když Auto je "moderní" způsobem, že jako již nemá volant, protože budoucnost je přece samoříditelná, nicméně samořízení ještě není úplně hotovo a tedy zatím nebylo do auta implementováno. Nakonec je z toho tedy obyčejné auto bez volantu a to se prostě dost blbě řídí a prakticky tomu nepomohou ani sliby, že jednou to samořízení snad bude
Tak nějak to vypadá u Intelu :-)
Keď autu chýba volant, tak Intelu chýba motor a na špici je len preto, že momentálne ide z kopca.
U Intelu volant nepotřebujou ti heftnou kus roxoru na volantovou tyč a jede se dál. :D
Intel ma s resizable barom bohate skusenosti. Uz napr. karty Xeon Phi (Knighs Corner) z r.2014 vyzadovali resizable bar. Je to vec zakladovky a biosu. Prakticky vsetky workstationy z toho obdobia to mali. Na rozdiel od beznych desktopov. Ja som si kvoli tomu kupoval specialnu lacnu zakladovku (MSI A320M Pro Vds), ktora to mala a procak Athlon GE200 s grafikou (aby sa pcie grafika nebila s tou kartou). Rozbehat to bol porod. Tu kartu kartu podporoval jediny Linux - Centos tusim 7cka. Ta option v biose na tej zakladovke sa vola "Above 4G memory/Crypto Currency mining". :)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.