Isten Nyila Válaszolta April 21, 2011 Share Válaszolta April 21, 2011 Azért nem is csak a puszta számítási kapacitáson múlik egy-egy adott célfeladatra való alkalmasság, ezt is lássuk be. Például, mint Silk is utalt rá már korábban, az is sokat számíthat, hogy egy-egy kódrészletet - előre kiszámíthatóan - mindig pontosan ugyanúgy és ugyanannyi idő alatt hajt végre ugyanaz a DSP. Egyrészt miután a DSP-processzorok mindenhol és tökéletes módon halálegyformák (míg CPU-ból, GPU-ból ezerféle van, és mindegyikkel mindenfelé kompatibilisnek kéne maradni), másrészt pedig nem csinálnak közben semmi mást. Aztán ugyebár a mai használt grafikus op.rendszerek közül egyik sem kimondottan realtime jellegű (se a Windows, se a Linux, se az OSX stb.), hanem eseményvezérelt és megszakítás alapú. (A DOS mondjuk még realtime volt... de nem is volt még akkor multitask. Valamit valamiért, úgy mondják.) Nem tudom, hogy ki állna ma neki mondjuk Windows alatt assembly-ben, gépi kódban fejleszteni valamit, egy bizonyos CPU-típusra optimalizálva, kiiktatva minden megszakítást... stb. Aki viszont elég "öreg" hozzá, és még emlékszik rá, milyen volt az Amigán vagy Commodore-on programozni a képernyőosztásos raszter-trükköket, a sprite-multiplexert, a floppy-gyorstöltőket, meg a többi ilyen, elképesztően pontos ciklusidőzítést kívánó feladatot, az megérti, hogy miről is van szó. (Óh, a régi demó scene! ) Bár létezik egy csomó emuláció, de ezek közül jó néhányat mind a mai napig nem képesek tökéletes pontossággal visszaadni modern gépeken (pedig milyen hihetetlen szakadék tátong köztük számítási teljesítményben). Nem is igen lehetséges mai környezetben ilyen fajta programozás szerintem. Link to comment Share on other sites More sharing options...
leslie Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Isten Nyila: végre valaki megpróbálja a lehetetlent, kaptál egy .ot Erőssen reklámszagú de van benne valami: The employed SHARC DSP was specifically designed to perform high-resolution audio processing. It always processes the audio with a 32-bit resolution, and algorithms and parameters are computed with a floating-point resolution of even 40 bits. If there are no such powerful structures at hand, programmers will have to make compromises regarding the resolution (accuracy) again and again for performance purposes; so the weakest link in the processing chain will often determine the sound. With SHARCs, however, you never have to compromise: the highest resolution is maintained during the entire process without affecting the performance. You can hear it in the results. Link to comment Share on other sites More sharing options...
DragonTamás Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 DragonTomek: Hát ja. Értem én, hogy sokkal kényelmesebb "html-ben" fejleszteni plugineket, mint gépikódban. Meg változtatni is sokkal könyebb. Csak az a baj, hogy nem túl hatékony. Azt is értem, hogy a rengeteg marketing mellett senkinek sincs ideje komolyabb szinten a fizikai meg matematikai alapokkal foglalkozni...aki meg ilyenekhez ért, az nem megy el havi 1800 dolcsiért dolgozni. Azt is értem, hogy a minöség nem elsödleges, hiszen fontosabb a haszon. Mindent meg lehet magyarázni. Szóval a kutyaütö fejlesztekröl kábé ennyit...pont olyanok, mint a usereik. Értem én, hogy mire gondolsz, és rengeteg igazság is van benne, bár megjegyzem ezeket a gondolatokat nem annyira kutyaütő marketingfejlesztők mondták. A marketing osztályok már így is túl nagyra nőttek szerintem. A kutyaütők mellett azért sok nagy agy is van, csak ők sok esetben nem marketingelik úgy magukat, de nekik még a minőség fontosabb, ezért is igyekeztem inkább tőlük közvetlen infókat szerezni/tanulni, és nem marketin anyagokat olvasni, akár legyen az az uad-tól, vagy bárki mástól. Egy komoly kis ex-tdm-es csapat véleményéből: "However, optimized code can be produced on the x86 far more easily than it can be developed for most DSPs." És nyilván emelett még mindig sok előnye lehet a dsp-nek. De a fejlődés nem áll meg. Link to comment Share on other sites More sharing options...
DragonTamás Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Az egyébként nagyon érdekes a gpu-k esetében, hogy elképesztő eredményeket lehet elérni velük, de még nincs egy kvázi szabvány, ami alapján ezt az elképesztő lehetőséget ténylegesen-biztonságosan-folyamatosan kiszedjék belőlük. Az nvidia nagyon jó fejlesztői dolgokat csinál, de valamiért ez a rész mégis lassabban halad, mint reméltük. Hiszen már hány éve megy az egész projekt, és "kézzel fogható" eredménye részünkre még nulla. Egyébként az nyilvánvaló, hogy most az uadnak emberfeletti energiákba (és nyilván pénzbe) kerülne mindent natívra átteni, a "dongle" hiányáról nem is beszélve. És itt jön a képbe a fejlesztők minősége. Akik ezt meg tudják csinálni normálisan, azok nem kétforint húszfilléres emberkék. És nyilván itt már hirtelen át is megyünk a mocskos biznisz részbe, hogy megérné-e egyátalán az egész sztori nekik, mert hát nyilván ők sem a vörös kereszt, nekik is meg kell élni. Link to comment Share on other sites More sharing options...
comp Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 " Egyrészt miután a DSP-processzorok mindenhol és tökéletes módon halálegyformák (míg CPU-ból, GPU-ból ezerféle van, és mindegyikkel mindenfelé kompatibilisnek kéne maradni)," Én nem fogok itt a fórumon minuszolni sose, de ezt ugye tudod hogy a GPU technikailag nem más mint egy többmagos DSP szteroidokon nevelve? Szóval GPU vs. DSP ügyben szinte azonos architektúráról beszélünk azonban a GPU-k a párhuzamos alkalmazásokra is fel vannak készítve. :-) Link to comment Share on other sites More sharing options...
comp Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 "Az egyébként nagyon érdekes a gpu-k esetében, hogy elképesztő eredményeket lehet elérni velük, de még nincs egy kvázi szabvány, ami alapján ezt az elképesztő lehetőséget ténylegesen-biztonságosan-folyamatosan kiszedjék belőlük." Ez megintcsak nem a GPU hibája hanem az őt körbevevő architektúráé. Az alapvető gond hogy amit számítottál a GPU-val az a saját dedikált memóriaterületére kerül. Ezt az adatmennyiséget folyamatosan vissza kéne rántani hogy az alkalmazás is tudjon vele kezdeni valamit és ez a szűk keresztmetszet ami megjósolhatatlanná teszi. A shader mikrokód ami a műveleteket elvégzi tulajdonképpen valós DSP művelet, ebből a szempontból nincs különbség egy GPU és egy DSP között (mivelhogy a GPU is DSP). Link to comment Share on other sites More sharing options...
Isten Nyila Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 " Egyrészt miután a DSP-processzorok mindenhol és tökéletes módon halálegyformák (míg CPU-ból, GPU-ból ezerféle van, és mindegyikkel mindenfelé kompatibilisnek kéne maradni)," Én nem fogok itt a fórumon minuszolni sose, de ezt ugye tudod hogy a GPU technikailag nem más mint egy többmagos DSP szteroidokon nevelve? Szóval GPU vs. DSP ügyben szinte azonos architektúráról beszélünk azonban a GPU-k a párhuzamos alkalmazásokra is fel vannak készítve. :-) Comp: én arról beszéltem, hogy minden egyes UAD kártyán pontosan ugyanaz a Sharc chip van. Szerintem ezt félreértetted! Link to comment Share on other sites More sharing options...
comp Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 "Aztán ugyebár a mai használt grafikus op.rendszerek közül egyik sem kimondottan realtime jellegű (se a Windows, se a Linux, se az OSX stb.), hanem eseményvezérelt és megszakítás alapú. (A DOS mondjuk még realtime volt... de nem is volt még akkor multitask. Valamit valamiért, úgy mondják.) Nem tudom, hogy ki állna ma neki mondjuk Windows alatt assembly-ben, gépi kódban fejleszteni valamit, egy bizonyos CPU-típusra optimalizálva, kiiktatva minden megszakítást... stb. Aki viszont elég "öreg" hozzá, és még emlékszik rá, milyen volt az Amigán vagy Commodore-on programozni a képernyőosztásos raszter-trükköket, a sprite-multiplexert, a floppy-gyorstöltőket, meg a többi ilyen, elképesztően pontos ciklusidőzítést kívánó feladatot, az megérti, hogy miről is van szó. (Óh, a régi demó scene! ) Bár létezik egy csomó emuláció, de ezek közül jó néhányat mind a mai napig nem képesek tökéletes pontossággal visszaadni modern gépeken (pedig milyen hihetetlen szakadék tátong köztük számítási teljesítményben). Nem is igen lehetséges mai környezetben ilyen fajta programozás szerintem." Én a DOS-os világban - mivel C64/Amiga scene körökből jöttem - még PC-n is programoztam raszter trükköket, meg lehet csinálni a mai napig is, hogy a kép fele grafikus, a másik fele szöveges módban van pl. :-) A Windows természetesen buta mert 20ms-nál rövidebb időegységeket nem tud kezelni, csak kernel ring0 szinten. A mai PC-kben is megvan pont ugyanaz a lehetőség hogy vsync alapján programozd őket (lásd: 0x3c8 vga port pl.), ennek ma két akadálya van: - Az OS közvetlenül nem engedi, tehát vagy kernelből kell megvalósítani, ideiglenesen kilőve az OS ütemezőjét, vagy teljesen OS nélkül megtenni (megjegyzem Linuxban pl. megvalósítható illetve vannak kifejezetten realtime OS-ek is pl. QNX). - Idejétmúlt a megközelítés. A vsync rendkívül szűk határok közé szorítaná a CPU teljesítmény optimális kihasználását (főleg, hogy ma már nem csak egy magról beszélünk). Amíg ez a technológia működött a képfelépítésnél lassabb órajelen működő gépeknél (pl. C64 17Mhz-en építette fel a képet, de a processzor sebessége 1Mhz-re le volt osztva ebből) nem megfelelő akkor ha a processzor nagyságrendekkel gyorsabb mint a képfrissítési frekvencia. A Vsyncre várással lényegében csak azt éred el, hogy a processzor állandóan várakozik és nem végezhet közben más feladatatot. Szóval ma inkább lemondanak a vsyncről csakhogy kihasználhassák a CPU(k) plusz teljesítményét. Az emuláció egyébként jó példa, de ott inkább a rengeteg számláló karbantartásával veszik el a teljesítmény. Linus Torvalds-nak volt egy TransMeta nevű projektje, amiben pont olyan processzort szerettek volna létrehozni, amiben a mikrokód cserélhető (tehát ha akarod lehet olyan mint egy motorola, cbm vagy bármi más az assembly programozás szempontjából). Kár hogy befuccsolt a projekt, retro körökben nagy előrelépés lett volna egy hardver-alapú emuláció :-) Link to comment Share on other sites More sharing options...
oldbrian Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Az egyébként nagyon érdekes a gpu-k esetében, hogy elképesztő eredményeket lehet elérni velük, de még nincs egy kvázi szabvány, ami alapján ezt az elképesztő lehetőséget ténylegesen-biztonságosan-folyamatosan kiszedjék belőlük. Az nvidia nagyon jó fejlesztői dolgokat csinál, de valamiért ez a rész mégis lassabban halad, mint reméltük. Hiszen már hány éve megy az egész projekt, és "kézzel fogható" eredménye részünkre még nulla. több mint egy évtizede két gyártó uralja a GPU világot, ha csak az egyik támogat valamit, már szinte tekintheted szabványnak (voltak (nem zene)ipari alkalmazások, amik már két évvel ezelőtt is CUDA-t használtak, még hazánkban is), de metszetben sem rossz a helyzet, az OpenCL-t éppen támogatja mindkettő, csakúgy, mint a DirectCompute-ot. amit mondtak UAD-sok, hogy térdre vittek egy Mac Pro-t nem hihetetlen, de nem a nyers számításigény miatt, hanem azért, mert más környezetre készült a kódjuk. ami egy SIMD architektúrán optimális kód, az a brute-force megközelítésnél is sokszorosan lassabb lehet SISD(-ebb jellegű) CPU-n. ilyen összevetésben a GPU-DSP vonalon kevesebb különbség van, de hát aki akart, az eddig is fejlesztett GPU gyorsította plugineket, csak ott nem lenne jó hardverkulcs. maga az indítócikk 80-20-as száma meglepő lenne (már hogy a szoftver meglepően sok, habár szó sincs arról mi számít bele "vasnak", így alapból értelmezhetetlen a számadat), ha nem mosolyogna csak rajta az ember... most komolyan, pont Pareto? viszont a vas és szoftver küzdelme nem ennyire egyoldalú, van ahol éppen a vas szorul ki. aki munkára használja a dolgokat, annak végül úgyis az dönt, hogy adott feladatra melyik a jobb, melyik illeszkedik jobban a workflow-ba. ha megnézitek az innováció számítógépes hangkönyvtáraknál már két évtizede zeneszerzőktől indul, mivel elsősorban ők használják és vasas szemmel nincs is benne elég pénz - gitárhangolóból mennyivel többre van szükség, mint egy nagyzenekari ütőskönyvtárra. ettől függetlenül tényleg szükség lenne technológiai innovációra is, aminek a "megfizetésére" nincs forrás ott. viszont a hangszintézis világa egyáltalán nem olyan stagnáló dolog, mint ahogy a szintimegjelenések alapján gondoljátok, csak túlságosan az akadémiai világban marad az innováció. Link to comment Share on other sites More sharing options...
Isten Nyila Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 A fő gondolat, amire itt utalni próbáltam, a programkód futásának tökéletes előre kiszámíthatósága; valamint a változatlan, fix hardverre való optimalizálhatóság előnye. A retró példákat is ennek alátámasztására hoztam fel, mivel ott még megvolt ennek a lehetősége (igen, én is azt írtam, hogy DOS alatt még lehetett is ilyet csinálni). A rasztermegszakítás kezelése például, ha jól emlékszem, úgy zajlott, hogy először is beállítottad a megfelelő regiszterben, melyik pixelsorban generáljon IRQ-t a gép. Majd a megszakításkezelő szubrutinban (mivel annak megírása során te már pontosan tudtad fejben előre, hogy abban az adott pillanatban hol fog járni épp az elektronsugár a képernyőn, s a következő ciklusokban mikor mennyit halad előre) pusztán csak az egyes utasítások végrehajtási idejének összeadásával ki tudtad számítani előzetesen, a kód végrehajtása során mikor érkezik el az a pont, ahová a szükséges változtatást végrehajtó utasításokat be kellett szúrni, hogy az éppen idejében történjen. Ez volt benne a szép és elegáns (ha kiszámoltad, külön várakozni nem kellett - egy órajel se veszett kárba sehol sem). A lényeg az, hogy - programozás szintjén - minden gépben ugyanaz a hardver volt, és ez tette ezt lehetővé számodra. Link to comment Share on other sites More sharing options...
comp Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 "Comp: én arról beszéltem, hogy minden egyes UAD kártyán pontosan ugyanaz a Sharc chip van. Szerintem ezt félreértetted! " Valóban, de a válaszom nek is erre vonatkozott :-) A raszter IRQ C64-en úgy működött, hogy minden képfelépítés megkezdésekor a $0314/$0315 címen tárolt mutatóval elérhető szubrutint meghívta a gép és ezután a te feladatod volt a megfelelő időzítés (ami az órajelet ismerve egy egyszerű várakozó ciklus volt). Hardver programozásnál egyébként jellemzően nem lineáris futással kell számolni, erre egy tökéletes ellenpélda például az FPGA programozás, ahol a kódod egyáltalán nem lineáris formában fut, hanem bármelyik jelvezeték aktivitása kiválthatja a következő lépést a logikai hálózaton (ennek a kifacsart gondolkodásnak megfelelően nem is hemzsegnek az FPGA fejlesztők a szakmában). "Az egyébként nagyon érdekes a gpu-k esetében, hogy elképesztő eredményeket lehet elérni velük, de még nincs egy kvázi szabvány, ami alapján ezt az elképesztő lehetőséget ténylegesen-biztonságosan-folyamatosan kiszedjék belőlük." Vannak kezdemények például rengeteg egyetem épít szuperszámítógépet GPU alapú megoldásokból. Meglátjuk hogy jutnak-e másra is. Link to comment Share on other sites More sharing options...
comp Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Tényleg, hova tűnt a hozzászólás szerkesztése opció? :-) Egyébként most jutott eszembe hogy a C=64-en valóban lehetett a D012-es címen raszter sorszámot megadni, de gyakorlatban nem ez a fajta használati mód volt a jellemző (inkább NOP-okkal tolták tele a várakozás miatt :-)). Link to comment Share on other sites More sharing options...
Isten Nyila Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Egyébként most jutott eszembe hogy a C=64-en valóban lehetett a D012-es címen raszter sorszámot megadni, de gyakorlatban nem ez a fajta használati mód volt a jellemző (inkább NOP-okkal tolták tele a várakozás miatt :-)). Én úgy használtam, ahogy fentebb leírtam. Azt hittem, hogy másnak is majd ez fog beugrani róla, akkor ezek szerint tévedtem... Beismerem, nem a legmegfelelőbb példát hoztam fel. Ez már nagyon OFF, de nekem meg az jutott az eszembe, hogy tényleg, azért nem kedvelték ezt a módszert, mivel ritkán előfordult, hogy a megszakításvégrehajtás elé éppen akkor beszúródott még a standard IRQ (mielőtt még letilthattad volna), ami miatt olykor-olykor megvillant a képernyő. De ezt is könnyű volt elhárítani, csak egy sorral korábbra kellett időzíteni, majd kivárni a következő sort (itt egy egész pici ciklusidő tényleg elveszett!). (De kezdek gyanakodni, ez már megint kissé untatja többséget...) Link to comment Share on other sites More sharing options...
Isten Nyila Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Hihi, az emlékek felidézésében nyújtott konstruktív közreműködésért cserébe most "visszapluszoltam" neked azt a hsz-t, amit előzőleg "lemínuszolt" valaki... (de csak azért, mert már bántotta a szememet) Link to comment Share on other sites More sharing options...
silk Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Vissza a lényegre (silk már csak ilyen ) Szerintem meg akkor is szar van a levesben ezzel az egész native-al. Hogy a büdös francba lehet az gyerekek, hogy közel 20 év alatt SEMMELYIK nagyarcú fejlesztönek nem sikerült meglépnie még egy koszos TDM minöséget se native-ban? UAD 10 éve van. Pölö ott a 1176. Köbö kis ezer cég gyárt belöle native-ot is, van aki sokkal régebben kezdte csinálni a plugot, mint maga az UA. Akkor mér van az, hogy mikor egymás mellé teszem öket, egy teljesen amatör hallgatónak is átjön, hogy az egyik sokkal szarabb, s ez nem az UAD verzió szokott lenni? Az amúgy marketing szerint "übercoder" fejlesztö gárdák mér nem bírják simán "kilopni" a kódot pofátlanul (mint ahogy megteszik ezer más területen) a tetülassúelavultszar SAHRC-ról, s átalgoritmizálni az übertápszuperhighend i7-re pölö??? Mert érted...ha ott lennének "agyilag", érteniük kellene, hogy az mit csinál. Akkor viszont, ha mást nem is, de szépen kicserélgetnék a speciális DSP kódokat az i7 SSE2 kódjaira, oszt had menjen. 2+2 az elvileg mind a két platformon 4, összadni meg azért i7-en is lehet szerintem. Szóval ezt rohadtul nem értem. Mert ha ezt a logikát követem két eset lehet: 1: (ez a jobbik) becsületes rendes fejlesztök nem lopkodnak és az i7-en nem lehet bizonyos dolgokat egyátalán megoldani, vagy sokkal "pontatlanabb" matematikailag 2: (ez a reálisabb) teljesen tökelütött html gárda fejlesztget a native platformra, jó beleszarós módon (ahogy az köreikben standard), akiknek a pénzen kivül más céljuk se nincsen. Süketek és izléstelenek is természetesen, s köbö annyit értenek az egész szakmához matematikailag, amit a Berkley internetes weboldaláról le lehet tölteni. No? Ti mit gondoltok erröl? Link to comment Share on other sites More sharing options...
cshuszar Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 comp / Isten Nyila: én is simán IRQ-ból használtam, és ha kellett a ricogásmentesség (tűéles függőleges osztás) akkor két rasztersornyit rá kellett áldozni a BNE lesimításra. Egyszerű feladatokra sztem ez volt a hatékonyabb, semmint a kimatekozott NOP sor, mert 2 sorral hamarabbra tetted az IRQ-t (sta $d012, és a BNE kettős tulajdonságát kihasználva 2 sor alatt kiegyenlítetted a D012 olvasás pontatlanságát. ez abból a szempontból hatékonyabb volt szvsz, hogy ilyen esetben, a raszterpozició pontosságot igénylő területen kívül, nyugodtan mehetett ömlesztve a bármi más, ami pl frame alapon (pl zene), vagy más feltételek alapon (pl memória mozgatás). És ugye ezeknek (zene és memória mozgatás) a szükséges raszterideje pixelpontosan (de sor pontosan is) meghatározhatatlan, szóval jót tesz neki, ha nem szorítja a gatya, előre számolni vele meg úgysem lehet. most, hogy ilyen nosztalgikus hangot ütöttünk meg elmerengtem, hogy milyen szar a mai tiniknek. nekik muszáj faszbukkal, meg ha nagyon kreativak valami html programozással kiélni számítástechnikai igényeiket, mi meg képikódban használtunk illegális operandusokat (úgy, hogy működött), ha akartunk valamit... meg memóriaháborút játszottunk... Link to comment Share on other sites More sharing options...
silk Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 LOL...eszembe jutott erröl egy ujabb vizió: Google Virtual Studio...na, ez meghozná az áttörést szerintem. (Másfelöl vicc, de szerintem 1 hét alatt beérnék minöségileg a mostani native gyártókat, ráadásul tök ingyenes lenne. ) Link to comment Share on other sites More sharing options...
cshuszar Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Vissza a lényegre (silk már csak ilyen ) Szerintem meg akkor is szar van a levesben ezzel az egész native-al. Hogy a büdös francba lehet az gyerekek, hogy közel 20 év alatt SEMMELYIK nagyarcú fejlesztönek nem sikerült meglépnie még egy koszos TDM minöséget se native-ban? UAD 10 éve van. Pölö ott a 1176. Köbö kis ezer cég gyárt belöle native-ot is, van aki sokkal régebben kezdte csinálni a plugot, mint maga az UA. Akkor mér van az, hogy mikor egymás mellé teszem öket, egy teljesen amatör hallgatónak is átjön, hogy az egyik sokkal szarabb, s ez nem az UAD verzió szokott lenni? Az amúgy marketing szerint "übercoder" fejlesztö gárdák mér nem bírják simán "kilopni" a kódot pofátlanul (mint ahogy megteszik ezer más területen) a tetülassúelavultszar SAHRC-ról, s átalgoritmizálni az übertápszuperhighend i7-re pölö??? Mert érted...ha ott lennének "agyilag", érteniük kellene, hogy az mit csinál. Akkor viszont, ha mást nem is, de szépen kicserélgetnék a speciális DSP kódokat az i7 SSE2 kódjaira, oszt had menjen. 2+2 az elvileg mind a két platformon 4, összadni meg azért i7-en is lehet szerintem. Szóval ezt rohadtul nem értem. Mert ha ezt a logikát követem két eset lehet: 1: (ez a jobbik) becsületes rendes fejlesztök nem lopkodnak és az i7-en nem lehet bizonyos dolgokat egyátalán megoldani, vagy sokkal "pontatlanabb" matematikailag 2: (ez a reálisabb) teljesen tökelütött html gárda fejlesztget a native platformra, jó beleszarós módon (ahogy az köreikben standard), akiknek a pénzen kivül más céljuk se nincsen. Süketek és izléstelenek is természetesen, s köbö annyit értenek az egész szakmához matematikailag, amit a Berkley internetes weboldaláról le lehet tölteni. No? Ti mit gondoltok erröl? én erről azt gondolom, hogy ha próbáltad már a brainworx plugineket, akkor nem fogod csodálni, hogy az UAD felkérte (vagy engedte) őket külső fejlesztőnek. Jó ízléssel (füllel) összerakott algoritmusok, amikben ki tudja mekkora potenciál van, ha nem kell CPUn futtatni őket, annak minden pontatlansági/kiszámíthatatlansági tényezőjére lebutítva. Az előző mondat értelmes!D szerk: hozzáteszem, jónéhány PC-re fejlesztő ismerősöm van, ráadásul elég elismert szakemberek, de egytől egyig visual basic, meg dotnet, meg php programozással foglalkoznak, teljesen érthető okokból (fentebb kitárgyalva - 1000 hardver kompatibilitás). ez kb az a szint, mint c64-en a basic, vagy annál is szarabb hatékonyság. van egy utópisztikus látomásom: a ps3 már ma is nagyon durva hardver, ráadásul kötött, a következő generáció meg ki tudja hányszor lesz erősebb. oprendszert is simán futtathat(na), és lévén kötött hardver, az optimalizáció is sokkal megoldhatóbb, csakúgy mint a DSP cuccoknál. ha kifizetődő lenne a szoftverfejlesztés ilyen platformokra, szerintem nagyon gyorsan kiszoríthatnák a PC-t. ... ja és azokhoz (pl ps3) ugyanúgy megoldható (lenne) a plusz DSP meg audio I/O bővítés. Vélemény? Link to comment Share on other sites More sharing options...
cshuszar Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 LOL...eszembe jutott erröl egy ujabb vizió: Google Virtual Studio...na, ez meghozná az áttörést szerintem. (Másfelöl vicc, de szerintem 1 hét alatt beérnék minöségileg a mostani native gyártókat, ráadásul tök ingyenes lenne. ) ez szerintem kb ugyanazt hozná, mint a rebirth anno. minden pozitív és negatív hatásával együtt... lehet, túl szkeptikus vagyok. Link to comment Share on other sites More sharing options...
Isten Nyila Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Sőt: gepikodb-an (á la Sótész Gögy) Hogy én is visszakanyarodjak, eszembe jutott egy jó kérdés. SPL lett ugyebár a "másik első" 3rd party. Mostanra az SPL Transient Designer már négy különböző platformon is jelen van (UAD-1 és UAD-2, natív, TDM). Nem lehetne ebből - ha valaki netán mindhez együtt hozzáfér - egy kis összehasonlítást csinálni? Link to comment Share on other sites More sharing options...
DragonTamás Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Sőt: gepikodb-an (á la Sótész Gögy) Hogy én is visszakanyarodjak, eszembe jutott egy jó kérdés. SPL lett ugyebár a "másik első" 3rd party. Mostanra az SPL Transient Designer már négy különböző platformon is jelen van (UAD-1 és UAD-2, natív, TDM). Nem lehetne ebből - ha valaki netán mindhez együtt hozzáfér - egy kis összehasonlítást csinálni? Az spl-es plugineket is a Brainworks csinálta, mindenhova. Link to comment Share on other sites More sharing options...
Isten Nyila Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Az spl-es plugineket is a Brainworks csinálta, mindenhova. Akkor annál inkább! Ez még jobban is hangzik, hiszen akkor - elvileg, az elvárások szerint - mindegyiknek egyformának kéne lennie. Amennyiben tényleg közös fejlesztések, akkor ez egy jó alapot teremt maguknak a platformoknak az összehasonlítására, vagy nem? Link to comment Share on other sites More sharing options...
DragonTamás Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Akkor annál inkább! Ez még jobban is hangzik, hiszen akkor - elvileg, az elvárások szerint - mindegyiknek egyformának kéne lennie. Amennyiben tényleg közös fejlesztések, akkor ez egy jó alapot teremt maguknak a platformoknak az összehasonlítására, vagy nem? Elég durva lenne, ha másképpen szólna, mert egy algoritmus, csak portolva lett. Link to comment Share on other sites More sharing options...
Isten Nyila Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Elég durva lenne, ha másképpen szólna, mert egy algoritmus, csak portolva lett. Nemcsak hangzás terén, hanem mondjuk prociterhelések, ilyesmi... Engem személy szerint kíváncsivá tett. (Persze más jellegű plugineknél másként alakulna valószínűleg majd ugyanez - így a többi cuccra nem lehetne visszavetíteni az eredményt, azaz nem lehetne kimondottan reprezentatív - de első lépésnek tán megteszi.) Link to comment Share on other sites More sharing options...
DragonTamás Válaszolta April 22, 2011 Share Válaszolta April 22, 2011 Egyébként pont a brainworks egyik oka az uad-hoz csatlakozáshoz a warez! Éppen ezért valószínű, hogy egyre több gyártó fog majd csatlakozni, de ez majd nyilván kiderül. A matek az meg matek. Nem pontosabb, vagy pontatlanabb itt, meg ott, csak úgy random módon. Az uadnál sem ufók ülnek, akik assemlyben nyomják reggeltől estig, vannak profi sharc emulátorok x86-ra, nem hiába... Nagyot bukott ez az egész szoftver ipar mára. Nem hiába igyekszik mindenki kapaszkodni, köztük az uad is. Még ők sem tudnak mindent megengedni maguknak, ott is van külsős bedolgozó agy. Talán az utóbbi évtizedek legnagyobb ilyen agyai akkor kerültek utcára, amikor a régi digidesign elkezdett csúszni. Ott irgalmatlan méretű volt a dsp és egyéb kóder dipártment. Ezek jó része ma már vagy egyéb helyeken fejleszt, de sokan el is hagyták az egész iparágat. Pont a brainworx is hasonló történés után alakult, nekik eddig nagyjából bejött, bár az uad felé fordulás szinte egyértelműen warez miatt volt. Nem kicsit jók a srácok, Ők csinálták az uad sdk-ját is... Konkrétan az Avidesek egyik legnagyobb szívfájdalma, hogy meg kellett válniuk sok olyan koponyától, akik olyan tudásúak, hogy már-már ufók. Ezeknek az embereknek egy része most natívban is fejleszt, illetve bedolgozik akár több cégbe is. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.