- Windows: mi történik valójában Leállításkor, Alvó módban és Újraindításkor?
- Gyenge Wi-Fi otthon? – a leggyakoribb hibák és megoldások
- Korábbi vezetője szerint 40 milliárd dollár kell az Intel versenyképességéhez
- Új, belépő szintű Radeont kapnak az OEM-ek
- Hamarosan találkozhat az USA és az Intel vezetője
Új hozzászólás Aktív témák
-
dezz
nagyúr
Abu szerint egy program egyszerre csak egyfélét használhat. [link] Bár ez nekem elég furcsa, szerintem megoldhatónak kell lennie, csak talán komplikáltabb.
(#99) lenox: Észrevetted már, hogy nagyon szereted kiforgatni a szavakat? (Uhh, 1000 bocs, ez most megint "az ellenfel fikazasa", csak hát, ez a helyzet.) Én mindösszesen arra kérdeztem rá, hogy elismered-e, hogy az említett esetben az APU a gyorsabb. Nyilvánvalóan ettől nem lesz automatikusan mindenben gyorsabb. Nem is értem, ez hogy jött ki neked. Vagy itt most a lenox-féle érveléstechnika csillant meg?
A #94-ben sem arra válaszoltál, hanem tereltél és kötözködtél.
"Ha jol ertem akkor nem tudsz peldat mondani, tehat akkor azt az allitast, hogy de te mar mondtal, azt minek nevezik?"
Ehh, újabb kiforgatás... (Pedig egyértelműen különbséget tettem az általános, a leszűkített és a programnév szinten konkrét példa között, direkt a kedvedért...) Nos, én az első kettőt teljesítettem: pontosan leírtam, milyen esetben jön ki az APU előnye, és példát is mondtam rá a ray-tracing képében. Csak hát te itt már programnevet követelsz, amivel valóban nem szolgálhatok, mint már írtam.
"nem az a lenyeg, hogy ossze van-e integralva a gpu a cpu-val, hanem hogy egy kozos lassu memoriarendszeren osztoznak-e."
Aham, csak kár, hogy ez hozzátartozik az összeintegráltsághoz, főleg ha még egy címterületen is dolgoznak majd... És mivel ez így van, amit te is jól tudsz, csak kibúvókat keresel, ezért tehát szerinted itt bukik az egész dolog. Én meg erre ugye azt mondom, már nem tudom, hányadszorra, hogy bizonyos feladatok esetén ez valóban bottlenecket képez, más feladatoknál meg nem.
-
lenox
veterán
Bocs, de egy ilyen 'felteve hogy valamire az apu a leggyorsabb, tagadod-e, hogy arra az apu a leggyorsabb' kerdest nem gondoltam, hogy komoly kerdesnek tartasz, most sem gondolom. Mondjuk a #94-ben erre valaszoltam, hogy nem ertetted...
Ha jol ertem akkor nem tudsz peldat mondani, tehat akkor azt az allitast, hogy de te mar mondtal, azt minek nevezik? En tudom... Dezz ervelestechnika, masik fo motivum az ellenfel fikazasa mellet, lasd gerincesseg.Az utolsó bekezdésben önmagadnak mondasz ellent
Ez megint valami dezz logika lehet, mert en nem latok ellentmondast, bar amugy megint nem ertetted, hogy nem az a lenyeg, hogy ossze van-e integralva a gpu a cpu-val, hanem hogy egy kozos lassu memoriarendszeren osztoznak-e.#97 Cal-t hasznalnak, nem opencl-t.
-
LordX
veterán
-
dezz
nagyúr
válasz
Dr. Akula
#93
üzenetére
Szerintem tesztelik, csak az nem várható, hogy kimondottan rá is optimalizálják a CPU-s részt Intel procikra.
(#94) lenox: Ez nagyon gerinces, hogy folyamatosan a konkrét (mint program-cím) példán pattogsz, de messziről elkerülöd a válaszadást az idézett mondatrész folytatására... (Mellesleg 1-1 tévedésedet sem igyekszel elismerni.)
"Az integraltsag elonyet akarod bizonyitani meg mindig. Nyilvan akkor olyan rendszerhez kell hasonlitani, ami hasonlo tulajdonsagu, csak nem integralt."
Természetesen!
"Amugy a cpu magaban 21.6 MPix/s-et tudott, de ebbol csak 7.6 maradt meg... Nekem ugy tunik gatoltak egymast, de akkor magyarazd meg, ha nem."
Sajnos nem szerepel ott CPU + diszkrét GPU eredmény, hogy legyen mihez hasonlítani. De nyilván csökkenti a CPU teljesítményét, ha a GPU dolgoztatásával is foglalkoznia kell. Nem mintha ez itt megint egetrengető lassulást okozna...
"Nem gondolom ezt"
Akkor miért vonsz le ilyen irányú következtetést?
"ez a kozos memoria bottleneck tema, ami az integraltsag hatranya."
Hogyan bizonyítanád, hogy itt erről van szó?
Az utolsó bekezdésben önmagadnak mondasz ellent, mert pl. a Trinitynél is közös lesz a memóriavezérelő, így szerinted mindenképpen rosszabb választás, mint a különálló CPU és GPU, ami a teljesítményt (akár grafikus, akár GPGPU) illeti.
-
lenox
veterán
Olyan feladatoknál
Ird legyszi a konkret pelda alkalmazast. Ha nincs, akkor nincs. Amugy azt nem tudom hogy gondoltad, hogy diszkret gpu onmagaban. Bar ha a proci onmagaban reszt nezzuk azon is az latszik, hogy meg mindig nem erted, hogy az apu-nak egy diszkret vga + cpu parost kene lenyomnia ahhoz, hogy kideruljon, van elonye az elmeletben gyorsabb kommunikacionak.
Nyilván nem ez volt a lényeg...
Hanem mi? Az integraltsag elonyet akarod bizonyitani meg mindig. Nyilvan akkor olyan rendszerhez kell hasonlitani, ami hasonlo tulajdonsagu, csak nem integralt. Tehat ha az apu-s rendszerben 2 gpu van, akkor a nem apu-s rendszerben is 2 kell legyen, kulonben semmi ertelme az osszehasonlitasnak.
Már többször is meghatároztam, milyen esetekben tud döntő tényező lenni és példát is írtam.
Hol a pelda, melyik program, mik az eredmenyek?
Már ha a 348,4 és 356 közötti 7,5 GFLOPS neked semmi...
Amugy a cpu magaban 21.6 MPix/s-et tudott, de ebbol csak 7.6 maradt meg... Nekem ugy tunik gatoltak egymast, de akkor magyarazd meg, ha nem.
1. Szerintem mosd ki a szemed, mert belement valami...
Gondolom mindjart jon a hulyezes is...
2. Miből gondolod, hogy ebben a tesztben olyan feladat van, aminél kulcsfontosságú a kettő közötti kommunikáció?
Nem gondolom ezt, ha nem csak irnal, latnad, hogy ez a kozos memoria bottleneck tema, ami az integraltsag hatranya.
3. A Llano csak az első lépés ebben az irányban, de te az egész APU koncepció létjogosultságát kérdőjelezted meg.
Ez megint kepzelges, azt kerdojelezem meg, hogy a llano-ban az integraltsag gyakorlati teljesitmeny elonnyel jar a gyorsabb cpu-gpu kommunikacio okan, azt, hogy eddig nem lehetett heterogen programot irni, most meg lehet, ellenben allitom, hogy az integraltsag hatranya pl. a kozos memoriarendszeren valo osztozas.
-
Dr. Akula
félisten
Ez oké, de a vita abból indult ki, hogy az AMD nem teszteli más gyártók procijával a kompatibilitást (ez nyilván csak az Intelre vonatkozhat, más valós konkurrenciája nincsen). Tekintve az Intel vs AMD procik teljesítménykülönbségét és elterjedtségét, a többségnek Intel van. Főleg ahol van pénz komolyabb videokártyára is. Így pont a csúcskategóriás Radeont vásárlókat szopatja az AMD, mert azoknak nagy valószínűséggel futja Intel procira is, és nem azért vettek csúcsradeont hogy prociból ne a csúcsot vegyék.Ilyen szempontból sztem öngól. Bár tudom hogy a legnagyobb eladások az alsókategóriában vannak, de a legkisebb haszon is azokon van. Aki AMD procit vesz, az csúcsradeon helyett beéri középkategóriával is. ez nemtom miért jó nekik. Engem konkrétan érint(ene, ha használná vmi az OpenCL-t) a dolog, és nem szívesen vennék AMD procit. Persze ha a Bulldozer tud majd annyit mint az SB, akkor simán váltok, de az Athlon 1 óta nem ez a helyzet, és ilyen értelmű előrejelzést se nagyon láttam még (leszámítva az AMD marketinget, de az nem mérvadó).
-
dezz
nagyúr
Olyan feladatoknál, ahol a CPU és a GPU gyors interakciója és a kellő számítási teljesítmény ugyanolyan fontos, előnyösebb egy APU, mint egy diszkrét GPU vagy a proci önmagában, AVX-es kóddal. Ezt csak nem tagadod...!? Az már más kérdés, hogy milyen alkalmazásban fordul elő ilyen feladat.
"Hat igen, ha ket gpu van a rendszerben, az gyorsabb lehet, mint ha egy."
Nyilván nem ez volt a lényeg...
"Teljesen lenyegtelen, hogy abbol az egyik a cpu-val egy lapra van integralva"
A fenti esetben nem -- ha kellően gyors (kis késleltetésű és elegendő sávszélességű) a CPU és a GPU közötti kommunikáció.
"Legyszi ird le a peldakat, amikor vgaval nem megy, ellenben apuval igen."
Már többször is meghatároztam, milyen esetekben tud döntő tényező lenni és példát is írtam.
"Melyik is volt az?"
#56?
"Amikor a llano csak gpu-val kb. ugyananolyan eredmenyt ert el, mint cpu+gpu-val"
Már ha a 348,4 és 356 közötti 7,5 GFLOPS neked semmi...
"de mindketto alatta volt az ugyanannyi sp-t tartalmazo, ugyanolyan sebesseggel jaro diszkret vga-s eredmenynek?"
Milyen érdekes, hogy az előzővel ellentétben a 356 és 359,9 közötti 3,9 GFLOPS itt mekkora jelentőségűvé válik... Hát tudod, itt most számszerűen kijött, hogy nem ugyanazzal a mérleggel méred a neked tetsző és nem tetsző dolgokat...
BTW, a 348,4 és 359,9 közötti, ~3%-os különbség sem nevezhető éppen egetrengetőnek...
"Ezt nem inkabb neked kene tudomasul venni, hogy hoppa, semmilyen elonnyel nem jar, ha osszeintegralod oket?"
1. Szerintem mosd ki a szemed, mert belement valami...
2. Miből gondolod, hogy ebben a tesztben olyan feladat van, aminél kulcsfontosságú a kettő közötti kommunikáció?
3. A Llano csak az első lépés ebben az irányban, de te az egész APU koncepció létjogosultságát kérdőjelezted meg. -
lenox
veterán
Most viszont úgy próbálod beállítani, hogy mintha a Llanonál egész más lenne a helyzet (GPGPU-s felhasználást illetően is), pedig teszteredmény bizonyítja, hogy egálban lehet a neki megfelelő diszkrét változattal.
Mirol beszelsz? Azt probalod bizonyitani, hogy van elonye a cpu es gpu kozotti gyors kommunikacionak. SP processing bottleneckes feladatnal egalban lehet a megfelelo diszkret valtozattal a llano, igen. Ebben az esetben semmi jelentosege, hogy gyorsabb-e a komminikacio, mint pcie eseteben. Tehat ezzel nem tudod bizonyitani, hogy elonye lenne, akkor miert erdekes ez az eset?
adott esetben igen sokat dobhat a teljesítményen, ha egy sok-SP-s GPU mellé tesznek egy ilyen APU-t
Hat igen, ha ket gpu van a rendszerben, az gyorsabb lehet, mint ha egy. Teljesen lenyegtelen, hogy abbol az egyik a cpu-val egy lapra van integralva, vagy nem, tehat lehet siman ket diszkret vga. Mint ahogy mar volt is, lasd physics tarskartya, vagy sli, vagy cf. Pont ezt mondom, semmi vilagmegvaltas, ilyen mar volt eddig is.
Csak nem mindig sikerül...
Legyszi ird le a peldakat, amikor vgaval nem megy, ellenben apuval igen.
Egyelőre itt én hoztam fel teszteredményt, ami éppen hogy az ellenkezőjét mutatta.
Melyik is volt az? Amikor a llano csak gpu-val kb. ugyananolyan eredmenyt ert el, mint cpu+gpu-val, de mindketto alatta volt az ugyanannyi sp-t tartalmazo, ugyanolyan sebesseggel jaro diszkret vga-s eredmenynek? Ezt nem inkabb neked kene tudomasul venni, hogy hoppa, semmilyen elonnyel nem jar, ha osszeintegralod oket?
-
dezz
nagyúr
válasz
Dr. Akula
#89
üzenetére
Az Intel OpenCL drivere egyelőre CPU-n fut.
Nem ismerem az OpenCL-t töviről-hegyire, de csodálkoznék, ha nem lehetne minden cuccnak saját OpenCL drivere. Tehát, ha pl. csak akkor működhetne együtt Nvidia és AMD GPU (vagy épp Intel CPU + AMD GPU), ha mindkettőnek ugyanazt a drivert használja (amilyen nyilván nem lesz, ami az első esetet illeti)...
Szerintem az APU-knál arról van szó, hogy adott esetben előnyösebb az összegyúrt driver (ami a GPU-t és a CPU-t egyben kezeli), mint a különállók.
-
dezz
nagyúr
Nézd, a SandyB esetén én fejeztem ki kételyemet a számítási teljesítményhez képesti fele olvasási és negyede írási L1D sávszélességgel kapcsolatban, akkor ti gyorsan megmagyaráztátok és végülis bizonyítottátok (legalábbis az olvasást illetően), hogy ez nem gond.
Most viszont úgy próbálod beállítani, hogy mintha a Llanonál egész más lenne a helyzet (GPGPU-s felhasználást illetően is), pedig teszteredmény bizonyítja, hogy egálban lehet a neki megfelelő diszkrét változattal. (Figyelmedbe ajánlanám, hogy az IGP-ben lévő cache ugyanolyan sávszélekkel rendelkezik, mint a diszkrét változat esetén.)
Az lehetséges, hogy egy jóval több SP-s GPU-val nem tud versenyre kelni, azonban adott esetben igen sokat dobhat a teljesítményen, ha egy sok-SP-s GPU mellé tesznek egy ilyen APU-t, ami bizonyos feladatokon a CPU-val közelebbi együttműködésben dolgozik.
Mindez desktopon -- mobil volalon nagyon sok esetben nem lesz diszkrét GPU.
"azt allitottam, hogy a kommunikacio esetleges gyorsasagat nemigen fogja tudni semmi kihasznalni (mivel a cpu - pcie - gpu rendszerben is mindig probalja az ember elfedni)"
Csak nem mindig sikerül...
"tehat csak az a hatrany fog kijonni, hogy a cpu es gpu kozos lassu memorian osztozik. Es lam a tesztek is pont ezt mutatjak, milyen meglepo."
Egyelőre itt én hoztam fel teszteredményt, ami éppen hogy az ellenkezőjét mutatta. A meglepő az, hogy nem veszed tudomásul...
-
Pietrosz
addikt
-
-
lenox
veterán
Az elejet meg egyszer vegiggondolhatnad, mielott bennem keresed a hibat, leven hogy nem az a kerdes, hogy lehet-e cpu es gpu kozott feladatot megosztani, hanem az, hogy hol lenne ebben az apunak valos alkalmazasban az elonye egy hagyomanyos cpu - pcie bus - gpu megoldashoz kepest. A hatranyat (kozos memoriarendszer) latom, azt jo sok helyen ki lehet mutatni, de hol az elonye? Szerinted a raytracingnel? Akkor mutass peldat olyan tesztre, ahol Athlon x4 + 800 sp vga teljesitmenyet eleri a llano, mert akkor az kezzelfoghato elony. De amig annyi a magyarazkodas, hogy de hat kb akkora a teljesitmenye, mint az ugyanolyan orajelen mukodo ugyanannyi sp-t tartalmazo gpu-s renszere (lasd amit #79-ben irtal), akkor az pont azt jelenti, hogy semmilyen elonye nincs.
Az avx-et ugye arra a helyzetre javasoltam, amikor az ido nagy resze kommunikaciora megy el, tehat nem fog az igp 500 GFLOP-ot nyomni masodpercenkent logikus modon.
Ezt a cache dolgot mar korabban is leirtam mas topikban is, szerintem eleg konzisztensen. Nem ertetted ezek szerint, az apu koncepciot nem ertelmetlennek tartottam sosem, hanem azt allitottam, hogy a kommunikacio esetleges gyorsasagat nemigen fogja tudni semmi kihasznalni (mivel a cpu - pcie - gpu rendszerben is mindig probalja az ember elfedni), tehat csak az a hatrany fog kijonni, hogy a cpu es gpu kozos lassu memorian osztozik. Es lam a tesztek is pont ezt mutatjak, milyen meglepo. Ha javitod ezt a bottlenecket nagy savszelessegu memoriaval, vagy nagy cache-sel, egybol no az apu teljesitmenye. Ez meg ma nincs, ha majd lesz, jo lesz, nyilvan amugy egy gpu ha beindul, akkor rettento mennyisegben ontja az adatot, lasd sb level3 cache problemai, szoval ez nem trivialis feladat, de kb. ezen all vagy bukik a dolog, mert nem hinnem, hogy 200 GB/sec sebessegu memoriarendszert akarna valaki alaplapra integralni (mert ha igen, az akkor grafkartya).
Ugyhogy lehet, hogy a marketing azt nyomatja, hogy vilagmegvaltas, de szerintem meg egy lapra integralt cpu+gpu, semmi kulonos, arazastol fuggoen jo vagy rossz vetel.
-
Pietrosz
addikt
A Xilisoft is gyenge minőséget csinál, most próbáltam. Amd app nélkül még elmegy, de ha bekapcsolom, igaz gyors lesz, de legalább ronda. De ez így kinek jó? Amd miért adja pl a nevét hozzá? Egy részről ott van a minőségre törekvés, egyre jobb AA, AF módok, stb, másik oldalról meg leszarják, csak gyors legyen?
Most vagy a fejlesztők is hülyének nézik az embert, vagy ez a technika tényleg nem a minőségről szól, csak én éltem álomvilágban 
-
dezz
nagyúr
Ejj, ejj, mintha nem tudnád, hogy a GPU-k (maiak sem) nem igazán szeretik az ugrásokat, amik a CPU-knak viszont meg sem kottyannak... Ennek kihasználásához mindössze olyan feladatok kellenek, amiknek egyes lépései komplikáltabb algoritmusok, más lépései pedig egyszerűbb, de számításigényesebbek. Ne mondd már, hogy ez annyira egzotikus dolog lenne!
Nem is kell messzire menni, vegyük pl. a a ray-tracinget: van benne rengeteg adaton, de egyszerűbb és jóval kisebb adathalmon, de jóval bonyolultabb számítási feladat is. (De szerintem ezt nem kell neked magyarázni.
Vagy ha mégis, később majd meglátod, ha továbbfejleszted esetleg azt a kis OpenCL-es ray-tracert...)Az AVX-ből, mint megbeszéltük, ilyen 200 GFLOPS körüli (vagy alatti) értékeket lehet kihozni SandyB-n és az IvyB sem lesz sokkal előrrébb. Ehhez képest a Llano IGP-je 4-500 GFLOPS-os, ami azért mégis csak 2-2,5x annyi. Bár még nem derült ki, milyen gyors lehet a kommunikáció a CPU és a GPU között.
"ugyhogy pontosan akkor lehet majd ebbol igazi elonyt kovacsolni, amikor az integralt cpu es gpu kozos cache-sel fog rendelkezni. Az meg nem most van."
Nocsak, nocsak! Eddig az egész APU koncepciót értelmetlennek mondtad (és még a mondat első fele alapján sem ilyen befejezésre számítana az ember
), ehhez képest előrelépés, hogy bizonyos feltétekkel már tulajdonítasz neki némi létjogosultságot. 
Mindegy, ezek csak az első lépések, a jövő a sokkal komolyabb integrálás, összegyúrás, közös regiszterkészlettel, stb.
-
#81
hugo chávez
aktív tag
lenox
#80
hugo chávez
aktív tag
"ugyhogy pontosan akkor lehet majd ebbol igazi elonyt kovacsolni, amikor az integralt cpu es gpu kozos cache-sel fog rendelkezni. Az meg nem most van."
Hát, a Sandy Bridge-nél közösen használhatják az L3 cache-t a procimagok és az IGP, de, tudomásom szerint, ott meg pont az a gond, hogy, ha az IGP "teleszemeteli", akkor ezzel a CPU részt lassítja.
-
lenox
veterán
Nem hiszem, hogy ne tudnál elképzelni olyan helyzetet, amikor nem optimális a nagyobb csomagok cseréje a CPU és a GPU között, hanem kisebb csomagok jóval gyorsabb cseréjére van szükség.
Ertem, hogy ez marketing bullshitnek jo, pont ezert kerdezem, hogy tudsz-e valos alkalmazasrol, mert gondolnam, hogy nem tudsz, pont azert, mert ezt marketing bullshitnek tartom. Mar tobbszor leirtam, hogy en max benchmarkot tudok elkepzelni, amiben ezzel villantani lehet, de nem feltetlenul jut eszembe minden problema a vilagon, szoval ha valaki tud ilyet, batran adja elo. Csak mert sarkitva vagy a kommunikacio a bottleneck, vagy a processing. Ha a kommunikacio, akkor az sse, avx regiszterek joval gyorsabban elerhetoek, ha a processing, akkor egy kozepes grafkartya joval nagyobb teljesitmenyre kepes, ugyhogy pontosan akkor lehet majd ebbol igazi elonyt kovacsolni, amikor az integralt cpu es gpu kozos cache-sel fog rendelkezni. Az meg nem most van.
Előtte is, utána is láttam több-GPU-s eredményeket, szal szerintem átmeneti bug lehetett.
En is, opengl-lel, cudaval meg cal-lal, de nem opencl-lel. Szoval tuti, hogy opencl volt?
-
dezz
nagyúr
+Raymond:
1. Az A8-3500M egy mobil chip, 1,5 GHz CPU és 444 MHz GPU órajellel. Így talán nem csoda, hogy az ugyanannyi s.p.-vel rendelkező HD5570 444 MHz-en van egálban vele... Később majd lesznek tesztek desktop A8-3800/3850-nel is, szerintem igen közel lesz az 5570-hez OpenCL-ben.
2. Tisztázni kellene, mi a gyenge közepes. Szerintem nem kapásból HD5xxx-en belül kellene nézni, mert a piacon van még rengeteg korábbi generációs kártya is, ahol is a középosztály alja lejjebb volt még.
"Erre mondj mar legyszi egy valos peldat, mert mindig felhozzatok, de a gyakorlatban valahogy en meg nem lattam ilyet, csak a fusion marketing szovegben."
Nem hiszem, hogy ne tudnál elképzelni olyan helyzetet, amikor nem optimális a nagyobb csomagok cseréje a CPU és a GPU között, hanem kisebb csomagok jóval gyorsabb cseréjére van szükség.
(#64): Előtte is, utána is láttam több-GPU-s eredményeket, szal szerintem átmeneti bug lehetett.
-
lenox
veterán
Probald meg mainconcepttel. Bar az interaktiv alkalmazasban nem tudom, mennyi lehetoseg van, a low level apiban ugyanazt lehet csinalni, mint az x86 verzioban.
Az x264 amugy meg eleg jo, szoval minosegben jobb nemigen lesz, csak gyorsabb. A mainconcept 1080p-t 50 fps felett tud max minoseggel, de ossze meg sosem hasonlitottam. -
Abu85
HÁZIGAZDA
A minőség nem a CUDA vagy az OpenCL reszortja, hanem az algoritmusé. A CUDA-ra írt transzkódolók többsége azért annyira gyors mert feláldozza a minőséget, de meg lehet írni úgy, hogy a minőség legyen a szempont, csak akkor lassabb lesz. Az Arcsoft MediaConverter7 x86-on és OpenCL-en közel ugyanazt a minőséget kínálja. A CUDA a programon belül megmaradt gyorsnak gyenge minőséggel.
-
Abu85
HÁZIGAZDA
válasz
Dr. Akula
#57
üzenetére
Az NV PhysX az a CUDA felületen működik. Senki sem támogatja a CUDA felületet az NV-n kívül. Az OpenCL-t minden gyártó támogatja. Az AMD-től nem hiszem, hogy el kellene várni, hogy teszteljék az Intel procikra a drivert, hiszen nem az Intel helyet akarják elvégezni a munkát. Az NV-től sem várja el senki, hogy a PhysX társkártya működését teszteljék Radeon mellett. Felajánlották anno az AMD-nek, hogy mehet a hivatalos társ-GPU, ha tesztelik a működést, de az AMD nyilván hülye lett volna belemenni ebbe.
Az AMD-nek most a célja, hogy valamilyen szinten működjön a driverük az Intel procikon, és használj APP SDK-t, ha OpenCL programot készítesz. Az AMD saját fejlesztőkörnyezete pedig biztos, hogy nem Intelre optimalizál. Hasonló a helyzet az Intel C fordítójához. Az sem AMD-re optimalizál. Most annyi a különbség, hogy a gyártók szerepe felcserélődött. Az Intel azért dolgozik olyan gyorsan az OpenCL SDK-n, mert a heterogén éra elkerülhetetlen, és tényleg fel kell mutatni valamit, különben az Ivy Bridge megjelenésére lesz egy csomó AMD-re optimalizált program. Ez nagyon nem jó dolog. -
lenox
veterán
Ha egy program fel van rá készítve, hogy több GPU device-t használjon
Megy mar amd-n a tobb gpu device? Utoljara mikor neztem meg azon szomorkodtak, hogy barmelyik gpu device-t valasztod, mindig a 0-st hasznalja, vagyis nem megy tobb gpu-n egyszerre. Ez mondjuk ha jol emlekszem decemberben volt, szoval akar mehet is azota, de amugy erdekes, nvidian mar tobb mint 5 eve mennek a tobb gpu-s kodok.
-
lenox
veterán
??? Igen, gondolom, miert, neked mit jelent az, hogy egy downclockolt ddr3-as 5570 teljesitmenyet hozza egy szintetikus tesztben? Nekem azt, hogy egy low end vga-val van egalban. Ugyhogy egy gyenge kozepestol (pl 6570/6670) mar kikap. Ez amugy benne van a korabban linkelt anandos vagy vreveal-es eredmenyekben is. Es ha jol emlekszem atlagban meg egy 6450 teljesitmenyet tudja, az meg 160 sp-s.
És vannak olyan feladatok is, ahol a CPU és a GPU közötti gyors kapcsolat is kiemelten fontos.
Erre mondj mar legyszi egy valos peldat, mert mindig felhozzatok, de a gyakorlatban valahogy en meg nem lattam ilyet, csak a fusion marketing szovegben.
-
Raymond
titán
Gondolod?
A kep amit linkeltel bizonyitja hogy van oka ra amiert azt gondolja (vagy inkabb tudja). Az 5570 egy 444Mhz lejebb huzott valtozata latszik rajta es ezzel mutat egyenlo teljesitmenyt a tesztben szereplo Llano. Az 5570 alapbol 650Mhz-en jar es messze nem a "gyenge kozepes" kartya, per pillanat ez a masodik legszarabb amit az AMD kinal az 5450 utan.
-
dezz
nagyúr
válasz
Dr. Akula
#57
üzenetére
Azt a részt én egy kicsit erősnek tartom. Nyilván nem fogják a végletekig optimizálni Intel CPU-kra, de szerintem abban nem érdekeltek, hogy egyátalán ne fusson, mert az az OpenCL-nek is keresztbe tenne és az ő nimbuszukat sem növelné. Azt sem árt szem előtt tartaniuk, hogy egyelőre mégis csak az Intel a domináns CPU fronton, és még mindig jobb, ha AMD VGA-t tesznek mellé.
De amúgy is botorság, hogy csak annyit érne, hiszen az OpenCL nyílt szabvány, nincs az AMD-hez kötve, előbb-utóbb az Nvidia és az Intel is előáll a hivatalos, nem beta 1.1-es drivereivel. (Már ami az x86(-64) platformot illeti, mert máshol is van OpenCL.)
"Ismerve a jelenlegi AMD procik "csodálatos" teljesítményét az Intelhez képest"
Ne zavarjon, hogy ezzel az előző gen. Intelt is lesimfölted. Fölösleges állandóan ilyen bicskanyitogatóan fogalmaznod. Már ha nem ebben leled minden örömödet -- akkor csak rajta, nem akarom ez is elvenni tőled...
-
Dr. Akula
félisten
az AMD külön kiemeli, hogy az OpenCL 1.1-es meghajtó működését csak a saját processzoraira teszteli, így ha egy program a driver hibájából nem, vagy hibásan, illetve esetlegesen lassan fut az Intel CPU-in, akkor ezzel kapcsolatban nem érdekeltek a javítás elkészítésében.
Akkor ez is csak annyit ér mint az nvidia only physx. Szart se. Pedig jó ötletnek tűnt. Ismerve a jelenlegi AMD procik "csodálatos" teljesítményét az Intelhez képest, nyilván nem fogok ezért AMD-re butítani. Meg gondolom sokan mások se.
-
dezz
nagyúr
Ha egy program fel van rá készítve, hogy több GPU device-t használjon, akkor több GPU-t fog egyszerre kihasználni. Bár remélem, valahogy meg lehet különböztetni az APU-t a diszkrét GPU-tól, mert ugye komoly előnye tud lenni a shared memóriának.
(#31) lenox: "Szoval opencl-ben megveri a llano az sb-t, de egy gyenge kozepes grafkartyatol mar kikap."
Gondolod?
Nyilván a 400 s.p.-jével nehezen lenne erősebb egy 800 s.p.-snél. Ez persze feladatfüggő is, valahova a max. throughput kell (kevés számolás -- sok memóriaművelet), máshol meg a számítási teljesítmény dominál. És vannak olyan feladatok is, ahol a CPU és a GPU közötti gyors kapcsolat is kiemelten fontos.
Eléggé nem mellékes, hogy eddig a legtöbb átlagos gépben ez a teljesítmény és feltételrendszer sem volt adott. A Llano remélhetőleg jelentősen hozzá fog járulni ezen arány javulásához, ami elősegíti az erre épülő szoftverek mind nagyobb számban való megjelenését, ill. a meglévők "feltorbózását".
-
Donor
tag
A felsorolt programok közül a NASTRAN az egy véges elem szoftver.pl ezt lehet vele csinákolni http://www.youtube.com/user/Constantinrender#p/a/u/2/v9D9XCHtcK8
Cserébe viszont baromi sok memória kell ha egy fickósabb modellen sűrű rácsozással szeretnél számolgatni.Ott egy darabig marad a cluster...... .Ja és nem NASTRAN hanem ANSYS... .
-
Abu85
HÁZIGAZDA
A Llanohoz viszonyítva nem számítanak combosnak. A Sandy Bridge IGP-jéhez képest combosak. Persze a beépítés extra költsége még az SB-hez képest sem érné meg sajna.
Akkor a nép majd Intelt vesz Intel IGP-vel. Idővel majd rájönnek, hogy mit jelent egy GeForce vagy egy Radeon. Az AMD és az NV itt lesz egy-egy új generációs APU-val.
Addig abból lehet kiindulni, hogy ezen a fórumon, én vagy te, vagy más vajon miért nem használ Intel GPU-t. ![;]](//cdn.rios.hu/dl/s/v1.gif)
-
-
#48
Abu85
HÁZIGAZDA
hugo chávez
#47
Abu85
HÁZIGAZDA
válasz
hugo chávez
#47
üzenetére
Igen, készülnek a játékok Bullett motorral. Talán nem lesz gáz, ha megemlítem a Max Payne 3-at és a Luciust.
-
#47
hugo chávez
aktív tag
eziskamu
#41
hugo chávez
aktív tag
Na igen, de, ha Intel cpu-t vennék, ahhoz már akkor inkább NV vga-t, mint AMD-t, persze, amennyiben valaki AMD cpu-t vesz, akkor ahhoz nyilván vga-ból is érdemes (és a jövőben egyre inkább érdemesebb lesz) AMD-t vennie
(#42) Abu85:
"Függetlenül ettől a lehetőség adott az IGP használatára, de nem számítanék túlzottan sok ilyen programra még 2012-ben sem."
Ez sajnos valószínű, bár ott van pl. a Bullet, amit, ha jól tudom, bárki ingyen beépíthetne, de tulajdonképpen csak arra voltam kíváncsi, hogy ilyen esetekben az NV drivere esetleg nem kavarna-e be, de akkor ezek szerint, csak a játékfejlesztőkön múlik, hogy mehet-e a fizikai móka IGP+cpu-n.
-
Abu85
HÁZIGAZDA
Most éppen milyen tény felett akarunk elsiklani?
Nem mondtam, hogy holnap fognak eltűnni. A gond azonban már most érezhető. A VGA-k előállítási költsége pengeélen táncol. Ha esik az eladás, akkor az anyagilag is nagyon fáj. Semmi gond azzal, hogy az IGP nem nyomja le a combos GPU-t. Az a gond, hogy a combos GPU beépítése aránytalanul drága.
Igazából a PC-s piac már nem olyan, mint régen. Nem a legózás megy, hanem egyben vesznek az emberek notit, netbookot, nettopot, egybegépet, miközben elenyésző lett a kiskereskedelmi alkatrészekből összerakott termékek piaca. Pont azért gáz az OEM-ek hozzáállása. Ha raknának a fenti kelendőbb gépekbe VGA-t semmi gond nem lenne, de a mocskok nem raknak, inkább a saját hasznukat nézik, mint a júzer érdekét.Májusban a Sandy Bridge IGP-jétől esett 30%-ot az eladás. Nyilván értesz hozzá, és tudod, hogy a rendszer hány sebből vérzik egy Radeonhoz vagy egy GeForce-hoz képest, de mit csináljanak az emberek, amikor ott vannak az üzletekben az összerakott gépek Radeon és GeForce nélkül.
Itt nem a marketing segít. Itt arról van szó, hogy a kelendő gépek esetében fel sincs kínálva a Radeon vagy a GeForce. Ezen csak az segít, ha integrálsz és felkínálod, mert arra várhatsz, hogy az OEM-ek beépítsék a VGA-t. Nyilván az NV sem viccből döntött saját processzor tervezése mellett, nagyon kockázatos projekt és messze nem olcsó, de integrálni kell, különben csak a jelentéktelen rétegpiacokat szerezheted meg. -
lenox
veterán
Marmint akkor mindegy, ha el akarunk siklani a tenyek felett
. Majd nezz vissza egy par topikot egyszer.
Egyebkent szerintem megint felreertelmezed a dolgot. Haldoklik a piac, de az nem azt jelenti, hogy a mar kifejlesztett termekek holnap megszunnek. Egyelore meg sok ido, amig nem lesz diszkret vga, es az is sok ido, ha lesz egyaltalan, hogy apuval lenyomnak a diszkret vga-kat. Addig meg mindegy milyen procit veszel, mindben gyenge az integralt vga, elkel melle egy diszkret vga. Es kb. mindegy, hogy intel/amd/nvidia. Mezei felhasznalasra meg az integraltak is jok, bar az amd jobb. Kerdes, mennyit er a marketing, tapasztalat szerint sokat. -
zörbi
csendes tag
Én nem is bánom ha bedől a diszkrét vga piac. Ha a legtöbb embernek mainstream VGA/integrált cucca lesz a játék gyártók legalább kénytelenek lesznek PC-re jobban optimalizálni. Ne adj isten előtérbe kerül a játékélmény a grafika helyett. A (ha jól tudom) 2006-os Company of Heroes óta nem fogott meg játék igazán. A szép grafika nálam csak 1-2 óra ámuldozásra elég, ha meg jó a játék tökmindegy a grafika. Akik játszottak anno a C64-es, 286-os időkben, tudják miről beszélek, nem kell szuperüber grafika hogy a gép elé ragassza az embert
RTS-t pedig muszály PC-re írni konzolon egy szenvedés ez a műfaj. -
#42
Abu85
HÁZIGAZDA
huskydog17
#39
Abu85
HÁZIGAZDA
válasz
huskydog17
#39
üzenetére
Igen oda kellene egy 10.12-es opencl driver. Akkor lesz OpenCL-es pipa is.
Ki kell próbálni a programot, hogy milyen terhelést mér a CPU-ra. Maga a post-process biztos, hogy a GPU-n dolgozik, azt hülyeség CPU-ra tolni.(#40) hugo chávez: Technikai akadálya nincs. Az adott program lehet akadály. A fejlesztők annyira nem rajonganak mostanában a fizika gyorsításáért. Annyi extrát ad, hogy a programban a fal 30 darab helyett 50 darabra törik. Ezt nem tartják túlzottan nagy extrának a játékélményben, hiszen vizuális effektusról van szó. A komplexebb, jobb lehetőségeket biztosító modellezéshez már saját fizikai motort kell írni, hiszen a licencelhető middleware-ek eléggé központosítottak. Úgymond alapszolgáltatásokat kínálnak, de az igazi innováció lehetősége nincs bennük. Függetlenül ettől a lehetőség adott az IGP használatára, de nem számítanék túlzottan sok ilyen programra még 2012-ben sem.
Ami az APU-k kapcsán előtérbe kerülhet az az AI áthelyezése az IGP-re. Főleg a stratégiai játékok húznának belőle előnyt. -
#41
eziskamu
addikt
hugo chávez
#40
eziskamu
addikt
válasz
hugo chávez
#40
üzenetére
Akkor viszont minek az nVidia
, Full AMD-vel tudnál tutira menni. -
#40
hugo chávez
aktív tag
Abu85
#17
hugo chávez
aktív tag
Abu, én arra lennék kíváncsi, hogy, ha lesz mondjuk egy gépem, amiben Ivy cpu és diszkrét NV videókártya van és van egy játék, amiben OpenCL-es fizikai motor van, akkor lesz-e annak akadálya, hogy (természetesen, amikor majd az Intel OpenCL drivere támogatni fogja az Ivy IGP-jét is) heterogén módon az Ivy cpu-ján és IGP-jén menjen a fizika?
-
#39
huskydog17
addikt
Abu85
#27
huskydog17
addikt
Köszi szépen a választ!
Amúgy nálam most 10.12 hajtja a kis Radeon HD 5470-et, de a GPU-Z azt mondja, hogy nincs OpenCL támogatás, csak DirectCompute 5.0. Ez gondolom az OpenCL driver hiányából fakad.
Vegyünk egy konkrét példát: a legújabb WinDVD (benne van a cikkben lévő listában) támogatja az OpenCL-t. Ez ennél a szoftvernél azt jelenti, hogy a Post Process effektek már a GPU-n zajlanak, igaz? Ha igen, akkor ennélfogva a CPU terhelés nem fog nőni (vagy nagyon minimális, elhanyagolható mértékben) ha bekapcsolom ezeket a képjavító funkciókat. A legjobb az volna, ha a Trimension is így futna (elvileg interpolációs technológia, hasonló, mint a Splash Pro-nál a Motion). Csak hogy míg a Splash Pro a Motion esetében hatalmas CPU terhelést generál, addig a WinDVD elvileg klasszisokkal alacsonyabb CPU terhelés mellett képes erre ha jól gondolom.
Javítsatok ki ha túl nagy hülyeséget mondtam!#26: Neked is köszönöm, főleg a linket!
-
Abu85
HÁZIGAZDA
Teljesen mindegy, hogy mi miatt van. A baj az, hogy drasztikusan csökken, és a piac nem tudja eltartani magát. Az AMD-féle Dual Graphics sem valami elképesztően nagy ötlet arra, hogy az eladások legalább egy kis részét megtartsák. Ez a piac durván haldoklik sajnos. A Llano csak egy újabb tőr benne. Az AMD nyilván nem akarja a végét a VGA-piacnak, de ugyanakkor reagálniuk kell arra, hogy az OEM gyártók nem akarnak GPU-t építeni a termékekbe.
Majd kiderül, hogy mi lesz a jövőben. Ha egy gyártótól kell mindenképpen választani, akkor egy dolgot tudok, hogy nem az Intel grafikát választom. -
lenox
veterán
-
#35
Abu85
HÁZIGAZDA
FireKeeper
#34
Abu85
HÁZIGAZDA
válasz
FireKeeper
#34
üzenetére
Nincs esély az 1.1-re. Nem alkalmas rá a hardver.
-
#34
FireKeeper
nagyúr
FireKeeper
nagyúr
radeon hd4000 esetében van esély az 1.1 támogatásra, vagy hardveresen nem tudja?
-
Abu85
HÁZIGAZDA
Igazából a dedikált GPU teljesen lényegtelenné vált. A gyártóknak a VGA beépítése olyan költséges, hogy hallani sem akarnak róla. Ezt az elmúlt héten az AMD is ecsetelte, hogy májusban globálisan 30%-kal kevesebb GPU-t adtak el, mint áprilisban. Erről hoztam is egy kínai piacon mért felmérést, ahol a visszaesés 40-45%. [link] ... nyilván az AMD adata globális, így más országokban lehet, hogy kisebb volt a csökkenés, és így reális is a 30%. Egyszerűen a gyártók hozzáállása gáz. Látják, hogy egy dedikált VGA-t beépítve kisebb a terméken a haszon, és ezt elég nagy problémának élik meg.
Mivel a PC is úgy alakul, hogy előtérbe kerülnek az előre összeszerelt gépek, így a vásárlások zömét nem a legózó vásárlók teszik ki, vagyis az OEM gyártók akarata nagymértékben kihat a piacra. Innentől kezdve nincs Sandy Bridge+GPU és Llano. Van Sandy Bridge és Llano, a GPU kizárva a versenyből.Most valami óriási reform kell a VGA-knál, mert a piac igényei így nem megfelelőek, vagyis felesleges fenntartani a piacot.
-
lenox
veterán
Arra mondjuk kivancsi lennek, hogy cpu device kell nekik, vagy van cpu-s kod is. Pl. a mainconceptnek eleg husszu ideje van cpu-s kodja, szerintem a cpu-ra irt kodjuk gyorsabb a cpu device-on futtatott opencl kodnal, csak mert par eve mar van optimalizalva. Ez kulonben altalaban is igaz.
Kulonben lassan egyre kezzelfoghatobban latszik, hogy dedikalt gyors memoria nelkul eleg gyenge teljesitmenyt nyujt a gpu vagy apu, ahogy egy paran mar mondogattuk jo ideje. Szoval opencl-ben megveri a llano az sb-t, de egy gyenge kozepes grafkartyatol mar kikap. Na mind1, mint egy masik topikban is irtam, lassuk a teljes palettat arakkal, meg legyenek tesztek, aztan kiderul, hogy minek hol a helye. Mindenesetre felrevezetesnek erzem, amikor az a mondas, hogy Llano-val verjuk az SB-t, de egy par eves olcso cpu+vga kombo veri mindkettot ugyanabban. Pl. vreveal, azt ugye nem irtak oda, hogy a cudat mar regota tamogatjak, es diszkret vga-val sokkal gyorsabb
. -
-
#27
Abu85
HÁZIGAZDA
huskydog17
#22
Abu85
HÁZIGAZDA
válasz
huskydog17
#22
üzenetére
A fő szempont az OpenCL driver. Ez általában a GPU-ra fontos. Ha van az adott programhoz jó OpenCL driver, akkor elméletben működnie kell. Nyilván Radeonra az AMD driverét használd, míg GeForce-ra az NV-ét. Ha nem működik, akkor az lehet attól, hogy a driver még nem támogatja azt a kiterjesztést, amit a program használ, vagy szimplán valami hiba van.
Egyes programokat már heterogén módon írnak, így a GPU mellett a CPU-n is fut. Ilyenkor olyan driver kell, ami támogatja a CPU-dat és a GPU-dat is egyszerre. Ha ez nem áll fenn, akkor a program nem fog heterogén módon futni. Minden működni fog, ha megfelelő a driver, de nem biztos, hogy a leggyorsabban.Le lehet tölteni külön. Ott van az individual fülön belül. Ara kell ügyelni, hogy a 11.5-ös OpenCL driver a 11.5-ös Catalysttel tesztelt. A mixelés korlátozottan lehetséges.
Pontosan úgy működik. A dekódolást a fix hardver csinálja, míg a többit a programozható rész.
A heterogén mód a rendezvényen a sebesség szempontjából volt kihangsúlyozva. A gyorsulás teljes mértékben az adott program függvénye. Például a ViVu termékei esetében számottevően jobb eredményre volt képes egy APU, mint egy GPU önállóan. -
#26
FireGL
aktív tag
huskydog17
#22
FireGL
aktív tag
válasz
huskydog17
#22
üzenetére
Amíg az OpenCL-ben írt programoknak ez lenne a lényege, addig a működésükhöz szükséges driver(ek) gyártófüggőek. Ez is le is van írva a cikkben, és már rohadt sokszor volt erről szó.
Az AMD-től tudsz olyan olyan Catalyst drivert is letölteni amiben benne van, tudsz olyat is amiben nincs, és magát az OpenCL drivert is külön le tudod tölteni ha kell.
http://sites.amd.com/us/game/downloads/Pages/radeon_win7-64.aspx#2
-
#24
vinibali
őstag
huskydog17
#22
vinibali
őstag
válasz
huskydog17
#22
üzenetére
van APP-s és nem APP-s AMD driver, szerintem csak úgy magában nem lehet leszedni, értelme sincsen nagyon
mindenesetre nagyon erősnek hangzik az AMD "előnye", legalábbis nagyon jó dolog hogy már kiadtak egy olyan komplett platformot ami támogatja. viszont nagy csend van az Intelnél, szerintem nagy bombát készítenek -
#22
huskydog17
addikt
Abu85
#21
huskydog17
addikt
Nekem az OpenCL körüli mizéria nekem nem teljesen világos, így remélem megengedsz néhány kérdést ezzel kapcsolatban.
Maga a programnyelv gyártófüggetlen, vagyis minden OpenCL-t támogató grafikus processzoron működniük kell az ebben a nyelvben írt szoftvereknek. Eddig világos. Akkor hogy lehetséges az, hogy egy ilyen szoftver egy OpenCL-t támogató GPU-n nem, vagy csak korlátozott mértékben működik? Nem az volna a programnyelv lényege, hogy az ebben írt programok minden támogatott GPU-n ugyanolyan jól működjenek?Az OpenCL driver az AMD esetében magában a Catalyst meghajtóban van elhelyezve vagy esetleg külön is le lehet tölteni és telepíteni?
Egy OpenCL-t támogató videolejátszó úgy működne, hogy a film dekódolását az UVD/VP motor végzi és a Post Process effekteket pedig a GPU stream processzorai végzik?
Annak, hogy egy OpenCL szoftver heterogén módon üzemel, pontosan mik az előnyei a gyakorlatban?Elnézést kérek a sok kérdésért, de szeretném tisztázni magamban ezt a dolgot!
-
Abu85
HÁZIGAZDA
A felsorolt programok mind Fusion optimalizációt kapnak, így a leggyorsabb feldolgozáshoz kell nekik a CPU device. Ezt mutogatják éppen az AFDS-en, hogy mennyit gyorsít rajtuk a heterogén mód a csak GPU-s kódhoz képest.
Természetesen ahol nem érhető el a CPU-s OpenCL device ott is fut majd a program, csak nem heterogén módban.Lesz olyan OpenCL program is, ami csak GPU-s OpenCL. Például a vReveal MotionDSP 3 is kint van, csak az nincs benne az AMD listájában, mert nem heterogén módon dolgozik. Hivatalosan nem is volt róla bemutató, csak megjegyezték, hogy létezik, GPU-s OpenCL és kész. [link] - szimplán ennyi volt a lényeg, hogy a Llano az SB-nél sokkal gyorsabb. Semmi extra.
-
HeavyToys
senior tag
Persze, ezt gondoltam. De ennél a kis teljesítményű rendszernél, sokat segíthet, például filmvágásnál, vagy bármilyen számítás igényes műveletnél, ha plusz számítási kapacitás áll így rendelkezésre. Talán még jobban észrevehető, mint egy amúgy is lényegesen erősebb CPU-résszel rendelkező egységnél.
-
Harlek
tag
"... az viszont biztos, hogy az NVIDIA nem fogja támogatni az AMD és az Intel processzorokat a meghajtóin keresztül."
Elnézést kérek az értetlenkedésért, de itt most az AMD és az Intel GPU-iról van szó, vagy CPU-iról? Mert ha GPU, azt tökéletesen megértem, de ha egy OpenCL Driver nem hajlandó biztosítani az AMD/Intel CPU és Nvidia GPU közötti munkát, akkor mi értelme a dolognak? Meg nem mintha lenne túl sok alternatíva CPU tekintetében.
-
#12
KevinMulder
tag
Ringman
#4
KevinMulder
tag
Igen. Az OpenCL főleg arra jó, amikor ugyanazon műveletet kell elvégezni egy adott memóriablokk elemein. Pl add össze az n és az m tömbök tartalmát,
z=n(i)+m(i) ahol i=0..255
Egy órajel alatt 256 összeadás, stb.OpenCL nem nagyon tolerálja az elágazásokat, mert a magoknak egyszerre kell futniuk. Ilyenkor az egyes ágak egymásra várnak.
-
#8
Petike1007
tag
Petike1007
tag
Jó ez...csak élhetné már a fénykorát
-
Stirlitz
senior tag
Örülök, hogy megjelent pár új program, de ez még mindig kevés. Fájdalmassan lassan terjed a technológia. Szakértőket kérdezném, elképzelhető-e az idővel, hogy diszkrét vga mellett, a prociba integrált vga mondjuk bonyolultabb fizikai modellt számoljon egy játékban pl?
Most vagy a fejlesztők is hülyének nézik az embert, vagy ez a technika tényleg nem a minőségről szól, csak én éltem álomvilágban 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Te a kivétel vagy, aki erősíti a szabályt. 
Itt nem a marketing segít. Itt arról van szó, hogy a kelendő gépek esetében fel sincs kínálva a Radeon vagy a GeForce. Ezen csak az segít, ha integrálsz és felkínálod, mert arra várhatsz, hogy az OEM-ek beépítsék a VGA-t. Nyilván az NV sem viccből döntött saját processzor tervezése mellett, nagyon kockázatos projekt és messze nem olcsó, de integrálni kell, különben csak a jelentéktelen rétegpiacokat szerezheted meg.
Remekbe-szabott cikk 
Új hozzászólás Aktív témák
Hirdetés
- Az NVIDIA és az AMD leadja a kínai chipeladásokból érkező bevétel 15 százalékát
- Debrecen és környéke adok-veszek-beszélgetek
- Fejhallgató erősítő és DAC topik
- Hegesztés topic
- Kerékpárosok, bringások ide!
- PROHARDVER! feedback: bugok, problémák, ötletek
- Korábbi vezetője szerint 40 milliárd dollár kell az Intel versenyképességéhez
- Házimozi belépő szinten
- Alkoholista nevelde
- iPhone topik
- További aktív témák...
- AKCIÓ! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Intel core I7 8700k
- Intel Core i7-10700 8-Core 2.9GHz LGA1200 (16M Cache, up to 4.80 GHz) Processzor!
- AKCIÓ! AMD Ryzen 7 3800X 8mag 16szál processzor garanciával hibátlan működéssel
- Új,bontatlan,dobozos, számlás,garanciás 7800X3D CPu.
Állásajánlatok
Cég: FOTC
Város: Budapest