Virallinen: NVIDIA vs AMD (vs Intel) keskustelu- ja väittelyketju

[hsalonen]

Nyt kyllä täytyy kysyä että puhutko sinä edes samoista asioista mitä @AION taikka minä tuolla toisessa ketjussa?

Mutta kun sinä nyt jatkuvasti haluat jotain todisteita, niin tässä käy vaikka kattomassa täältä
The Khronos Group · GitHub

Ja miksi edelleen intät ajureista kun jo tuolla toisessa ketjussa sinulle annoin lähteet joista selviää että Linux kernelistä löytyy nykyisin ihan natiivi tuki AMD:n näytönohjaimille. On jo niin hyvällä mallilla opensource MESA ajurit että pärjää vertailussa jopa win 10:lle ja pöllyttää AMD:n suljetut linux ajurit ihan 6-0.

Ei nyt siirrytä "avoimien" (määrittelyä odottaen @AION) rajapintojen tukemisesta johonkin ihan muuhun, unohtaen ne kolme asiaa, jotka alunperin oli esillä: Vulkan, OpenCL ja se kolmas .

Tuossa on ihan samantasoisia repositoryjä CUDA:sta, tekeekö se siitä avoimen:
GitHub - NVIDIA/cuda-gdb: CUDA GDB
CUDA · NVIDIA/nvidia-docker Wiki · GitHub

 

[AION]

Ei nyt siirrytä "avoimien" (määrittelyä odottaen @AION) rajapintojen tukemisesta johonkin ihan muuhun, unohtaen ne kolme asiaa, jotka alunperin oli esillä: Vulkan, OpenCL ja se kolmas .

Tuossa on ihan samantasoisia repositoryjä CUDA:sta, tekeekö se siitä avoimen:
GitHub - NVIDIA/cuda-gdb: CUDA GDB
CUDA · NVIDIA/nvidia-docker Wiki · GitHub

Ihan samanlaisia? Ai tuolla on kaikki koodi saatavilla, spekseineen ja sen lisäksi lisenssillä, jolla sitä sää käyttää ja uudestaan levittää tietyin ehdoin.

Avoin:
Tällä viittasin avoimen lähdekoodin järjestelmiin (News | Open Source Initiative)
tai avoimiin alustoihin tai ekosysteemeihin.

En tässä lähdekään siitä liikenteeseen, että avoimet järjestelmät olisivat aina 100% parempia tai, että esim kaikki AMD:n kama toimisi kokonaan ilman heidän contribuutioita.

Esimerkiksi Vulkan ei välttämättä toimi täydellisestä ilman näytönohjain valmistajien jotain blobbeja jossain välissä (Intel ehkä?).

Lähden tässä ajattelussa enemmänkin siltä kannalta, että esim Vulkan mahdollistaa varteenotettavan kilpailun Microsoftin asemalle de-facto käyttiksenä pelaamiseen. Ja tuo on pitkälti AMD:n pohjatyöhön perustuva.

Sitten taas tuo OpenCL. Vaikka AMD ei sitä sen kummemmin kehittäisi tai tukisi niin AMD ei kuitenkaan pushaa omaa, suljettua (toimii vain yhdellä vendorilla) kamaa sen tilalle.

nVidia teki ensimmäisen adaptive sync ratkaisun ja se toimii vain heidän korteilla ja näytöillä, jossa on heidän piirit. AMD teki vastaavan ja tuuppas osaksi DP standardia, jonka kuka tahansa saa implementoida ilman royalteja.


Kysymys tässä nyt ei ole yksi tekniikka ja toinen vaan kokonaiskuva. AMD panostaa enemmän avoimen lähdekoodin järjestelmiin ja standardien kehittämiseen kuin nVidia. Myös esimerkiksi Vulkan työllä sekä nyt hyvin pitkälti avoimille Linux ajureilla ovat panostaneet tuohon avoimeen ekosysteemiinkin jo kiitettävästi.

Ja tästä voin maksaa vähän extraa rauta hankintani yhteydessä.

 

[hsalonen]

Ihan samanlaisia? Ai tuolla on kaikki koodi saatavilla, spekseineen ja sen lisäksi lisenssillä, jolla sitä sää käyttää ja uudestaan levittää tietyin ehdoin.

Kyllä, siellä on ihan GPL 2, joka on sallivampi kuin GPL 3. Saa käyttää ja levittää uudestaan.

Kaikkea koodia ei ole Khronoksenkaan repossa, siellä on vain työkaluja, esimerkkejä ja API:n määrittelydokumentit. Eli ei mitään käytännöllistä, jos niinkuin haluaa vaan käyttää sitä APIa, eikä kehittää sillä. Voisin jopa sanoa, että jos olet Linux-käyttäjä, joka haluaa vaan ajaa pelejä/ohjelmia, jotka käyttävät OpenCL:ää, tuolla koodilinkillä ei tee yhtään mitään. Toivottavasti tämä ei ollut se, mihin kaikki "avoimuus" mielestäsi perustuu.

Avoin:
Tällä viittasin avoimen lähdekoodin järjestelmiin (News | Open Source Initiative)
tai avoimiin alustoihin tai ekosysteemeihin.

En tässä lähdekään siitä liikenteeseen, että avoimet järjestelmät olisivat aina 100% parempia tai, että esim kaikki AMD:n kama toimisi kokonaan ilman heidän contribuutioita.

Esimerkiksi Vulkan ei välttämättä toimi täydellisestä ilman näytönohjain valmistajien jotain blobbeja jossain välissä (Intel ehkä?).

Kyllä. Siis tämä on minunkin mielestäni avoimuuden määritelmä. Mutta tässä on taas jotain ihme idiotismia, kun riittää, että osa järjestelmästä on avoin. Väliin saa tunkea mitä suljettua paskaa haluaa. Vulkan ei toimi OSS-ajureilla. OpenCL ei toimi OSS-ajureilla. Mantle ei toimi OSS-ajureilla.

Lähden tässä ajattelussa enemmänkin siltä kannalta, että esim Vulkan mahdollistaa varteenotettavan kilpailun Microsoftin asemalle de-facto käyttiksenä pelaamiseen. Ja tuo on pitkälti AMD:n pohjatyöhön perustuva.

Kyllä. Missä olit 2014 kun AMD esitti ihan 100% samat argumentit Mantlen puolesta, lupasi täydellistä Linux-tukea, jota ei koskaan tullut ja oksensi jotain jämiä GitHubiin, että avoimuuslupaus on jollain tasolla pidetty?

Sitten taas tuo OpenCL. Vaikka AMD ei sitä sen kummemmin kehittäisi tai tukisi niin AMD ei kuitenkaan pushaa omaa, suljettua (toimii vain yhdellä vendorilla) kamaa sen tilalle.

Ai niinkuin Mantle?

nVidia teki ensimmäisen adaptive sync ratkaisun ja se toimii vain heidän korteilla ja näytöillä, jossa on heidän piirit. AMD teki vastaavan ja tuuppas osaksi DP standardia, jonka kuka tahansa saa implementoida ilman royalteja.

Sanotaan joo, vaikka pikkupräntissä lukee, että Adaptive Sync ei ole täysi Freesync ja DP lisensointi maksaa rahaa.

Kysymys tässä nyt ei ole yksi tekniikka ja toinen vaan kokonaiskuva. AMD panostaa enemmän avoimen lähdekoodin järjestelmiin ja standardien kehittämiseen kuin nVidia. Myös esimerkiksi Vulkan työllä sekä nyt hyvin pitkälti avoimille Linux ajureilla ovat panostaneet tuohon avoimeen ekosysteemiinkin jo kiitettävästi.

Ja tästä voin maksaa vähän extraa rauta hankintani yhteydessä.

Vulkanista on tullut kauniita lupauksia, mutta ei mitään konkreettista. Siis avoimuuden puolesta. Se on yhä yhtä suljettu kuin CUDA, jos mietitään Linux-tukea.

Nvidiallakin on Nouveau, jottei pääse unohtumaan. Siitä voidaan kyllä argumentoida, kumpi on kehittyneempi: Nouveau vai AMD:n OSS-ajuri.

Nyt ihmiset ei ymmärrä, että nämä on AMD:n markkinointikalvoista otettuja osatotuuksia ja jos ei ole rahaa näköpiirissä, niin Linux-miehet heitetään pihalle:
AMD Closes OSRC, Lays Off Several Linux Kernel Developers - Slashdot

 

[JiiPee]

Kyllä. Siis tämä on minunkin mielestäni avoimuuden määritelmä. Mutta tässä on taas jotain ihme idiotismia, kun riittää, että osa järjestelmästä on avoin. Väliin saa tunkea mitä suljettua paskaa haluaa. Vulkan ei toimi OSS-ajureilla. OpenCL ei toimi OSS-ajureilla. Mantle ei toimi OSS-ajureilla.

Vulkanista on tullut kauniita lupauksia, mutta ei mitään konkreettista. Siis avoimuuden puolesta. Se on yhä yhtä suljettu kuin CUDA, jos mietitään Linux-tukea.

Ahaa. No mikäs tämä sitten on? "Pure open source" Minulle tuo tarkoittaa sitä että saat rullaamaan 3D grafiikat ilman että asennat bitin bittiä suljettua koodia, joka tarkoittaa samalla sitä että ei tarvi esim. Fedorassa viritellä mitään ulkoisia repoja. Fedora kun ei monen muun distron lailla ota jakeluun paketteja joista ei vapaasti sourcecode saa.

AMDGPU-PRO 17.30 vs. Linux 4.13 + Mesa Git RadeonSI Benchmarks - Phoronix
Ja vinkkinä, tukee myös Vulkania.

ROCm on open source OpenCL käikäre linuksille jossa sanotaan näin:

Closed source components

The ROCm platform relies on a few closed source components to provide legacy functionality like HSAIL finalization and debugging/profiling support. These components are only available through the ROCm repositories, and will either be deprecated or become open source components in the future. These components are made available in the following packages:

• hsa-ext-rocr-dev

Eli tulevaisuudessa tarkoitus on saada tuo ulos täysin open sourcena.

 

[hsalonen]

Ahaa. No mikäs tämä sitten on? "Pure open source" Minulle tuo tarkoittaa sitä että saat rullaamaan 3D grafiikat ilman että asennat bitin bittiä suljettua koodia, joka tarkoittaa samalla sitä että ei tarvi esim. Fedorassa viritellä mitään ulkoisia repoja. Fedora kun ei monen muun distron lailla ota jakeluun paketteja joista ei vapaasti sourcecode saa.

AMDGPU-PRO 17.30 vs. Linux 4.13 + Mesa Git RadeonSI Benchmarks - Phoronix
Ja vinkkinä, tukee myös Vulkania.

ROCm on open source OpenCL käikäre linuksille jossa sanotaan näin:


Eli tulevaisuudessa tarkoitus on saada tuo ulos täysin open sourcena.

Ai toimiiko se Vulkan jo? Viimeeksi, kun katsoin, se oli vielä rikki.

 

[jabbadap]

Ai toimiiko se Vulkan jo? Viimeeksi, kun katsoin, se oli vielä rikki.

Pjooh taitaa olla aika pelistä peliin ja näyttiksestä näyttikseen. Mutta kyllä se RADV jo avoimilla pyörii:
6-Way RadeonSI OpenGL vs. RADV Vulkan Comparison - Phoronix

Ja intelin vulkan ajurithan tais tulla linuxille ennen windowsia, tosin niissä tehot riitä sitten oikein mihinkään muuhun kuin dotaan.

...
Nvidiallakin on Nouveau, jottei pääse unohtumaan. Siitä voidaan kyllä argumentoida, kumpi on kehittyneempi: Nouveau vai AMD:n OSS-ajuri.
...

Tarkoitat kai että freedesktopilla on nouveau, nvidia ei paljoa tuohon projektiin osallistu. Ok no tegra puolella tekee oikeasti koodiakin nouveau ajureille, mutta desktop puolen asioihin se ei puutu. Nvidialla oli omat vapaat 2D ajurit nimeltä NV, mutta niiden valmistus lopetettiin joskus ~10 vuotta sitten. AMD:llä taas on open source puolen ajureihin ihan omaa väkeä palkkalistoilla.

 

[peksi]

Kaikkea koodia ei ole Khronoksenkaan repossa, siellä on vain työkaluja, esimerkkejä ja API:n määrittelydokumentit. Eli ei mitään käytännöllistä, jos niinkuin haluaa vaan käyttää sitä APIa, eikä kehittää sillä. Voisin jopa sanoa, että jos olet Linux-käyttäjä, joka haluaa vaan ajaa pelejä/ohjelmia, jotka käyttävät OpenCL:ää, tuolla koodilinkillä ei tee yhtään mitään. Toivottavasti tämä ei ollut se, mihin kaikki "avoimuus" mielestäsi perustuu.

Sekoitat implementaation ja speksin avoimuuden. Avoimien speksien pointti on että ne laatii joukko yrityksiä joita kaikkia kuunnellaan (mikä saattaa toki johtaa paskoihin kompromisseihin kuten GLSL infra) ja speksin luoja/Khronos ei siis voisikaan tehdä mitään maagista implementaatiota itse, lähinnä tuottaa työkaluja kuten jotain high-level shaderkoodin geneeriseksi tavukoodiksi kääntäviä referenssitoteutuksia tai validointisettejä vendoreille jotka tekevät toteutuksia.

Se että joku valmistaja tekee suljetun toteutuksen avoimesta speksistä ei ole mikään OpenGL:n tai Vulkanin ongelma. CUDA taas on ihan oikeasti suljettu rajapinta, vendorien on käytännössä mahdotonta toteuttaa suoraan CUDAa tukevaa rautaa (AMD:n kääntäjäviritys on vähän eri asia) eikä ole tietoa tai mitään sanaa sanottavana mihin suuntaan rajapintaa tulevaisuudessa viedään.

AMD:llä on selkeästi avoimempi strategia ollut käytössä jo pitkään: Linux-puolella kernelpalikka on avoin, sen kanssa voi valita käytettäväksi joko suljetun tai avoimen (ja ihan ok:n) GL-toteutuksen, Vulkan on vielä ainakin toistaiseksi suljettu. Nvidian joskus tuottama Nv-ajuri sai just ja just 2d-kuvaa piirrettyä ja koodi oli aika uskomatonta kamaa (ts. suoraan jotain taikavakioita Nvidian sisäisistä spekseistä ilman mitään dokumentaatiota sun muuta), Nouveau on enemmän yhteisön tuotos joskin Nvidia on saattanut joitakin ropoja heittää mukaan.

Olisi tietenkin aina hienoa jos mitään firmware blobia ei tarvitsisi koskaan ladata mutta ei se tee avoimesta kernel-ajurista tai rajapintaimplementaatiosta mitenkään vähempiarvoista, samalla tavalla CPU ja wifipiirit latailevat ajurin yhteydessä blobeja. Siis jopa ihan Linux-kernelin mukana jaetaan noita.

 

[JiiPee]

Ai toimiiko se Vulkan jo? Viimeeksi, kun katsoin, se oli vielä rikki.

Tuolla linux ajuripuolella on käynyt kova kuhina siitä asti kun AMD alkoi työntää koodia open source puolelle. Linux ajureissa on tuskin koskaan nähty samnalaisia harppauksia kuin tässä viimeisen 6-12kk aikana on nähty.

Vulkan on vielä ainakin toistaiseksi suljettu.

Juu AMD:n tarjoama Vulkan on toistaiseksi suljettu joka tulee AMDGPU-PRO ajureiden mukana mutta RADV on avoin, tosin epävirallinen. Mutta huhua on että AMD lähtisi sen kehitykseen mukaan lähitulevaisuudessa.

 

[AION]

Myös jos voin sitä vielä kerran painottaa, en puhunut yhdestä tai kahdesta tai kolmesta yksityiskohdasta vaan firman yleisestä asennoitumisesta standardeihin ja avoimeen ekosysteemiin / avoimen lähdekoodin toteutuksiin.

Kaikki ei vielä ole aivan täydellistä jne. mutta AMD kuitenkin yrittää tukea Linux - ekosysteemiä ja avoimia järjestelmiä (tässä kohtaa käytän nimeä "järjestelmä" viitaten Vulkaniin ja OpenCL:ään koska ovat kuitenkin vähän enemmän kuin vain rajapintoja)

Sitten on taas firmoja, jotka tunkevat väen väkisin suljettuja systeemejä, kuten esimerkiksi GameWorksiä alueille, jossa ei ole välttämättä edes tarvetta sellaisille tai löytyy vapaitia / avoimia vaihtoehtoja tilalle jo valmiiksi.

Tästä olen valmis maksamaan. Se oli koko ajan se pointti.

Paskaako sitä tiedä, vaikka jostain tulisi yht'äkkiä 3. varteenotettava GPU valmistaja (ei taida tulla???), jolle olisi hiukan yksinkertaisempi implementoida FreeSync ja TressFX kuin nVidian vaihtoehdot?

Tai vaihtoehtoisesti jostain tulee 3. käyttöjärjestelmä, jonka on hiukan helpompi rakentaa Vulkan tuki kuin DX tuki (tämä siis Khronos vs MS, eikä niinkään MAD vs nVidia).

 

[Deleted member 3664]

Eli testin perusteella yksinkertaistettuna ainankin peleissä
Vega on Fury X kellotaajuuspäivitys, ei muuta.

Testien ja tosielämän perusteella Pascal on Maxwell kellotaajuuspäivitys, ei muuta.

 

[HEDT]

Jatkoa: AMD julkisti Radeon RX Vegat, myyntiin 14. elokuuta

Kyse oli siitä että tarviiko Vega muka 1000W virtalähteen minä sanoin että ei tarvi ja sinä aloit väittää että on niinkovia piiki Watteja että tarvii, niin että kuka on se asiantuntija tässä asiassa kun mielestäni väitteesi niin valtavista piiki Wateista on satukirjasta reväistyyn asiantuntemukseen perustuva.

1000W powerisuositus on ihan ok. Tuollakin testatussa mallissa oli huiput 380W + SKL-X tai TR (12-16c, ( jossa TDP 180W)) josta lisää helposti n. 200W = n.600W ilman kellotuksia +100W muu käyttö + 20% reserviä =n. 840W.

PS Se virtaliitin höpinä oli niin pahasti pihalla että en nähnyt mitään syytä kommentoida siihen yhtään mitään

Se kysymys ei ollut edes sulle osoitettu.
________________________________________________________
Lisää testiä mallista: AMD Radeon Vega Frontier Edition 16GB Review

Pelitestiä UHD- resolla.

Suhteellisen kuumana käy, pelitestiä 30 min. suljettu kotelo, max 100°C:

Kortin kääntöpuoli.

Testi: AMD Radeon Vega FE: Frequency, Temperature & Noise

 

[JiiPee]

Suhteellisen kuumana käy, pelitestiä 30 min. suljettu kotelo, max 100°C:

Ja pointti oli? Mikäli olisit yhtään perehtynyt asiaan, niin tietäisit että Vega FE julkaistiin keskeneräisenä virranhallinnan osalta. Tämän on ihan AMD myöntänyt samassa yhteydessä jossa kertoivat että tiilirendaus ei ole vielä käytössä.

 

[hese_e]

1000W powerisuositus on ihan ok. Tuollakin testatussa mallissa oli huiput 380W + SKL-X tai TR (12-16c, ( jossa TDP 180W)) josta lisää helposti n. 200W = n.600W ilman kellotuksia +100W muu käyttö + 20% reserviä =n. 840W.

Onko? Tomssin testissä 1080Ti. Piikit on 300W, powerisuositus 600W. Aikalailla powerit heikkenee jos 80W lisää tuo 400W isomman powerin tarpeen.

 

[HEDT]

Ja pointti oli? Mikäli olisit yhtään perehtynyt asiaan, niin tietäisit että Vega FE julkaistiin keskeneräisenä virranhallinnan osalta. Tämän on ihan AMD myöntänyt samassa yhteydessä jossa kertoivat että tiilirendaus ei ole vielä käytössä.

Ai, vedetäänkö ne pois myynnistä korjausta varten?

Onko? Tomssin testissä 1080Ti. Piikit on 300W, powerisuositus 600W. Aikalailla powerit heikkenee jos 80W lisää tuo 400W isomman powerin tarpeen.

Luotan, että valmistajien näkemys asiaan on oikea. (he tuskin ns. fanittavat mitään rautaa)

 

[hese_e]

Luotan, että valmistajien näkemys asiaan on oikea. (he tuskin ns. fanittavat mitään rautaa)

Tai ihan piikkinä: Vegan powerisuosituksiin lisättiin extraa, kun skylake-X tuli markkinoille ja tajuttiin, että prosut voikin haukata enemmän..

 

[HEDT]

Tai ihan piikkinä: Vegan powerisuosituksiin lisättiin extraa, kun skylake-X tuli markkinoille ja tajuttiin, että prosut voikin haukata enemmän..

Ihan samalla lailla se TR: in haukkaa..

 

[JiiPee]

Ai, vedetäänkö ne pois myynnistä korjausta varten?

Kuka on sanonut että ne ominaisuudet olisi rikki? Niitä ei vaan ehditty ajureihin/biosiin toteuttaa ja Vegassa bios voidaan päivittää ajuripäivityksen yhteydessä eli korjaantuu kunhan ajuripäivitys tulee.
Eihän se nyt mitään älyttömiä tiputa, mutta jotain kuitenkin. Kyllähän nuo testaajat ajeli korttia reilusti alemmilla volteilla ja näin saivat myös jonkin verran parempaa suorituskykyä kun kortti ei rotlannu jatkuvasti vaan piti koko ajan maksimi kellot.

 

[HEDT]

Kuka on sanonut että ne ominaisuudet olisi rikki? Niitä ei vaan ehditty ajureihin/biosiin toteuttaa ja Vegassa bios voidaan päivittää ajuripäivityksen yhteydessä eli korjaantuu kunhan ajuripäivitys tulee.
Eihän se nyt mitään älyttömiä tiputa, mutta jotain kuitenkin. Kyllähän nuo testaajat ajeli korttia reilusti alemmilla volteilla ja näin saivat myös jonkin verran parempaa suorituskykyä kun kortti ei rotlannu jatkuvasti vaan piti koko ajan maksimi kellot.

Luin tuosta kuumimmasta eli doubleristä. Joka on periaatteessa kuin multiplexeri ja se jakaa yhden PWM- singnaalin kahteen sekä alentaa max kytkentä taajuuden puoleen.
En usko bios/ ajuri- päivityksen alentavan esim. HBM2- muistin lämpöjä yhtään (max 96°C).

 

[hkultala]

Luin tuosta kuumimmasta eli doubleristä. Joka on periaatteessa kuin multiplexeri ja se jakaa yhden PWM- singnaalin kahteen sekä alentaa max kytkentä taajuuden puoleen.
En usko bios/ ajuri- päivityksen alentavan esim. HBM2- muistin lämpöjä yhtään (max 96°C).

DRAMin sähkönkulutukseen vaikuttaa todella paljon se, miten sitä käytetään, esim. kuinka montaa muistisivua pidetään yhtä aikaa auki. DRAMin osalta nämä ovat hyvin monimutkaisia juttuja.

Ja tähän voidaan hyvin suuresti vaikuttaa siihen, miten muistiohjain toimii. Todennäköisesti muistiohjaimeen on suunniteltu useampi eri toimintamoodi sen mukaan, halutaanko maksimaalista suorituskykyä, pientä virrankulutusta vai hyvää kompromissia näiden väliltä. (ja näiden lisäksi voi olla vielä pari erilaisiin tilanteisiin optimoitua moodia)

Voi kuitenkin olla, että jotain näistä moodeista ei vielä varhaisella BIOSilla/varhaisilla ajureilla ole tuettu.
En sano, että näin välttämättä on, mutta tämä on ihan mahdollista.

 

[hkultala]

(ja mobiilipeleissä se grafiikkakerros on abstraktoitu, ei siellä kukaan käytä mitään APIa suoraan)

Ymmärrätkö, mitä sana "API" tarkoittaa?

AMD:n puhelimia odotellessa

Qualcommilla taitaa olla n. 45% markkinaosuus kännyköiden SoC-piireistä.

Qualcommin näyttikset on alunperin kotoisian ATIlta, ATI myi handheld-näyttis-osastonsa qualcommille reilut 10 vuotta sitten.

Tietyissä qualcommin mobiilinäyttiksissä oli aikoinaan huomattavaa sukulaisuutta ATIn/AMDn joihinkin PC-näyttiksiin.
Tosin nykyään tästä on niin kauan, ja molempien kehitys mennyt niin eri suuntiin että enää niissä ei yhtäläisyyksiä juuri ole.

Huoh. Nyt voisit lukea edes sen Wikipedian artikkelin throttlauksesta. Tämä on ihan turhaa käydä väittelyä, kun et osaa edes perusasioita:
Dynamic frequency scaling - Wikipedia

Ei sitä virranhallintaa voida tehdä kuin alikellottamalla grafiikkaprosessoria. Ei tästä tule missään skenaariossa lisää tehoa, päinvastoin..

Huoh vaan itsellesi.

Virranhallintaa voi tehdä _todella monella_ eri tavalla, ja kyse on nykyään hyvin monimutkaisesta asiasta.

Jos esim. piirillä on päällä(idlenä) joku sillä hetkellä täysin turha isohko IP-lohko, se kuluttaa tietyn määrän sähköä vuotovirtana.

Kun tämä IP-lohko power gatetetaan alas, se ei kuluta tätä vuotovirtaansa.

Tämä pienentää piirin virrankulutusta, ja sitten voidaan vaikka piirin muiden osien jännitettä ja kellotaajuutta kasvattaa, ja päästä parempaan suorituskykyyn samalla sähkönkulutuksella

 

[hsalonen]

Ymmärrätkö, mitä sana "API" tarkoittaa?

Olisi pitänyt lisätä low-level api, mutta kun se tuli silloisesta konteksista ilmi..

 

[Kaotik]

Qualcommilla taitaa olla n. 45% markkinaosuus kännyköiden SoC-piireistä.

Qualcommin näyttikset on alunperin kotoisian ATIlta, ATI myi handheld-näyttis-osastonsa qualcommille reilut 10 vuotta sitten.

Tietyissä qualcommin mobiilinäyttiksissä oli aikoinaan huomattavaa sukulaisuutta ATIn/AMDn joihinkin PC-näyttiksiin.
Tosin nykyään tästä on niin kauan, ja molempien kehitys mennyt niin eri suuntiin että enää niissä ei yhtäläisyyksiä juuri ole.

Sen verran pitää korjata että AMD myi, ei ATI ja siitä on vasta vähän vajaa 10 vuotta (2008).
Adreno 200 ehdittiin julkaisemaan alun perin AMD Z430 -nimellä ja on käytössä Freescale i.MX51- ja i.MX53-sarjojen malleissa joissa on 3D:ta tukeva GPU (vaikka ko. piirit taisivat tulla selvästi AMD-Qualcomm-kauppojen jälkeen niin ne on silti AMD Z430 -nimellä eikä Adreno 200 koska Freescale oli hankkinut lisenssit kun Imagineon oli vielä osa AMD:ta)

 

[Andy]

Kyllä ne virtalähteetkin piikkitehoja antaa. Eiköhän Vegallekin se ~650w riitä, jos siihen laittaa pariksi virtapihin Ryzen 6-ytimisen, Intelin virtasyöppöjen sijaan.

 

[jabbadap]

Sen verran pitää korjata että AMD myi, ei ATI ja siitä on vasta vähän vajaa 10 vuotta (2008).
Adreno 200 ehdittiin julkaisemaan alun perin AMD Z430 -nimellä ja on käytössä Freescale i.MX51- ja i.MX53-sarjojen malleissa joissa on 3D:ta tukeva GPU (vaikka ko. piirit taisivat tulla selvästi AMD-Qualcomm-kauppojen jälkeen niin ne on silti AMD Z430 -nimellä eikä Adreno 200 koska Freescale oli hankkinut lisenssit kun Imagineon oli vielä osa AMD:ta)

Tais olla nimeltään Imageon z430. Eikös tuo Imageon ollut ihan suomalaisen BitBoys firman peruja, minkä Ati osti 2006?

 

[Kaotik]

Tais olla nimeltään Imageon z430. Eikös tuo Imageon ollut ihan suomalaisen BitBoys firman peruja, minkä Ati osti 2006?

Ei, kyllä se oli ihan AMD Z430. Imageon on ihan ATI:n peruja, vaikka BitBoys siihen liitettiinkin kun se ostettiin. Z430 ja siten ensimmäiset Adrenot perustuvat lähteestä riippuen Xenosiin tai R600:aan, joka tapauksessa ekoja unified shader gpuita AMD:lta

 

[oma]

Oma näyttö on edelleen ilman Free-suck tai G-suckia.

FreeSuckin saa pienellä Cru-kikkailulla lähes kaikkiin näyttöihin toimimaan ihan ilmaiseksi.. Itse laitoin Yammun Catleappiin piruttain!

Edit: Itseäni kyllä vituttaa ettei Nvidia voi antaa korteilleen freesync tukea. Toki ymmärrän syyn sehän käytännössä tuhaisi G-synkkailun, mutta he ehkä voisivat sen säilyttää niin sanottuna "premiumina".

Edit2: Muistaakseni DP to HDMI adapterilla pitäisi myös toimia. Olisi kyllä mielenkiintosta tietää toimiiko kyseinen kikka myös G-Sync näytöillä..

 

[Andy]

FreeSuckin saa pienellä Cru-kikkailulla lähes kaikkiin näyttöihin toimimaan ihan ilmaiseksi.. Itse laitoin Yammun Catleappiin piruttain!

No perkele tätäkään tiennyt! Harmi vaan, että toimii vain HDMI:llä. Mielummin silti käytän DP:tä ja säilytän 144Hz, koska näyttö ei tue HDMI 2.0.

Ehkä joskus toimii DP:kin kautta.

 

[Griffin]

Kuka on sanonut että ne ominaisuudet olisi rikki? Niitä ei vaan ehditty ajureihin/biosiin toteuttaa ja Vegassa bios voidaan päivittää ajuripäivityksen yhteydessä eli korjaantuu kunhan ajuripäivitys tulee.
Eihän se nyt mitään älyttömiä tiputa, mutta jotain kuitenkin. Kyllähän nuo testaajat ajeli korttia reilusti alemmilla volteilla ja näin saivat myös jonkin verran parempaa suorituskykyä kun kortti ei rotlannu jatkuvasti vaan piti koko ajan maksimi kellot.

¨

Kunnes tulee kortit, BIOS ja ajurit, joilla ko ominaisuus on käytössä toimivasti, HW tason ongelma on täysin mahdollinen.
Ja mitä pidempään kestää, sitä todennäköisempää se on.

Ei AMD halua varmasti tarkoituksella antaa paskaa ensivaikutelmaa VEGAsta. Tällä hetkelläkin vaikuttaa, että kokoajan myöhästytään käytännössä lisää.

 

[HEDT]

VIDEO: EPICIN UNREAL ENGINE 4 -PELIMOOTTORI TAIPUU OSAAVISSA KÄSISSÄ KÄSITTÄMÄTTÖMÄÄN REALISMIIN

Unreal Engine 4 vauhdittaa muun muassa Gears of War 4 -toimintapeliä. GoW 4:n grafiikka kuitenkin raapaisee vain pintaa verrattuna siihen, mihin pelimoottori todellisuudessa kykenee.

De Boerin mukaan hän päätti kokeilla photogrammetry-prosessia, jossa hän käytti tosielämän valokuvia luodakseen allaolevalla videolla nähtävän taideteoksen. Apuna luontiprosessissa toimi Unreal Engine 4 sekä kaksi Nvidian GeForce 1080 Ti -näytönohjainta.

Kokeellaan De Boer halusi omien sanojensa mukaan testata, mihin ohjelmisto ja rauta kykenevät kun niiden ominaisuuksia venytetään äärimmilleen.

On kyllä hienon ja aidon näköistä varsinkin 2160p: llä.

Tällä hetkellä De Boerilla on työn alla demoympäristö, jossa hänen tekemiään kokeiluja voidaan testata reaaliajassa.

Ympäristö tulee tarjolle ladattavaksi Steamin kautta myöhemmin tänä vuonna.

 

[Kaotik]

¨

Kunnes tulee kortit, BIOS ja ajurit, joilla ko ominaisuus on käytössä toimivasti, HW tason ongelma on täysin mahdollinen.
Ja mitä pidempään kestää, sitä todennäköisempää se on.

Ei AMD halua varmasti tarkoituksella antaa paskaa ensivaikutelmaa VEGAsta. Tällä hetkelläkin vaikuttaa, että kokoajan myöhästytään käytännössä lisää.

jos esim DSBR olisi rikki hw-tasolla meillä ei olisi jo testilukemia siitä

 

[Griffin]

jos esim DSBR olisi rikki hw-tasolla meillä ei olisi jo testilukemia siitä

Ominaisuushan voi olla rikki myös s.e. testi voidaan ajaa, mutta piirtämisen lopputulos ei ole kelvollinen, jolloin käytännössä ko ominaisuutta ei voida käyttää...
TAI
Ominaisuuden käyttö voi aiheuttaa tietyissä tilanteessa epävakautta (kuten esim ryzen prossuissa on tällä hetkellä..)

 

[Jahve3]

Väärä ketju

 

[JiiPee]

Tässä on ihan mielenkiintoista juttua varsinkii tuossa videolla joka on tekstin lopussa.

Selitti ainakin itselle aika paljon asioita että miksi DX11 ja DX12 välillä nähdään niin paljon eroja ja miksi AMD hyötyy DX12 huomattavasti enemmän mitä nVidia.

 

[Andy]

Näinkin joskus videon aiheesta, mutta tokkopa enää sitä löydän. Tuo scheduler on myös yksi syy AMD:n korkeampaan virran kulutukseen. Nvidia luopui rautatason schedulerista GTX 480-mallin jälkeen, joka ilmeisesti on melkoinen virtasyöppö myös. Ajuri schedulerilla Nvidia tosiaan lisää prosessorin käyttöä, mikä periaatteessa on siirtänyt hieman virrankäyttöä näyttikseltä preosessorille.

Bitwit testasi, mitä kortteja R3 1300X jaksaa pyörittää. Noissa testeissä 1060 pärjäsi huomattavasti RX 580 paremmin, varmaankin ajureiden takia, vaikka kovemmalla prossulla ovat melko tasaväkisiä. Tämä on saanut hieman myös kaduttamaan RX 480 ostoa, koska oma FX 8350 voisi hyötyä tästä.

 

[hkultala]

Näinkin joskus videon aiheesta, mutta tokkopa enää sitä löydän. Tuo scheduler on myös yksi syy AMD:n korkeampaan virran kulutukseen. Nvidia luopui rautatason schedulerista GTX 480-mallin jälkeen, joka ilmeisesti on melkoinen virtasyöppö myös. Ajuri schedulerilla Nvidia tosiaan lisää prosessorin käyttöä, mikä periaatteessa on siirtänyt hieman virrankäyttöä näyttikseltä preosessorille.

edit: tämä meni ehkä vähän asian vierestä:

Fixed function-rauta tekee saman asian tyypillisesti monta kertaa energiatehokkaammin kuin pieni energiatehokas ohjelmoitava prosessori, ja toisaalta se pieni energiatehokas ohjelmoitava prosessori tekee tyypillisesti saman asian monta kertaa energiatehokkaammin kuin sarjamuotoiseen suorituskykyyn optimoitu CPU, joten en oikein usko tähän teoriaan.



Ja tarkkaan ottaen, minkä asioiden skeduloinnista tässä teoriassa edes on kyse?

Skedulointia tehdään hyvin monella eri tasolla. (prosessorien käskynskedulointi, work grouppien skedulointi ytimille jne).



Tai no:

Jos tarkastellaan shader-prosessoriydinten käskyskedulointia, niin nVidialla on nykyisin käytössään matalamman tason käskykanta jossa suurempi osa käskynskeduloinnista on kääntäjän vastuulla, GCN:n ollessa melko RISC-tyyppinen käskykannan abstraktiotason suhteen, ja prosessoreissa lienee scoreboarding-mekanismi käskyjen skedulointiin(en ole ihan varma tästä scoreboardingista).

Tällä nVidia tosiaan hiukan säästää virtaa AMDhen nähden noissa shader-prossuissa, mutta: nVidian tarvii käyttää se virta CPUlla vain kerran ohjelman alussa kun ne shader-koodit käännetään, ei jatkuvasti.

Mutta: Shader-prosessorien käskynskeduloinnilla ei ole käytännössä MITÄÄN tekemistä CPU-puolen säikeiden/monisäikeistyksen kanssa.



nVidialla lienee käytännössä maailman paras kääntäjäporukka. Noita matalamman tason käskykantoja (exposed datapath architectures) on tutkittu parikymmentä vuotta ja ne on saatu toimimaan hyvällä suorituskyvyllä joissain melko rajoitetuissa tapauksissa, mutta ne on vaan perinteisesti oleet liian hankalia kääntäjälle, tai siis hyvän kääntäjän tekeminen exposed datapath-arkkitehtuureille on vaan ollut todella vaikeaa, ja ne myös vaativat todella hyvän kääntäjän.

nVidia tuntuu kuitenkin tällaisen kääntäjän tekemisessä onnistuneen, ja lisäksi Denver oli myös aika suuri osoitus nVidian kääntäjäporukan taidoista. Aiemmat yritykset ajaa mitään binäärikäännöksellä VLIWillä(transmeta, uudempien itaniumien x86-tuki) kaatuivat huonoon suorituskykyyn kun kääntäjä ei ollut niin hyvä kuin mitä siltä vaadiittiin

 

[BOT]

OT

@hkultala

Ihan kiva että selität kaikkea, mutta näitä teknisiä selityksiäsi on lähes mahdotonta ymmärtää. En ole varma ymmärrätkö itsekään mistä puhut.

Koita jatkossa jäsentää teksti selkeämmin kieliopin mukaisesti.

 

[hkultala]

[offtopic]

OT

@hkultala

Ihan kiva että selität kaikkea, mutta näitä teknisiä selityksiäsi on lähes mahdotonta ymmärtää.
Koita jatkossa jäsentää teksti selkeämmin kieliopin mukaisesti.

Typoja teen jatkuvasti ja paljon, ja sitten ninjaeditoin niitä pois sitä mukaa kun niitä löydän, mutta kieliopillisesti kirjoitan melko korrektia tekstiä.

En ole varma ymmärrätkö itsekään mistä puhut.

Yleisesti ottaen olen täällä niitä henkilöitä, jotka nimenomaan ymmärtävät. Nytkin täällä oli muiden toimesta puhuttu vaan ylimalkaisesti "skeduloinnista" ymmärtämättä yhtään minkä skeduloinnista oli kyse.

[/offtopic]

Skedulointi tarkoittaa asioiden suorittamisjärjestyksen/suorittamisajan päättämistä/valitsemista.

Matalalla tasolla käskyt skeduloidaan (joko kääntäjän toimesta ohjelmaa kääntäessä, tai prosessorin itsensä toimesta kun sitä ajetaan).

Toisaalta, käyttöjärjestelmä skeduloi säikeitä eri prosessoriytimille.

Molemmat ovat skedulointia, mutta tarkoittavat silti aivan eri asioita, ja tapahtuvat aivan eri tasoilla.


Tämän lisäksi näyttiksen tapauksessa tilannetta monimutkaistaa vielä se, että inputtina tulee kolmioita, joiden rendauksessa käytetään monia fixed function-rautapalikoita, ja näillekin pitää mahdollisesti näiden kolmioiden rendausta skeduloida.

Eli, koskaan ei pitäisi puhua pelkästään "skeduloinnista" kertomatta minkä skeduloinnista on kyse, ellei se tule täysin selväksi siitä, missä asiayhteydessä siitä puhutaan.

 

[Andy]

Näytönohjaimen ja prosessorin välisestä keskustelusta "draw call" kyse. Nvidian ajurit osaa jakaa nämä monelle ytimelle dx11 käytettäessä, mutta AMD ei kykene samaan rautatason schedulerin takia.

 

[hkultala]

Näytönohjaimen ja prosessorin välisestä keskustelusta "draw call" kyse. Nvidian ajurit osaa jakaa nämä monelle ytimelle dx11 käytettäessä, mutta AMD ei kykene samaan rautatason schedulerin takia.

Mistä "rautatason skedulerista" nyt oikein puhut?

Mitä se "rautatason skedulerisi" skeduloi?



Mikään näyttiksellä oleva rauta ei skeduloi yhtään mitään CPU-ytimille.

 

[JiiPee]

Mistä "rautatason skedulerista" nyt oikein puhut?

Mitä se "rautatason skedulerisi" skeduloi?



Mikään näyttiksellä oleva rauta ei skeduloi yhtään mitään CPU-ytimille.

Eh... Ei puhe ollutkaan että NÄYTTIKSELLÄ oleva rauta niin tekisi, vaan kyse on siitä että AMD:llä näyttiksessä oleva rauta skeduloi paljon ENEMMÄN asioita kuin nVidia joka tekee ajureilla paljon sellaista mitä AMD tekee näyttiksessä olevalla raudalla. Tästä syystä nVidia voi tehdä kaikenlaisia kikkoja joita AMD ei pysty tekemään koska hommat on jo siirretty GPU:lle.

Se että sinä tiedät paljon asioita on ihan jees. Mutta tuo sinun tyylisi kyykyttää sellaisia joilla ei sitä tietoa ole niin paljoa ja esittävät välillä asiat sinulle ehkä liian "yksinkertaisesti" on aika ärsyttävä.

 

[Andy]

Tai olisit vain lukenut tuon reddit postauksen ja ehkä jopa linkatun videon katsonut.

 

[JiiPee]

Tai olisit vain lukenut tuon reddit postauksen ja ehkä jopa linkatun videon katsonut.

Ja vaikka videolla ei kaikki termit ja muu jargoni ihan täysin oikein menisikään, niin otetaan tähän esimerkiinä Folding@Home jota itse tulee ajeltua talvella kun ei ole niin väliksi sähkönkulutus kun on sähkölämmitys muutenkin.
AMD:n GPU koneessa ja voit ajaa CPU:n kaikilla coreilla CPU foldingia samalla. nVidian kortti kun on kyseessä niin kannattaa jättää CPU foldingista yksi core käyttämättä. Jos laittaa kaikki coret foldaamaan niin se vaikuttaa GPU foldingiin jonkin verran, koska nVidia tekee jotain paljon enemmän ajureilla.

 

[hkultala]

Tai olisit vain lukenut tuon reddit postauksen ja ehkä jopa linkatun videon katsonut.

Olisit vaan itsekin lukenut sen reddit-postauksen loppupuolen.

 

[Zetteri]

Tuosta että Nvidia kortit haluu nopeamman prossun kaveriksi (kun siirtää tehtäviä prossulle) kuin AMD pitää kyllä hyvin paikkaansa.
Tuossa vasta päivittelin Xeon E5 2670 koneeseeni R9 290 tilalle 980Ti. Niin jossain peleissä jopa R9 290 voittaa 980Ti:n tai pääsee ihan tasoihin.
Riippuen siis ihan jo paljon peli osaa hyödytään montaa ydintä.
Näkee vaan kuinka AMD kortti ei ole ihan niin prossu riippuvainen kuin Nvidian.

Tässä ihan videoni missä näkyy tulokset R9 290 vs 980Ti

 

[JiiPee]

Olisit vaan itsekin lukenut sen reddit-postauksen loppupuolen.

Mitä siitä? Oli editoitu ja lisätty jonkuun "tietäjän" näkemys. Ei se invalidoi tuota videon esiinnostamaa asiaa varsinkaan kun siinä ei ole esittää mitään sen oleellisempaa kuin henkilön omia näkemyksiä. Eli videon argumentit on ihan yhtä valideja kuin vasta argumentit.

 

[Kaotik]

Mitä siitä? Oli editoitu ja lisätty jonkuun "tietäjän" näkemys. Ei se invalidoi tuota videon esiinnostamaa asiaa varsinkaan kun siinä ei ole esittää mitään sen oleellisempaa kuin henkilön omia näkemyksiä. Eli videon argumentit on ihan yhtä valideja kuin vasta argumentit.

Ei sillä AMD:n rautaskedulerilla ole mitään tekemistä draw callien tms kanssa. hkultala on täysin oikeassa siinä että pitäisi ensin tarkentaa mistä skeduloinnista puhuu, ja että sinun olisi kannattanut lukea se reddit-postauksen loppu. Se "tietäjä" on RTG:n edustaja, eli Radeon Technology Groupin eli AMD:n.

 

[JiiPee]

Ei sillä AMD:n rautaskedulerilla ole mitään tekemistä draw callien tms kanssa. hkultala on täysin oikeassa siinä että pitäisi ensin tarkentaa mistä skeduloinnista puhuu, ja että sinun olisi kannattanut lukea se reddit-postauksen loppu. Se "tietäjä" on RTG:n edustaja, eli Radeon Technology Groupin eli AMD:n.

En tarkoittanut "tietäjällä" sitä AMD:n heppua vaan sitä aiempaa kommenttia joka otti suoraan kantaa tuohon videon aiheeseen. Tuo AMD hepun kirjoitus on yli vuoden takaa eikä ole mitenkään suoraan vastaus tuohon videoon.
Koska sinäkin nyt tunnut olevan näitä tietäjiä jotka tykkää piikitellä niin kertoisitko sitten mistä nuo erot johtuu jota on jo tuotu esille, miksi siis Folding@Home vaatii nVidian kortilla yhden CPU coren itselleen ja se CPU käyttö ei ole mitään ihan pientä. Kun vastaavasti AMD:n GPU ei laita CPU:lle foldatessa juuri mitään kuormaa?

 

[Kaotik]

En tarkoittanut "tietäjällä" sitä AMD:n heppua vaan sitä aiempaa kommenttia joka otti suoraan kantaa tuohon videon aiheeseen. Tuo AMD hepun kirjoitus on yli vuoden takaa eikä ole mitenkään suoraan vastaus tuohon videoon.
Koska sinäkin nyt tunnut olevan näitä tietäjiä jotka tykkää piikitellä niin kertoisitko sitten mistä nuo erot johtuu jota on jo tuotu esille, miksi siis Folding@Home vaatii nVidian kortilla yhden CPU coren itselleen ja se CPU käyttö ei ole mitään ihan pientä. Kun vastaavasti AMD:n GPU ei laita CPU:lle foldatessa juuri mitään kuormaa?

Mun tekninen tietämys näistä ei ole edes etäisesti hkultalan tasolla, mutta koitetaan.
NVIDIA siirtyi Keplerissä "softaskeduleriin", mikä tässä tapauksessa tarkoittaa että kääntäjä hoitaa warpin (=wavefront=wave riippuen firmasta joka puhuu) sisäisten käskyjen skeduloinnin ja GPU:lta löytyy vain yksinkertainen scoreboardingia tukeva skeduleri (tai itseasiassa useampiakin) warpien välistä skedulointia.
Toimii hyvin pelihommissa, vähän heikommin computessa ja sitä heikommin mitä monimutkaisemmista laskuhommista on kyse.
AMD:lla on Fermin tapaan tuo kaikki hoidettu GPU:n sisällä, eli se osaa ihan itse pistää niitä käskyjä jonoon eikä sille tule ongelmia siitä että sieltä tulikin joku yllättävä stalleja tai toisista riippuvaisia käskyjä tms

 

[JiiPee]

AMD:lla on Fermin tapaan tuo kaikki hoidettu GPU:n sisällä, eli se osaa ihan itse pistää niitä käskyjä jonoon eikä sille tule ongelmia siitä että sieltä tulikin joku yllättävä stalleja tai toisista riippuvaisia käskyjä tms

Niin tuosta löytyy suht kattavaa juttua vaikka täältä
NVIDIA GeForce GTX 680 Review: Retaking The Performance Crown

 

[Dodekaedri]

Niin tuosta löytyy suht kattavaa juttua vaikka täältä
NVIDIA GeForce GTX 680 Review: Retaking The Performance Crown

Artikkelin oikeellisuutta en pysty arvioimaan, kaikki asiasta löytämäni tiedot vaikuttavat aika ylimalkaisilta. Joka tapauksessa tuonkin perusteella skedulointiin liittyvää työtä olisi siirretty raudalta kääntäjälle. Ohjelma täytyy kääntää vain kertaalleen ennen suorittamista, joten jatkuvaa CPU-kuormaa asia ei aiheuta.