Strona 394 z 394 PierwszyPierwszy ... 294 344 384389390391392393394
Pokaż wyniki od 3931 do 3938 z 3938

Wątek: miniNEWS oraz dyskusje

  1. #3931
    Member
    Awatar Skoti
    Dołączył
    Feb 2003
    Postów
    669
    Podziękowania

    Domyślnie


    Reklama widoczna tylko dla niezalogowanych użytkowników
    Cytat Zamieszczone przez Monio Zobacz posta
    Jedyna rzecz której brak w wersji OpenCL w stosunku do CUDA to CMJ który nie sprawi większego problemu z przeportowaniem
    Nie sprawi - TO PRAWDA, jednak wydajność mocno spadnie i o tym mówię. Obecnie sampling w wersji OpenCL jest bardzo prosty (szybciej zrobi N-sampli, ale wygląda nieporównywalnie gorzej przy tej samej ilości sampli). Correlated Multi-Jittered Sampling od Pixara czyli quasi-Monte Carlo robi olbrzymią różnicę w jakości i wydajności, dlatego teraz porównywanie wersji OpenCL bez niego z CUDA z CMJ jest po prostu niepoważne, bo przy tej samej ilości sampli na jednym masz tylko szum, a na drugim jakość produkcyjną.

    Cytat Zamieszczone przez Maciek Jutrzenka Zobacz posta
    Skoro Cuda jest taka ekstra a AMD i opencl jest napisany na kolanie to jakim cudem, Cuda wypada tak źle.. to jest wina developerów blendera czy samej biblioteki/api Cuda?
    To zupełnie nie tak. Porównujesz po prostu dwa zupełne renderery. Wygląda to trochę tak jakbyś mówił, Cycles ssie, bo Blender Internal szybciej wyrenderuje - prawda, ale efekt jest zupełnie inny.

    Co do AMD i OpenCL to AMD dobi bardzo dobre karty obecnie a i OpenCL jest obecnie wyśmienity. Problem nie w tym, że nowe karty AMD są złe czy 2.2 nie daje Ci czegoś ważnego dostępnego w CUDA, bo daje wszystko. Kompilacje offline kernelów (z możliwością znacznie dalej idących optymalizacji niż online) dzieki SPIR-V masz od OpenCL 2.1, Dynamic parallelism z CUDA masz w OpenCL 2.0, Concurrent Kernel Execution (Hyper-Q) masz w teorii od OpenCL 1.2. Tylko tak jak kilka lat temu OpenCL dobijały karty i sterowniki AMD tak teraz dobija go Nvidia i przykładowo wszystko powyżej OpenCL 1.2 nie jest wspierane przez ich sterowniki (mimo, że sterowniki OpenCL 2.x mają od lat i mam do nich dostęp, ale nie wydają publicznie), a Concurrent Kernel Execution przez nich nie jest wspierane (a przynajmniej poprawnie) przez co w programach konsumenckich zostaje używać api w wersji zupełnie nieprzystosowanej do obecnego sprzętu (specyfikacja 6-7 lat) - to nie znaczy, że OpenCL jest pisany na kolanie, o nie... to znaczy jedynie, że jego ekosystem jest bardzo podzielony i tym co dzielą wcale nie zależy na popularyzacji OpenCL'a, więc dopóki nikt Nvidii nie zmusi (a był czas gdy tak było, bo był hype na OpenCL, ale AMD go wtedy ubijało), ich polityka się nie zmieni, a co za tym idzie OpenCL będzie w plecy

  2. #3932
    Member

    Dołączył
    Mar 2015
    Postów
    1355
    Podziękowania

    Domyślnie

    owkeeeey czyli jak rozumiem Open CL jest bardziej zawansowane od CUDA. A Nvidia specialnie nie wspiera nowego Open CL aby ludzie używali ich CUDY? correct?

    sprawa numer dwa.. Cycles na karcie AMD w trybie open CL to inny silnik niż na karcie Nvidi w trybie CUDA... Rozumiem. Tylko dalej nie rozumiem jednego... czego silnik cycles na nvidi... tak strasznie zwalnia gdy scena jest skomplikowana że nawet CPU jest szybsze. A na karcie AMD nie zwalnia.... nie testowałem jak bardzo różnią się rendery za pomocą diff. ale.. no jak patrzysz okiem to nie widać różnicy.

    czyli to nie jest wina cuda? tylko developerów którzy słabo zakodowali silnik na cudzie?

  3. #3933
    Member
    Awatar Skoti
    Dołączył
    Feb 2003
    Postów
    669
    Podziękowania

    Domyślnie

    Cytat Zamieszczone przez Maciek Jutrzenka Zobacz posta
    owkeeeey czyli jak rozumiem Open CL jest bardziej zawansowane od CUDA. A Nvidia specialnie nie wspiera nowego Open CL aby ludzie używali ich CUDY? correct?
    OpenCL 2.2 jest porównywalny z CUDA... no ok SPIR-V i możliwość kompilacji C++ do niego jest naprawdę fajna, ale to nie sprawa wydajności, a odpowiedniego pośredniego języka i dostarczonych kompilatorów. Nie jest bardziej zaawansowane, ale nie ma żadnych słabości. I tak... Nvidia specjalnie nie wypuszcza sterowników do OpenCL (którego sami tworzą, a szefem standaryzacji OpenCL dalej jest wiceprezes Nvidii).

    Cytat Zamieszczone przez Maciek Jutrzenka Zobacz posta
    Tylko dalej nie rozumiem jednego... czego silnik cycles na nvidi... tak strasznie zwalnia gdy scena jest skomplikowana że nawet CPU jest szybsze. A na karcie AMD nie zwalnia.... nie testowałem jak bardzo różnią się rendery za pomocą diff. ale.. no jak patrzysz okiem to nie widać różnicy.

    czyli to nie jest wina cuda? tylko developerów którzy słabo zakodowali silnik na cudzie?
    Dlatego, że nie wszystkie algorytmy są dla architektury SIMT/SIMD zabójcze, a nie mają z nim problemów arch MIMD (jak CPU). Nie bez powodu fizyka akcelerowana przez GPU w grach to dalej nie jest standard... o ile GPU sobie świetnie radzą z fizyką ciuchów, fluidów itp... to zupełnie padają przy zwykłej fizyce brył sztywnych. Tak samo tu jest. Liczenie permutacji w Correlated Multi-Jittered Sampling prowadzi do branchowania kodu przez co przykładowo jeśli masz 64 rdzeni w SIMD na karcie graficznej to w zależności od danych wejściowych działać może od 1 do 64 rdzeni (czytaj od 0 do 63 na 64 rdzenie odpoczywa i nic nie robi, bo mogą wszystkie wykonywać na raz taką samą instrukcje na innych danych, a że już tamte wyszły z brancha to muszą czekać aż inne też to zrobią, aby prace kontynuować). CPU jest tak zaprojektowane (MIMD) z prostej przyczyny - jest uniwersalne i nie zwalnia w zależności od danych wejściowych. Wersja OpenCL ma bardzo prosty sampling i nie branchuje.

    OFC możesz sobie sprawdzić czy to wina CUDA odpalając blendera i w wersji OpenCL na karcie Nvidii (sterownik Nvidii OpenCL implementuje tak, że kompiluje kernele OpenCL online do CUDA i ogólnie tak czy tak wykonywany jest kod CUDA - tylko gorszy jakościowo, bo na kompilacje kernela nie miał kilku-kilkunastu minut (jak to jest w kompilacji offline, gdzie optymalizacja jest dogłębna), a kilka sekund ).

  4. #3934
    Member

    Dołączył
    Mar 2015
    Postów
    1355
    Podziękowania

    Domyślnie

    Am am. Czyli To że openCL jest szybkie to zasługa tego że używa gorszego samplera który jest zdecydowanie szybszy?

  5. #3935
    Member
    Awatar Skoti
    Dołączył
    Feb 2003
    Postów
    669
    Podziękowania

    Domyślnie

    Cytat Zamieszczone przez Maciek Jutrzenka Zobacz posta
    Am am. Czyli To że openCL jest szybkie to zasługa tego że używa gorszego samplera który jest zdecydowanie szybszy?
    Nie tylko... i OpenCL nie jest szybsze, tylko cycles w wersji OpenCL szybciej sampluje... co oznacza, że N sampli per pixel zrobi Ci szybciej, ale obrazek w porównywalnej jakości już wolniej, bo potrzebuje conajmniej kilkukrotnie więcej sampli na pixel aby rezultat był podobny - czyli jeśli zrobisz benchmark renderowanie N sampli to faktycznie wyjdzie szybciej, a jeśli po jakości/zaszumieniu sromotnie przegra - zależy czy mówimy o rezultacie czy cyferkach których się nie da porównać rzetelnie . Na CPU też renderery z samplingiem Monte Carlo czy Metropolis light transport samplują wolniej i tyle samo sampli uzyskasz dużo szybciej na weekendowych projektach studentów... tylko szum przy tej samej ilości sampli nieporównywalny - jeśli liczysz czas jako sample per pixel w danym czasie to wszystkie najlepsze renderery unbiased zasysają względem prostych hobbystycznych projeków... jeśli liczysz czas do wyrenderowania produkcyjnej jakości obrazka to już jest odwrotnie.
    Ostatnio edytowane przez Skoti ; 27-05-17 o 08:23

  6. #3936
    Member
    Awatar Idaho
    Dołączył
    Mar 2004
    Lokalizacja
    Warszawa
    Postów
    469
    Podziękowania

    Domyślnie

    Jakoś mi umknęło
    Silhouette brush w blenderze, ładnie to wygląda oby tylko skończyli
    https://wiki.blender.org/index.php/U...C2017/Proposal
    orientuje się ktoś może czy Laplacian Mesh Optimization (jest też w GSOC-u 2017) wpłynie na wierniejsze odwzorowanie alph i detalu w blenderze? Czy trzeba jednak czekać na nowy silnik ? Na dzień dzisiejszy większość ludzi pomimo że robią w blenderze detal przerzuca do zetki by uzyskać np takie pory skóry, zmarszczki itp.
    Ostatnio edytowane przez Idaho ; Dzisiaj o 10:10

  7. #3937
    Member
    Awatar mandragora
    Dołączył
    Jan 2006
    Postów
    670
    Podziękowania

    Domyślnie

    podoba mi się to i wygląda to na coś co konkretnie pomoże w pracy, brakuje tylko tworzenie dziur
    Mój komputer działa

  8. #3938
    Been Through the Mill
    Awatar Nezumi
    Dołączył
    Oct 2006
    Lokalizacja
    Ciudad de Mexico
    Postów
    4433
    Podziękowania

    Domyślnie

    Rewelka. A do dziur masz carver addon, ale jakby tu tez zintegrowali to by byla moc.

    w zasadzie jak poczytalem to nigdzie nie jest zdefiniowane ze nie bedzie wycinania dziur - wrecz przeciwnie, wydaje mi sie ze w subtract to bedzie:

    "If in subtractive mode, the stroke defines parts of the mesh which get cut out. It works like a subtractive boolean operation of the additive shape with the existing geometry"

    Czy to nie sugeruje tez dziur?
    Ostatnio edytowane przez Nezumi ; Dzisiaj o 14:56
    “There is nothing noble in being superior to your fellow man; true nobility is being superior to your former self.”
    ― Ernest Hemingway

Uprawnienia umieszczania postów

  • Nie możesz zakładać nowych tematów
  • Nie możesz pisać wiadomości
  • Nie możesz dodawać załączników
  • Nie możesz edytować swoich postów
  •