NVIDIA esitteli avoimen Streamline-ohjelmistokehyksen skaalaimille

[Kaotik]

NVIDIA on esitellyt GDC:n yhteydessä uuden Streamline-ohjelmistokehyksen skaalaimille. Streamline on avointa lähdekoodia ja se on suunniteltu helpottamaan pelinkehittäjien työtä; heidän pitäisi vain sisällyttää tuki ohjelmistokehykselle ja valmistajien skaalainten liitännäiset hoitaisivat lopun. Samaan ohjelmistokehykseen voidaan upottaa myös muita valmistajien liitännäisiä.
NVIDIAlta itseltään on tarjolla joko heti tai lähitulevaisuudessa DLSS:n ja DLAA:n lisäksi NVIDIA Image Scaling- ja Real-time Denoisers -liitännäiset, joiden lisäksi Intel on jo lupautunut tuomaan XeSS:n Streamlineen. AMD ei ole toistaiseksi ilmoittanut aikooko se tuoda omia liitännäisiään ohjelmistokehykselle.

Lähde: Streamline

 

[KVahlman]

Noni, hyvä hyvä. Juuri tälläistä liikehdintää markkinat kaipaakin kun kilpailevia tuotoksia on muuten työläs sisällyttää samaan softaan. Tietysti haasteena vielä saada pelikehittäjät käyttämään ko. APIa, kuten aina.

Hieman kyllä yllättää että juuri näinpäin että NVIDIA ajaa asiaa ja AMD ei ole mukana mutta ehkäpä sekin korjaantuu aikanaan.

 

[hik]

Toivottavasti Hardware Vendor #3 lähtee mukaan kisaan taistelemaan pronssista. Suorat vertailut olisi helppoja.

Mahtaako nämä liitännäiset tulla joskus DirectX:n osaksi?

 

[Nerkoon]

Noni, hyvä hyvä. Juuri tälläistä liikehdintää markkinat kaipaakin kun kilpailevia tuotoksia on muuten työläs sisällyttää samaan softaan. Tietysti haasteena vielä saada pelikehittäjät käyttämään ko. APIa, kuten aina.

Hieman kyllä yllättää että juuri näinpäin että NVIDIA ajaa asiaa ja AMD ei ole mukana mutta ehkäpä sekin korjaantuu aikanaan.

nVidian on pakko yrittää jotain. Tilanne kun on se, että AMD:n DLSS:n vastine on jo ihan nurkan takana ja se toimii kaikkien valmistajien korteilla, nVidian DLSS ei. Molempien implementointi peliin vaatinee suunnilleen saman ajan, joten pelikehittäjien ei kannata vilkaistakaan DLSS:n suuntaan, koska se toimii vain nVidialla. Jos nVidia haluaa DLSS:n ja muut nVidia only kilkkeet peliin, sen on pakko keksiä tapa jolla niiden lisääminen ei aiheuta juuri mitään lisähommia pelikehittäjälle.

 

[KVahlman]

Molempien implementointi peliin vaatinee suunnilleen saman ajan, joten pelikehittäjien ei kannata vilkaistakaan DLSS:n suuntaan, koska se toimii vain nVidialla.

Jätät huomioimatta sen että jos tekee toisen niin toinen on jo lähes ilmainen koska vaatimukset on käsittääkseni käytännössä identtiset. AMD itsekin on mainostanut että jos pelissä on jo DLSS 2.x niin FSR 2.0 menee sisään muutamassa päivässä. Miksi siis ei laittaisi molempia ja Xessiä vielä kaupan päälle, sekään tuskin poikkeaa radikaalisti integroinniltaan. Markkinointiarvoa löytyy heti kun voi mainostaa että kyllä meidän pelissä toimii kaikki, voit käyttää mitä haluat.

 

[zepi]

Nvidia on perinteisesti tarjonnut pelifirmoille jeesiä siihen, että implementoivat heidän featureitaan. Tulevat usein siis tosi vähällä työllä, kun nvidian koodarit vähän jeesaavat…

 

[Nerkoon]

Jätät huomioimatta sen että jos tekee toisen niin toinen on jo lähes ilmainen koska vaatimukset on käsittääkseni käytännössä identtiset. AMD itsekin on mainostanut että jos pelissä on jo DLSS 2.x niin FSR 2.0 menee sisään muutamassa päivässä. Miksi siis ei laittaisi molempia ja Xessiä vielä kaupan päälle, sekään tuskin poikkeaa radikaalisti integroinniltaan. Markkinointiarvoa löytyy heti kun voi mainostaa että kyllä meidän pelissä toimii kaikki, voit käyttää mitä haluat.

Päin vastoin: Miksi kuluttaa se 3-4 päivää lisää lisäämällä käytännössä saman asian tekevä toinen implementaatio kun yhdellä saa kaikki valmistajat kerralla? Se koodarin työ ei ole ilmaista ja noiden ylimääräisten lisäämisestä ei saa mitään käytännön hyötyä olemattoman markkina-arvon lisääntymisen lisäksi. AMD mainostaa tuota pelkästään siksi, että heidän versionsa toimii kaikilla ja nVidian ei.

Jos minä olisi pelikehittäjä, niin tiputtaisin pois ensimmäisenä vain yhden valmistajan vaihtoehdot ja sen jälkeen valitsisin parhaan jäljellejäävistä peliin lisättäväksi.

 

[KVahlman]

Päin vastoin: Miksi kuluttaa se 3-4 päivää lisää lisäämällä käytännössä saman asian tekevä toinen implementaatio kun yhdellä saa kaikki valmistajat kerralla? Se koodarin työ ei ole ilmaista ja noiden ylimääräisten lisäämisestä ei saa mitään käytännön hyötyä olemattoman markkina-arvon lisääntymisen lisäksi. AMD mainostaa tuota pelkästään siksi, että heidän versionsa toimii kaikilla ja nVidian ei.

No vältän puuttumasta siihen onko kuinka "käytännössä samasta asiasta" kyse ennenkuin FSR 2.0 on ulkona, mutta muutama päivä devaajan työtä on täysin merkityksetön investointi viiden vuoden projektissa. Väitän että jos markkinointiin saa ilmaiseksi NVIDIAn rummuttamaan että tässä hyvä peli kun on DLSS (kuten tuppaa tapahtumaan) niin kuka tahansa markkinaihminen maksaa devaajan työn vaikka omasta budjetistaan.

Mutta turha kai vääntää sen enempää, aikahan sen näyttää että siirtyykö kaikki FSR 2.0:aan kun muita ei edes tarvitse, onnistuuko Streamline tavoitteessaan vai jatkuuko meno nykyisen sirpaloitumisen kaltaisena.

 

[pomk]

Tämä myös mahdollistaa sen, että dlss voidaan integroida avoimen lähdekoodin projekteihin. Tämä interface kun on avointa ja millekkään NDA:n alaisille paskeille ei ole enää tarvetta. Ei varmaan mikään kovin iso juttu isommassa mittakaavassa, mutta esim. se quake rtx ei saanut dlss tukea tuon takia.

 

[Zetteri]

Nvidia on perinteisesti tarjonnut pelifirmoille jeesiä siihen, että implementoivat heidän featureitaan. Tulevat usein siis tosi vähällä työllä, kun nvidian koodarit vähän jeesaavat…

Juu ja pitäneet myös huolta että peli pyörii mahdollisimman surkeasti korteilla missä ei noita Nvidian määrättyjä juttuja ole... eli vanhemmilla Nvidian korteilla tai varsinkaan kilpailijoiden korteilla.

 

[KVahlman]

Tämä myös mahdollistaa sen, että dlss voidaan integroida avoimen lähdekoodin projekteihin. Tämä interface kun on avointa ja millekkään NDA:n alaisille paskeille ei ole enää tarvetta. Ei varmaan mikään kovin iso juttu isommassa mittakaavassa, mutta esim. se quake rtx ei saanut dlss tukea tuon takia.

DLSS ei kyllä vaadi mitään NDA:ta kun SDK löytyy githubista, mutta eipä sen käyttäminen jonkun avoimen API:n lävitse sekään muuta mitään; jos koodi on GPL:ää kuten quaken kohdalla on, ei binääriin saa ympätä mitään suljettua palikkaa. Tietynlaisella plugin-arkkitehtuurilla ongelmaa pystyy kiertämään mutta se ei tule tässä tapauksessa mitenkään kyseeseen.

 

[pomk]

jos koodi on GPL:ää kuten quaken kohdalla on, ei binääriin saa ympätä mitään suljettua palikkaa.

Siihenhän tämä juurikin tuo muutoksen. Itse binääriin ei tarvitse laittaa mitään suljettua palikkaa.

edit: ellei sitten MIT lisenssi ole liian rajoittava integroitavaksi.

 

[Nerkoon]

Siihenhän tämä juurikin tuo muutoksen. Itse binääriin ei tarvitse laittaa mitään suljettua palikkaa.

edit: ellei sitten MIT lisenssi ole liian rajoittava integroitavaksi.

Kyllähän se kieltämättä kiva ja helppo olisi jos tuen saisi vaan tiputtamalla yhden dll:n pelin hakemistoon. Näinköhän vaan pääsee ihan noin vähällä?

 

[pomk]

Kyllähän se kieltämättä kiva ja helppo olisi jos tuen saisi vaan tiputtamalla yhden dll:n pelin hakemistoon. Näinköhän vaan pääsee ihan noin vähällä?

Ei tarvitse välttämättä edes tiputtaa pelin hakemistoon, kunhan yhteensopiva dll löytyy jostain pathilta tmv. Pitäis noi streamlinen gittikamat käydä läpi jotta voisi sanoa varmasti.

Edit:
Toi ”vanha”/ tämän myötä tarpeettomaksi muuttuva dlss sdk on lisenssiltään epäyhteensopiva aika monen softan kanssa. Tän streamline pluginhässäkän läpi käytettäessä ei pitäisi tulla samoja onglemia.

 

[P c L A Y E R]

Päin vastoin: Miksi kuluttaa se 3-4 päivää lisää lisäämällä käytännössä saman asian tekevä toinen implementaatio kun yhdellä saa kaikki valmistajat kerralla? Se koodarin työ ei ole ilmaista ja noiden ylimääräisten lisäämisestä ei saa mitään käytännön hyötyä olemattoman markkina-arvon lisääntymisen lisäksi. AMD mainostaa tuota pelkästään siksi, että heidän versionsa toimii kaikilla ja nVidian ei.

Jos minä olisi pelikehittäjä, niin tiputtaisin pois ensimmäisenä vain yhden valmistajan vaihtoehdot ja sen jälkeen valitsisin parhaan jäljellejäävistä peliin lisättäväksi.

Niin ja jos AMD tekisi plugarin ntuohon, niin kaikki valmistajat saisivat oman skaalauaimen joka peliin. FSR:ssä on kuitenkin optimointeja AMD radalle, kuten XeSS, intelille ja DLSS on varmaan nopeampi NVIDIA:lla, kun FSR tai XeSS.

 

[Zetteri]

Niin ja jos AMD tekisi plugarin ntuohon, niin kaikki valmistajat saisivat oman skaalauaimen joka peliin. FSR:ssä on kuitenkin optimointeja AMD radalle, kuten XeSS, intelille ja DLSS on varmaan nopein NVIDIA:lla.

FSR:ssä optimointeja AMD raudalle? No mene ja tiedä tuosta, kun ainakin tuo FSR 1.0 toimii hemmetin hyvin Nvidian korteilla ja intelin igpu:lla mitä tuossa olen tuota testaillut.

FSR 1.0 ainakin toimii Nvidian korteilla 600-sarjasta eteenpäin ja AMD korteilla HD 7000-sarjasta eteenpäin.

 

[P c L A Y E R]

FSR:ssä optimointeja AMD raudalle? No mene ja tiedä tuosta, kun ainakin tuo FSR 1.0 toimii hemmetin hyvin Nvidian korteilla ja intelin igpu:lla mitä tuossa olen tuota testaillut.

FSR 1.0 ainakin toimii Nvidian korteilla 600-sarjasta eteenpäin ja AMD korteilla HD 7000-sarjasta eteenpäin.

"AMD did spend some time optimizing processes for RDNA 2 architectures. For example, optimizing the Lanczos calculations includes storing precomputed Lanczos lookup tables in a texture and then sampling them at runtime. According to AMD engineer Colin Riley, this is faster on some RDNA 2 architectures."

FSR 2.0 Improves Performance by Up to 147% in Deathloop; RDNA 2 GPUs Have Exclusive Optimizations

AMD FSR 2.0 can improve frame time by up to 147% in Deathloop with Ultra Performance mode. RDNA 2 GPUs will get specific optimizations.

wccftech.com

 

[Zetteri]

"AMD did spend some time optimizing processes for RDNA 2 architectures. For example, optimizing the Lanczos calculations includes storing precomputed Lanczos lookup tables in a texture and then sampling them at runtime. According to AMD engineer Colin Riley, this is faster on some RDNA 2 architectures."

FSR 2.0 Improves Performance by Up to 147% in Deathloop; RDNA 2 GPUs Have Exclusive Optimizations

AMD FSR 2.0 can improve frame time by up to 147% in Deathloop with Ultra Performance mode. RDNA 2 GPUs will get specific optimizations.

wccftech.com

Niin mutta onko tuolla mitään väliä onkin aivan toinen asia.
Muutenkin kun FSR:n (miksei myös tämän tulevan nvidian tuotoksen) paras käyttötarkoitus on saada vanhalla raudalla uusi peli pyörimään pelattavasti.
Eli olla se viimeinen oljenkorsi kun grafiikka asetuksissa ei voi mennä enää alaspäin.

Toki noita moni käyttää esim. 1440p resolla että peli renderöidään FSR:llä 1080p:llä kun vissiin grafiikka asetusten tiputtaminen on no no.

 

[P c L A Y E R]

Niin mutta onko tuolla mitään väliä onkin aivan toinen asia.
Muutenkin kun FSR:n (miksei myös tämän tulevan nvidian tuotoksen) paras käyttötarkoitus on saada vanhalla raudalla uusi peli pyörimään pelattavasti.
Eli olla se viimeinen oljenkorsi kun grafiikka asetuksissa ei voi mennä enää alaspäin.

Toki noita moni käyttää esim. 1440p resolla että peli renderöidään FSR:llä 1080p:llä kun vissiin grafiikka asetusten tiputtaminen on no no.

No nämä temporaaliset upscaling tekniikat (FSR2.0 XeSS, DLSS) tarjoaa useassa pelissä paremman AA:n, kun pelin/enginen oma AA, jonka johdosta itsekkin saatan laittaa DLSS:n päälle, vaikka en sitä FPS:n takia tarvisikaan.

 

[KVahlman]

Siihenhän tämä juurikin tuo muutoksen. Itse binääriin ei tarvitse laittaa mitään suljettua palikkaa.

Jos tämä olisi totta, mitään ongelmaa ei olisi ikinä kun voisi vain laittaa väliin jonkun apin ja kaikki lisenssihuolet kaikkoaisi kuin pieru saharaan. Mutta näin ei ole vaan GPL määrittelee aika tiukasti sen miten sitä tulkitaan jos prosessi lataa suljettua koodia ajon aikanakin. Jos GPL-koodi ja suljettu koodi juttelee "tiukasti" toistensa kanssa homma ei ole ok GPL:n suhteen, muutenhan dynaamisesti linkatut kirjastotkin olisi jo sallittuja.

Tämä on suuri syy miksi GPL ei ole kovin suosittua silloin kun projekteissa pyörii suljettuakin softaa, ja GPL 3 on suorastaan hyljeksitty kun siellä on sitten jo patenttilausekkeitakin yms tiukempaa tekstiä.

 

[pomk]

Jos tämä olisi totta, mitään ongelmaa ei olisi ikinä kun voisi vain laittaa väliin jonkun apin ja kaikki lisenssihuolet kaikkoaisi kuin pieru saharaan. Mutta näin ei ole vaan GPL määrittelee aika tiukasti sen miten sitä tulkitaan jos prosessi lataa suljettua koodia ajon aikanakin. Jos GPL-koodi ja suljettu koodi juttelee "tiukasti" toistensa kanssa homma ei ole ok GPL:n suhteen, muutenhan dynaamisesti linkatut kirjastotkin olisi jo sallittuja.

Tämä on suuri syy miksi GPL ei ole kovin suosittua silloin kun projekteissa pyörii suljettuakin softaa, ja GPL 3 on suorastaan hyljeksitty kun siellä on sitten jo patenttilausekkeitakin yms tiukempaa tekstiä.

Eli MIT lisenssin mukaista softaa ei saa liittää osaksi GPL lisensoitua softaa, jos se saattaa joissain tilanteissa mahdollisesti käyttää jotain ei GPL lisenssin mukaista ulkoista binääriä? Miten ihmeessä sä sit edes ajat jotain peliä, kun ajurit ei taatusti ole kokonaisuudessaan OS kamaa, ja pelit juttelee tiukasti kyseisen softakikkareen kanssa? Joku perus GPL minesweeperkin käyttää jotain windowsin ikkunointibinääriä ja homma menis päin persettä jos tilanne olisi kuten väität. GPL kieltää sua jakamasta sitä DLSS DLL filua pelisi kanssa, mutta ei estä sen käyttöä jos se löytyy järjestelmästä ns. valmiiksi, tässä tapauksessa nvidia varmaan jakelee jonkun version ajuriensa mukana jatkossa.

You may link your program to these libraries, and distribute the compiled program to others. When you do this, the runtime libraries are “System Libraries” as GPLv3 defines them. That means that you don't need to worry about including their source code with the program's Corresponding Source. GPLv2 provides a similar exception in section 3.

You may not distribute these libraries in compiled DLL form with the program. To prevent unscrupulous distributors from trying to use the System Library exception as a loophole, the GPL says that libraries can only qualify as System Libraries as long as they're not distributed with the program itself. If you distribute the DLLs with the program, they won't be eligible for this exception anymore; then the only way to comply with the GPL would be to provide their source code, which you are unable to do.

Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation

www.gnu.org

DLSS:ää ei ollut mahdollista aikaisemmin liittää GPL softaan, sillä sen SDK:n lisenssit on kauheat. Niitä SDK:n lisenssejä ei voinut aikaisemmin kiertää millään toimivilla laillisilla keinoilla. Nyt nvidia on tullut järkiinsä kyseisen asian osalta.

 

[ratkakapu]

Niin mutta onko tuolla mitään väliä onkin aivan toinen asia.
Muutenkin kun FSR:n (miksei myös tämän tulevan nvidian tuotoksen) paras käyttötarkoitus on saada vanhalla raudalla uusi peli pyörimään pelattavasti.
Eli olla se viimeinen oljenkorsi kun grafiikka asetuksissa ei voi mennä enää alaspäin.

Hidasta tai muuten puutteellista rautaa on julkaistu RDNA2 arkkitehtuurillakin mm 6500XT ja kaippa jotain integroitujakin on sillä jo kaupan ja onko Steam Deck myös.
Ja joskus se RDNA2 on ser osastoa myös. Kaikki teknologia mitä julkaistaan ei ole hyödyllistä just nyt.

Toki noita moni käyttää esim. 1440p resolla että peli renderöidään FSR:llä 1080p:llä kun vissiin grafiikka asetusten tiputtaminen on no no.

Jos "1440p" kuva FSR:llä/DLSS:llä näyttää paremmalta kuin natiivi 1440p kuva huonommilla kuvanlaatuasetuksilla samalla ollen kevyempi pyörittää, niin miksi ihmeessä säätäisin asetuksia alemmaksi vain että saisin natiivin 1440p kuvan?

 

[KVahlman]

GPL kieltää sua jakamasta sitä DLSS DLL filua pelisi kanssa, mutta ei estä sen käyttöä jos se löytyy järjestelmästä ns. valmiiksi, tässä tapauksessa nvidia varmaan jakelee jonkun version ajuriensa mukana jatkossa.

JOS näin tekee niin juu, silloin toki DLSS pulikka voidaan luultavasti tulkita systeemikirjastoksi lainaamallasi tavalla. Streamlinen SDK:n ohjeet ei moisesta kyllä mainitse mitään ja vähän epäilen että NVIDIA ei ota harteilleen yhteensopivuusongelmaa joka tästä syntyy.

Ja se RTX SDK:n lisenssikin löytyy tuolta DLSS plugarin kyljestä että ainakaan tuon gittirepon perusteella siitä ei pääse luistamaan.

Mutta paras opetushan tästä taas on se että GPL on kiihkoavoimena rajoittavampi kuin suljetut softat; niitä sentään voi huoletta käyttää järkevästi lisensoidun (esim. MIT) avoimen softan kanssa yhdessä.

 

[pomk]

Ja se RTX SDK:n lisenssikin löytyy tuolta DLSS plugarin kyljestä että ainakaan tuon gittirepon perusteella siitä ei pääse luistamaan.

Siinä tapauksessa tälle nyt julkaistulle häkkyrälle ei ole mitään tarvetta. Ihme pelleilyä muka lisenssivapaan arkkitehtuurin mainostamisella jos se ei oikeasti pidäkkään paikkaansa.

edit: tai no jos haluaa vaikka sekä xess:n ja fsr2.0:n samaan projektiin, ja ne päättävät käyttää yhteensopivia plugarin apikutsuja, niin tämä saattaa säästää tekijän jopa päivän devaukselta.

 

[KVahlman]

Siinä tapauksessa tälle nyt julkaistulle häkkyrälle ei ole mitään tarvetta. Ihme pelleilyä muka lisenssivapaan arkkitehtuurin mainostamisella jos se ei oikeasti pidäkkään paikkaansa.

edit: tai no jos haluaa vaikka sekä xess:n ja fsr2.0:n samaan projektiin, ja ne päättävät käyttää yhteensopivia plugarin apikutsuja, niin tämä saattaa säästää tekijät jopa päivän devaukselta.

Niin siis koko pointtihan on tosiaan yhtenäinen API kaikille skaalaus (yms) toteutuksille eli kertaintegraatio sen sijaan että käyttäs kolmea eri SDK:ta. Ei NVIDIA mitään eri vapauksia lisenssien suhteen ole (tietääkseni) mainostanutkaan, tämä SDK nyt sattuu olemaan MITtiä varmaan eniten sen takia että siellä ei tosiaan ole mitään vendor-kohtaista suoraan eli NVIDIAlla ei ole intressiä suojata sen enempää tuota sisältöä.

 

[pomk]

Niin siis koko pointtihan on tosiaan yhtenäinen API kaikille skaalaus (yms) toteutuksille eli kertaintegraatio sen sijaan että käyttäs kolmea eri SDK:ta. Ei NVIDIA mitään eri vapauksia lisenssien suhteen ole (tietääkseni) mainostanutkaan, tämä SDK nyt sattuu olemaan MITtiä varmaan eniten sen takia että siellä ei tosiaan ole mitään vendor-kohtaista suoraan eli NVIDIAlla ei ole intressiä suojata sen enempää tuota sisältöä.

Mitä nopeasti katsoin tota gittiä, niin ainakin jos tuota dlss plugaria käyttää, niin se haluaa läjän dlss spesifejä plugarin alustuksia ja inputteja. En oikein näe sitä että missä kohtaa säästää minuuttiakaan työtä.

edit: mutta voihan se olla että olen ymmärtänyt jotain väärin, tai että dlss SDK:n vastaavat alustukset ja inputtien valmistelut on paljon työläämmät, ilman järkevää tarkoitusta.

 

[KVahlman]

Tälle proggikselle voinee laittaa ruksin päälle kun kerran AMD sanoo suoraan että ei kiinnosta osallistua. Harmi sinänsä.

 

[mäsä-79]

Kertoo kaiken tällä hetkellä.. evvk 2.0 tulee seuraavaksi

 

[Zetteri]

Tälle proggikselle voinee laittaa ruksin päälle kun kerran AMD sanoo suoraan että ei kiinnosta osallistua. Harmi sinänsä.

Ei kukaan halua tehdä Nvidian kanssa yhteistyötä jos on yhtään perillä minkälaiset toimintavat kyseisellä firmalla on.
Eli kustaan niin kuluttajien kuin yhteistyö kumppaneitten kintuille minkä keretään ja tätä on tehty jo 20 vuotta.

 

[Kizmo]

Katsokaapa vain niin lopputulema tässä(kin) on sama kuin freesyncin kanssa. Nvidia jyrää ylivoimaisella markkinaosuudellaan:

Freesync -> G-sync compatible

FSR -> DLSS compatible

 

[KVahlman]

Ei kukaan halua tehdä Nvidian kanssa yhteistyötä jos on yhtään perillä minkälaiset toimintavat kyseisellä firmalla on.
Eli kustaan niin kuluttajien kuin yhteistyö kumppaneitten kintuille minkä keretään ja tätä on tehty jo 20 vuotta.

En tiedä mitä tekemistä noilla on sen kanssa että tehtäisiin plugari avoimen API:n alle, joka kuten DLSS->FSR modeista näkee olisi varmaan aika triviaali homma.

Tosin ehkä tässä ei edes tarvita AMD:tä, osaahan ne modaajat tehdä tuollaisen toteutuksen kun FSR on avoin. Joka vain alleviivaisi sitä että puhtaaasti bisnesmielessä (ei "hyödytetä" kilpailijaa yhteisillä jutuilla eikä käytetä työaikaa) AMD änkyröi, ainakaan minua ei vakuuttanut ollenkaan selittelyt siitä että tämä olisi jotenkin turha projekti.

Mutta vaikea tosiaan nähdä että tästä mitään pysyvää nyt enää tulisi kun kaikki kolme ei ole mukana.

 

[Kaotik]

En tiedä mitä tekemistä noilla on sen kanssa että tehtäisiin plugari avoimen API:n alle, joka kuten DLSS->FSR modeista näkee olisi varmaan aika triviaali homma.

Tosin ehkä tässä ei edes tarvita AMD:tä, osaahan ne modaajat tehdä tuollaisen toteutuksen kun FSR on avoin. Joka vain alleviivaisi sitä että puhtaaasti bisnesmielessä (ei "hyödytetä" kilpailijaa yhteisillä jutuilla eikä käytetä työaikaa) AMD änkyröi, ainakaan minua ei vakuuttanut ollenkaan selittelyt siitä että tämä olisi jotenkin turha projekti.

Mutta vaikea tosiaan nähdä että tästä mitään pysyvää nyt enää tulisi kun kaikki kolme ei ole mukana.

Oikeastaan se miten helposti modaajat ovat saaneet FSR:llä korvattua DLSS:n kertoo siitä ettei tuollaiselle lisävälikerrokselle kummoistakaan tarvetta pitäisi olla?

 

[pomk]

ainakaan minua ei vakuuttanut ollenkaan selittelyt siitä että tämä olisi jotenkin turha projekti.

Ootko kattonu ton gittirepon läpi? Ei tosta ole nykymuodossaan käytännössä mitään hyötyä. Se api pitäis toteuttaa siten että kaikki yhteensopivat TAA algot toimii kunhan tää nvidian OS API on käytössä, mutta ainakin gitin esimerkkien perusteella sun pitää koodata kaikkea TAA algo spesifiä paskaa joka tapauksessa. Eli en vaan ymmärrä että mitä käytännön hyötyä tästä on. Täysin tarpeeton API kerros, joka ei yksinkertaista mitään.

 

[KVahlman]

Oikeastaan se miten helposti modaajat ovat saaneet FSR:llä korvattua DLSS:n kertoo siitä ettei tuollaiselle lisävälikerrokselle kummoistakaan tarvetta pitäisi olla?

Täysin tarpeeton API kerros, joka ei yksinkertaista mitään.

Se suurin hyöty yhtenäisestä APIsta olisi se että devaajan ei tarvitsisi välttämättä testata kolmea toteutusta itse sekä tulevaisuudessakin todennäköisemmin yhtenäinen API kun siihen olisi jollain tasolla sitouduttu.

 

[finWeazel]

Liekö tuolla rajapinnalla isoa merkitystä enää? dlss2 tuki on vaivalloisesti ja vuosien aikana toteutettu isompiin peleihin ja engineihin jo? Pitkäänhän sitä naristiin, että dlss on paska ja sen jälkeen, että vaikka olis ok. niin kun tukea ei ole peleissä niin dlss2 ei kiinnosta/ei ole relevantti. Tällähetkellä olemassaoleva tuki kantanee etiäpäin, kun ei puhuta yksittäisistä harvoista peleistä joissa tuki on.

AMD:n FSR2 vaatii samat datat ja tiedot kuin dlss2 ja voi astua valmiiseen pöytään kuten 3rdparty modaukset ovat osoittaneet.

Osassa peliengineistä kuten UE5 on dlss2/fsr2 vastaava oma implementaatio. UE5:ssa TSR. ue5 tapauksessa vielä pluginina toteutus niin in helppo toteuttaa oma plugin, jos niin haluaa. Sen kun toteuttaa oman version ja tiputtaa dll:n sisään.

UE4 peleistä on sekä nvidia spesifistä toteutusta, että virallista ue4 pluginia skaalaimelle. Pelit joissa on nvidia spesifinen toteutus/rajapinta eikä ue4 virallinen plugin toteutus vaatinevat peliohtaisen säädön, kun rajapinta voi olla "mitä vain" riippuen miten pelintekijä/nvidia on dlss2:en integroinut peliin sisään. Se on harmi, että virallisen ue4 skaalain pluginin kanssa kesti aikaa ja moni peli säädettiin pelintekijän/nvidian toimesta toimimaan dlss2:en kanssa. Olisi ollut kaikille parempi, että plugin toteutus olisi saatu aikaisemmin tehtyä.

 

[mRkukov]

En tiedä mitä tekemistä noilla on sen kanssa että tehtäisiin plugari avoimen API:n alle, joka kuten DLSS->FSR modeista näkee olisi varmaan aika triviaali homma.

Tosin ehkä tässä ei edes tarvita AMD:tä, osaahan ne modaajat tehdä tuollaisen toteutuksen kun FSR on avoin. Joka vain alleviivaisi sitä että puhtaaasti bisnesmielessä (ei "hyödytetä" kilpailijaa yhteisillä jutuilla eikä käytetä työaikaa) AMD änkyröi, ainakaan minua ei vakuuttanut ollenkaan selittelyt siitä että tämä olisi jotenkin turha projekti.

Mutta vaikea tosiaan nähdä että tästä mitään pysyvää nyt enää tulisi kun kaikki kolme ei ole mukana.

Aina ei kannata tehdä uutta "parempaa" korvaamaan kasaa vanhoja. Todennäköisesti tuosta ei ole juuri mitään apua ja olisi vain turhaa työtä. Nytkin dlss2 tiedostot korvaamalla on saatu fsr2 käyttöön monessa tapauksessa. Tuollaisen lisäpurkan lisääminen väliin toisi vain taas yhden hajoavan/ylläpidettävän lisäkerroksen.

 

[pomk]

Se suurin hyöty yhtenäisestä APIsta olisi se että devaajan ei tarvitsisi välttämättä testata kolmea toteutusta itse sekä tulevaisuudessakin todennäköisemmin yhtenäinen API kun siihen olisi jollain tasolla sitouduttu.

Mutta tämä nvidian väkerrys ei tuota tavoitetta toteuta. Ihan oikeasti, älä oleta mistä on kyse vaan selaa se gitti läpi.

 

[Kizmo]

Ei kukaan halua tehdä Nvidian kanssa yhteistyötä jos on yhtään perillä minkälaiset toimintavat kyseisellä firmalla on.
Eli kustaan niin kuluttajien kuin yhteistyö kumppaneitten kintuille minkä keretään ja tätä on tehty jo 20 vuotta.

Oon kyllä itse kuullut juuri pelideveiltä täysin vastakkaista kommenttia. Siinä missä AMDn tuki harvoin vastaa edes devien tukipyyntöihin nvidia tarjoaa jopa loanerirautaa pyytämättä pelien testaamiseen. Ero on tai ainakin oli aika jäätävä.

 

[mRkukov]

Oon kyllä itse kuullut juuri pelideveiltä täysin vastakkaista kommenttia. Siinä missä AMDn tuki harvoin vastaa edes devien tukipyyntöihin nvidia tarjoaa jopa loanerirautaa pyytämättä pelien testaamiseen. Ero on tai ainakin oli aika jäätävä.

Eikös nvidialla ole ollut tapana tulla vaikka auttamaan koodaamisessa jotta saavat omat "ratkaisut" peliin mukaan? Tesselöidään neliskulmaista palkkia niin paljon että kilpailijan kortit hyytyy kun niistä puuttuu ominaisuus X. Joo auttavat kyllä, mutta oma lehmä ojassa ja edes pieni perffihitti ei haittaa, jos se kuitenkin osuu kilpailijaan pahemmin. link

Jos siis puhutaan yrityksen toimintatavoista niin nvidia on yksi paskimmista näin kuluttajan kannalta. Yksittäisen devaajan kannalta varmaan hyvä että saa apua, mutta yrityksenä aivan silkkaa sontaa.

 

[Kizmo]

Eikös nvidialla ole ollut tapana tulla vaikka auttamaan koodaamisessa jotta saavat omat "ratkaisut" peliin mukaan? Tesselöidään neliskulmaista palkkia niin paljon että kilpailijan kortit hyytyy kun niistä puuttuu ominaisuus X. Joo auttavat kyllä, mutta oma lehmä ojassa ja edes pieni perffihitti ei haittaa, jos se kuitenkin osuu kilpailijaan pahemmin. link

Jos siis puhutaan yrityksen toimintatavoista niin nvidia on yksi paskimmista näin kuluttajan kannalta. Yksittäisen devaajan kannalta varmaan hyvä että saa apua, mutta yrityksenä aivan silkkaa sontaa.

Yrityksen on kuitenkin tarkoitus vääntää rahaa markkinoilta joten nvidia ei todellakaan ole paska vaan erinomainen yritys.

 

[mRkukov]

Yrityksen on kuitenkin tarkoitus vääntää rahaa markkinoilta joten nvidia ei todellakaan ole paska vaan erinomainen yritys.

Ja siksi kilpailijan pitäisi tukea sen turhaa apia?

 

[Kizmo]

Ja siksi kilpailijan pitäisi tukea sen turhaa apia?

Se ei oikeastaan ole nvidian ongelma

 

[finWeazel]

Se on aika vetinen suo lähteä todistamaan yhtäkään julkisesti treidattua yritystä kuluttajan ystäväksi. Loppukädessä laillinen mandaatti listatuilla yrityksillä on sijoittajille lisäarvon tekeminen.

api/softa juttuihin liittyen niin mantle tervehtii ja siitä sitten pieni piiri pyörii ja silleen. Tarpeeksi kauas menneisyyteen kaivelee niin loppuu oma mielenterveys ennen kuin sontakasa on tyhjätty. Ei edes jaksa tuollaiseen leikkiin lähteä. Ostaa sen ratkaisun mikä sopii omaan budjettiin ja arvoihin, jokainen tyylillänsä. Aina on joku väärässä internetissä ja se ei lopu vaikka kuinka yrittäisi. Viimekädessä peilistäkin löytyy virhettä.

amd:lla on nykyään kassassa sen verran rahaa, että nähtäneen myös sieltä puolelta paremmin panostusta devaajien auttamiseen. Rauta on aika pieni osa nykypäivän gpu:ta kuluttajan näkökulmasta.

 

[Kaotik]

api/softa juttuihin liittyen niin mantle tervehtii ja siitä sitten pieni piiri pyörii ja silleen.

Mantle teki sen mitä sen pitikin, eli sai DX12 ja Vulkanin aikaan. Vulkan kirjaimellisesti tehtiin Mantlesta ja DX12kin kuuleman mukaan lainannut siitä aika tavalla.
Itse rajapinnastahan olisi tullut täysin avoin kaikille, mutta Vulkan täytti sen aukon joten Mantle vedettiin firman sisäiseksi kehitysalustaksi

 

[Lacsative]

Katsokaapa vain niin lopputulema tässä(kin) on sama kuin freesyncin kanssa. Nvidia jyrää ylivoimaisella markkinaosuudellaan:

Freesync -> G-sync compatible

Öö paitsi että Nvidia hävisi tuon VRR-kilvan jo paljon aikaisemmin, kun valmistajat lähti nihkeästi sen omaan G-sync moduuli -pelleilyyn mukaan, ja lopulta AMD:n (alunp. VESAn) Freesync yleistyi, ja Freesync oli se joka veti pidemmän korren yleistymisessä, kunnes Nvidia luovutti ja salli tuon omilla korteilleen ajureillaan, ja nyt näytöistä löytyy usein maininta sekä Freesyncistä että G-sync compatible. Eli nykyinen tilanne on hyvin tasapuolinen, ja kuluttajille tosi hyvä, kiitos Freesyncin. Niitä Nvidian fyysisiä G-sync moduuleita ei taida käyttää juuri kukaan enää uusissa näytöissä. Se oli Nvidialta ihan surkea vikatikki ja selkeä epäonnistuminen.

Edit: @Kizmo esim. Samsungin tämän vuoden uusissa pelinäytöissä mainitaan heidän sivuilla ainoastaan AMD FREESYNC PREMIUM, eikä edes huippunäyttö Neo G8 pääsivulla mainita Nvidian G-syncistä halaistua sanaakaan Ei Nvidia ole kyllä voittanut G-sync compatible:llään mitään. Tuo maininta kyllä löytyy monista näytöistä, mutta niin löytyy myös AMD Freesync..

Yrityksen on kuitenkin tarkoitus vääntää rahaa markkinoilta joten nvidia ei todellakaan ole paska vaan erinomainen yritys.

Nvidia on tekemisissä myös muiden kuin osakkeenomistajiensa kanssa, joten ei yrityksen hyvyyttä tai huonoutta mitata vain rahassa. On muitakin näkökulmia kuin osakkeenomistajien ja verotulojen näkökulmat..

Tuo ''juujuu mutta firman tarkoitus on tehdä rahaa'' on vakiovastaus nykyisin tällä foorumilla, silloin kun kritisoidaan firmaa X.. Laiska argumentti, eikä haasta ihmisiä ajattelemaan firman PR-potaskaa brändiä eikä imagoa pidemmälle..

 

[Kaotik]

lopulta AMD:n (alunp. VESAn) Freesync yleistyi

Toi oli sinänsä hauska episodi. AMD kehitti speksin VESAn olemassaolevan speksin (eDP) pohjalta ja ehdotti VESAlle joka ratifioi sen Adaptive-synciksi ja AMD sitten brändäsi oman tukensa sille FreeSynciksi

 

[KVahlman]

Liekö tuolla rajapinnalla isoa merkitystä enää?

ue5 tapauksessa vielä pluginina toteutus niin in helppo toteuttaa oma plugin, jos niin haluaa. Sen kun toteuttaa oman version ja tiputtaa dll:n sisään.

Minusta jälkimmäinen lainaus nimenomaan kertoo miksi tämä rajapinta olisi voinut olla hyvä juttu. Ehkä toisaalta parempi odottaa että skaalaus-api syntyy DirectX:ään ja Vulkaniin, ei pitäisi olla kiinni politiikasta yhtenäiset toteutukset sen jälkeen. Toivottavasti joskus tapahtuu.

 

[Kaotik]

Minusta jälkimmäinen lainaus nimenomaan kertoo miksi tämä rajapinta olisi voinut olla hyvä juttu.

Kun se rajapinta ei toimi noin. Eikä sitä rajapintaakaan noin vaan voi tiputtaa peliin x.

 

[pomk]

jälkimmäinen lainaus nimenomaan kertoo miksi tämä rajapinta olisi voinut olla hyvä juttu.

Et oo vieläkään ottanut selvää kuinka turha juurikin _tämä_ uutisen rajapinta on? Joku toinen rajapinta voisi olla ihan fiksukin juttu.

 

[KVahlman]

Et oo vieläkään ottanut selvää kuinka turha juurikin _tämä_ uutisen rajapinta on? Joku toinen rajapinta voisi olla ihan fiksukin juttu.

Onhan se turha kun tuki muille kuin NVIDIAn plugareille tai edes Vulkanille puuttuu. Mutta jos muut vendorit toisi omat plugininsa niin rajapintaa tietenkin kehitettäisiin geneerisemmäksi, ei kai kukaan kuvittele että jos vendori X tekee ensivedoksen APIsta että se on hakattu kiveen ikuisiksi ajoiksi ja palvelee kaikkien toteutuksia sellaisenaan?

Ja kyllä, olen lukenut sekä Streamlinen esimerkkikoodeja että FSR 2.0:n ja DLSS:n SDK-esimerkkejä. Sen lisäksi olen kurkannut miten PotatoOfDoom teki modinsa Cyberpunkiin jne sekä lukenut herran haastattelun jossa kuvailee erilaisia haasteita mitä siinä oli.

Ja ei, mikään noista ei muuta mielipidettäni siitä että Streamline tai mikä muu vastaava API jossa kaikki hardware vendorit tekisi yhteistyötä olisi huippujuttu ja pitkässä juoksussa kaikkien etu.

Ei myöskään sitä että koska AMD sanoi kiitos ei, tämä yritys joutaa roskakoriin. Momentum käyttöönottoon meni varmasti developperien silmissä.