- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen házat vegyek?
- Azonnali informatikai kérdések órája
- Nikon Z MILC fényképezőgépcsalád
- Xiaomi Pad 6 - kiapadhatatlan jóság
- Milyen TV-t vegyek?
- Fejhallgató erősítő és DAC topik
- Acer M511: kompakt projektort próbáltunk ki
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Milyen videókártyát?
Hirdetés
-
Empire of the Ants - Az év végétől építhetünk saját hangyabirodalmat
gp A valós idejű stratégiai játék a tervek szerint novemberben debütál PC-n és konzolokon.
-
Az AI függővé teszi a bankokat a big tech-től
it A bankok szerint a nagy AI-népszerűség fokozza majd az amerikai big tech cégektől való függőségüket, ami új kockázatok teremt.
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
Új hozzászólás Aktív témák
-
sayinpety
tag
Osszeteveszted az optimalizalast a hardware teljesitmenyevel. Az R9-290X azert gyorsabb, mert a hardware gyorsabb. Az outsourcing strategiahoz semmi koze. A Maxwell 2 front-end limites. Ma nem latszik, mert az API a korlat, am Direct3D 12vel a hardware korlatok szamitanak. A GCN eros IP fine-grain async task schedulingre tervezve. A Maxwell nem.
Az outsourcing celja a rugalmassag. Kihozzuk a GPU IPkbol a legtobbet, am nem garantaljuk, hogy GTX980/Titan-X gyorsabb lesz R9-290Xnel. Ez nem cel. Az µarch kepessegei szamitanak.
Pascal jobb µarch lesz. A Tonga/GCN1.3 tobb kepessege elerheto lesz. DPP cross-lane ops, fast context switch, hard preemption, compute fast path, etc. Maxwell csak egy mobile kitero. Nem jon belole Tesla sem. Az igazi compute µarch a Pascal. -
sayinpety
tag
Az AMD resze a GAB/ARBnek. Nem akarnak rosszat! Velemenyem szerint ha nem tesznek ostobasagot jobb az iparagnak, hogy az AMD diktal. Jogos az Intel/Nvidia aggodalma, am a GAB/ARB alkalmatlan.
Nem vagyok tagja a GAB/ARBnek, am Inteltol tudom az AMD hamar beszel tervekrol. Ha nem elnek vissza hatalmukkal, akkor az iparag jol jart. -
-
sayinpety
tag
Nehez megallapitani, am nem tunik jonak az LDS usage. Optimalizalatalan kodjaim jobbak.
Velemenyem szerint senki nem erti mi baja Nvidianak. Harom ev mulva az Intel nem kinal tobb cserelheto CPUt. 2018ra 6-7 TFLOPS IGP, 32-64GB HBM, 1-1,5TB/s chip jon PCIExpress nelkul, 200-250 watt a TDP budget. AMD maganak tervez PCIExpresst, am tul pici a piac. 2020ra feladjak ok is. Nvidianak ket eve van megmutatni, hogy a GRID cloud gaming uj PC Gaming. A GameWorks ennek resze, ahogy a dokumentaciok hianya. Fusson rosszul az application, az a jo. Nem ertek egyet vele, am nem tehetnek mast. Meglatasom szerint az Intel nem gondolja meg magat. Tobbszor beszelgettem veluk. Nem akarjak az Nvidiat. A Federal Trade Commission egyezmeny decembertol nem kotelezi oket, hogy biztositsanak 16x PCIExpresst.
-
sayinpety
tag
Jobb. Dev driverrel tilthato tessellation. Ugy a Hairworks ketszer gyorsabb GCNen. Am nem szamit, az LDS usage optimalizalas 4-5 ms budgettel felesleges. 0.2 ms nyeres nem eri meg. A tessellation belassitja.
- akarnak dedicated GPUkat eladni harom ev mulva.
- a GRID cloud graphics configuration medium-high szint.[ Szerkesztve ]
-
sayinpety
tag
Explicit API nem befolyasolja optimalizalast. Irhato kulon codepath Keplerhez, kihasznalhato lesz 192 shader/SMX. Velemenyem szerint nagyobb baj a 350 series driver branch. A Kepler shader complier register allocation romlott. Tobb registert foglal le, csokken a futtathato WARP szama. Independent workload optimalizalas hasznos, am csak akkor, ha register allocation optimalizalt. Kepleren 340 series driver branch jobb volt.
Gyulolok minden vendor specific compliert. Egy uj driver branch es elromlik a codepath teljesitmenye. Kezdhetjuk ujra a munkat. Napokban olvastam SPIR-V/LLVM converterol. Remelem mukodni fog es megkerulheto lesz minden vendor specific complier. Ha mas nem HSAIL binary szallithato.
[ Szerkesztve ]
-
sayinpety
tag
Megint sok felreertes. D3D valtas idoigenye engine prototype kerdese. Jelentos API modositas jelentos engine structure modositast igenyel. D3D10 lassan terjedt, mert draft specification utan indult a munka. D3D12 szerencses API. Az engine prototype lezajlott Mantlelel. Mantle support titkos, am rajtunk kivul 132 studio irt tamogatast. Sokan csak prototype celbol. A D3D12 alapja a Mantle. Vulkan alapja is. Mantle prototype jo D3D12/Vulkan valtasra.
MS nagyon sokat var D3D12tol. 70+ jatek egy ev alatt a terv, am velemenyem szerint nem szamolnak kesesekkel. Engine support alapjan teves szamolni. Szerintem kevesebb D3D12 jatek jon egy ev alatt.API nem ad IHV elonyt. GCN valoban jobb microarch asynchronous computetal, am ez hardware feature. APInak semmi koze hozza. GCN elonye csak a market share. Minden multi-platform next-gen engine design a GCNnek kedvez. Olvasom sok PC market share elemzest, am semmi koze a valosaghoz. Nagyon keves PC-only engine keszul. Sokkal tobb a multi-platform engine. Nem PC market share szamit engine design donteseknel, Xone/PS4/PC market share egyutt szamit. Engine design nem csak technologia kerdes, ma mar uzleti dontes. Kiadok rengeteg penzt fektetnek be. Legkisebb kockazat GCNre tervezni, mert Xone/PS4 elerheto lesz 6-7 evig. PC formalhato piac majd a user alkalmazkodik.
-
sayinpety
tag
Igen. D3D12 nagyon erdekes mobile projecthez. Overhead csokkentese uzemidot noveli. Van iOS es Windows 10 mobile side projectunk. Metal es D3D12 haromszorosara novelte az uzemidot OGLES/D3D11 rendererhez kepest.
AAA % nem tudok. Aki teheti valt! Sokkal olcsobb D3D12re portolni. Ma minden console engine runtime resource creation elvu, am ez nem mukodik D3D11en. Ennek atirasa sok ide es penz. Explicit APIval csokken a kockazat, sokkal kevesebb lesz a rossz port. Kiadok a D3D11 legnagyobb ellensegei. Tul sok penzbe kerul.
[ Szerkesztve ]
-
sayinpety
tag
Igen. Nagyon koltseges elavult PC APIkhoz igazodni. Az elavult driver model rengeteg penzbe kerul. Latjuk ha nem mukodik, am nem tudjuk miert. D3D12 olcsobb, mert vegre nincs tobbet kernel driver. Az engine atveszi a szerepet. Leegyszerusodik a hibakereses.
Biztosan nem kell azonnal minden D3D12 feature. R&D sem engedne meg. Elobb a problemakra kell megoldas. Multithreading, ExecuteIndirect, UAV Typed Load es asynchronous pipelining fontos. Tobbi feature kihasznalasara es innovaciora varni kell.
Velemenyem szerint D3D12 nagyon jo, am a HLSL IR rossz. MS bytecode optimizer vec4 alap, ma mar sok kart tesz. Mai driverek resze a reverse optimization. Xbox One shader complier mar sokkal jobb. 40%kal gyorsabb kodot fordit az MS bytecode optimizer hianya. PCn a D3D12 nem segit shader forditason. A SPIR-V jo lenne, am MS nem akarja tamogatni. Nem ertem a strategiat. Szerintem par MS engineer beleszeretett a HSAba. C++ AMP>HSAIL forditas kivalo otlet, en tamogatom, am nem minden IHV tamogatja.
Velemenyem szerint SPIR-V a jovo. Mindenki tamogatja, Vulkan API jon, OpenCL C++ tokeletes shader nyelv.
RRC nem befolyasolja hardware teljesitmenyet. Kevesebb loading screen lesz. A loading screen a kiadonk szerint megtori a jatekot. Tobb kutatast vegzunk a loading screen eltuneseert. -
sayinpety
tag
Ez tevedes. 4GB eleg. A problema csak software jellegu. Sajat engine meg D3D11 alatt sem hasznal 700MBnal tobb adatot. Amit nem tudok megtenni a regi adatok torlese. Tul sokaig tart. De nem hasznalja mar az engine semmire.
Nem profiloz az AMD driver. Virtualis memoriat kenyszerit video memory 512MBos reszere. A torolt allokalt teruletek atkerulnek. A torles felgyorsul. Csokken a stuttering es a CPU terheles. Az 512MBos resz management Mantle drivert hasznal. Tobbet nem mondhatok. Ha akarnak beszelnek rola. -
sayinpety
tag
Multiplatform title fejlesztese nem a PCtol fugg. Egy kiadot sem erdekel PC market share. Az R&D penz befektetesekor legutolso helyen van market share. Egy next-gen engine ot ev alatt termeli vissza a befektest. Szukseges egy ot evig biztosan elerheto architektura.
Nem ertem az async shader problemat. Miert ne hasznalna egy next-gen engine? Xbox One es PC D3D12 code megegyezik. Miert kapcsolnank ki async shader featuret PCn?
Nem ertem miert kanibalizalja eladasainkat az optimalizalas. :?[ Szerkesztve ]
-
sayinpety
tag
Nem lehet optimalizalni multiplatform jatekot konzoltol fuggetlenul. Nem eri meg fuggetlen technologiakat fejleszteni.
Xenos micorarch jelentosen kulonbozott az AMD Terascale micorarchtol.Miert nem fekszik Maxwellnek? Sajat engine avg. 18%ot gyorsul tole. Elnezest, nem ertem miert koltene nVidia penzt a gyorsulas letiltasaert. Miert vennem el a gyorsulast? Sok Geforce vasarlo nem orulne neki.
Nem ertem mi koze a Pascalnak async shader eleresehez. Async shader nincs micorarchhoz kotve.
Nem ertem miert kell GCNre valtani. Geforcera is optimalizalunk.
A kiadoknak multiplatform reszesedes miatt GCN a fokusz. Erre epul ket console. Jovore harom console. PC eladas tul keves, hogy beleszoljon a dontesbe. Sok PC port nem letezne console portok nelkul.
-
sayinpety
tag
Egy graphics, egy compute, egy copy queue celszeru. Hallottam tobb compute queue conceptrol, am nehez kivitelezni. Ket compute queue belefer, am ugyelni kell register allocationre. A shader csak 32 VGPRt hasznalhat.
GCN updatek folenye VRben nagy. GCN 1.0/Maxwell/Kepler nem eleg jo. Hawaii hatareset. Fiji es Tonga nagyon folyekony elmeny. Mashol kisebb kulonbseg lesz.
Nem tartom jo otletnek aszinkron compute pipelineok szamat novelni. Egy compute queue eleg. Registerekre figyelni kell. Tobb compute queue tul sok munkat igenyel.Igen. Virtual texture tileok benne vannak.
Nem. Az engine csak utasit allokalt terulet torlesere. A torlest WDDM es driver vegzi. Nincs befolyasunk felette. Explicit API mar mas. -
sayinpety
tag
FL szintnek semmi koze a D3D12 tamogatashoz: Direct3D 12 programming guide
FL szint tamogatasa nem szukseges optional function tamogatashoz. Minden function kulon detektalhato.
UE4 base D3D12 functiont tamogat MTCBR, multiengine, multiadapter, execute indirect. Egyetlen optional function a minimum FP precision. -
sayinpety
tag
Nagyon sok targyi tevedest olvasok. A D3D11 hasznalhatatlan. Keptelenseg tovabb eletben tartani. Tul sokat tema a grafika, am senki sem beszel a gameplay simulationrol. Evek ota nem fejlodik. Ennek a Microsoft az oka. D3D11 driver fejlesztese nagyon bonyolult. Velemenyem szerint senkie nem jo. Intele a legjobb, am az NV D3D11 driver legrosszabb. Tul agressziv threading, nagyon sokaig kell butitai a simulationt, hogy mukodjon.
D3D12 pont jokor jott. Tobb baratommal beszelgettem a Siggraphon. Mindenki tapasztalta, hogy tovabb kell butitani simulationt. Mar az AMD D3D11 driver is erosen multi thread, am szerencsere nem annyira, mint NV D3D11 driver. Intel D3D11 drivere meg nem multi thread. Ertik, hogy tobb kernel thread nem megoldas.
Szamomra D3D12 elonye a szabadsag. Nem veszi el a processort a driver. Lehetoseg a simulation javitasa. A szep grafika jo, am jatek nem ettol lesz jobb. Gameplay simulation nagyobb ertek. En ebben hiszek, am simulation javitasahoz uj API kell. -
sayinpety
tag
Volt szerencsem AotS jatekmenetet latni. Zsenialis. Velemenyem szerint nagy hatasa lesz. Vizsgaljuk egy hasonlo ur RTS fejleszteset.
Anonimkent elmondok egy titkot. Nem szeretnem, ha felreertenetek. A PC jatekfejlesztes draga. Minden IHV ad bizonyos anyagi tamogatast. Enelkul nem fognank bele AAA PC portolasba. Tul kockazatos. Penzert cserebe kiallunk E3on, elmondjuk Radeon/Geforce/Iris kiraly es kapunk penzt. Exkluziv magasztalas tobb penz. Am egyetlen IHV sem tamogat olyan jatekot, ahol grafika nem jobb a konzolnal. Szerzodesben rogzitik. Ezert butitjuk a simulationt.
A jatekfejlesztes uzlet. Legtobb penzt harom platform port hoz es IHV tamogatas. Senki sem tudja mit hagytunk ki a jatekbol megjelenesig. Grafika butitast eszre veszik, am ha tudnatok mi marad meg ki, nem erdekelne grafika. -
sayinpety
tag
válasz
schwartz #9264 üzenetére
Reszben a driver. Kis terhelesnel az en enginem lassabb NV hardwaren D3D12ben. Nagyobb terhelessel jon +30-50 szazalek. AMD sokkal jobban gyorsul +100-200 szazalek.
Szemelyes velemenyem szerint a Microsoft hibazott. Kevesen tudjak hogy szuletett D3D12. Evek ota rossz a D3D. D3D9 ota tart overhead csokkentes? State blocks, large state groups, deferred context. Mind bukas! Az AMD D3D11 megjelenese elott mondta a kernel graphics driver miatt nem gyorsulunk. A Microsoft arogansan mondta AMDnek mutassanak jobbat. Az AMD 2009re osszerakta elso prototype explicite APIt. Egyik kolegam szerzodtettek Sonytol. Ismerte a GCMet. 2009 vegen megmutattak mi lehet a megoldas. A Microsoft azonnal penzt ajanlott nekik a source codeert. A D3D12 alapja 2012es AMD prototype API source. Ezert hasonlit ennyire Mantle, D3D12, Vulkan. Mind harom AMD fejlesztes. Am az AMD sajat nezopontjabol fejlesztett. 2012 vegen keszult el elso D3D12 specification. Az Intel, NV szabalyosan ordibalt miatta. Kesobb kiderult AMD nem kert penzt source codeert, cserebe core specificationt meghatarozhattak. 2013ban jott a Mantle. A Mantle a Microsoftnak varatlan volt. Felgyorsult a D3D12 fejlesztese. Nem voltak vitak. Az Intel, NV lecsendesedett. A Mantle nagyobb fenyegetes volt, mint a D3D12 core specification. Tobbi ismert.
A D3D12 core specification AMDnek kedvez. Megkoveteli a multi-engine es binding reasources Tier3 codeot. Intel, NV szamara nem tetszik, hogy tobb az overheadjuk mint AMDnek. A Mantle miatt a Microsoft felelos. Szerintem maig banjak, hogy nem vasaroltak meg source codeot. A Microsoft es Khronos csak hasznalatra kapot jogot, am az AMD tulajdona maradt. Ebbol meg sok baj lesz!
Az AMD honapok ota kerdezi mire van szukseg. Rengeteg informaciot gyujtottek. Velemenyem szerint a tervuk veszelyes. Mire vitara kerul egy specification update mar hardware es Mantle updateje van AMDnek. Egy IHV sem fog vitazni, ha konkurens termek kesz. Liquid VR jo pelda. Az AMD minden vR specificationt leadott. Ha elfogadjak jo. Radeonhoz illo szabvany. Ha nem fogadjak el jo. Csak Radeonon mukodik. Az AMD velemenyem szerint manipulacioval elerte a piac iranyitasat.
A Gameworks ezert lett. Mindenki utalja a middlewaret, am nincs mas valasztas. AMD a ket konzollal kepes lesz gyorsan fejlodni. NV tehetetlen. A Gameworks celja a fejlodes megfogasa.Nem tartom PCt rossz piacnak, am teny rosszak az APIk. Mindenki nyugodt volt regen. Mindenkinek ugyanolyan rossz volt D3D, OGL, etc. Amikor kertunk jobb APIkat nem arra gondoltunk, hogy az AMD dolgozza ki! Nem szabad ekkora hatalmat adni IHV kezebe, mert annak eredmenye a kaosz. Ezert csak Microsoft es Khronos Group hibas.
-
sayinpety
tag
Volt szivas, am megoldottuk. Sajnos developer driverek sokat valtoznak, nem stabilak meg. Jelenleg multi-engine & sync code eredmenye +4% Geforce es +22% Radeon. Am mi software tessellationt futtatunk async compute modeban. Specialis eset.
Szerintem Nv tul ideges. Latszik rajtuk, am nem ertem miert. Tobb alternate pathot irtunk be enginebe fel ev alatt. Sokat segitett a Geforceoknak. Mar hasonlo teljesitmenyu a 980 es 290x. VR-tol felnek. Mi VR tamogatasunk nem lesz kesz jovore. Elmondtam nekik. Latszott rajtuk a megkonnyebbules. Vicces volt. :-)
Szerintem Nv tul optimista volt. Tobb programozojuk belatta nem jo a Gameworks. Hiaba hoztak 4 effektet, egyiket se tudom beepiteni. Legalabb egy evvel csuszna engine. A kiado nem orulne. Par uj Gameworks effekt hasznal conservative rasterizationt es ROVsot, am olyan enginerol nem tudok, ami tamogatna. En jovore kezdem tervezni az updatet. Akkor veszem szamitasba uj lehetosegeket. Ha minden jol alakul conservative rasterization es ROVs algoritmusokat harom ev mulva tudunk beepiteni. Nem varazsutessel fejlesztunk! D3D12 tul nagy update. Nem lehet mindent gyorsan tamogatni. A tamogatast eloszor alapfunkciokra korlatozom, plus multiadapter. Ha mukodik lepunk tovabb. Meg be kell epiteni a Vulcan APIt. Mantle miatt nem varok nehezseget, am par hetet elvisz.
-
sayinpety
tag
válasz
daveoff #10850 üzenetére
Draw-level preemption alkalmatlan virtualis valosagra. David Kanter megallapitasa jogos.
Async timewarp queue overloadhoz vezethet. Geforce driver nagyon rosszul reagal ra. A driver tolt fel egy queuet, am ugyelni a parancsok sorrendjere. Sajnos a software sokszor hibazik. A timewarp beszorul egy batch moge es sokat varhat. A driver nem rendelkezik eleg informacioval hogy meghatarozza meddig fog futni egy batch. Sajnos nemreg derult ki hogy a grid management hardware nem valtoztathat a parancsok sorrendjen.
Ket tenyezot vettem eszre Geforceon. Kiszamithatatlan a viselkedes. Barmikor beragadhat a timewarp egy draga batch moge. A timewarp futtatasa alacsony hatekonysagu. 45bol csupan 10-15 timewarp erkezik idore, tobbi lekesi a frissitest.
AMD implementacio sokkal elonyosebb. FuryXen sosem kesik a timewarp. Valamiert a Radeonon a DXKG alig hasznal processoridot. Geforceon elvisz egy Haswell magot, nem ertem miert. Talan sok szimulaciot futtat a runtime a helyes sorrendert? Radeonon talan ez azert nem kell, mert az ACE/HWS out of order hardware.
Nagyon furcsa, hogy Oculus miert egyetemesen hatarozza meg CPUt. Core i5 valoban kell Geforce 970hez, am Radeonhoz eleg Core i3, vagy kevesebb. -
sayinpety
tag
Csak tulterheles talan nem, am sync igen. Az NV grid management hardware nem kezel sync pontokat, am az AMD ACE/HWS hardware igen. NV emulalja implicit synchronizationt. Fuggosegelemzes rengeteg processoridobe kerul, ezert valoszinu lassulas. AMD hardwarenek nincs szuksege elemzesre, a ACE/HWS hardwareben kezeli implicit synchronizationt, nem igenyel processoridot.
-
sayinpety
tag
Az Ashes/Nitrous velemenyem szerint attores. Nem lattam jobbat. Neztem mit szamolnak, am sajan enginem nem tudna kiszamolni. 100+ shadow casting lights raadasul real-time. :-o
Nem ismerek enginet, ami nyolcnal tobbet szamol. Szerintem jatekok 99.99% maximum kettovel szamol.
Azt nem ertem hogyan generalnak ilyen gyorsan terraint. Nekem hasonlo minoseg 10 perc Corei7 5960x CPUn. Atlag CPUn fel ora. :-( AVX2t nagy remenyekkel fogadtam, am +10% nem segit. -
sayinpety
tag
válasz
Yllgrim #11391 üzenetére
Nekem a legnagyobb kulonbseg a profilozas/debugolas. D3D11ben sok tenyezot nem latok. Ha nem fut gyorsan a kod sokszor nem tudom megallapitani miert. Oruletbe kerget az IHV support. Vegre jo valami am jon egy driver, amitol rosz lesz. Elkuldom a kodot elemzesre, visszadnak egy masik kodot. Beirom elromlik a teljesitmeny masik hardwaren. Honapokig megy ez. D3D12ben latom mi tortenik. Latom a hibat, ki tudom javitani. Uj driver sem rontja el.
D3D11 rendererben volt olyan hiba, amit sosem sikerult javitanom. Barmit csinaltam egy IHV teljesitmenye mindig nagyon rosz lett. Tudtam mi a baj, am egyik IHV sem akart driveren modositani. Cserebe kaptam toluk kodot. Vegul az AMD kodjat epitettem be, mert csak picit lassitotta le Intel/Nvidia hardwareket.
D3D12ben visszanyertem a teljesitmenyt Intel/Nvidia hardwareken. D3D12 rendererben is volt sok hiba, am ket het alatt ki tudtam eddig javitani mindet. -
sayinpety
tag
válasz
#85552128 #11737 üzenetére
Anno 2205 felteteles multi-thread strategiat hasznal. Nvidia regota rendelkezik egy specialis multi-thread optimalizalassal, am a kod csak Maxwellen fut jol. A kod nem zart, am nem modosithato. Felteteles elgazassal fut a Maxwell optimalizalas, am a tobbi architecturara semmi. Keplerre sem. Kevesen hasznaljak.
Magam reszerol ilyen kodot sosem kerek, am hallottam, hogy a felteteles elagazas nelkul mindenen jol fut. Am nem adhato ki igy a program.
Regi Nvidia strategia a prev gen limitalasa. Nem AMD/Intel ellen iranyul. Keplert akarjak korlatozni. Jovore Maxwellt. Kesobb Pascalt. -
sayinpety
tag
Sajnos zart middleware beepitese nem egyszeru. A kikapcsolas nem segit. A zart kod meghatarozza a renderert. Sok hasznos optimalizalas nem mukodik. Nem fog mukodni tole az effect. GW SDKval sok PC renderert optimalizalas nelkul kell szallitani. Csak igy mukodik a GW middleware. Nagy szerencse kell az optimalizalt PC porthoz. Velemenyem szerintem a legjobb mar az elejen tudni a GWrol. Legalabb 1.5 evvel a megjelenes elott. 1.5 ev eleg ido, hogy jo PC renderer optimalizalas keszuljon.
Sajnos tobb kiado tul keson kot szerzodest. Par honappal a megjelenes elott nincs mit tenni. A GW middleware mukodeseert le kell butitani a PC renderert. Talan osszes optimalizalast torolni kell. Karba vesz sok munka. Hiaba kapcsolod ki az effectet az optimized renderer path mar nem erheto el.
Rocksteady hibazott nagyot. Nem tud mit kezdeni a Batmannal. Nagyon jol futott a GW integralasaig, am pre-build resource creationnel nem mukodott a GW. Vegul ki kellett kapcsolni minden renderer optimalizalast.
Middlewaret nyilt forraskod nelkul nem szabad hasznalni! -
sayinpety
tag
Enginefuggo.
Pentiummal ImmediateContext jobb Nvidian. DeferredContext AMDn. ImmediateContext /manual threading Nvidian.
D3D extensionnel MultiDrawInstancedIndirect es MultiDrawIndexedInstancedIndirect jobb AMDn.
4 core CPUval DeferredContext jobb lesz Nvidian. MultiDrawInstancedIndirect es MultiDrawIndexedInstancedIndirect marad az AMDn jobb. -
sayinpety
tag
válasz
Laja333 #13860 üzenetére
Velemenyem szerint mindenki ugyanabba a hibaba esik D3D12vel. Sokan Mantle APIn tanultuk meg az explicit GPU accesst, am a Mantle egy manual multi-engine API. Megkoveteli az explicit queueing modelt. Minden workloadrol manualisan kell donteni. Tobb munka, am atlathato. A D3D12 auto multi-engine API. Nem kovetel workload meghatarozast, kepes onmaga donteni melyik queue legyen felhasznalva. Ha copy engine nem letezik marad a compute. Ha compute engine nem letezik marad a graphics. Ebbol lehet galiba. Compute workloadot nem mindig jo compute enginebe tolteni, am a D3D12 auto multi-engine megteszi. Copy workload egyszerubb. Mindig jo a copy engine. Az auto multi-engine nekem nem mukodott. Lefutott a testcode, am sokkal lassabb volt a Mantle pathnal. Ma mar nem hasznalom az auto featuret computera. Copyra igen. Nekem ket compute scheduling forma valt be. Default path a long running compute outsource sema. Ismerem melyik workload okoz stallt. Melle elindithato egy compute workload. Alternate path a short running compute batch sema. Nagyon nehezen megoldhato, am talan eleg jo lesz a GPU usage a batchek vegeig. PCn a GCN default pathot, am a Kepler, Maxwell, Intel altenate pathot hasznal.
D3D12n nehezen kezelheto a signal update. GCN minden wavefront vegeztevel updatel, am Kepler/Maxwell csak a command list vegen kepes ra. Nincs ra jo orvossag sajnos. Szerencsere Pascal nem lesz elavult.[ Szerkesztve ]
-
sayinpety
tag
válasz
schawo #13936 üzenetére
Engem nem zavar a munka. Kepes vagyok ket pathot irni. Signal update sem erdekel, amig az overhead kezelheto.
Ami zavar a D3D12ben a tudas hianya. Mantle APIn es konzolokon van ds_swizzle_b32, ds_ordered_count, s_setvskip. D3D12ben egy sincs. s_setvskip hianyat tulelem, am a SIMD lane swizzle es ordered atomics hasznos. Sokkal lassabb nelkuluk a codepath. -
sayinpety
tag
Laborban az elso Pascal. Hatha erdekel titeket. Remelem nyaron kapok samplet.
-
sayinpety
tag
válasz
#85552128 #13988 üzenetére
PC kepes ra, am nincs hozzaferes. Amiota letezik D3D12 csak novekszik az igeny. Annyi mindent akarunk az X1bol PCre, hogy MS nem tud lepest tartani. Nem reg lattam felkerult az inactivated flush-to-zero on denormal support lehetoseg, harom eve kerjuk. Jo lenne tobb tudast vinni a PCbe.
-
sayinpety
tag
CUDAban nem kovetelmeny a barriers tamogatas. GMUk csak barrier free parancsokat kaphatnak.
D3D12ben DXKG manageli az utemezest. A main command processor OS vezerelt a CPU synchronization miatt. Sok hardwaredizajn nem erre keszult. Am a D3D12 ezert multi engine API. Betoltheto a parancs dedikalt egysegeken. Synchronization kovetelmeny lehet, am ha nem az OS vezerli nem kell ujra-utemezes, cache flush, etc.
-
sayinpety
tag
Nem lehet. Am hardwaret ra lehet tervezni. Velemenyem szerint Microsoft egysegesiteni akarja a hardwaredizajnokat. Talan hibasak vagyunk ebben. Sokat panaszkodtunk eltero front endekre. A DXKG kenyszeriti az IHVt az xBox One integrated GPU front end modelhez. Egysegesitesnek orulok. A modszernek nem.
-
sayinpety
tag
Factory overclock nem tul jo meglatasom szerint. Tesztre kaptunk regebben ASUS 980Ti Strix OC modelt az NVtol. Kesobb vettunk 8 darabot az ASUStol. Az NV press modelje a leggyorsabb. 6-9 szazalekkal gyorsabb a vasaroltaknal. Felbontatlan karton, gyari mukodes. Tipus ugyanaz. ASUS support mondta 11% performance gap lehet ket ugyanolyan 980Ti Strix OC kozott. Azota talaltunk megoldast boost tiltasara, am sok bonyoldalmat okozott. Sokaig nem tudtuk mitol lasult le a code ugyanolyan PCn.
AMDnel is tapasztaltuk, am csak 3 szazalakos kulonbseget mertunk. Sajnos AMDn nem lehet tiltani, am megengedik, hogy valogassunk. Ha 5 VGA kell kerunk 15ot. Abbol lesz ot ugyanolyan gyors. 10et visszakuldunk.[ Szerkesztve ]
-
sayinpety
tag
válasz
rocket #15893 üzenetére
A Sony erosebbet kapott. Akkor meg Naughty Dognal dolgoztam. A Thebe-H prototype SoC 1450MHz CPU es 650MHz iGPU volt. Az AMD jelezte belefer a TDPbe a nagyobb orajel. A Sony eredetileg a TDPt akart csokkenteni, am vegul az orejel nott. Microsoftot nem tudom, naluk nem dolgoztam.
-
sayinpety
tag
válasz
Locutus #15886 üzenetére
En ugy hallottam a Sonytol, hogy a Neo a VR miatt jon. Nagy potencialt latnak benne ezert akartak egy erosebb gepet.
A gaming market helyzete nagyon jonak tunik. A GPUOpennel vegre egyszerre fejleszthetunk konzolra es PCre. Koltsegkimelo es a PC konzol optimalizalast kap. Szerintem ehhez alkalmazkodni kell a konzoloknak.
-
sayinpety
tag
válasz
keIdor #16686 üzenetére
Hiba csak PC reszesedest szamitani. Cross-platform fejlesztesnel PS4+XOne+PC reszesedes szamit. Ha csak PC szamitan a NVre optimalizalnank, am console miatt GCN fontosabb.
NV kicsit panikol. Ma sok penzzel tamogatnak a Nintendot, ha Tegra kerulne az NX handledbe. Nintendo elgondolkodott rajta. Visszavontak a programmer's guideot. Bizonytalan mi lesz. Halottam, hogy NV evi 100 million dollart kinal a Tegra melle. Velemenyem szerint jo ajanlat. -
sayinpety
tag
válasz
Locutus #16693 üzenetére
Tenykent nem allitom. Nem dontottek. Csak visszavontak programmer's guideot. Melle kaptunk ertesitest. A target handled teljesitmeny felere kell tervezni. Inkabb nem tervezunk semmire, amig nem tiszta a kep. 1st party studiokat sajnalom. A hirtelen valtas nem jo. Elvenni a teljesitmeny felet roszabb.
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen