... allerdings bin ich mir auch nicht ganz sicher was es bedeutet. Bedeutet das nun, dass KDE mit KWin dann garnicht mehr läuft, oder nur, dass Compositing mit Effekten dann nicht mehr funktioniert? Läuft KDE dann also auf alter Hardware nur noch so, wie wenn ich aktuell Strg + Alt + F12 drücke? Ich finde auch die Annahme, dass z.B. der I965 aus 2006 ist etwas grenzwertig, da mit sicherheit viele Systeme mit einem I965 nicht sofort bei Erscheinen des Chips sondern in der Zeit danach gekauft wurden, was natürlich auch entsprechend für die Vorgängergeneration gilt. D.h. gibt es vermutlich viele I945 Systeme die z.B. noch 2007 gekauft wurden, und somit "gefühlt" nicht so alt sind. Das sollte man auf jeden Fall auch bedenken. Ich glaube zwar auch, dass der Schnitt mit Qt5/KDE5 erfolgen sollte, hoffe aber auch, dass nicht so viele betroffen sind, da unter Linux ja gerne auch mal alte Hardware genutzt wird, gerade weil diese noch unterstützt wird. Allerdings glaube ich auch, dass diese Ausnahmen auch gut mit LXDE oder anderen schlanken DEs auskommen können. Ich bin mit meinem I965 Laptop und meiner NV 7600GT im Desktop zum Glück nicht betroffen ... noch nicht
Bedeutet das nun, dass KDE mit KWin dann garnicht mehr läuft, oder nur, dass Compositing mit Effekten dann nicht mehr funktioniert?
Im Gegensatz zu anderen Desktop Umgebungen erzwingt KDE Plasma kein Compositing. Heißt wenn (und nur wenn) OpenGL 1.x Unterstützung entfernt wird, steht diese nicht mehr zur Verfügung. Jedoch steht weiterhin (solange wir unter X sind) XRender zur Verfügung und in meinem Blogpost habe ich eine klare Voraussetzung für das Entfernen von OpenGL 1.x Code genannt: llvmpipe muss funktionieren.
Also selbst wenn (und nur wenn) wir OpenGL 1.x Code entfernen stehen weiterhin Effekte zur Verfügung mit Ausnahme derer, die sowieso nicht auf der Hardware unterstützt würden.
Ich glaube zwar auch, dass der Schnitt mit Qt5/KDE5 erfolgen sollte
Ich weise an dieser Stelle noch einmal darauf hin, dass es keine Pläne für ein "KDE5" gibt. Wie in meinem Blogpost erwähnt, werden wir mit Qt 5 sowieso die Unterstützung von OpenGL 1.x Code entfernen müssen. Ich erwarte dass KWin mit 4.10 oder 4.11 auf Qt 5 umsteigen wird.
Was mich mal interessieren würde: Kann man über ein kleines Tool, wie es z.B. LinuxCounter benutzt, in etwa grob herausfinden, wieviel Prozent der KDE-User denn tatsächlich davon betroffen wären?
Wenn du eine Lösung hast wie man überhaupt rausfindet, wie viele Nutzer wir haben und was für Hardware, welche Option und so weiter, wären wir sehr daran interessiert.
Ich finde es gut das Altlast entfernt wird. Ich selbst habe einen altes Laptop mit einem SIS Chipsatz und mit einer aktuellen Distributionen gibt es sowieso nur Performanceprobleme zusätzlich würde ich auf so einer alten Hardware keine Gnome oder KDE betreiben.
Man muss nun mal nach vorne schauen und nicht jede alte Sache mit schleppen, welche nur mehr Arbeit kostet und die Entwicklung neuerer Features für die Mehrheit bremst.
Von Trächtige Tröllin am Mi, 22. Februar 2012 um 21:29 #
Das hier sind Statistiken zu Grafikhardware: > http://bsdstats.org/bt/devices/class/03/subclass/00.html Erfasst werden die mit: > http://www.freshports.org/sysutils/bsdstats/ Die Verwendung von bsdstats ist natürlich freiwillig. Sieht zumindest bei den BSDlern nicht so aus, als würden die jedes Jahr los rennen wollen, um sich neue Hardware zu kaufen. Das kann Apple ja machen wie sie lustig sind, so lange die Käufer das mitmachen, aber genau solch einem Diktat zum Neukauf wollen die Anwender freier Software offensichtlich wohl eher nicht.
Hast Du keinerlei Befürchtung, dass vielleicht 50% Eurer ATI-Nutzer keine Lust haben werden, ihre neuen und nagelneuen Radeon-Chips mit dem im Vergleich zu fglrx langsameren radeon-Treiber zu betreiben, d.h. ihren Treiber downzugraden?
Fglrx-Nutzer setzen ja gerade keine alte oder obsolete Hardware ein. Sie wollen ihre neuen Radeons unter Linux ausreizen. Das funktioniert mit radeon nicht.
Wenn das aber alles nicht so wichtig für KDE4 ist, dann raus mit OpenGL 1.x.
Ich verwende ein Dell Latitude D620 mit GMA945, auf dem KDE 4 hervorragend läuft. GMA945 wurde auch für viele Netbooks verbaut, die bis zur letzten oder vorletzten Atom Generation verbaut wurden. Zumindest für die Netbooks dürfte llvmpipe keine Alternative sein, da die Rechenleistung eh schon bescheiden ist und für die Grafik nicht noch ein Großteil dabei flöten gehen sollte, die müssten also alle auf XRender umstellen. Man kann aber auch z.B. Debian 7 installieren, sobald das rauskommt, damit hat man sicher noch ein KDE das mit OpenGL 1.x kann und das vermutlich bis 2015 gepflegt wird. Mich persönlich juckts jetzt nicht so sonderlich, mein D620 hat nen Lüfter mit Lagerschaden und ich hoffe dass es noch durchhält bis die Ivy Bridge CPUs rauskommen, dann ist ein neues fällig und damit hab ich in Zusammenarbeit mit Mesa 8 dann sogar OpenGL 3.
Von Alte Hardware-Benutzer am Di, 21. Februar 2012 um 13:28 #
Die Frage ist natürlich, ob bei so alter Hardware die Effekte nicht einfach abgeschaltet werden sollten. Auf meinem X40 Tablet läuft KDE4.8 super, solange man in der Xorg.conf XComposite komplett abschaltet.
Ein Notebook wie der Dell Latitude D620 mit Dualcore CPU um die 2GHz, 3GB RAM und Intel 945GM Grafik ist doch wirklich leistungsstark genug für die üblichen Anwendungen. Von alter Hardware würde ich hier nicht sprechen wollen.
Bisher läuft auch Compositing unter KDE4 schnell und problemlos. Sobald das gegen eine langsame Softwareemulation ersetzt wird ist Compositing praktisch nicht mehr nutzbar und damit sind die wenigen Usability-Vorteile von KDE4 dahin.
Danke für die Klärung. "KDE5" hätte ich besser in Anführungszeichen geschrieben ... oder vielleicht nur Qt5 gesagt, weil das ist was ich eigentlich meinte ... oder vielleicht Qt5/Wayland.
IMO hast Du viel zu viel um den heißen Brei herumgeredet: Die alten DRI1-Treiber und -Grafikchips haben sowieso bald keinerlei 3D-Unterstützung mehr, damit ist unter Linux ab Mesa 8.0 nichts mehr "Hardwaremäßiges" da, was mit OpenGL zusammenarbeiten darf. Selbst XAA wurde entfernt, damit verlieren viele alte Grafikchips auch noch ihre 2D-Hardwarebeschleunigung. Die alten Grafikchips sind somit ohnehin "tot". Deshalb wird empfohlen, in Zukunft shadowfb zu benutzen.
Allerdings ist die Llvmpipe für Systeme unter einem Dual-Core sehr wahrscheinlich keine gangbare Alternative, das System wird praktisch "stehen". Du brauchst Dir ja nur einmal zu überlegen, in was für Rechnersystemen diese alten Grafikchips stecken.
So wie ich das verstanden habe, sind aber auch auf KMS/DRI2 portierte Grafikchips wie z.B. die Radeon 7500 und Geforce4MX von dieser Aktion betroffen. Wenn KWin mit diesen Chips nicht mehr funktioniert, dann kann man ja z.B. auf Openbox ausweichen oder KDE3 benutzen oder eine alte Distro weiterverwenden (SL5, CentOS5).
Mit diesem verstärkten Setzen auf reine CPU-Power (Llvmpipe) sehe ich in punkto freie Grafiktreiber lausige Zeiten auf uns zu kommen. Wenn Nouveau dann halt wieder einmal nicht funktioniert, dann soll man doch bitte die CPU zur Grafikverarbeitung nutzen, die GPU dreht dann halt Däumchen.
Typische Kandidaten für die Llvmpipe sind starke Rechner z.B. mit Quadcore-CPUs. Wenn man also einen NVidia- oder Radeon-Chip im Rechner hat, der von Linux nur mit Vesa unterstützt werden würde, dann kann man von den "3D-Features" dieser Llvmpipe profitieren und Gnome3 wird - z.B. mit heiß laufendem Notebook - zufriedenstellend in Pseudo-3D-Pracht laufen. Llvmpipe ist aber nichts für alte Systeme, es fehlt schlichtweg die CPU-Power. Diese Illusion sollte man nicht unnötigerweise erwecken oder aufrechterhalten.
Ich weise an dieser Stelle noch einmal darauf hin, dass es keine Pläne für ein "KDE5" gibt.
Ich kenne die aktuelle Entwicklung diesbezüglich nicht. Heißt das, dass man innerhalb der KDE4-Linie dann die Binärkompatibilität über Bord wirft? Hat man das ernsthaft so beschlossen?
werden wir mit Qt 5 sowieso die Unterstützung von OpenGL 1.x Code entfernen müssen
Naja, "müssen"... In Zeiten von Git wäre die Pflege eines eigenen Zweiges so einfach wie noch nie zuvor. Auch wenn ich das natürlich nicht gut finde.
Es ist halt immer die Frage, ob einen alte Zöpfe wirklich Zeit kosten. Meinethalben kann man den OpenGL 1.x-Support ja deaktivieren aber drin lassen. Wer dann auf ihn angewiesen ist, muss Bugs darin fixen. Es ist in der Softwareentwicklung ohnehin illusorisch, sicherstellen zu wollen, das sämtliche unterstützten Szenarien funktionieren und bei der Weiterentwicklung berücksichtigt werden.
Ich kenne die aktuelle Entwicklung diesbezüglich nicht. Heißt das, dass man innerhalb der KDE4-Linie dann die Binärkompatibilität über Bord wirft? Hat man das ernsthaft so beschlossen?
Wenn man die aktuelle Entwicklung diesbezüglich nicht kennt, sollte man keine Schlüsse ziehen Was ich aussagen wollte, ist dass es keine Pläne für ein KDE 5 wie ein KDE 4 gibt. Der einzige Unterschied ist, dass dann Qt 5 statt Qt 4 verwendet wird. Mehr oder weniger einfach nur einmal neu kompilieren.
Naja, "müssen"... In Zeiten von Git wäre die Pflege eines eigenen Zweiges so einfach wie noch nie zuvor. Auch wenn ich das natürlich nicht gut finde.
"Müssen" war das falsche Wort. Es wäre sinnbefreit den Code zu behalten, da Qt 5 OpenGL (ES) 2.0 eh erfordert.
Wenn man die aktuelle Entwicklung diesbezüglich nicht kennt, sollte man keine Schlüsse ziehen
Na Momeeent, grundlegendes Verständnis über Schnittstellen und Shared Libraries besitze ich deshalb trotzdem. Nur, weil ich leider keine Zeit mehr habe, die Mailinglisten zu lesen, heißt das nicht, dass ich gleich fachlich abgebaut hätte.
Was ich aussagen wollte, ist dass es keine Pläne für ein KDE 5 wie ein KDE 4 gibt. Der einzige Unterschied ist, dass dann Qt 5 statt Qt 4 verwendet wird.
Aha, also stimmt meine Aussage, die Binärkompatibilität innerhalb der KDE 4-Reihe wird aufgegeben, da man auf Qt5 umsteigt. Das hat man bei den letzten Versionen eben so nicht gemacht, daher kam meine Frage: Hat man diesen Fakt entsprechend diskutiert und für "ist egal" befunden? Das wäre immerhin neu.
Es wäre sinnbefreit den Code zu behalten, da Qt 5 OpenGL (ES) 2.0 eh erfordert.
Nach Hauptlinie, ja. Es ist halt die Frage: Welcher Code erfordert das. Wenn man die Notwendigkeit auf Seiten KDE hätte, die Kompatibilität zu alten Grafikkarten beizubehalten, müsste man dort eben andere Wege finden. Ich sage nicht, dass man das muss, sondern dass es zur Not sicher auch anders ginge.
Die "binärkompatibilität" kann dir doch völlig wurscht sein solange nur der Compile angeworfen werden muss - Oder hast du schon mal eine Binär-Distribution gesehen die bei enem KDE-Update alte und neue Binaries mischt?
Die "binärkompatibilität" kann dir doch völlig wurscht sein solange nur der Compile angeworfen werden muss
Es ist schön, wenn man im Leben nur auf freie Software zurückgreifen muss, in der Realität ist die weit größere Menge von Software jedoch proprietär. Aus diesem Grund lassen sowohl Qt als auch die KDE-Libs es lizenztechnisch zu, in proprietärer Software gelinkt zu werden.
Darüber hinaus mag nicht immer jeder Anwender einer In-House-Lösung in der Lage sein, diese aus dem Quellcode zu bauen, nur, weil seine Distribution die darunter liegenden Qt- oder KDE-Versionen aktualisiert hat.
Deshalb haben das KDE-Projekt und Qt bislang großen Wert darauf gelegt, innerhalb einer Major-Version binärkompatibel zu bleiben. Den aRts-Soundserver hat man deshalb durch die gesamte KDE3-Linie geschliffen, obwohl man sich seiner technischen Schwächen schnell bewusst war. Das man diesen Grundsatz jetzt offenkundig aufgegeben hat, mag man als Anwender mögen oder nicht, Konsequenzen hat es jedenfalls.
Ob die OpenGl 1.x Ünterstützung fällt oder nicht ist m.E. für den Benutzer unwichtig. KDE 4.8 läuft jedenfalls auf meinem sieben Jahre alten Sempron und einer via-chrome onboard Grafikkarte und 1 GB RAM schnell genug.
Wenn KDE nicht benutzt wird, hat dies andere Gründe als die der Grafikkarte. Bei mir ist es z.B. der Arbeitsspeicher. Die Webbrowser fressen mit jedem Tab immer mehr Speicher. Da ich meine Arbeitsweise nicht ändern will, benutze ich icewm. Denn damit steht meinem Webbrowser von Anfang an mehr RAM zur Verfügung.
Mit anderen Worten, es ist für mich unerheblich, wie sehr sich die Entwickler bemühen, ich werde auf diesem Rechner gründsätzlich kein KDE mehr benutzen.
PS: Ich werde mir bald einen neuen Rechner anschaffen und dann auch wieder KDE benutzen.
Von Trächtige Tröllin am Di, 21. Februar 2012 um 17:14 #
Der Intel GMA 950 ist in Massen in Netbook und in Nettops typischerweise mit der 2 Watt Intel Atom CPU n270 verbaut. Bürocomputer benutzen den Intel GMA950 auch ganz gerne. Wenn erst ab dem i965 Chipsatz mit der Intel GMA 3000 der Betrieb möglich sein soll, dann wird da wirklich der Ruf der Alternativen zu Windows massiv geschädigt. Der Intel GMA 950 zieht zwar nicht die Wurst vom Teller, KDE4x ist aber mal damit fröhlich gelaufen, auf meinem Netbook und auf meinem Nettop.
Wäre wirklich nett, wenn KDE und die Grafikunterstützung den Usern nicht kaputt gemacht würde.
Der Kommentar von Kenneth Graunke (hier als Link direkt auf den Kommentar) ist wirklich interessant! Damit wären die Intel-Grafikchipsätze GMA 900, GMA 950, GMA 3000 und GMA 3100 abgedeckt und von der Änderung nicht betroffen. Das halte ich insofern für wichtig, da z.B. der GMA 3100 noch 2009 verkauft wurde.
SLI wurde nie unterstützt und das was da war, war selbst bei nur einem Kern nur etwa 70 % so schnell wie der Windows Treiber.
Und was ist jetzt? Jetzt ist die ganze Karte obsolete, weil der Rest auch noch rausgeschmissen wird.
Denn es betrifft ja nicht nur KWin, sondern vor ein paar Tagen gab's ja hier auch ne Meldung wegen X.ORG wo auch Zeugs rausgeschmissen wird.
Fazit: Closed Source Treiber des Herstellers sind sinnvoller, denn die funktionieren wenigstens von Anfang an schnell und bieten alles was die Karte kann und ehe der Support dafür eingestellt wird, kauft man einfach ne neue Karte. Denn die Warteei auf gute Open Source Treiber bringt ja auch nichts wie man sieht und Alttechnologie wird auch im Linux Umweld irgendwann obsolete.
Ach ja, die Voodoo 5 war schon von Anfang an sehr gut dokumentiert. Die Glide Lib ist auch Open Source, da steckt das ganze Know How drin.
Die Voodoo-3D-Treiber unter Linux sind vollkommen freie 3D-Treiber, an der sich selbst nouveau noch eine Scheibe abschneiden kann, wenn manche modernste Nvidiagrafikkarten damit nur ohne 2D- und 3D-Hardwarebeschleunigung funktionieren. Insofern sind die tdfx-Treiber ein Verlust.
"Closed Source Treiber des Herstellers sind sinnvoller"
Du meinst die nicht vorhandenen Closed Source-Voodoo-Treiber des im Jahre 2000 untergegangenen Voodooherstellers 3Dfx? Frage doch mal bei Nvidia nach, die haben den Laden damals gekauft.
Und wie sinnvoll diese merkwürdige OpenGL 1.x-Abhängigkeit der fglrx-Treiber ist, sieht man ja jetzt. Game Over (zunächst nur unter KDE4) für proprietären Krempel. Da lacht mein FSF-Herz.
Trotzdem würde ich eine Entscheidung, die KDE4 mit fglrx inkompatibel macht, davon abhängig machen, wieviel KDE4-Radeon-Nutzer denn überhaupt fglrx einsetzen. Sind es mehr als ein Drittel, würde ich die angesetzte OpenGL 1.x-Axt ganz schnell wieder verschwinden lassen.
Noch schlimmer als das Benutzen unfreier Software ist es, treue Nutzer vor den Kopf zu stoßen. Die fglrx-Treiber sind normalerweise zigmal schneller als ihre radeon-Pendants (nicht mit KDE4-Effekten, wohl aber im Zusammenspiel mit richtig fordernden OpenGL-Programmen). Da haben wir wieder diese schreckliche Fratze, nämlich die offene Linuxdrohung mit einem Verschlechterungsupgrade. Also, liebe KDE4-Entwickler: Macht doch bitte eine Umfrage!
Im übrigen kann es sogar sein, dass es für einige Voodoo- und auch Matroxgrafikkarten vielleicht sogar irgendwann einmal einen richtigen KMS-Grafiktreiber geben wird. "3D" ist allerdings in Zukunft weg, die Grafikchips sind mittlerweile einfach zu alt. Ihre Hardware-3D-Fähigkeiten passen nicht in die geplante, neue Wayland-/DRI2-/Gallium3D-Welt.
Nichtsdestotrotz gibt es immer noch zwei mögliche, partielle Rettungszenarios: 1. Ein Xorg-Entwickler erbarmt sich eines Grafiktreibers und flickt ihn als Nichtmaintainer provisorisch zusammen (z.B. tdfx). 2. Ein großer kommerzieller Distributor ist mit großen "Beständen" noch eingesetzter Legacy-Grafikchips in bestimmten Segmenten konfrontiert und muss sich aus Profitgründen zwangsweise darum kümmern (z.B. mga).
"Closed Source Treiber des Herstellers sind sinnvoller"
Du meinst die nicht vorhandenen Closed Source-Voodoo-Treiber des im Jahre 2000 untergegangenen Voodooherstellers 3Dfx?
Nö, ich meine damit hauptsächlich das Marktangebot im Gesamten. Also die beste Lösung an Grafikkarten für Linux mit ausgezeichneten Treibern wenn die Karte neu ist und das war schon immer NVidia mit seinen closed source Treibern.
Die TDFX Treiber wurden übrigens von 3dFX mitentwickeln, dafür hatte 3dFX extra Entwickler abgestellt und als 3dFX dann hopps ging, gingen die Entwickler auch und an SLI wurde nicht mehr weitergearbeitet. Die Open Source Community hat dann an SLI auch nichts mehr gemacht bzw. das in den Griff bekommen, das will ich damit sagen, daß man sich hier auf die Open Source Community nicht verlassen kann.
Denn möglich wäre es gewesen, die OS Community hatte alle Daten die für SLI notwendig gewesen wären.
Die fglrx-Treiber sind normalerweise zigmal schneller als ihre radeon-Pendants (nicht mit KDE4-Effekten, wohl aber im Zusammenspiel mit richtig fordernden OpenGL-Programmen).
Tja siehste und genau da liegt das Problem.
Ne GPU hat man normalerweise, damit die 3d Grafik Berechnung schnell geht. OS Treiber waren schon immer langsamer und reduzierten die eigentliche Leistungsfähigkeit der GPU drastisch. Bei der VSA-100 wie bereits gesagt auf 70 %, während die NVidia Treiber immer bei fast 100 % liefen im Vergleich zu den Windowstreibern gesehen.
"3D" ist allerdings in Zukunft weg, die Grafikchips sind mittlerweile einfach zu alt. Ihre Hardware-3D-Fähigkeiten passen nicht in die geplante, neue Wayland-/DRI2-/Gallium3D-Welt.
Ja, leider und genau das ist ja auch der Grund, warum man bei GPUs nicht auf Open Source setzen kann. Man muß das nehmen, wo es die schnellste Treiber für die aktuelle HW gibt und damit wären wir bei NVidia CS.
Es bringt einfach nichts hier aus ideologischen Gründen auf OS zu setzen und dann > 5-10 Jahre warten, bis die GPU endlich ausgereizt werden kann, denn am Ende stellt man fest, daß der ganze Support trotzdem über Bord geworfen wird und man nie auf die maximale Geschwindigkeit (oder auch Features) die auch unter Win geboten wurde herankam. Und genau dieses Faktum, die Einstellung des Supportes bei Open Source Treibern relativiert auch die Einstellung des Supportes bei Closes Source Treiber, daher ist das kein Manko, wenn NVida Karte XY nach X Jahren nicht mehr unterstützt, denn bei Open Source Treiberkarten fällt die Unterstützung ja auch weg. Und BTW, meine Geforce 4 läuft auf meinem Ubuntu LTS noch und die Karte konnte von Anfang an ausgereizt werden.
Daher sage ich ja, bei Grafikkarten gilt closed source only, weil besser.
Es ist bei GPUs einfach ein Märchen, daß man mit Open Source den besten Support, das Beste Bugfixing, die Beste Funktionalität und das auf fast ewig (für Computerverhältnisse) bekommt. Bei anderer HW mag das anders aussehen, aber bei GPUs ist Closed Source in jeder Hinsicht überlegen.
Tja. Ich persönlich habe da schon längst kapituliert. Ich benutze strikt Debian Main und unter Squeeze ist das mit einer Radeon- oder Nvidia-Karte gleichbedeutend mit Computer-2D-Steinzeit. Und dass ich zukünftig anfange, KDE4 oder Gnome3 in reinem Software-3D ohne tatsächliche 2D- und 3D-Hardwarebeschleunigung zu nutzen, das fällt mir nicht im Traum ein. Ich gehe auch davon aus, dass PIII- und PIV-Single Core-CPUs für die Llvmpipe zu langsam sein werden.
Diese Llvmpipe ist IMO real gewordene, hochgradige Verzweiflung angesichts dieser unfassbar unfreien Grafikhardwarelandschaft und sie ist auch nichts anderes als die Konsequenz aus Deiner ziemlich richtigen Analyse: Red Hat und Co. wissen, dass die freien radeon- und insbesondere die nouveau-Treiber es nie mit ihren unfreien Pendants werden aufnehmen können und dass es im freien Grafiktreiberbereich immer Unterstützungsprobleme geben wird, also trifft man eine Vorsorge, die zumindest auf neuen Rechnersystemen als Fallback mit ultraschlechter Performanz (im Vergleich zu den Fähigkeiten der eingebauten GPU) funktioniert. Jedenfalls sind unter Linux die Fähigkeiten von CPUs um einiges besser nutzbar als die meisten de facto "verbotenen" und unzugänglichen GPU-Features.
Natürlich ist es auch richtig, dass KDE4 nicht für zehn bis fünfzehn Jahre alte Grafikhardware entwickeln kann, vor allem dann nicht, wenn Xorg und Mesa für diese alte Hardware praktisch den Support einstellen. Der Vorschlag, im 2D-Bereich einen solchen alten Grafiktreiber ohne 2D- (und 3D-) Hardwarebeschleunigung, dafür aber mit shadowfb zu benutzen, heißt nichts anderes. Besser wäre der Ratschlag, auf älteren Systemen z.B. RHEL5 oder einen RHEL5-Klon zu verwenden, mit Support bis 2017 für einen älteren Xorg und ein älteres Mesa, das DRI1-Grafikchips ganz gut unterstützt. KDE4 und Gnome3 sind definitiv nichts mehr für alte (Grafik-)Hardware.
Kontraproduktiv ist auch, dass Linux angefangen hat, an den Grundlagen des unfreien fglrx- und nvidia-Supports herumzusägen. Wenn das mal nicht nach hinten losgeht.
Von Trächtige Tröllin am Mi, 22. Februar 2012 um 12:58 #
Also ich komme mir ganz besonders bei den freien Treibern vor den Kopf geschlagen vor. Stichwort Intel GMA 950, die in Massen in Notebooks und in Netbooks, sowie in Bürocomputern verbaut ist. Mit der Intel GMA 950 hat man sich komplett auf freie Grafiktreiber verlassen und muss nun entsetzt feststellen, dass dies einen riesige Fehlentscheidung war. Vor allem kann man auch in Netbooks und in Nettops die Intel GMA 950 nicht austauschen, so wird gleich der ganze Computer als Desktop System unbrauchbar gemacht, durch die Entscheidung die Unterstützung für OpenGL für diese Chipsätze zu zerstören.
Zu gut deutsch, da wird zehntausenden von Usern Leid zugefügt. Da wird mit Gewalt der Ruf von OpenSource Software zerstört. Auf das jeder deutlich merken soll, das OpenSource Software unzuverlässig ist?
Nur in bezug auf KDE4. Ich kann mir nicht vorstellen, dass eine Unternehmensdistro mit ihrem Unternehmensstandarddesktop (meist ist das Gnome) ähnlich verfährt.
Das Wichtigste aber vorweg: Du musst beachten, von was für einem Zeitfenster der KWin-Entwickler da spricht, es geht nicht um KDE4/Qt4/KDE4-Kwin, es geht um KDE5/Qt5/KDE5-Kwin. Weder das bis 2017 unterstützte Ubuntu 12.04 werden davon betroffen sein, noch RHEL6/SL6/CentOS6 mit Support bis 2020 und höchstwahrscheinlich noch nicht einmal SLES12/SLED12 mit ähnlich langem Support. Bis 2017/2020 sollten sich die Unkosten für Dein Intel-Notebook aber amortisiert haben.
Im übrigen kann ich Dir nur raten, frühzeitig Bugreports in der Betaphase einer Distributionsentwicklung abzusetzen, damit vermisste Funktionalität zumindest als optionales Etwas wiederhergestellt wird. Distros wie openSUSE/Suse und Fedora/Red Hat sind dafür am Geeignetsten, weil sich die Entwickler sehr gut mit der Materie auskennen und nicht selten dafür auch bezahlt werden. Du erhältst dann eine klare Ansage: O.k., das können wir einbauen bzw. optional anbieten oder aber das geht aus dem und dem konkreten Grunde nicht.
Die Catalystgeschichte muss allerdings in den AMD-Bugtracker. Auch hier kann man eine klare Aussage erwarten. Ergänzend dazu kann es sich lohnen, in bestimmten Foren herumzuposten (u.a. Phoronix) und AMD-Leute wie "bridgeman" zu fragen, vor allem im Hinblick auf technische (Machbarkeits-) Fragen.
Zudem sind bestimmte Distros eher konservativ: Selbst wenn Du Dir heute ein aktuelle, sehr moderne openSUSE (also nicht nur SLES/SLED) anschaust, dann findest du überall Kompatibilitätsbibliotheken und Legacy-Xorg-Module, wie z.B. intellegacy und nv. Debian z.B. lässt nv zwar aus eher ideologischen Gründen (ab Wheezy) verschwinden, eine eher unternehmensorientierte Distro wird sich da tunlichst davor hüten.
Ein weiteres Beispiel ist das openSUSE-Cups-Zusatzprogramm "parallel-printer-support" bzw. demnächst ein entsprechendes Modul für das kommende Cups 1.6. Übrigens war der Auslöser für dieses Projekt der Bugreport eines Administrators eines Schulcomputernetzes, dessen Parallel Port-HP Office-Jets plötzlich nicht mehr druckten. Die haben schlichtweg kein Geld für neue Drucker.
Übrigens: Laut einem Kommentar unter http://blog.martin-graesslin.com/blog/2012/02/the-costs-of-supporting-legacy-hardware/#comments läuft KWin mit OpenGL2-Shadern: http://blog.martin-graesslin.com/blog/2012/02/the-costs-of-supporting-legacy-hardware/comment-page-1/#comment-46365
Bis 2017/2020 sollten sich die Unkosten für Dein Intel-Notebook aber amortisiert haben.
Ein NB mit einem Pentium M oder besser und 2 GB RAM reicht locker für alle heutigen Office und Surfausgaben aus und das wird auch in 2017/2020 noch der Fall sein, weil zu Officeprogrammen auch nicht mehr so viel neues hinzukommt, was Leistung fressen würde.
Insofern bedeutet KDE 5 also für diejenigen, daß man eine gute funktionstüchtige Hardware wegschmeißen muß, nur damit KDE 5 läuft. Und KDE 4 wird dann ja wohl kaum weitersupported werden.
Deswegen halte ich die Entscheidung den Support für diese alte HW rauszuschmeißen für falsch. Denn Leistungsfähig ist diese alte Hardware für normale Office und Surfaufgaben immer noch mehr als genug.
Debian z.B. lässt nv zwar aus eher ideologischen Gründen (ab Wheezy) verschwinden, eine eher unternehmensorientierte Distro wird sich da tunlichst davor hüten.
Ubuntu hat den Support für die Glide Library bei ca. Ubuntu 6.10 rausgeschmissen und die libglide ist GPL. Ohne Glide Library gibt's keine 3d Unterstützung für Voodoo Banshee, 3, 4 und 5 Karten.
"Ubuntu hat den Support für die Glide Library bei ca. Ubuntu 6.10 rausgeschmissen und die libglide ist GPL. Ohne Glide Library gibt's keine 3d Unterstützung für Voodoo Banshee, 3, 4 und 5 Karten."
Keine Ahnung, was Ubuntu da gemacht hat. In anderen Distros sind die notwendigen OpenGL-Libs noch enthalten. Z.B. in Debian Squeeze: http://packages.debian.org/squeeze/libglide2 http://packages.debian.org/squeeze/libglide3 Ich habe in einem Rechner noch eine uralte Voodoo Banshee verbaut, die funktioniert mit libglide3 in "3D" (16bit-Farbtiefe).
Was KDE5-KWin anbelangt: Du musst die alte Hardware nicht wegschmeißen, Du kannst dann wahrscheinlich nur keinen 3D-KDE5 mehr benutzen, "nur" eben einen 2D-KDE5 mit normalem 3D für die üblichen OpenGL-Programme oder auch mit Xrender.
Ja, genau das ist das Problem von Open Source Treibern.
Mein Notebook ist aus dem Jahre 2005 und besitzt zum Glück eine NVidia Geforce 6600 Go und die closed source Treiber laufen immer noch auf aktuellen Distributionen und das sie super performant sind und die Stromsparmodi der GPU unterstützen muß ich ja nicht noch extra erwähnen.
Ich hab noch einen alten Laptop aus 2000 mit SIS Chipsatz und eine Riva TNT2 Grafikkarte. Hilft das irgendwie weiter?
... allerdings bin ich mir auch nicht ganz sicher was es bedeutet. Bedeutet das nun, dass KDE mit KWin dann garnicht mehr läuft, oder nur, dass Compositing mit Effekten dann nicht mehr funktioniert?
Läuft KDE dann also auf alter Hardware nur noch so, wie wenn ich aktuell Strg + Alt + F12 drücke?
Ich finde auch die Annahme, dass z.B. der I965 aus 2006 ist etwas grenzwertig, da mit sicherheit viele Systeme mit einem I965 nicht sofort bei Erscheinen des Chips sondern in der Zeit danach gekauft wurden, was natürlich auch entsprechend für die Vorgängergeneration gilt. D.h. gibt es vermutlich viele I945 Systeme die z.B. noch 2007 gekauft wurden, und somit "gefühlt" nicht so alt sind. Das sollte man auf jeden Fall auch bedenken.
Ich glaube zwar auch, dass der Schnitt mit Qt5/KDE5 erfolgen sollte, hoffe aber auch, dass nicht so viele betroffen sind, da unter Linux ja gerne auch mal alte Hardware genutzt wird, gerade weil diese noch unterstützt wird.
Allerdings glaube ich auch, dass diese Ausnahmen auch gut mit LXDE oder anderen schlanken DEs auskommen können.
Ich bin mit meinem I965 Laptop und meiner NV 7600GT im Desktop zum Glück nicht betroffen ... noch nicht
Also selbst wenn (und nur wenn) wir OpenGL 1.x Code entfernen stehen weiterhin Effekte zur Verfügung mit Ausnahme derer, die sowieso nicht auf der Hardware unterstützt würden.
Ich weise an dieser Stelle noch einmal darauf hin, dass es keine Pläne für ein "KDE5" gibt. Wie in meinem Blogpost erwähnt, werden wir mit Qt 5 sowieso die Unterstützung von OpenGL 1.x Code entfernen müssen. Ich erwarte dass KWin mit 4.10 oder 4.11 auf Qt 5 umsteigen wird.Was mich mal interessieren würde: Kann man über ein kleines Tool, wie es z.B. LinuxCounter benutzt, in etwa grob herausfinden, wieviel Prozent der KDE-User denn tatsächlich davon betroffen wären?
Wie sollte so etwas zu einem zuverlässigen Ergebnis führen?
Wenn du eine Lösung hast wie man überhaupt rausfindet, wie viele Nutzer wir haben und was für Hardware, welche Option und so weiter, wären wir sehr daran interessiert.
Also nein, das bringt leider gar nichts.
viele Laptop benutzer die wie noch einen schleppi mit 945 grafik haben
Aber bestimmt nicht mit der neusten Distribution.
Ich finde es gut das Altlast entfernt wird. Ich selbst habe einen altes Laptop mit einem SIS Chipsatz und mit einer aktuellen Distributionen gibt es sowieso nur Performanceprobleme zusätzlich würde ich auf so einer alten Hardware keine Gnome oder KDE betreiben.
Man muss nun mal nach vorne schauen und nicht jede alte Sache mit schleppen, welche nur mehr Arbeit kostet und die Entwicklung neuerer Features für die Mehrheit bremst.
Einfach weg damit.
Jup, das find ich auch!
Das hier sind Statistiken zu Grafikhardware:
> http://bsdstats.org/bt/devices/class/03/subclass/00.html
Erfasst werden die mit:
> http://www.freshports.org/sysutils/bsdstats/
Die Verwendung von bsdstats ist natürlich freiwillig.
Sieht zumindest bei den BSDlern nicht so aus, als würden die jedes Jahr los rennen wollen, um sich neue Hardware zu kaufen.
Das kann Apple ja machen wie sie lustig sind, so lange die Käufer das mitmachen, aber genau solch einem Diktat zum Neukauf wollen die Anwender freier Software offensichtlich wohl eher nicht.
Hast Du keinerlei Befürchtung, dass vielleicht 50% Eurer ATI-Nutzer keine Lust haben werden, ihre neuen und nagelneuen Radeon-Chips mit dem im Vergleich zu fglrx langsameren radeon-Treiber zu betreiben, d.h. ihren Treiber downzugraden?
Fglrx-Nutzer setzen ja gerade keine alte oder obsolete Hardware ein. Sie wollen ihre neuen Radeons unter Linux ausreizen. Das funktioniert mit radeon nicht.
Wenn das aber alles nicht so wichtig für KDE4 ist, dann raus mit OpenGL 1.x.
Ich verwende ein Dell Latitude D620 mit GMA945, auf dem KDE 4 hervorragend läuft. GMA945 wurde auch für viele Netbooks verbaut, die bis zur letzten oder vorletzten Atom Generation verbaut wurden. Zumindest für die Netbooks dürfte llvmpipe keine Alternative sein, da die Rechenleistung eh schon bescheiden ist und für die Grafik nicht noch ein Großteil dabei flöten gehen sollte, die müssten also alle auf XRender umstellen. Man kann aber auch z.B. Debian 7 installieren, sobald das rauskommt, damit hat man sicher noch ein KDE das mit OpenGL 1.x kann und das vermutlich bis 2015 gepflegt wird.
Mich persönlich juckts jetzt nicht so sonderlich, mein D620 hat nen Lüfter mit Lagerschaden und ich hoffe dass es noch durchhält bis die Ivy Bridge CPUs rauskommen, dann ist ein neues fällig und damit hab ich in Zusammenarbeit mit Mesa 8 dann sogar OpenGL 3.
Die Frage ist natürlich, ob bei so alter Hardware die Effekte nicht einfach abgeschaltet werden sollten. Auf meinem X40 Tablet läuft KDE4.8 super, solange man in der Xorg.conf XComposite komplett abschaltet.
Ein Notebook wie der Dell Latitude D620 mit Dualcore CPU um die 2GHz, 3GB RAM und Intel 945GM Grafik ist doch wirklich leistungsstark genug für die üblichen Anwendungen. Von alter Hardware würde ich hier nicht sprechen wollen.
Bisher läuft auch Compositing unter KDE4 schnell und problemlos. Sobald das gegen eine langsame Softwareemulation ersetzt wird ist Compositing praktisch nicht mehr nutzbar und damit sind die wenigen Usability-Vorteile von KDE4 dahin.
man kann auch Kubuntu 12.04 verwenden. Das kommt mit 4.8 und wird fünf Jahre unterstützt - also bis 2017.
Danke für die Klärung.
"KDE5" hätte ich besser in Anführungszeichen geschrieben ... oder vielleicht nur Qt5 gesagt, weil das ist was ich eigentlich meinte ... oder vielleicht Qt5/Wayland.
IMO hast Du viel zu viel um den heißen Brei herumgeredet:
Die alten DRI1-Treiber und -Grafikchips haben sowieso bald keinerlei 3D-Unterstützung mehr, damit ist unter Linux ab Mesa 8.0 nichts mehr "Hardwaremäßiges" da, was mit OpenGL zusammenarbeiten darf. Selbst XAA wurde entfernt, damit verlieren viele alte Grafikchips auch noch ihre 2D-Hardwarebeschleunigung. Die alten Grafikchips sind somit ohnehin "tot". Deshalb wird empfohlen, in Zukunft shadowfb zu benutzen.
Allerdings ist die Llvmpipe für Systeme unter einem Dual-Core sehr wahrscheinlich keine gangbare Alternative, das System wird praktisch "stehen". Du brauchst Dir ja nur einmal zu überlegen, in was für Rechnersystemen diese alten Grafikchips stecken.
So wie ich das verstanden habe, sind aber auch auf KMS/DRI2 portierte Grafikchips wie z.B. die Radeon 7500 und Geforce4MX von dieser Aktion betroffen. Wenn KWin mit diesen Chips nicht mehr funktioniert, dann kann man ja z.B. auf Openbox ausweichen oder KDE3 benutzen oder eine alte Distro weiterverwenden (SL5, CentOS5).
Mit diesem verstärkten Setzen auf reine CPU-Power (Llvmpipe) sehe ich in punkto freie Grafiktreiber lausige Zeiten auf uns zu kommen. Wenn Nouveau dann halt wieder einmal nicht funktioniert, dann soll man doch bitte die CPU zur Grafikverarbeitung nutzen, die GPU dreht dann halt Däumchen.
Typische Kandidaten für die Llvmpipe sind starke Rechner z.B. mit Quadcore-CPUs. Wenn man also einen NVidia- oder Radeon-Chip im Rechner hat, der von Linux nur mit Vesa unterstützt werden würde, dann kann man von den "3D-Features" dieser Llvmpipe profitieren und Gnome3 wird - z.B. mit heiß laufendem Notebook - zufriedenstellend in Pseudo-3D-Pracht laufen.
Llvmpipe ist aber nichts für alte Systeme, es fehlt schlichtweg die CPU-Power. Diese Illusion sollte man nicht unnötigerweise erwecken oder aufrechterhalten.
Es ist halt immer die Frage, ob einen alte Zöpfe wirklich Zeit kosten. Meinethalben kann man den OpenGL 1.x-Support ja deaktivieren aber drin lassen. Wer dann auf ihn angewiesen ist, muss Bugs darin fixen. Es ist in der Softwareentwicklung ohnehin illusorisch, sicherstellen zu wollen, das sämtliche unterstützten Szenarien funktionieren und bei der Weiterentwicklung berücksichtigt werden.
lg
Erik
lg
Erik
Die "binärkompatibilität" kann dir doch völlig wurscht sein solange nur der Compile angeworfen werden muss - Oder hast du schon mal eine Binär-Distribution gesehen die bei enem KDE-Update alte und neue Binaries mischt?
Darüber hinaus mag nicht immer jeder Anwender einer In-House-Lösung in der Lage sein, diese aus dem Quellcode zu bauen, nur, weil seine Distribution die darunter liegenden Qt- oder KDE-Versionen aktualisiert hat.
Deshalb haben das KDE-Projekt und Qt bislang großen Wert darauf gelegt, innerhalb einer Major-Version binärkompatibel zu bleiben. Den aRts-Soundserver hat man deshalb durch die gesamte KDE3-Linie geschliffen, obwohl man sich seiner technischen Schwächen schnell bewusst war. Das man diesen Grundsatz jetzt offenkundig aufgegeben hat, mag man als Anwender mögen oder nicht, Konsequenzen hat es jedenfalls.
lg
Erik
Schaltet man Compositing aus, verliert man aber auch die wenigen Usability-Vorteile die KDE4 gegenüber KDE3 oder anderen Desktops überhaupt aufweist.
Benutzt das jemand? Überall wo ich es bisher getestet habe ist es mir zu langsam, so dass ich freiwillig auf Compositing verzichte.
Ob die OpenGl 1.x Ünterstützung fällt oder nicht ist m.E. für den Benutzer unwichtig. KDE 4.8 läuft jedenfalls auf meinem sieben Jahre alten Sempron und einer via-chrome onboard Grafikkarte und 1 GB RAM schnell genug.
Wenn KDE nicht benutzt wird, hat dies andere Gründe als die der Grafikkarte. Bei mir ist es z.B. der Arbeitsspeicher. Die Webbrowser fressen mit jedem Tab immer mehr Speicher. Da ich meine Arbeitsweise nicht ändern will, benutze ich icewm. Denn damit steht meinem Webbrowser von Anfang an mehr RAM zur Verfügung.
Mit anderen Worten, es ist für mich unerheblich, wie sehr sich die Entwickler bemühen, ich werde auf diesem Rechner gründsätzlich kein KDE mehr benutzen.
PS: Ich werde mir bald einen neuen Rechner anschaffen und dann auch wieder KDE benutzen.
Der Intel GMA 950 ist in Massen in Netbook und in Nettops typischerweise mit der 2 Watt Intel Atom CPU n270 verbaut. Bürocomputer benutzen den Intel GMA950 auch ganz gerne.
Wenn erst ab dem i965 Chipsatz mit der Intel GMA 3000 der Betrieb möglich sein soll, dann wird da wirklich der Ruf der Alternativen zu Windows massiv geschädigt. Der Intel GMA 950 zieht zwar nicht die Wurst vom Teller, KDE4x ist aber mal damit fröhlich gelaufen, auf meinem Netbook und auf meinem Nettop.
Wäre wirklich nett, wenn KDE und die Grafikunterstützung den Usern nicht kaputt gemacht würde.
1. XRender soll noch unterstützt werden.
2. sieht es nach einem Kommentar von Kenneth Graunke gar nicht mal so schlecht für diesen Chipsatz aus:
http://blog.martin-graesslin.com/blog/2012/02/the-costs-of-supporting-legacy-hardware/
Der Kommentar von Kenneth Graunke (hier als Link direkt auf den Kommentar) ist wirklich interessant! Damit wären die Intel-Grafikchipsätze GMA 900, GMA 950, GMA 3000 und GMA 3100 abgedeckt und von der Änderung nicht betroffen. Das halte ich insofern für wichtig, da z.B. der GMA 3100 noch 2009 verkauft wurde.
SLI wurde nie unterstützt und das was da war, war selbst bei nur einem Kern nur etwa 70 % so schnell wie der Windows Treiber.
Und was ist jetzt?
Jetzt ist die ganze Karte obsolete, weil der Rest auch noch rausgeschmissen wird.
Denn es betrifft ja nicht nur KWin, sondern vor ein paar Tagen gab's ja hier auch ne Meldung wegen X.ORG wo auch Zeugs rausgeschmissen wird.
Fazit:
Closed Source Treiber des Herstellers sind sinnvoller, denn die funktionieren wenigstens von Anfang an schnell und bieten alles was die Karte kann und ehe der Support dafür eingestellt wird, kauft man einfach ne neue Karte.
Denn die Warteei auf gute Open Source Treiber bringt ja auch nichts wie man sieht und Alttechnologie wird auch im Linux Umweld irgendwann obsolete.
Ach ja, die Voodoo 5 war schon von Anfang an sehr gut dokumentiert.
Die Glide Lib ist auch Open Source, da steckt das ganze Know How drin.
Es gab also keine Ausrede für die OS Entwickler, daß sie keine Doku dafür hätten.
Immer dieses Gejammer.
Die Voodoo-3D-Treiber unter Linux sind vollkommen freie 3D-Treiber, an der sich selbst nouveau noch eine Scheibe abschneiden kann, wenn manche modernste Nvidiagrafikkarten damit nur ohne 2D- und 3D-Hardwarebeschleunigung funktionieren.
Insofern sind die tdfx-Treiber ein Verlust.
"Closed Source Treiber des Herstellers sind sinnvoller"
Du meinst die nicht vorhandenen Closed Source-Voodoo-Treiber des im Jahre 2000 untergegangenen Voodooherstellers 3Dfx?
Frage doch mal bei Nvidia nach, die haben den Laden damals gekauft.
Und wie sinnvoll diese merkwürdige OpenGL 1.x-Abhängigkeit der fglrx-Treiber ist, sieht man ja jetzt.
Game Over (zunächst nur unter KDE4) für proprietären Krempel.
Da lacht mein FSF-Herz.
Trotzdem würde ich eine Entscheidung, die KDE4 mit fglrx inkompatibel macht, davon abhängig machen, wieviel KDE4-Radeon-Nutzer denn überhaupt fglrx einsetzen. Sind es mehr als ein Drittel, würde ich die angesetzte OpenGL 1.x-Axt ganz schnell wieder verschwinden lassen.
Noch schlimmer als das Benutzen unfreier Software ist es, treue Nutzer vor den Kopf zu stoßen. Die fglrx-Treiber sind normalerweise zigmal schneller als ihre radeon-Pendants (nicht mit KDE4-Effekten, wohl aber im Zusammenspiel mit richtig fordernden OpenGL-Programmen).
Da haben wir wieder diese schreckliche Fratze, nämlich die offene Linuxdrohung mit einem Verschlechterungsupgrade.
Also, liebe KDE4-Entwickler: Macht doch bitte eine Umfrage!
Im übrigen kann es sogar sein, dass es für einige Voodoo- und auch Matroxgrafikkarten vielleicht sogar irgendwann einmal einen richtigen KMS-Grafiktreiber geben wird. "3D" ist allerdings in Zukunft weg, die Grafikchips sind mittlerweile einfach zu alt. Ihre Hardware-3D-Fähigkeiten passen nicht in die geplante, neue Wayland-/DRI2-/Gallium3D-Welt.
Nichtsdestotrotz gibt es immer noch zwei mögliche, partielle Rettungszenarios:
1. Ein Xorg-Entwickler erbarmt sich eines Grafiktreibers und flickt ihn als Nichtmaintainer provisorisch zusammen (z.B. tdfx).
2. Ein großer kommerzieller Distributor ist mit großen "Beständen" noch eingesetzter Legacy-Grafikchips in bestimmten Segmenten konfrontiert und muss sich aus Profitgründen zwangsweise darum kümmern (z.B. mga).
Nö, ich meine damit hauptsächlich das Marktangebot im Gesamten.
Also die beste Lösung an Grafikkarten für Linux mit ausgezeichneten Treibern wenn die Karte neu ist und das war schon immer NVidia mit seinen closed source Treibern.
Die TDFX Treiber wurden übrigens von 3dFX mitentwickeln, dafür hatte 3dFX extra Entwickler abgestellt und als 3dFX dann hopps ging, gingen die Entwickler auch und an SLI wurde nicht mehr weitergearbeitet.
Die Open Source Community hat dann an SLI auch nichts mehr gemacht bzw. das in den Griff bekommen, das will ich damit sagen, daß man sich hier auf die Open Source Community nicht verlassen kann.
Denn möglich wäre es gewesen, die OS Community hatte alle Daten die für SLI notwendig gewesen wären.
Tja siehste und genau da liegt das Problem.Ne GPU hat man normalerweise, damit die 3d Grafik Berechnung schnell geht.
OS Treiber waren schon immer langsamer und reduzierten die eigentliche Leistungsfähigkeit der GPU drastisch. Bei der VSA-100 wie bereits gesagt auf 70 %, während die NVidia Treiber immer bei fast 100 % liefen im Vergleich zu den Windowstreibern gesehen.
Ja, leider und genau das ist ja auch der Grund, warum man bei GPUs nicht auf Open Source setzen kann.
Man muß das nehmen, wo es die schnellste Treiber für die aktuelle HW gibt und damit wären wir bei NVidia CS.
Es bringt einfach nichts hier aus ideologischen Gründen auf OS zu setzen und dann > 5-10 Jahre warten, bis die GPU endlich ausgereizt werden kann, denn am Ende stellt man fest, daß der ganze Support trotzdem über Bord geworfen wird und man nie auf die maximale Geschwindigkeit (oder auch Features) die auch unter Win geboten wurde herankam.
Und genau dieses Faktum, die Einstellung des Supportes bei Open Source Treibern relativiert auch die Einstellung des Supportes bei Closes Source Treiber, daher ist das kein Manko, wenn NVida Karte XY nach X Jahren nicht mehr unterstützt, denn bei Open Source Treiberkarten fällt die Unterstützung ja auch weg.
Und BTW, meine Geforce 4 läuft auf meinem Ubuntu LTS noch und die Karte konnte von Anfang an ausgereizt werden.
Daher sage ich ja, bei Grafikkarten gilt closed source only, weil besser.
Es ist bei GPUs einfach ein Märchen, daß man mit Open Source den besten Support, das Beste Bugfixing, die Beste Funktionalität und das auf fast ewig (für Computerverhältnisse) bekommt.
Bei anderer HW mag das anders aussehen, aber bei GPUs ist Closed Source in jeder Hinsicht überlegen.
Tja.
Ich persönlich habe da schon längst kapituliert.
Ich benutze strikt Debian Main und unter Squeeze ist das mit einer Radeon- oder Nvidia-Karte gleichbedeutend mit Computer-2D-Steinzeit.
Und dass ich zukünftig anfange, KDE4 oder Gnome3 in reinem Software-3D ohne tatsächliche 2D- und 3D-Hardwarebeschleunigung zu nutzen, das fällt mir nicht im Traum ein.
Ich gehe auch davon aus, dass PIII- und PIV-Single Core-CPUs für die Llvmpipe zu langsam sein werden.
Diese Llvmpipe ist IMO real gewordene, hochgradige Verzweiflung angesichts dieser unfassbar unfreien Grafikhardwarelandschaft und sie ist auch nichts anderes als die Konsequenz aus Deiner ziemlich richtigen Analyse: Red Hat und Co. wissen, dass die freien radeon- und insbesondere die nouveau-Treiber es nie mit ihren unfreien Pendants werden aufnehmen können und dass es im freien Grafiktreiberbereich immer Unterstützungsprobleme geben wird, also trifft man eine Vorsorge, die zumindest auf neuen Rechnersystemen als Fallback mit ultraschlechter Performanz (im Vergleich zu den Fähigkeiten der eingebauten GPU) funktioniert. Jedenfalls sind unter Linux die Fähigkeiten von CPUs um einiges besser nutzbar als die meisten de facto "verbotenen" und unzugänglichen GPU-Features.
Natürlich ist es auch richtig, dass KDE4 nicht für zehn bis fünfzehn Jahre alte Grafikhardware entwickeln kann, vor allem dann nicht, wenn Xorg und Mesa für diese alte Hardware praktisch den Support einstellen. Der Vorschlag, im 2D-Bereich einen solchen alten Grafiktreiber ohne 2D- (und 3D-) Hardwarebeschleunigung, dafür aber mit shadowfb zu benutzen, heißt nichts anderes.
Besser wäre der Ratschlag, auf älteren Systemen z.B. RHEL5 oder einen RHEL5-Klon zu verwenden, mit Support bis 2017 für einen älteren Xorg und ein älteres Mesa, das DRI1-Grafikchips ganz gut unterstützt.
KDE4 und Gnome3 sind definitiv nichts mehr für alte (Grafik-)Hardware.
Kontraproduktiv ist auch, dass Linux angefangen hat, an den Grundlagen des unfreien fglrx- und nvidia-Supports herumzusägen.
Wenn das mal nicht nach hinten losgeht.
Also ich komme mir ganz besonders bei den freien Treibern vor den Kopf geschlagen vor.
Stichwort Intel GMA 950, die in Massen in Notebooks und in Netbooks, sowie in Bürocomputern verbaut ist.
Mit der Intel GMA 950 hat man sich komplett auf freie Grafiktreiber verlassen und muss nun entsetzt feststellen, dass dies einen riesige Fehlentscheidung war.
Vor allem kann man auch in Netbooks und in Nettops die Intel GMA 950 nicht austauschen, so wird gleich der ganze Computer als Desktop System unbrauchbar gemacht, durch die Entscheidung die Unterstützung für OpenGL für diese Chipsätze zu zerstören.
Zu gut deutsch, da wird zehntausenden von Usern Leid zugefügt. Da wird mit Gewalt der Ruf von OpenSource Software zerstört.
Auf das jeder deutlich merken soll, das OpenSource Software unzuverlässig ist?
Nur in bezug auf KDE4.
Ich kann mir nicht vorstellen, dass eine Unternehmensdistro mit ihrem Unternehmensstandarddesktop (meist ist das Gnome) ähnlich verfährt.
Das Wichtigste aber vorweg:
Du musst beachten, von was für einem Zeitfenster der KWin-Entwickler da spricht, es geht nicht um KDE4/Qt4/KDE4-Kwin, es geht um KDE5/Qt5/KDE5-Kwin.
Weder das bis 2017 unterstützte Ubuntu 12.04 werden davon betroffen sein, noch RHEL6/SL6/CentOS6 mit Support bis 2020 und höchstwahrscheinlich noch nicht einmal SLES12/SLED12 mit ähnlich langem Support.
Bis 2017/2020 sollten sich die Unkosten für Dein Intel-Notebook aber amortisiert haben.
Im übrigen kann ich Dir nur raten, frühzeitig Bugreports in der Betaphase einer Distributionsentwicklung abzusetzen, damit vermisste Funktionalität zumindest als optionales Etwas wiederhergestellt wird.
Distros wie openSUSE/Suse und Fedora/Red Hat sind dafür am Geeignetsten, weil sich die Entwickler sehr gut mit der Materie auskennen und nicht selten dafür auch bezahlt werden.
Du erhältst dann eine klare Ansage: O.k., das können wir einbauen bzw. optional anbieten oder aber das geht aus dem und dem konkreten Grunde nicht.
Die Catalystgeschichte muss allerdings in den AMD-Bugtracker. Auch hier kann man eine klare Aussage erwarten. Ergänzend dazu kann es sich lohnen, in bestimmten Foren herumzuposten (u.a. Phoronix) und AMD-Leute wie "bridgeman" zu fragen, vor allem im Hinblick auf technische (Machbarkeits-) Fragen.
Zudem sind bestimmte Distros eher konservativ:
Selbst wenn Du Dir heute ein aktuelle, sehr moderne openSUSE (also nicht nur SLES/SLED) anschaust, dann findest du überall Kompatibilitätsbibliotheken und Legacy-Xorg-Module, wie z.B. intellegacy und nv. Debian z.B. lässt nv zwar aus eher ideologischen Gründen (ab Wheezy) verschwinden, eine eher unternehmensorientierte Distro wird sich da tunlichst davor hüten.
Ein weiteres Beispiel ist das openSUSE-Cups-Zusatzprogramm "parallel-printer-support" bzw. demnächst ein entsprechendes Modul für das kommende Cups 1.6. Übrigens war der Auslöser für dieses Projekt der Bugreport eines Administrators eines Schulcomputernetzes, dessen Parallel Port-HP Office-Jets plötzlich nicht mehr druckten. Die haben schlichtweg kein Geld für neue Drucker.
Übrigens:
Laut einem Kommentar unter
http://blog.martin-graesslin.com/blog/2012/02/the-costs-of-supporting-legacy-hardware/#comments
läuft KWin mit OpenGL2-Shadern:
http://blog.martin-graesslin.com/blog/2012/02/the-costs-of-supporting-legacy-hardware/comment-page-1/#comment-46365
Ein NB mit einem Pentium M oder besser und 2 GB RAM reicht locker für alle heutigen Office und Surfausgaben aus und das wird auch in 2017/2020 noch der Fall sein, weil zu Officeprogrammen auch nicht mehr so viel neues hinzukommt, was Leistung fressen würde.
Insofern bedeutet KDE 5 also für diejenigen, daß man eine gute funktionstüchtige Hardware wegschmeißen muß, nur damit KDE 5 läuft. Und KDE 4 wird dann ja wohl kaum weitersupported werden.
Deswegen halte ich die Entscheidung den Support für diese alte HW rauszuschmeißen für falsch.
Denn Leistungsfähig ist diese alte Hardware für normale Office und Surfaufgaben immer noch mehr als genug.
Ubuntu hat den Support für die Glide Library bei ca. Ubuntu 6.10 rausgeschmissen und die libglide ist GPL.
Ohne Glide Library gibt's keine 3d Unterstützung für Voodoo Banshee, 3, 4 und 5 Karten.
"Ubuntu hat den Support für die Glide Library bei ca. Ubuntu 6.10 rausgeschmissen und die libglide ist GPL.
Ohne Glide Library gibt's keine 3d Unterstützung für Voodoo Banshee, 3, 4 und 5 Karten."
Keine Ahnung, was Ubuntu da gemacht hat.
In anderen Distros sind die notwendigen OpenGL-Libs noch enthalten.
Z.B. in Debian Squeeze:
http://packages.debian.org/squeeze/libglide2
http://packages.debian.org/squeeze/libglide3
Ich habe in einem Rechner noch eine uralte Voodoo Banshee verbaut, die funktioniert mit libglide3 in "3D" (16bit-Farbtiefe).
Was KDE5-KWin anbelangt:
Du musst die alte Hardware nicht wegschmeißen, Du kannst dann wahrscheinlich nur keinen 3D-KDE5 mehr benutzen, "nur" eben einen 2D-KDE5 mit normalem 3D für die üblichen OpenGL-Programme oder auch mit Xrender.
Ja, genau das ist das Problem von Open Source Treibern.
Mein Notebook ist aus dem Jahre 2005 und besitzt zum Glück eine NVidia Geforce 6600 Go und die closed source Treiber laufen immer noch auf aktuellen Distributionen und das sie super performant sind und die Stromsparmodi der GPU unterstützen muß ich ja nicht noch extra erwähnen.