Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Mi a probléma a Fusionös cikkekkel? Konkrét tények vannak benne. Vagy meg kellene várnom az Intel és az NVIDIA heterogén módon programozható lapkáját? Majd ha egyszer ők is előjönnek egy ilyennel, akkor ők is kapnak buksisimogatást.
Az NVIDIA dolga azon dolgozni, hogy a saját termékükön is jól fusson majd a kód. Az AMD oldaláról eddig nem érkezett olyan hír, hogy konkrétan kizárták volna egy program fejlesztéséből az NVIDIA csapatát. Fordított esetben nem egy példát lehetne mondani.
-
lenox
veterán
Mar mmx ota van sad, en mondjuk sse2-ben hasznaltam eloszor, de az sem ma volt, szoval kb. tudom, hogy mire jo. Azt kell latni, hogy a h264 encoding nem arrol szol, hogy milyen gyors a sad utasitas. Eloszor is maga a motion estimation az idonek csak egy reszet foglalja el, masodszor pedig a konkret sad szamolas ideje minimalis ahhoz kepest, hogy mennyit kell a kulonbozo memoriak eleresere varni. Ugyhogy maga a sad utasitas meglete minimalisat nyom a latban, mar csak azert is, mert nem ez az egyetlen felhasznalasa a gpunak. De egyebkent az encoding tesztekben nem azt lehet latni, hogy erosebb kartyaknal sosem a gpu processing a bottleneck, hanem a cpu vagy valamilyen memoriaeleres sebessege?
Hogyan befolyásolja a cikkeket? Mutass példát?
Szerintem az osszes Fusion-os cikk jo pelda.
...AMD külön fizetett a konkurencia kizárásáért.
Te valamit felreertettel. Nem volt szo kizarasrol, arrol volt szo, hogy lehet olyan kodot irni, ami amd hardwaren fut jol es nvidian nem, vagy forditva. En spec. tudok. Errol akkor erdemes vitatkozni, ha te is tudsz...
-
dezz
nagyúr
"Pl. a két modulos Bulldozert, akárhogyis nézzük, a négymagos CPU-kkal fogják megversenyeztetni"
Az nem olyan biztos: [link]
"Az a=b*c - a=a+e ennek speciális (bár igen gyakori) esete."
Amiből lenne ugye:
a=b*c; a=b*c+e
Nem értem, mi szükség lenne külön a bal oldali szorzásra. Sőt, mivel az eredmény eleve elvész, egyátalán nincs rá szükség!"a fúziónak software-esen teljesen transzparensnek kell lennie, ezért fontos a retirement"
Az első nyilvánvaló, de nem értem, ehhez mi köze a retirementnek?
"és az ott megvalósított kivételkezelés. Abban ez esetben, ha pl. b vagy c egy NaN, akkor nem válthatod ki a kivételt a nem is létező a=b*c+e utasításra; ugyanígy ha pl. c memóriaparaméter és érvénytelen területre mutat."
1., Ezek alapján sosem lehetne fúziónálni, vagy mégis?
2., Hogy-hogy nincs? Ez nem egy 4-operandusos FMA? -
P.H.
senior tag
"adott sziilíciumra vetítve - 1 FPU = 2x annyi számítás"
Ez lenne a lényeg. Pl. a két modulos Bulldozert, akárhogyis nézzük, a négymagos CPU-kkal fogják megversenyeztetni - és erre az AMD is rápakol egy lapáttal, hogy négymagosnak hívja -, tehát 2 FPU-val kell legalább azt a teljesítményt hoznia, amit egy K10 néggyel tudott. Ez a gyakorlati része.
Az elméleti, hogy mivel az FPU-ban eddig se voltak single-cycle utasítások (K10 esetén 2 órajelesek a legrövidebb lefutású, pl. MMX utasítások, de 3-4 a jellemző), ezért a függőségekből adódóan annyi "hole" volt/van benne, amelyet könnyedén kitölthet 2 szál is. Ehhez hozzávéve azt, hogy a K10 ütemezőben található gyerekbetegségeket is eltávolítják, esélyessé teszi azt, hogy összevetve a K10-zel, feleannyi FPU ugyanazt a teljesítményt nyújtsa. Minden más további módosítás (pl. 2 FADD/FMUL egység, a tárgyalt fúzió) csak pozitív irányba növeli a különbséget."A második felét nem egészen értem, mindenesetre én arra gondoltam, hogy a felesleges FMUL már a dispatcht se hagyná el. Ehhez ott legalább egy pár utasítás hosszon meg kellene nézni, hogy az eredményt tároló regiszter tartalma elvész-e. Ha igen, akkor eleve elhagyható."
Ebben igazad van. Ami miatt ez szvsz nem kivitelezhető:
- az általános eset az a=b*c - d=a+e lenne. Ezesetben is működőképest a leírt fúzió, csak ehhez mindenféleképpen FMA4 kell. Az a=b*c - a=a+e ennek speciális (bár igen gyakori) esete. Legegyszerűbb egyfélét, az általánosat megvalósítani (ezt sem egyszerű), ekkor viszont igenis kell a szorzás eredménye is
- a fúziónak software-esen teljesen transzparensnek kell lennie, ezért fontos a retirement és az ott megvalósított kivételkezelés. Abban ez esetben, ha pl. b vagy c egy NaN, akkor nem válthatod ki a kivételt a nem is létező a=b*c+e utasításra; ugyanígy ha pl. c memóriaparaméter és érvénytelen területre mutat.Valamiért nem egyedi ph-s jelenség, hogy az Intel-topikok elmennek más irányba: végigolvastam az RWT-s Sandy Bridge cikk topikját, de ott szó Bulldozerról, Atomról, GPGPU-ról, Larrabee-ről, hogy miért nincs soros port a laptopokon, miért nincs D-SUB a laptopokon, mikor fog kihalni a PCI busz...; a Bulldozeres megmaradt majdnem teljesen a témájánál
-
Abu85
HÁZIGAZDA
Azért nem mindegy, hogy a Sum of Absolute Differences, ami sokszor használt multimédiás alkalmazásoknál, hogyan van futtatva. A DX11-es Radeonokban külön SAD utasítás van erre, amit az ALU-k támogatnak. Ez része a media ops kiterjesztésnek. Ez valamivel többet nyom latban a minimálisnál.
Hogyan befolyásolja a cikkeket? Mutass példát?
Azért ne keverjük az AMD-t az NVIDIA-val. Olyan még nem volt, hogy az AMD külön fizetett a konkurencia kizárásáért. Majd ha lesz ilyen, akkor beszélhetünk arról, hogy milyen módszerekkel kovácsol magának előnyt az AMD. Egyelőre a fejlesztői programok arról szólnak, hogy a szoftverek jól fussanak az AMD-s rendszeren, aztán majd az NV és az Intel intézi a saját hardvereihez az optimalizálást.
-
lenox
veterán
A logikus következtetés, hogy az OpenCL-t csak az AMD és az Apple tolja.
Ok, akkor ezt felreertettem.
Abban ne bízz, hogy az AMD pusztán jó szándékból megkegyelmez a konkurenseknek...
Miert biznek? De szerintem a media ops minimalisat nyom a latban. De pl. a peak performance, meg hogy egyre jobban ki is lehet hasznalni, az joval tobbet.
Az engem nem érdekel, hogy mit érzel az AMD-vel szemben
Engem sem az erdekel, hogy te mit erzel, csak az, hogy ez hogyan befolyasolja a cikkeket. Marmint kulonosebben nem zavar, csak nem tartom helyesnek. Nyilvan tobb ezer velemenyt hallasz, hat ez egy kozuluk.
Ha a media ops kiterjesztés előny, akkor az AMD alkalmazni fogja a fejlesztésekben
Biztos igy lesz, es valami minimalis elonnyel fog is jarni, gondolom. De szerintem ez keves lenne, ehhez kepest a nem gyarto specifikus kod is ugy lesz megirva (mindig ugy szokott), hogy a sajat platformon jol fusson, mas platformon meg rosszul. Mindenki mas is igy probal tenni.
én csak az álláspontoddal nem értek egyet.
Vegul is azt nem tudom, hogy most konkretan mivel nem ertesz egyet. Azzal, hogy nem csak a media ops-bol fognak elonyt kovacsolni maguknak az altaluk penzelt fejlesztesekben?
-
dezz
nagyúr
"Én ezt az 1 FADD+1 FMUL helyetti 2 FADD/FMUL-t saccolom ~1.3 gyorsulásra, jelenlegi kódok esetén."
Ez vili.
"2 szál esetén ugye nincs dependencia, ha ugyanarra az FPU-egységre küldöd a számításokat (adott sziilíciumra vetítve - 1 FPU = 2x annyi számítás)"
Ez viszont továbbra sem. Szálon belül ugye hiába van fúzió (nem eleve FMA4-es kódról beszélve), az adott esetben felesleges külön FMUL is végrehajtandó, a másik FMAC-on. Sima FMUL-ok és FADD-okból persze mehet az egyik szál az egyik, másik a másik FMAC-ra. Azonban, eddig magonként volt egy FADD és egy FMUL egység. Így lényegében nem lenne gyorsulás, sőt inkább lassulás, az independent részeknél.
Kivéve ha... Először arra gondoltam, hogy egy FMAC csak vagy egy FADD, vagy egy FMUL, vagy egy FMA-t tudhat egyszerre, de megnézve ezt, végülis nincs kizárva, hogy úgy is viselkedhet(nek), mint a korábbi független FADD és FMUL egységek. Más szóval, tudhat 1-1 független FADD-ot és FMUL-t. Esetleg még az is lehet, hogy a szálak között is feloszthatók. De hogy ebből most mennyi gyorsulás következne...
"Bonyolíthatod a retirement-et (úgy, hogy pl. egy bejövő utasításnak ne is legyen kimeneti megfelelője a CPU-ból sem)"
A második felét nem egészen értem, mindenesetre én arra gondoltam, hogy a felesleges FMUL már a dispatcht se hagyná el. Ehhez ott legalább egy pár utasítás hosszon meg kellene nézni, hogy az eredményt tároló regiszter tartalma elvész-e. Ha igen, akkor eleve elhagyható.
ps. ezzel viszont lehet, hogy jobb lenne átmenni a Bulldozer topikba.
-
P.H.
senior tag
Kiegészítettem 1 szálra:
"Elvileg ugye most is egyidőben történhet egy FADD és egy FMUL -- feltéve, hogy nincs dependencia." Különben megvárják egymást a függő utasítások. Én ezt az 1 FADD+1 FMUL helyetti 2 FADD/FMUL-t saccolom ~1.3 gyorsulásra, jelenlegi kódok esetén.2 szál esetén ugye nincs dependencia, ha ugyanarra az FPU-egységre küldöd a számításokat (adott sziilíciumra vetítve - 1 FPU = 2x annyi számítás), nem keverve az integer utasításokkal, ugyanarra a portra küldve.
"Hát hogy az a szorzás az FMA-nál is megvan.
Bonyolíthatod a retirement-et (úgy, hogy pl. egy bejövő utasításnak ne is legyen kimeneti megfelelője a CPU-ból sem), de ez vezet valami jóra a jelenlegi CPU-kban, tényleg alapvető átalakítások nélkül? -
P.H.
senior tag
"Csak azt kérdezem, hogy az FMA használata csak dependens esetben jelent jelentős gyorsulást?"
Megértettem, mire kérdeztél rá . Igen, az az FMA-alkamazás, amt leírtam és linkeltem, csak dependens esetben jelent gyorsulást. Minden már FPU-terhelés elhanyagolható lassulást okozna. Integer esetben sem tapasztalható lassulás. -
dezz
nagyúr
Elvileg ugye most is egyidőben történhet egy FADD és egy FMUL -- feltéve, hogy nincs dependencia. Az FMA-nál pedig akkor is, ha van. Így csak dependens részeknél van/lenne gyorsulás. Ha jól látom, te is ezért teszed ezt ~1.3x-ra.
"és kb. 2x-es 2 szálas) gyorsulás."
Ez miért is?
"Hogy lehetne kihagyni?"
Hát hogy az a szorzás az FMA-nál is megvan.
Santiagain: Az nem kommunizmus, hanem fogyasztóvédelem.
-
P.H.
senior tag
"Csak azt kérdezem, hogy az FMA használata csak dependens esetben jelent jelentős gyorsulást?"
Mire gondolsz, nem értem még most sem. Eddig adott volt egy 128 bites FADD és egy 128 bites FMUL egység; most kettő 128 bites FADD+FMUL-képes egység, egyértelmű, hogy 128 bites esetben lesz megfelelő (kb. 1.3x-ra saccoható egyszálas és kb. 2x-es 2 szálas) gyorsulás.
Az nem elhanyagolható, hogy 2 L1D-cache és 2 szál lesz, de ez a (bármely) SMT lényege: 2x gyakrabban van olyan utasítás, ami nem függ az előzőtől, ennek kiszolgálása az alatta levő dedikált egységek dolga. Amely utasítások eleve 1 órajel alatt futnának le, azok hátrányban vannak (megnő a késleltetésük, a órajelról elméletileg sokszorosra), amelyek több órajel alatt, azok előnyt kovácsolnak ebből.
A CMT annyiban tesz emellé lehetőségeket, hogy az eredetileg 1 órajeles: integer utasítások valóban 1 órajel alatt futnak le; a többet igénylők meg 4 helyett pl. 5-6 alatt (ütemezők fő elve: a legkorábban beérkezett utasítások a lehető leghamarabb fussanak le)."átírtam a kérdést." erre?
"ha azt az FMUL-t az FMA mellett teljesen ki is lehetne hagyni (amihez persze ellenőrízni kellene, hogy később felhasználásra kerül-e a C, de ez nem egyszerű), és a másik FMAC-on inkább már egy következő, independent művelet mehetne."Hogy lehetne kihagyni?
-
dezz
nagyúr
Értettem azt a részt. Csak azt kérdezem, hogy az FMA használata csak dependens esetben jelent jelentős gyorsulást?
Emellett eredetileg az FMA melletti FMUL értelmére kérdeztem rá, aztán rájöttem, hogy az ottani (rész)eredményt végülis valamely következő műveletben is felhasználhatják, így átírtam a kérdést.
Kár, hogy nem folytatódott ott az a sub-thread...
-
P.H.
senior tag
Amit linkeltem, arra célzott, hogy ha egy microarch x idő alatt hajtja végre az
a=b*c
és y idő alatt az
a=a+d
függő utasításokat, akkor ha ezek egymást követik (?nem tudható, mikor), akkor ez lefordulhat:
a=b*c
a=(b*c)+d
alakra, függőségek nélkül, eredményben ugyanaz, időben fele, ha az FMUL mondjuk 6 órajel, az FADD is 6 órajel és az FMA is 6-7 órajel.Ehhez kell, hogy az a=b*c+d számítást felismerje a decoder a fenti képletből egymást követő(vagy távolabbi?) utasítások esetén, vagy legkésőbb az FPU-ütemező. Ez akkora befektetés (és módosítás a meglevő megoldásokhoz képest), ami nem valószínű az első Bulldozerben. SZVSZ.
-
dezz
nagyúr
Olvastam, de lenox #120-as megjegyzése után két külön esetnek vettem a kódfúzióból eredő és az FPU kialakításból eredő lehetséges gyorsulásokat, az elsőt kisebbnek tekintve 2-nél.
Szóval, SB-nél is mehet egy FADD és FMUL egyidőben, és az FMA előnye csak az (throughput szempontból), hogy ott dependent esetben is?
Ez nem akkor lenne az igazi, ha azt az FMUL-t az FMA mellett teljesen ki is lehetne hagyni (amihez persze ellenőrízni kellene, hogy később felhasználásra kerül-e a C, de ez nem egyszerű), és a másik FMAC-on inkább már egy következő, independent művelet mehetne?
Attól tartok, mindkettőre lehet úgy optimalizálni (a fordítónak), hogy az a másikon ne fusson jól, és ezt elsősorban az Intel tudja majd kihasználni (neki van saját fordítója)...
ps. szerintem ez nem annyira off.
-
P.H.
senior tag
Ja, te az MUL+ADD->MADD fúzióra gondolsz?
Egen, a csendes megjegyzésembeli lnkem a MUL + ADD = FMUL + FMA egyidejűségére vonatkozott."Bár arról se feledkezzünk meg, hogy az SB-nél magonként van 1-1 256-bites FMUL+FADD (amiknél SSE kódnál csak az alsó 128 bit aktív), itt viszont modulonként 2 FMAC."
Ami addig nem előny, amíg nincsenek AVX-alkalmazások, azaz ma. Az AVX (szerintem) kb. olyan erős lesz, mint az SSE2, az biztos, hogy előbb-utóbb mindenki alkalmazni fogja: az Intel szerint akár már most jelentős, ahogy megjelent, az AMD szerint majd később, most elég a megfelelő megközelítéssel kezelni (2x 128 bites végrehajtás mellett)
Meglátjuk, mi lesz a jó megközelítés, -
dezz
nagyúr
De azért azt nem lehet mondani, hogy akár az Intel, akár az Nvidia ellenérdekelt lenne az OpenCL-ben. Az Intel számára elég kényelmetlen a CUDA feltörése, így hát akkor is az "ellenpólust" támogatja, ha ő egyelőre ezt csak CPU-val tudja kiszolgálni. De hát ugye a jövőre is kell gondolni. A Nvidia számára pedig kockázatos lenne csak egy vasat tartani a tűzbe. Valószínű tisztában vannak vele, hogy a CUDA uralma a GPU alapú HTC-ben eléggé kétesélyes.
Egyébként korábban próbáltam innen a N-Body Physics Simulationt (amivel korábban reklámozták magukat), és teljesen jól futott HD5750-en. Meg a Particle Collision Simulation is. Igaz, voltak olyanok is, amik el sem indultak, hanem kiléptek hibaüzenettel. Érdekes lenne a jövőben az OpenCL-t is bevenni a tesztelésbe...
(#120) lenox: Nvidiás órajelekből indultam ki, mert mostanában ott jellemző a skaláris-szerű végrehajtás.
(#126) P.H.: Ja, te az MUL+ADD->MADD fúzióra gondolsz? Én arra, hogy két bármilyen egymásutáni, persze nem függű 128 bites SSE műveletet egyszerre végezhet el a két FMAC.
Bár arról se feledkezzünk meg, hogy az SB-nél magonként van 1-1 256-bites FMUL+FADD (amiknél SSE kódnál csak az alsó 128 bit aktív), itt viszont modulonként 2 FMAC.
-
P.H.
senior tag
"A közös FP ütemezővel ez nagyon nincs kizárva, és sokan úgy gondolják, már most jön."
A közös FP ütemező magában kevés (nem is kell "közös"nek lennie mondjuk).
Ami ehhez kell:
- a lehető legnagyobb előny kihasználásához legalább 2 FADD+FMUL képességű egység (eddig minden x86 microarchitekúrában 1-1 FADD és FMUL van/volt), ez Bulldozer-ben lesz, pipa
- a lehető legnagyobb előny kihasználásához 4-operandusú belső műveletek (micro-opok) lehetősége; 3-operandusú is elég lehetne, de megbonyolítja a register-átnevezést (az Intel microop-jai eddig 2 bemeneti és egy kimeneti értéket támogattak, Pentium Pro óta; ezért is szenvedős ADC/SBB vagy CMOVcc utasításokat használni rajtuk; ezen az AVX miatt az Intel is változtatott a Sandy Bridge-dzel; az AMD integer oldalon 3 bemenetit támogat K7 óta; FMA4-hez pedig FPU-oldalon is 3 bemenet + 1 kimenet kell), Bulldozer-ben lesz, pipa
- de a legfontosabb: olyan decoder (vagy FPU-ütemező), amely a paraméterek vizsgálatával képes az eredeti utasítástól gyökeresen eltérő micro-opokat generálni (vagy ütemező szinten konvertálni), nem befolyásolva a retirement-et. Ilyen még nem volt az x86-világban, az Intel macro-op fusionje a paraméterek ismerete nélkül konvertál át 2 egymást követő utasítást eggyé, amelynek így közösen összesen 2 bemeneti és 1 "kimeneti (IP)" értékük van (pl. compare value1,value2; jump if condition).
Az elv ugyan nem új, de túl nagy ugrás lenne ennyi mindent összedolgozni egy új termékbe, ilyen feszített tempó mellett SZVSZ. -
Abu85
HÁZIGAZDA
A logikus következtetés, hogy az OpenCL-t csak az AMD és az Apple tolja. Az Intel ellene van, mert le van maradva itt mint a borravaló. Az NV-nek pedig csak a CUDA számít, az Apple ahol lehet mellőzi is őket ezért.
Abban ne bízz, hogy az AMD pusztán jó szándékból megkegyelmez a konkurenseknek, és nem használják ki a saját kiterjesztéseiket a Fusion Fund mellett készülő programok esetében.
Az engem nem érdekel, hogy mit érzel az AMD-vel szemben, ez a te dolgod, én csak az álláspontoddal nem értek egyet. Ha a media ops kiterjesztés előny, akkor az AMD alkalmazni fogja a fejlesztésekben. Mivel nincs más cég, aki érdekelt az OpenCL terjedésében, az AMD megteheti, hogy a pénzelt szoftvereket a saját igényeire szabja. Nyilván nem fogják az Intel és az NVIDIA helyett elvégezni a munkát, ez nem az ő dolguk. -
lenox
veterán
Miért kellene ahhoz az AMD-t nyomni, hogy a logikus következtetést levond?
Marmint mi a logikus kovetkeztetes, hogy a media ops fontosabb, mint a printf? Ha transzkodolni akarsz kesz szoftverrel, ami csak amd-re van, es csak media ops extensionnel megy, akkor ez igaz lehet, egyebkent mar nem biztos, es szerintem te sem az elso csoportba tartozol, ugyhogy ha ez logikus szerinted, mar mondtam miert van (szerintem). De en meg biztos amd ellendrukker vagyok. De valojaban meg szerintem mezei usernek mindketto mindegy. A transzkodolas minosege mar nem, de ez nem attol lesz jobb vagy rosszabb, hogy van-e media ops ext, hanem a kod tobbi reszetol.
A CUDA csinál low end minőségű tömörítést
Szerintem ahogy irtam is, az nvidia csinal, nem a cuda, de pl. van mainconceptes cuda sdk mar egy ideje, persze azt nem olcson adjak. Az opencl-es meg uj, azt meg nem probaltam, de altalaban nem a jol parhuzamosithato reszek szoktak a lassuak lenni gpu transzkodolasnal, hanem a tobbi, ugyhogy szerintem tul sokat nem szamit.
-
Abu85
HÁZIGAZDA
Miért kellene ahhoz az AMD-t nyomni, hogy a logikus következtetést levond? OpenCL terjedésében van más cég, aki érdekelt? Egyelőre az AMD az aki dolgozik az OpenCL terjesztésén, így teljesen logikus, hogy a saját kiterjesztéseiket és az azokra épülő algoritmusokat előszeretettel fogják ajánlani a partnereknek.
Én lennék a legboldogabb, ha az OpenCL a játékokra is betörne, de nagyon nem úgy néz ki. Egyelőre a DirectX 11 számottevő előnye, hogy a DirectCompute a platform része, és a fejlesztők nem akarnak az OpenCL-lel foglalkozni, amíg mindent meg tudnak oldani a DX11-es platformon belül. Ez érthető is, a jelenleg DirectCompute minden felmerülő igényt kielégít. Az OpenCL nem jelentene előnyt.
A CUDA csinál low end minőségű tömörítést, persze gyorsan dolgozik. A Stream már közel van az x86-os algoritmusok szintjéhez, de lassabb, mint a CUDA.
Itt vannak képek az Anadtech összehasonlításából:
Cuda: [link]
Stream: [link]
x86: [link]A Mainconcepttel kapcsolatban volt nemrég egy OpenCL-es bejelentés: [link]
-
lenox
veterán
A printf-et kapasbol tudtam, hogy valtozott, azert irtam. Te mindig az amd-t nyomod, azert van nalad az amd kiterjesztesen a hangsuly gondolom
, mert pl. lehetne a directx interopon is, amennyire en ertem legalabbis a ph-s olvasok inkabb jatszanak, ugyhogy talan nekik az lehetne fontosabb. Nekem spec egyelore egyik sem, ugyhogy nekem egyelore api szempontjabol jo mind a ketto, sebesseg szempontjabol meg vegyes az eredmeny, es ugyis kell mindkettot supportaljam, ugyhogy sok valasztas nincs.
Egyebkent ha megnezed a media ops extensiont, az csak egy par fuggveny, ugyhogy nem tul nehez barmilyen device-on supportalni, nyilvan az az erdekesebb, hogy milyen gyorsulast hozhat a hasznalata. Egyelore az amd es az nv is csak lowend minosegu tomoritest csinal (ez pl. egy tipikus felhasznalasa), es amennyire en ertem minosegben es sebessegben is veri oket az intel fele media sdk (es ezt se probaltam, mainconceptet hasznalok mar regen), ugyhogy en nem latom olyan nagy jelentoseget (es a gpu printf se volt tul hasznos), de nyilvan lehet mas a velemenyed, meg termek is lehet meg erre epitve, ami megvaltja a vilagot. -
lenox
veterán
Hat egy osszeadast meg egy szorzast tud egy orajel alatt. Ha nem is fma...
Az eddigi amd gpu-k peak performance-at amugy csak nehezen, meg bizonyos feladatoknal lehetett kihasznalni, az avx-szel meg meg semmi tapasztalatom nincs, ugyhogy eleg nehez osszehasonlitani, hogy ez jo-e barmire. Az biztos, hogy pl. az nv gpu-k eleg jol teljesitenek, pedig a peak performance joval kisebb, mint amd-nel, es ebbol megintcsak nem lehet levonni semmi kovetkeztetest az intel illetve amd cpu opencl performance-ra
. SSEx-et sokaig hasznaltam, az eleg jol mukodott, ez alapjan az avx is jol mukodhet, de ez meg mindig nem jelent semmit arra vonatkozoan, hogy opencl alatt hogy teljesitene.#115: szerintem inkabb 4, amd-nel eleg alacsony szokott lenni a gpu clock.
#118: persze, hogy lehetseges sajat platformra optimalizalni, vagy nem ez volt a kerdes?
De nyilvan minden gyartonak a sajat felelossege, hogy jo drivert irjon, de aztan hogy ki milyen kodot akar rajta futtatni...#119: ez mezei usernek nem sokat mond, meg pl. nvidianal azota mar van printf az tuti, szoval ez egy moving target. De kulonben en amugy se ilyen optimalizalasra gondoltam, az extensionok nelkuli kodot is nyilvan lehet adott platformra optimalizalni.
-
Abu85
HÁZIGAZDA
Lehetséges specifikus optimalizálást csinálni. Az AMD GPU-i támogatnak SAD utasítást, ami a transzkódolásnál nagyon jól jön. Illetve van egy ocl AMD media operations kiterjesztés is, ami szintén használható a termékekhez. Mondjuk ettől a többiek nem szenvednek hátrányt, mert ez egyéni optimalizáció lenne.
Itt van az extra OCL kiterjesztések összehasonlítása:
-
dezz
nagyúr
Ja bocs, az magok száma és az órajel beszámításához túl álmos voltam.
"2 flop/cycle"
Ezt hogyan?
A Llanoban lévő IGP eleve többszörösét tudja a 96/192 GFLOPS-nak, és ugyancsak nem mindegy, hogy azt jóval alacsonyabb fogyasztással tudja!
(#108) Abu85: A Fusion Funddal kapcsolatban: [link]
-
LGLuke
őstag
Megy itt a vita az alaplap cseréről, közben sokkal nagyobb probléma is van:
Csak a H67-es lapok tudják kihasználni, illeve egyáltalán használni az IGP-t.
Ez rendben is van, viszont a H67-es lapokat nem lehet tuningra használni.
Az ember még ezt is benyeli, főleg, ha a stabilitás a fő szempont.Viszont csak a 2500K, valamint 2600K szorzózár mentes CPU-kban található 12db számolóegység.
A gyengébb CPU-kban csak 6db-os van. Ergo egy antituning alaplapba vegyél tuning CPU-t. hogy használhasd az IGP-t, és abból az erősebbet kapd.
Ez szerintem sokkal nagyobb probléma, mint amin itt folyik a vita! -
Srodney
senior tag
igen,igen meg az is kimaradt hogy ha már költeni kellene mint az állatt akkor adjanak hozzá jó fizetést is hogy közbe biztosításokat is tudjunk fizetni és megtakarításaink is lehessenek,mert vagy költesz vagy félrerakod itt keleten,nyugaton mindkettőre tellik...
mellesleg meg minden respect a PHközgaszdásznak!!!!! 
-
Abu85
HÁZIGAZDA
De be lehet. Az Intel valószínűleg mérlegeli is, hogy jól jönne-e ki abból, ha beépítenék. Azért nincs jelenleg beépítve a támogatás, mert nagyon lassú lenne a programok futása, ezzel a támogatás is értelmét veszti. A Sandy a Llano ellen megy, és a Llano IGP-je eleve 500 GFLOPS, és az OpenCL 1.1-re tervezett Evergreen alapjaira épül. Ezek alapján azt a kérdést is fel lehet tenni, hogy mennyi értelme van az OpenCL IGp-s támogatásának, ha a Sandy sebessége a töredéke lenne a tesztben a Llanohoz viszonyítva. Inkább érdemes bevállalni azt, hogy ez a funkció hiányzik és kész.
Az Intel SDK-ja már kezeli az 1.1-es OpenCL-t. Kipróbáltam a drivert a saját procimon, már ahol nem lépet ki a program hibaüzenettel. Gyorsnak persze nem mondanám. Az AMD driverével jobb a procim sebessége, és a programok is futnak. Persze a kettő összehasonlíthatatlan. Az Intel még csak most kezdte el fejleszteni az SDK-t, az AMD pedig már publik drivernél tart. Majd jövő ilyenkorra várható az Inteltől is a publikus driver. -
lenox
veterán
-
Abu85
HÁZIGAZDA
A Khronos Group egyik fejlesztőjét kérdeztem az OpenCL támogatásról. Ő mondta, hogy az 1.0 megoldható, de nagyon lassú lenne a rendszer teljesítménye. Olyan ez, mint a HD 4000 vagy a G80. Tudja az OpenCL 1.0-t, de lassú mindkettő, mert a számítási teljesítmény csak egy dolog, az OpenCL-hez igazított architektúra lényegesebb. A HD 5000 és a GT200 nagyon veri az elődöket OpenCL alatt, pedig a számítási teljesítmény alapján nincs akkora előny.
Először be kellene építeni az AVX támogatást az SDK-ba. Ennél is fontosabb, hogy az Intel is kidolgozzon egy OpenCL terjedését segító programot, mert a saját SDK-jával e nélkül nem megy semmire. A Fusion Fundban résztvevő fejlesztők helyett az AMD írja meg az OpenCL kódot, és természetesen a saját eszközeiket használják. -
lenox
veterán
Szerintem nem, sp-ben ugye 8 hosszu vektorok vannak, 4 core, nagysagrendileg 4-szer akkora orajelen, mint az amd gpu-knal, 8*4*4=128. Persze arrol az oldalrol is lehet kozeliteni, hogy kb 200 GFLOPs peak performance (3 GHz * 8 hosszu vektor * 4 core * 2 flop/cycle = 192 GFLOPs). De amugy nem a konkret szamokon akarok lovagolni, hanem azon, hogy az opencl-t nem csak igp-n lehet futtatni, es ez intel es amd cpu-ra egyarant vonatkozik, szoval ha lassu az igp, akkor lehet cpu-n.
-
dezz
nagyúr
A közös FP ütemezővel ez nagyon nincs kizárva, és sokan úgy gondolják, már most jön.
Közben olvasom, hogy az FMA3 a Haswellel lesz bevezetve Intel részről, 2013-ban. [link], [link] (Tekintve a SandyB hagyományos FP kezelését, túl nagy változás lenne ez egy shrinknek.)
lenox: A GPU-kban fused MADD van? Gondolom az, mert gyorsabb. A precizitás szempontjából sem mindegy. De valószínű nem feltétel, mert mai CPU-kon is futhatnak OpenCL kódok. Vagy csak az 1.0-ások?
A #23-asban nem számoltad el magad véletlenül? 1-1 scalar SP single-prec.-ben 32 bittel dolgozik, 128 ilyen már 4096 bit -- szemben az AVX 256 bitjével.
-
flatland8
csendes tag
Ez az érme másik oldala!
Erre is gondoltam miköznem a mondandómat fogalmaztam, de nem akartam kitérni rá.
Sok szempontból lehetne ezt a témát vitatni, de nemsok értelmét látom a továbbiakban. Én csak a Józsibácsis példábmól adodó félreértést szerettem volna megmagyarázni!
-
lenox
veterán
De, ugy tunik. Mondjuk integer valtozatot mar sse2 idoben is hasznaltam... Mondjuk nekem nem is fontos, hogy fused legyen, meg az opencl specifikacioban sem latom, hogy kene az 1.1-hez, de lehet, hogy tevedek. Mindenesetre arra akartam felhivni a figyelmet, hogy az intel nem feltetlenul az igp-n akar opencl-t futtatni, hanem a cpu-n, de egyebkent az amd bulldozer is nagyon eros lesz ebben, nem kell feltetlenul igp-re hagyatkozni.
-
válasz
flatland8
#97
üzenetére
hát bazz nem semmi közgázt adtál itt elő. pár dolog azonban kimaradt :
Azért vehetnek nyugaton mindenből újat akár félévente, mert minden sokkal
olcsóbb mint amennyibe kerülnie kellene. Hogy miért ? Mert nem építik be a
borzalmas környezetszennyezést amit kínába okoz, a rabszolgamunkát amivel
a hozzá való nyersanyagot afrikában kibányásszák, a sok millió 40 évesen elhullott
kínai munkásember egészségügyi költségeit, vagy hogy durvább legyek a 15-20 évesen
elhullott fiatal rabszolgákat akik nem bírják a napi 12 óra állást a szallag mellett.Ha ezekbe úgy igazán belegondolsz akkor talán átgondolod a fogyasztást éltető
közgázodat. Vagy nem -
lenox
veterán
Mondjuk azert irtam cpu-t es nem igp-t, mert a cpu avx supportjara gondoltam... Es az tud MADD-ot.Egyebkent arra kivancsi lennek, hogy mi alapjan mondod ra, hogy gyakorlatban kevesbe... Az gondolom vilagos, hogy ez is tud opencl-t, es latencyben semmilyen cpu-ba integralt gpu nem kozeliti meg. Persze bandwidth ez alatt sincs, de arrol csak en hiszem azt, hogy fontos, masok ugye a latencyben hisznek, hat ez bajnok latencyben.
-
flatland8
csendes tag
válasz
Joachim21
#89
üzenetére
Félreértettél! Főleg a Józsibácsival kapcsolatban.
Nagyon röviden leirnám, hogy mit értettem ez alatt.Szerintem ha nem veszünk kétévente új aplapot, akkor kevesebb alapalpot adnak el, Jozsibácsinak is kevesebb a munkája.
Tőlünk nyugatabbra ez tök normális dolog! b+ ott szezonra veszenk bicajt!!! Nem 15-20 évre. És itt gondolok mindenre amit el tudsz képzelni. Semmi baja az adott terméknek, és már cserélik újabbra.
És ebből a pazarlásból kifolyolag, van munka! Mert az emberek költenek. Gyártani kell nekik az újabb és újabb dolgokat. Még ha nem is mindig jobb az új.
Szerintem a lényeg, hogy amit a mi szemünkel nézve, elpazarolnak pénzt, az hosszú úton keresztül visszaté a zsebükbe. (Józsibácsi eladta az lapalpot Ferinek. Feri pedig eladott egy Fűnyirót Sanyinak. Sanyitól pedig megvette a téligumit a mi Józsibácsink.)
Mindenki költött, de mindenki keresett is! És a gazdasági helyzetük
is jobb mint annak a 3 embernek, akiknek van pénze, de fukarok és nem vesznek semmit.
Itt egyedül az a bibi, hogy felénk az átlagkereset meg sem közeliti a nyugatabbra élőkét.
Hülyén hangzik, de ezen csak úgy lehetve változtatni hamindeki elkezdene költeni mint állat!
Ehez viszont az alapvető gondolkodásmodunkon kellene változtatni. Mindenkinek! És több generáció leforgása alatt, ez meg is történhet. Majd akkor talán felzárkozunk a nagyokhoz!
Nem vagyok bankár, sem közgazdász, de szerintem a válság fő oka az volt, hogy az emberek több kölcsont vettek fel mint amennyit termeltek. Bankok pedig odadták. De nem volt ki visszafizesse. (addig nyújtozkodj, amig a takaród ér! Ez a mondás egyáltalán nem volt betartva.) Mindenki mohó volt. Aztán elfogyott a pénz, és a többit tudjátok. Gondolom azért ettől tobbről volt szó... De nagyjábol ez volt a lényeg.Nem azzal van a gond amikor az ember minden pénzét elkölti, hanem az amikor már olyan pénzt költ ami nem is az övé.
A gyártók pedig még szép, hogy minden követ megmozgatnak, hogy pézt csalogassanak ki a zsebünkből, ahogyan te is remélem mindent megteszel azért (törvényes kereteken belül
![;]](//cdn.rios.hu/dl/s/v1.gif)
), hogy minél több pénzt tudj keresni.Azt pedig mindenki döntse el maga, hogy meg e engedhet magának egy esetleges újitást. Vagy meg kell barátkozni egy átlagos, vagy akár átlagon aluli termékkel. Hameg egyáltalán nincs rá, akkor nem veszel semmit.
Én is nagyon örülnék egy 3-way SLI GTX580 triónak, de saaaajna nem engedhetem meg magamnak még a single-ot sem.
Mégegyszer megjegyezném, hogy nem vagyok Közgazdász! Nem értek hozzá! De én ilyennek látom, egyszerű, paraszt ésszel a gazadaságot.
-
darál0w
Jómunkásember
775nél a visszafele kompatibilitás volt inkább...
pl egy uj p45ös lapba bele tudtál dobálni régebbi Ds procikat...vagy mondjuk egy 90nmes P4est is...
de egy régebbi LGA775ös lapba...mondjuk 945ösbe ( csak hogy ne menjünk annyira régre vissza
) már csak első szériás c2d procikat lehetett beletenni joesetben...szal a LGA 775 sem volt akkora "hudejo mehet bele minden LGA775ös proci" foglalat
-
#19617792
törölt tag
Az LGA775 sem volt jobb ebből a szempontból, sőt több és nagyobb kavar volt esetében. [link] És 65nm vs. 45nm nem ment ám olyan simán, van olyan 65nm Core 2 alá való lap ami nem támogatja a 45nm procikat, szóval nagy kavarás volt LGA775-nél. Miért ferdülnek el az emlékek az idő múlásával? Miért messiás az LGA775?
-
válasz
#19617792
#90
üzenetére
Hát igen! Ezért remélem én hogy rövid időn belül rákényszerülünk valami értelmesebb
világra ( pölö amit Joachim21 is írt), vagy valami bazi nagy válság miatt, vagy mert egyszerűen kifogyunk a nyersanyagokból ( ritka földfémek)De hogy a témához is hozzászóljak : A Zintel bek@phatja :
Egy civil szervezetnek is dolgozok 10 db 6-7 éves gépük van ( sdramos 1,7 P4, 1,5 Amd
meg hasonló) már hetente döglik meg valami ( lap,táp,vinyó ) pénz nincs új gépekre.
Most végre kiírtak egy pályázatot márc31-okt31 között beszerezhető gépekre, pár
napja ezt rakom össze hogy milyen gépeket vegyenek hogy minél tovább tudják
használni és fejleszteni, előre örültem hogy talán lga1155-el kihúzzák sokáig mert milyen jól
bele lehet majd három év múlva pattintani a kifutó IvyBrige-ket.
Most már csak azon reménykedek hogy ideér addig a Llano meg az FM1-es lapok, és
nem lesz semmi komoly problémájuk, és akkor a zintel kevesebb lesz azzal 800K-nyi
pénzel amin gépeket vennénk. -
-
Joachim21
őstag
válasz
flatland8
#79
üzenetére
Ha minden kompatibilis mindennel, akkor miért csökken a variációs lehetőség?
Miért lenne megkötve a gyártó keze? 5 évente olyan foglalatban állapodhatnának meg, amely elégséges sávszélt kínál mindennek, amit az elkövetkezendő 5 évben bevetni terveznek.
A gazdaság, az jelenleg egy nem fenntartható pályán mozog. Józsibácsi éhen hal, mert nincs munka, ami van azt pedig nem fizetik meg, aki meg munkahelyet teremtene nem tud, mert a piacra való belépést ellehetetlenítik számára. Mivel a gazdaság exponenciálisan nővekszik(?) ezért előbb utóbb újra és újra válságoknak kell visszatérítenie azt egy olyan szintre, ami még tartható, ennek meg mi isszuk meg a levét. Szóval mielőtt ezelőtt a zsidókapitalista világ előtt térdre borulsz, és elmondod egy közgazdásznak hogy hogyan működik, azelőtt gondold át, hogy Józsibácsi annak örülne-e ha 1 munkahelyre mehetne el dolgozni alacsony bérért, vagy 10 munkahely versenyezne a tudásáért.
Ha az autódba az összes autógyár, összes részegységéből válogathatnál, akkor a jelenlegi 8 motor helyett több százból válogathatnál! Igen, ugyanis minden kompatibilis lenne, de nem ugyanolyan!
Nem látom miért ne tudnának a gyártók is megállapodni. Ilyen tápáramkört alkalmazunk a következő 5 évben. A foglalat PGA-1500/LGA-1500 (mindegy vmilyen) és meghatároznák a lábkiosztást. Nem kötelező minden lábat használni, de hagynának tartalékot. Kellene még egy déli híd, de most kapaszkodj! az is lehetne cserélhető, és variálható. Miért ne lehetne? Csak akarni kellene!
-
Takacs666
csendes tag
Nemértem mi a baja mindegyikőtöknek.....
A gépem:Intel Pentium 4 650-es 3.4Ghz(64 bit,800mhz FSB 2MB chache)
4 Gb 800mhz-es kingmax alap DDR2(4x1Gb)
Gainward 8600GTS 256Mb
Asus P5WD2
Integrált hang
Érdekes nálam minden megy rendesen szaggatás nélkül és nem csúnya....pedig a processzor 2005-ös a VGA meg talán 2007-2008?Majd jövőre megveszem az Ivy Bridge-et és ujabb 5 évig nem kell gép..mit kell ezt felfujni? -
LGLuke
őstag
Még nem váltottam, csak gondolkodok rajta, de ha váltok, akkor H67-es lapot választok, mert nekem kellene az IGP.
Ergo engem biztosan érintene a probléma, mégsem hisztizek.
Az a vicces, hogy nyakamat merem rátenni, a problémázók 3/4 része eleve be sem fog ruházni H67-es lapra, de valószínű P67-re sem. Szóval csak jó hőbörögni.Valóban kellemetlen, hogy gyakorta cserélgetik a foglalatokat az Intelnél, de szerintem PC-t nem érdemes évente cserélgetni átlag felhasználóknak, vagyis a többségnek.
Ebben az esetben meg mindegy, ahogy már hamarabb kifejtettem. -
flatland8
csendes tag
válasz
Joachim21
#77
üzenetére
"...nem a gyártóktól várom el az egységes foglalat bevezetését, vagy csak ötletszintű felvetését, hanem hogy a kormányok összefogása révén kényszerítsék azt ki!"
Szerintem ez hülyeség! Ha csak 1 féle CPU foglalt lenne, a gyártoknak valamelyest meg lenne kötve a keze. Eleve nem lenne akkora versengés sem. Másrészt ha mélyebbre hatolunk, akkor oda lyukadun ki, hogy "a gazdaság a pénz forgásáról szól..." Józsibácsi éhenhalna a proc hátlapi merevitő gyárban, ha nem kellene újat gyártani. És akkor ő sem tudná megvenni azt a kenyeret amit akármelyikőtök apja süt. és igy tovább...
...És autoból is csak csak olyat gyátsanak, amenyeknél minden alkatrész passzol minden tipushoz. Beleértve magát a motort is.
Ez azt eredményezné, hogy sokkal kisebb lenne a választék. Pont mint régen. Valakik biztosan emlékeznek rá.
És sokan irják itt, hogy hudemilyen jó az amd foglalata... ki mondta, hogy intelt kell venni???
Én speciel sokkal jobban örülök annak, hogy van miből választani. Mindegyik gyártonak és az azokhoz tartozo foglalatoknak is megvannak a maguk előnyei/hátrányai és mindenkinek megvan a lehetősége választani.
Aki pedig minden újitásnál komplett gépet cserél, annak duplán jó.
-
szacsee
nagyúr
-
flatland8
csendes tag
Több mint 3 honapja kezdtem el új gép üsszeállitásán agyalni. Decemberben sikerult megszabadulnom jó áron a C2D rendszeremtől és elhatároztam, hogy 1156-ba invesztálok. Játékra kell a gép és a tuning is lényeges szempont számomra. Nagynehezen kiválasztottam mindent(eléggé válogatos vagyok
)
Ekkor megjelent a Sandy és megtetszett. Most meg olvasom, hogy 1 év mulva ismét újitás...
Érdekel minden technikai újitás/fejlődés, de mint vásárló.... nem IZGAT mint egyeseket.
Szánalmasak azok akik nemrégiben megvették az 1156/1366 rendszeruket és itt panaszkodnak. Szegény szerencsétleneknek, genetikai tulajdonságaikbol és anyagi helyzetükből adodoan, muszáj megvenniük a legújabbat.
Most komolyan... egy átlag felhasználónak mire kell jobb, gyorsabb?
Várni megintcsak nincs értelme mert ilyen hozzáállással soha nem újitanánk. Mindig lesz jobb, újabb.
Én nemsokára beújitok egy i5-K-s sandy-t és az majd elmegyeget nekem 4,5-5Ghz-n, és szerintem minimum 3-4 foglalaton is túl leszünk mire "rákényszerülök", hogy procit váltsak. Addigra meg már ugyis DDR4-es memek lesznek.Azoktol, akik meg értelmetlen okokbol külön akarnak majd először alaplapot újitani, és majd csak később procit venni, megkérdezném, hogy pusztán egy alaplap újitástól mivel lesz jobb az átmeneti időszakban a gép?
Nem ésszerűbb félretenni addig a pénzt mig összejon a procira való is és egyszerre újitani?
Valaki emlitett itt olyat, hogy ezzel akarja a költségeit kiegyenliteni. Beszarás!
Olyanról még nem hallottak az ilyenek, hogy nem kell elb*szni a pénz, amint hozzájut?
EGYENLETESEN félre lehet tenni a havi fizuból annyit amennyi kell. Ezt nevezik SPÓROLÁSNAK!Sry, csak próbálom megérteni az emberi elmét. És az offért is! (Kinek nem inge, ne vegye magára!)
-
Tidus
addikt
Tehát 2011-ben, biztos hogy marad az X58, Szandira amúgy sem akartam fejleszteni. Viszont az Ivy-ről még több infó kell, amik folyamatosan érkezni fognak.
De gondolom sok user arcára rá ült a döbbenet, akik az elmúlt hetekben(héten) eladták az X58-as konfigot ár alatt, aztán P67-re fejlesztettek. -
LGLuke
őstag
Jaja, bocsi, csak előtted valaki írta az 5 évet, és az rémlett, szóval nem csak Neked szólt a válasz, hanem a többieknek is.
atti_2010: Igen, valamint a sok kártya a szellőzést is zavarja, ami a nagy teljesítményű CPU-k és VGA-k miatt ma már ultra fontos.
Ráadásul microATX lapoknak annyi lenne. Rengeteg bővítő hely kellene, főleg, ha speciális eszközöket is használna valaki.
-
LGLuke
őstag
Nem csak azért lehetetlen.
Régen mindent bővítőkártyával oldottunk meg. Még a HDD vezérlő is külön kártyán volt, így nem ritka eset volt, hogy 4-6 kártya is helyet foglalt a gépben.Ma már a I/O vezérlők, a hangkártya, sok esetben VGA kártya és minden vezérlő integrálva van.
Hogy lehetne új USB3, vagy SATA3 vagy bármilyen új szabványt integrálni, ha 5 évente újítanák a chipsetet. Sokkal drágább lenne külön kártyákat vásárolni.
-
Srodney
senior tag
válasz
#19617792
#63
üzenetére
jah igaz szép álom de az sem jó ha mindíg alkatrész vásárlásra buzdítanak,mert különben lemaradsz a fejlődésben...ez a két véglet,kettő közt kellene marketingezni a vállalatoknak....tehát kellene egy jó verseny jó árakkal és ritkább foglalatcserével és nagyobb kompatibilitással visszamenőleg!...jovanmár ez is álom 
-
Srodney
senior tag
válasz
#19617792
#58
üzenetére
Platformosítás nem öli meg a PC-t. Továbbra is lehet legózni szépen, komoly lap + olcsó proci, majd később egy nagyobb kompatibilis proci. Minden platformon meg lehet játszani.
Így legyen AMEN!!!
#60: az lenne csak az igazi legózás,azt teszek bele amit csak akarok...de azért 5év alatt annyi minden változik,gondolj csak bele a s939-be...hiába voltak már abba is x2esek,amin fejleszteni már nem lehet az elavult és újat kell helyette készíteni,ami tovább fejleszthető...nah igen de vannak olyanok is akik mindíg újat készítenek ahelyett hogy inkább megprobálnák a régit úgy megépíteni hogy fejleszthető legyen.....ez eléggé idegesítő mert egyszer úgy is eljön az idő amikor váltani kell,csak nem 6évente hanem (ezekszerint) évente a gyártók és kereskedők nagy örömére....
-
Joachim21
őstag
Be kell vezetni világszinten egy foglalatszabványt (+chipset szabványt), amit 5 évente lehet cserélni és kész. 5 évig tuti lenne, és bármelyik gyártó, bármelyik termékét kezelné, mert mindenki úgy sakkozna, hogy az egyetlen foglalathoz jó legyen a CPU-ja, akár ARM, akár x86, vagy bármilyen más architektúrára is épüljön. Szép álom.
-
LGLuke
őstag
Ebben az esetben nincs gond!
Csak a 2500K és 2600K, azaz "K" végű CP-kban van 12-es feldolgozóegység.
Tehát, aki IGP-t hosszú- vagy középtávon szeretné használni, annak ha fene - fenét eszik is, ilyet kell vennie.
Aki i3-ast választ, az max a 6 feldogozóegységes IGP-t kapja, így valószínűsítem, ha játékra használja, akkor +VGA kerül a gépbe. Ekkor meg lehet P67-es alaplapot választani, hátha az támogatja majd, - mint a cikkben is szerepel - az új CPU-t is.Akinek meg elég H67 6 egységgel, az meg vehet használtan i7-et 12-vel a Sandyból.
-
#19617792
törölt tag
Az idő megszépít minden emléket... LGA775-nél pontosan ugyanez volt, mint most ennél az LGA1155-nél, sőt, ráadásul többször is. Olvasd el az #54-es hozzászólást.
Platformosítás nem öli meg a PC-t. Továbbra is lehet legózni szépen, komoly lap + olcsó proci, majd később egy nagyobb kompatibilis proci. Minden platformon meg lehet játszani.
-
#57
Ł-IceRocK-Ł
veterán
Ł-IceRocK-Ł
veterán
A Sandy Bridge jó formán még el sem indult hódító útjára.... és már az Ivy Bridgre ről hallani...
ez kész. -
Srodney
senior tag
igen,ezért ez a platformosítás öli meg a pc lényegét...sajnos...inteltől sokat nem lehet várni,oda mindíg újat kell venni,a s775-höz hasonló korszaknak vége...az amd viszont nyerő lehet ezekkel a am2+ és am3+ os lapokkal hogy hagyják az embert kibontakozni és elgondolkodni a fejlesztéseken...
-
#19617792
törölt tag
válasz
Angel1981
#45
üzenetére
Alapvetően igazad van, de egy pici korrigálást tennék.
LGA775-nél a processzorok fejlődése során nemcsak a chipset volt inkompatibilis az új procikkal, hanem a lap processzor tápellátó, VRM része. A régi Pentiumokhoz képest a Core 2-nek alacsonyabb feszre volt/van szüksége és finomabb, kisebb léptékű feszültségszabályzásra, amit az akkori, Pentiumokra tervezett lapok nem tudtak. Ezért adtak ki sok régebbi lapból (pl 945P chipsetes lapokból, amik hivatalosan nem támogatják a Core 2-ket, de a gyártók rácáfoltak) "Core 2 Ready" verziót, ahol a BIOS mellett a VRM is frissült. Szóval nemcsak a chipsetek okoztak némi gubancot LGA775-ön, hanem a VRM is. -
Chaser
legenda
Én azt nem értem hogy mért nincs belépő cpu az s 1156/1155-be. Nekem kb egy 20k-s G9650 még nem belépő. s775-be már nehézkes értelmes k_vadot venni újan meg drága is, akinek most meg nem kellene kraft vehetne s1155-ös lapot valami olcsóbb procival, de nem vehet, mert olyan nincs. Majd jönnek, de abszolút lowend -mint pl s140 amd-nél- nem lesz. Hogy ebben mi a ráció azt mondja meg nekem valaki.
-
stratova
veterán
-
LGLuke
őstag
A tesztben is le volt írva, hogy túl erősek a CPU-k átlagos felhasználásra.
Aki most ilyet vesz, annak CPU-t 3 évig tuti nem érdemes cserélnie, mert nem nagyon használja ki semmi, ha csak nem olyan munkához veszi.
Aki komoly munkához választ gépet, az meg betudja költségnek, úgyis mindig a legújabbat kell megvennie.Az hülye, aki mindig otthoni felhasználásra a legújabb terméket választja. A nagy többség 2-3 generációnként, vagy még később vált, addigra meg úgyis új ram és alaplap kell.
-
stratova
veterán
Aki most vett új rendszert nem valószínű, hogy mostanság cseréli. De ha valaki nem csúcs SB-t vesz annak esetleg érdekes lehet, hogy később netán használtan tud-e bele tenni egy újabb procit amire most nem tellett (akár szolgáltatás, akár fogyasztás akár-mi miatt
.
Korábban AM2+-ba nem volt rossz fejleszteni, de most már nagyon eltávolodott a ddr2 ddr3 ára.
Mondjuk egy 2500K-val a gépemben én sem bánkódnék, ott pont az alaplapok szeparálása lehet zavaró, illetve ennek fényében eleve érdekes a szorzólock és a GPU teljesítmény viszonya Intelnél.
Az sem lehet rossz dolog, ha pl. van egy diszkrét VGA-d és az APU-ban lévő GPU besegít fizikában vagy más műveletben (ki tudja).
A memóriabővítéshez vegyük hozzá a méret mellett az adott típus árát is mint korlátozó tényezőt
Azért eseménydús évnek nézünk elébe szvsz lesz miből válogasson az ember, most már emberi fogyasztás mellett. -
#21795072
törölt tag
Engem spec érdekel, hogy időt álló legyen a lapom. 2006-ban vettem P5B Deluxe deszkát E6600 procival. ez a lap még most is tökéletes, és az E8600 proci, amit 2009-ben vettem 13000 ráfizetéssel most is 4,6GHz-en ketyeg benne. Ez így együtt nem volt rossz vétel.
Ha jól akarod húzni a procit, ahhoz jó lap kell. Csak procit cserélni egyszerűbb, mint mindent.
-
#42
Cyberpunk
félisten
Dragon3000
#37
Cyberpunk
félisten
válasz
Dragon3000
#37
üzenetére
Tudod vannak akik csak akkor érzik jól magukat ha mindig a legfrissebb hardver van a gépükben. Mert az a menő és nőhet az e-pénisz
Én például nem futok SB-t venni jó nekem az i7 is. Sőt ez legalább jobb többkártyás rendszerekhez. -
LGLuke
őstag
Azért kicsit eltúlzottnak érzem a hőbörgést!
Főleg az IGP változik. Aki vesz külön VGA-t, annak:
1. mivel CPU rész nagyon nem változik, ezért magasról tesz rá, hiszen sokat nem profitálna az új prociból
2. akinek H67-es lapja van, annak mivel a tesztek szerint a mostani IGP is erős vagy nem lesz szüksége az újra, vagy vesz mellé egy külön VGA-t később, és megúszta a gép frissítést.Tudtommal alaplapot és CPU-t akkor cserélünk, ha vagy a memória ezen típusa már nem bővíthető tovább - ebben az esetben 32GB a jobb alaplapoknál - vagy a CPU lassabb, ez meg ugye kiderült, hogy az újabb se lesz sokkal gyorsabb.
Az meg eleve hülyeség, hogy a most drágán megvett CPU-dat féláron eladod, hogy vegyél újra 2x áron egy 10%-kal gyorsabbat. -
#19617792
törölt tag
válasz
megint én
#32
üzenetére
LGA1155 lapba csak LGA1155 proci megy, LGA1156-tal semmilyen formában nem kompatibilis. Amúgy kötelez valaki a cserére? Ha már Intel a legjobb, akkor szépen vegyél meg mindent tőle...
Annyira bírom, hogy pl. Intel jön egy új foglalattal, itt sír mindenki, hogy jaj új foglalat, kötsög Intel, minek megint új foglalat, stb... És, kötelez valaki a cserére? Mielőtt valaki fanboyságot sütne rám, az nagy bakot lő. Nekem hótmindegy, hogy AMD vagy Intel logó feszít a procin.
(#29) Solten: Just like LGA775.
-
#38
Móci
addikt
Dragon3000
#37
Móci
addikt
válasz
Dragon3000
#37
üzenetére
Kb. így van. De azért nekem sem tetszik ez a rengeteg 'csere'...
-
#37
Dragon3000
nagyúr
Dragon3000
nagyúr
Most mit vagytok kiakadva? Akinek van egy 1156os normális rendszere vagy már szandija és cserélni akarja az új szandik érkezésével az egyszerűen hülye. Az hogy jön egy új cucc nem jelenti , hogy kötelező megvenni.
-
stratova
veterán
Arról nincs információ, hogy az új lapok fogadni fogják-e a jelenlegi Sandy Bridge processzorokat? Ugyebár az AM3+ egyik előnyeként volt feltüntetve, hogy kezeli a régebbi az AM3-as CPU-kat, így nem kell egyszerre alaplapot és CPU-t cserélni. Ha elméletben van esély a P67-es lapoknál a jövevény támogatására, akkor ez a felvetés sem várható ki nem?
Igaz ennek szvsz itt egy árnyalattal kevesebb értelme van, mert elnézve az SB teljesítményét nem éppen a CPU gyengesége miatt vált a mezei felhasználó lapot. Persze ez csak a 2500, 2600-asnál lenne így. Új Core I3-asokról még el tudom képzelni, hogy erősebb CPU miatt vált valaki (ha lehetséges) először lapot, majd CPU-t elterítve a kiadásokat és megoldva, hogy ne essen ki az érintett gép a(z esetleg) napi használatból.
Egyelőre nekem is szimpatikusabb az AMD megoldása, de meglátjuk mi sül ki még ebből. Most hogy egyre inkább lehoznak olyan szolgáltatást asztali megoldásokba, amik ált. szerverek kiváltságai (itt most a virtualizációt érintő képességekre gondolok AMD-V szinte mindegyik processzorukban (talán csak a Sempronokban nem?), IOMMU a felsőbb kategóriás desktop chipsetekben. Biztos van más is nem vagyok még benne járatos, de egyre jobban érdekel a téma).
-
megint én
őstag
És azt hittem, hogy előre gondolok, legyen benne USB3, Sata3, Stb, Stb... Érre jön az 1155ös, meg most ez is... Hát amígre lesz nekem Sata3as adathordozóm addigra már a 3. alaplapom lesz -_-' 
Ilyet vazzze, most nagyot csökkent a szememben az intel.
Ja és persze ott van még a tuning csonkítása! Fúúúj, de pöce kis g.cik ezek! -
-
DRB
senior tag
"A Sandy Bridge IGP-jének problémája, hogy nem kezeli a manapság terjedő szabványokat, így hiányzik a legújabb DirectX és DirectCompute, valamint az OpenCL és a WebGL használatának lehetősége"
Tehát magyarul semmire nem jó, csak hogy legyen valami kép a monitoron(viszont ezért tök felesleges volt belepréselni a prociba), és ahhoz, hogy továbblépjen az ember(proci csere egy már valóban használhatóra) kell egy másik alaplap. Nesze neked Intel, aki most megvette a lapot + procit, az meg is szívta ahogy az a nagykönyvben(Intel forgatókönyve) meg van írva. Ez nekem akkor se kéne ha féláron adnák.
-
#3
BobChemistry
őstag
BobChemistry
őstag
Új (n)év, új foglalat. Mi ebben a meglepő?
elképesztő...
mellesleg meg minden respect a PHközgaszdásznak!!!!! 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
), hogy minél több pénzt tudj keresni.
)
És azt hittem, hogy előre gondolok, legyen benne USB3, Sata3, Stb, Stb... Érre jön az 1155ös, meg most ez is... Hát amígre lesz nekem Sata3as adathordozóm addigra már a 3. alaplapom lesz -_-' 
.
Új hozzászólás Aktív témák
- Műholdaktól is képes segítséget kérni az Apple Watch Ultra 3
- Nők, nőügyek (18+)
- Építő/felújító topik
- Törvényben kötelezné az USA a hazai AI igények elsődleges kiszolgálását
- Eredeti játékok OFF topik
- 3D nyomtatás
- iPhone topik
- Kerékpárosok, bringások ide!
- Apple iPhone 16 Pro - rutinvizsga
- Dacia topic
- További aktív témák...
- i5 12400F dobozában, még 2 hónap Aqua garanciával
- Intel Core i9-12900K 16-Core 3.2GHz LGA1700 (30M Cache, up to 5.20 GHz) Processzor!
- Intel Core I9 14900F - 24mag/32szál - Új, Gari 2030.08.27. -ig - Eladó!
- AMD Ryzen 7 9700X - Új, 3 év garancia - Eladó!
- Intel Core Ultra 7 265K - Új, Gari 2028.09.27. -ig - Eladó!
- Telefon felvásárlás!! Huawei P20 Lite/Huawei P20/Huawei P30 Lite/Huawei P30/Huawei P30 Pro
- LG 25GR75FG - E-Sport Monitor - FHD 360Hz 1ms - NVIDIA Reflex + G-sync - AMD FreeSync - HDR 400
- LÉZEREZÉS! külföldi billentyűzet magyarra kb. 20-30p alatt!
- iPhone 13 mini 256GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3404
- Bomba ár! HP EliteBook 8440P - i5-520M I 4GB I 250GB I DVDRW I 14" HD I DP I W10 I Garancia!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest