Likes Likes:  0
  1. #1
    Avatar von Skysnake
    Mitglied seit
    20.04.2010
    Beiträge
    9.800

    Grund für abfallende Skalierung bei mehr als 2 GPUs

    Ich habe in verschiedenen Tests zu 3 und 4 Wege SLI Systemen gesehen, das bei 2 Karten die Skalierung recht gut ist, danach diese aber verhältnismäßig stark abfällt, obwohl durch NF200 Chip genug Lanes für alle bereitgestellt werden

    Ich habe hierfür zwei Theorien entwickelt.

    1. Der NF200 ist ein Switch, welcher bei voller Bestückung nicht die Bandbreite zur Verfügung stellen kann um schnell/flexibel genug den Karten die von der CPU zur Verfügung gestellten Lanes bereit zu stellen.

    Diese also z.B. fest aufgeteilt sind, oder aber nur relativ "selten" umverteilt werden was die AUfteilung zwischen den GPUs anbelangt.

    2. Der Koordinationsaufwand der ja überproportional (sollte exponentiell sein) ansteigt bei mehr Karten schlägt hier bereits zu Buche.

    Mein Hauptanliegen ist hier, ob wenn es sich um Punkt 1 handelt, sich dies damit korregieren lässt, das PCI-E 3.0 kommt und damit insgesamt mehr Bandbreite pro Karte vorhanden ist, womit dann auch der Flaschenhals geweitet wird und die GPUs weniger ausbremst.

    Oder aber, ob ein Board wie das EVGA SR-2 mit seinen zwei Xeons und seinen zwei NF200 bereits jetzt dieses Problem löst.

    Ich wäre hier wirklich sehr stark an einer Aussage dazu interessiert.

    PS: Löst eventuell der NF300 hier auch das Problem?

    • Bitte einloggen, um diese Anzeige auszublenden.
  2. #2
    Avatar von ruyven_macaran
    Mitglied seit
    22.08.2007
    Beiträge
    30.981

    AW: Grund für abfallende Skalierung bei mehr als 2 GPUs

    Die Frage sollten Tests mit Dual-SLI an NF200, Dual-SLI an X58 und Triple/Quad-SLI mit X58 bzw. X58+NF200 beantworten:
    Afaik unterscheided sich der Skalierungsverlust von Dual auf Triple nicht sonderlich, egal ob man von 16/16 auf 16/8/8 (X58) oder auf 16/(16+16) (X58, NF200) wechselt. Er ist in jedem Fall größer, als der Skalierungsunterschied zwischen Dual-SLI an einem NF200 im Vergleich zu Dual-SLI an einem X58. Das heißt: Ob 16 Lanes oder 16 "fake"Lanes (oder 8 Lanes) pro Karte hat sowohl bei Dual- wie auch Triple-SLI weniger Einfluss auf die Skalierung, als Dual- im Vergleich zu Triple-SLI, die Anbindung sollte also das kleinere Problem sein (wenn auch kein unerhebliches).
    (wozu ich keinen Test kenne, ist der Einfluss der CPU: Liegt bei Triple-GPU schlichtweg eine Limitierung vor? Leider sind die kleinen Karten ja nicht Triple-SLI-tauglich, so dass man innerhalb einer Generation leider keinen Vergleich machen kann)

    P.S.: Der NF200 ist übrigens keine einfache Weiche, sondern ein vollwertiger Switch. D.h. er weißt nicht wechselseitig die Lanes zu, sondern er leitet die Daten weiter, ggf. sogar an beide (broadcasting). Über beide GPU-Leitungen fließen somit mehr Daten, als durch einmal x16 passen würde. (Nachteil dieses Verfahrens ist natürlich die Latenz)
    PCG&H-Statistik: 25235 Post, 380 Threads, 17091 Antworten (0,677/Post, 44,876/Thread) since 18:04, 26.09.2001

    [Langzeittagebuch]Vom Flugzeug zum 0db-Wakü-PC; 31.8.11: Stufe 4.0 Fanless

  3. #3

    Mitglied seit
    31.12.2008
    Liest
    PCGH.de & Heft
    Ort
    Großraum Stuttgart
    Beiträge
    4.367

    AW: Grund für abfallende Skalierung bei mehr als 2 GPUs

    Das liegt einfach (zum Teil auch) an der Rasterisierungsgrafik...
    Keine Engine skaliert 100%ig neutral, vor allem nicht mit beliebig vielen Grafikchips.
    Hach, mit Raytracing wäre alles sooooo viel einfacher

  4. #4
    Avatar von Skysnake
    Mitglied seit
    20.04.2010
    Beiträge
    9.800

    AW: Grund für abfallende Skalierung bei mehr als 2 GPUs

    Ich würd das ja gern selbst bis zum Erbrechen durchbenchen, aber son SR-2 + zwei Xeons ist halt fern ab meiner Preisklasse und ne Alternative wäre mir nicht bekannt. Serverboards gibts eventuell noch welche, aber die sind ja noch viel weiter weg von gut und böse...

  5. #5
    Avatar von ruyven_macaran
    Mitglied seit
    22.08.2007
    Beiträge
    30.981

    AW: Grund für abfallende Skalierung bei mehr als 2 GPUs

    @Skysnake: Einen Dual-Xeon brauchst du für solche Fragestellungen nicht. Wenn es rein ums Prinzip geht, reicht ein X58-Board und ein zweites X58-Board mit NF200 sowie ein Stapel 8800GTX (auch nicht gaaanz billig, aber für einige machbar). PCI-E Limitierung kann man durch untertakten ggf. simulieren.
    Man weiß dann halt nur nicht, ob die Aussagen auf heutige Generationen übertragbar sind.

    @caps:
    Es geht ja nicht um eine 100% Skalierung, es geht um eine weitere Verschlechterung der Skalierung bei noch mehr Chips. D.h. Dual-SLI bringt z.B. 70% der addierten Leistung zweier Karten, aber Triple-SLI bringt nur 50% der addierten Leistung dreier Karten. Das ist nur über die Grafikengine nicht zu erklären. Erst recht nicht in AFR, wo so oder so jede Grafikarte für sich rechnet und drei Karten somit dreimal so oft ein Bild ausspucken sollten, wie eine einzelne. Raytraycing ändert da afaik auch nichts dran, denn der eigentliche Rasterisierungsprozess ist hochgradig parallelisiert. (= 512 Berechnungen parallel beim GF110)
    PCG&H-Statistik: 25235 Post, 380 Threads, 17091 Antworten (0,677/Post, 44,876/Thread) since 18:04, 26.09.2001

    [Langzeittagebuch]Vom Flugzeug zum 0db-Wakü-PC; 31.8.11: Stufe 4.0 Fanless

  6. #6
    Avatar von Lars Weinand
    Mitglied seit
    07.12.2010
    Ort
    Muc
    Beiträge
    303

    AW: Grund für abfallende Skalierung bei mehr als 2 GPUs

    Ab einem gewissen Punkt gibt es einfach zuviel Overhead. Zu viel Verwaltungsarbeit, die Frames müssen vorberechnet werden etc. Es hängt dann auch sehr stark von der Game-Engine ab. Wir unterstützen offiziell 3-way SLI mit aktuellen High-End GPUs. 4-way geht, ist aber eher ein Feature für Extrem-Overclocker (LN2 etc)

  7. #7
    Avatar von Skysnake
    Mitglied seit
    20.04.2010
    Beiträge
    9.800

    AW: Grund für abfallende Skalierung bei mehr als 2 GPUs

    Zitat Zitat von ruyven_macaran Beitrag anzeigen
    @Skysnake: Einen Dual-Xeon brauchst du für solche Fragestellungen nicht. Wenn es rein ums Prinzip geht, reicht ein X58-Board und ein zweites X58-Board mit NF200 sowie ein Stapel 8800GTX (auch nicht gaaanz billig, aber für einige machbar). PCI-E Limitierung kann man durch untertakten ggf. simulieren.
    Man weiß dann halt nur nicht, ob die Aussagen auf heutige Generationen übertragbar sind.
    Meiner Meinung nach eben nicht, da du eben die PCI-E Lines von zwei CPUs hast und du theoretisch somit nicht ein 4-Wege SLI System hast, sondern praktisch zwei 2-Wege SLI Systeme in einem Case.

    Dies wird bei Spielen sicher schwer zu realisieren sein, aber bei Software die Multisockel fähig ist, oder selbst geschriebenen Programmen mit MPI wirste sehr sehr sicher den Flaschenhals vom PCI-E stark reduzieren.

    Zitat Zitat von Lars Weinand Beitrag anzeigen
    Ab einem gewissen Punkt gibt es einfach zuviel Overhead. Zu viel Verwaltungsarbeit, die Frames müssen vorberechnet werden etc. Es hängt dann auch sehr stark von der Game-Engine ab. Wir unterstützen offiziell 3-way SLI mit aktuellen High-End GPUs. 4-way geht, ist aber eher ein Feature für Extrem-Overclocker (LN2 etc)
    Oder für Leute die damit rechnen wollen wie ich Und da wärs halt schon verdammt interessant wie sich der zweite NF200 auswirkt, und vorallem wie das mit Dualsockel läuft.

    In den ganzen Supercomputern werden ja eigentlich por Knoten nur Zwei GPUs verbaut, eben wegen der dummen PCI-E Bandbreitenlimitierung -.-

    Hab selbst dazu schon einige Tests auf meinem System gemacht mit relativ einfachen Sachen zur Analyse von Bilddaten aus einem Laser Mikroskop, wo ich aber atm leider nicht so weiterarbeiten kann wie ichs hätte wegem Studium

  8. #8
    Avatar von ruyven_macaran
    Mitglied seit
    22.08.2007
    Beiträge
    30.981

    AW: Grund für abfallende Skalierung bei mehr als 2 GPUs

    Zitat Zitat von Skysnake Beitrag anzeigen
    Meiner Meinung nach eben nicht, da du eben die PCI-E Lines von zwei CPUs hast und du theoretisch somit nicht ein 4-Wege SLI System hast, sondern praktisch zwei 2-Wege SLI Systeme in einem Case.
    Bislang hast du noch gar keine PCI-E Lanes von CPUs in einem 2-CPU System

    Dies wird bei Spielen sicher schwer zu realisieren sein, aber bei Software die Multisockel fähig ist, oder selbst geschriebenen Programmen mit MPI wirste sehr sehr sicher den Flaschenhals vom PCI-E stark reduzieren.
    Da sprechen wir dann aber nicht von "SLI", denn für Cuda und unabhängig voneinander laufende Berechnungen müssen die Grafikkarten eben nicht gekoppelt sein. Wenn man dann soviele unterschiedliche Daten zwischen GPUs und Restsystem hin- und herschaufeln muss (und eben nicht alle Mitglieder eines Triple-SLI-Gespanns mit den gleichen Texturen versorgt), dann sollte auch ein NF200 seinen Nutzen verlieren und man hat defacto die Leistung von @x8 Karten. Ein durch die PCI-E Bandbreite limitierter Code sollte dann durch PCI-E 3 beschleunigt werden.

    Oder für Leute die damit rechnen wollen wie ich Und da wärs halt schon verdammt interessant wie sich der zweite NF200 auswirkt, und vorallem wie das mit Dualsockel läuft.
    Bislang hat die Zahl der Sockel keinen Einfluss. Der NF200 wird an einen x16-Slot des (einzelnen) Chipsatzes angeflanscht - ob an dessem anderen Ende 1 oder 2 CPUs hängen, ist egal. (Xeon-EX-Boards mit mehreren QPI-PCI-E Bridges und NF200 wären mir nicht bekannt, in dem Segment beschränkt man sich ohnehin oft auf PCI-E x8. Wer Quad-CPU mit Octa-GPU in einem System kombinieren will, sollte sich sowieso mal Gedanken über Cluster-tauglichen Code machen )
    Bei Synchronisation über zwei CPU nebst interner Verbindung könnte es bei Sandybridge-E zu etwas höheren Latenzen kommen, aber im Prinzip war das auch schon bei Quad-FX so (de facto zwei NF570 an je einem Opteron, Verbindung nur über den HT-Link zwischen beiden Opterons). Ob das da kein Nachteil war, oder ob ihn nur niemand bemerkt hat, weil der Rest der Plattform so misraten war, weiß ich nicht

    In den ganzen Supercomputern werden ja eigentlich por Knoten nur Zwei GPUs verbaut, eben wegen der dummen PCI-E Bandbreitenlimitierung -.-
    HP hat laut aktueller c't Fat-Nodes mit Dual-Xeon und Triple-Tesla in der Pipeline. Dagegen hat Chinas neuester Leistungschampion zwei CPUs auf eine GPU.
    Ich würde mal sagen, das da extrem viel am Code hängt: Tolle Rohleistung nützt einem nichts, wenn Code, der fast nur auf der GPU läuft erst erscheint, wenn der Rechner veraltet ist. Dann lieber mehr CPUs, mit denen weiß wenigstens jeder, wie er mit umzugehen hat.
    PCG&H-Statistik: 25235 Post, 380 Threads, 17091 Antworten (0,677/Post, 44,876/Thread) since 18:04, 26.09.2001

    [Langzeittagebuch]Vom Flugzeug zum 0db-Wakü-PC; 31.8.11: Stufe 4.0 Fanless

  9. #9
    Avatar von Skysnake
    Mitglied seit
    20.04.2010
    Beiträge
    9.800

    AW: Grund für abfallende Skalierung bei mehr als 2 GPUs

    Sorry für den Fullqoute aber da muss ich einfach auf ein paar Dinge eingehen:

    Zitat Zitat von ruyven_macaran Beitrag anzeigen
    Bislang hast du noch gar keine PCI-E Lanes von CPUs in einem 2-CPU System
    Naja, das würd aber absolut keinen Sinn machen. Ich hab ja im Dualsockel Fall nicht nur die Anbindung an den Chiosatz von einem Satz PCI-E Lanes, sondern deren zwei. Sprich die Anzahl der Lanes, die die CPUs zur Verfügung stellen sollten doppelt so groß sein, darüber hinaus hast du ja den QPI Link zwischen den CPUs womit du dann auch auf den Speicher des anderen zugreifen kannst.

    [QUOTE=ruyven_macaran;2477165]
    Da sprechen wir dann aber nicht von "SLI", denn für Cuda und unabhängig voneinander laufende Berechnungen müssen die Grafikkarten eben nicht gekoppelt sein. Wenn man dann soviele unterschiedliche Daten zwischen GPUs und Restsystem hin- und herschaufeln muss (und eben nicht alle Mitglieder eines Triple-SLI-Gespanns mit den gleichen Texturen versorgt), dann sollte auch ein NF200 seinen Nutzen verlieren und man hat defacto die Leistung von @x8 Karten. Ein durch die PCI-E Bandbreite limitierter Code sollte dann durch PCI-E 3 beschleunigt werden.
    [Quote]
    Das ist halt die Frage, ob bei einem Quad System eben nicht doch der NF200 als switch den Flaschenhals dahingehend darstellt, das er einfach die Latenzen nach oben treibet. Du hast ja durch nen Switch eigentlich immer zumindest eine sehr kleine Latenzsteigerung, und damit dann die Bandbreit einknickt zwischen den GPUs. Aner ja das ist eher für Anwendungen wichtig und nicht für games.

    Zitat Zitat von ruyven_macaran Beitrag anzeigen
    Bislang hat die Zahl der Sockel keinen Einfluss. Der NF200 wird an einen x16-Slot des (einzelnen) Chipsatzes angeflanscht - ob an dessem anderen Ende 1 oder 2 CPUs hängen, ist egal. (Xeon-EX-Boards mit mehreren QPI-PCI-E Bridges und NF200 wären mir nicht bekannt, in dem Segment beschränkt man sich ohnehin oft auf PCI-E x8. Wer Quad-CPU mit Octa-GPU in einem System kombinieren will, sollte sich sowieso mal Gedanken über Cluster-tauglichen Code machen )
    Bei Synchronisation über zwei CPU nebst interner Verbindung könnte es bei Sandybridge-E zu etwas höheren Latenzen kommen, aber im Prinzip war das auch schon bei Quad-FX so (de facto zwei NF570 an je einem Opteron, Verbindung nur über den HT-Link zwischen beiden Opterons). Ob das da kein Nachteil war, oder ob ihn nur niemand bemerkt hat, weil der Rest der Plattform so misraten war, weiß ich nicht
    Die Chipsätze für die Dualsockelboards bieten aber von sich aus meines wissens nahc mehr PCI-E Lanes als die der Singelsockel Boards. Daher sollten die zusätzlichen Lanes/Anbindungen durch die zweite CPU schon nutzbar sein.

    Zitat Zitat von ruyven_macaran Beitrag anzeigen
    HP hat laut aktueller c't Fat-Nodes mit Dual-Xeon und Triple-Tesla in der Pipeline. Dagegen hat Chinas neuester Leistungschampion zwei CPUs auf eine GPU.
    Ich würde mal sagen, das da extrem viel am Code hängt: Tolle Rohleistung nützt einem nichts, wenn Code, der fast nur auf der GPU läuft erst erscheint, wenn der Rechner veraltet ist. Dann lieber mehr CPUs, mit denen weiß wenigstens jeder, wie er mit umzugehen hat.
    Naja, ich habs in eigenen Programmen so erlebt, und auch von anderen Leuten durchweg so mitbekommen die wissenschaftliche Programme für GPUs entickeln oder überlegt haben zu entwickeln, dass die PCI-E Anbindung der größte Flaschenhals in sehr vielen Dingen darstellt und man sowohl mit den Latenzen als auch einfach mit dem Datendurchsatz sehr zu kämpfen hat. Dies war auch meine Erfahrung. Sobald du Datenaustausch zwischen CPU und GPU hast oder aber du recht viel Daten hin und her schaufeln musst, wirds schnell ekelig, weil einfach PCI-E verdammt langsam ist im Vergleich zum Ram etc.

    Das gleiche Problem gibts mit dem Global Mem auf den GraKas selbst. Tolle Bandbreite, aber wenn du ~80 Taktzyklen mit Arbeit füllen musst, bis der Speicherzugriff durch ist, dann haste oft halt verloren. Ist bei meiner Anwendung z.B. so.

    Auf der CPU dauerts 59 ms auf der GPU 100 ms Daten hin 100 MS Ergebnis zurück und dann 3,5 ms reines Rechnen auf der GPU -.-

    Klar die 200ms Datenaustausch kann man verstecken, aber trotzdem ich nutz grad mal 10% der GPU weil der global Mem beschränkt. Sind halt einfac Berechnungen bisher. Wird später mehr wenn ich dann die Daten anfang auszuwerten und das dann auch sinnvoll in den Cache passt, aber bis ich soweit bin isses halt scheise..

    • Bitte einloggen, um diese Anzeige auszublenden.
  10. #10
    Avatar von ruyven_macaran
    Mitglied seit
    22.08.2007
    Beiträge
    30.981

    AW: Grund für abfallende Skalierung bei mehr als 2 GPUs

    Zitat Zitat von Skysnake Beitrag anzeigen
    Naja, das würd aber absolut keinen Sinn machen. Ich hab ja im Dualsockel Fall nicht nur die Anbindung an den Chiosatz von einem Satz PCI-E Lanes, sondern deren zwei. Sprich die Anzahl der Lanes, die die CPUs zur Verfügung stellen sollten doppelt so groß sein,

    ...


    Die Chipsätze für die Dualsockelboards bieten aber von sich aus meines wissens nahc mehr PCI-E Lanes als die der Singelsockel Boards. Daher sollten die zusätzlichen Lanes/Anbindungen durch die zweite CPU schon nutzbar sein.
    Nö. Der X58 und der 5520 Chipsatz unterscheiden sich ausschließlich in der Zahl der QPI-Links und damit CPUs. Auf Dual-Sockel-Systemen wird ein 5520 mit zwei QPIs direkt an beide CPUs angebunden. Seinerseits stellt er die üblichen 36 Lanes (+DMI) zur Verfügung, genauso wie der X58.
    Erst bei Quad-Konfigurationen für Xeon-XE kommen afaik zwei Chips zum Einsatz. (deren Funktionsumfang bei Intel gerade nicht auffindbar ist)

    Erst mit Sandy-Bridge-E ändert sich das ganze.

    Das ist halt die Frage, ob bei einem Quad System eben nicht doch der NF200 als switch den Flaschenhals dahingehend darstellt, das er einfach die Latenzen nach oben treibet. Du hast ja durch nen Switch eigentlich immer zumindest eine sehr kleine Latenzsteigerung, und damit dann die Bandbreit einknickt zwischen den GPUs. Aner ja das ist eher für Anwendungen wichtig und nicht für games.

    Ich sagte gerade: Bei unabhängigen Berechnungen auf den Karten bringt dir ein NF200 gar nichts. Also einfach weglassen, dann hat man definitiv keine Probleme mit Latenzen. (die übrigens nicht die Bandbreite verringern, sondern "nur" deren Nutzung erschweren. Bei einem CPU-initierten Code sollte es aber meiner Laienmeinung nach auch möglich sein, die benötigten Daten konstant zu streamen, so dass Latenzen keine Rolle mehr spielen)


    Naja, ich habs in eigenen Programmen so erlebt, und auch von anderen Leuten durchweg so mitbekommen die wissenschaftliche Programme für GPUs entickeln oder überlegt haben zu entwickeln, dass die PCI-E Anbindung der größte Flaschenhals in sehr vielen Dingen darstellt und man sowohl mit den Latenzen als auch einfach mit dem Datendurchsatz sehr zu kämpfen hat. Dies war auch meine Erfahrung. Sobald du Datenaustausch zwischen CPU und GPU hast oder aber du recht viel Daten hin und her schaufeln musst, wirds schnell ekelig, weil einfach PCI-E verdammt langsam ist im Vergleich zum Ram etc.
    Dann solltest du aber eben einen Code haben, der zu erheblichen Teilen nicht auf der GPU, sondern in der CPU abläuft (denn sonst wäre der Flaschenhals jenseits von CPU/GPU/RAM/PCI-E in der Massenspeicheranbindung). Das meine ich dann mit mangelhaft optimierten Code: Man hat eben kein Programm, dass auf der GPU läuft, sondern man ein CPU-Programm, dass eine GPU als Hilfsprozessor nutzen möchte. Die daraus resultierenden Probleme kann aber nur durch eine Integration der GPU samt Speicherinterface in die CPU lösen. Oder anders gesagt: Was gesucht ist, ist ein Chip mit extrem viel Leistung, universellen Fähigkeiten und gigantischer Speicheranbindung.
    Derartige Chips sind immer die perfekte Lösung für alle bestehenden Probleme, bringen aber das Problem "WIE?" mit sich

    Das gleiche Problem gibts mit dem Global Mem auf den GraKas selbst. Tolle Bandbreite, aber wenn du ~80 Taktzyklen mit Arbeit füllen musst, bis der Speicherzugriff durch ist, dann haste oft halt verloren. Ist bei meiner Anwendung z.B. so.

    Auf der CPU dauerts 59 ms auf der GPU 100 ms Daten hin 100 MS Ergebnis zurück und dann 3,5 ms reines Rechnen auf der GPU -.-
    Tjo. Ein Interface mit extrem niedriger Latenz ist aufwendig zu realisieren - der Vorteil von GPUs ist aber eben, dass sie ziemlich viel ziemlich einfach umsetzen und deswegen sehr viele Recheneinheiten in bestehenden Budgets umsetzen. Man kann nicht beides haben. Wer die die optimale Einbindung der Recheneinheiten einer CPU will, muss eine CPU nehmen. In Sachen Effizienz klingt dein Problem nach Larrabee oder Pineview-Clustern, nicht nach Nvidia.
    PCG&H-Statistik: 25235 Post, 380 Threads, 17091 Antworten (0,677/Post, 44,876/Thread) since 18:04, 26.09.2001

    [Langzeittagebuch]Vom Flugzeug zum 0db-Wakü-PC; 31.8.11: Stufe 4.0 Fanless

Ähnliche Themen

  1. Radeon HD 6970: Cayman XT rund 15-20 Prozent schneller als GTX 480 bei mehr als 255 Watt TDP?
    Von PCGH-Redaktion im Forum News-Kommentare zu Grafikkarten
    Antworten: 101
    Letzter Beitrag: 31.10.2010, 11:10
  2. Bringt MHz bei cpu mehr als hohe MHz bei ram?
    Von Jägermaister im Forum Overclocking: Prozessoren
    Antworten: 11
    Letzter Beitrag: 25.02.2010, 14:25
  3. Antworten: 4
    Letzter Beitrag: 15.12.2008, 21:57
  4. PCGH.de: Sind die Lötstellen von Nvidia GPUs der Grund für die erhöhte Ausfallrate?
    Von PCGH-Redaktion im Forum News-Kommentare zu Grafikkarten
    Antworten: 27
    Letzter Beitrag: 02.10.2008, 09:48
  5. Skalierung der Auflösung bei 260/280 GTX 16:10 und 4:3
    Von DaxTrose im Forum Grafikkarten
    Antworten: 9
    Letzter Beitrag: 22.08.2008, 13:58

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •