Hirdetés
- Mobil flották
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Vodafone mobilszolgáltatások
- Samsung Galaxy Watch7 - kötelező kör
- iPhone topik
- Redmi Note 13 Pro+ - a fejlődés íve
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Xiaomi 13 - felnőni nehéz
- OnePlus 8T – fazonigazítás
- Google Pixel 9 Pro XL - hét szűk esztendő
Hirdetés
-
Színpadon a hardverzenekar
ph A hangeszközöké és monitoroké a rivaldafény, de asztali gépekről, komponensekről, notebookról és egérpadról is szó esik.
-
Érkezik a Redmi Watch 5 Lite
ma Szeptember 25-én Indiában lesz az aktivitáskövető premierje, és lehet, hogy marad is azon a piacon.
-
Decadent - Az őrület határán
gp A jövőre érkező játékban egy veteránt irányíthatunk, aki a fiát szeretné megmenteni a rémségektől.
-
Mobilarena
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
-
Abu85
HÁZIGAZDA
Pont ugyan úgy kerül bele a VRAM-ba/cache-be az adat, ahogy ma, csak a menedzsment hardveres lesz, ami lehetővé teszi, hogy a hardver döntsön és ne a szoftver. Ennek két alapvető előnye lesz: jóval kevesebb memória kell hozzá, illetve jóval ritkábbak lesznek a szoftveres menedzsmentből eredő akadások. Lásd például a BF1-nél a kezdeti DX12 módot, annak az akadásai a Vegát nem érintettek volna, mert a hardver eleve nem egy felületesen optimalizált menedzsmentet használt volna, hanem a saját hardveres megoldását.
A fejlesztők igény szerint használhatják a normál működést is, de nem fogják. Az eddigi tapasztalatok szerint nagyon messze vannak a hardveres menedzsmenttől. Márpedig nem éri meg heteket optimalizálni a rosszabb eredményért.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
HSM
félisten
De nem érted a mondanivalóm lényegét. A hardver nem tudja előre, mi fog következni a játékban, ergó mire lesz hamarosan szükség, az csak a múltat ismeri és a jelent, mi kell most, és mi kellett korábban. Viszont, amikor MOST rájön, hogy valami kell, amire eddig nem volt szükség, akkor az az adat lassan fog rendelkezésre állni egy VGA memória sebességéhez képest, ami LAG-ot fog okozni. Hiába raksz SSD-t a VGA-ra, az is semmi sebességű, ahogy a rendszermemóriát is csak a csigalassú PCI-E-en keresztül éri el.
Tehát valóban jól működő, lagmentes menedzsmentet csak az előrelátó és jó programozó képes készíteni.
[ Szerkesztve ]
-
Jack@l
veterán
válasz Yutani #26502 üzenetére
Ha abu leírta, akkor az már úgy is van. Én egy szóval nem mondtam olyat, hogyha nv csinálja ugyanezt játékokban, akkor az meg jó... (nem is értem honnan sikerült ezt kikövetkeztetni)
[ Szerkesztve ]
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
Jack@l
veterán
Onnan indul a dolog(bullshitelés), hogy nem is a hardver fogja ezt intézni, hanem a driver "hardveres"
[ Szerkesztve ]
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
Abu85
HÁZIGAZDA
Pont ugyanannyit tud előre a hardver, mint a szoftver. Az persze a hardver előnye, hogy sokkal gyorsabban reagál, mert a szoftveres menedzsmentnek mindenképpen kell ellenőrzés, ami nemi prociidőt elvesz. Jósolni pedig nem lehet. A szoftver sem képes rá, mert a te döntésed, hogy merre fordulsz és ez mindenképpen kiszámíthatatlan. A hardveres modellnek van itt annyi előnye, hogy sokkal takarékosabban bánik a memóriával, így jóval a szoftveres menedzsment előtt betölthet adatokat, amit nem biztos, hogy használni fog a program, de a menedzsment formája nem követel többletterhelést, tehát a szoftveres modellel szemben a hardveres menedzsment semmit sem veszít, ha nagyon a biztonságra játszik.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Jack@l
veterán
Várjunk, itt van nekem egy hülye hardveres robotom aki csak megy az utcán, ha elkezd esni az eső, kinyitja az esernyőjét.
Egy másik meg kommunikál fejlett radarrendszererel, van pontos időjárás előrejelzése. A városi locsolóhálózat is előre figyelmezteti hogy bekapcsolják az öntözést. Vajon melyikük lesz vizes?[ Szerkesztve ]
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
HSM
félisten
"Pont ugyanannyit tud előre a hardver, mint a szoftver."
Hát, nem éppen."...mert a te döntésed, hogy merre fordulsz és ez mindenképpen kiszámíthatatlan."
Itt a bibi. Persze, az előtted, és mögötted lévő részeknek is készen kell állnia a videómemóriában, hogy ne legyen lag. De ezt a szoftver tudja, hiszen a programnak kutya kötelessége ismerni, hova tudsz eljutni mondjuk 5 másodpercen belül, azoknak mindenképpen azonnal rendelkezésre kell állniuk, tehát a szoftver igenis képes előre látni, "jósolni". A grafikus hardver számára viszont ez nem létezik, annak pont ugyanolyan adat a következő lehetséges 5 másodperc, mint bármelyik másik, egészen addig, míg oda nem értél, és meg nem született e rednerelési parancs....(#26507) Jack@l: Mekkora jó példa... Zseniális, pontosan erről beszéltem.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz Jack@l #26507 üzenetére
Na ez az, ami miatt nem értitek. Azt hiszitek, hogy a szoftveres menedzsmentnek több adat all rendelkezésre. Nem. Pont ugyanannyi. Ha mindenképpen ezt a példát akarjatok, ami szerintem hülyeség, de legyen... Szóval az történik, hogy ha elkezd esni az eső, akkor a hardveres megoldás érzékeli és kinyitja az esernyőt. A szoftveres megoldás esetében engedélyt kell kérni az esernyő kinyitására, tehát meg kell kérdezni a szoftveres menedzsmentet, hogy ezzel nem okoz-e bajt, erre kap majd egy választ a hardver, és csak utána nyithat esernyőt.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Jack@l
veterán
Azért nem értjük, mert baromság amit írsz. Legalábbis fejlesztői szemmel. Vagy hülye(csak egyszerű feladatokra alkalmas) valami és gyors, vagy lasssabb és jó. Az előre jósolt memóriamenedzsment nem a csont egyszerű feladatok egyike...
Ahogy te se tudod megmondani egy útvesztőben mi fog következni, csak ha te csináltad az útvesztőt és látod az egész térképet.[ Szerkesztve ]
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
Abu85
HÁZIGAZDA
Ilyeneket a szoftver nem tud. Ez nem mesterséges intelligencia, hanem memóriamenedzsment. Arról dönt a szoftver, hogy melyik adat legyen a VRAM-ban és melyik a rendszermemóriában. Ezt pedig nem egy távoli szerver 100 millió sorból írt AI-ja vezérli, ami figyeli minden mozgásodat.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
HSM
félisten
Igen, de a szoftvernek van ideje engedélyt kérni és ellenőrizgetni, mert bőven előre tudja, mikor lesz valamire szükség.
(#26511) Abu85: Nem hát. Régen ezt úgy oldották meg, hogy volt egy betöltő képernyő, amikor szépen a memóriába lapátolta a program, amire a következő pályarészen szükség lehet. Pazarló? Az. Jól működik? Szuperül. Egyszerű? Mint a szög.
Ugyanezt okosabban néhány program úgy oldotta meg, hogy pályarészeken amikor áthaladtál, akkor a háttérben elkezdte cserélgetni a memória tartalmát. Ugyanaz a pazarló, de jól működő rendszer, load képernyők nélkül. De itt fontos látni, hogy a pazarlás azért szükséges, hogy ne kelljen über AI a háttérbe jósolgatni. Persze, a buta hardveres megoldás tökéletesen spórolós lesz a rammal, egy bitet nem fog felelegesen megtölteni, de ennek az lesz az ára, hogy lagtenger lesz a program, mikor új részekre érsz.
(#26510) Jack@l: Pontosan. És a jól megírt program pontosan tudja, hogy ha egy pontra elérsz, akkor ezt és ezt kell betöltögetni, hogy mire ténylegesen odaérsz, ne a 32*32 pixeles textúra feszüljön az orrodba egy fél képernyőnyi tárgyon.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz Jack@l #26510 üzenetére
Senki sem beszél jósgömb menedzsmentről. Az egész alapvetően csont ugyanúgy működik, mint a szoftveres, csak áthelyezve a hardverbe, ezzel szerezve neki lényeges előnyt a hatékonyság tekintetében, mert kizárod az emberi hibát, illetve az összes többletterhelést. Önmagában a HBC nem nagy trükk, csak azt, ami ma szoftverben zajlik átnyomja hardverbe. A HBCC igazi trükkje az 512TB-os flat címzés, de ez leginkább a professzionális vonalon lesz kihasználható. De erről most nem értekeztünk, a sima Radeonokon szempontjából lényegtelen is.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Jack@l
veterán
De milyen hardverről beszélsz? A vga fogja írogatni majd az alaplapi memóriát, csak úgy brahiból? Bios direkt erre elkülönít egy részt? Alaplapi fw-k mikor jönnek rá? Ha el van különítve, akkor azt ugye már nem fogom tudni használni windowsban a sima programokkal?
[ Szerkesztve ]
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
Abu85
HÁZIGAZDA
Ha lenne rá idő, akkor eleve nem létezne maga a probléma, mert időközönként át lehetne menni a teljes allokáción és meghatározni, hogy mi kell belőle és mi nem. Amiért ezt nem teszik meg PC-n a fejlesztők az az, hogy egyáltalán nem ingyenes maga az ellenőrzés, illetve a törlés utáni defragmentació sem kézenfekvő. Egyszerűen, ha ezt megcsinálnák, akkor iszonyatos mertekben csökkenne a VRAM-igény, de lenne is az ellenőrzésekkor és a defragmentlciókor úgy jó negyed másodperces akadás. Tehát nem éri meg élni ezzel. A hardveres menedzsment ezeket on-the-fly csinálja mindenféle lassítás nélkül.
Egy mai modern memóriamenedzsment eleve olyan, hogy a program addig allokál új területet, ameddig van szabad memória. Ezen belül ma tipikusan bevett szokás a szabad kapacitás feléig a beállított mérettel dolgozni, majd utána kisebb felbontású textúrákat betölteni. Ezzel húzzák az időt, ugyanis így később telik be a VRAM. De ha betelik, akkor jön a törlés LRU alapon. Ilyenkor azért mindenképpen fájni fog a dolog, tehát a legtöbb alkalmazás úgy van kialakítva, hogy akkor töröljön egyszerre sokat, hogy a következő kritikus törlés minél később következzen be.
A hardveres on-the-fly tud menedzselni, tehát egyrészt jóval több memória áll rendelkezésre a potenciálisan szükséges adatok betöltésére, másrészt sosem következik be a kritikus törlés problémája, mert nem várja meg a rendszer, hogy elmenjen a programfuttatás a hatáig. Emiatt radikálisán megritkul a lag lehetősége.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
HSM
félisten
Igen, de adott esetben egy negyed másodperces tudatosan, célzottan a megfelelő helyre elhelyezett "Please wait" felirat még mindig számomra ezerszer jobb alternatívának tűnik, mint a folyamatos lagtengerben úszás új részeknél...
A GTA4 jut erről eszembe, az is csinált a városrészek között egy ilyen negyed másodperces lagot, teljesen élhető volt vele a játék.
Én értem, hogy miért jó a cache működés, és miért előzi meg a fragmentációt és az azzal kapcsoaltos pluszmunkát/lagot/pazarlást, én csak azt mondom, hogy amennyire én látom, ennek nagy ára van/lesz lag-terén.
[ Szerkesztve ]
-
#45185024
törölt tag
válasz Jack@l #26510 üzenetére
Na figyeljetek videjások mutatok nektek egy AMD működő jós technologit:
RYZEN:
"Fejlődik az elágazás-becslő részleg is, amit ezúttal nem egyszerű „Branch Prediction” névvel emleget az AMD, hanem a "Neural Net Prediction System” elnevezést használja, ezzel utalva arra, hogy nem csak hatékonyabban működik az új rendszer, de bizonyos mértékű tanulásra is képes. Az elágazás-becslésre egyébként annyit tesz, hogy még a kód tényleges lefutása előtt megbecsüli a kimenetelét a műveletnek, hogy már az utána lévő dolgokkal is tudjon foglalkozni. Hibás becslés esetén a munka kárba vész, ezért fontos, hogy viszonylag pontos legyen az elágazásbecslő."[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Ha lenne loading vagy please wait felirat, akkor az működne, de sajnos manapság nincs. Ennek az oka a játékból való kizökkentés elkerülése.
De pont az van, hogy a.hardveres megoldás a lagot fogja csökkenteni.
(#26514) Jack@l: A programnak eddig is joga volt azt írni a memóriába, amit akart, illetve ez igaz volt a grafikus kernel driverre is. A Vega esetében annyi történik, hogy az AMD-nek lesz egy meghajtója, ami odaadja az adatot a VGA-nak és a hardver onnan már mindent intéz automatikusan. Persze van legacy működés és kérhetnek ilyet is a fejlesztők DX12 és Vulkán alatt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Jack@l
veterán
válasz #45185024 #26517 üzenetére
Remélem a speakeren is kitolja néha az újratervezés szót
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
HSM
félisten
válasz #45185024 #26520 üzenetére
Végülis... Így elképzelhető, hogyha a "hardveres" megoldás egy okos szoftveres adatbank (tárolt adatelemzések+valószínűségszámítási eredmények az adott játékból) alapján kap szoftveres "súgást" a működéshez. De ez már ennél messzebb nem is állhatna az Abu által emlegetett cache szerű hardveres működéstől, mert akkor az egész lelke az előre elkészített szofvteres analízis a játékról.
[ Szerkesztve ]
-
nagyúr
válasz Jack@l #26510 üzenetére
csak a 80x86os uarchot tekintve is majdnem 30 éve jósolunk. többszintű hierarchiát használva a kristálygömb egész jól működik - 95%nál is magasabb a hit ratio.
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
janos666
nagyúr
Hmm. Ha szabad, akkor összefoglalnám konyhanyelven ezt a vitát.
- A "hardware" oldal érve, hogy csökken a CPU terhelés, illetve minimalizálódik az emberi (programozói) hiba (vagyis inkább lustaság és/vagy bénaság) lehetősége (és annak hatása), illetve egységesebbé, ezért valamelyest kiszámíthatóbbá, így bizonyos szempontból (talán) jobban méretezhetővé válik a rendszer.
- A "szoftveres" oldal érve, hogy a játékprogram pontosan látja, hogy a 'kamera' hol van (de még azt is, hogy pillanatnyilag merre néz és merre mozog, sőt milyen sebességgel és gyorsulással mozog...), és innen melyik irányba (és milyen sebességgel, illetve gyorsulással), milyen maximális távolságokig utazhat (sőt, ha részben korlátozott a lehetséges kameraszög, akkor még azt is, hogy merre fordulhat), így elvileg (ha akarja, illetve ha ez az egész művelet nem tűnik "drágább" feladatnak, mint amit potenciálisan megspórol ***), egész jól megsaccolhatja (nem abszolút bizonyossággal, de nagy valószínűséggel), hogy mely textúrákat lehet érdemes a leggyorsabban elérhető memóriában tartani / oda mozgatni annak érdekében, hogy minél kevesebb legyen a 'baki' ('placeholder' textúrák felbukkanása, majd szemünk előtti átvillanása részletgazdag képekké, vagy esetleg microlag, netán tüskeszerű' fps akadozás, stb).
Minderre viszont képtelen a hardware, mert annak alapvetően fogalma sincs a játékvilág bejárható és megtekinthető részeinek alakjáról, lehetőségeiről, pillanatnyi állapotáról, stb (3D-s térben repülünk véletlenszerűen, vagy 2.5D-ben "platformozunk", esetleg 2D labirintusban megyünk alapvetően A-ból B-be...?), hanem szó szerint a sötétben botorkál, csak azt látja, hogy épp mi szükséges a monitoron lévő kameraálláshoz (vagy maximum egy "kockát" tud a kamera köré képzelni? -> tud egyáltalán ilyet...? Nekem már ez is "félig szoftveres" megoldásnak tűnne, amihez lényegében kéne a játékprogram segítsége, nem beszélve az egész keretrendszerről, hogy ezt milyen formában és miként kommunikálják le egymással...).*** [...], amire most nem tudok "educated guess"-t sem tolni, csak felvetni a kérdést, hogy ilyen lehet-e (hogy ez túl drága), és akkor miért..., de "józan paraszt ésszel" nekem gyerekjátéknak tűnik maga a predikció (képzeljük el az egyik legegyszerűbb formáját: kivetítünk egy X surgarú gömböt a kamera köré, és amelyik textúra a gömbbe esik, azt a VRAM-ba szorgalmazzuk, ami nem, azt onnan kifelé --- ez pedig aztán építhető tovább egy pillanatnyi mozgásvektorral megszorzott, ["elnyújtott"] ellipszoiddá [persze némi "tompítással, nehogy egyszerre ki/be töltsünk 100x egyetlen textúrát], stb, kinek meddig van kedve finomítani az eljárást...), sőt bizonyos játékok talán más okokból is végeznek hasonló predikciókat (tippre lehet ilyesmikkel szűrni glicth-eken vagy hack-eken alapuló csalásokat, mikor valaki "lehetetlen" dolgot művel), csak a konkrét RAM management része a fekete folt számomra, amiről elhiszem, hogy probléma lehet ilyen elven felépíteni. De miért...? (Ez az, amiről tippem sem lehet, sőt talán a választ sem értem meg, ha kapok rá.)
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Yutani
nagyúr
válasz Jack@l #26504 üzenetére
Egyébként nem értem ezt a nagy hőzöngést. Amikor megérkezik a VEGA és azt látjuk, működik ez a hardveres memória menedzsment, akkor majd te és az NV-s barátaid elvonulhattok csendben sírdogálni. Ha nem fog működni és tele lesznek akadással a játékok a rossz koncepció és kivitelezés miatt, akkor majd én és a nem NV-s "barátaim" fogunk elvonulni csendben sírdogálni, hogy mi a f*szért álltunk ki már megint az AMD mellett.
#tarcsad
-
korcsi
veterán
Egy felvetés.
Azt tudjuk jelenleg, hogy működik a textúrák betöltése? Nem explicit API esetén a driver menedzseli a dolgot, szerintem nincs túl bonyolítva, ha kell valami beteszi a VRAM-ba. Explicit API esetén mi történik? Van előtöltés, vagy csak betöltjük a szükséges adatot a megfelelő LOD szinten és mindez nem okoz problémát?
Igazándiból mindenki a betöltéssel van elfoglalva amikor a törlés a probléma. Ha folyamatosan tudod tölteni a szükséges textúrákat akkor ez jelent problémát egyáltalán? A PCIe 16GB/s-et nyújt, biztos kevés ez a szükséges adatmennyiséghez (amiről szintén nem tudjuk, hogy mekkora)?Lehet pont ez a lényege a HBC-nek, nincs törlés probléma (a hardver gyalul ha van kedve) a töltögetés meg megy igény szerint.
Csak úgy felmerült bennem ez a dolog.
[ Szerkesztve ]
referencia 5700(XT) plexi ARGB-s blokk eladó!
-
HSM
félisten
válasz Yutani #26525 üzenetére
Engem elég sokszor megvádoltatok, hogy "piros szemüveges" vagyok, de nekem se jön be ez a koncepció az eddigi infók alapján. Na akkor most mi van?
(#26526) korcsi: Amennyire értem az a baj, amikor törölgetni kéne, mert lyukak maradnak, töredezik a memória. Ha cache-ként használják, és valójában egy virtuális címtér elemei vannak csak a fizikai gyorstárban (VRAM), akkor ott gond nélkül garázdálkodhat a hardver, rendezgethet, mert nem fognak összekutyulódni a címek, mert azok mindig a virtuális nagy területből lesznek, és az csak "gyorsítótárazva" lesznek a fizikai tárolóban. Maga a koncepció tök jó, csak valahogy ebbe még bele kellene vinni a programozói előre látás képességét, hogy ténylegesen mikor mire lenne szükség. Tehát a hardvernek és szoftvernek együtt kéne működnie az én véleményem szerint.
[ Szerkesztve ]
-
Yutani
nagyúr
Én sosem vádoltalak piros szemüveggel, nincs is bajom azzal, de azért mondjuk ki, minimum rózsaszín a szemüveged, ha nem is piros.
Ettől függetlenül persze nem kell, hogy minden tetsszen, amit az AMD csinál. Nekem nincs bajom a koncepcióval, bár nem is értek hozzá, de el tudom képzelni, hogy jól működhet, ha jól körbejárták a mérnökök a problémát és jó megoldást találtak rá.
(#26531) smc: Jó kérdés. Csak a memória IC-k száma befolyásolja a fogyasztást, vagy a kapacitása is?
[ Szerkesztve ]
#tarcsad
-
TTomax
nagyúr
Részint igy van,meg ugye a memóravezérlö pont annyit eszik akkor is 4GB van rákötve ha 8 vagy 12.
★★★★★ I got too much soul, rhythm and blues R&B ya see, all that's cool, but hip-hop and rap yeah that's where my heart's at Even back when I used to break on a box ★★★★★ "Chief Rocka"
-
-
HSM
félisten
válasz szmörlock007 #26535 üzenetére
A mostani problémás megoldásokat is ugyanazok a "top mérnökök" dolgozták, amit majd most ki akarnak javítani. Hát... Majd hiszem ha látom.
Én a load-képernyőben és a pazarló módszerben hiszek.
-
Malibutomi
nagyúr
Kivettem a szemelyeskedo kommenteket.
-
#45185024
törölt tag
Szeressétek egymást emberek ne haterkedjetek !
Szerintetek Rudy nem tolta kicsit túl az AMD megjelenést a cikkében ? -
stratova
veterán
válasz #45185024 #26539 üzenetére
rudi
Szerintem nem, a két lapka között azért van egy olyan árnyalatnyi eltérés, hogy az új NV kártya egy már piacon lévő csúcskártya vágott verziója, míg AMD teljesen új terméket jelentet meg, amivel már régóta volt adós. Reméljük most valóban olyan ütős lesz, ahogy beharangozzák, mert a Ti ára szépen lekövette a konkurencia nélkül megjelent GTX 1080-1070-es portékák +200$-ral megemelt nyitóárát.
[ Szerkesztve ]
-
#45185024
törölt tag
-
Malibutomi
nagyúr
Ez a RADEON talalgatos nem az AMD talalgatos.
Procikat ne ide linkeljetek legyszives, hanem a processzoros topicokba.[ Szerkesztve ]
-
#45185024
törölt tag
Magyar idő szerint ,mikor lesz MA a kapszaicin nem tudjátok ?
[ Szerkesztve ]
Új hozzászólás Aktív témák
Hirdetés
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.
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen