KGPU, czyli CUDA w Linuksie

1. "da się zauważyć przewagę karty Nvidia GTX 480 nad procesorem Intel Core i7-930" (autor: bumblebee | data: 11/05/11 | godz.: 16:33)
   Bzdet tygodnia.
   
   
2. haha (autor: Aamitoza | data: 11/05/11 | godz.: 16:53)
   przewaga GTX480 nad i7 930? No fajnie, fajnie. Ale i7 930 nie wspiera instrukcji AES, przez co szyfrowanie idzie na nim wolno. Niech porównają do SB które jest kilka/kilkanaście razy szybsze w AES od bloomfielda.
   
   
3. @Aamitoza (autor: Promilus | data: 11/05/11 | godz.: 17:01)
   W syntetykach kilkanaście, w realu kilka. GPU jest w realu kilkanaście razy szybsze :) Szkoda, że nie zrobili tego z OpenCL bo GTX480 chowa się bodajże nawet przed 5770 ;)
   
   
4. @bumblebee (autor: emulator | data: 11/05/11 | godz.: 17:20)
   nie śmiej się z wedelka, pochodzi ze wsi gdzieś w południowo zachodniej Polsce na pograniczu hanyso-gorolskim, czasami nawet gwarą pisze.
   
   
5. emu (autor: Aamitoza | data: 11/05/11 | godz.: 17:23)
   Jak Ty piszesz, to czasem się zastanawiam z jakiej planety jesteś, bo na pewno nie z naszej. I też się wtedy lekko uśmiecham, ale jedynie z politowania.
   
   
6. Badania byly przeprowadzone pod linuxem (autor: Sony Vaio rev 6.0 | data: 11/05/11 | godz.: 17:27)
   ktos pisal by zrobic OpenCL, ups amd i linux, chyba niedziala.
   
   
7. sony (autor: Aamitoza | data: 11/05/11 | godz.: 17:44)
   Ty również mógł byś zacząc pisać po polsku, lub po prostu pisać spójnie i logicznie. W przedszkolu dzieci układają już bardziej zaawansowane logicznie zdania - nie wspomnę już o ich większej spójności.
   
   
8. @emulator (autor: Wedelek | data: 11/05/11 | godz.: 18:01)
   Nie przypominam sobie bym gwarom pisał... Potocznych słów użyłem nie raz, a i owszem, ale gwary nie znam:(
   
   Ja wcale za tymi wynikami nie obstaję, bo według mnie akurat w tym przypadku różnica będzie strasznei mała, ale jeśli wyskalować odpowiednio, to wyjdzie że jednak różnica jest duża. Zresztą podkreśliłem to słowem "Podobno". Myślę, że bumblebee dobrze o tym wie i chciał poprostu wyrazić swoją opinię na ten temat, a nie konkretnie zganić mnie osobiście.
   
   Co zaś tyczy się Ciebie, to niestety nie mam zbyt dobrego zdania o osobach, które sądzą innych tylko po miejscu ich zamieszkania...
   
   
9. @up (autor: Wedelek | data: 11/05/11 | godz.: 18:02)
   mój błąd, nawet napisać tego nie umiem:P Gwarą miało być, rzecz jasna:P
   
   
10. @sony gówno (autor: Promilus | data: 11/05/11 | godz.: 18:10)
    Akurat nie ma najmniejszego problemu z AMD pod Linuksem czy choćby aspektem w postaci ICD OpenCL. Tak samo jak ujadacze nvidii ryczą, że hd4k i opencl na tych kartach to totalne nieporozumieni.
    Polecam przejrzeć komentarze:
    http://www.geeks3d.com/...mark-based-on-luxrender/
    Jak widać testowałem i na windowsie, i na linuksie. Ale kibol karciochowy ze szczątkową inteligencją wie lepiej ;)
    
    
11. @ Promilus kulturalny i wyksztalcony, (autor: Sony Vaio rev 6.0 | data: 11/05/11 | godz.: 18:18)
    zaginasz rzeczywistosc, typowa umiejetnosc przebrzydliwego fanboja amd. Od lat amd ssie w linuxie, maja tragiczne wsparcie, compiz na tych kartach nie domaga, ale ty masz zwajhrowane oko i wszystko jest ok. Wszystkiego najlepszego i zebys w czysccu musial odpracowac te brednie, konfigurujac linuxy na amd.
    
    
12. Promilus (autor: Gigant | data: 11/05/11 | godz.: 18:41)
    A jak tam ten tessmark? Załączyli w końcu ten drugi tesselator w Caymanie czy ciągle nie? ;)
    
    
13. he he (autor: Jarek84 | data: 11/05/11 | godz.: 19:23)
    moherowy sony zaswiatami straszy... :D
    
    @Gigant - dołączyłeś do tych, co grają w smarki?? ;>
    
    
14. emulator (autor: agnus | data: 11/05/11 | godz.: 19:50)
    "gdzieś w południowo zachodniej Polsce na pograniczu hanyso-gorolskim"
    
    Większej bzdury dawno nie słyszałem. Pogranicze hanyso-gorolskie jest w południowo-zachodniej Polsce? ROTLF. Zerknij jeszcze raz na mapę.
    
    
15. @Sony (autor: Promilus | data: 11/05/11 | godz.: 20:30)
    tak, tak, compiz nie domaga, a unity nie działa ;) A OpenCL szkoda gadać, ciągle kernel panic ^^ Masz zwichrowaną psychę, szkoda mi cię ;)
    @Gigant - mnie się nie pytaj, szukaj odpowiedzi w results tessmarka.
    
    
16. KGPU, czyli CUDA w Linuksie (autor: Marucins | data: 11/05/11 | godz.: 20:45)
    Ciekawe jak to dalej potoczy się...
    
    Cuda jest od pewnego czasu na OSX co z tego skoro nie ma softu wspierającego ta technologię!
    
    
17. @Marucins (autor: Promilus | data: 11/05/11 | godz.: 20:50)
    CUDA na Linuksie są od dawna, KGPU to projekt mający doklepać do samego kernela wspomaganie niektórych zadań przez GPU (nv) poprzez CUDA. MacOS X to Apple, a Apple stawia na swoją działeczke tj. OpenCL. Nie na rękę im support CUDA.
    
    
18. Czytajac wasze blyskotliwe fanboyowskie teksty (autor: Takeya | data: 11/05/11 | godz.: 21:23)
    mam nadzieje, ze w koncu TwojePC zablokuje mozliwosc komentowania wpisow. Autentycznie, odechciewa sie czytac ten serwis przez idiotow pokroju SV cz mogriego, dla ktorych jednordzeniowe Atomy sa lepsze do peceta niz dowolny Phenom...
    
    
19. @Takeya (autor: xernos | data: 11/05/11 | godz.: 21:45)
    A mi tm takie "twórcze komentarze" nie przeszkadzają w większości przypadków, czasami są ciekawsze od samego artykułu :] -pzdr.
    
    
20. Promilus (autor: Gigant | data: 11/05/11 | godz.: 22:23)
    http://www.erodov.com/...0-review/41513-page6.html
    
    Na najnowszej wersji tessmarka 0.3.0 i ze sterami 11.3 nadal Cayman ma jedynie 9 fps w w trybie insane....czyli tyle samo co Cypress i 8x mniej niż GTX580.
    
    Nie potrafią tego tesselatora włączyć czy może Cypress już ma 2 tesselatory? ;)
    
    
21. "CUDA w Linuksie" (autor: 5eba | data: 11/05/11 | godz.: 23:41)
    nigdy ich nie brakowało ;D
    
    
22. A co z OpenCL u nV i Intela? (autor: MBR[PL] | data: 12/05/11 | godz.: 00:07)
    Cholera, może by wreszcie poszli po rozum do głowy i wsparli otwarty, crossplatformowy standard jakim jest OpenCL, mający wsparcie nie tylko pod Windows, Linux, ale i MacOS - Apple od dawna go wspiera. Bo skończy się jak zwykle (już to przerabialiśmy z OpenGL i OpenAL) - standard otwarty, darmowy, crossplatformowy, przychodzi MS i rozjeżdża towarzystwo jak walec drogowy ze swoim DX, niedługo pewnie DirectCompute. Intel co prawda wypuścił OpenCL ...ale tylko działający na ich CPU (OpenCL ICD AMD działą i na sprzęcie Intela), nVidia maniacko promuje CUDA. AMD porzuciło długofalowe wsparcie dla Stream CAL/Brook) i zdecydowało się wspierać otwarty OpenCL. Przypomina to wojny w piaskownicy - przez to prawie nie ma softu wspierającego GPGPU, w szczególności niezależnego od sprzętu, a bardzo szkoda.
    
    Co do wynurzeń o nie działaniu GPUGPU/OpenCL pod linuksem na AMD/ATI - dość śmieszne są te powyższe teksty, (przynajmniej cześć z nich). Jak zwykle wypowiadają się najczęściej fanboje, którzy nie mają o tym pojęcia i nawet tego nie sprawdzali w praktyce. Tak się składa, że dla przyjemności liczę cały czas GPGPU pod linuksem (co prawda Stream, nie OpenCL bo taki jest klient dnet, ale jednak). I działa idealnie - mimo że z tego co niektórzy pisali, działać nie ma prawa - na 64bitowym ubuntu (podobno wieszającym się co chwila ;>, R4850 i starym Athlonie64 3000+ - już nie używany normalnie sprzęt do pracy 24/7 liczący GPGPU, seedujący torrenty (distro, a nie lewizna - teraz choćby nowy Backtrack 5.0 o którym jakoś cicho w PL sieci, a miał premierę już wczoraj. Poniżej kawałek logów:
    [May 11 21:48:10 UTC] The keyserver says: "Danish cows go Oink!"
    [May 11 21:48:10 UTC] Refreshed project state data from server. (cached)
    [May 11 21:48:11 UTC] RC5-72: Retrieved stats unit 43 of 43 (100.00%)
    [May 11 21:48:12 UTC] RC5-72: Sent 1 packet (64.00 stats units) to server.
    [May 11 21:48:12 UTC] Connection closed.
    .....10%.....20%.....30%.....40%.....50%.....60%.....70%.....80%.....90% ...
    [May 11 21:57:44 UTC] RC5-72: Completed CE:F951EBE9:00000000 (64.00 stat ...
    0.00:09:55.21 - [461,809,698 keys/s]
    [May 11 21:57:44 UTC] RC5-72: Loaded CE:F7F6DD4A:00000000:43*2^32
    [May 11 21:57:44 UTC] RC5-72: Summary: 1442 packets (86408.00 stats units)
    9.05:11:59.01 - [465.97 Mkeys/s]
    [May 11 21:57:44 UTC] RC5-72: 158 packets (9995.00 stats units) remain in
    buff-in.r72
    Projected ideal time to completion: 0.22:12:40.00
    
    Działa nonstop od prawie 10 dni licząc GPGPU (wyłaczam jak wyjeżdżam z domu na dłużej - jednak trochę szkoda prądu).
    Wiem, że z powyższego wynika niezbyt zawrotna szybkość obliczeń, ale to już starszy, nie używany sprzęt - szkoda mi głównego desktopa na Phenomie II/AM3 z Win7 do takiej pracy 24/7. Najciekawsze, że pod linuksem dnet GPGPU dział znacznie stabilniej w dłuższych okresach czasu - pod Win7 jednak jest z rzadka, ale jednak BSOD od czasu do czasu. Na pewno pomaga też wrzucenie do crona pauzowania klienta na 1 minutę co pół godziny - następuje wtedy automatyczne przełączenie z 680 MHz@1,120V na 250MHz@0,892V - choćby po to by niezbyt rozsądnie zrobiona goła (bez radiatora) sekcja zasilania na asuowym R4850 z Glaciatorem trochę ostygła przez tą 1 min.
    
    
23. CUDA juz od dawna uzywane ale w specjalistycznych zastosowaniach (autor: VP11 | data: 12/05/11 | godz.: 07:46)
    Prosze poczytac ze obliczenia wykonane za pomoca CUDA (tesla C1060) jest szybsze o okolo 13 raz niz obliczenia tego samego procesorem Xeon E5410. Tyle ze dedykowane karty CUDA kosztuja. Ale mowimy o sytuacji, gdzie czas obliczen jest istotny i czesto zakupywany sprzet kosztuje kilkadziesiat tys. zlotych. A to tylko by policzyc cos w ciagu kilkunastu dni a nie kilku miesiecy.
    Sa dedykowane programy ktore wymagaja kart z CUDA aby moc liczyc szybko.
    Dla przecietnego uzytkownika to bajer.
    
    
24. kontynuacja (autor: VP11 | data: 12/05/11 | godz.: 07:48)
    http://static.msi.umn.edu/rreports/2011/26.pdf artykul o wykorzystaniu CUDA, prawda po angielskiemu.
    
    
25. @Gigant (autor: Promilus | data: 12/05/11 | godz.: 08:09)
    "Nie potrafią tego tesselatora włączyć czy może Cypress już ma 2 tesselatory? ;)"
    Nie udawaj głupa. W UH2.1 tryb OGL cayman i cypress podobne wyniki, tryb DX11 i cayman jest sporo przed cypressem. Wiem, ty dalej wierzysz że cypress ma 2 rasteryzatory ;) Więc teselatory pewnie też, haha.
    
    @MBR[PL]
    Trochę niżej info o ivy bridge, ponoć ma igp już ocl wspierać.
    @VP11 -
    "obliczenia wykonane za pomoca CUDA (tesla C1060) jest szybsze o okolo 13 raz niz obliczenia tego samego procesorem Xeon E5410"
    Z tym co teraz napiszę to i pewnie morgi się zgodzi. Aplikacja w CUDA z kodem na równoległe przetwarzanie danych na kilkuset cuda cores kontra zero optymalizacji dla x86... Człowieku, pierwszy klient GPU Milkyway@home był tak szybki na tle SSE2 że wróżyli koniec ery CPU, a dali kompetentnemu kolesiowi go poprawić (Crunch3r) to nagle przewaga stopniała. Łatwo jest własny brak umiejętności pisania szybkich aplikacji ukryć dzięki jeszcze szybszemu sprzętowi. Jak topowa tesla jest w typowych zadaniach 10x szybsza od średniego quad core to jest dobrze. Nie liczyłbym na więcej. Więcej bywa, ale w bardzo specyficznych zastosowaniach.
    
    
26. @25 (autor: Jarek84 | data: 12/05/11 | godz.: 10:05)
    Hindi coders - z własnej autopsji i bez komentarza ;) = "Optimization, what optimization?!?!? - people should have more powerfull hardware"
    
    
27. niezła zagwozdka (autor: Qjanusz | data: 12/05/11 | godz.: 11:16)
    co bardziej polubią Linuxowcy?
    
    zamknięte CUDA, czy otwarte OpenCL
    CUDA działające tylko na GeForcach, czy OpenCL działające na wszystkim.
    
    
28. Qjanusz, polubią to co działa (autor: Sony Vaio rev 8.0 | data: 12/05/11 | godz.: 11:30)
    amd olewa sprawę sterowników w linuxie, jak masz lapka i kartę pokrojy 3450 jest ok, schody zaynają się w nowszych od 6850 np. Compiz nie działa nawet na 11.5, a wbudowany ster testowany przez brać lunuksową fgrlx bodajże to 8.3. Ogólnie tragedia na tym polu
    
    
29. @Sony (autor: Promilus | data: 12/05/11 | godz.: 13:10)
    http://ubuntuforums.org/...hp?t=1676402&page=2
    Taa, nie działa compiz... siur, a plamy na Słońcu spowodowały już roztopienie lodowców i zalanie Ziemi ;)
    
    
30. Promilus Ty chyba mnie nie czytać (autor: Sony Vaio rev 8.0 | data: 12/05/11 | godz.: 13:23)
    napisałem o ubuntu 11.04, na razie lipa, dokładnie to samo było z 10.10, dopiero po jakimś czasie udało się amd to zrobić. Możnra było kombinować z nieficjalnymi sterami, a poem usuwać watermark, ale nie tędy droga.
    
    
31. @sony (autor: Promilus | data: 12/05/11 | godz.: 13:27)
    sam jesteś nieoficjalny ster...
    
    
32. ta Promilus zajebiste te amd w linuxie (autor: Sony Vaio rev 8.0 | data: 12/05/11 | godz.: 13:32)
    rozumiem żeby robić myki ze sterami, wklepywać kody by odblokować shadery, umożliwić podkręcanie, ale nie do bidy nyndzy żeby poprawnie wyświetlać pulpit i potem jeszcze takie typy jak Ty mają czelność mówić, że linux to przyjazny system dla laika.
    
    
33. @sony multiban (autor: Promilus | data: 12/05/11 | godz.: 14:17)
    gówno wiesz i gówno widziałeś. Tak mogę tylko te twoje brednie podsumować.
    
    
34. typowe, masz problem z linuxem jesteś odiotą (autor: Sony Vaio rev 8.0 | data: 12/05/11 | godz.: 14:41)
    dla tego ten system zawsze będzie gówniany, przez jego społeczność
    
    
35. @sony (autor: Promilus | data: 12/05/11 | godz.: 15:01)
    Ty nie masz problemu z linuksem. Ty nie masz problemu z Radeonem. Ty masz problem ze sobą. A świadczy o tym choćby twój status multibana...
    Problemy konkurenta 6850 pod nowym ubu
    http://ubuntuforums.org/showthread.php?t=1743407
    http://ubuntuforums.org/showthread.php?t=1743821
    http://ubuntuforums.org/showthread.php?t=1595509
    Heh. Tylko drobny procent wszystkich ;) No tak, ale najlepiej napisać, że "amd olewa sprawę sterowników w linuxie". Ty nie szukasz rozwiązania problemu, ty szukasz kogo by tu obwinić o problem. I jak to zwykle u trolli internetowych bywa obrywa nielubiana firma. Dlatego zawsze będziesz gnębiony - masz tylko to na co trollowaniem zasłużyłeś. Porzuć wydurnianie się i wojenki to może się coś zmieni.
    
    
36. @sony - przestań już zgrywać guru dla zakompleksionych (autor: Qjanusz | data: 12/05/11 | godz.: 16:47)
    AMD wcale nie olewa Linuxa.
    Fakt, KIEDYŚ Radki pod Linuxem były do tyłu w porównaniu z nVidią.
    
    Teraz to się zmieniło. A ten co pisze że jest inaczej to zwyczajnie zmyśla.
    
    Zresztą, nawet gdyby była to prawda, to akurat taki wpis pod Twoim nickiem bardzo wątpliwej reputacji, czyniłby z tej wypowiedzi czystą brednię.
    
    
37. Promilus (autor: Gigant | data: 12/05/11 | godz.: 17:30)
    Cypress ma 2 rasteryzatory, 1 tesselator i 1 geometry assembler. O co ci chodzi? Cayman ma 2 teselatory , 2 geometry asemblery i 2 rasteryzatory.
    
    No powiedz dlaczego w tessmarku Caymany nadal nie są 2x szybsze od Caypressa? Jeden tesselator AMD jest 2x szybszy od tego Nvidii.
    2 tesselatory AMD to jak 4 u Nvidii...
    
    
38. @Gigant (autor: Promilus | data: 12/05/11 | godz.: 17:52)
    "Cypress ma 2 rasteryzatory"
    Na slajdzie... i nigdzie więcej.
    
    
39. Promilus (autor: Gigant | data: 12/05/11 | godz.: 19:01)
    Nie na slajdzie. Ma w realu 2 rasteryzatory ;)
    
    
40. @Gigant (autor: Promilus | data: 12/05/11 | godz.: 19:04)
    To czemu przetwarza 1 trójkąt na cykl.. lol
    
    
41. Promilus (autor: Gigant | data: 12/05/11 | godz.: 19:19)
    Trójkąty to ustawia geometry assembler... Rasteryzator je wypełnia pixelami...
    
    (-;
    
    
42. @Gigant (autor: Promilus | data: 12/05/11 | godz.: 19:52)
    "AMD created some confusion on this front when it introduced Cypress by claiming the chip had dual rasterizers. In reality, Cypress was dual core "from the rasterizers down," as a knowledgeable source put it to me recently. What Cypress had was dual scan converters—a pixel-throughput optimization for large polygons—but it lacked the setup and primitive interpolation rates to surpass one triangle per clock cycle"
    Rasteryzacja to proces przenoszenia sceny 3D w 2D monitora zatem i ładowanie krawędzi poly, i skanowanie pikseli poly to proces zachodzący w raster engine czy też rasterizer. Widać teraz moda na rozdzielanie wszystkiego i zmiany nazw. Rasterizer może być całkowicie programowy (i był, 15 lat temu). Prawdziwy dual rasterizer (u AMD graphics engine) to ma cayman. U NV to samo nazywa się raster engine. A jak coś nie działa w OGL to się korzysta z software rasterizer. Rasterizer, nie raster engine, nie graphics engine.
    
    
43. Promilus (autor: Gigant | data: 12/05/11 | godz.: 23:34)
    Rasteryzacja to proces wypełniania trójkątów pixelami. http://pl.wikipedia.org/wiki/Rasteryzacja
    
    Rasteryzator jedynie wypełnia trójkąty pixela. Do przetwarzania trójkatów jest geometry assembler... ;0
    
    
44. @Gigant (autor: Promilus | data: 13/05/11 | godz.: 07:34)
    Jak zwykle polska wiki wszystko upraszcza dla osób mających nikłe pojęcie... a może tak inaczej? Pełniej? Lepiej?
    http://en.wikipedia.org/wiki/Rasterisation
    Jak widać rzeczywiście AMD może mieć w cypressie 2 jednostki do scan conversion czyli to co tak ładnie źle polska wikipedia podaje jako proces rasteryzacji.
    
    
45. Promilus (autor: Gigant | data: 13/05/11 | godz.: 14:12)
    To co opisuje ta niepolska wikipedia to cały proces renderignu a nie rasteryzacja. Opisują nawet teksturowanie, usuwanie niewdocznych krawędzi, że to rasteryzacja. Technicznie opisali cały potok graficzny jaki karta wykonuje. Więc jeśli chcesz zaliczyć jednostki TMU do rasteryzatora to proszę bardzo ;-)
    
    
46. @Gigant (autor: Promilus | data: 13/05/11 | godz.: 15:17)
    Nieprawda, widać słabo znasz angielski.
    Primo
    "At a very basic level, rasterizers simply take a stream of vertices, transform them into corresponding 2-dimensional points on the viewer’s monitor and fill in the transformed 2-dimensional triangles as appropriate"
    Secundo
    "While the basic rasterization process has been known for decades, modern applications continue to make optimizations and additions to increase the range of possibilities for the rasterization rendering engine"
    Czyli mowa tylko i wyłącznie o rozszerzeniach typowego SILNIKA RENDERUJĄCEGO opartego o rasteryzację, a nie rasteryzatora. Czytaj ze zrozumieniem. BTW dalej nie wierzysz w mikroarchitekturę Core, Core 2, Nehalem? Tylko P6, P7, P8...
    
    
47. Rasteryzacja polega na tym, że (autor: Gigant | data: 13/05/11 | godz.: 16:00)
    algorytm rasteryzujący zapala piksele leżące najbliżej krzywej/wewnątrz figury...
    
    Natomiast przetwarznie, usuwanie trójkątów to nie jest rasteryzacja... Od tego jest geometry assembler i backface culling...
    
    
48. Promilus (autor: Gigant | data: 13/05/11 | godz.: 17:02)
    Core, Core 2 - nazwy handlowe procesorów
    Penryn ,Nehalem - nazwy kodowe procesorów
    P7, P8- architektura rdzenia (generacja)
    
    
49. @Gigant (autor: Promilus | data: 13/05/11 | godz.: 17:37)
    Przecież udowodniłem ci jasno, że nawet intel stosuje nazwy core uarch, core2 uarch a nie żadne P7, P8, P9... P6 to też było wszystko od Pentium Pro, poprzez Pentium II, Pentium III, Pentium M czy wreszcie Core. Później nie było P7 tylko Netburst. Później nie było P8 tylko Core2. Ostatnio nie P9 i P10 tylko Nehalem i Sandy Bridge. awet w najbardziej optymistycznych marketingowych scenariuszach sandy bridge i ivy bridge to ledwie gen9, tak samo bulldozer. A Ivy Bridge to odmienna mikroarchitektura od Sandy Bridge więc nie sraj mi tu z generacjami, bo to jak widać jest prawie wcale nie skorelowane.
    http://www.beyond3d.com/content/news/618
    http://www.radgametools.com/pixomain.htm
    Tutaj rasterizer to zajmuje się jak widać kompletnym potokiem, lol. Widać znaczeń jest tyle co przyzwyczajeń inżynierów/programistów.
    
    
50. Promilus (autor: Gigant | data: 13/05/11 | godz.: 19:00)
    Jezu ale ty tępy jesteś... To się tak mówi, że GPU to urządzenia rasteryzujące grafike. Ale procesy takie jak transformowanie, usuwanie niewidocznych trójkątów, vertex/pixel shading, teksturowanie nie zaliczają się do procesu rasteryzacji... i są wykonywane przez inne dedykowane jednostki...
    
    Intel jest debilem skoro nazywa core uarch jakby nie mógł użyć P8... Co to jest wogóle core uarch? Conroe, Nehalem, SB wszystkie to core a bazują na 3 różnych generacjach...
    
    
51. Potok graficzny: (autor: Gigant | data: 13/05/11 | godz.: 19:20)
    1. vertex assembling/shading
    2. tessellating
    3. gometry assembling/culling/shading
    4. rasterization/hierarchical-z culling
    5. pixelshader/texsturing
    
    I tyle w temacie...
    
    
52. @Gigant (autor: Promilus | data: 13/05/11 | godz.: 19:20)
    Nie. Core2 microarchitecture to zarówno conroe jak i wolfdale (+mobilne i serwerowe odpowiedniki). Nehalem to bloomfieldy, lynnfieldy, clarkdale, arrandale itp. Sandy Bridge microarchitecture to oczywiście SB i IB, a kolejną mikroarchitekturą będzie dopiero hasswel (i znowu kilka nazw rdzeni zależnie czy mobile, desktop czy server).
    "Ale procesy takie jak transformowanie, usuwanie niewidocznych trójkątów, vertex/pixel shading, teksturowanie nie zaliczają się do procesu rasteryzacji"
    Hueh, a czy ja gdzieś pisałem że rasterizer robi pixel shading? Albo ustawia oświetlenie sceny? Nie ;) rasteryzacja odbywa się w 2 niezbędnych krokach. Najpierw przygotowanie poly (co jak zaznaczyłeś robi primitive assembly) a później skanowanie, tudzież samplowanie pikselami. 2 nieodłączne kroki, jeden bez drugiego nie ma sensu :) W przeciwieństwie do pixel/vertex/geometry/compute shadera i innych opcjonalnych elementów w potoku :] Zatem nie, nie uważam, że 2 scan convertery z 1 primitive assembly są równoznaczne z 2 rasterizerami. Zupełnie żadnej przewagi nad tak samo taktowanym 3870 albo 4870 w kwestii rasteryzacji właśnie :]
    
    
53. Promilus (autor: Gigant | data: 13/05/11 | godz.: 19:37)
    buhahahaha PentiumM,Core to było P7. Netburst to był Netburst. Core2 to P8. Nehalem to P9 a SB to P10... IvyBridge to P10
    
    
54. Promilus (autor: Gigant | data: 13/05/11 | godz.: 19:50)
    1 primitive assemble i 2 scan convertery to jeden składacz trójkątów i 2 rasteryzatory wypełniacze pixelami... Dlaczego uważasz, że jak masz jeden geometry assembler to nie można podłączyć do tego dwóch rasteryzatorów? ;)
    
    
55. Próbujesz (autor: Gigant | data: 13/05/11 | godz.: 19:56)
    podciągnąć pod rasteryzator taki oddzielny element jak geometry assembler. To może jeszcze podciągnij tesselator i vertex assemblera i reszte jednostek SP/TMU. Będziemy wtedy mieli GPU zrobione z jednego rasteryzarora (-;
    
    
56. @Gigant (autor: Promilus | data: 13/05/11 | godz.: 21:07)
    To sprawdź roadmap intela.
    Od pentium pro do Yonaha całość leci jako P6, chociaż sam Yonah miał już sporo z architektury Core2 (bo core2 to podpicowany core z 64bitami)
    "To może jeszcze podciągnij tesselator i vertex assemblera"
    Nie strugaj głupa. To o czym piszesz odnosi się tylko do potoku DX10+ bo wcześniej nie masz geometry assemblera. Jest teraz bo do niego nie tylko przelotowo dane trafiają, ale można je wyeksportować, pozmieniać i wpuścić, coś czego nie było w DX6 czy 7, co zaczęło się pojawiać w 8 i 9 (dla vertex assemblera) i ma finał w 10 i 11 (geometry shader, domain shader). Różnica jest taka, że z geometry shadera nie trzeba korzystać. Tak samo pixel i vertex shadera. Ale jak chcesz uzyskać obraz na ekranie to potrzebujesz primitive assembly i scan conversion. Wygląda to tak, że w DX11 zwiększyli możliwości primitive assembly i zmienili to na geometry assembly przez co wydzielili poza funkcjonalną całość. Wcześniej primitive assembly nie robił nic ponad to by przygotować z wierzchołków trójkąty które wysyłał do scan convertera na którego wyjściu dopiero były piksele. Jedno bez drugiego nie ma sensu. Jedno i drugie bierze udział w rasteryzacji.
    "Dlaczego uważasz, że jak masz jeden geometry assembler to nie można podłączyć do tego dwóch rasteryzatorów"
    Można, tylko nic to nie daje co widać po cypress.
    
    
57. Promilus (autor: Gigant | data: 14/05/11 | godz.: 11:47)
    P6 kończy się na PentiumieIII. Banias to już now generacja...Yonah to to samo co Banias czyli oba układy to P7... Conroe jedzie na P8.
    
    Jak nie masz wcześniej geometry assmemblera? Od DX10 doszedł geometrt shader a nie geometry assembler bo ten to już istnieje od początku pierwszych akceleratotów 3D...
    
    Vertex, geometry assembler i rasteryzator to podstawowe elementy które są w każdym GPU nawet w tych za czasów Voodoo... Shadery jakie się pojawiły za czasów GeForca to tylko upiększacze...
    
    Sam rasteryzator bez assemblera nie zadziała tylko że w przypadku Cypressa jest tam już jeden assembler zatem można podłączyć do tego 2 rasteryzatory. I nie chrzań głupot że dodatkowy rasteryzator z 16 jednostkami ROP nic nie daje Cypresowi.
    
    
58. @Gigant (autor: Promilus | data: 14/05/11 | godz.: 14:05)
    "a nie geometry assembler"
    Geometry assembler łączy się bezpośrednio z geometry shader.
    "The OpenGL rendering pipeline works in the following order:
    Get vertices, in a specific ordered sequence.
    Vertex processing via Vertex Shader. Each vertex in the stream is processed in turn into an output vertex.
    Primitive assembly and optional Geometry Shader primitive processing. The output is a sequence of primitives.
    Primitive clipping, and culling.
    Scan conversion and primitive parameter interpolation.
    The data for each fragment is processed with a Fragment Shader. Each fragment generates a number of outputs.
    Per-sample blending, depth, and stencil operations."
    A do tego:
    In addition to the usual primitive assembly step, you can instead use a geometry shader. This is a user-defined program that processes each incoming primitive, returning zero or more output primitives.
    The input primitives for geometry shaders are the output primitives from primitive assembly. So if you send a triangle strip as a single primitive, what the geometry shader will see is a series of triangles.
    
    Zatem nie geometry assembly a primitive assembly było w voodoo :)
    " I nie chrzań głupot że dodatkowy rasteryzator z 16 jednostkami ROP nic nie daje Cypresow"
    Daj jakikolwiek dowód na to, że daje ;) Ponoć dali go tylko dlatego, że tego wymaga zgodność z DX11 ;) A tłumaczyli, że duże poly pozwala szybciej skanować, heh. No tylko po co w takim razie teselacja jak mają być duże poly? :>
    " tylko że w przypadku Cypressa jest tam już jeden assembler zatem można podłączyć do tego 2 rasteryzatory"
    A może 4? A może 6? I co to zmieni? Ano nic ;)
    
    
59. Promilus (autor: Gigant | data: 16/05/11 | godz.: 02:03)
    Geometry assembly i primitive assembly to to samo jakbyś niezauważył. Używają kilka nazw do określenia jednej i tej samej rzeczy ;)
    
    Dodatkowy rasteryzator może wypełcić 2x więcej trójkątów. Jak użyjesz teselacji to możesz wygenerować z jednego trójkąta kilka małych zatem nie potrzeba więcej geometry assemblerów aby rasteryzator miał co wypełniać ;)
    
    
60. A dokładnie to (autor: Gigant | data: 16/05/11 | godz.: 02:16)
    używanie określenia primitive assembler jest nieprecyzyjne bo w skład primitive assemblera wchodzą vertex assembler i geometry assembler. ;) Voodoo miało jedynie geometry assemblera bo funkcje vertex assembler i vertex shader były wykonywane przez CPU...
    
    
61. @Gigant (autor: Promilus | data: 16/05/11 | godz.: 08:12)
    "Dodatkowy rasteryzator może wypełcić 2x więcej trójkątów"
    Zobacz co wychodzi w ciągu jednego cyklu pracy z primitive assembly a potem dopiero potem mów, że 2x więcej scan converter to 2x więcej trójkątów przerobionych. Nie bez powodu optymalny rozmiar tri to 16px u AMD.
    "jak użyjesz teselacji to możesz wygenerować z jednego trójkąta kilka małych"
    Tak, to jest krok na dużo przed primitive assembly, zatem nadal cię ogranicza wydajność primitive assembly+scan coverter. Dlatego nv ma tego wszystkiego x4 i stąd rozsądna wydajność w teselacji, a nie z racji samej ilości teselatorów (16) bo jak widać im bardziej na starcie skomplikowana scena (i mniejszy tess factor) tym owe teselatory są gorzej używane... do tego stopnia, że taki cypress nawet może powalczyć ;)
    "Voodoo miało jedynie geometry assemblera"
    Pokaż mi GEOMETRY ASSEMBLER w dokumentacji układów NV (obecnych) albo 3dfx (właśnie owych voodoo) czy ATI. No nie ma. To sobie AMD wymyśliło do określenia jakiejś tam funkcjonalności. Ale w dokumencie
    http://developer.amd.com/...adeon2900_Hot3D(GH2007).pdf
    Masz wydzielone co robi vertex assembler z tess, co robi geometry assembler i co robi rasterizer+interpolator. G80? Input assembler, a później vertex thread issue, geometry thread issue i pixel thread issue (i to wszystko przygotowuje dane do obróbki w shader core czy tam stream multiprocessor. Osobny bloczek to setup/raster/z-cull i tam właśnie trafiają dane finalne, tam ustawia się trójkąty, tam się je skanuje :)
    http://techreport.com/...80/gt200-arch-diagram.png
    A tu fermi z geometry+vertex assemblerem (w nazewnictwie AMD)
    http://t3.gstatic.com/...P0r3JKzSi0Ua-U0ryvr6qeihV
    Co prawda sam raster engine
    http://images.anandtech.com/...IA/GF100/raster.png
    Jest podzielony na edge setup (czy tam poprzednio triangle setup), rasterizer (powód naszej kłótni) i z-cull, to widać, że tworzą jedną funkcjonalną, nierozerwalną całość z typowym szeregowym połączeniem... czyli setup->rasterize->z-cull, nic innego i właśnie taka kolejność.
    Ogółem nv ma 8x vertex fetch, 8x tess, 2x raster engine względem caymana. Fajnie. A Cayman mimo to jeszcze jako tako walczy.
    
    
62. @up (autor: Promilus | data: 16/05/11 | godz.: 08:24)
    A żeby już wątek zakończyć to mam w d*** jak kto co tam nazywa bo widać burdel jest nieziemski :P Każdy robi po swojemu, byle było zgodne z potokiem DX, heh.
    
    
63. Promilus (autor: Gigant | data: 16/05/11 | godz.: 20:29)
    Ale twierdzisz, że Cypress nie ma dwóch pełnych rasteryzatorów bo nie ma drugiego geometry assemblera.
    
    Jeżeli 2 rasteryzatory u Cypressa są podłączone do jednego geometry assemblera to po co AMD dodało drugi rasteryzator skoro jest on całkowicie niewykorzystywany? Widzisz gdzieś tu logike? ;)
    
    
64. @Gigant (autor: Promilus | data: 16/05/11 | godz.: 20:46)
    Przecież ty wyskoczyłeś z geometry assemblerem. Ja napisałem, że są 2 scan convertery, które tak czy siak dostają 1 trójkąt na cykl (a nie 2, po jednym dla każdego) więc wypadkowo wydajność jest jak jednego. Spekulować dlaczego tak a nie inaczej zrobili można by jak o zdjęciach kości Llano i dodatkowych dekoderach. Zapytaj Fruehe czy jak mu tam ;)
    
    
65. Promilus (autor: Gigant | data: 16/05/11 | godz.: 22:15)
    No ale ile trójkątów na cykl mogą przeskanowować 2 rasteryzatory u Cypressa?
    
    "Cypress Dual rasterizers up to 32piksels per clock." Czyli co to do cholery oznacza? Jak są trójkąty 64pikselowe to nawet jednego trójkąta ci niezeskanuje na cykl? ;-)