- Kormányok / autós szimulátorok topicja
- Házimozi haladó szinten
- TCL LCD és LED TV-k
- Hogy is néznek ki a gépeink?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Samsung Galaxy Tab S6 Lite 2024 - a visszatérő
- Hobby elektronika
- Samsung Galaxy Tab S8 és Tab S8+ - méretvariációk egy témára
- Autós kamerák
Hirdetés
-
Három éve fontos döntést hozott az AI-ról az Apple
it A Bloomberg szerint saját chipekkel működtetné az AI-szervereket az Apple.
-
Már elérhető Steamen a klasszikus Marathon
gp A közkinccsé tett alkotás eddig is ingyen játszható volt, de nemrég végre bekerült a Valve áruházába is.
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
PROHARDVER!
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Petykemano
veterán
RX 6700 - talán már erre is jut.
Ez elmúlt napokban megjelent egy JPR jelentés, ami negyedéves szinten 6%, éves szinten 19%-os dGPU forgalom csökkenésről számolt be.
Feltehetőleg a következő nagy teljesítményugrást ígérő generációt övező várakozás, valamint a kriptovaluták árfolyamának (a bányászat jövedelmezőségének) megtorpanása, hovatovább csökkenése miatt csökkenhetett a nyomás az eladási csatornákon. Ennek hatására az árak belesimultak a normál, msrp árakba.Persze meg kell jegyezni, hogy a kriptovaluta bányászat nem omlott be, vagyis nem ömlött a használtpiacra rengeteg rendkívül olcsó bányászkártya. Mivel ez nem következett be, így a bolti árak is összeomlás helyett csak szépen belesimultak az ajánlott fogyasztói árba.
Elképzelhető, hogy a következő hetekben bekóstolnak az msrp alá is. Az persze megjósolhatatlan, hogy meddig megy le, ezt meg sem kísérlem.
Ami a hírben érdekes, az az, hogy amíg a kereslet nagyon nagy volt, az volt az álláspont, hogy a cégek igyekeznek a rendelkezésükre álló wafer kapacitásokat olyan termékekre allokálni, amin minél magasabb árrést tudnak elérni. Ennek köszönhető az a lépcsőzetes termékbevezetés (amennyiben nincsenek gyártási/kihozatali nehézségek), hogy szűk kapacitás esetén először a drágább piacokat szolgálják ki, majd azok telítődése esetén kezdenek kisebb, olcsóbb termékeket gyártani.
Ez a lépcsőzetesség lapkán belül is érvényes. Amennyiben nincsenek kihozatali nehézségek, úgy egy lapkát érdemesebb teljes értékű termékként eladni és csak akkor értékesíteni vágott termék formájában akár mesterséges szegmentáció révén, amennyiben a legyártott lapkákat a teljesértékű termék formájában és árán nem lehet eladni.Érdekes kérdés, hogy vajon az RX 6700 összegyűjtött selejtek kiszórása, limitált széria, vagy pedig a legyártott Navi 23 lapkák alacsonyabb áron való értékesítítése arc (árcsökkentés) nélkül?
Találgatunk, aztán majd úgyis kiderül..
-
Komplikato
veterán
válasz Petykemano #57601 üzenetére
Mindenki várja az RX7000 meg az Rtx 4000 szériát remegve, erre kijönnek ilyenek mint az RX6x50 sorozat, az RX6700 10GB vagy a GTX1630. Ez már GPU raktársöprés?
"Figyelj arra, aki keresi az igazságot és őrizkedj attól, aki hirdeti: megtalálta." - (André Gide)
-
Petykemano
veterán
válasz Komplikato #57602 üzenetére
Afféle...
VCZ megfejtette:
"Sapphire BC-2235 GPRO X080 cryptomining card vs Sapphire Radeon 6700
Both 36 CU, 10 GB 160-bit.
Must be a coincidence "
[link]Találgatunk, aztán majd úgyis kiderül..
-
Yutani
nagyúr
-
Petykemano
veterán
válasz Yutani #57604 üzenetére
Elnézést. A kártya nem RX.
Gyanítom ez alapján, hogy valójában nem AMD által specifikált hivatalos termék.
(És nem Navi 23, hanem 22)Vélhetően arról lehet szó, hogy a sapphire megállapodott az AMD-vel, hogy a hibás példányokkal azt kezd, amit akar. Ebben a formában ez selejtszórás, semminthogy mesterséges szegmentáció lenne.
Találgatunk, aztán majd úgyis kiderül..
-
Yutani
nagyúr
válasz Petykemano #57605 üzenetére
És mégis valahogy pont beillik a sorba. Ez a modern chiptervezés csodája.
#tarcsad
-
Yutani
nagyúr
válasz Petykemano #57601 üzenetére
Persze meg kell jegyezni, hogy a kriptovaluta bányászat nem omlott be, vagyis nem ömlött a használtpiacra rengeteg rendkívül olcsó bányászkártya.
Annyira nem omlott be, hogy éppen all-time csúcsot dönt az ETH hashrate:
#tarcsad
-
Devid_81
nagyúr
válasz Yutani #57607 üzenetére
Gondolom boldog boldogtalan banyaszik (meg) hatha csurran cseppen, mar mindent bedobnak meg a Casio szamologepet is, hatha valahogy megis meglehet elni dolgozas helyett
Ekozben a profitability meg az ETH arak mennek le, szoval halott ugy.Annyira "megeri banyaszni", hogy jelen UK villanyarak mellett majdnem 1 fontot termelne naponta egy db RTX 3090 jelenleg...teljesen kedvet kaptam hozza
Vegulis ha lenne 1000db RTX 3090-em akkor tok jol elhetnek[ Szerkesztve ]
...
-
Petykemano
veterán
válasz Yutani #57607 üzenetére
kemény.
Pedig a profitability tényleg nagyon alacsony.
[link]De hát ha még a jelenlegi energiaárak mellett is 1 font/nap, akkor a meglevő infrastruktúrát érdemes járatni.
Vagy a fene tudja. Lehet, hogy érdemes elgondolkodni, hogy a hardver amortizációja havi szinten több-e mint 30 font? Mert ha igen, akkor ugye ma többért el lehet még passzolni, mint 1 hónap múlva. (Ugye most egy 3090-ről beszélünk, ami pár hónap múlva jelentős árcsökkenésen mehet át)Találgatunk, aztán majd úgyis kiderül..
-
Devid_81
nagyúr
válasz Petykemano #57609 üzenetére
Mar eleg sokan feldobaltak a VGA-kat amugy Angliaban Ebayre.
Meglepo de RTX 3080 Ti van £612-ert, RTX 3090-es meg £590-ertNagyon bele sem merultem, mert ennyiert sem erdekelne egyik sem
Szerk: ehhez kepest RX 6900 XT-k meg inkabb £759+ magassagban vannak
Gondolom azert is, mert ezekbol joval kevesebb ment banyaba, igy nincs akkora nagy keszlet a hasznalt piacon sem.
Bar teljesitmeny szempontbol akkor mar inkabb vennek egy RTX 3090-et, 24GB ram es meg olcsobb is, de csereben tobbet is eszik[ Szerkesztve ]
...
-
Abu85
HÁZIGAZDA
válasz Petykemano #57609 üzenetére
Ha a hit erős, akkor a profit másodlagos.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
félisten
válasz Devid_81 #57610 üzenetére
3080 volt a héten többször több darab Gigabyte pl neweggen 699$ ért. Én azt gondolo m ( reménykedem) nagyon le foge sni az áruk nyár közepére ezeknek a kártyáknak és akkorát a mortizálodik az értékük, hogy havi x euroért nem fogja megérni az egész.
Én ennek szorítok, szeretnék egy 3080 12 GB karit"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Devid_81
nagyúr
Ha nem felsz a hasznalt VGA-ktol (mining positive) akkor Angolna foldrol mar lehet szerezni ezt azt egeszen jo aron.
Sztem utazoban amennyiben latszik rajta, hogy hasznalt (bontott doboz) viheto es nem vamolnak.
Mondjuk szamomra a hasznalt Ampere kartya most olyan mint a friss kutya sz@r a jardan, elkerulom inkabb, mert tutira ment honapokat/evet ki tudja milyen korulmenyek kozott...
-
Petykemano
veterán
Navi3 will be in preproduction this month and is expected to be handed over to AIB after August for a final release in October/November.
[link]Találgatunk, aztán majd úgyis kiderül..
-
Petykemano
veterán
Találgatunk, aztán majd úgyis kiderül..
-
paprobert
senior tag
"Nem véletlen, hogy sem az AMD, se az NV nem csinál a következő körben 500 dollár alá GPU-t. Az a piac megdöglött. Az AMD viszont csinál bivaly APU-t (tényleg nagy teljesítményű kiadás, nem klasszikus IGP vonal), hogy tudjon reagálni a Core+Arc kombóra. Az NV is csinálna, ha lenne processzoruk."
[link]
Ez a hír előbb jön Abu-tól, mint hogy a nemzetközi leakerek beszélnének róla.#57617 Petykemano
Edit: marad a last gen $500 alatt, talán.[ Szerkesztve ]
640 KB mindenre elég. - Steve Jobs
-
paprobert
senior tag
válasz Petykemano #57617 üzenetére
Rosszat linkeltem az előzőben, itt a forrás:
https://prohardver.hu/tema/re_bemutatta_eddig_titkolt_fejleszteseit_az_intel/hsz_36-36.htmlEbben a kommentben néhány érdekesség van elrejtve.
Egyrészt az óriás APU-ról még nem hallottam sehol, ez egy meglepő leak Abutól.
Másrészt az "$500 alatti piac döglött" kijelentés... kell ezt cáfolnom?
És ennek az alapgondolatnak a továbbvitele, miszerint az érkező erősebb APU-k fogják az $500 alatti szegmenst lefedni, felidézik bennem a Kaveri-várás időszakát.Az eredeti, költői kérdésem az lett volna, hogy az emberek által tömegében elérhető "AMD GPU-k jövője" az APU lesz?
[ Szerkesztve ]
640 KB mindenre elég. - Steve Jobs
-
félisten
válasz paprobert #57618 üzenetére
az hogy Nvidiának nincsen APU ja nem jelenti azt, hogy nem gyárthat 500$ alá GPU-t.
Itt az Ampere most is vanpl 3060 500 dollár alatt megtarthatják 500 dollár alá őket
AMD mostani árazását ismerve pedig az az óriás APU nem 250 dollár lesz és nem is 500.[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Petykemano
veterán
válasz paprobert #57618 üzenetére
Ez egy régi teória, ahogy mondod, és bár mindig felcsillant valami, az idővel.letekerődött.
Most a csillanás az elérhető árú APU-hoz az infinity cache, ami kihúzhatja a memória sávszesség méregfogát egy közepes IGP esetén. De HBM használathoz is ott az EFB, ami egy nagyobb IGP esetén nagy interposer.nélkül biztosít sávszélt.
Mellesleg az egész már lehet chiplet, nem feltétlenül kell monolitikusnak lennie.De közepes IGP-hez ebben a genben is ott lett volna az IFC és mégis inkább Navi24 lett. Abu azt állítja, ennek fő oka az volt, hogy az bekerülhetett inteles gépbe is.
Szerintem nem fog megszűnni az $500 alatti gpu piac. Legfeljebb nem kap fókuszt, vagyis 5nm-es RDNA3 nem lesz ilyen áron. De az oemeknek mindig fog kelleni olyan relatív olcsó de szar dgpu, Amivel nyerhetnek még pár dollárt ha közben kinyírják a memória sávszélességet 1 memória modullal.
Találgatunk, aztán majd úgyis kiderül..
-
paprobert
senior tag
Szerintem is, még mindig ebben a szegmensben van a vásárlók 70 százaléka.
Nézd, ha amiatt nem tervez az AMD $500 alá, mert az új gyártástechnológia "drága", azon az APU sem segít.
-Max. a GDDR phy-t lehet megspórolni
-egységnyi teljesítmény egy dedikált GPU-val olcsóbb(vagy azonos áron gyorsabb)
-az összetett APU gyártási hibára hajlamosabb mint egy GPU package
-az Infinity Cache egyaránt gyorsít egy GPU-t is
-egy APU hőmérsékletileg limitáltabb a CPU jelenléte miatt
-elavult node-ot használni APU-ban problémásabb.Én alig látok pozitívumot akár költség, akár teljesítmény, akár felhasználási szempontból.
[ Szerkesztve ]
640 KB mindenre elég. - Steve Jobs
-
Yutani
nagyúr
válasz paprobert #57621 üzenetére
$500 alatti szegmensben lehet értéksíteni a már létező megoldásokat. Oké, a Navi24 egy kalap 57@®, de a Navi23 is egy sokáig piacon tartható termék szerintem, akár tovább vágva is (RX 6600 "LE/SE").
Ami biztos: a Navi24 még évekig velünk lesz: kicsi, olcsó (a gyártónak), szükség kártyának megteszi, főleg az OEM-eknek.
[ Szerkesztve ]
#tarcsad
-
Radeon's targeting poor OpenGL performance with a future AMD Software release
Tudjuk, "az OpenGL-be senki nem öl erőforrást...oh wait"
Szerencsére és csodával határos módon az AMD-nek eszébe jutott rendbe tenni a katasztrofális OGL driverét bő másfél évtized után. Végül is jobb későn, mint soha. Ez a D3D11 driver rendbe rakása után logikusnak tűnt, de én elkönyveltem magamban, hogy az AMD már soha többé nem fogja rendbe tenni, ezt leginkább az itteni propaganda miatt hittem el, de hála az égnek hogy én is és a propaganda is tévedett (utóbbi számomra nem meglepő)!
Úgy tűnik Lisa mama végre rendbe akarja tenni a driveres lemaradásokat és hajlandó erőforrást ölni abba, amibe senki nem akar erőforrást ölni, legfőbb ideje volt!
Gameplay csatornám: https://www.youtube.com/channel/UCG_2-vD7BIJf56R14CU4iuQ
-
Abu85
HÁZIGAZDA
válasz huskydog17 #57623 üzenetére
Egyrészt az AMD meghajtójának OpenGL drivere egy workstation driver. Nem pedig performance. Másrészt az OpenGL baja az, hogy ha ezt átrakják performance driverré, akkor keletkezik kismillió bug, mert maga az OpenGL nem jól működik. Hiába szabvány, ha mindenki úgy értelmezi a specifikációt, ahogy akarja. Ergo minden egyes OpenGL program úgy van megírva, hogy van külön kód minden gyártóra. Erre mondjuk a kódcsere áthozható, de amint hozol egy új programot, rögtön ott fogja találni magát a fejlesztő, hogy kell egy külön kód az új AMD driverre, és egy másik a régire. Emiatt értelmetlen az egész OpenGL, mert egy ilyen drivercsere már gyártón belül is gyakorlatilag kompatibilitási gondokat eredményez. Az AMD tudna erről mesélni, mert ők rendelkeznek a legfrissebb OpenGL driverrel. 2004-ben döntötték el, hogy újraírják a nulláról, és 2007-ben lett kész. Ekkor csinálták meg azt, hogy a régi performance drivert kicserélték workstation driverre, hogy masszívan a szabvány specifikációját kövesse a rendszer. Viszont a játékok többsége szart a szabványra, emiatt ennek haszna nem volt, maximum annyi, hogy ha valaha is szabványos kódot akartál OpenGL-re, akkor nem mentél tovább az AMD OpenGL driverénél. A performance driverek mások. Azoknál szabadabb a szabvány értelmezése, és ezt ki is használják a cégek, mert teljesítményt nyernek velük. Persze annak az árán, hogy a saját értelmezésük eltér a konkurens értelmezésétől, és cserébe két kód kell, vagy több, ha per driverben is gondolkodsz. Ezért döglött meg az OpenGL, nincs senkinek sem türelme 5-6 különböző kódutat fenntartani, amikor Vulkan API-ra elég egy kódút.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Most hosszasan leírtad a te saját nyelveden, hogy az AMD valamiért képtelen volt normális OGL drivert írni, ezt tudjuk, látjuk másfél évtizede.
Ha annyira szar a performance, akkor az NV-nél miért nem volt soha gond a nagyságrendekkel nagyobb teljesítménnyel?
2004-ben kezdték újraírni? Na akkor ott k*rták el az egészet. 2004-ben még jó volt a teljesítmény, 2007-től nagyjából fos lett, szóval jó munkát végeztek, a performance-t kinyírták, de 15 évvel később úgy tűnik visszahozzák.
Ha annyira bugos a performance mód, akkor miért hozzák most vissza 15 évvel később?
Hogy lehet az NV-nek nem voltak gondjai a jó teljesítménnyel?Állandóan azt szajkózod, hogy a programok a sárosak így meg úgy és nem szabványosak. Érdekes, hogy az NV-nek nem okozott gondot, minden OGL programmal gond nélkül működött jó teljesítménnyel, viszont az AMD-nél nagyon súlyos problémák voltak az elmúlt bő évtizedben (személyesen is tapasztaltam elég sokszor), de az alkalmazások a szarok, ezzel egyidőben azt is állítod, hogy minden fejlesztő, aki OGL-re programozott, hülye volt és nem vette figyelembe a szabványt és szándékosan úgy írta meg a játékot, hogy AMD-n szarul fusson.
VAAAGY
van egy olyan lehetőség is, hogy a fejlesztők megtettek mindent, hogy mindenen jól fusson, szabványos kódot írtak, de az AMD fos driverével nem tudnak mit kezdeni.
Ez utóbbi sokkal valószínűbbnek tűnik nekem.
Ha pedig figyelembe veszem, hogy például a Teardown fejlesztői hónapokat, rengeteg időt és pénzt égettek el arra, hogy AMD-n valahogy értelmes teljesítményt érjenek el (külön kódutat írtak), hogy valamennyire megközelítsék az NV driver out of the box tempóját, akkor pláne őrültségnek hangzik az elméleted.A legvalószínűbb inkább az, hogy az NV csinált szabványos drivert, míg az AMD valami fost odahányt 2007-ben, amihez nem nyúltak hozzá 15 évig. Ja de hozzányúltak, mert a A Doom 4 OGL teljesítményt is az AMD k*rta el driverből. Gondolom Tiago Sousa és az id Software is figyelmen kívül hagyták a szabványt.
Ha szerinted az AMD annyira szabványos, akkor miért módosítják most 15 évvel később és miért akarnak kismillió bugot (ahogy te írtad)?
Adj légyszi egy linkeket, ahol programozók írásban megerősítik az elméleted. Ha nem tudsz ilyeneket adni, akkor csak egy újabb őrültséget olvashattunk tőled és akkor részemről bejeztem ezt a diskurzust.
Gameplay csatornám: https://www.youtube.com/channel/UCG_2-vD7BIJf56R14CU4iuQ
-
Hellwhatever
aktív tag
Hogy lehet az hogy egy szabványt nem a specifikáció szerint implementálnak (hiszen ettől szabvány), illetve alkalmazás szintjén hol és hogyan lehet hibázni? Tényleg érdekel a dolog, akár egy külön cikket is szívesen olvasnék a témában úgyis uborkaszezon van hardver fronton.
Nagyon leegyszerűsítve gondolom megvannak az OGL interface-ek, ezeket kell megvalósítani majd a megfelelő értékkel visszatérni.
Alkalmazás szintjén pedig ezeket a függvényeket hívják.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz huskydog17 #57625 üzenetére
Évek óta ismert problémát írtam le. Ez végezte ki az OpenGL-t.
#57626 Hellwhatever : Leginkább úgy, hogy amikor az OpenGL-t specifikálták, akkor már a fejlesztésébe bele volt kódolva, hogy el lehet szarni.
Rich elég sok előadást tartott anno, amikor a Valve motorját portolta natívan OpenGL-re. A lényege ezeknek mindig az volt, hogy hiába beszélünk egy API-ról, a gyártók az egyes függvényeket másképp implementálják. Egyszerűen a specifikációban leírtak nem egyértelműek.
Többször utalt rá, hogy az NV-vel gyorsan működhetnek a dolgok, de a kód, amit így megírsz nem lesz szabványos, és az NV-nek a fejlesztőeszközei pontosan ezért használhatatlanok, mert a debug eszközökkel összevesznek, ugyanis a debug nem azt várja, amit kap, egy nem szabványos kódot. A fejlesztéshez tehát nem tudott a Valve mást használni, csak AMD hardvert, mivel a GPU PerfStudio és a CodeXL eléggé szabványos eszközök voltak, és kompatibilisek szabványos debug eszközökkel is, illetve az AMD workstation drivere is szabványosan kezeli az API-t, de ha erre megírsz egy kódot az nem jó az NV-nek, mert az meg más kódot vár. Olyat, ahogyan az NV értelmezte a szabványt. Emellett az AMD workstation drivere pont azért workstation driver, mert arra van kigyúrva, hogy a specifikációknak megfelelően kezelje az API-t, és ilyenkor nem csinál olyat, amitől az alkalmazás összeomolhatna, nem értelmezi szabadon a függvények specifikációit, hogy kihagyjon teljesítményigényes ellenőrzéseket. Utóbbitól lesz egy performance driver gyors, egyszerűen a nagyon lassú munkafolyamatokat koncepció szintjén kihagyja, még akkor is, ha a specifikáció előírja az erőforrások ellenőrzését, annak érdekében, hogy ne alakulhassanak ki hazardok. Viszont ilyenkor nagyon sok múlik a játékra szabott meghajtón, mert ott kell olyan ellenőrzési rutinokat beépíteni, ami ezt megakadályozza, ha már az API működését nem követik. És ez az, amiért a performance driverekkel lehetetlen a nagy OpenGL alkalmazások debugolása és profilozása. Egyszerűen a meghajtó még nem ismeri az alkalmazást, és az ellenőrzések kihagyásával tele lesz az egész munkafolyamat hazarddal.Ezen túlmenően nagy gond volt még a shader fordítás. Az OpenGL programban magát a shader forrást kellett szállítani, és azt a meghajtó fordította le a GPU-nak. De az egyes meghajtók más kódokat igényeltek, attól függően, hogy miképpen értelmezték a specifikációt, ezért kellett külön shader az összes gyártónak, sőt, az egyes architektúrák sem mindig fogadták el a gyártóspecifikus shadert, így hiába beszéltél szabványról, akkor is egy gyártóra két-három kódutat szállítottál OpenGL-ben, vagyis mindent kb. 7-9-szer kellett megírni. És mivel más megoldás nem volt, ez egy leülős-gépelős feladat volt.
Nem véletlen, hogy a Vulkan API már sokkal egyértelműbben fogalmaz a specifikációk tekintetében. Kevésbé félreérthető. Alapvetően a dokumentációját az AMD-től emelték át, és azt módosították, tehát helyből már egy olyan alap állt rendelkezésre, amit hozzáértők írtak meg. És így már jól lehetett építeni erre az alapra. A shader fordítást is megváltoztatták, mostantól nem lehet forrást szállítani, hanem IR-t kell, és az IR-re gyári fordító van, vagyis nincs olyan, hogy az NV/AMD/Intel "véletlenül" máshogy értelmezte a specifikációt. Az IR-ig hozzá sem tudnak szagolni a fordításhoz, tehát ők már csak az IR után dolgozhatnak, és ez a köztes nyelv nem magas szintű, így sokkal-sokkal egyértelműbb, mint magas szintű nyelvről gépi kódot fordítani.
Röviden, az volt a gond, hogy OpenGL-re nagy applikációkat lehetetlen volt írni egy kódútból. Egyszerűen több kellett. Emiatt meg is pusztult az API. A Valve is áttért később a Vulkan API-ra, mert igazából nagyon-nagyon drágává tette az OpenGL mód karbantartását az, hogy 7-8-szor volt megírva minden.
#57628 morgyi : Igazából a gyártóspecifikus kiterjesztések egyszerre voltak hasznosak és katasztrofálisak. Az egyik előadáson Rich meg is említette, hogy ARB kiterjesztésekkel lehetetlen gyors kódot írni, egyszerűen azok túl rosszak. Emiatt a Valve is a lehető legtöbb dologra gyártóspecifikus kiterjesztéseket használt. Ha ezek nem lettek volna, akkor az OpenGL a DirectX leképező teljesítményének a huszadát sem szedte volna össze, annyira el van szarva az egész. A kiterjesztésekkel lehet hozni bele teljesítményt.
Nincs azon mit csodálkozni, hogy manapság nem igazán jön OpenGL-re semmi. Néhányan a régi kódutakat még karbantartják, de a Vulkan akkora átütő siker, és a Khronos annyira leállt az OpenGL fejlesztésével, hogy ez a kérdés már rég eldőlt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
félisten
Egyszer érném meg hogy így érvelsz Intel és Nvidia oldalán....( nem fogom)
Ott általában azt olvassuk mért szar amit csinálnak még ha jónak is tűnik,( lásd eza hozzászólás) itt meg azt hogy azért szar valami az AMD től mert közben jó, mint mindig. Egyszerűen nem tudnak hibázni náluk, na.[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Yutani
nagyúr
Én a #57629-ben azt látom leírva, hogy miért sz@r az OpenGL, miért lassú az AMD, és miért gyors az NV implementáció. Viszont azt nem értem, hogy miként lehetett mindig is gyors az NV OGL alatt, ha annyit kellett minden alkalmazásra optimalizálni a drivereket. Ennyi erőforrást tett vajon bele, hogy minden jól fusson?
#tarcsad
-
félisten
válasz Yutani #57631 üzenetére
Linux alatt amúgy egyáltalán nem rossz az AMD OGL futasa Nvidiához nézve,sőt.De ott nyílt forráskód ugye.Tehat szinte csak driveren mulik a sebesseg.Ott megoldjak a fuggetlen fejlesztők.
Igen valószínűleg ez van mögötte.Évek óta az első szabványhitelesítéseket pont az Nvidia szerzî meg,tehát annyira nem mennek ők szembe ezzel a dologgal se driveresen se fejlesztői eszközök terén.[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Petykemano
veterán
Bocsánat.Elnézést.
Abu nem válaszolta meg a kérdésemet.Jól értem, hogy az OpenGL valójában nem egy API, hanem csak egy API-speficikáció, amire minden hardver gyártónak írnia kell egy implementációt. És az AMD-nek eddig volt valamilyen implelemtációja, de most csinált egy újat, ami elvileg jobb. De csak elvileg.
Merthogy Abu kritikája szerint az OpenGL specifikációja annyira pontatlan, elnagyolt, hogy valójában egy-egy implementáció bemeneti és kimeneti eredménye (mivelhogy épp annak nem kéne számítania, hogy belül mi történik) annyira más, hogy ahhoz egy-egy alkalmazás kénytelen alkalmazkodni és ha az AMD új implementációja másként viselkedik, akkor az eddigi AMD openGL implementációra való optimalizációk az összes alkalmazásban kuka.Jól értem?
A másik kérdésem pedig az volna, hogy tulajdonképpen egy ilyen API-nak nem az lenne a lényege, hogy függetlenítse az alkalmazást a hardvertől és/vagy a hardverhez tartozó drivertől? Vagy ez jelen esetben csak olyan mértékben történik meg, hogy mondjuk az AMD és az Nvidia openGL implementációja is megoldja azt, hogy az alkalmazásnak ne kelljen foglalkoznia azzal, hogy miylen amd vagy milyen nvidia kártya van benne, de a két gyártó openGL implementációja azért annyira eltér egymástól, hogy az alkalmazás attól már ne tudjon elvonatkoztatni, hogy melyik gyártó openGL imlementácójával kommunikál?
Jól értem?
Találgatunk, aztán majd úgyis kiderül..
-
félisten
válasz Petykemano #57633 üzenetére
Szerintem az van amit Husky is és tulajdonképpen Abu is irt,csak ugye ő cukormázba foglalta,Husky meg a vegeredmenyt jelentette ki egy kerdessel megspekelve.
AMD tulajdonkeppen nem foglalkozott OGL gyorsitasaval eddig pont az a fazis ami ahogy irtad belul tortenik nem volt kezelve naluk.Hogy most miert kerult porondra dx11 es az OGL a fene tudja.Szerintem nem kuka az csak lassu es bugos,de szabvanyos.
Abu szerint az Nvidia azert gyors mert sok szempontból nem szabvany szerint kezelte a dolgot megkerult check in fazisokat AMD meg igy elmeletileg stabilabb de lassabb.Most ez ellen az szól hogy rengeteg bug volt es van OGL jatekokkal AMD nel,nem cdak a sebesseg es evek ota az elso hitelesiteseket Nvidia szerzi meg,ami igy eleg erdekes mert Abu szerint az AMD fejlesztoeszkozokket hasznaljak.Kisse ellentmondasos de mindegy is ezek ilyen parttalan vitak.[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Abu85
HÁZIGAZDA
válasz Yutani #57631 üzenetére
Igen, bele van rakva egy rakás munka. A Valve előadásai nagyon jól mutatták ezt. Ők ugye kényszerűen AMD hardveren fejlesztettek, mert akkora kódmennyiséget az NV debug eszköze nem tudott kezelni. Szétfagyott az egész a picsába.
Itt van a dia, ami azt írja le, hogy miért az AMD fejlesztőeszközét használták:
Ezt az előadást láttam is, és Rich azt is hozzátette, hogy ha nincs a GPU PerfStudio 2, akkor sose lett volna OpenGL módja az említett két játéknak. Egyszerűen kivitelezhetetlen lett volna egy ekkora kódbázisra az egész, mert egyénileg kellett volna minden egyes függvényt ellenőrizni, hogy az hogyan fordul le xy hardverre, és ott pontosan mit csinál. Az pedig akár 5-6 évnyi munka is lett volna, és olyan időtávban felesleges dolgozni, mert mire ellenőrzik xy hardverre, addigra két-három generációval későbbi hardverek jönnek, amelyekre szintén ellenőrizni kell, vagyis ismét jöhet a munka, bár nem 5-6 évnyi, de folyamatosan patch-ek kellenének, amelyek az érkező hardvereket 1-2 év csúszással támogatják csak.Ezen túlmenően a szabványos kódjuk, meg se moccant az NV hardvereken. Egyszerűen sűrűn szétfagyott, illetve kaptak egy rakás stallt. Ezt úgy oldották meg, hogy a kódot mindig elküldték az NV-nek, amely cég egy új driverrel együtt visszaküldte a kívánt módosítást. Tehát nem csak egy másik kódút kellett, hanem egy specializált driver is, amit mindig használtak, mert ha nem, akkor a módosított kódút is szétfagyott a picsába, és a teljesítménye is kb. a tizede volt annak, amire szükség volt.
Alapvetően ezek voltak az OpenGL bajai, és évek óta ismertek, csak a Khronos egyszerűen nem fordított erőforrást a kijavításukra, mert feltettek mindent a Vulkan API-ra. Ezzel együtt pedig a Valve is befejezte az OpenGL mód supportját. A Vulkan mellett nem volt értelme.
Tehát amikor valaki OpenGL-re dolgozik egy igen nagy programot, akkor igazából gyártói segítség nélkül azt nem fogják összehozni. És a gyártók is egyedi kódokat javasolnak, gyártói kiterjesztésekkel, amit a Valve szintén említett, hogy használják is bőven, mert az ARB-vel sokkal lassabb a program. Ilyen szintű együttműködés ugyan megoldható, de végül lesz gyártónként két-három kódút, és specializált driverek, és a kódutakat úgy kell karbantartani, hogy új driver kell a módosításokhoz. Ma már ezzel nem éri meg foglalkozni. Az egyetlen működő OpenGL debugert sem fejleszti már az AMD. Persze a forráskódját kiadták, hogy aki szeretne dolgozni, az elmaszatolhat vele, de sokkal-sokkal könnyebb Vulkan API-ra váltani.
#57632 b. : Ami ugye Linux alatt megint úgy sikerült, hogy a Valve a saját programjaihoz módosította a meghajtót, vagyis ez sem szabványos teljesen.
A szabványhitelesítés lényegtelen OpenGL alatt, mert az a gond, hogy maga a dokumentáció nem fogalmaz egyértelműen, hogy mik a követelmények. Egy-egy dolog implementációjára több út is van, és a gyártók ezt ki is használják. Itt változott nagyon sokat a Vulkan. Amikor átvették a Mantle API-t, akkor vele átvették az AMD dokumentációját is, és az nagyon szigorúan fogalmazza meg, hogy mit hogyan lehet implementálni. Ezt a Vulkan vitte tovább, tehát alig van olyan tényező, hogy valamiben kérdés merülne fel. Ha van is, azt is nagyon gyorsan egyértelműsítik, hogy ne álljon be az a helyzet, ami az OpenGL-nél.
Az OpenGL dokumentációjával simán lehet olyan meghajtókat írni, amelyek mind átmennek a hitelesítésen, de eközben ugyanazokat a kódokat nem úgy értelmezik. És ez az API hibája, nem egyértelmű a specifikáció, és ezt a gyártók szándékosan félreértelmezik, hogy gyorsabb legyen a meghajtó, csak nem eszi meg a szabványos kódot.
Érdekes módon a workstation piacon mindenki tudja, hogy mi a szabványos és mi nem. Ott eléggé egységesen van kezelve minden, akármilyen gyártói drivert dobsz fel, megeszi a szabványos kódot. Tehát nem hülyék a gyártók sem, csak tetetik, hogy hülyék, mert csak az AMD hozza át a workstation meghajtóját Windows alatt a gaming driverbe. Ez változik meg a következő nagy batch-csel, de ezzel együtt már az AMD meghajtója sem lesz szabványos.#57633 Petykemano : Igen jól érted. Az új meghajtóval a régi játékok OpenGL módja problémás lehet, de mivel alig van OpenGL program, így nagyon egyszerű per alkalmazás szintjén leprofilozni az egészet, és akkor az új meghajtó problémáit célirányosan lekezelni úgy, hogy az AMD még a fordítás előtt kicseréli a programkódot egy olyanra, amit a nem szabványos meghajtó megeszik. Ezt csinálja az NV is. Csak ugye az ilyen modell megöli az API-t, mert így fejleszteni lehetetlen rá, lásd fentebb Valve.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Petykemano
veterán
Helyükre kerülnek a dolgok:
AMD rumored to be working on another Navi 3X GPU with 16384 Stream Processors [link]Találgatunk, aztán majd úgyis kiderül..
-
Alogonomus
őstag
válasz Petykemano #57637 üzenetére
-
Abu85
HÁZIGAZDA
Közben volt 3D matyi futás. Egyelőre eredmény nélkül, de a maximum elért órajel 3,8 GHz volt.
Ez amúgy lehet reális, ha tényleg ugyanazzal a performance library-vel készül, amivel a Zen 4, az is tud 6 GHz-re turbózni.
Valszeg a tipikus órajel az AMD-nél prociban 5-5,5 GHz közötti lesz, míg GPU-ban 3-3,5 GHz közötti.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Petykemano
veterán
Hogyan küzdötték le a hősűrűséget?
Pár éve még azt mondogatták minden csövön, hogy a sűrűség növekedésével degradálódni fog az elérhető frekvencia. Lényegében ez volt anno a 20nm problémája is.(Ha tippelnem kéne arra tippelnék, amit az Intel 4-nél is lehet olvasni, hogy a rézről kobaltra váltás ugyan nem vált be, de valamilyen kobalt-réz ötvözet, vagy Kobalt bevonatú réz viszont nagyonis [link] )
Találgatunk, aztán majd úgyis kiderül..
-
félisten
válasz Alogonomus #57638 üzenetére
Ez nem feltétlenül gamer kártya, írja is a szivárogtató.
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Petykemano
veterán
Időbeli lefolyást nézve vajon mi történhetett?
Az első 2 GCD-s tervek nem működtek, ezért történt egy fallback 1 GCD-re, de Végülis egy későbbi designban sikerült megoldani, vagy megcsinálják a 2 GCD-s megoldást, de csak compute célokra?
Vagy azért vetették el a 2 GCD-s terveket, mert 3-3.5GHz-en egy nagyobb GCD is elég és wafer kapacitás tekintetében így hatékony? De prémium (Pro Duo) terméknél beléfér?
Találgatunk, aztán majd úgyis kiderül..
-
félisten
válasz Petykemano #57644 üzenetére
Nem tudni.Tippelgetnu lehetne .
Azt gondolom ,az egy GCD-s tud nagy orajelen menni,igy kisebb GPU,magas orajel,jobb kihozatal ,olcsobb gyartas es csucs közeli teljesitmény.
Nvidianal 18000+ feldolgozó lesz a csúcs Ada .Tegnap kopite mar azt irta a 2,8 Ghz nem kihívas neki azaz 3 Ghz Biztos megy ami hatalmas előrelépés.Azt gondolom,hogy tokéletesen tudják megint,mit hoz a másik és hol tart,mit változtat. egymashoz igazitjak a Csucs kategoriat.
lehet meglepő lehetett az Ada monolitikus teljesitménye AMD nek,ezért lépniek."A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Abu85
HÁZIGAZDA
válasz Petykemano #57641 üzenetére
Fene se tudja, de ugye a saját performance libjük manapság erőteljesen órajelre megy. Szóval ez bele van tervezve a dizájnba. Valószínűleg 5 nm-en már lehet rá elég tranzisztort áldozni. Alapvetően az órajel is egy dizájnkérdés manapság. Rá tudsz tervezni egy lapkát.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Petykemano
veterán
mi az oka, hogy az AMD (és az Intel is) a szűkebb, de magas órajelen működő architektúra irányába megy és nem követi az Apple-t a széles, alacsony órajelen és alacsony fogyasztással való működés felé?
Nyilván az IPC (architektúra szélesítése) nem egyszerű, azért azt kimondhatjuk, hogy az AMD és az Intel is egy nagyon (egy évtized óta) bejáratott ösvényen halad a processzoraik jelenlegi felépítésével kapcsolatban és toldozgatás-foltozgatás, bufferek, pufferek, cache-ek kisebb-nagyobb bővítése volt (manapság főleg inkább az intelnél) de az alapvető felépítés nem nagyon változott.
Nyilván a magasabb IPC elérése széles architektúrával jelentékeny tranzisztorköltséggel jár. De mint mondod, a magas frekvenciát elérni képes architektúra sincs ingyen tranzisztor szempontjából. Nem is beszélve arról, hogy a magas frekvenciához magas feszültség kell, ami növeli a tranzisztorok melegedését, a hősűrűséget ez pedig azt eredményezheti, hogy az architektúra tranzisztorsűrűsége messze elmarad a névlegestől.Találgatunk, aztán majd úgyis kiderül..
-
Abu85
HÁZIGAZDA
válasz Petykemano #57647 üzenetére
Mert van olyan performance libjük, amivel ezt megtehetik, ellentétben az Apple-lel, amely cég a gyári libeket használja.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Petykemano
veterán
-
Abu85
HÁZIGAZDA
válasz Petykemano #57649 üzenetére
Mert olyat akarnak csinálni, amit el tudnak adni. Olyat nem, ami csak az Apple-nek jó, de az Apple nem veszi meg.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
- Bocsánatot kért az Apple, mert nagyon mellélőtt a legutóbbi reklámjával
- gban: Ingyen kellene, de tegnapra
- Kormányok / autós szimulátorok topicja
- EAFC 24
- Milyen autót vegyek?
- Házimozi haladó szinten
- Okosóra és okoskiegészítő topik
- exHWSW - Értünk mindenhez IS
- Ismét egyedit alkotott a Sharp
- Skoda, VW, Audi, Seat topik
- További aktív témák...
- Zotac Trinity RTX 3080 OC videokártya /Doboz/Friss Mx6 paszta/Beszámítás/
- nVidia RTX 3080 Ti 12GB Founders Edition + GARANCIA
- Palit Geforce RTX 3060 12GB /CSAVARMATRICA/GYÁRI ÁLLAPOT/BESZÁMÍTÁS/
- BESZÁMÍTÁS! ASUS TUF RX 7900 XTX 24GB GDDR6 videokártya garanciával hibátlan működéssel
- ÚJ EVGA GeForce RTX 3080 FTW3 ULTRA GAMING 10GB GDDR6X (10G-P5-3897-KR) Videokártya
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen