Od AIGLX do serwera X, czyli wprowadzenie do technik wyświetlania obrazu w Linuksie 27


Od pewnego czasu użytkowników elektryzują nowe efekty graficzne, które powoli pojawiają się na pulpitach naszych komputerów. Hasła takie jak AIGLX, XGL, Beryl czy Compiz coraz częściej pojawiają się w dyskusjach, jednak początkującym ogarnięcie tych technik może sprawiać odrobinę kłopotów. Ten artykuł postara się wyjaśnić „co z czym” i „dlaczego”.

Żeby jednak móc opowiadać o kompozytowych menedżerach okien, należy rozpocząć od początku, czyli od systemu X Window.

Na początku był X

W DOSie i w systemach pochodnych zasada wyświetlania obrazu na ekranach komputerów była prosta – system operacyjny miał bezpośredni dostęp do pamięci ekranu (lub karty graficznej) i zmieniając zawartość pamięci manipulował obrazem. Zresztą nie musiało się to dziać poprzez system operacyjny, bo programy uruchomione w DOSie również mogły manipulować pamięcią ekranu. Przykład? Proszę bardzo. Jeszcze kilka lat temu pisząc dowolny program w Turbo Pascalu można było dobrać się do zawartości ekranu w trybie tekstowym, która to zawartość czekała spokojnie pod adresem B000:0000. Oczywiście wraz z rozwojem techniki i nadejściem trybów ekranu lepszych niż VGA oraz trójwymiarem sprawa się ciut skomplikowała, ale podstawa była właśnie taka: system operacyjny bezpośrednio, lub poprzez sterowniki ekranu, manipulował pamięcią ekranu podłączonego lokalnie do komputera.

Systemy operacyjne mające źródła w Unixie mają zupełnie inną filozofię wyświetlania obrazu na ekranie monitora. Wymusiły to terminale, czyli – mocno upraszając sprawę – wiele końcówek z własnym monitorem i klawiaturą podłączonych do jednej jednostki centralnej. Wszystkie programy były uruchamiane na jednym serwerze, ale każdy z użytkowników siedział przy własnej klawiaturze i na własnym monitorze widział wyniki pracy.

Żeby to obsłużyć powstał X Window System. Ów system, który idealnie nadawał się do pracy z tekstem i grafiką 2D, działał w architekturze klient-serwer. Rolę serwera spełniała końcówka, czyli monitor, klawiatura lub mysz, a klientem były programy działające na jednostce centralnej. Oczywiście klawiatura i monitor mogły być podłączone nie do terminala, ale bezpośrednio do jednostki centralnej, ale nawet wtedy procesy klienta (uruchomione programy) i serwera (procesy obsługujące klawiaturę czy ekran) były od siebie oddzielone.

Działanie serwera X
Obrazek 1. Działanie serwera X

W tym momencie warto wyjaśnić jeszcze jedną kwestię, a mianowicie czym są menedżery okien. System X dostarcza tylko podstawową funkcjonalność, a mianowicie pozwala na rysowanie prostych elementów graficznych (kwadrat, linia, itp.). Żeby z takich elementów złożyć okno, w dodatku z możliwością skalowania i przesuwania, konieczny jest menedżer okien. Takimi menedżerami są np. Metacity w Gnome, albo KWin w KDE. To właśnie one obliczają położenie okna na ekranie, reagują na przesuwanie i zmianę wielkości okien, a następnie wysyłają do serwera X polecenia rysujące. Dla serwera X właśnie menedżer okien jest klientem, z którym on się komunikuje.

Wchodzimy w trzeci wymiar

Wszytko zaczęło się zmieniać, gdy pojawiła się trójwymiarowa grafika wspomagana akceleracją na karcie graficznej. Żeby oprogramowanie mogło korzystać z mocy obliczeniowej drzemiącej na GPU, sterowniki karty graficznej wystawiały w kierunku oprogramowania zestaw procedur, których uruchamianie wykonywało określoną czynność, np. utworzenie bryły w jakimś miejscu w przestrzeni, lub zapalenie światła. Najbardziej znanym zestawem procedur jest OpenGL, ale jeżeli ktoś chce, to w Microsoft Windows może skorzystać z DirectX.

Jak jednak skorzystać z procedur sterownika karty graficznej, skoro programy nie mają do niego dostępu, a sama karta jest schowana za serwerem X? Jak programy korzystające z OpenGL mają działać w Linuksie?

Powstały dwa rozwiązania tego problemu. Pierwszym rozwiązaniem jest użycie biblioteki Mesa, która udaje, że jest kartą graficzną. Mesa wystawia w kierunku programów kompletny zestaw procedur OpenGL, ale wywołanie tych procedur tłumaczy na komendy zrozumiałe przez serwer X, a następnie rysuje obraz na ekranie korzystając z serwera X. Plus takiego rozwiązania jest ogromny: nawet, gdy nie możemy skorzystać z jakiejś procedury OpenGL, bo dostawca sterowników o tym zapomniał (o tym za chwilkę), to zawsze możemy skorzystać z biblioteki Mesa. Jest jednak minus takiego rozwiązania. Całość działa wolno, bo moc obliczeniowa karty leży odłogiem, a obliczenia trójwymiarowe są przeprowadzane na procesorze.

Drugie rozwiązanie jest oparte na pewnej możliwości wbudowanej w serwer X. Funkcjonalność serwera X może być zwiększana poprzez stosowanie rozszerzeń, np. rozszerzenia pozwalającego korzystać z protokołu GLX. Protokół GLX służy do wymiany informacji o wywołaniu procedur OpenGL pomiędzy aplikacjami (a dokładniej pomiędzy bibioteką libGL) i serwerem X, który te wywołania przekazuje bezpośrednio do sterownika karty graficznej. Otwarta biblioteka zawierająca rozszerzenie w serwerze X nazywa się libglx, ale twórcy kart graficznych dostarczają własne, zamknięte biblioteki.

Indirect rendering
Obrazek 2. Indirect rendering

Ten sposób wykorzystania karty graficznej nazywa się indirect rendering, czyli „rendering pośredną, ponieważ programy nie mają bezpośredniego dostępu do karty graficznej, a wszystkie polecenia rysujące obraz przechodzą przez serwer X. Całość, chociaż o wiele szybsza niż użycie biblioteki Mesa, ciągle jest zbyt wolna dla niektórych programów.

Gry są zachłanne

Niektóre programy, zwłaszcza gry, wymieniają z kartami graficznymi ogromne ilości danych. Geometria potworów, ścian i broni, tekstury, podprogramy dla vertex i piksel shaderów… Sporo tego. Przepuszczanie tych informacji przez serwer X może spowodować, że przeciwnicy zdążą gracza przedziurawić, pociąć i jeszcze po nim pozamiatać, zanim gracz zdąży nacisnąć spust broni. Gra potrzebuje obejścia serwera X i bezpośredniego dostępu do karty graficznej.

Żeby to osiągnąć, trzeba jednak odłożyć funkcjonalność serwera X na bok. Jeżeli program ma mieć bezpośredni dostęp do karty, musi działać na tym samym sprzęcie, na którym działa karta. Nie może to działać przez sieć, więc dla maszyn, które muszą skorzystać z OpenGL przez sieć pozostaje albo GLX, albo Mesa.

Producenci kart graficznych dostarczają zamknięte biblioteki libGL, które użyte w aplikacjach bezpośrednio komunikują się ze sterownikami karty graficznej. Protokół komunikacji został zestandaryzowany i nazywa się DRI (Direct Rendering Infrastructure), a sposób wykorzystania karty graficznej to direct rendering, czyli rendering bezpośredni.

Direct rendering
Obrazek 3. Direct rendering

Tak więc przy wykorzystaniu direct rendering aplikacje okienkowe działają tak, jak do tej pory, czyli poprzez serwer X, ale programy korzystające z OpenGL komunikują się z kartą graficzną bezpośrednio. Rozwiązanie nie jest proste, ale póki co nic lepszego nie wymyślono.

Przyspieszanie okienek

Rozwój techniki spowodował, że dzisiejsze komputery mają spore zasoby i moc obliczeniową, która nie zawsze jest wykorzystywana. Korzystamy z niej podczas skomplikowanych obliczeń, albo podczas grania w nowe gry 3D, ale na co dzień – podczas przeglądania stron internetowych, czy pisania maili – ta moc leży odłogiem. I tutaj dochodzimy do tematu, który od pewnego czasu elektryzuje użytkowników. Ktoś wpadł na pomysł, by część mocy obliczeniowej, która jest w danym momencie niewykorzystana, użyć w innym celu, na przykład do uatrakcyjnienia pulpitu. W chwili obecnej istnieją dwa konkurencyjne rozwiązania, które pozwalają osiągnąć zamierzony efekt: utworzony przez tandem Novell i Suse XGL (X-to-OpenGL), oraz produkt Red Hat nazwany AIGLX (Accelerated Indirect GLX).

Za XGL kryje się bardzo prosty pomysł, choć zdecydowanie skomplikowany w implementacji. XGL to zwykły serwer X, który wciska się pomiędzy już istniejący serwer X oraz aplikacje. Programy, zamiast wysyłać polecenia serwerowi X, wysyłają je do XGL, który tłumaczy cały obraz na 3D, a następnie za pomocą poleceń OpenGL i serwera X leżącego „pod spodem” wyświetla go na ekranie. Serwer X pod spodem jest potrzebny na początku pracy, by XGL mógł poprzez niego nawiązać kontakt z kartą grafiki. Potem XGL komunikuje się z kartą grafiki bezpośrednio, używany jest tutaj direct rendering.

Schemat XGL
Obrazek 4. Schemat XGL

XGL, jak wszystko, ma swoje plusy i minusy. Plusem jest to, że XGL do działania wymaga jedynie serwera X ze sprzętową akceleracją grafiki. Co więcej, nawet jeżeli jakaś procedura OpenGL nie jest zaimplementowana w sterownikach grafiki producenta karty, to XGL wykonuje ją programowo, za pomocą biblioteki Mesa. Mam tu na myśli procedurę GLX_EXT_texture_from_bitmap, która zamienia okienka zapisane w pamięci komputera na tekstury nakładane potem na obiekty 3D, a która niestety nie jest zaimplementowana w zamkniętych sterownikach ATI.

Jest jednak i druga strona medalu. Ponieważ XGL jest pomostem łączącym aplikacje z kartą, wszystkie odwołania do serwera X, łącznie z przyśpieszanymi operacjami 3D, muszą przejść przez XGL. Aplikacje nie mają dostępu do karty graficznej i właśnie dlatego mogą one korzystać z akceleracji 3D tylko poprzez libGL XGLa, czyli indirect rendering. XGL, jako pomost, sprawia również sporo kłopotów – problemy z układem klawiatury i niedziałające tunery TV to tylko drobne przykłady.

W przeciwieństwie do XGLa, który na nowo odkrywa koło, AIGLX nie jest czymś dodatkowym, a jedynie modyfikacją istniejącego serwera X. Aplikacje mają dostęp do karty graficznej poprzez direct rendering tak, jak do tej pory. Jedyna nowość polega na tym, że sam serwer X również może za pomocą akceleracji sprzętowej wyświetlać obraz 3D.

Schemat AIGLX
Obrazek 5. Schemat AIGLX

W porównaniu z XGL ten sposób wyświetlania ma sporo zalet i tylko jedną wadę. Jest o wiele szybszy i bardziej wydajny, ale do działania wymaga wspomnianej już metody GLX_EXT_texture_from_bitmap… Ta procedura jest ujęta w sterownikach NVIDII, Intela i otwartych sterownikach dla kart Ati, ale niestety ktoś zapomniał o niej przy tworzeniu fglrx, czyli zamkniętych sterowników Ati. I tu leży pies pogrzebany, bo otwarte sterowniki dla Ati nie obsługują najnowszych modeli tej firmy. Posiadacze kart nowszych niż Radeon x850 są zmuszeni skorzystać ze sterowników zamkniętych (fglrx), a co za tym idzie, są skazani na XGL lub na nieużywanie XGL/AIGLX w ogóle. Zresztą otwarte sterowniki nie do końca wspierają akcelerację 3D w kartach od Radeona 9500 do x850 i używanie akcelerowanych okienek może nie być tak wygodne, jak powinno…

Jej! Jaka ładna kostka!

Wyświetlanie okienek w AIGLX lub XGL nie jest takie proste i wymaga dość ścisłej współpracy pomiędzy serwerem X i menedżerem okien. Dlatego zwykłe menedżery zostały zastąpione przez menedżery kompozytowe, np. Compiz lub Beryl. Potrafią one wysyłać do serwera X polecenia rysujące okienka, a następnie modyfikować wygląd okien poprzez dodanie cienia, nałożenie przezroczystości lub ich wykrzywienie. To one są odpowiedzialne za wszelkie efekty widoczne na monitorze. XGL i AIGLX są tylko podstawą, która umożliwia akcelerację tych efektów.

Jeszcze do niedawna Compiz i Beryl były dwoma konkurencyjnymi projektami o wspólnych korzeniach. Compiz opierał się na jakości kodu i stabilności, podczas gdy w Berylu ważniejsze były efekty i bajery. Compiz był kiepski w konfiguracji, bo jedynym sposobem zmiany ustawień była ich ręczna edycja w gconfie. Beryl przygotował specjalny wygodny menadżer do zmiany ustawień… Jednak niedawno oba projekty się połączyły i teraz będą wspólnie tworzyć jeden menedżer, w którym z Compiza przyjęto stabilne jądro, a z Beryla pluginy i program do konfiguracji. Czas pokaże, co z tego wyjdzie.

Powrót do przyszłości

Uatrakcyjnianie pulpitów to nieodwołalna przyszłość i, sądząc po obecnych tendencjach, już niedługo nasze pulpity będą jeszcze ładniejsze i jeszcze bardziej efektowne. Wystarczy powiedzieć, że XGL i AIGLX to nie jedyne projekty dążące do wprowadzenia okienek w trzeci wymiar. Microsoft wystartował ze swoim Aero w Windowsie Vista, powstał napisany w Javie Looking Glass, a obecna implementacja XGL (nazywana XGLX) ma być zastąpiona na pozbawioną wad XEGL… I choć nie wszystkich bawią żelujące okna, albo obracająca się kostka, to warto skorzystać z dobrodziejstw nowych technologii. Chociażby dlatego, żeby odciążyć procesor i przenieść obliczenia dotyczące okien na kartę graficzną.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

27 komentarzy do “Od AIGLX do serwera X, czyli wprowadzenie do technik wyświetlania obrazu w Linuksie

  • BLADE

    patrzylem na mozliwosci aero i compiza… i aero wydalo mi sie kompletnie „zaporzyczone” z compiza.. i mnei funkcjonalne… więc zastanawiam sie czym ten MS sie tak chwali…. artykul bardzo ciekawy i pomocny 🙂

  • uranage

    Dzięki za artykuł. Długo dochodziłem do tego, że moja karta graficzna X 1600 i stery do niej oprzec muszę na zamkniętych sterownikach i obowiązkowo na XGL-u. Ten artykuł pomógł mi to wszystko poukłądac i zrozumiec. Jeszcze raz wielkie dzięki !!!

  • Rad

    Dobry artykuł. AIGLX działa bardzo dobrze z otwartymi sterownikami ATI (tymi z jądra), niestety beryl przycina się na starszych kartach, więc ja przykładowo używałem go bardzo krótko.

  • kwalo

    Jeśli chodzi o karty wspiearające AIGLX, to wystarczy wpisać:
    glxinfo | grep texture_from_pixmap
    Jeśli coś się nam wypisze na ekran, to znaczy, że AIGLX nam pójdzie.

    @Smiecho, gratuluję świetnego artykułu!

  • szafir

    super artykul
    prosto i na temat:)

    @xxxx beryl ‚u mnie dziala’ na xgl na radeonie x1300 z fglrx

    @kwalo sprecyzuj co ma sie pokazac:) bo u mnie np ‚cos’ sie pokazuje ale to czysty error i aiglxa nie odpale:)

  • JanNiezbedny

    Serwer X musi zostac kompletnie przepisany, wraz z implementacja wszystkich rozszerzen akceleracji. Ciagle „rozbudowywanie” go na ulomny, linuksowy sposob nic nie da i nie zwiekszy
    stabilnosci oraz predkosci dzialania.
    Na szczescie z tego co wiem programisci serwera X wprowadzili juz w jego najnowszej wersji modularnosc [alter], ktora pozwoli zachowac stabilnosc najistotniejszego jadra X przy jednoczesnym zapewnieniu mozliwosci stosowania dopasowanych do mozliwosci kart i preferencji uzytkownika rozszerzen.

  • Tomasz Chiliński

    Świetny artykuł! Brawo!
    Aplikacje nie OpenGL-owe też mogą korzystać z DRI, bo DRI nie jest uzależnione w żaden sposób od GLX. DRI to mechanizm, który nic nie wie na temat tego czy używamy 3D czy 2D.
    W niektórych diagramach zostało to przeoczone. Jeśli się mylę to proszę o konstruktywną polemikę. Pozdrawiam.

  • crackers

    Taka mala poprawka. B000:0000 – to adres pamieci karty graficznej, ale monochromatycznej. Dla kart kolorowych ten adres to B800:0000

  • Smiecho Autor wpisu

    [quote comment=”4429″]czy na XGL pójdzie beryl, czy trzeba kozystac z aiglx (chodzi o karty ati)[/quote]
    Beryl i Compiz mogą pracować zarówno na XGL, jak i na AIGLX. Nie ma tutaj żadnych zależności, więc spokojnie.
    [quote comment=”4498″]U mnie jedak Intelowskie są chyba wybrakowane (karta zintegrowana) – zresztą w FAQ compiza jest to opisane…[/quote]
    Nie ukrywam, że w testach miałem do czynienia tylko z kartami Ati i nVidii. Jednak z tego, co wiem, Intel wypuścił otwarte sterowniki, które radzą sobie z AIGLX: http://www.ossgeeks.co.uk/?p=70
    [quote comment=”4519″]Mała poprawka dotycząca otwartych sterowników ATI. r300 obsługuje takze karty z serii r400, x700 nalezy do tej rodziny a x300[/quote]
    Dzięki. Uściśliłem już artykuł.
    [quote comment=”4542″]Na szczescie z tego co wiem programisci serwera X wprowadzili juz w jego najnowszej wersji modularnosc[/quote]
    Masz jakies linki?
    [quote comment=”4556″]Aplikacje nie OpenGL-owe też mogą korzystać z DRI, bo DRI nie jest uzależnione w żaden sposób od GLX. DRI to mechanizm, który nic nie wie na temat tego czy używamy 3D czy 2D.[/quote]
    Zgadza się. Prawdą jest jednak, że mechamizm DRI jest najczęściej wykorzystywany przy okazji akceleracji 3D. Ze względu na przejrzystość artykułu i czytelność dla mniej wtajemniczonych poszedłem na małe uproszczenia.
    [quote comment=”4567″]Taka mala poprawka. B000:0000 – to adres pamieci karty graficznej, ale monochromatycznej. Dla kart kolorowych ten adres to B800:0000[/quote]
    A czy ja rozróżniam tryby monochromatyczne i kolorowe? 🙂 To był tylko przykład, zresztą, jak sam potwierdziłeś, był prawdziwy.

  • _johny

    Witaj,

    Nie myślałes czasem o opublikowaniu twojej pracy na wikipedii, np. pod haslem, „Serwery X w linuksie”, albo coś podobnego? Mogłoby to być świetne żródlo informacji.

    Pozdrawiam i gratuluje wiedzy

  • tjp

    [quote comment=”4429″]czy na XGL pójdzie beryl, czy trzeba kozystac z aiglx (chodzi o karty ati)[/quote]Inaczej: na zamkniętych sterownikach ATI Beryl pójdzie tylko na XGL, bo w sterach brak jakiejś funkcji. Na open-sourcowych sterownikach pójdzie i AIGLX i XGL

  • Kraftman

    Artykuł świetny! Też popieram pomysł zamieszczenia go na Wikipedii.

    Co do JanNiezbedny „Ciagle „rozbudowywanie” go na ulomny, linuksowy sposob nic nie da i nie zwiekszy
    stabilnosci oraz predkosci dzialania.” ułomny to jest Twój umysł, a nie sposób rozbudowywania serwera X w Linuksie.

  • Gothic

    [quote comment=”4533″]Jeśli chodzi o karty wspiearające AIGLX, to wystarczy wpisać:
    glxinfo | grep texture_from_pixmap
    Jeśli coś się nam wypisze na ekran, to znaczy, że AIGLX nam pójdzie.
    [/quote]
    oj nie do konca, bo np. na zamknietych sterownikach ATI (fglrx) rowniez znajduje sie GLX_EXT_texture_from_pixmap z tym, ze nie w sekcji rozszerzen opengl, a serwera X

    server glx extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method,
    GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe,
    GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer

    w efekcie grep wypisze nam znalezione rozszerzenie, a jak wiemy fglrx GLX_EXT_texture_from_pixmap nie obsluguje…

    Mnie natomiast trapi inny problem, na otwartych sterownikach do ATI (Radeon 9550 R350), z wlaczonym dierect rendering, nie jestem w stanie uruchomic Beryla przez AIGLX, ze wzgledu na brak rozszerzenia ARB_texture_non_power_of_two, podczas uruchamiania dostaje taki blad:
    Checking for non power of two texture support : failed
    Wersje oprogramowania ktore uzywam to:
    mesa-6.5.2
    x11-drm-20070314
    xorg-server-1.2.0

    Przeszukalem google i problem ten powtarza sie na roznych kartach S3, Intel, Ati, ale niestety nigdzie nie znalazlem rozwiazania.

  • Radek

    Artykuł fajny, lecz ma sporo błędów, głównie wynikających z zastosowanych uproszczeń i skrutów myślowych:

    „Jak jednak skorzystać z procedur sterownika karty graficznej, skoro programy nie mają do niego dostępu, a sama karta jest schowana za serwerem X? Jak programy korzystające z OpenGL mają działać w Linuksie?”

    – wyraźnie odwołujesz się do renderowania grafiki 3D za pomocą akceleracji karty graficznej

    i nagle:

    ” Powstały dwa rozwiązania tego problemu. Pierwszym rozwiązaniem jest użycie biblioteki Mesa, która udaje, że jest kartą graficzną.”

    piszesz o renderowaniu grafiki 3D za pomocą bibliotek Mesa pracujących w trybie softwareowym. To nie jest rozwiązanie problemu akceleracji sprzętowej OpenGL, to po prostu całkowicie programowa implementacja OpenGL.

    „Żeby z takich elementów złożyć okno, w dodatku z możliwością skalowania i przesuwania, konieczny jest menedżer okien. Takimi menedżerami są np. Metacity w Gnome, albo KWin w KDE. To właśnie one obliczają położenie okna na ekranie, reagują na przesuwanie i zmianę wielkości okien, a następnie wysyłają do serwera X polecenia rysujące. Dla serwera X właśnie menedżer okien jest klientem, z którym on się komunikuje.”

    – bzdura, managery okien faktycznie są odpowiedzialne za umiejscowienie oraz rozmiary okien aplikacji na ekranie Xserwera ale nic poza tym. Nie wysyłają do Xserwera poleceń rysowania – w domyśle artykułu – aplikacji X klienta, nie przejmują tych odwołań jak jest to sugerowane w tekście i nie podszywają się pod klientów Xserwera które obsługują. To że managery okien są jak każde aplikacje Xserwera klientami tego serwera to jest oczywiste ale jedyne co takie managery okien rysują to wyłącznie dekoracje okien aplikacji które NIE należą do aplikacji. Jedyne co managery okien wykonują na rzecz aplikacji X11 to przesyłanie do Xserwera informacji gdzie na ekranie ma się znależć dane okno czy jaki powinien być jego rozmiar – czyli realizują umiejscowianie i zmianę rozmiarów okien.

    „utworzony przez tandem Novell i Suse XGL”

    – już od jakiegoś czasu Suse jest wyłącznie marką firmy Novell a nie oddzielją firmą więc o jakim tandemie tu rozmawiamy?

    pozdr

    Radek

  • slackman

    Fajny artykuł o podstawach, niektórzy młodzi ubuntowcy mają szansę dowiedzieć się dlaczego to czarne okienko nazywa się emulatorem terminala 😉

  • Chyrek

    Mam problem z kartą ATI Radeon x700 256 mb monitor moj pokazuje na ekranie gdy sie wlacza jakies paski i kratki i o co biega czy karta moja do wymiany czy jak bo sam juz nie wiem ?? please pomoc
    Asus typ karty