[Zonerman]

Teema oleks hea, kui siin nii palju paska ei oleks. Sorry et olen otsekohene. Nii palju kui mina omal käel olen uurinud seda teemat, siis KÕIK on alles varajases staadiumis, et enne oleks vaja nii öelda "kukk kinni püüda" kui sellest juba suppi teha tahetakse.

On ikka imemehi, kes teevad suuri järeldusi ühe mängu mootori põhjal, mis ka veel poolik. Kui selle järgi midagi üldse üldistada, siis on kõik samal pulgal mis puutub AMD /NVIDIA DX12 PRAEGUSTE kaartide supporti. Mõlemal head halvad vead ning uutel kaartidel hakatakse kasutama rohkem DX12 featuure rauas.

[Vael]

Mida ma oleks oodanud, et AMD FX 8350 Inteli i3-st natuke ette rebiks ikka. http://www.pcper.com/reviews/Graphics-Cards/DX12-GPU-and-CPU-Performance-Tested-Ashes-Singularity-Benchmark/Results-Heavy
Video esitluses ka mainis, et jääb segaseks CPU-de osa...

[Scart]

[Etz]

[Scart]

[londiste]

Scart, su viimane post ei aita jälle asjale kaasa.
Etz, miks on vaja norima hakata kui eelnev post on actually asjassepuutuv ja õigeaegne?

aga kollocki postist dx12 kohta:

[Revilo]

[Scart]

[londiste]

Revilo, nvidia pahaseks saamise osas - dev üsna otse ütleb, et nvidia draiverid pole valmis async shaderitega seoses

ashes praeguses seisus raisk alla 4 core lihtsalt ei tööta.
dualcore peal nagu töötaks aga pilti näita ja annab random tulemusi jms anomaaliad.
oma masina peal dx11 all i7 kasutab benchi ajal 65-70%, ühegi core kasutus oluliselt suurem ka ei ole.

[Scart]

Btw, AMDi poolne smearing campaign oli lihtsalt hale. Tüübid organiseerisid vähemalt Beyond3D, HardOCP ja Guru3D foorumitesse "kasutajad", kes levitasid Ashesi testi FUDi tubli nädal aega ning kes nüüd üksteise järel "ära kaovad". Madal, madal.

HardOCP foorumis oli staariks see düüd - http://hardforum.com/member.php?u=286820 Õnneks oli teistel kasutajatel piisavalt kogemust, et asi juba esimestel päevadel läbi näha.

[Etz]

[Archangel]

Kõrvaltvaatajana jääb mulle selline mulje, et siinne rahvas nagu ise tahaks saasta lugeda ja draamat tekitada.

Piisab, kui üks inimene ajab veidi jama või sõnastab midagi valesti ning kohe on kümme teist tüüpi kraes. Nahhui nada. Tegelikult on ju ükstapuha, kes mis firmat fännab. Absoluutselt 0 tähtsust, kui asi puudutab fakte. Pole mõtet kellelgi demagoogitseda.

Aru ma ei saa, miks pagana pärast on vaja üldse mainida kellegi eelistusi siin teemas. AMD, Nvidia - täiesti pohhui ju. Mitte kellegi eelistused ei muuda fakte. Argumenteerida tuleb argumentide vastu, mitte inimeste vastu.

Ning veel tobedam on see, et hakatakse veel üksteist idiootideks sõimama selle asemel, et argumenteerida. Keegi loeb siinseid postitusi, saab valesti aru, küsib ausa küsimuse ning vastuseks saadetakse põhimõtteliselt perse ja sõimatakse nägu täis, võtmes a'la "ma pole seda öelnud, bla-bla-bla". Väga tore - kui keegi mõistab kellegi postitust valesti, siis tuleb seletada ilusti kuidas asja mõeldi, selle asemel, et segaduses inimene perse saata ning ülbitseda.


Ning mis veel ajudele käib, on see, et selle asemel, et ilusti rääkida teemast, loobitakse lihtsalt artikleid vasakule ja paremale. Pool aega unustatakse mainida, et mis argumenti see artikkel peaks nagu toetama, ja kus kohas. Teinekord loe 3 lähekülge mingi suvalise blogipidaja spekuleerimisi läbi ning aru ei saa mitte muhvigi.


Londiste on see, kes siin normaalselt räägib. Oleksid ülejäänud ka sellised, oleks siin teemas rahu majas.

[rene p]

Archangel,

Valame õli veel tulle juurde
http://wccftech.com/preemption-context-switching-allegedly-best-amd-pretty-good-intel-catastrophic-nvidia/

[Vondur]

[lopes39]

http://www.guru3d.com/news-story/nvidia-will-fully-implement-async-compute-via-driver-support.html

[Denkeš]

[erick]

Ma vahepeal tuletan meelde, et ükski driver ei asenda riistvaralist funktsiooni ilma suurte jõudlusekadudeta. NVidia võib siin vabandada ette ja taha oma drivereid, aga sisuliselt on küsimus ikkagi nende 31 queue depth vs AMD 64 queue depth async computes.

[londiste]

erick, su väited on väga kategoorilised, äkki täpsustaksid oma seisukohtade põhjuseid?
miks queue depth nii oluline on? see võib muutuda oluliseks optimeerimisel kuid mitte otsese mõju tõttu jõudlusele.
hard datat igat pidi hetkel lihtsalt ei ole ja ei saagi olla enne kui nvidia oma draiveritega valmis on ja dx12 laiemat kasutust leiab. shaderite jagamise haldus softis võib olla perf hit kuid võib osutuda ka oluliseks optimeerimisnüansiks. haldus on piisavalt keeruline "funktsioon", et selle rauas tegemisel jäävad piirangud, mida sama softis tehes saab ümber mängida (tänases paradigmas nagu mänguprofiilid draiverites).

mitte, et nvidia (siiani kinnitamata aga väga tõenäoline) rauas halduse puudus pettumus ei oleks, aga ma ei näe kuidagi ka sellist katastroofi nagu sa jutlustad.

sulle numbrid meeldivad. siis spetsiaalselt sulle need uuesti:

[Revilo]

[londiste]

Revilo, aukude kasutamine ei tööta selles mõttes reaalajas.
pikk pipeline ja mingil määral vajalike asjade ette teadmine on niikuinii olemas. probleem võiks olla pigem prosekasutuses.
töö jagamise alternatiiv softis tegemisele - prediction algoritm rauas - on muide üsna hardcoded.

[erick]

londiste, queue depth defineerib mitu async compute workloadi saab korraga töötada. Kui mälu ei peta (viimastel päevadel on sel teemal saanud läbi kammitud kümneid artikleid ja foorumithreade), siis iga korralik workload (füüsika, valgustus, post-processing efektid, view culling jne) vajas suurusjärgus 16-32 queue depthi. Ehk siis 31 võimaldaks äärmisel juhul kahte workloadi, 64 aga võimaldab kuni 4.

Sisuliselt tuleks teha valik siis - mida async compute mode'is siis võtta näiteks ülaltoodud neljast - kas füüsika ja valgustus, või post-processing ja view culling? AMD samal ajal jooksutab kõiki nelja ilma mingi perf hitita.

[londiste]

erick, mingit linki nende queuede või workloadide (mis on erinevad asjad) vajaduse kohta?

perf hit ei tule mitte queue depthist vaid sellest kui palju (ja milliseid) ressursse queued tarbivad, kaasa arvatud (ja eelkõige) primary graafika oma.
su viimane lause on huvitav - see tähendab, ühte kahest:
- amd arhitektuuri või draiverite tõttu on kaartide efektiivsus üsna masendav.
- need workloadid ei ole väga koormavad.

[erick]

Ma olen aru saanud, et queuede arv defineerib selle, mitu workloadi saavad graafikaga samal ajal joosta. Ehk mida rohkem queuesid seda rohkem tööd suudetakse ühe taktiga ära teha. Kahjuks mul ei õnnestu leida konkreetset viidet, aga mäletan selgelt juttu, et AMD kaartidel on võimalik 3-4 workloadi graafikale lisaks ja nVidial siis riistavaraliselt pool sellest või vähem.

Muide, tegelikult oli ka enne Ashes of Singularityt olemas benchmark, mis näitas selgelt ära kui palju efektiivsem on AMD GCN arhitektuur workloadide puhul, mis elavad compute queude arvu peal:



Kunagi ammu peeti seda müsteeriumiks, aga nüüd me siis teame, miks see nii oli.

[londiste]

sellepärast, et amd integer võimekus, arvutusüksuste arv ja struktuur toetavad bitcoini kaevandamise algoritmi paremini. või mida sa silmas pidasid?

edit:
su enda graafiku allikast:

[erick]

Värskemate vaadete kohaselt oli asi ikkagi selle taga, et massiivse paralleelsuse puhul annab compute queuede arv kõvasti perfi juurde teatud tüüpi rakendustele.

[londiste]

erick, tahitil 16 queued ei olnud? 2 ace, 8 queued each.

edit:
on jah. isegi amd enda 7900 seeria specide leht ütleb: Dual Asynchronous Compute Engines (ACE)
elik, su enda jutu järgi ei kõlba üldse kuskile.

[erick]

londiste, 15 queued rohkem kui Titanil või GTX 680-l (kummalgi 1 graphics ja 1 compute queue). Tulemust võid graafikult vaadata.

[londiste]

erick, source? hyperq oli juba kepleris, ehk siis 32 queued.

[erick]

[londiste]

Hyper-Q for CUDA streams vs Hyper-Q for MPI connections?
esimest titan toetab, teist mitte. mpi on mingi supercomputerite asi.
ma ei suuda kuskilt kiire guugeldamise tulemusena välja lugeda titani piiranguid.

[erick]

[londiste]

erinevad allikad pakuvad numbreid 4-32.
proovi järgi

[erick]

londiste, mina mingi CUDA progeja pole, aga kui doktorikraadiga inimene kes uurib graafikatehnoloogiat ütleb, et ta üle 8 striimi pole käima saanud Titani peal, siis ma kaldun teda uskuma.

Muidugi kui sul on mingi lihtne programm millega seda testida, siis võin proovida.

[londiste]

üldiselt läheb see juba väga teemast mööda.

[gl0be]

yall snickers need to get laid.

Rääkige asjast, Millal tuleb ja kas asja saab (kuulduste järgi) ?
Kas RWEd on olnud ahhetama panevad või pigem keskpärased? tehke rumalale nüüd mingi kokkuvõte, lõpetage sõdimine.

[NATAS999]

[erick]

"Veidi efektiivsem" on ikka understatement of the century. Oluliselt efektiivsem multi-core CPU kasutus (räägitud on numbritest +50% fpsile), lisaks async compute lubab suurusjärgus 30-50% paremat fps-i sõltuvalt kaardist. Kahjuks nagu ilmneb on vanematel ja isegi praegustel nVidia kaartidel vähe tolku async computest, aga AMD omanikud alates HD7800 seeriast peaksid küll sillas olema.

[Scart]

[londiste]

erick, amdst räägid? sul on õigus, seni ainsa ashesi testitulemused näitavad amd kaartidel umbes +50% fpsile.
nvidia kaardid millegipärast on dx11 all samapalju ees ja dx12 all üsna võrreldavas olukorras.

dx11 osas on ilmselt oma osa sellel jutul: http://www.anandtech.com/show/2716/3

[NATAS999]

erick, visuaalsest küljest oli juttu ja seal vallas ei toimu suuri muudatusi. esiteks seda on näidanud ajalugu, et graafika ei arene nii järsult, et see kohe yõsiselt wow effekti tekitaks ja teiseks, on ürgaja tehnoloogiaga konsoolid jälle piiduriks visuaalse külje arengule.

[londiste]

NATAS999, kui su eelmise posti ja viimase posti esimese poolega võib nõus olla, siis konsoolide kommentaariga ilmselt mitte.
gcn on amd kaartides siiani ja konsoolides peaks täiendatud gcn 1.2 olema, mis on täiesti state-of-the-art, täna ja kindlasti lähema aasta-paari jooksul. jõudlus võib olla probleem, aga mitte tehnoloogia.

dx12 teeb eelkõige parema optimeerimise võimalikuks (seejuures mitte tingimata lihtsamaks). uusi efekte on läbi aegade juurde tilkunud aga mingit murrangulist muudatust dx12 oodata ei tasu. nii amd kui nvidia on näidanud, et nende puudujääkidest saab võrdlemisi väikse vaeva (ja jõudlushitiga) ümber ja midagi tegemata ei jää.

jõudluse ja uuemate-paremate efektide osas on kuigi aeglustunud aga siiski jätkuval väiksemale tootmisprotsessile minekul palju suurem osa. võimaldab kasutatad rohkem transistoreid suuremate gpu-de puhul ja väiksemaid (odavamaid) kive ja vähem voolu väiksemate puhul.

[erick]

[kaspar737]

[erick]

Nii palju siis Nvidia async compute võimekusest:

[Vael]

Viimase aja mänge vaadates tekib küsimus, et kus kohast seda visuaali veel kenamaks kruttida saakski? Kui FPS takistama ei tuleks, siis on mängud juba ilusamad ja detailsemad kohati kui päris elu(Crysis 3 Ultra peal).
Paljukirutud Witcheri optimiseerimine tuli ka FPS arvelt arvatavasti, kui seal ka FPS poole kõrgem oleks olnud, siis poleks seal ka millegi üle enam nuriseda olnud.
Kus nuriseda annab on füüsika, inimeste liikumine jne...

Ja ma ei räägi mingitest suitsu liikumise mustritest või mingi väikse detaili varju kuvamisest selle pimedasse nurka 1cm2 suurusele alale. Madistamise ajal seda nagunii tähele ei pane. Nagu see demo, kus aegluubis võib märgata erinevust, vean kihla, et kui 10 sellist mängus tuld annaks mängija pihta, siis need varjud oleks viimane asi mida märgata;) https://www.youtube.com/watch?v=rd4DE-RG_jw

[erick]

Vael, no otse peast asju mida DX12 võimaldab oluliselt paremini teha:

1. Palju suurem draw distance
2. Palju suurem AI juhitud tegelaste arv
3. Palju suurem hulk autosid/lennukeid/kaste/füüsikaliste omadustega detaile
4. Detailsem füüsika
5. Parem valgustus
6. Paremad eriefektid ilma kohutava slowdownita (post processingu abil, nt Bokeh)

[kaspar737]

[Scart]

[erick]

Scart, kui sa lähed viimases lauses viidatud postitusele, siis sa loed sealt sama juttu mida ma kirjutasin, kenasti arusaadava metafoori kujul (seinapesijad vs seinamaalrid). Loomulikult on kõigil mängutootjatel mõistlik "vana" rendering path sisse jätta, nVidia jaoks. Aga mis puudutab async computet, siis korralike workloadide puhul pole Nvidial mitte mingit lootust Nii lihtsalt on ja ükski driver ei suuda luua olukorda, kus CPU teeb sama töö ära kiiremini kui GPU enda peal olev pisiprotsessor.

[Scart]