- AMD Navi Radeon™ RX 9xxx sorozat
- Milyen videókártyát?
- 3D nyomtatás
- A héten érkezik az Xbox alkalmazás az LG okostévékre
- Milyen billentyűzetet vegyek?
- Hobby elektronika
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Házimozi belépő szinten
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
1. Nem kell közvetlen programozás. De a köztes rétegek mindig jelentenek némi veszteséget a teljesítménynél. Ezt kell minimalizálni.
2. Ez még most is magas szintű kód lesz a programozó szemszögéből. Főleg annyi változik, hogy nincs megtiltva a VRAM-hoz való hozzáférés.
3. Mihez képest? Az is rengeteg időt emészt fel, hogy beírsz egy kódot és nem úgy működik, ahogy eltervezted, de nem tudod meg, hogy hol a hiba, mert nem látod, hogy a driver mit csinál. A részben profilozhatatlan működés is időgyilkos.
-
-
haddent
addikt
Az utóbbi idő leginformatívabb cikke, nagyon hasznos olvasmány volt, köszönöm!
Bennem felmerült egy-két kérdés: én is próbálok egyszerűen fogalmazni/gondolkozni, C++, C# Java alapján (bár lehet, hogy hibás az elképzelés..): egy játékot megírunk valamilyen szinten, legyen ez most akár csak a játék motorja. A játék motorját egy alacsonyabb szinten írták még, ami egy (vagy több) API -val képes működni. Na itt kis megálló, ezen a szinten rengeteg háborút lehet nyerni és veszteni ez nagyon jól látszik az utóbbi időben. Nyilván a trehány hozzá nem értő programozói tervezést nem lehet pótolni, de tegyük fel, hogy a játék motorja jól van optimalizálva, hiszen ezt egyszer kell megírni, onnantól tizen X játék, X évig használja röhögve, akár egy teljes API életciklusig (mondom, feltéve, hogy teljesen optimalizált az adott jelenlegi API -val szinkronban
Az API életciklusa alattnem változikdehogynem, csak nem kéne, hogy változzon. De tegyük fel, hogy nem változik. Most érünk el az API - driver absztrakciós szintre. Szerintem még az én bugyuta egyszerű példámból is látszik, hogy már idáig is sok ember jól összehangolt precíz munkája kéne egy normális kódhoz. Innentől van teljes káosz csak igazán.
Itt, miért kell havonta, hetente naponta új eszközkezelő/driver? Miért nem elég egy hardver életciklusára néhány, nagyobb optimalizációs felfedezés utáni frissítés? Eddig feltettük, hogy minden adott és konstans, az (még) absztrakt utasításkészlet nem változik. Miért nem elég a gpu gyártóknak minden GPU -hoz egy "profilt" készíteni, ami a cikkben is tárgyalt optimalizációs lépéseket tartalmazza.Magyarán miért nem elég a legislegalsó szinten, épp a hardver előtt elcsípni az 1. szinten absztakt utasításokat és helyettesíteni azokat, egyfajta preprocesszor szerepet betöltve?
Ez egy "újrafordítás" lenne nyilván, hiszen egy sor kód cseréje lehet, hogy konstans gyorsít, de a nagyságrend nyilvánvalóan nem fog változni globális szinten. Ahhoz, hogy hülye triviális példa O(n^log2(n)) -ből O(n) legyen nagy legyen a mértéke nagyobb kódrészleteket kéne felismertetni és optmalizáltatni egyben, ez pedig valós időben nyilván lehetetlen.Na most akkor utoljára, újrafogalmazva a kérdésemet: miért nem lehet a játékokat kiadni a mai megszokott módon, majd telepítés közben otthon mindenkinek a saját, éppen aktív grafikus illesztője/drivere szépen átfésüli a kódot és optimalizálja a saját kártyájára? Olyat már meg se merek említeni, hogy a kedves gyártó adna ki tizen X féle optimalizált kódot és mindenki azt tölti be automatikusan ami neki kell?
-
Cathfaern
nagyúr
"Xbox One jó minőségben tudjon játékot PC-re streamelni"
Ha van egy Xbox One-om, miért akarnék PC-re streamelni bármit is?
Játszok akkor az Xboxon... Vagy felhős szolgáltatásként? Szerintem azzal az MS nem fog tudni mit kezdeni, ahhoz az internet infrastruktúján kéne javítani, hogy drasztikusan alacsonyabb pingek legyenek. -
Bundyta
tag
Elolvastam a cikket, de néhány dolgot nem értek:
1. Vissza kell térni a hw közvetlen programozásához, mert a HAL-ek miatti ide-oda fordítgatás eleve nem olyan kódot generál, mintha a hw-t assembly-ben programoznák?
2. Nem vagyok videokártya guru, de számomra úgy tűnik, ahány videokártya, annyi féle hardware??? Mert ha igen, akkor szinte lehetetlen lesz assembly-ben olyan kódot írni, mely mindegyik kártyán jól fut.
3. Ha mégis valaki ezt megcsinálja, iszonyú sok időt emészt fel, kérdés, megéri-e?
Kissé úgy érzem a dolgot, mint anno a C-64-en:
- POKE-olás nélkül nem lehetett BASIC-ben grafikát, hangot sem kicsiholni a gépből
- jött a Graphic Basic, a Simon's Basic és ezt a terhet levette a BASIC programozó válláról
- de így is nagyon lassú volt a folyamat, plusz a GB vs SB programokat nem lehetett a másik "fordító" - pontosabban interpreter - alatt futtatni. Az eltérő utasításkészlet, ugyebár...Ezért át kellett állni az assembly nyelvű programozásra, hogy közvetlenül a hw-nek lehessen megmondani, mit csináljon. Egy előny volt: a hw nem változott félévente...
Egyáltalán ma megéri-e PC-n egy lefordított kódot kézzel optimalizálni a gyorsabb futás érdekében? Vagy a júzer vegyen egy gyorsabb hw-t???
-
FLATRONW
őstag
Igen, ezzel eddig is tisztában voltam (nem adhatjuk előbb össze a 3-at a 0,5-el) és már azzal is, hogy a MAD utasítás egy szorzás és összeadás sorrendjén alapul.
Most már inkább az a kérdésem, hogy miért nincs egy olyan utasítás is ahol előbb összeadunk majd szorzunk egy ciklus alatt? Ez az utasítás tökéletesen megfelelne az „(a+6)*0,5” példához.
Sokkal egyszerűbb lenne, mint optimalizáció címszó alatt 2 szorzás után eljutni „(a+6)*0,5”-ból „a*0,5+3”-ba, amit majd a számítógép a MAD utasítás segítségével egy ciklus alatt elvégez. -
Dare2Live
félisten
Melyik legacy HWvel, melyik low level APInál?
AMD(ATI):
-DX12: DX12 támogatás emlékeim szerint GCN1.0tól.
-Mantle: AMD(ATi)nál 7000es sorozatnál jött a GCN1.0 ~ehez köthetőő a Mantle. A mennyiség miatt mindenki GCN1.0át veszi alapul így nem lepne meg ha még 2016ban is boldog lennék a 7950emmel.NVnél nem tudom.
-
_Scythe_
aktív tag
válasz
Cathfaern
#15
üzenetére
Azzal együtt, teljesen egyetértek veled, egy dologról megfeledkeznek sokan: az alacsony szintű hw elérés opcionális. Így az indie (vagy kevésbé magabiztos, esetleg kevesebb erőforrással rendelkező fejlesztői gárdák) továbbra is írhatnak DX11-es kódot. Sőt, akár DX9-est is, ha a játék olyan. Továbbá ott van az OpenGL is, mint opció. Nyilván itt - ahogy Te is írtad - elsősorban az AAA kategóriás játékok fejlesztőinek vágya az alacsonyszintű elérés, nem a candy crush saga szintű csodáké, ami valjuk be, tök mindegy, hogy milyen renderert használ.
-
arcsi84
aktív tag
Szerintem ezt nem lehetne kivitelezni, mert ezzel az összes hardware gyártó (kivéve azt aki a konzolok hardware gyártását végzi) csődbe menne. Ha ugyanis egy mezei celeron és egy jó minőségű router elég lenne bármilyen játékhoz, akkor ez szerintem olyan ellenállást váltana ki a prominensebb gyártókból, amit nem gyűrne le egy könnyen a Microsoft.
Azért egy Intel/AMD/Nvidia gyártó koalíció, olyat üt mint egy IFA homok...
-
#40
pakriksz
őstag
Plazmacucci
#29
pakriksz
őstag
válasz
Plazmacucci
#29
üzenetére
Szerinted. A tesztek szerint, meg de
-
Abu85
HÁZIGAZDA
Igen az OS-t kékhalálba küldheti (de ezt low-level API nélkül is meg lehet oldani, ha nagyon akarod
![;]](//cdn.rios.hu/dl/s/v1.gif)
).
A grafikus hardverben nem tehet kárt, mert az eléggé védett így is, ha valami nem jó, akkor le fog kapcsolni, ellenben a fájlrendszert taccsra vághatja. Mérhetetlenül ritka, de nem lehetetlen olyan hibát előidézni, ami után lefagy az OS, és reset után többet nem bootol be (elveszik a partíció). Ezek kétségtelenül hátrányai a low-level elérésnek a sok előny mellett.
Egyébként ezekre figyelnek a fejlesztők. A Mantle és a DX12 low-level API-khoz van egy-egy validátor. Addig nem szabad szállítani az alkalmazást, amíg az hibát közöl a tesztelésnél. Ez nagyon fontos. -
LLKobe
veterán
Tényleg; laikusként kérdezem: ha a fejlesztők kezébe adják a direkt hardverelérést, az rossz kód esetén az egész windowst megfektetheti nem? Sőt akár kárt is tehet a hardverben?
Csak mert ha jól tudom a magas szintű API-k egyik nagy előnye hogy golyóállóak, és megvédik az oprendszert, max a progi crashel nem minden.
-
Abu85
HÁZIGAZDA
Írd be ide a forrást, hogy be tudjuk rakni a cikkbe.
(#33) Alchemist: Valószínűleg lesznek. Ezért nő meg a fejlesztők felelőssége.
(#24) Tazsam01: Nem lehet majd olyan kódot írni, ami x gyártón fut, de yz-n nem. Ez lehetetlen a DX12-ben. Olyan kódot lehet, ami x architektúrán jól fut, de yz-n már nem.
-
rudi
nagyúr
Lehet, hogy ezen a dolgon csavar egy jó nagyot a Microsoft és tényleg nagyon jól megcsinálja azt a csavart, hogy az Xbox One jó minőségben tudjon játékot PC-re streamelni. Onnan a fejlesztőknek csak Xboxra kell majd fejlesztenie, nem kell a sokféle PC-s hardverre optimalizálással szenvednie. Egyúttal az MS marketen és Xbox csatornákon keresztüli terjesztéssel a kalózkodásnak is oda lehetne vágni. A júzernek meg nem kellene állandóan a hardver frissítésével kínlódnia, lenne egy alap PC-je, ami fogadja az Xbox One streamjét és hello. Ha ennek tetejébe megoldanák rendesen a bill+egér kezelést és portolnák Xbox-ra azt a fél tucat online játékot, amivel a gamer populáció 80%-a játszik (LOL, DOTA, CS, WoT és társaik), akkor nagyon komolyan átszabnák a játékok világát. Elég sokan jól járnának vele és néhányan nagyon durván megszívnák.
-
#31
-Solt-
veterán
Plazmacucci
#29
-Solt-
veterán
válasz
Plazmacucci
#29
üzenetére
Ennek azért járj utána...
-
#05364992
törölt tag
Az ideális eset ez lenne, de hiba mindkét oldalon lehet. Eleve jöhetnek a motor frissítésben is nem dokumentált változások, amik adott speciális körülmények között gubancot okozhatnak (sok esetben azért is nincs dokumentálva valami módosítás, mert senki se gondolta volna hogy akárhogy is gondot okozhat). Ugyanennek egy másik verziója, ha a játék kódjából a motorban valami rosszul paraméterezve volt használva, de különféle "csillagegyüttállások" miatt mégis működött a dolog. (A határidő közeledtével általában egyre jobban kell sietni, és egyre esélyesebb hogy ilyen gondok nem jönnek ki mondjuk code review-kon, a teszten meg nem bukik meg, mert "véletlenül" működik.) Ebben ugye a legaljasabb hogy a renderer kódja a progi futásának 100%-ban dolgozik, de lehet valami mondjuk csak egy adott pályán jön ki, mert a bemenetek ott vágják ki az új verzióval a biztosítékot. Összefoglalva az egészet, én még nem látom hogy a pc hardver ilyen low level elérése hogy lenne egy pozitívabb jövő, inkább tűnik egy adott valós probléma túlreagálásának, mint megoldásnak. Szóval én a hobbi projektjeimen tuti maradok még d3d11.x-en, amíg csak lehet.
-
#29
Plazmacucci
félisten
Cifu
#10
-
-Solt-
veterán
Azért a konzol kicsit más kategória szerintem... ott eleve azért veszik már XY konzolt, mert XY játék arra jelenik meg.
Gondolod, hogy például az EA-t meg tudja fizetni mondjuk az NV, hogy a BF4 esetében lemondjanak cirka 1 millió AMD tulajról? Kétlem...pontosabban inkább remélem, hogy nem lesz ilyen.
-
#27
Cathfaern
nagyúr
bitblueduck
#22
Cathfaern
nagyúr
válasz
bitblueduck
#22
üzenetére
Ezt írtam én is
"Piacot célszerű szétbontani:
1. AAA kategóriás játékok...
1. Általában saját motort fejlesztenek"
És ők meg nem max., hanem pont hogy visszaálltak erre a módszerre. Ebbe is rokkant bele (majdnem) pár engine gyártó cég.
-
-
-Solt-
veterán
Az egyáltalán nem fog futni szerintem túlzás... egyik sem fog akkora támogatást adni, ami pótolná a kiadó bevételkiesését...
Gyártó specifikus hibákból biztos több lesz, viszont azokat már nem lehet majd a "szar" driverre fogni, így, ha ilyen lesz, akkor ott kilóg a lóláb...
-
bit_bro
tag
válasz
#05364992
#21
üzenetére
A teszteléstől nem mentesülnek, ez tény.
Viszont a motor fejlesztőjének részletesen kommunikálnia kell a változtatásokat, nem lehet egy "black box".
Egy engine update után mindenre kiterjedő teljes tesztet csinálni nem reális, de a változtatásokat azért le kell(ene) tudniuk ellenőrizni. -
#05364992
törölt tag
Szvsz meg nem oldja, max elodázza a problémát. A fejlesztési részt ugyan megoldja a motort szállító cég, de ha én az adott már kint lévő játékomba ki akarom rakni az új architektúrákra is optimalizált változatot, akkor az egész progit újra át kell küldenem a QA részlegen. Murphy törvénye hatványozottabban igaz a komplexebb rendszerekre, a kódbázisban (akár a sajátod, akár middleware) bármi bárhol is módosul, orosz rulett teszteletlenül kiadni. Ezek után én pl. elgondolkodnék hogy ez megéri-e nekem anyagilag, valszeg nemleges lenne a válasz rá, és innentől ott vagyunk ahol a part szakad. (De ez egyébként bármilyen kódbázisra áll, ha függőségben bármi változás áll be, tesztelni kell mindent, mert sose tudhatod pontosan mire van hatással.)
-
bit_bro
tag
válasz
#05364992
#18
üzenetére
A licenszelős modellel szerintem ez a probléma megoldható.
Lesznek cégek, akik elsősorban játékmotort fejlesztenek (Epic, Unity, Crytek, stb.), és ők meg fogják csinálni az optimalizálást az újabb GPU architektúrákra - hiszen elemi érdekük, hogy a vásárlóik (a játékfejlesztő cégek) egy "gyors" motort kapjanak.
A játékfejleszőknek csak arra kell ügyelniük, hogy kellőképpen modulárisan legyen megírva a program, hogy a licenszelt engine-t könnyen lehessen alatta update-elni. -
#05364992
törölt tag
Igen ez a probléma egyik fele, a másik az, hogy mi van ha a GPU-m frissebb mint a játék, és architekturálisan különbözik attól amire low level optimalizálták a motort. Ergo megvettem az új papiron erős videókártyát, és vagy ugyanúgy, vagy szarabbul fut rajta egy jó csomó nem feltétlenül régi cím. A gond nem csak elméleti, mert pl. a BF4 Mantle rendererének akadtak gondjai anno a Tongával. Összefoglalva a full low level elérés frankó ha a célhardver időben nem változik különösen, mint konzolok esetében. Az szvsz nem igazán várható el a fejlesztők oldaláról se hogy folyamatosan up to date tartsák a renderer kódot, hogy mindenhol jól fusson, egy idő után kezelhetetlenné válna a helyzet. (Arról nem is beszélve, hogy én tudom magamról, hogy egy-két ilyen taskkal történő szenvedés után hamar új munkahelyet keresnék, a mentális egészségem elsőbbséget élvez minden helyzetben, és ezzel szvsz nem vagyok egyedül.
) -
Cathfaern
nagyúr
Piacot célszerű szétbontani:
1. AAA kategóriás játékok
2. Középkategóriás játékok
3. Indie, vagy ahhoz közeli játékok1. Általában saját motort fejlesztenek, hatalmas szakember gárda és tőke áll rendelkezésre. Náluk jönnek elő az olyan problémák, hogy az absztrakció miatt nem tudnak egy-egy bugot javítani, vagy bizonyos funkciókat megcsinálni. Náluk lényegében ugyanannyi munkával is jobb minőséget lehet elérni, mivel amit elvesztenek a több fejlesztésen, azt visszanyerik a plusz funkciókkal és az egyszerűbb debugoláson
3. Esetek többségében nem fejlesztenek saját motort, licencelnek valamilyen megoldást. Ugye pár ember dolgozik a projekten, nincs se idő, se pénz a saját motorra. Őket nem érinti a dolog, a licencelt motorokat úgyis átírják DX12/Mantle-re, ők ugyanúgy csak használják amit eddig. Ha minden jól megy, náluk ugyananyi munkával jobb eredményt fognak elérni, de legrosszabb esetben is csak ugyanolyan lesz, mint eddig.
2. Na náluk van a probléma. Gyakran saját motort írnak, de nincs igazán kapacitás arra, hogy ezeket komolyan fejlesszék, illetve nagyon extra funkciókat bele tegyenek. Náluk plusz nehézséget jelent az új API, viszont hozadéka nem igazán van. Főleg ha a kód karbantartását is figyelembe kell venni. Jó eséllyel amúgy idővel ők is át fognak állni a licencelt megoldásra épp emiatt. -
nonsen5e
veterán
Azt nem olvastad, hogy a DX12 nVidia kártyákon is menni fog és jó lesz? Nem kell rögtön utálkozni.
Amúgy jól értelmezem (főképp a 4. oldalt), hogy akkor DX12 / Mantle alatt ha ugyanennyire lesznek jók a játékok mint most - mivel több felelősség lesz a kezükben, több dologgal kell majd foglalkozniuk ( míg több pénzt nem fognak kapni az biztos), akkor minek dolgozzanak többet? Tehát lesz két fajta játék? Az egyik csodálatosan fog működni, mivel a fejlesztők nem spórolnak az idővel, energiával, és a másik kategória - akik ugyanannyira fognak foglalkozni vele mint most és ugyanilyen, vagy még siralmasabb eredmény lesz végül? Vagy az egész API váltásnak, és annak hozományainak hála még úgy is jobban fog futni adott program, ha nem fektetnek bele külön több időt?
-
#11
RetepNyaraB
veterán
csakdzsó
#7
RetepNyaraB
veterán
a hsz-em lenyege viszont pont az volt, hogy nem feltetlenül van barmi haszna egy uj meghajtonak, plane nem eszeveszetten cserelgetni minden uj megjeleneskor. A Shadow of Mordor pl. hibatlanul szaladt a 13.4-en ES random crashel az omegaval. A kartya persze nem uj (7870 XT).
-
#7
csakdzsó
tag
RetepNyaraB
#5
csakdzsó
tag
válasz
RetepNyaraB
#5
üzenetére
Én is most köpültem fel a gépemre(friss win7-re)a 14.12 omegát.Rögtön ráengedtem a Crysis 1-et.Eddig semmi gond.A zsuga egy Asus hd7870 dc2.
-
#5
RetepNyaraB
veterán
RetepNyaraB
veterán
Szep munka. Mindenesetre en ket hettel ezelöttig a 13.4-es drivert hasznaltam es csak nagy unalmamban nyomtam fel a 14.12-es omegat. Nehany random crash-en kivül mast nem vettem eszre
-
Egy alapvető kérdés azért még (számomra) tisztázatlan maradt. Mi lesz a "legacy" hardverekkel? Amik adott esetben elég erősek lennének még az adott játék futtatására, de már kívül esnek a fejlesztők "sweet point"-ján?
Játszok akkor az Xboxon... Vagy felhős szolgáltatásként? Szerintem azzal az MS nem fog tudni mit kezdeni, ahhoz az internet infrastruktúján kéne javítani, hogy drasztikusan alacsonyabb pingek legyenek.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
).
Új hozzászólás Aktív témák
Hirdetés
ph Ma már szinte minden új programhoz új eszközillesztő kell. Megvizsgáljuk, hogy miért, és hogy lesz-e változás a jövőben.
- BESZÁMÍTÁS! 1TB Samsung 980 PRO NVMe SSD meghajtó garanciával hibátlan működéssel
- LG 65C4 - 65" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - 1000 Nits
- Bomba ár! Dell Latitude 3510 - i5-10GEN I 8GB I 256SSD I 15,6" FHD I Cam I W11 I Garancia!
- AKCIÓ! ASUS PRIME Z390-P i5 8600K 16GB DDR4 512GB SSD RX 6600 8GB GDDR6 DEEPCOOL Matrexx55 630W
- ÁRCSÖKKENTÉS Dell latitude E5430 eladó
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest