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

• #36 Abu85 HÁZIGAZDA julius666 #35

  Új Válasz 2011-08-25 10:37:20 #36

  Ú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 julius666 #35 üzenetére

  Pontosa ezt emelték ki az előadáson, hogy a GPU és a CPU heterogén módon történő kihasználásával ez lehetségessé válik. Most ezt hiába tudod megcsinálni elméletben, a gyakorlatban nem fog működni, mert nincs meg a teljesítmény.

  [ Szerkesztve ]

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

• #49 Abu85 HÁZIGAZDA julius666 #47

  Új Válasz 2011-08-25 15:14:36 #49

  Ú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 julius666 #47 üzenetére

  WebCL. Erről is beszélt az ARM. Az okostelefonok proci része erősödik ugyan, de nagyon messze van a PC-s szinttől. A WebCL-lel ez a probléma is megoldódik. Úgy gondolják, hogy 2013-tól már elterjednek azok a webes szabványos, amelyek főleg a GPU-t terhelik. A CPU csak kismértékben határozza azután meg az internetes megjelenítés sebességét. Mint "Javascript leváltó" a WebCL ebben komolyan benne lesz. Legalábbis az ARM szerint.

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

• #51 Abu85 HÁZIGAZDA julius666 #50

  Új Válasz 2011-08-25 16:22:13 #51

  Ú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 julius666 #50 üzenetére

  A hang- és gesztusfelismerést át lehet ültetni a weboldalakra is. Ezen dolgozik az ARM. Az új generációs fórummotorok esetében ez komoly lehetőségeken nyitna meg. Természetesen ennek részesei leszünk PC-n is, hiszen szabványszinten ez az egész átkarolja az összes terméket. A CPU tehermentesítését pedig a mobil piacon egyértelműen sürgetni kell. Az IGP energiatakarékosabban dolgozza fel a webes tartalmakat. Ez már most kimutatható, később a szabványok finomodásával jobb lesz. Mobil terméknék az üzemidő szempontjából nem mindegy, hogy a CPU, vagy az IGP lesz túráztatva.

  [ Szerkesztve ]

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

• #53 Abu85 HÁZIGAZDA julius666 #52

  Új Válasz 2011-08-25 17:15:41 #53

  Ú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 julius666 #52 üzenetére

  Dehogynem alkalmas rá. A Youtubeon a videót ki nézi teljesen procival? Sokkal többet fogyasztana, mint a GPU-k erre felkészített feldolgozómotorjával. GPU-val még post-processre is van lehetőség, ha szeretnéd. Ezt már ma is ki tudod használni, nem a jövő webtartalma, és az akkuidőben durván meg fog látszani a különbség.

  A WebCL másra kell, például a javascript helyébe léphet, az ARM szerint erre nagy esély van (az akkuidő miatt a javascript nem kellemes jelenség az netes tartalomban, de jelenleg nincs alternatíva). Képzelj el például egy webes, fejlett fényképszerkesztőt.
  A Nokia már kísérletezik a WebCL-lel. [link] - Az FF6-hoz tölthető egy kiterjesztés, amivel már bárki dolgozgathat.

  [ Szerkesztve ]

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

• #56 Abu85 HÁZIGAZDA julius666 #55

  Új Válasz 2011-08-25 17:59:27 #56

  Ú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 julius666 #55 üzenetére

  Pont erről beszél az ARM is. A számításigényes feladatok minek terheljék a CPU-t, amikor a GPU kisebb erőforrásigényből megoldja, és ezzel még akkuidőt is nyertél.

  Éppenséggel a Direct2D és a DirectDraw gyorsítás pont, hogy általánosan előnyös a fogyasztásban. Ez is kihasználható már pár oldalon. Minél több HTML5-ös oldal lesz, annál kevesebb fogyasztást fog igényelni azok megjelenítése, ha azokat GPU-val gyorsítod.

  Az ARM víziója szerint az eszközöd állandóan a netre csatlakozik, vagyis azok a programok, amiket jelenleg még külön böngésző nélkül futtatsz átkerülnek a webre. A webalapú programok jelentik a vállalat víziójában a jövőt. Minél jobban el kell osztani a terhelést a SoC-on belül, egy APU jó kihasználásával üzemidőt nyersz.

  [ Szerkesztve ]

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

• #58 dezz nagyúr julius666 #55

  Új Válasz 2011-08-25 18:17:05 #58

  Ú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

  

  dezz

  nagyúr

  válasz julius666 #55 üzenetére

  Szerinted 10 év múlva is ilyen flat (szöveg+pár kép) lesz a net?

  (#57): "a CPU pedig önmagában jellemzően kevesebbet zabál adott idő alatt"

  Ez csak akkor igaz, ha egy sokszoros peak FLOPS teljesítményű GPU hasonlítasz egy CPU-val. Viszont adott fogyasztás mellett is többszörös peak FLOPS teljesítményű a GPU. A többi már csak azon múlik, hogy az adott feladat mennyire fekszik a GPU-nak, azaz mennyit lehet kihasználni a peakből a gyakorlatban. Ebben nagyon sokat fejlődtek a GPU-k az elmúlt években és ma is nagy léptekkel halad a dolog.

  "A jelenlegi GPU-gyorsított enkóderek mindenesetre nagyon ganék."

  Elsősorban a sebességre mentek rá, de azt hiszem, létezik profi, minőségi megoldás is.

  [ Szerkesztve ]

• #61 Abu85 HÁZIGAZDA julius666 #59

  Új Válasz 2011-08-25 18:34:39 #61

  Ú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 julius666 #59 üzenetére

  Már hogyne lenne köze. A PH-t hogyan tudod gyorsítani GPU-val? Nem sok ilyen tartalom van rajta. A HTML5-ön belül viszont számos olyan tartalmat használhatsz, ami GPU-val gyorsítható.

  [ Szerkesztve ]

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

• #62 dezz nagyúr julius666 #60

  Új Válasz 2011-08-25 18:35:59 #62

  Ú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

  

  dezz

  nagyúr

  válasz julius666 #60 üzenetére

  Miből gondolod, hogy a jövőben emailen és chaten tartja majd a kapcsolatot egymással az átlagember?

  A 3D-hez nem feltétlen kell (attól függ...), de az animáláshoz és az interakcióhoz nem árt.

  Azt sem értem, miért akarod mindenáron az OS-re vagy a browserre bízni az egészet? Sokkal rugalmasabb és fejleszthetőbb, ha a kód nagy részt az oldallal töltődik be.

  Az #58-ba beszerkesztettem a választ az #57-re.

  [ Szerkesztve ]

• #68 Zeratul addikt julius666 #67

  Új Válasz 2011-08-25 20:24:57 #68

  Ú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

  

  Zeratul

  addikt

  válasz julius666 #67 üzenetére

  Itt már mintha pár sikerre ítélt architektúra elvérzett volna hivatott. Cell, Itanium.

• #71 dezz nagyúr julius666 #64

  Új Válasz 2011-08-25 21:31:16 #71

  Ú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

  

  dezz

  nagyúr

  válasz julius666 #64 üzenetére

  Hosszabb távon megjelenhet pl. a közvetlen agyak közötti kommunikáció, és lehet, hogy ehhez nem kevés asszisztencia is kel majd. Ki tudja, mit hoz a jövő...?

  Rövid távon is sokmindent el lehet képzelni. Valószínű előbb-utóbb visszaszorul pl. a billentyűzet használata (és majd az egéré is). Hangvezéerlés, beszéd- és emóció-felismerés, tekintetkövetés, stb. stb.

  Ez a flatness is elég unalmas már, akár OS, akár web szinten.

  "Pl. azért, mert egy használhatóbb beszédfelismerő/mintafelismerő forráskódja sok(tíz)ezer sor."

  Jó, persze, én sem úgy értettem, hogy az ilyen nehézsúlyú dolgok mind 1-1 adott weblap kódjában lennének. Azt nem értem, miért ne lehetne több-kevesebb WebGL és WebCL kód a lapokon.

  (#65) Blindmouse: Mindketten tudjuk, hogy ez egy szintetikus teszt, ami messze nem mond el mindent.

  (#70) Zeratul: Nem hiszen, hogy ez lett volna a cél, ahhoz túl gyenge a PPE, mint normál CPU mag. Inkább egyfajta co-procinak szánták egy nagyteljesítményű hagyományos CPU mellé, már ami az IBM-et illeti. Pl. a Roadrunner is eléggé ott van még a szeren, és van egy pár kistestvére is. A projekt fő szponzora, a Sony a maga részéről eleve a PS3-ba szánta, a Toshiba pedig TV-kbe, médiaplayerekbe, stb.

  [ Szerkesztve ]

• #73 dezz nagyúr julius666 #72

  Új Válasz 2011-08-26 00:42:29 #73

  Ú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

  

  dezz

  nagyúr

  válasz julius666 #72 üzenetére

  Már vagy 10 éve kapható olyan agyhullámvezérlésű joystick, ami egy fejre rakható pántból és egy elemző egységből áll. Először még nagyon primitív volt, mostanra már talán használhatóvá vált, valamennyire. Ha a PC vagy a telefon kellő kapacitást tud erre elkülöníteni, nem csak kiváltható a külső elemző egység, hanem nagyobb kapacitás is rendelkezésre állhat, olcsóbbá és hatékonyabbá téve az egészet. Persze, nem csak a számítási kapacitáson múlik a dolog. De egyéb érdekes kutatások is zajlanak ilyen téren.

  Láttam, hogy te is látsz (némi) rációt a beszédfelismerésben és társaiban. Az is igaz, hogy a legjobb, ha ezeket már eleve az OS tudja, vagy ha az nem, akkor a fejlődéssel lépést tartó browserek, amihez nem a WebCL a legoptimálisabb. (Viszont az OpenCL-lel nem tudom, mi a bajod, senki sem fog nekiállni mindezeket shader-asm-ben leprogramozni minden fajta GPU-ra. )

  Viszont, addig sem kell feltétlen megállnia a fejlődésnek, amíg az OS/browser/browserplugin készítők megemelik a val...kat.

  Amúgy van már valamelyik okostelefon platformra OpenCL implementáció? Lehet, hogy WebCL előbb fog megjelenni, mint az...

  "Egyébként ezzel a 3D-s UI-val már piszok régóta próbálkoznak, mindeddig abszolút sikertelenül."

  Talán megelőzték a korukat. Előbb meg kellett várni, amíg a jónép kiismeri magát a 2D-s felületeken.

  "Sőt ha megnézed határozottan megfigyelhető trend az UI-k minimalizálódása mind design, mind egyéb téren. Az érintőképernyők terjedésével ez csak folytatódni fog (lásd Win8 csempés felülete)."

  Azt nem ismerem, viszont bejönnek az Andoid vagy az iPhone 3D-s UI megoldásai... Egy harmónika-szerű fotóalbum is gyorsabban és kevésbé fárasztóan végigpörgethető, mint sok kis 2D-ben kiterített képecskét nézegetni.

  "Max annyira hogy ha megjelennek normális 3D-s monitorok akkor ugyanazok a 2D-s felületek kapnak valami minimális mélységet is (kb. csak a csicsa, valódi funkcionalitás nélkül)."

  A zárójeles részben nem lennék annyira biztos.

  "Ehhez pedig 3D-s leíró nyelv meg driver kell, semmi más, ezek eddig is rendelkezésre álltak."

  Itt most a VRML-re gondolsz? Az valahogy nem jött divatba (talán túl korai volt neki, vagy nem tudom). Vagy nem platform-független megoldásokra? Azok egyre inkább "felejtősek"... Ami az OpenCL-t illeti, az elvileg platformfüggetlen, viszont a gyakorlatilag nem annyira. Az WebCL viszont az. Mint ahogy a WebGL is.

• #81 ddekany veterán julius666 #80

  Új Válasz 2011-08-26 09:59:24 #81

  Ú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

  

  ddekany

  veterán

  válasz julius666 #80 üzenetére

  Én meg attól tartok, hogy a megbízható beszédfelismerés nem csak számítási kapacitás kérdése, hanem AI-é is. Legalábbis nekem borzalmasan sokat segít egy szöveg (főleg egy angol szöveg) hallás utáni megértésében, hogy tudom hogy milyen szó értelmes az adott ponton (a sok hasonlóan hangzó közül).

  JS dolog: "Ezt nem igazán értem."

  Elég gyér egy olyan alkalmazás fejlesztésre szánt platform, amiben a legalacsonyabb szintű nyelv egy eredetileg nagyon-nagyon kicsi projektekre tervezett script nyelv. Képzeld ha Windows platformon a VB lenne a legalacsonyabb szintű nyelv amit használhatsz, és nem létezne a gépikód, amire építve létezhet a C++, Pascal, Python, meg akármi ami kell. Meg nem utolsó sorban, amire építhetsz nagy és széles körben használt könyvárakat anélkül, hogy mindenkinek aki használja 5x annyit egyen mert dinamikus nyelv. Normális platformokon van választásod.

  "Egyébként ha a Google próbálkozásai sikerrel járnak és elterjed, a jövőben natív kód (illetve próbálkoznak egy köztes nyelv használatával is)"

  Ilyesmi lenne a helyes út... bár a natív kód elég szarul hangzik, a köztes (Dalvik pl.?) már sokkal jobban.

• #82 ddekany veterán julius666 #79

  Új Válasz 2011-08-26 10:05:59 #82

  Ú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

  

  ddekany

  veterán

  válasz julius666 #79 üzenetére

  "a WebCL az javascript bindig az OpenCL-hez, nem több."

  A WebCL valójában egy új nyelv is. Ha megnézel egy oldalt ami használja, ilyeneket találsz benne:

  <script type="text/x-opencl">
  ... valami C-szerű forráskód ...
  </scrpit>

  [ Szerkesztve ]

• #84 ddekany veterán julius666 #83

  Új Válasz 2011-08-26 15:05:51 #84

  Ú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

  

  ddekany

  veterán

  válasz julius666 #83 üzenetére

  "Szarrá van sandboxolva meg ellenőrizve, így talán annyira nem."

  Nem is a biztonság a gondom vele, meg annyira fatális gondom nincs vele ha majd CPU architektúra független is lesz (PNaCl, LLVM). Csak kicsit furcsa, hogy míg Windows alkalmazásfejlesztés terén már rég elindult a trend a C++ (natív) leváltására C#-al (CLR), itt most megint totál natívról akarnak kezdeni. A JVM (Java, stb) és CLR (C#, stb) felfogásának közel sem csak a valamivel nagyobb biztonság az előnye... Hanem pl. automatikus memória kezelés, nincsenek pointerek, jobb interoperabilitás a mások által fejlesztett komponensekkel. Persze a (P)NaCl-en meg lehet valósítani egy JVM-szerűséget, csak nehogy az legyen, hogy ezért nem fog ilyesmi elterjedni, mert alapból nincs elég helyen telepítve, és 50 MB-t lerántatni a weboldal első meglátogatáskor meg nem vicces. (Ez kb u.a. a sztori mint desktopon, ahol is a .Net igazi felfutásához egyértelműen fontos, hogy az Windows része lett. Itt ha csak a PNaCl lesz a böngészők része alapból, de az akármilyen-VM (pl. Dalvik) nem... kétséges a kimenetel.)

  "Csak komolyabb dolgokhoz (pl. komolyabb játékmotorokhoz, nagyobb üzleti rendszerekhez) alkalmatlan, de nem igazán értem ez miért akkora probléma, nem is erre találták ki, nem is próbálja senki ilyesmire használni."

  Azért igencsak vastagodnak a kliens oldali rétegek is... És amúgy a dinamikus nyelvek problémái közül a sebesség csak az egyik, és sokszor nem is a lényeges gond. A karbantarthatóság és IDE támogatás az ami miatt sokszor nem jó üzlet a dinamikusság. (Na de ilyen nyelvi finomságokról kár is beszélgetni Web kapcsán, ahol is a programok 99%-át PHP-ban írják, ami nyelvtervezésileg egy hatalmas kupac inkompetencia némi káosszal nyakon öntve... Képzelem, emberek ezen nőnek fel, és a koporsóig más nem is látnak. Csak hallották, hogy van ilyen, mint Scala, meg Ruby meg Python, de azok bloatedek meg lassúak meg vááá...)

• #86 ddekany veterán julius666 #85

  Új Válasz 2011-08-26 20:46:29 #86

  Ú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

  

  ddekany

  veterán

  válasz julius666 #85 üzenetére

  "kódkiegészítés lényegében nincs (van csak buta) és sorolhatnánk. Ez azonban nem hiszem hogy szükségszerű állapot"

  Javítani lehet sok mindenen, heroikus befektetésekkel... de soha nem lehet azt a szintet elérni, mint statikus nyelvekkel, főleg azonos befektetéssel nem. Ha ugyanis tényleg kihasználod a dinamikusságot, akkor szükségszerűen nincsenek egyértelmű válaszok arra, hogy mi milyen típusú (osztályú), meg ha adott osztályú akkor milyen metódusai vannak. Neked is sokszor nehéz kigabalyítani, hát még egy IDE-nek aki magasabb szinten nem érti a programot, na meg nem futtathatja és nézegetheti debuggerrel. Ha meg nem használod ki a dinamikusságot, akkor inkább valami modern statikus nyelvet érdemes használni. Persze itt egy nagy buktató, hogy a statikus nyelvek világa valamiért elég nehézkesen mozgott az utóbbi évtized(ek?)ben... A korszerűbbek (pl. Digital Mars féle D vagy Scala, Kotlin, Ceylon) még szinte sehol sincsenek, főleg tooling terén, holott utóbbi lenne pont ez egyik lényeges erényük. A Java ilyen szempontból remek pozícióba van, de maga a nyelv ma már fájdalmasan elmaradott és eleve feleslegesen szószátyár, ezzel is égetve a statikus nyelveket. C# még tán a legjobb azok közt ami elterjedt, de Mono ide vagy oda, ott az MS árnyéka. Szóval legalábbis nem-Windows platformon van itt egy űr, ami kedvez a dinamikus nyelveknek, jobban mint megérdemelnék. Most ezért a szerver oldalon is a feleslegesen szadista Java és a saját műfajában elég jó Ruby ill Python közt kell választani. (Persze, visszatérve a rögös Webes valóságba, az is már csodás lenne, ha mondjuk a Python ugyan olyan mindenhol alapértelmezésben jelenlévő és bagóért hosztolható lenne, mint a PHP. Igen, a VPS ára szerencsére csökken.)

  Ja, "kicsit" OFF-ok lettünk...

  [ Szerkesztve ]

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