Új hozzászólás Aktív témák
-
Pikari
veterán
,,A Tahiti cGPU további előnye, hogy kezeli a C++ programnyelvet''
fogalmazzátok át, még a végén valami gametpisti azt hiszi, hogy a gpu futtatja a .c fájlokat. Nem is csoda, hogy azt hiszi, hisz ezt írtátok, makes no sense.mellesleg szerintem ennek a koncepciónak dedikált kártyaként semmi értelme. cpuval összeépítve persze már lesz.
-
-
Z10N
veterán
Az meglehet, viszont elfelejted ami ra van irva a kartyara: ENGINEERING SAMPLE. Azaz betas. Attol, hogy vki az NDA megszegesevel kiszivarogtat vmit az meg nem hivatalos. Az OEM gyartok szamara lettek kikuldve, hogy ez alapjan fejlesszek es tervezzek az uj termekeket, ideertve az OC valtozatokat is, amihez pedig kell szufla. Az en 6850 Toxic kartyamon is 2x6P csatlakozo van, bar ugye azert mert 6870 pcb, ezert is birja diszno modon a tuningot. Ehez kell a 6+8P, hogy a gyartok varialhassanak. Nyilvan a referencia nyakok szolidabbak lesznek vmennyivel.
-
#101
Z10N
veterán
TESCO-Zsömle
#98
Z10N
veterán
válasz
TESCO-Zsömle
#98
üzenetére
Viszont igy ebay-n ki lehet fogni jo dogokat
De ez igy szokott lenni, masnap mar lehet kapni naluk mindent, viszont a fizetesukbol meg igysem futja, pedig ezek a gyari munkasok tobbet keresnek joval, ezert masbol kell megoldani abevetelt 
-
#100
aram01
nagyúr
TESCO-Zsömle
#98
aram01
nagyúr
válasz
TESCO-Zsömle
#98
üzenetére
élelmesek nem hiába ugrott ekkorát a gazdaság
-
#99
Youri
veterán
TESCO-Zsömle
#98
Youri
veterán
válasz
TESCO-Zsömle
#98
üzenetére
És mégis oda viszi boldog boldogtalan...
-
Z10N
veterán
válasz
Angel1981
#31
üzenetére
Az ES kartyak Kinaba keszulnek. Ott szerinted milyen mobilokat tudnak megfizetni, mert a kemfotok telefonnal keszulnek altalaba. Viszont ezek a fotok egy Olympus Stylus 820-szal keszultek. Amig nincsenek a kozelbe gephaz oldala le, egy-ket gyors kep es mintha misem tortent volna
. -
#95
Angel1981
veterán
Cybertrone
#93
Angel1981
veterán
válasz
Cybertrone
#93
üzenetére
Ahogy mondod!
-
-
#85
aram01
nagyúr
TESCO-Zsömle
#83
aram01
nagyúr
válasz
TESCO-Zsömle
#83
üzenetére
arra még várhatunk
-
#82
aram01
nagyúr
TESCO-Zsömle
#81
aram01
nagyúr
válasz
TESCO-Zsömle
#81
üzenetére
na tudtam hogy túl fogod komplikálni
-
#80
aram01
nagyúr
TESCO-Zsömle
#79
aram01
nagyúr
válasz
TESCO-Zsömle
#79
üzenetére
Én is így gondolom.
Milyen grafikont szeretnél?![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Angel1981
veterán
És DX9 vagy DX11?
Átlag FPS?
Demo anyag, vagy ténylegesen a futtatott játékból való?
Ha igen, abból melyik rész? (A Metro 2033 pl. nagyon széles FPS számmal mozog, pályától függően.)
Milyen a konfig, amibe be van téve kártya?
Bocs, de EZ a táblázat a "nesze semmi fogd meg jól" kategória - számomra semmi hitele nincs!
Persze nincs gond, előbb-utóbb csak körvonalazódik majd valami... -
#73
juzer78
tag
Cybertrone
#71
juzer78
tag
válasz
Cybertrone
#71
üzenetére
Várjuk-várjuk, január 6-án jön is elvileg!
-
#60
Abu85
HÁZIGAZDA
Meteorhead
#55
Abu85
HÁZIGAZDA
válasz
Meteorhead
#55
üzenetére
Beleírtam, hogy multiprecíziós, az AMD is így nevezi.
-
#59
Day 'n' Nite
tag
Meteorhead
#50
Day 'n' Nite
tag
válasz
Meteorhead
#50
üzenetére
Lassan az itt lévő hsz-eidből összerakhatnál egy cikket logout-ra.
-
#55
Meteorhead
aktív tag
Abu85
#53
Meteorhead
aktív tag
Ez persze rendben van. De mint OpenCL programozó, számomra megváltásként érkezik, hogy nem kell majd vért izzadva vektorizálni kódot, mert VLIW végrehajtók helyett skalár végrehajtók lesznek. Persze, a compiler megpróbál auto-vektorizálni adatfüggőség alapján, de vannak algoritmusok ahol borzasztó rossz eredményt ad. Ezért nagyon félrevezető a vektor jelleg, mert egy szál skalárműveletekkel operál.
-
vanhalen
senior tag
Írjon hozzá a linux 'közösség"
Kártyát ne tervezzék és gyártsák le az AMD helyett?Kártyát ne tervezzék és gyártsák le az AMD helyett?
Más "unix like" rendszereknél hogy lehet, hogy megoldott a Radeonok támogatása? Másoknak miért megy mégis úgy, hogy nem az AMD írja meg helyettük hm? -
#53
Abu85
HÁZIGAZDA
Meteorhead
#50
Abu85
HÁZIGAZDA
válasz
Meteorhead
#50
üzenetére
Nekem figyelembe kell venni, hogy nem biztos, hogy azt a hsz-t, amit most írtál megérti egy átlag olvasó. Én nem akarom ezt egy hírben annyira túlbonyolítani. Aki vágja a működést, az úgyis doksik szerint dolgozik, de egy olvasónak még a vektorfeldolgozó is sok, nemhogy a részletek.
Van egy nagyon részletes doksim a működésről. Az alapján nevezhető vektorfeldolgozónak az egység. Ki lehet persze egészíteni az elnevezést Multi-Precision vektorra, de nem kicsit kellene magyarázni ehhez. -
#52
Abu85
HÁZIGAZDA
Cybertrone
#49
Abu85
HÁZIGAZDA
válasz
Cybertrone
#49
üzenetére
Nem pont ezt akartam, hogy így jöjjön le, de akkor járjuk körbe a témát. A DirectX 11.1 tulajdonképpen ki fog elégíteni minden igényt. Annak én sem örülök, hogy visszakerülnek a VSC bitek, de szerencsére az MS úgy építette fel a rendszert, hogy továbbra is megmarad az úgymond kőbe véset rész. A fejlesztő eldöntheti, hogy akar-e VSC biteket használni. Nyilván azt kell mérlegelni, hogy az adott motor a VSC bitekkel elérhető extrák mellett javulna-e. Ha nem, akkor természetesen megtartható a DX10-ben bevezetett erőforrás-ellenőrzés, így továbbra is egyszer kell érvényesíteni a hardvert, méghozzá a program indításának elején.
A VSC bitek valószínűleg azért hozta vissza az MS, mert jönnek az ARM-os GPU-k, amelyek azért sokban különböznek a működésben, mint a nagyobb társaik. Egyszerűen annyira tág elképzelések között fog lavírozni a piac, hogy nem lehet egységesen ezt lefedni. Természetesen, ha használsz VSC biteket, akkor annak az az ára, hogy az erőforrás-ellenőrzés a DX9-es szintre süllyed, vagyis minden kiadott rajzolási parancs előtt meg kell kérdezni a hardvert, hogy egyáltalán támogatja-e. Ennek sokan nem örülnek, de tulajdonképpen jobb opció nincs. Vigasztalja a fejlesztőket, hogy nem kötelező ezeket használni, így gyakorlatilag megmarad valamennyire a hatékonyabb modell is.
Most ugye a DX11.1-nek lesznek kőbe véset követelményei, és ha azokat támogatja egy hardver, akkor az már DX11.1-es. A VSC biteket, mint például a PRT-t nem kötelező támogatni. Nem is várhatja el az MS, mert jelenleg csak az AMD képes rá. Ettől a DX11.1 elvesztené a szabványos formáját. Mondjuk úgy, hogy mindegyik DX11.1-es VGA DX11.1-es lesz, de némelyik kínál majd kihasználható extrákat VSC bitek formájában.
Most az értelmezés kérdése, hogy mennyire tekintjük butának azokat a VGA-kat, melyek teszem azt nem támogatják a PRT-t. Nyilván lehet annak tekinteni, de nem érdemes, mert olyan technikáról van szó, amit nem sok fejlesztés képes kezelni, ráadásul a szó szoros értelmében nem is szabványos, csak van rá lehetőség az adott API-n keresztül. Én inkább úgy fogalmaznék, hogy lesznek DX11.1-es kártyák extrákkal.Sok pletyka szál fel és alá.
Igen hallottam olyat, hogy az NV leállította a GK100-at, ami ugye ahhoz vezet, hogy egy lapka csak 2012 végén jöhet a csúcskategóriába, de ha nincs valami komoly baj a GK100-zal, akkor ezt talán nem érdemes meglépni. Az NV-nek szerződése van a Titan projektre, amibe Kepler kerül 2012 közepe felé. Lehetséges, hogy leállt a GK100 fejlesztése, de akkor azonnal adódik a kérdés, hogy mit raknak a Titánba. Ezért is írtam a korábbi cikkemben, hogy szerintem érdemes az eredeti pletykákra alapozni, vagyis, hogy jön a GK100 2012 közepén.
Technikai felépítést nem tudok, de a Kepler támogatni fogja az (ARM) virtuális memóriát, és képes lesz a magasabb prioritású szálak kezelésére. Előbbi hasonló lesz, mint amit az AMD támogat, csak nyilván AMD64 licenc nélkül inkább az ARM-ra épít az NV. Ettől függetlenül az IOMMU és a VT-d megoldást kínál az x86 virtuális memória elérésére is. Valszeg kidolgoznak majd ők is egy PRT-hez hasonló eljárást, csak nem PRT lesz a neve, és a Keplerhez illeszkedik. Nyilván ez is VSC bit lesz. -
#50
Meteorhead
aktív tag
Abu85
#40
Meteorhead
aktív tag
Tisztában vagyok vele, hogy VLIW nem teljesen vektorfeldolgozó (különbség annak aki nem tudná, vektorfeldolgozók ugyanazt az utasítást küldik le a sávok mentén, csak más adaton, míg VLIW (Very LongIntruction Word) egy utasításba pakol különböző műveleteket, amik egyszerre tudnak végrehajtódni a feldolgozón).
A SIMD kifejezéseket lehet használni, de talán az egyszerűség kedvéért érdemes félretenni őket. Amit mondasz, az majdnem igaz, de mégsem. Azért nem igaz a 4 db 512 bites vektorfeldolgozó, mert az igaz, hogy ugyanazon műveleteket hajtják végre más-más adaton, de elágazni vektor jelleggel nem lehet, ezek meg külön szálak, amik el tudnak ágazni egymástól. (if-else, és igen, azt is tudom hogyan korlátozódik ez GPUn)
Fermi végrehajtókban dedikált INT és FP skalárvégrehajtó van (amik akár egyszerre is dolgozhatnak), ezekből van 32 egy CU-ban, ennyi tud egyszerre futni, ezért 32 a warp-size.
Evergreen (VLIW5) esetében 16 darab 5 széles VLIW egység van, ahol 16 szál tud igazából egyszerre futni, de 64-nél kevesebbet nem tud kezelni egy CU, ezért ekkora a wavefront-size. Ezek a szálak képesek vektorműveletre, de a VLIW jelleg miatt ennél bonyolultabb dolgokat is tudnak csinálni.
Northern Islands (VLIW4) kiiktatja a speciális egységet, és a transzcendens műveleteket (MOD, SIN, COS, ...) három mezei végrehajtó összekapcsolásával érik el. Így mezei műveletekre nagyobb kapacitás marad.
Southern Islands sokkal jobban hasonlít Fermire, avval a különbséggel, hogy itt nincs dediktált INT és FP egység, hanem ugyanaz a végrehajtó végzi mindkettőt. Egy CU-ban most már nem 16 VLIW4 feldolgozó van, hanem 4 darab külön életet élő 16 utas SIMD. De ez azért több egy 64 utas SIMD-nél, mert a 4 fürt SIMD egység egy CU-n belül tényleges elágazást is végezhet egymástól, sőt akár halál más dolgot is számolhatnak. Az nincs megkötve, hogy ugyanazt a shadert (vagy kernelt) kell futtatniuk. A CU definíciójában csak az van, hogy közös memóriaterületet szolgáltat a benne lévő szálak számára Az nincs benne, hogy azoknak a szálaknak egy wavefront/war-ból kell hogy származzanak, sőt még az sem, hogy ugyanannak a kódnak kell lennie.
A hozzászólásod egyébként túlnyomó többségben igaz, nagyrészt csak kötekedem, de szerintem így talán tisztábban látni a különbségeket, mert vannak bőven.
-
#49
Cybertrone
veterán
Abu85
#47
Cybertrone
veterán
Miért hozzák vissza azt ami egyszer már problémás volt? Amúgy ha jól értem valószínű a high end kártyák fognak kiaknázni minden dx11.1-es ficsőrt, a többi az le lesz butítva, kb így kell érteni?
Nv oldalról mit tudsz, ők hogy próbálkoznak megoldani a keleti kérdéseket, számodtevő újítások lesznek? Mit gondolsz arról hogy a chip csak jövő év végén lesz kész, halottál esetleg valami problémáról, ami esetlegesen megosztható?
-
#48
Angel1981
veterán
TESCO-Zsömle
#42
Angel1981
veterán
válasz
TESCO-Zsömle
#42
üzenetére
Ok, köszi, ez új infó!
fulltime4wd: jó a meglátás, és a cáfolat, de tényleg!
-
#47
Abu85
HÁZIGAZDA
Cybertrone
#36
Abu85
HÁZIGAZDA
válasz
Cybertrone
#36
üzenetére
Valójában a DX11.1 sokkal problémásabb felület lesz. Visszahozza a Vendor Specific Caps bitek kezelését, amit ugye az MS a DX10 óta mellőz. Tekintve, hogy ez az architektúra mi lesz, nem csak a DX verziók között lesz különbség, hanem a DX11.1-es kártyák között is. A DX11.1 megkövetel számos extrát, amit gyakorlatilag nem túl nehéz beépíteni, vagyis ebből a szempontból az új felület nem fogja megváltani a világot. Vannak persze nagyon értékes újítások, mint például a nagyobb parancspuffer az SRV-k felülírásának tiltásával. Ebből lehet sebességet nyerni, de alapvetően a Vendor Specific Caps bitek visszahozása jelenti a ... hát ő ... az előrelépést. Persze ez nem kevés problémát fog okozni. Például a hírben szereplő PRT egy Vendor Specific Cap és csak a GCN architektúra fogja támogatni, amiből sejted, hogy mi következik. Megatextúrázásnál persze világmegváltó lesz.
-
#46
fulltime4wd
tag
Angel1981
#39
-
#44
fatallerror
addikt
Cybertrone
#36
fatallerror
addikt
válasz
Cybertrone
#36
üzenetére
de ha 2-3 évre veszem 1x csak elkezdik használni xD
-
#43
leviske
veterán
TESCO-Zsömle
#11
leviske
veterán
válasz
TESCO-Zsömle
#11
üzenetére
A Zambezi esetében sem jártak jól azzal, hogy több fronton léptek az ismeretlenbe. AZ XDR2-ről nemigazán olvastam olyat, ami miatt ne várhatna.
(#1) adorjant: Nem hiszem, hogy a HD2900 jó példa. Most -ha jól értem- ugyanazt a lépést teszik meg, mint az nVIDIA a Fermi-vel, annyi különbség mellett, hogy volt idejük rákészülni. A G80>R600, R600>Fermi teljesen más szemléleten alapult, ezért tudott az egyik az akkor aktuális környezetben elhúzni. Feltételezem, hogy most ilyen különbségek nem várhatók.
MÁS: A cikkben említett skálázhatóság annyit jelent, hogy van esély a hasonló felépítésű 800-as és 700-as szériára, vagy az már réges-rég eldöntetett, hogy maradnak a NI sorozattal bevezetett taktikánál?
-
#41
Abu85
HÁZIGAZDA
Cybertrone
#8
Abu85
HÁZIGAZDA
válasz
Cybertrone
#8
üzenetére
Nem is a képből szipkáztam ki.
Raktam be képeket az architektúráról.(#4) helkis: A HD 4000 óta nem alkalmaznak ringbust. Áttértek a HUB-os vezérlőre.
-
#40
Abu85
HÁZIGAZDA
Meteorhead
#14
Abu85
HÁZIGAZDA
válasz
Meteorhead
#14
üzenetére
A VLIW-ben sosem voltak vektorfeldolgozók. Szuperskalár shader processzorokból állt. A Caymannél négy azonos képességű skalár processzor, míg a VLIW5 típusnál négy azonos és egy speciális van. Ezek rendeződtek egy multiprocesszorba, amit a Cayman 64 utas simd tömbjénél 16 szuperskalár processzor volt. Tulajdonképpen most változott a felépítés, de a helyzet hasonló a helyzet. Egy CU alkot egy multiprocesszort, és ez 4 darab 512 bites vektorfeldolgozót ad. Ezzel ugye a feldolgozó 64 utasnak tekinthető. Emellett a CU-ban van még egy IU skalár feldolgozó is a széles vektorfeldolgozók mellett.
Tulajdonképpen a rendszer a Larrabee-re hasonlít. Persze számos különbség van, így talán ehhez sem érdemes hasonlítani.
A Fermiben a CUDA magok skalárfeldolgozók, de már van olyan dokumentumom, ami a további fejlesztéseket ecseteli. Ez pedig arról ír, hogy a skalár egységeket 128 bites vektorfeldolgozók váltják fel. Az IU valószínűleg megmarad skalár. -
-
#38
vanhalen
senior tag
Meteorhead
#34
vanhalen
senior tag
válasz
Meteorhead
#34
üzenetére
"Hát az AMD linuxos támogatásáról inkább ne is beszéljünk... én linuxra fejlesztek tudományos szimulációkat, hozzáértő embernek tartom magam, és valami botrány ami linux oldalon történik a driverekkel"
Írjon hozzá a linux 'közösség"
Egyébként ezt az arhitektúrát szerintem nem "gémer" szemmel kell(ene) nézni, hanem inkább úgy, mint a Teslát az nV-nél nem?
-
#37
wetomi
aktív tag
Meteorhead
#34
wetomi
aktív tag
válasz
Meteorhead
#34
üzenetére
Kernel szinten gondoltam, mert a win7-nél is itt van a gond ha jól értem.
Sajnos én is ismerem a linuxos driverek minőségét. (desktopon amd platform + opensuse, nekem szerencsére elég a nyílt driver)Nagy megváltás lehet majd az amd-nek a win8. Rendben lesz az ütemező a bulldozerhez, rendben lesz a hd7xxx támogatása oprendszer felől.
-
#36
Cybertrone
veterán
fatallerror
#35
Cybertrone
veterán
válasz
fatallerror
#35
üzenetére
Ami valljuk be felér egy dx10.1-es parasztvakítással
-
#35
fatallerror
addikt
fatallerror
addikt
tökjó, mire gépet veszek tudok majd naprakészet venni ami 2-3 évig megint elég lehet
külön örülök h akkor már dx 11.1-esek lesznek -
#34
Meteorhead
aktív tag
wetomi
#28
Meteorhead
aktív tag
Hát az AMD linuxos támogatásáról inkább ne is beszéljünk... én linuxra fejlesztek tudományos szimulációkat, hozzáértő embernek tartom magam, és valami botrány ami linux oldalon történik a driverekkel. (Most a Windows-os driverek is trágyák, de linuxra a feature-ök rendre később érkeznek. Számomra is rejtély hogy miért.)
AMDs fejlesztői fórumon egész komoly parasztlázadás tört ki, annyira xarok a driverek. Bugosak, helyenként hibás eredményeket adnak, szénné fagyna a gépek tőlük, van hogy bootolni sem képes linuxot... botrány.
-
Angel1981
veterán
Összeesküvés elméletnek tűnhet, de szerintem a kémfotók 90%-át maga a gyártó szivárogtatja ki, hogy növelje az érdeklődést.
És hogy miért gondolom így? Pont az általad említett dolog miatt!
Hogy lehet az, hogy már 30 ropiért tűrhető képet készítő, magas megapixelszámú fényképezőgépet kapni, de a kémfotók mégis homályosak, alacsony felbontásúak, gyenge minőségűek? -
wetomi
aktív tag
"...Természetesen ehhez az operációs rendszer szintjén is komoly támogatás szükséges, így a Windows 7 alatt az új architektúra félkarú óriás lesz, rengeteg kihasználhatatlan extrával."
Végülis ha a Fermihez hasonlóan szerverbe készül, akkor mi itt a gond? Úgyse Win7-en fognak számolni, hanem linuxon. Ebből a szempontból mi a helyzet linuxon? Ott azért hamarabb várható támogatás, nem?
-
#21
Angel1981
veterán
TESCO-Zsömle
#16
Angel1981
veterán
válasz
TESCO-Zsömle
#16
üzenetére
A Kaveri a Trinity utódja?
-
#20
Psychopeti
senior tag
Psychopeti
senior tag
Érdekes hogy korábban az R600-as GPU esetében amely a Radeon HD 2900-as sorozat kártyáin teljesített szolgálatot 512-bit
széles GDDR4-es adatsínt alkalmazott a gyártó.Nem semmi ugye
Az egy 850-es TX PRO Tápegység lenne ha jól látom
-
#19
aram01
nagyúr
TESCO-Zsömle
#16
aram01
nagyúr
válasz
TESCO-Zsömle
#16
üzenetére
szerintem inkább 2012 q3-q4 lesz belőle mert az nv biztos durrantani akar majd jövő karácsonyra ezért a red fiúknak is bele kell majd húzni,érdekes év lesz ez a 2012.
Angel1981: ennyi
-
#17
Angel1981
veterán
TESCO-Zsömle
#11
Angel1981
veterán
válasz
TESCO-Zsömle
#11
üzenetére
Biztos megvan az oka, hogy a mérnökök végül nem azt választották.
Valószínűleg ha már tényleg minden kifacsartak a GDDR5-ből, akkor váltanak. -
#16
TESCO-Zsömle
titán
aram01
#13
TESCO-Zsömle
titán
Háát... Végül is... Ha jól olvasom, akkor 2013-ig úgyse lesz értelme ilyet venni...
Ugye 2012 vége felé jön a Win8, aztán még legalább fél-egy év, mire tényleg lesznek is cuccok, amik legalább részben kihasználják az új lehetőségeket, ha egyáltalán lesznek...
Arról nem is beszélve, hogy 2013-ban jön a Kaveri... Bull3.0+GCN(2.0?!?)...
Bár már a Trinity-re is nagyon kíváncsi lennék, hogy muzsikál játékok alatt a Bull2.0+VLIW.
-
#15
shteer
titán
fulltime4wd
#2
shteer
titán
válasz
fulltime4wd
#2
üzenetére
hogy jobb kémfotókat lehessen készíteni róla
-
#14
Meteorhead
aktív tag
Meteorhead
aktív tag
"Mindenesetre a hírek arról szólnak, hogy 32 darab CU, azaz Compute Unit lesz benne, ami a korábban használt számozás értelmében 2048 darab shader processzornak felel meg. Az AMD valószínűleg így fog majd a feldolgozók számára utalni, de valójában ez technikailag nem helyes, ugyanis egy CU-ban négy darab 512 bites vektorfeldolgozó található, vagyis nem beszélhetünk skalár egységekről a GCN architektúra esetében."
Olvasnak a fiúk neten?? GCN egyik legdurvább újítása, hogy lecserélik a shadereket skalár feldolgozóra! Eddig 4 széles vektor feldolgozók voltak, amiből volt 16 egy CUn. Ezek futtattak 64 szálat "egyszerre" (16+16+16+16 egymásután, mert regisztert 4 órajel elérni). GCN-ben felbontották a vektor végrehajtót, és négy wavefront fut egyszerre. Ez annak felel meg, mintha régi architektúrán négy szálat küldenénk a feldolgozón keresztül, egyet-egyet minden vektor sávon. De ez nem vektorfeldolgozó!!! 40 program counter van egy CU-n, ami 40 paralell futó wavefrontot enged (2560 szál!) amiből 256 aktív egy adott pillanatban. Minden shader külön azonosítóval rendelkező shadert futtat. Ezt azért csinálták, mert GPGPU-ra alkalmasabbak a skalár feldolgozók, így ebben a tekintetben jobban fog hasonlítani Fermire.
Szóval én ezt kijavítanám a cikkben, mert ez egy durva hiba.
Amúgy a többi újítás (amik igazából sokkal nagyobbak) szintén nagyon tuti és nagyon felkavarják végre az állóvizet ami a GPUs szolgáltatásokat illeti. Itt tényleg komoly integráció fog végbemenni a köv 2-3 évben.
-
#13
aram01
nagyúr
TESCO-Zsömle
#11
aram01
nagyúr
válasz
TESCO-Zsömle
#11
üzenetére
azt majd a következő sorozatra májusban,ne légy mohó
-
#12
helkis
veterán
Cybertrone
#8
helkis
veterán
válasz
Cybertrone
#8
üzenetére
persze ha nem ringbus alapú lesz, akkor nem szóltam, csak miért dobnák ki teljesen ami már bevált?
-
#7
Angel1981
veterán
fulltime4wd
#2
Angel1981
veterán
válasz
fulltime4wd
#2
üzenetére
Ez mérnöki tesztpéldány, nem számít a külső!
-
#2
fulltime4wd
tag
fulltime4wd
tag
Miért ilyen "napkiszívta" nyákot választottak....
De ez igy szokott lenni, masnap mar lehet kapni naluk mindent, viszont a fizetesukbol meg igysem futja, pedig ezek a gyari munkasok tobbet keresnek joval, ezert masbol kell megoldani abevetelt 
abu már egy hsz végén említette, viszont akkor azt nem értem hogy miért csak most próbálnak meg így sávszélességet növelni? 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Menő retró konfig: Q9550, Gigabyte P43, 4GB RAM, ASUS GT730,
- LG 34WQ75X-B - 34" Ívelt IPS Panel - 3440x1440 2K QHD - 60Hz 5ms - FreeSync - USB Type-C 90W
- Prémium PC házak akár 20-40% kedvezménnyel eladók garanciával, számlával!
- Bomba ár HP Pro X360 11 G1 - Intel N4200 I 4GB I 128GB SSD I 11,6" HD Touch I Cam I W10 I Gari
- T Phone Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest