Įvyko „nVidia“ GTC renginys, žaidėjams nieko įdomaus

Vakar vyko „nVidia“ GTC renginys. Daugelis jo metu tikėjosi kažką išgirsti apie naujas vaizdo plokštes žaidėjams, ar bent pamatyti jų išleidimo planą. Deja, „nVidia“ generalinis direktorius net nepalietė šios temos ir kalbėjo apie dirbtinį intelektą, „Ray Tracing“, save vairuojančius automobilius ir pristatė pora darbo stotims skirtų produktų, tiesa įspūdingų.

„Quadro GV100“ remsis „Volta“ architektūra, turės 5120 CUDA branduolių ir 32 GB HBM2 atminties. Kartu su „Tensor“ branduoliais ši vaizdo plokšte turės iki 118 TFLOPS skaičiuojamosios galios. „Quadro GV100“ buvo sukurta visai neseniai išleistai „nVidia“ RTX (Real Time Raytracing) technologijai. Jos demo ir matėme GTC metu. „nVidia“ gali sujungti du GV100 grafikos procesorius NVLink pagalba, tada vienas akseleratorius gali turėti iki 10240 CUDA branduolių.

Kitas produktą galime prilyginti super kompiuteriui, o „nVidia“ tai vadina tiesiog didžiausiu grafikos procesoriumi pasaulyje. Tiesa, tai yra į vieną kompleksą sujungti 16 „Tesla V100“ grafikos procesorių, kurių kiekvienas disponuoja 32 GB HBM2 atmintimi. Visa sistema turi 512 GB atminties buferį ir 81920 CUDA branduolius. Šis monstras gali pasiūlyti 2000 TFLOPS skaičiuojamąją galią. Visi grafikos procesoriai vienas su kitu yra sujungti NVLink pagalba ir gali dirbti kaip vienas. Toks super kompiuteris kainuoja viso labo 399 tūkst. JAV dolerių.

46 Komentarai

  1. mafo parašė:

    Esu žiauriai nusivylęs ir kažkodėl visai nesijaučiu nustebęs. Tiesiog racionalu buvo nieko naujo nepristatyti tuo metu kai lentynos tuščios ir nespėjama gaminti jau dabar egzistuojančių VGA. Tiesiog reikia drožti pinigą o dar AMD spaudimo nedaro, nors ir išspaudė vega64 GTX1080 lygį, bet kainos nežmoniškos ir „out of stock“. Visgi žiūrėjau iki pat galo su viltimi, kad bent kažkas bus. 😀

  2. BC00 parašė:

    Štai, mieli žaidėjai, kur dedami jūsų pinigai 😀

  3. kernel_panikuoja parašė:

    Jus isisamoninkit ta fakta, kad NVIDIA yra didesnis uz visa AMD (iskaitant ir CPU dali), o pelningumu visa AMD’a lenkia desimtimis kartu (75 kartus, jei pagal 2017’tus). Pamirskit jus tas svajones, kad Radeon’ai ar ju „ekosistema“ kazkada bus visom prasmem pazangesni uz NVIDIA’ijos produktus, nes taip nebus. Nebent pastaroji iseis is consumer segmento. Ko galima tiketis, tai AMD produktu, kurie case by case bus konkurencingi kainos prasme, panasiai kaip Ryzen’as.

    Vien programuotoju resurso skirtumas yra milziniskas. NVIDIA turi kruva enterprise-grade GPU-related solution’u nuo A iki Z, turbut kokias tris cloud’o versijas. AMD turi GPUOpen iniciatyva ir kratini open source komponentu su mintimi „pasidarykit patys“, nes jie fiziskai negali tiek implementint. Cia ne stumimas ant AMD, tai normalu ir tiek.

    • mafo parašė:

      Jeigu taip tai rek paremt AMD… 🙂 Nusipirksiu vadinasi ryzen… na bet VGA tai bus Nvidia 😀

    • Strelok parašė:

      “ o pelningumu visa AMD’a lenkia desimtimis kartu (75 kartus, jei pagal 2017’tus) “

      Nu man tas gana keista, kad AMD grynasis pelnas toks žemas palyginus su Nvidia, nors pajamos tik 2 kartus žemesnės. Aišku, AMD ilga laiką dirbo į minusą. Tačiau turėdama panašiai darbuotojų kaip Nvidia ir 10x mažiau nei Intelis palyginus gerai varo per CPU ir GPU markets.

      • kernel_panikuoja parašė:

        Taip, tie 75 kartai grynai del buvusiu nuostoliu. Mano mintis buvo daugiau ta, kad NVIDIA gali sau leisti daug brangesni R&D. Net jeigu einant laikui skirtumas tarp ekonominiu rodikliu sumazes, vistiek reikia ivertint ta fakta, kad NVIDIA uzsiima is principo tik GPU, o AMD ir GPU, ir CPU, ir APU, ir semi-custom ir embedded. Sutinku, kad pagal situacija, AMD daro kone stebuklus.

        • Strelok parašė:

          Nu manau, kad reiketu lyginti ne grynaji pelna, o pajamas. Kurios praeitais metais tik 2 kartus nusileido Nvidios. Grynasis pelnas tai yra kas lieka sumokejus visus mokescius, development islaidas ir atlyginimus ismokejus. Aisku jeigu lyginti su Intel tai AMD tikrai yra David pries Goliath

  4. Gnytasis parašė:

    Bent pafantazuokim 😀 Nu jeigu palygint pascal quadro su 1080 ti, atminties skirtumas 5gb, tai tada 2080 ti jeigu tokia bus tures kokia 18 ar 20 gb atminties jeigu nedaugiau 😀

  5. Andria parašė:

    Tai panašu, kad nesuklydau prieš kelias savaites 1080Ti pirkdamas 😀

  6. IFeelYou parašė:

    Koloniuk, tau naują kortą išleido su 32 GB vRam. Kada galime tikėtis rezultatų forume? 🙂

  7. Stipena parašė:

    Turi nvidia nv linką kuris yra superior prieš SLI, bet paprastiem useriam duoda penisa graužt ir bando SLI nužudyt. Galėtumėt sau ramiai su 3x1080Ti 4K 144Hz žaisti, bet ne, only for quadro.

    • SoTOP parašė:

      Skaičiavimai ir panašiai puikiai „scalinasi“, o žaidimam visas procesas daug sudėtingesnis. Praktiškai ir dabar, su tinkamai suprogramuotu žaidimu, galėtum turėti kokį 250% vienos plokštės greičio naudodamas tris, bet žaidimų kurimas ir optimizavimas yra sudėtingas ir dėl to brangus reikalas.

      • IFeelYou parašė:

        Šiaip SoTOP visiškai teisus, yra benchmarkų kur su specifiniais skaičiavimais paprastas SLI scalinimas yra 70-90%. Bėda manau čia daugiau slypi pas žaidimų developerius kuriems reikia visko greitai ir kuo pigiau prasisukt.

        • Minde parašė:

          nelabai suprantu prie ko cia zaidimu developeriai. Cia grynai game’engino reikalas. Nebent jis labai abstractus ir palikta zaidimu kurejamas kilometrai vietos implementacijoms.

          Zaidimu kurejai tai praktiskai konfiguruotojai plius teksturos, ir tam tikros 3d modeliu elgesnu instrukcijos, kas visai neturi nieko bendro su atvaizdavimu. Juk vaizdo plokstei vienodai, ar kaireje objektas ar desineje.

      • Minde parašė:

        kaip jau rasiau, nesuprantu, prie ko cia zaidimas. Cia galetu viska suzaisti driveriu lygmeny. Tik proco pajegumu daugiau reiktu dvi tokias plokstes aptarnauti. Bet jei stabdis vaizdo apdorojimas, tai jokiu problemu. Cia ir CPU daugiau branduoliu turi. Cia gal drtx’as normaliai nepalaiko. Duodi sugeneruoti vienai plokstei vaizda, ir kol si nebaige generuoti duodi kitai sugeneruoti pagal naujesne busena. Ir viskas. Gal kazkiek fokusu butu su CSS kur ten kazkaip nuo fps viskas priklauso, bet ir ten manau isprendziamas reikalas. O kada duoti sekanti vaizda kitai plokstei: na arba kada ji atsilaisvina, arba pasikaiciuoti kiek laiko uztruko daryti pries tai buvusi frame’a, kad tolygiau juos kepti.

        Manau siaip visi dejo ant to SLI. Bet be drxt’o yra vulcanas, paskui OpengGL’as, kas manau galetu suimplementuoti dvieju vaizdo ploksciu palaikyma.

        Kas cia koja galetu pakisti: kad vienam vaizdui post procesinti panaudojamas buves frame’as. Nors labai abejoju.
        Antra, kad ramu, ir proco nuskaitymas susijes su vaizdo apdorojimu beveik padvigubetu. Kai dabar CPU turi daug branduoliu, tai ne problema. Ramai kazkiek gal stabdytu, bet jei stabdymas mazesnis negu sugeneruota nauda – super.

        Zodziu, nematau kodel negalima vien driveriu pagalba pasidaryti to SLI, crossfire ar dar ko. Isvis, kam vienai plokstei reikia zinoti apie kita. Cia nebent kai dali frame’o generuoja viena VGA, kita dali kita, tai jiems gal tien NLinkai ir reikalingi. Bet kai share’inimas atsiranda, tai ir reikia visokiu papildomu pgrogramavimo isikishimu. Nors, neoptimizuojant ir cia ju nereiketu.

        • IFeelYou parašė:

          Kaip suprast kam reikalinga vienai plokštei žinoti apie kitą? SLI veikia Master/Slave principu. SFR atveju dalį vaizdo (top) generuoja Master, apačią generuoja Slave. Po to Slave siunčia viską Master kad sudėti į vieną. Ar ne taip?

        • SoTOP parašė:

          Vienas iš SLI veikimo būtų yra Alternate Frame Rendering, kuris iš esmės ir daro tai ką pasakei. Problema, kad priversti gerai veikti visą tai yra daug kartų sudėtingiau negu tu įsivaizduoji.

          • Minde parašė:

            nemanau. Gal tiesiog niekas neinvestavo i tai. Lygiai kaip niekas neinvestuoja i normalu SLI palaikyma. Pvz Nvidia daznai bendradarbiauja kuriant zaidimus, bet daznai uztenka darbo ta pati zaidima iskepti. O kalbant apie zaidimu kurejos, tai ka tik iseje zaidimai buna kiauri, bugovi, tad tas SLI paskutiniame plane.

      • kernel_panikuoja parašė:

        Nesidomejau kaip tiksliai implementuotas NVlink’as, bet galiu pasakyti tiek, kad kol dev’ai negaus visiskai permatomos multiGPU abstrakcijos, tol labai abejoju, ar jus matysit gera scale’a daugumoje zaidimu. Isimtis butu nebent tai, jeigu einant laikui visus pagrindinius variklius redesign’ins nuo 0 taip, kad visi optimaliai isnaudotu DX12/Vulkan funkciuonaluma ir ju teikiama mGPU (kas yra paciame API), apeinant visas SLI/Crossfire nesamones driver’iuose. Bet tam reikes nemazai laiko ir pastangu is dev’u, o del pastarojo buvimo as labai abejoju.

        As kazkaip manau, kad ateityje bus multi-chip’ines GPU kortos, kur keletas GPU bus sujungit kazkokiu high speed interconnect network’u, panasiai, kaip pas NVIDIA DGX2 ar AMD infinity fabric. Dev’ai matys viena abstrahuota GPU, o kazkoks greitas HW ir minimalistinsi driver’is load’a permatomai skirstys keliems chip’ams. Atitinkamai isidejes antra korta, turesi dar daugiau „horse power“ po apacia. Gal ir klistu, bet man asmeniskai cia atrodo realesnis approach’as multi-GPU implementacijoje nei tiketis, kad tinginiai programeriai kazka gerai optimizuos.

        PS. Sakydamas dev’ai turiu omenyje tuos, kas daro varikli.

        • Minde parašė:

          kaip ir sakiau, yra du budai panaudoti kelias vaizdo plokstes:
          Kai kelios vaizdo plokstes piesia ta pati vaizda, bet cia vel, kam tas enginas? Pati viena vaizdo plokste yra multi irenginys. Tereikia kad antra vaizdo plokste prailgintu ta multi irengini. Va cia ir ateina visokios jungtys tarp ploksciu. Tik klausimas kaip ten sharinasi resursais, gal reikia gudriau kaip nors, kad efektyviai padaryti resursu sharinima ir cia gali buti arba gali nebuti daug sudetingumu.

          Ir antras budas: kai viena vaizda piesia viena vaizdo plokste, o antra vaizda piesia antra vaizdo plokste pirmai dar nepabaigus piesti. Cia isvis nereikia jokiu jungciu ir vaizdo plokstems nereikia nieko vienai apie kita zinoti. Nebent problema butu duomenu uzkrovimo skirtumai, ir, jei pvz ramu truksta, ir pastoviai kraunami duomenys, ir viena vaizdo plokste krauna leciau, tai kazkiek sutrukdytu grazu sklandu darba. Bet gal driveriais galima butu kazka ispresti. Zodziu, mano galva cia paprasciausias reikalas.

          Zaidimas tai: 3d modeliai laike su teksturomis, vaizdo procesinimu (apsvietimai, efektai ir t.t.) bei post procesai.

          Zaidimai vyksta taktais (nors teoriskai gali buti ir ne taktais) , tad kas takta sugeneruojamas 3D modeliu duomenis naujame takto laike ir visa tai paduodama i vaizdo plokste. Toliau eina keli variantai:
          Vienas: kad laukiama kol vaizdo plokste sugeneruos vaizda, ir tik sugeneravus pradedama skaiciuoti.
          Antras variantas, kad gali sugeneruoti nauja 3D modeliu vaizda dar nesulaukus vaizdo.
          Trecias variantas, kad taktas yra fiksuotas, ir tai kaip zaidimo bio laikrodis.

          Va tik tiek tos magijos.
          Taip, jei yra variantas, kad game enginas laukia kol GPU sugeneruos vaizda ir tik tada perskaicuojamas taktas, tada kelios nepriklausomos vaizdo plokstes nepades. Tereikia pakeisti maza takto inicializavimo dali ir olia…. Taip, jei ten persipine per penkis kokius programavimo sluoksnius ar n libu su uzdaru api, tada gali buti sunkumu. Bet manau issprendziama, juk ne bankas, nebent suartys, kad negalima keisti kodo 😀 Bet mintis ta, kad didziaja dali zaidimu enginu butu galima paturbinti gan lengvai.
          Antras variantas, kad jau nieko daryti nereikia.
          Trecias variantas: cia gali buti keli sub variantai: kad taktai skaiciuojami per letai, tai tada joks SLI apskritai nepades, na kazkiek fps padetu sumazinti kai viena frame’a apdoroja kelios vaizdo plokste, bet gali buti, kad paskui greitai ji apdorojus bus apdorojamas antras toks pats frame’as.
          Jei visgi taktai greiti, tai jokiu problemu, laisvai tinka tas variantas, kur kelios nepriklausomos vaizdo plokstes.

          Kas as noriu pasakyti, kad tereikia kad koks drtx’as ar koks kitas libas moketu dirbti su dviem nepriklausom VGA, o zaidimu varikliai turetu moketi dirbti atitinkamais taktais ir tiesiog paprasyti sugeneruoti vaizda, kol dar kita vaizdo plokste nebaige generuoti – ir olia, viskas vazuoja. Ten jau menas aisku butu padaryti, kad 2 vaizdo plokste duotu 80% vertes, bet kad koki 40%, manau lengvai. Dabar kai kuriuose zaidimuose su SLI isvis bedos buna.

          • Minde parašė:

            pamirsau apie sujungima dvieju vaizdo ploksciu su monitoriumi. Tai reiktu kokio gudraus kabelio sakotuvo (G-syncas neveiktu, nebent butu sustras ir brangus kabelis), arba tiesiog butu masteris ir slave’as, ir masteris turetu moketi vaizda is slave’o persiusti, kaip ir dabartiniuose SLI.

        • Minde parašė:

          ir man toptelejo, kodel programuotoju gali reiketi isikysimo del SLI 🙂

          pagalvojau, kad VGA sistema pati galetu moketi pasiskirstyti duomenis ir viena skaicuotu viena dali, kita antra. Bet tas paskirstymo mechanizmas turetu buti ziauriai gudrus. Ir daug paprasciau, kad enginas pats padaro du atskirus vaizdus, ir nepriklausomai paduoda vaizdo plokstems. Na cia panasiai kaip skiriasi vazidas nuo rezoliucijos pasirinktos ar monitoriaus. Teoriskai cia nieko gudraus nereikia, vaizdo plokstes susisneka, kad baige darbus, slave’as atiduoda savo dali masteriui, masteris jas sudeda ir issiuncia. Ir nieko sudetingo. Du vaizdai, tereikia kad game variklis tuos du vaizdus iskirptu, o tai nesudetinga, nes reialiai tuos vaizdus jau skirtingus karpo pagal monitorius ir rezoliucijas.

Parašykite komentarą

Brukalų kiekiui sumažinti šis tinklalapis naudoja Akismet. Sužinokite, kaip apdorojami Jūsų komentarų duomenys.