Szerencsére amd-n kívül már mások is tudtak régesrég fluid motion-t csinálni apu nélkül. Hogy ez mért nem működik mostanában cpu-n a fene se tudja...
http://www.tested.com/tech/pcs/329-how-to-enable-motion-interpolation-on-your-movie-files/

BTW: jó kis toborzós PR cikk

A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

Azért nem működik, mert a Fluid Motion Video az AMD technológiája. Maga az egyébként HSAIL kód a driverben van benne és a lejátszóprogram engedélyezheti. A kód átírására nincs lehetőség. Azon a hardveren működteti az AMD, amelyiken akarja. A Cyberlink ezt nem tudja kiterjeszteni, maximum annyit tehetnek, hogy írnak egy saját kódot, de ezt még nem tették meg. Egyelőre addig jutottak el, hogy engedélyezik ezt a technológiát és kész.

Természetesen nem technikai probléma áll a Fluid Motion Videóhoz hasonló megoldás alkalmazásán más CPU-kon, vagy GPU-kon, hanem az, hogy az AMD ezt direkten a Kaveri APU-ra írta mint szolgáltatást, és máshol nem használható.
Egyébként licencelhető kódról van szó. Az ARM és a Qualcomm már tárgyal erről. Nyilván van az a pénz, amennyiért az AMD eladja nekik.

[ Szerkesztve ]

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

Alig várom az A6 7400K-s változatot!
Remélem nem lesz túlárazva...18-20 db ezres körül lenne már meg is rendelném!

Közút nem versenypálya! Versenypálya NEM közút ;)

Az A6-6400K-ból kiindulva legfeljebb azoknak lehet jó, akiket egyáltalán nem érdekel a CPU erő, és csak az IGP-re utaznak valami régebbi, vagy újabb, de alacsony erőforrásigénnyel rendelkező játék miatt.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Jelenleg is egy 5400K változattal tengetem napjaimat. Új játékokkal nem játszok régebbiekkel viszont jól elvagyok! Pénztárcám ennyit tud magából kiizzadni így beérem ezzel a 7400K változattal!
Ha a Diablo 3 és a Bf3 jobban fog kocogni a jelenlegi APU-tól már megérte a pénzét számomra!

Közút nem versenypálya! Versenypálya NEM közút ;)

Sajnos az AMD továbbra sem tud megfelelöen erös CPU-t csinálni.Kár mert így minden az Intel felé billen.

duree54

Tökéletes! ...HTPC-be (meg netbook-ba), de egy középkategóriás PC-hez ez még mindig kevés - önmagában, ha meg dVGA-t kell hozzá vennem, akkor miért fizessek a GPU-ért...

Nem-e lehetne é-e, hogy amíg nem tudja(/tudhatja, ha engedély kell rá neki ehhez vkitől) addig megnövelni, legalább a szálankénti teljesítményt az AMD, amíg nem tudnak memóriával egybetokozott/Slot-os, "normális" teljesítményű APU-t gyárta(t)ni?
Ez mégiscsak többeknél lépné át a vásárlási hajlandóságuk ingerküszöbét, mint a 4 éve helyben toporgó APU-juk (jó, csíkszélességváltás volt, de azon kívül nem sok előrelépés történt a teljesítményben)!

A regisztrációdat véglegesen kitiltottuk a következő ok miatt: III.10.8 Üdvözlettel: PROHARDVER!

Abu: korábban beszélgettünk már arról, hogy maga az OpenCL-es HEVC támogatás akár egy középkategóriás ARM megoldáson is elszaladgálhat.
Arról van információ, hogy a 4K felbontású gyorsításnak mi a minimum követelménye? Pl. működik-e A8, A10 és FX mobil APU-kon?

GrassFX-et talán érdekesebb lett volna egy alacsonyabb szintű VGA-n tesztelni, kicsit vicces ez a 90 vs. 98 fps. Bár lehet itt az volt a cél, hogy kifejezetten GPU igényes környezetben prezentálja a kooperációt.

"GrassFX-et talán érdekesebb lett volna egy alacsonyabb szintű VGA-n tesztelni, kicsit vicces ez a 90 vs. 98 fps."

Nem kicsit

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Mivel a HEVC eleve GPGPU-t figyelembe véve lett megtervezve, így elég gyengus IGP is elég hozzá. 150-250 GFLOPS kb. mindennel megbirkózik.

A 6-10 fps közötti pluszt jelent, ha kirakod a munkát egy olyan gyors IGP-re, mint a Kaverié, bár ez nagyban függ attól, hogy a leképzésnél még mit csinál a dedikált GPU. A GCN-ek eléggé hatékony asszinkron rendszerek. Azoknak ez annyira nem fáj, mint a többinek. Régebbi Fermi/Kepler GeForce-hoz képest lehet +20 fps-t is nyerni az IGP-s opcióval. A HyperQ-s/NP-s GeForce-ok már hatékonyabbak.

[ Szerkesztve ]

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

Árakról tudunk valamit? Egy A10-7800-as lehet, hogy játszana év vége felé.

Én kérek elnézést!

Nyitóárak. A6-7400K még nincs a kínálatban.

[ Szerkesztve ]

solfilo

Nálam semmi se billen az Intel felé. Max a középsőujjam.

Rácuppannék arra az 7600-ra, csak hát semmi értelme egyelőre.

Nem!

Az ajánlott árak:

Szóval a 7800 le fog jönni 40.000,- környékére, a 7600 meg 30.000,- alá valószínű.

[ Szerkesztve ]

Ha az A8-7600 ára úgy viszonyul majd Ft-ban az 105$-hoz, mint most az A10-7850K ára a 173$-hoz képest, akkor nagyon jó vétel lesz.

solfilo

Elnézve a 7600 teljesítményét a 7800-hoz képest, valóban jó vétel lehet majd egy 30k körüli/alatti áron. A 7800 igazából csak az IGP tekintetében tűnik erősebbnek, nem éri meg a felárát.

Benchmark: Anandtech ; Hexus

Kisebb "K"-s modellekre leszek még kíváncsi tuninggal, sajna azokat nem tesztelték még.

Pont így, az A10-7700K sem éri meg az árát a kisebb tesóhoz képest. Azt hiszem az A8-7600 a Kaveri sweet spotja. (csak álljon be szépen az ára)

solfilo

Na végre megtudtam, mire jó az IGP játékos szemszögből. Ideje volt már.

Az önvezető autó olyan, mint az önmegivó sör.

A 4K kódolás miatt több fórumon reklamáltak, hogy míg Intel és Nvidia már hardveresen dxva keretében lehetővé teszi a gyorsítás AMD ezt még mindig nem támogatja. Ha ezt a funkciót pl. PowerDVD-hez köti AMD, két probléma van vele: nem multiplatform, nem ingyenes.
Korábban legalább támogatták VLC-t még ha csak egyes effektek szintjén is.

Kicsit OFF: Carrizo tekintetében felmerült, hogy mekkora problémát okozhat az L2 cache felezése. De ez először Llano-nál nőtt magonként 1 MB-ra.
Ha belegondolok pl. egy 45 W-os 4x512 K L2-es Athlon II X4 nem nyújtott teljesítményt.

A6-3650 100 W 2.6 GHz
CB 11.5 multi: 3.16 single: 0.8

Athlon II X4 620 95W
Athlon II X4 620e 45 W 2.6 GHz (új stepping tán válogatott is lehetett)
CB 11.5 multi: 2.99

A10-5700 3.4/4 GHz 65 W
CB 11.5 multi: 2.94

Nem a 4K-ról van szó, hanem a HEVC-ről és a H.264-ről. Az AMD szerint a HEVC-re kell gyúrni, mert az a jövő, így a H.264-en a 4K-val már nem foglalkoznak. Az NV és az Intel nem igazán szeretné ezt a HEVC-s jövőképet még, mert bár kétségtelen utóbbinak az előnye, de az AMD sokkal több pénzt és energiát ölt a 4K HEVC-be, és ebben nagyon hátrányban vannak hozzájuk képest. Ezért akarják, hogy a 4K még maradjon a régi formátumon, és ezért a HEVC-re mostohán néznek.
Igazából most ketté szakad a piac. Az AMD, az ARM, a Qualcomm például készen áll a 4K-s HEVC-re és nem foglalkoznak a 4K H.264-gyel, míg az NV és az Intel számára kell még egy év ahhoz, hogy teljesen elkészüljenek a fejlesztésekkel, ezért ma a 4K H.264 prioritás.

Valamennyivel gyorsul tőle a Carrizo, de nem sokkal.

[ Szerkesztve ]

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

Világos, eszerint AMD mintegy átugorja a 4K H.264-et. Bár tekintve, hogy H.265-nek éppen nagyobb a HW igénye mint H.264-nek, teljesítménybeli akadálya nem lenne a régebbi szabvány támogatásának sem.

Carrizonál éppen arra céloztam, hogy AMD úgy találhatta, hogy többet nyer az L2 cache felezésén fogyasztásban, mint amennyit teljesítményben veszít.

Nagyobb teljesítményigény vagy sem a HEVC jobban tömörít és ez kell a 4K-hoz. A H.264-es 4K tartalmat túl nagyok. Nem látják értelmét. A 4K tömegesen a HEVC-n fog terjedni.
A probléma az, hogy a HEVC-hez igazából senki sem akar dedikált hardvert tervezni, ugyanis egy ilyen blokk akkora, mint egy mai processzormag. A GPGPU-hoz igazított feldolgozás miatt tökéletes hardver a grafikus vezérlő. A gond csak az, hogy ehhez meg kell írni a szoftvert. Jön egy pár OpenCL dekóder, de az Intel az AVX2-höz akarja, míg az NV a CUDA-hoz.

A teljesítményért felezték. Így gyorsabb lesz, mert kisebb lesz a késleltetése.

[ Szerkesztve ]

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

Azt nemtom ki mihez akarja, de gyanítom ez elfut majd minden opencl kompatibilis cuccon. (sima gpu-n, vagy intel cpu-n is)
http://www.strongene.com/en/downloads/downloadCenter.jsp

[ Szerkesztve ]

A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

Nagyon igazad van.

duree54

A Strongene HEVC OpenCL dekódere csak olyan cuccon fut jelenleg, ami a cl_amd_media_ops/cl_amd_media_ops2 kiterjesztéseket támogatja. Nem véletlenül emelik ki, hogy ez ma only AMD. Egyszerűen az AMD írta és az AMD szállítja nekik. A kód módosítására nincs lehetőségük.
A Strongene alap HEVC dekódere egyébként támogat NEON-t és SSSE3-at. Emellett mondták, hogy lesz később egy HSA dekóder/enkóder. Ha xy gyártó mást akar, akkor finanszírozniuk kell a projektet, ahogy az AMD tette az OpenCL dekóderrel. Nem zárkóznak el az AVX/AVX2-től, vagy a CUDA-tól, de nem fogják maguk finanszírozni a fejlesztést. Ha az Intel és az NV ad rá pénzt, akkor mehet, ha nem, akkor HSA lesz, amivel használhatók a gyorsítók.

[ Szerkesztve ]

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

Nem hiszem, hogy komolyan foglalkozna vele az Intel és az NV. Valószínűleg majd ennek is egy dedikált hardveres dekóder lesz a vége, ami alig foglal helyet, keveset fogyaszt, és nem kell komolyan a szoftverrel szórakozni.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Ebben az esetben nincs előnye a dedikált hardveres blokknak. A HEVC-t a nulláról úgy építették fel, hogy a GPGPU-nak kedvezzen. A szoftverfejlesztőknek, mint a Strongene a HSA nagyon egyszerű kihasználást jelent majd.
A Tensilica-nak lesz egy dedikált hardveres blokkja rá, de az is ~8mm2-es 28 nm-es TSMC node-on. Majdnem annyi helyet foglal, mint két Jaguar/Silvermont mag. Egyszerűen nem éri meg két magnyi helyet egy dedikált blokkra elhasználni, ha a feladat GPGPU-val hatékonyan megoldható.
Ugyanerre a következtetésre jutott a Qualcomm is. A next-gen lapkákból kihagyják, mert Adreno400-as IGP-n futtatva is energiahatékonyabb.
Szabvány szinten egyébként a SYCL és a SPIR is nagy segítség.

[ Szerkesztve ]

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

"A Tensilica-nak lesz egy dedikált hardveres blokkja rá, de az is ~8mm2-es 28 nm-es TSMC node-on. Majdnem annyi helyet foglal, mint két Jaguar/Silvermont mag. "

Akkor majd az Intel megcsinálja harmad vagy negyed ennyiből a saját technológiáján.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Nyilván zéró tapasztalattal elsőre jobbat alkotnak majd, mint a régóta DSP-ben utazó Tensilica. Nem mellesleg az Intel is Tensilica licencelő, igaz ma már csak az audio DSP-re vonatkozóan. A video DSP-ket a SWARM64-től licencelik. A Qualcommnak van még licencelhető HEVC blokkja, de az majdnem kétszer nagyobb, mint a Tensilica érkező megoldása.
A másik lehetőség még a Keystone, de ők eléggé alap blokkot kínálnak. Ez van a Mediatek cuccokban.
Az a baj, hogy 200-300 GFLOPS-nyi DSP teljesítményt nem igazán lehet komolyan 8-12 mm2 alá gyűrni.

[ Szerkesztve ]

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

"Nyilván zéró tapasztalattal elsőre jobbat alkotnak majd, mint a régóta DSP-ben utazó Tensilica."

Hány hasonlóra láttunk már példát? Pl. ott az integrált memóriavezérlő, de még lehetne sorolni.

Ha szükséges és megéri, akkor majd saját blokkot készítenek.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

És miért érné meg? Oké tegyük fel, hogy ma nekikezdenek és 2019-re talán leterveznek egy blokkot. Eközben lényegesen olcsóbb lenne megdobni pénzzel a szoftverfejlesztőket, hogy írjanak támogatást az Intel hardverekre. Azt meg kötve hiszem, hogy ha a Tensilicának nem sikerül a szükséges teljesítményt begyűrni x mm2 alá, akkor másnak fog. Nézd meg a többi blokkot. A Qualcommé sokkal több helyet foglal (még az IGP-jüknél is többet). Ők sem hülyék ám, csak nincs mögöttük olyan tapasztalat, mint a Tensilica mögött.

[ Szerkesztve ]

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

Lényegesen alacsonyabb fogyasztás, és nem kell szívni a szoftveres résszel.

2019-re? Egy ilyen blokkot legfeljebb 1,5-2 év alatt összedobnak ha nullról indulnak. 5 év alatt felhúznak egy komplett x86-os mikroarchitektúrát.

Sanszos, hogy már nagyban dolgoznak rajta.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Nincs lényegesen alacsonyabb fogyasztás. Pont azt mérte az ARM és a Qualcomm, hogy GPGPU-val legalább olyan energiahatékony.
Dehogynem kell szoftveres rész. Azt nem varázsolja oda senki. Ezek a DSP-k ugyanúgy programozhatók, mint a CPU-k és a GPU-k. Persze nem olyan kötetlenül, de ugyanúgy meg kell írni a kódot. Persze meg lehet OpenCL-ben. A Texas Instrument C64x DSP-k már támogatják ezt a nyelvet, szóval ki lehet használni ezt az előnyt.

Ja és gondolom kutatás az nincs is. Valaki majd kilopja a doksikat egy DPS-s cégtől.

Sanszos, hogy nem, mert sokkal olcsóbb az IGP-re írni támogatást és kész. Ez már a Haswellre benne is van a béta driverekben (igaz még nem 4K-ra), csak még nem használja egy program sem. Meg kell dobni a fejlesztőket egy kis pénzzel, hogy ránézzenek erre a lehetőségre is.

[ Szerkesztve ]

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

Ja, egy 1,5 wattos ARM prociban lehet hogy ezt mérték, de egy 10-20 vagy netán annál magasabb TDP-jű modellre ez már nem állná meg a helyét.

nem kell szívni a szoftveres résszel =/= nem kell szoftveres rész

"Ja és gondolom kutatás az nincs is. Valaki majd kilopja a doksikat egy DPS-s cégtől."

Liszenszdíj a varázsszó.

"Sanszos, hogy nem, mert sokkal olcsóbb az IGP-re írni támogatást és kész."

Olcsóbb, és gyorsabban megvan, csak éppen rosszabb a hatásfoka. Ahol pedig majd az alacsony fogyasztásra játszanak (x86 tablet, ultrabook), ott jól fog jönni a dedikált egység, és meg fogja érni, a büdzsébe pedig simán belefér.

[ Szerkesztve ]

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Két dologhoz szólnék hozzá:

1. FluidMotion: mivel legutóbb az erre vonatkozó hsz-emre nem érkezett válasz, így bátorkodom újra elővenni, ugyanis azóta a kérdéseim a témára vonatkozóan nem változtak.

2. GrassFX: érkezik a TressFX rokona, ez mindenképp dicsérendő és fantasztikus dolog, leginkább a szabvány miatt, illetve, hogy végre használják az OpenCL-t játékokban is. Milyen játék(ok)ban láthatjuk majd ezt az új technológiát?

Gameplay csatornám: https://www.youtube.com/channel/UCG_2-vD7BIJf56R14CU4iuQ

Itt inkább a pJ/FLOP mutató a lényeges. Azért mérték ezt, mert a GPU-k pJ/FLOP mutatója nagyon közel van a DSP-kéhez. Másrészt a HEVC-t eleve GPGPU-ra tervezték, tehát maga a feldolgozás jobban illik GPU-ra, mint DSP-re.

A szoftverrel így sem kell igazán szívni. Amit az AMD csinál az csak egy saját költségen fejlesztett rendszer. A Strongene eközben önköltségen fejleszti a saját HSA megoldását és a natív CPU-s opciót. Az AMD csak első akart lenni. Azok lettek és az élet megy tovább.
A programozási nyelv és modell inkább egy döntés, és nem technikai probléma. Ha megvan a pénz, akkor természetesen mehet a vector intrinsics, de ez költségesebb például az OpenCL-hez viszonyítva. Meg kell nézni, mit enged a pénztárca. A Strongene kétségtelenül a legolcsóbb opciót választotta a HSA-val.

[ Szerkesztve ]

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

Bár az AMD a forrást nem teszi nyílttá és a technikáról nem beszélnek részletesen, de a CyberLink szerint a működésben igazából nincs lényeges eltérés a többi megoldáshoz képest. Ahol az AMD rendszerének előnye van az a fogyasztás. Ott hajtják végre a feladatot, ahol az energiahatékonyabb. Ez ugyanakkor a hátránya is, mert ezért igényel Kaveri APU-t.

Főleg a Nixxes érdeklődik ezek iránt. Szóval leginkább a Square Enix játékokban tűnhet fel. Az EA mondta, hogy nekik elég a Mantle, a kutatás-fejlesztést ezután megoldják, csak legyen egy használható API. Szóval az EA játékokban kevés az esélye, hogy lesz Tress/GrassFX. A többi meg kétesélyes.
Szvsz az EA-nek van ebben igaza. Mindenki fejlesszen saját technológiát. Most már arra sem lehet hivatkozni, hogy nincs low-level API.

[ Szerkesztve ]

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

Köszi a választ!

Nekem így elsőre semmivel nem előnyösebb a FluidMotion, mint a Mirillis megoldása, főleg, hogy ugye a lengyel csapat fejlesztése minden gépen működik, ahol van SSE2 utasításkészlet a CPU-ban. Igaz, ez CPU-val számol, tehát szoftveres. Gondolom az AMD megoldása már hardveres, OpenCL-t valószínűsítek a háttérben. Kár, hogy az eljárásuk Kaveri exkluzív.

A GrassFX-et pedig pont FPS- játékokban tudnám a leginkább elképzelni, legfőképpen egy Far Cry epizódban, oda illene a legjobban. Mondjuk ha a Nixxes beépíti a következő Tomb Raider és Hitman játékba, akkor az csak jó.
A TressFX-et idő közben a holland csapaton kívül más stúdió is alkalmazza a CryEngine-nel. Látsz esélyt arra, hogy a GrassFX-et is többen fel fogják használni?
Van egyébként valahol lista arról, hogy milyen játékokban lesz még TressFX? A Lichdom-ot tudom, illetve valószínűsítem még, hogy a következő TR játékban is lesz 2.0 verzió. Na de ezen a két címen kívül van még valami?

Én nem feltételen gondolom azt, hogy minden áron a saját technológia a jó, hiszen ezt csak szinte be kell másolni a kódba ozt jónapot és ez legalább nem egy fekete-doboz, mint a GW.

Gameplay csatornám: https://www.youtube.com/channel/UCG_2-vD7BIJf56R14CU4iuQ

Élőben kell látunk, hogy mennyivel előnyösebb vagy sem. A Splash 24p mellett elképesztő sok képi hibával interpolál, gyakorlatilag házimozi felhasználásra teljesen alkalmatlan eljárás ill szoftver, még alacsony beállításon is.

Az interpolálás alatt én 48, illetve 60 FPS-t értettem. Itt a Splash Pro két kattintással elintézi. Az már más kérdés, hogy előfordulnak képi hibák, az minden interpolációs technikánál előjön, nincs tökéletes algoritmus. Itt arra gondolok, hogy minden gépen két kattintásból aktiválni lehet a funkciót, ennél kényelmesebb és felhasználóbarátabb megoldást szerintem nem létezik.
A 24p-hez meg nem kell interpolálás, annyi a filmek eredeti képsebessége is, tehát ott a Motion funkciót alapból felesleges bekapcsolni, ekkor pedig semmilyen képhiba nem keletkezik. Nem értem miért mondod, hogy alkalmatlan házimozihoz. Én minden HD filmet ezzel játszom le és messze a legjobb lejátszó, amivel valaha találkoztam.
A Motion nevű interpolációs funkciójánál nem szabad kiválasztani a 10-es fokozatot, mert ott valóban túl sok a képi hiba, mert túl agresszív a kód. A 60 FPS-hez a 6-os fokozat tökéletes, ezen a fokozaton kapod a legkevesebb képhibát 60 FPS mellett. Azt sajnos el kell ismerni, hogy Motion meglehetősen régi, elavult kód, sokat lehetne rajta még csiszolni. Sajnos azonban a fejlesztőbanda valami teljesen érthetetlen oknál fogva úgy döntött másfél évvel ezelőtt, hogy befagyasztanak minden Splash-hez kapcsolódó fejlesztést. Gyakorlatilag tehát halálra ítélték a programot, ami nagyon nagy kár szerintem. A cég most minden erőforrását az Action nevű felvevő szoftverre csoportosította.

#40: Szoftveres alatt úgy értetem, hogy az algoritmus kizárólag a CPU-ra támaszkodik, az IGP-hez és dGPU-hoz nem nyúl hozzá. Az OpenCL kód már hardveres, mert ott IGP és dGPU is dolgozik.

[ Szerkesztve ]

Gameplay csatornám: https://www.youtube.com/channel/UCG_2-vD7BIJf56R14CU4iuQ

Az AMD-é HSAIL-ben van írva. Az nagyjából assembly szintű kód.
Egyébként semmi akadálya, hogy OpenCL-ben is legyen ilyen. Bele kell rakni a pénzt és ki kell fejleszteni. Az AMD-től nem érdemes univerzális megoldást várni, ezt a szoftverfejlesztőknek is el kell fogadniuk.

Igen sok fejlesztővel beszéltem már ezekről. A TressFX és a GrassFX típusú megoldások a csúcsminőséget képviselik, aminek a hátránya, hogy viszonylag drága effektek az erőforrásigény szempontjából. A legtöbb fejlesztő jóval egyszerűbb szimulációban gondolkodik, amelyek akár negyedannyi erőforrásból is megoldhatók. Vannak a gyártóknak nagyszerű effektjeik, amelyekre ténylegesen lehet építeni. Az Intelnek ilyen a compute HDR-je, a CMAA, az AMD-nél a HDAO, CHS, bilateral filter, compute particles, forward+ és PPLL koncepciók, míg az NV-nek a HBAO, az FXAA, stb. Ezek full szabvány opciók és tényleg reális megoldások bizonyos problémákra. Legfőképpen a teljesítménynövelő eljárások. Az AMD TressFX, GrassFX, az NV HairWorks stb. már más kategória. Ezeknek vannak követelményeik. Helyenként elég durvák. A TressFX karakterenként két UAV (DX11-ben nyolc van összesen egy futószalagra), a HairWorks csúnya eredményt ad a deferred motorokban (ma is ilyen egy csomó: Frostbite, CryEngine, Unreal Engine, Unity, stb.) ... Ezek mind problémák, alkalmazkodni kell hozzájuk, ezért lesz egy olyan csoport, amely szerint megéri (például Nixxes), de mások szerint ez nem teljesen az az irány, ami segít a PC-n. Az ok is egyértelmű. Régen a GPU-s cégek nem igazán fejlesztettek effektet. Egyszerűen ezt megoldották a fejlesztők. Amiért ez a háttérbe szorult, hogy a DirectX a fejlesztők útjában áll, és nem tudnak már úgy effekteket írni, ahogy régen. Vissza is szorult a PC-s R&D, pedig ötlet az lenne, csak nincs értelme úgy belevágni, hogy lehet, hogy nem lesz belőle semmi. Ezért mondta az EA, hogy nekik nem gyártó által kidolgozott kész effekt kell, hanem egy olyan API, amiben lehet fejleszteni. Ez a kulcs szerintem is, mert az R&D minden stúdiónál ott van, hiszen rengeteget költenek a konzolra, és minő véletlen ott képesek új effekteket kidolgozni.
Szóval ez a gyártó adja az effektet az nem az a jövő, ami tartósan fenntartható a PC-ben, mert szinte mindenki más motort használ, és nehezebb egy effekthez alkalmazkodni a motorból, mint a motorhoz tervezni az effektet. Persze csak akkor, ha van olyan API, ami működik, de látod, hogy a Mantle és a DX12 ebbe az irányba megy, tehát hosszabb távon az EA modellje lesz a nyerő.

Ami szerintem reálisan fenntartható az egy közös effektgyűjtemény. Pár cég összefog és bedobnak egy ilyet a GitHUB-ra, amit aztán szabadon módosíthat xy fejlesztő, és ez egy állandóan fejlődő, nyílt rendszer lenne. Ez egy teljesen reális lehetőség az általános problémákra, de a specifikus gondokat mindenképp házon belül kell mindenkinek megoldani az adott motorhoz igazítva.

[ Szerkesztve ]

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

Köszi!

Van arról valami nfó, hogy mely játékokban lesz GrassFX? Az világos, hogy eddig kizárólag a Nixxes érdeklődik iránta. Na de mely Square Enix játékba illik bele ez a technológia? Legfeljebb a TR-ben és a Hitman-ben tudnám elképzelni, de a TR-ben valószínűleg ugye lesz TressFX, így kétlem, hogy a holland banda mellé rakna még egy GrassFX-et, pláne, hogy mennyire erőforrás igényes.
De hogy látod ezt Abu? Szerinted mely címekben juthat szerephez a GrassFX?

Gameplay csatornám: https://www.youtube.com/channel/UCG_2-vD7BIJf56R14CU4iuQ