CrossFire bez kart Master?

1. dobrze ze są już sterowniki (autor: Jacek_2004 | data: 8/11/05 | godz.: 17:35)
   jeszcze tylko zostało im stworzyć te karty :)
   
   
2. te polaczenia od poczatku byly bez sensu (autor: RusH | data: 8/11/05 | godz.: 20:18)
   po kiego wala laczyc karty kablem i sprzetowo laczyc dwa obrazy (co linie/bloki) kiedy mozna co jeden FPS przeslac obraz z jednej karty do drugiej po PCI-e ktore ma KOLOSALNA przepustowosc .. a jedna klatka to raptem 1-7MB, marte 500MB/s przy normalnym graniu (70fps) w rozdzielczosci HD
   
   ja sie dziwie ze jeszcze nikt nie napisal uniwersalnego sterownika wirtualnej karty graficznej rozbijajacego obciazenie na fizyczne karty w kompie - idealny projekt OpenSource
   
   
3. RusH (autor: Movi | data: 9/11/05 | godz.: 02:28)
   Świetnie, mają kolosalną przepustowość, ale wtedy i CPU musi się zająć komunikacj,a, bo wszystkie łącza szyny kończą się na CPU (szyna NIE jest dzielona, jest ich wiele, wszystkie od siebie niezależne), dodatkowo występują problemy z synchronizacją kart. Kiedy masz łącze bezpośrednie karty nie wykorzystują pośrednika. Najlepszym wyjściem był 3d1 Abita - wda chipy na jednej karcie. A pozatym TAK STRASZNIE ci przeszkadzała mała krzemowa belka, wielkości 1/2 gumy do żucia między dwoma kartami (w wersji nV - ATi jak zwykle spieprzyło sprawę) ?
   
   
4. ... (autor: Pet | data: 9/11/05 | godz.: 05:21)
   Rozwiązanie ATI może wydawać się gorsze z powodu sztywnego połączenie z tyłu komputera ale ma też zaletę. Fagment ramki generowany w każdej z kart nie musi być przesyłany do 2giej karty lub do komputera i znowu do karty aby go wyświetlić. Źródło sygnału jest po prostu przełączane W czasie rysowania ramki. Więc jest to metoda szybsza od mostka nvidii.
   
   Natomiast wersja SLI/Crossfire bez dodatkowych połączeń oznacza to iż właśnie obie karty renderują w pamięci komputera poprzez PCI-EX. Po wyrenderowaniu "obraz" wraca spowrotem do karty do której podłączony jest monitor. Jest to, tak jak wspomniał przedmówca, niestety strasznie czasochłonne. W tym czasie praktycznie karty graf i procesor komputera są zamrożone dla użytkownika.
   
   
5. czego to ludzie nie wymyślą, (autor: Vetch | data: 9/11/05 | godz.: 07:59)
   żeby przez chwilę pograć na blasze w dwie nudne gierki rocznie. No, ale ktoś musi napełniać kieszenie prezesów nV i Ati :-)
   
   
6. Pet Movi (autor: RusH | data: 9/11/05 | godz.: 13:12)
   bez przesady,
   zreszta pomylilem sie oczywiscie, karta przeciez potrzebuje przeslac polowe klatki
   3.5MB dla rozdzielczosci HD na klatke - to jest NIC dla karty PCIE
   a przy rozdzialkach w jakich sie gra obecnie to 1.5MB/frame
   
   Dodatkowo przy takim podejsciu do sprawy mozliwe by bylo napisanie uniwersalnego sterownika SLI pozwalajacego laczyc wiecej kart roznych producentow (z pewnymi ograniczeniami - ATI ladniej generuje i byloby to widac :P polowa ekranu bylaby wyraznie ladniejsza hehe)
   Przy pomocy takiego drivera mozna by np polaczyc moc GF6600, GF6600GT oraz GF6800GT wykonujac swego rodzaju load balancing pomiedzy przydzielanym kartom obciazeniami (pierwsza ~25% linii, druga ~30%, trzecia ~45 regulowane dynamicznie co pare fps)
   
   sklejenie obrazu w calosc to mizerny ulamek tego, co musi zrobic CPU co klatke
   Pomysl jest imo bardzo dobny, szkoda ze nie interesuje sie programowaniem, a tym bardziej OGL :), powinienem o tym napisac do hmmm kolesia piszacego stery OpenGL dla Voodoo 5500(nadal je ulepsza)
   
   
7. RusH (autor: Pet | data: 9/11/05 | godz.: 19:57)
   Pamiętaj, że takich ramek trzeba przesłać np. 60 w czasie sekundy. Weźmy nawet to 1.5MB do przesłania. 1.5*60 = 90MB dodatkowego przesyłania danych w czasie sekundy. To jest sporo. Zauważ, że np. przy kopiowaniu głupiego pliku z HDD na inny HDD przy transferze nawet 40MB/s (a dzisiaj przecież spokojnie i dużo więcej wyciągają HDD) obciążenie procka windows pokazuje niewiele ale jednak w tym czasie system pracuje jak żółw.
   W czasie renderingu do pamięci komputera procesor ani żadne inne urządzenie nie mogą korzystać z pamięci komputera i muszą czekać. Naprawdę jest to olbrzymia strata.
   
   BTW: Nowy driver model od windows vista podobno jest tak ciekawy, że da się sterowniki napisane pod niego łatwo przenieść na inne platformy systemowe. Programiści Wine już sobie ostrzą na to zęby. Możliwe będzie używanie sterowików do urządzeń visty zwyczajnie w Wine np. pod linuxem :) Nawet kart graficznych. Więc w pewnym sensie to co piszesz będzie mogło być łatwo zrealizowane.
   
   
8. Pet (autor: RusH | data: 9/11/05 | godz.: 23:42)
   z calym szacunkiem, ale programowales kiedys jakies I/O?
   
   PCIE/AGP to nie kontroler IDE, 90MB/s to NIC, ZERO, 1 procent pasma PCI-E
   
   AGP x8 to 2.1GB/s , z czego 1GB w strone CPU
   PCIe x16 to 8 GB/s , dodatkowo przy PCI-E mozesz zadeklarowac kanaly(max 4 dla intela obecnie) pomiedzy kartami, kazdy kanal to 250MB/s full duplec, BEZ posrednictwa CPU.
   
   No i jaki rendering do pamieci komputera? do pamieci transferowane bylyby tylko gotowe klatki.
   
   
9. RusH (autor: Pet | data: 10/11/05 | godz.: 05:27)
   Takie transfery nie obciążałyby teoretycznie komputera jeśliby była to transmisja z urządzenia PCI-E do innego urządzenia PCI-E. Tutaj jest to transfer do pamięci komputera. CPU w tym czasie nie może z niej korzystać. Znaczy czeka i marnuje się. Nie może odpowiedzieć urządzeniom, wysłać nowych poleceń do karty graficznej itp. Wszystko stoi aż urządzenie przestanie korzystać z ramu komputera.
   Renderowanie w pamięci komputera - oczywiście miałem na myśli że klatka znajdzie się w komputerze. Mało istotne czy najpierw w całości znajdzie się w karcie graficznej a potem w ramie komputera czy też po kawałku. W sumie zajęcie zasobów będzie podobne. Dużo mniejsze transfery po PCI-EX już powodują straszne spowolnienia. Mam doświadczenie z programowaniem grafiki i wysłaniem wierzchołków do karty w każdej ramce. Jest to strasznie obciążające pomimo iż wydawałoby się, że to nic to jednak magistrali nie starcza. Po to wymyślono shadery. Jeszcze gdyby miało dojść te 90MB/s w czasie generowania grafiki dzisiejszych gier byłoby to bardzo odczuwalne.
   Zresztą widać to po kartach z hyper memory czy turbocache. Karty z włączonymi tymi opcjami generują właśnie finalną ramkę w pamięci komputera. Niczym więcej się to nie różni od starej metody - wsystko w ramie karty. Można zobaczyć jaki to ma zły wpływ na wydajność.
   
   
10. cd... (autor: Pet | data: 10/11/05 | godz.: 05:51)
    BTW: PCIe x16 to 8 GB/s ale licząc w obie strony. W jedną jest tylko 4GB/s
    Skąd wziąłeś informację o upstream w AGP ? Zawsze myślałem, że AGP wyrobi tylko 266MB/s do CPU.
    
    
11. cd...:) (autor: Pet | data: 10/11/05 | godz.: 06:19)
    Jeszcze wytłumaczę się z tego przykładu z HDD i IO. Chodziło mi o to, że przy włączonym DMA HDD przesyła dane do ramu komputera bez udziału CPU. A raczej prawidłowo powinno się powiedzieć: HDD ma dostęp do ramu komputera bezpośrednio i inne urządzenia mu w tym nie przeszkadzają.
    Już ta operacja przy transferze znacznie wolniejszym od tych 90MB/s powoduje ram komputera niedostępny dla CPU i tym samym występują strasznie duże opóźnienia dla całego systemu. Cóż więc mi z tego, że magistrale PCI-E są nieobciążone skoro mi tu procesor komputera działa np. 4 razy wolniej w czasie całego transferu ?
    
    
12. Pet (autor: RusH | data: 10/11/05 | godz.: 16:05)
    nie mam pojecia, teraz znalazlem 133MB/sec wiec sie poddaje jesli chodzi o agp
    
    "Już ta operacja przy transferze znacznie wolniejszym od tych 90MB/s powoduje ram komputera niedostępny dla CPU"
    
    ??? :)
    1 CPU ma cos takiego jak cache
    2 jak juz pisalem mozna linkowac karty PCIE ze soba bezposrednio, GPU wykonuje mikrokod wiec nie ma problemu z wgraniem tam programu do lazcenia obrazow - tak pewnie robia to te dual sli asusy
    
    
13. RusH (autor: Pet | data: 10/11/05 | godz.: 18:52)
    1.
    Cache na długo nie starczy. To nie jest coś co działa aż w takiej skali jak sobie pewnie wyobrażasz. Zwłaszcza w dzisiejszych czasach kiedy głupia instrukcja if((int)a>(int)b) zajmuje 1500 cykli procesora na typowym kompilatorze to na jakieś wielkie optymalizacje w cache nie ma co liczyć.
    2. Z mikrokodem w GPU bym uważał bo i tak nie wiemy na prawdę jakie są możliwośći kart w tym względzie. Raczej bardzo prościutkie. Jeśli bufory w kartach graficznych są rzędu 2-4KB to samo miejsce na mikrokod może mieć np. 512 bajtów. Ale owszem. Cały czas zakładałem w tej dyskusji, że proces łączenia tych obrazków robi karta graficzna i CPU nie będzie tu potrzebny.
    Ale powtórzę znowu. Jeśli jakieś urządzenie ma DMA do pamięci to żadne inne w tym czasie nie może z tej pamięci korzystać. Musi czekać aż urządzenie pamięć zwolni. Właśnie dlatego mniej czasu cpu jest dostępne podczas gdy jest transmisja danych HDD albo w czasie teksturowania z pamięci komputera.