Új hozzászólás Aktív témák

• #9 Abu85 HÁZIGAZDA DigitXT #6

  Új Válasz 2012-12-10 18:06:09 #9

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz DigitXT #6 üzenetére

  Az átlagember nem fog sosem saját PC-t összerakni, telepíteni, bekonfigurálni, megvenni a működéshez szükséges szoftvereket, és a többi időigényes dolgot elintézni. Ezért kell beágyazott rendszerként gondolni erre. Egyszerű, gyorsan beüzemelhető, és komoly karbantartást nem igénylő termék kell a vásárlók 95%-ának. Az, hogy neked, vagy a PH hardcore közösségének nem kell a gyártók szemszögéből lényegtelen, mert mi az elhanyagolható kisebbséget képviseljük. Nagy volumenben értékesíthető, akár 3-4 évet is lehúzó termék kell a népnek, mindezt a lehető legegyszerűbben kezelhető szolgáltatásokkal tálalva. Mindezek mellett rugalmasnak kell lennie, hogy az átlag igényeknek tökéletesen megfeleljen. Gyakorlatilag egyre inkább úgy tűnik, hogy a Post-PC érát a PC-s élményt kínáló gépek képviselik majd beágyazva.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

• #115 Abu85 HÁZIGAZDA quailstorm #103

  Új Válasz 2012-12-11 17:25:37 #115

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz quailstorm #103 üzenetére

  Nézd meg Kína nagy volumenű GPU rendelését. Az AMD-vel kötöttek meg egy 10 millió VGA-ra vonatkozó tendert az elkövetkező hónapokra. Az indok, amiért az NV-t dobták a Linux támogatása volt.
  A Linux terméktámogatása minden cégnél alacsony fókuszt képez. Egyszerűen egy maréknyi júzerért nem éri meg az átlagosnál jobban törni magukat. Persze vannak célterületek, amit a piaci szempontok miatt jobban fejlesztenek. Az NV például a CUDA-t eléggé fejleszti Linuxra, míg az OpenCL támogatásuk ezen az OS-en teljesen használhatatlan. Az AMD az OpenCL-t nagyon fejleszti Linuxra, szinte azonos időben jelennek meg az újítások, mint a Windows driverben. Ezek itt üzleti szempontok, mivel bizonyos a területeken sok pénz van, és ezért az átlagosnál nagyobb munkát raknak bele a cégek.
  Ha lesz egy olyan gép, ami Linuxot használ, és potenciálisan eladható belőle minimum 5 millió termék, akkor azért már megéri támogatást csinálni. Itt a kulcs a felhasználóbázis. Kevés felhasználó, kevés pénz = kicsi fókusz. Sok felhasználó és nagy pénz = komoly fókusz. Ezek a dolgok sosem véletlenek. Ott van például az a terv, hogy az AMD a beágyazott rendszereket célozza az új APU-kkal, és itt akarnak növekedni. Ennek az eredménye, hogy hamarabb jelent meg az APP 2.8-as runtime Linuxra, mint Windowsra, illetve már egyéni drivereket is lehet rendelni a termékekhez. Ugyanez az NV-nél fordítva. Nulla esélyük van bekerülni erre a piacra, amit az AMD kinézett. Kb. nulla is befektetésük ebből a szempontból, lásd nincs érdemben működő OpenCL-jük Linux alatt. Szimplán az a különbség, hogy az egyik oldalon lehet belőle pénz, így megéri befektetni, míg a másik oldalon nulla a várható bevétel, így minek törjék magukat.
  A támogatás minőségét mindig az határozza meg, hogy mennyi a felvásárlóbázis. Az otthoni Linux azért képez kicsi fókuszt, mert egy maréknyi júzer az egész, akik ráadásul átlagos árat fizetnek a hardverekért. A beágyazott rendszer sem sok vásárlóbázis, de ez be van kalkulálva az árba. Egy E2-1800 listaára 50 dollár körül van. Egy vele majdnem megegyező AMD G-T56N listaára 140 dollár. Az egész lapka tök ugyanaz, de utóbbinál kifizettetik veled az 5 éves terméktámogatást. Ezért adnak hozzá külön drivert Linuxra.
  Ha a Valve AMD-t akar a rendszerbe, akkor megvizsgálják, hogy mennyi eladás lehet a gépből, és ha jónak tartják, akkor megcsinálják amit kérnek. Ha úgy gondolják, hogy nagy a kockázat, vagy valami az üzlet ellen van, akkor visszamondják. Máshol is így működik. Nyilván a Steambox az nem egy Wii, Xbox vagy PS kaliber, szóval ott tényleg figyelembe kell venni, hogy lesz-e elég eladás, ergo nincs automatikusan igen a felkérésre. Maximum akkor, ha a Valve megelégszik az elérhető hardverekkel, és nem akarnak egyéni dizájnt.

  (#114) quailstorm: Rakja fel hozzá a Windows 8 drivert. Nem nehéz ezt letölteni és telepíteni.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

• #119 Abu85 HÁZIGAZDA joysefke #113

  Új Válasz 2012-12-11 17:41:46 #119

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz joysefke #113 üzenetére

  Szerintem a Steambox OS attól függ majd, hogy mennyien készítenek Linux portot a játékból. Ha kevesen, akkor mindenképpen maradni kell a Windowsnál. Az emuláció szerintem kizárt, túl lassú megoldás. Esetleg azt tudom elképzelni, hogy ha Linux és az adott játékra nincs port, akkor azt felhőből kell futtatni.

  Ami látszik, hogy a Mac sokkal elterjedtebb, mint a Linux, de így is kb. szarnak bele a fejlesztők a Mac portokba. A Steamen elérhető játékok ötöde érhető el Mac-ra. Ez 334 játék. Linuxra 30 játék érhető el. Egyszerűen mindkettő kevés.

  Értem én a Valve-ot, hogy a Windows 8 maga az ördög, mert ott a beépített store, de ez nem győzi meg a fejlesztőket, hogy Linuxra márpedig érdemes portolni.

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

• #126 Abu85 HÁZIGAZDA quailstorm #117

  Új Válasz 2012-12-11 20:06:25 #126

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz quailstorm #117 üzenetére

  Szerintem eleve ez a Steambox elképzelés csak úgy működőképes, ha bármilyen OS-re építve egy szabvány API mellé írnak egy sajátot. Ezzel a mai szabvány API-k legnagyobb problémája kiüthető, így sokkal jobb grafika biztosítható a Steamboxra fejlesztett játékoknál. Más szempontból nincs lényegi értelme, mert az elején kicsi az install bázis, vagyis semmiképp sem lehet exkluzivitásra építeni, maximum akkor, ha bevállalják a gép masszív veszteség mellett való árulását. De az a baj, hogy ez nem egy Samsung holmi. Erre max. Valve lesz írva, amit alig ismer az átlagember.

  A piactér lényegtelen. Ha Windows fut mondjuk rajta, akkor gyakorlatilag egy extra store-ba kerül a program, de komoly módosításra nincs szükség.

  Ott van benne, hogy Radeon HD 4000. Abba beletartozik a HD 4450 is.

  (#120) marcias: Persze, a Steam szolgáltatási sokkal jobbak. De a Windows Store integrálva jön a Windows 8-cal. Ez a probléma. Ez olyan, mint az Internet Explorer effektus. Minek a másik böngésző, ha van már telepítve.

  (#121) joysefke: Semmi sem fogja őket motiválni. A Macre portolást sem tartják túl fontosnak, pedig az egy viszonylag nagy és kifejezetten fizetőképes réteg.

  A Steambox csak úgy életképes, ha a szabvány grafikus API-k mellé raknak egy sajátot is, amit a fix hardverhez illesztenek. Ez az egyetlen, amiből előnyt lehet kovácsolni.

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

• #129 Abu85 HÁZIGAZDA djgeg #127

  Új Válasz 2012-12-11 20:27:25 #129

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz djgeg #127 üzenetére

  Nem hiszem, hogy megéri az exkluzív cím az elején. Azért szerintem a Valve sem számít 1 milliónál nagyobb kezdeti eladásra. De nem is kell exkluzív cím, csak valami extrák kell felmutatni. Mondjuk jobb grafika. Mivel ezt PC-n erősen korlátozza a szabványos API, így a Steambox egy saját, célhardverre fejlesztett API-val sokkal jobb eredményekre lenne képes.

  (#128) dabadab: A Wine az nem igazán emuláció. Lehet olyan gyors, mint a Windows, vagy gyorsabb is, bár ez sok dologtól függ. Viszont egy játéknál kapásból meg kell oldani a DirectX API támogatását. Ez a Wine esetében jelenleg a 9-es verzióig van maradéktalanul megoldva. A DX10-es és főleg a DX11-es játékok már szenvednek. Két három éves késéssel persze meg lesz oldva a Wineban is a támogatás, csak ez nem az a szint, amire egy átlagjúzer vágyik.

  Nem olyan nagy dolog ez. Az OpenGL-t alapnak veszik és kivágnak belőle részeket, ami a célhardver miatt nem szükséges, ugyanakkor jelentősen gyorsít az API működésén. A driver kifejezetten gyorsan kész lenne egy ilyen koncepcióra. Az Xbox 360 és a PlayStation 3 API-ja is egy módosított szabványos megoldás. Lényegében abban különböznek a PC-s társaiktól, hogy teljesen ki vannak vágva belőlük a bonyolult erőforrás-ellenőrzést igénylő rutinok és direkten kezelhető a parancspuffer. Ugyanezt a Valve is megcsinálhatja. Roppan egyszer, és a hatás óriási. Kivágod az API-k legnagyobb problémáját, vagyis az overheadet.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

• #146 Abu85 HÁZIGAZDA dabadab #136

  Új Válasz 2012-12-12 10:29:05 #146

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz dabadab #136 üzenetére

  Nem biztos, hogy a procierővel a next gen játékokban sokat lehet majd nyerni. Jelenleg az az erős pletyka járja, hogy a Thebe-J lesz a PS4 alapja, és most lesz kész. Amit egyöntetűen mondanak az a Jaguar processzormag (ez egy Bobcat utód, vagyis kb. Atom szintű - jó annál azért gyorsabb, de a behatárolással ebbe a kategóriába lehetne elhelyezni). Ugyanez a pletyi az új Xboxra, csak a magok száma kérdéses. A Jaguar a nagy magokhoz képest elég gyenge önmagában, viszont a fejlesztési irány szempontjából a fejlesztőkkel közösen úgy döntöttek a next gen konzolokat tervező emberek, hogy a központi processzor helyett az integrált GPU jobb kihasználását helyezik előtérbe. A Nintendót is szívatják, hogy gyenge a Wii U procija egy next gen géphez képest, volt nemrég egy előadás, hogy ez igaz lehet, de sokkal erősebb a GPU, mint amit eddig egy konzolba beleraktak. Lényegében az üzenet az, hogy ha nem megy procival, akkor ott a GPU. Hamarosan lesz hozzá speciális OpenCL SDK.
  Angelo Pescének volt nemrég egy előadása, hogy az egész eddigi játékfejlesztési irányt újra kell értelmezni. A GPU compute a kulcs az innovációhoz. Nem tudom, hogy mennyire publikus az előadása, de két képet berakok, hogy merre mehet az egész: [link] ; [link]

  Ezeket az irányokat látva egy játékra kihegyezett rendszernél nem lesz hátárnya az NV-nek, ha a /mag teljesítmény nem lesz toppos. Nem ebből fog jönni a sebesség.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

• #148 Abu85 HÁZIGAZDA marcias #147

  Új Válasz 2012-12-12 12:24:05 #148

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz marcias #147 üzenetére

  Szerintem egyértelmű, hogy ezzel az iránnyal a régi grafikus API-k helyett újakat hozunk be, amelyek másképp működnek. A next gen konzolokhoz akár készülhet egy ilyen. Még az is lehet, hogy az MS és a Sony közös alapokat használna, hogy egyszerűbb legyen a portolás. Ez nem egyszer felmerült, hogy a fejlesztők munkáját meg kell könnyíteni egy ekkora reform során. A konzoloknál ez egyszerű, mert a gépet úgyis az exkluzív címek adják el, ami közös alapok mellett is megmarad.
  Van az egészre egy megoldás. A fejlesztő oldaláról két dolog a fontos. A sok hardvertől függetlenül egyszer kelljen megírni a kódot, de ugyanakkor az API overhead legyen sokkal alacsonyabb. Erre jó opció egy közös virtuális ISA-ra épített API. Amiben meg kell egyezni az a vISA. Jelenleg az Intel és az NVIDIA nem szeretné ezt az irányt. Az Intel azért, mert a jelenleg kifejlesztet GPU megoldásaik messze el vannak maradva a konkurenciától, amire gyorsan vásároltak egy ZiiLabs-ot, de az is idő lesz, mire abból alkotnak valamit (addig van egy elavult alapokra épített HD Graphics, és egy Larrabee/MIC, amiről már látszik, hogy zsákutca). Az NV pedig azért, mert nekik az lenne a jó, ha a CUDA mögé állnának be a cégek, és nem egy nyílt, gyártófüggetlen szabvány lenne erre. A cégek viszont nem akarnak a CUDA mögé beállni, így inkább a HSA felé közelítenek. Ennek egyetlen oka az, hogy amíg a CUDA zárt és konkrétan egy konkurens cég fejleszti, addig a HSA nyílt és egy kiszervezett alapítvány fejleszti. Utóbbi nem kockázatos, mert minden érintettnek beleszólási joga van a fejlesztésbe.
  Korábban már volt róla pletyka, hogy a Microsoft a HSA nyolcadik alapító tagja, csak még nem jelentették be. Ha a HSA-ra lenne írva egy új grafikus API, akkor az egész kérdés eldőlne, és mindenki belépne, aki még akar valamit ebben a szegmensben.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Új hozzászólás Aktív témák