|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
Von Anonymer Feigling am Friday 20. August 2004, 11:20 MEW (#1)
|
|
|
|
|
ich habe eine Matrox Karte, die bestens durch FOSS Treiber unterstütz wird. Ich bin doch nicht wahnsinnig und lasse ein Binary Modul laufen!!!!! Die einfachste Lösung ist der Boykott von ATI, nicht noch lange betteln, das dieser geschlossene schrott ein bisschen weniger mies ist
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Klar, einfach den Quellcode offenlegen, um eine kleine Minderheit zu befriedigen, dann wird alles besser. Sicher kein Problem das Firmen-Knowhow der Welt zu präsentieren. Ist ja schliesslich nicht das Kapital der Firma.
Ein Boykott bringt sicher einiges, das macht sich dann in der Statistik sicher mit einem 0.1%-igen Umsatzeinbruch bemerkbar.
</sarcasm>
Hier läuft übrigens der ATI Treiber mit einer Radeon 9600XT problemlos und performant.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich dachte, die Hardware wäre das Kapital - die Treiber gibts ja eh gratis.
|
|
|
|
|
|
|
|
|
|
|
|
|
Aber nicht das Wissen dahinter.
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 20. August 2004, 14:43 MEW (#12)
|
|
|
|
|
nach Softmodems jetzt auch Softgrafikkarten ?
im Prinzip sollten OS_Treiber nur die
Ansprechfunktionen der GK offenlegen,
natürlich könnte man nach solch einer Offenlegung
nicht mehr soo gut bei Benchmarks schummeln
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sicher kein Problem das Firmen-Knowhow der Welt zu präsentieren
Das Knowhow steckt im Chip drin. Offenlegen muesste man nur die Interfaces. Wer das nicht glaubt muss nur mal Intel anschauen. Nur weil die den x86 Maschinencode offengelegt haben (ohne das gaebe es schlicht gar kein Linux!) haben die ihre Geheimnisse was in den x86 Chips drin ist nicht verloren.
Und ein Markt fuer ATI-Cloner nur um Treiber schreiben einzusparen gibt es keinen. Und Apps sind eh nur DirectX kompatible, nicht direkt chipabhaengig, also auch kein Marktverlust wie bei x86 Clonern.
Und zu glauben, dass Konkurrenten (ausser Nvidia ist da eh niemand) aus dem Interface der jetzt verkauften Karten etwas herauslesen koennen, dass ihnen hilft in der naechsten Generation viel besser zu werden, ist wohl massive Ueberschaetzung des eigenen Vorsprungs.
Die beiden Firmen lesen ja schliesslich die gleichen Forschungsberichte, und haben die gleichen Infor von MS was in DirectX n+1 noetig sein wird.
Ein Boykott bringt sicher einiges, das macht sich dann in der Statistik sicher mit einem 0.1%-igen Umsatzeinbruch bemerkbar
Leider. Und eine Petition wird vermutlich genauso wertlos sein. Linux, und erst recht die die alles voll offen haben wollen, ist schlicht nicht genug wichtiger Markt um vor Panik idiotisch gewordene Firmenbosse unter Druck zu setzen.
--
hardware runs the world, software controls the hardware,
code generates the software, have you coded today
|
|
|
|
|
|
|
|
|
|
|
|
|
Hoi Neil,
Das Knowhow steckt im Chip drin. Offenlegen muesste man nur die Interfaces.
Ja, der grösste Teil des Knowhows steckt sicher im Chip drin. Obwohl auch dort soviel ich weiss die Integrationsdichte der treibende Faktor ist, d.h. immer mehr Pipelines, immer mehr Speicher, immer schnellere Busse. Aber ich glaube nicht, dass der Treiber einfach einen Adapter darstellt, und selber nichts grosses macht. Wie erklärst du dir dann die Performancesprünge, bei neuen Versionen von Treibern? Ausserdem kann ich mir gut vorstellen, dass z.B. bei OpenGL preprocessing im Treiber gemacht wird, um die Daten für die Karte optimaler aufzubereiten.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Obwohl auch dort soviel ich weiss die Integrationsdichte der treibende Faktor
Das ist bei bei allen Chips so, ATI vs Nvidia oder Intel vs AMD. Das wirkliche Knowhow steckt darin, wie man aus mehr Transistoren optimal viel rausholt, also entscheiden auf welche Funktionen man die Transistoren verbraucht, und was man weiterhin in Software macht.
Und das muss man sich von 100en Uni Forscher ihren Berichten sowie internen analyses von Games (und DirectX) zusammensuchen. Und zwar jetzt, nicht erst aus der Konkurrenz ihrem Interface rauslesen (und dann sich fragen was wohl die Gruende waren), wenn die schon am verkaufen sind. Sonst hat man eh bereits verloren.
Aber ich glaube nicht, dass der Treiber einfach einen Adapter darstellt, und selber nichts grosses macht.
Der Treiber macht einerseits all das was man in Software gelassen hat. Wobei man die Implementation von dem ja nicht mal offenlegen muss, das muessen die OS Leute nacherfinden.
Anderseits tut er dann die Hardware vorbereiten und ansteuern, dann wenn die zum Zug kommt.
--
hardware runs the world, software controls the hardware,
code generates the software, have you coded today
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Jein, Chips entwickeln ist ein bischen mehr als nur ein paar 0815 Techniken aus dem Lehrbuch anwenden. Du musst schon ziemlich viel Grips in einen Chip reinstecken um mehr Leistung rauszuholen. Einfach nur den Chip groesser machen (ie laengere Pipelines, parallelisieren etc) ist nur bis zu einem gewissen Grad moeglich (Die groesse (ie Chipflaeche), Stromverbrauch, Waermeabfuhr), mal abgesehen davon, dass du da dann schnell an die Leistungsgrenzen deines Designs stoesst (nicht alles laesst sich beliebig parallelisieren oder durch mehr Speicher beschleunigen).
Fuer mehr Infos besuche doch bitte die Vorlesungen VLSI von Prof. Kaeslin et al.
Und um deine Frage zu beantworten, warum neue Treiber mehr Leistung bringen: Die Treiber machen ein Mapping der OpenGL/DirectX Funktionen auf die Funktionen die die Karte beherscht. Je nachdem wie gut das Mapping ist, ist auch die Leistung die man rausholt. Auch kannst du durch geschicktes spielen mit den Registern der CPU (ie, die GP Register und Config Register, wie zB MTRR regs) mehr Leistung rausholen. Oder ein memcpy auf die Graphikkarte anpassen und du holst 1-10% mehr Datentransferrate raus (so aehnlich geschehen bei MPlayer, als der memcpy von mem2mem auf mem2pci und mem2agp optimiert wurde). Wenn sie durch einen neuen Treiber mehr Leistung rausholen heisst das schlicht weg, dass der alte noch ned fertig entwickelt und der User nur ein Betatester war.
Und ja, auch ich bin der Meinung, dass das Knowhow von ATI/NVidia/Matrox nicht in den Treibern steckt, sondern in der HW. Sieht man uebrigends sehr schoen an den kaputten Treibern von nvidia, dass die nicht viel mit Software am Hut haben.
|
|
|
|
|
|
|
|
|
|
|
|
|
Jein, Chips entwickeln ist ein bischen mehr als nur ein paar 0815 Techniken aus dem Lehrbuch anwenden.
Das habe ich auch nicht behauptet geschrieben. Das sieht man an der unglaublichen Komplexität heutiger Prozessoren (z.B. alles was mit Pipelining zu tun hat, aber das weisst du sicher alles besser). Ich sage nur, dass es unrealistisch ist, das eine Firma in einem hoch-kompetitiven Umfeld wie NVidia oder ATI, ihr Knowhow preisgibt (auch wenn's nur ein Bruchteil ist). Erklär das mal den Investoren oder den Leuten im Management.
Danke übrigens für die Referenz auf die VLSI Vorlesung. Aber zwei Vorlesungen (Digitaltechnik und Digitaltechnik und Rechnerstrukturen Kernfach) haben gereicht, um mich zu überzeugen, dass meine Interessen nicht in dem Bereich sind.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 20. August 2004, 12:05 MEW (#3)
|
|
|
|
|
Nimmt mich ja wunder welches Notebook eine Matrox Karte hat... Für eine Workstation ist auch Suspend nicht relevant.
|
|
|
|
|
|
|
|
|
|
|
|
|
Auch wenn ich selber eine NVIDIA Karte besitze.
Und ehrlich gesagt ist es mir ziemlich egal welche Lizenz ein Treiber hat solange er macht was er soll und das mit der gleichen Qualitaet wie unter Windows.
Wie waere es denn mit einer Petition an alle Linux-Kernel-Developer, dass die Treiberschnittstellen unter LGPL gestellt werden? Damit wuerden vermutlich wesentlich mehr Firmen Treiber fuer Linux bereitstellen.
So, und jetzt wartet mal eben, bis ich meine feuerfeste Asbestunterwaesche angezogen habe...
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 20. August 2004, 17:40 MEW (#19)
|
|
|
|
|
Ich glaub, sowas wie eine (stabile) "Treiberschnittstelle" gibt es unter Linux nicht...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>Ist seit jeher einer meiner Hauptkritikpunkte an
>Linux.
Einfache Loesung: verwende Solaris.
Du brauchst abgesehen davon nicht fuer jede Kernelversion neue Treiber und sie kommen praktisch immer mit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Solaris hat eine stabile Treiber-Schnittstelle zum Kernel (solange man das dokumentierte [sprich das offizielle] API benutzt).
Das man bei Nicht-Standard-Hardware (=Hardware, wo der Treiber nicht im Standard-Kernel drin ist) selber patchen muss, ist soweit klar. Hat aber weniger mit der Treiberschnittstelle zu tun, als
mit dem organisieren des Treibers.
|
|
|
|
|
|
|
|
|
|
|
|
|
Solaris hat eine stabile Treiber-Schnittstelle zum Kernel (solange man das dokumentierte [sprich das offizielle] API benutzt).
Lass es mich anders ausdrücken: Nur weil ich einen bestimmten Punkt an Linux kritisiere, heisst das noch lange nicht, das ich sofort auf irgend ein anderes System wechsle, wo dieser Punkt besser gelöst ist.
Das man bei Nicht-Standard-Hardware (=Hardware, wo der Treiber nicht im Standard-Kernel drin ist)
Yo. Wir sind ja heute gar nicht arrogant, was? Jede Hardware, deren Treiber nicht im Kernel ist, wird bequemerweise zum nicht-Standard erklärt.
Tatsache ist: Mit Freiwilligenarbeit kriegt man nie alle Treiber zusammen. Einerseits, weil es dazu viel zu viel verschiedene Hardware gibt, andererseits, weil für manche Hardware schlicht nicht genug Informationen zur Verfügung stehen. Daher gibt es immer wieder diese Petitionen an die Hardwarehersteller, eigene Linuxtreiber, wenn möglich OpenSource, herzustellen. Aber wenn die Treiberschnittstelle alle 18 Monate ändert, dann verlieren die meisten Hersteller die Lust, diese kleine Minderheit zu unterstützen.
--
Linux ist eine Turboprop. HURD ist ein Düsenjetprototyp, der seinen Heimatflughafen nie verlassen hat.
|
|
|
|
|
|
|
|
|
|
|
|
|
Lass es mich anders ausdrücken: Nur weil ich einen bestimmten Punkt an Linux kritisiere, heisst das noch lange nicht, das ich sofort auf irgend ein anderes System wechsle, wo dieser Punkt besser gelöst ist.
Dann stoert er Dich nicht genug...
Yo. Wir sind ja heute gar nicht arrogant, was? Jede Hardware, deren Treiber nicht im Kernel ist, wird bequemerweise zum nicht-Standard erklärt.
Nein. Dann nenn es meinetwegen Default (oder Vanilla)-Hardware. Standard ist aussagekraeftiger. Bei anderen Betriebssystemen (Windows/Solaris/VMS) gibt es HCLs (Hardware-Compability Lists), wo drin steht welche Hardware unterstuetzt ist.
andererseits, weil für manche Hardware schlicht nicht genug Informationen zur Verfügung stehen.
Das ist die Hardware, die man nicht kaufen sollte.
Daher gibt es immer wieder diese Petitionen an die Hardwarehersteller, eigene Linuxtreiber, wenn möglich OpenSource, herzustellen.
Dies ist zwecklos. Mann soll vor dem Kauf ueberlegen resp. dem Hersteller sagen, wieso man seine Hardware nicht gekauft hat.
Aber wenn die Treiberschnittstelle alle 18 Monate ändert, dann verlieren die meisten Hersteller die Lust, diese kleine Minderheit zu unterstützen.
Wenn Du die Hardware-Schnittstelle standardisierts, hast Du dieses Problem nicht. Das war bei (nicht-billig-)Hardware (lies: nicht PC-Hardware) die letzten Jahrzehnte der Fall.
Andere Moeglichkeit: die Treibersoftware in den Kernel einfliessen lassen, und nicht als Patch bereitstellen (Beispiel XFS).
|
|
|
|
|
|
|
|
|
|
|
|
|
Dann stoert er Dich nicht genug...
Ah. Ich darf also nicht gleichzeitig Linux benutzen, und es kritisieren, versteh ich das richtig?
Nein. Dann nenn es meinetwegen Default (oder Vanilla)-Hardware.
Es ist "Hardware ohne Linux-Treiber". Nicht mehr und nicht weniger. Ob eine Hardware als Standard betrachtet werden kann, entscheiden mehr oder minder die Verkaufszahlen.
Das ist die Hardware, die man nicht kaufen sollte.
Das ist die Hardware, die 90% der Verkäufe für Endbenutzersysteme ausmacht. Zumindest in den Bereichen Grafikkarten, TV-Karten, Scanner und Drucker.
Dies ist zwecklos. Mann soll vor dem Kauf ueberlegen resp. dem Hersteller sagen, wieso man seine Hardware nicht gekauft hat.
Was genau so viel oder wenig bringt, wie Petitionen. Wenn eine genügend hohe Anzahl Interessierter da ist, wird auf sie eingegangen. Wie auf die Anzahl Interessierter hingewiesen wird, ist letztendlich wurscht.
Wenn Du die Hardware-Schnittstelle standardisierts, hast Du dieses Problem nicht.
Das stimme ich dir zu, aber die derzeitige Situation ist nun mal eine andere.
Andere Moeglichkeit: die Treibersoftware in den Kernel einfliessen lassen, und nicht als Patch bereitstellen (Beispiel XFS).
Und wer, glaubst du, wartet den XFS-Code? Wer hat die ganzen Anpassungen auf den 2.6-er Kernel geschrieben? Das war SGI selbst! Nur haben wir hier den Vorteil, dass XFS vor allem auf Server ausgelegt ist. Und im Unterschied zu Desktops hat dort Linux eine ernst zu nehmende Marktposition.
--
Linux ist eine Turboprop. HURD ist ein Düsenjetprototyp, der seinen Heimatflughafen nie verlassen hat.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ah. Ich darf also nicht gleichzeitig Linux benutzen, und es kritisieren, versteh ich das richtig?
Nein.
Es ist "Hardware ohne Linux-Treiber".
Nein. Es ist Hardware, wo der Treiber vielleicht als Patch herumliegt, dieser aber moeglicherweise nicht gepflegt wird.
Und wer, glaubst du, wartet den XFS-Code?
XFS war urspruenglich ein gigantischer Linux-Kernel mit eingebauten Patch. Separater Tree. Ist nach und nach in den Standard-Kernel gebracht worden. Das war mein Punkt.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ah. Ich darf also nicht gleichzeitig Linux benutzen, und es kritisieren, versteh ich das richtig?
Nein.
Dann lass bitte Sätze im Stile von "geh doch zu Solaris". Oder setz Smileys oder Tags, wenn du es sarkastisch meinst.
Nein. Es ist Hardware, wo der Treiber vielleicht als Patch herumliegt, dieser aber moeglicherweise nicht gepflegt wird.
Sorry. Ich meinte natürlich: Hardware ohne Linux-Treiber im Kernel.
XFS war urspruenglich ein gigantischer Linux-Kernel mit eingebauten Patch. Separater Tree. Ist nach und nach in den Standard-Kernel gebracht worden. Das war mein Punkt.
Dein ursprünglicher Punkt war, dass eine Integration in den offiziellen Kernel helfen soll, wenn sich die Treiber-API ändert. XFS hast du als Beispiel aufgeführt. Mein Gegenargument ist, dass du Maintainer bleibst, auch wenn der Treiber in den Kernel geht. Wenn sich die API ändert, du nichts mehr vom Treiber wissen willst, und auch niemand sonst die Wartung übernimmt, dann fliegt der Treiber ganz einfach wieder raus (ist auch schon passiert).
--
Linux ist eine Turboprop. HURD ist ein Düsenjetprototyp, der seinen Heimatflughafen nie verlassen hat.
|
|
|
|
|
|
|
|
|
Von mtthu
(m anderskor abegglen uf gmx punkt zeha)
am Friday 20. August 2004, 12:26 MEW (#7)
(User #1241 Info)
|
|
|
|
|
Ich habe für mich ein kleines Gedankenspielchen gesponnen, welches auf eine weitere Abstraktion unserer Hardware zielt.
Da wir langsam aber sicher immer mehr an die physikalischen Grenzen stossen, z. B. bei der Übertragungsfrequenz von Signalen in einer Kupferleiterbahn, sollte das Ziel sein, das übertragene Datenvolumen von einem Komponenten zum anderen so klein wie möglich zu halten. Will heissen: Das übertragene Datenvolumen von Northbridge zur Grafikkarte sollte so weit als möglich reduziert werden. Was hat das ganze mit Treibern zu tun? Nun, es spricht einiges dafür, dass man der Grafikkarte etwas mehr intelligenz spendiert. Man könnte dann beispielsweise die Instruktionen, die zur Grafikkarte wandern, erst auf der Karte selbst für die GPU aufbereiten. Wichtige Treiberfunktionen könnte man so in die Firmware auslagern. Worauf ich hinaus will ist Folgendes: Es würde nur noch eine Art Bytecode von der Northbridge in die Grafikkarte übertragen, welcher von der Grafikkarte selbständig interpretiert wird. Dabei spielt es keine Rolle ob die GPU jetzt von ATI oder von NVIDIA stammt. Wie dass dieser Bytecode interpretiert wird, hängt alleine von der entsprechenden Implementation auf dem Board ab. Wenn ein dedizierter Prozessor auf dem Grafikboard diese Aufgabe übernimmt, kann das sogar relativ schnell geschehen. Die Vorteile wären verlockend:
1. Man braucht sich als Treiberentwickler nicht mehr darum zu kümmern was für eine GPU genau am Werk ist. Dies würde allerdings bedingen, dass ATI und NVIDIA sich über den Funktionsumfang resp. den Code selbst einigen könnten. Andernfalls gäbe es halt verschiedene Bytecodes mit verschiedenen Instruktionen.
2. Das Datenvolumen wird reduziert, so kann evtl. der stetige Anstieg der Signalfrequenz in den Schnittstellen etwas konsolidiert werden.
3. Die hochfrequenten Signale müssen nur noch von diesem Prozessor zur GPU übertragen werden.
Es ist sogar denkbar, dass ein solcher Prozessor in der GPU integriert werden könnte, so dass kein weiteres Bauteil (=Kosten) nötig wäre um diesen ganzen Spass zu realisieren.
Ich bin der Meinung, dass eine Komponente in einem System möglichst autonom arbeiten sollte. Die Schnittstelle auf das Gerät sollte so einfach wie möglich und sehr abstrakt sein. So sind die Zeiten längst vorbei, als man der Festplatte noch jede Bewegung befehlen musste. Je mehr Interpretationsarbeit eine Komponente selbständig erledigen kann, desto schlanker wird die Schnittstelle.
----------------
Eat, Drink, Drum
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
also quasi openGL / mesa3D / DirectX direkt auf die Karte bringen?
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja, ungefähr.
----------------
Eat, Drink, Drum
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 20. August 2004, 16:21 MEW (#16)
|
|
|
|
|
Ist nicht D3D / DirectX genau das... Mit all den programmierbaren Shadern und dem Zeug?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OK, die Überschrift ist vielleicht etwas prahlerisch. Was ich meine sind Konzepte die einen Ansazt verfolgen, der bislang nur sehr spärlich umgesetzt wurde. OpenGL als Schnittstelle wäre wahrscheinlich das Wunschziel und hatte, wie du sagst, vor langer, langer Zeit vielleicht einmal genau diese Abstraktion zum Ziel. Das Problem war damals sicherlich, dass die Umsetzung dieser Konzepte ausserhalb des technisch Machbaren lag (ok, machbar, aber nicht bezahlbar). Heute wo die GPUs in ihren spezialisierten Aufgaben um ein vielfaches schneller sind als eine CPU, und es kein Problem wäre, ein API direkt in der Firmware zu integrieren, sollte man die Idee wieder aufgreifen. Wie gesagt, die Vorteile wären enorm.
----------------
Eat, Drink, Drum
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 20. August 2004, 13:43 MEW (#8)
|
|
|
|
|
Bei den alten Rage Karten waren die ATI Treiber für Win so schlecht, dass selbst ein simples resizen eines OpenGL Fensters den Treiber (und damit das OS) zu Fall brachte. Also hab ich mir die Zeit genommen, ATI einen sauberen Bugreport mit allen Details zu senden. Reaktion? Feedback? Vergiss es.
|
|
|
|
|
|
| |
|
|
|
|
Von Anonymer Feigling am Friday 20. August 2004, 16:26 MEW (#18)
|
|
|
|
|
Auf der Erde...?
Es ist einfach, mit Schematics ist sicher nicht der Kern gemeint weil der eigentlich auch 'programmiert' wird daraus wird dann dass hardware schema mit den aberwitzig vielen Transistoren generiert.
Was sie eher meinen ist das ganze klim-bim drumherum damit man weiss wie die Speicherarchitektur etc aussieht.
Ausserdem will man ja auch versuchen etwas Druck auszuüben. Denn sollte das durchkommen könnte es durchaus sein dass andere Hersteller nachziehen was nur ein Vorteil sein kann.
Das hier ist auch interessant: http://www.opencores.org/
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 20. August 2004, 17:57 MEW (#20)
|
|
|
|
|
Druck? Von ein paar Leuten die ein OS mit einer Desktop-Verbreitung von unter 1% brauchen?
Druck machen wohl eher die Konkurrenz, OEM Hersteller, Game Hersteller, MS mit neuen DirectX Versionen, Intel mit neuen Bussystemen und Hardwaresiten wie HardOCP, Tomshardware et al.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 20. August 2004, 18:56 MEW (#23)
|
|
|
|
|
Ja ok... Es geht einfach darum Präsenz zu markieren. Je nach dem wieviele Leute bei der Petition mit machen kann sich ATI selber ausrechnen wieviele potentiell zu Kunden werden - auch solche die nicht mitgemacht haben.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 20. August 2004, 13:56 MEW (#10)
|
|
|
|
|
bis zur ATI Radeon 9200 (r200, r250) geht DRI doch auch mit den freien treibern wunderbar, passiv gekuehlt das ganze sogar, zumindest fuer meine ansprueche. wer zocken will kann auch gleich M$ Win nehmen oder 'ne Spielekonsole.
wer aber wirklich 3D-leistung fuer seine arbeit braucht, der steht wirklich bloed da und ist wohl (leider!?) besser bedient mit NVidia, wenn man nicht gerade richtig teure GL-hardware anschaffen will/kann. insofern schon eine unterstuetzenswerte petition ... *sign*
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 20. August 2004, 15:04 MEW (#14)
|
|
|
|
|
die radeon9000 hat mehr als genug Grafikpower
für Quake3 bei 1024x768 Lightmap und highrestexturen
;) .. naja wer D3 bald unter Linux spielen will der muss sich eine nvidia gk holen
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 20. August 2004, 16:23 MEW (#17)
|
|
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 20. August 2004, 19:52 MEW (#24)
|
|
|
|
|
naja gut wenn Du über die 150 fps kommen willst ?
dann nicht,
|
|
|
|
|
|
