heh, tańsza nie działa droższa działa...skoro nie działa to po kiego grzyba kupować?
Nie działa - to dziekujemy bardzo

Droższa Hydra od tańszej różni się tylko i wyłącznie liczba linii PCIE...

Wypuszczanie czegoś takiego to skandal, zarówno ze strony Lucid, jak i producentów płyt głównych. Minęło wiele czasu od premiery, tymczasem ten produkt wciąż znajduje się w fazie alpha. Rozumiem że dawne pojęcie bety w ostatnich latach wyewoluowało do pierwszej wersji finalnej (błędów niech szukają klienci, w końcu teraz wszystko ma wymienny firmware), jednak Hydra w takim stanie to kpina.

Hydra jest spóźniona na rynku co najmniej o dwa lata. To nic innego jak CPU przechwytujące rozkazy graficzne i podające je dalej. Im silniejsze grafiki tym będzie gorzej. Nie ma własnej pamięci, wszytko musi przewalać przez pcie, a to interfejs szeregowy, co generuje w tym przypadku opóźnienia. Nie wyśle połowy rozkazu jedną linią, drugiej połowy nastepną, a dane kolejnymi, to musi iść jedną 'paczką', czyli minimum kilkanaście taktów. Czipy graficzne nie są projektowane z myślą o szybkim odczycie pamięci graficznej przez CPU, czyli wysyłanie jej na PCI-E, tylko po kątem jak najszybszych operacji na lokalnej pamięci karty. Gdyby tak było to już dawno w konfiguracjach SLI, Crosfire X można by było cały Ram na karcie sumować.
Hydrę gdyby nie ograniczenia licencyjne mógłby z powodzeniem zastąpić zwykły CPU i działo by to szybciej i pewniej, ponieważ sterowniki do kart nie są pisane z myślą o Hydrze.

Z tego co kojarzę hydra działa na innej zasadzie. To JEJ sterownik funkcjonuje jako akcelerator 3D (stąd kolejne poprawki wnoszące m.in. obsługę DX11), gdy układ otrzyma szereg instrukcji modelujących jakąś scenę to dzieli zadania pomiędzy poszczególne GPU - innymi słowy modyfikuje to co dostał i odsyła do sterowników prawdziwych GPU - te zaś przetwarzają dane i odsyłają do kart. A co do pci-e - pamiętasz ile to szeregowych linii jest w kartach pracując równolegle? Nie sądzę by CPU było w stanie zastąpić ten wyspecjalizowany układ. Z wielu powodów o których nie zamierzam teraz pisać.

Sterownik - to program, tu musi udawać (emulowac) kartę graficzną. Dx11 nic tu nie zmieniło, dopisali 'udawanie' dx11. A udaje dlatego aby hydraCPU mogło to podzielić i porozsyłać dalej.

'A co do pci-e - pamiętasz ile to szeregowych linii jest w kartach pracując równolegle'
A czy posądzasz hydrę o taką wielowątkowość? Odbiór danych na 16 liniach, przemłócenie tego i równoległą wysyłkę oraz odbiór danych na 32 liniach? To był by wtedy bardziej zaawansowany układ niż obecne CPU.

Linie Pci-e to jak Amazonka co wiele wody niesie ale wolno płynie. Czasami jednak lepsze są strumienie co mniej wody niosą, za to o wiele szybciej płyną. W najbardziej optymistycznym przypadku są tylko 2x większe opóźnienia i to tylko w przypadku kiedy hydra nie robi nic, a tylko stara się być 'przezroczysta'.

Wyglada to na oszustwo. Jak to mozliwe, aby dolozenie kolejnej silnej karty nic nie dawalo. Tu logika prostestuje.

Logika i komputery? Nie zauważyłeś jeszcze, że te dwa terminy niemal się wykluczają?

To jest dla entuzjastów... Nie jesteś entuzjastą nowinek nie kupuj.

Od tego są właśnie układy specjalizowane, np. Xena, który jest wielokrotnie mniej wydajny (obliczeniowo) niż CPU obecnej i poprzedniej generacji, ale ma zalety (bardzo szybko obsługuje wszystkie zdarzenia na pinach) których owe procesory nie posiadają. Zrozum, że CPU tak naprawdę do wielu zadań po prostu się NIE nadaje. Wiele algorytmów opłaca się implementować choćby w FPGA niż pisać soft specjalnie do CPU. A obsługa 'udawanego' GPU DX11 była konieczna bo jak inaczej mogłoby to działać gdyby układ nie rozpoznawał instrukcji DX11? Nadal twierdzę, że żaden obecny x86 nie byłby odpowiednim konkurentem dla Hydry.

Raczej frajerow, skoro wydajac 800 zl na kolejna karte przyrost wydanosci jest rowny 0%. O cenie plyty z tym wynalazkiem nie wspomne.

Jak to nie . Przecież masz SLI i CrosfireX. Tu się CPU zajmuje rozdzielaniem zadań.



Dopisanie Dx11 to jeden z dowodów na to że to jest CPU, rozdzielanie rozkazów to kolejny dowód. Sceny 3D są za bardzo złożone aby sprawdzał się jeden sztywny algorytm zaszyty na sztywno w tranzystorach sobie z tym poradził. To nie strumieniowe mpegi gdzie paczka danych jest całością (zwłaszcza te pierwsze mpegi).
A trzecim dowodem jest sama dokumentacja układu LT22102

'Embedded RISC

o
Tensilica Diamond Architecture 32-bit RISC
o
300 Mhz clock
o
64 Kbytes on-chip instruction memory
o
32 KBytes on-chip data memory
o
On chip DMA engine to enable PCIe packet generation and reception
o
Real time control over the switch operation
'

On jest już obecnie za mało wydajny aby poradził sobie z dzisiejszymi kartami z górnej półki.

po co to komu to ja nie wiem...

Niczym się nie zajmuje... 99% gier w których to działa posługuje się AFR - CPU nic zasadniczo nie musi dzielić, po prostu jedna karta renderuje klatki parzyste, druga nieparzyste i odsyła je do mastera gdzie są naprzemiennie wysyłane na wyświetlacz. Do tego nie trzeba żadnego dzielenia zadań, wystarczają mechanizmy wbudowane w kartę. Hydra to inna sprawa, pokazałeś specyfikację więc widzisz sam wyraźnie że tu nie liczy się wydajność obliczeniowa, tylko szybkość reakcji na dane zdarzenia na magistralach. Tyle od strony sprzęu - układ tylko 'demultipleksuje' polecenia wysyłane poprzez sterownik urządzenia, ewentualnie odsyła mu stan urządzeń docelowych. Tylko tyle i aż tyle, bez tego układziku byłoby to może nie NIEMOŻLIWE, ale z całą pewnością ZNACZNIE trudniejsze do wykonania. Zresztą włącz tryb PIO w dysku i zacznij coś kopiować Im szybszy dysk i większy transfer (oraz większa liczba transferów, żądań dostępu itp) to tym obciążenie proca by poszło w górę... a tak... niezbyt wydajny układzik mający dokładnie jedno konkretne zadanie się całością zajmuje.

Taaa, a karty przepychają wszytkie dane przez PCI-e i mostkiem nie są połączone.
Tu nie chodzi o to że to działa kiedy nic nie robi, wtedy zachowuje się jak mostek (przynajmniej wg schematu blokowego), ale nie wyrabia się wtedy kiedy sam 'udaje' kartę graficzną. Wtedy następuje tłumaczenie rozkazów i podział pracy. Ten obiekt na karcie A, ten na karcie B. Jeśli wyświetlaniem obrazu zajmuje się karta A, to musi przepchać całość wyników końcowych z pamięci karty B do karty A. Oooo nowa instrukcja, do której nie ma algorytmu w pamięci podręcznej, to wio przez PCI-e zapytać się co z tym robić CPU i programu sterownika. Ten układ nie ma żadnej własnej pamięci po za pamięcią podręczną. Czyli albo musi poszukiwać takich danych w pamięci RAM, albo ordynarnie upycha je w pamięci karty graficznej. Dostęp do tego co mu brakuje jest zawsze wolny, bo przez PCI-e. Wszystkie jaskółki śpiewają, że Lucid wpadł na pomysł programowalnego mostka PCI-e, tyle że nie było co z nim zrobić, i jak go sprzedać. Więc spece od marketingu wpadli na taki pomysł i nazwali go Hydra. Obiecamy gruszki na wierzbie i entuzjaści go łykną. A to że to nie będzie miało prawa działać wydajnie przemilczą.
PCI-e jest szeregowa, i w przypadku grafiki pewnie przelatuje przez nią więcej danych niż instrukcji, ale np ma się pojawić nowy obiekt na scenie, to leci tam instukcja (co to) i rersta danych obiektu, np współrzędne wierzchołków. Teraz przechwytuje to hydra, decyduje na która kartę to wysłać, dokonuje tłumaczenia instrukcji pod właściwe GPU i wysyła... ale, ale pracuje tylko z zegarem 3x szybszym niż PCI-e, a tu musi gdzieś tą instrukcję odłożyć, sprawdzić na co wysłać i w jakiej postaci, pobrać właściwy kod rozkazu i wysłać... nie coś tu nie gra dalej, a gdzie dane? Ot zanim zdecyduje co i jak i gdzie musi cały pociąg z danymi odebrać, zatrzymać na bocznicy (cache) zmienić lokomotywę ( istrukcję) i dopiero puścić to dalej. Jak widać nie zawsze się to udaje, bo nie 'hula'... o nie, nawet nie zawsze poprawnie jest to wyświetlane. Gorzej czasami muszą być te dane gubione bo se coś mryga na ekranie. No ale tym powinien się zająć 'sterownik' aby na raz więcej nie wysłać niz CPU w hydrze może obsłużyć, tyle ze nie zawsze się to da zrobić. Gdyby RISC w hydrze miał parę MB własnej pamięci ram nie było by tyle problemów.

Teraz jeszcze jedno, nVidia udostępniła tryb SLI dla kart GF6200, gdzie karty wymieniały ze sobą dane przez PCI-e, Jednak już w przypadku GF6600 mówiła że PCI-e będzie za mało wydajne i konieczny jest mostek SLI. Owszem, to było na PCI-e 1, a teraz mamy PCI-e z dwa razy większą przepustowością, ale hmmm które z obecnych kart można równać wydajnościowo z GF6600?

To nie będzie, bo nie może, ani nigdy nie mogło sprawnie działać

Bosz.. co ty bierzesz ? Zmień dilera

sluka - mostek sli z tego co pamiętam to 0.9GB/s, biorąc pod uwagę że teraz mamy pci-e 2.0 to niewiele.

Mnie się wydaje że 1 GB/s, ale mogę się mylić. Najważniejsze jest jednak to, że jest to bezpośrednie i ekskluzywne połączenie między kartami. Komunikacja między kartami przez PCIE odbywa się za pośrednictwem mostka północnego, a pasmo musi być też dzielone z danymi z i do CPU. Dlatego ten mostek o niewielkiej przepustowości daje tak dużo.

te logo lucida kojarzy mi sie z polamana sfastyka :/