GEM / KMS für Intel in FreeBSD 10-CURRENT commitet
- Ersteller Yamagi
- Erstellt am
Wir hatten die Diskussion ja schon öfter... Aber dennoch. Die aktuelle Entwicklung bestätigt doch genau das, was absehbar war. Alle Systeme außer Linux sind praktisch chancenlos, was Grafiktreiber betrifft und es gibt direkt keine Möglichkeit daran etwas zu ändern:
1. Man kann den Linux-Code portieren. Aber es ist nahezu unmöglich oder zumindest extrem aufwändig. Der aktuelle KMS-Port hat schließlich nahezu 18 Monate gedauert, einen Entwickler in Vollzeit beansprucht und perfekt ist er noch bei weitem nicht. Und hat man endlich eine Reife erreicht, dass man den Code mit etwas Wohlwollen produktiv nutzen kann, wird wieder alles über den Haufen geworfen und von vorn begonnen. Das von Linuxern oft vorgebrachte Argument, dass der Code offen sei und ja übernommen werden kann, zählt daher nicht. Er ist einfach nicht portabel genug!
2. Man könnte natürlich die Grafiktreiber forken und eine "Nicht-Linux-Branch" ins Leben rufen. Aber wie sollte das gehen? Man bräuchte entsprechende Entwickler und die fallen nicht vom Himmel. Vor allem aber, gibt es in den meisten Fällen nur Code und keine Doku. AMDs Doku ist ohne Beispielcode (vor allem ohne einen Shadercompiler) nahezu sinnlos, nicht umsonst entwickelt AMD inzwischen seine freien Treiber weitgehend selbst, bzw. in sehr enger Zusammenarbeit mit den restlichen Entwicklern. Für Intel gibt es dann auch gleich so gut wie gar keine Doku. Das Linuxer-Argument ist nun, dass ja der Code die Doku sein, aber allein diese Aussage disqualifiziert jeden Teilnehmer einer Diskussion als ahnungslos. Code war nie Doku, Code ist keine Doku und Code wird nie Doku sein. Er kann höchstens Doku unterstützen.
Was machen wir also? Das Spielchen weiter mitzuspielen und munter Portierungen zu versuchen ist gescheitert. Man muss die Strategie wechseln. Im einzelnen ist FreeBSDs beste Chance im Moment:
1. Wir FreeBSDler müssen uns Nvidia warm halten, denn ohne deren Blob geht nichts.
2. Wir sollten versuchen AMD zu überzeugen einen "Catalyst for FreeBSD" zu bauen.
3. Wir sollten Intels GPU-Team animieren, FreeBSD explizit zu unterstützen
1. Man kann den Linux-Code portieren. Aber es ist nahezu unmöglich oder zumindest extrem aufwändig. Der aktuelle KMS-Port hat schließlich nahezu 18 Monate gedauert, einen Entwickler in Vollzeit beansprucht und perfekt ist er noch bei weitem nicht. Und hat man endlich eine Reife erreicht, dass man den Code mit etwas Wohlwollen produktiv nutzen kann, wird wieder alles über den Haufen geworfen und von vorn begonnen. Das von Linuxern oft vorgebrachte Argument, dass der Code offen sei und ja übernommen werden kann, zählt daher nicht. Er ist einfach nicht portabel genug!
2. Man könnte natürlich die Grafiktreiber forken und eine "Nicht-Linux-Branch" ins Leben rufen. Aber wie sollte das gehen? Man bräuchte entsprechende Entwickler und die fallen nicht vom Himmel. Vor allem aber, gibt es in den meisten Fällen nur Code und keine Doku. AMDs Doku ist ohne Beispielcode (vor allem ohne einen Shadercompiler) nahezu sinnlos, nicht umsonst entwickelt AMD inzwischen seine freien Treiber weitgehend selbst, bzw. in sehr enger Zusammenarbeit mit den restlichen Entwicklern. Für Intel gibt es dann auch gleich so gut wie gar keine Doku. Das Linuxer-Argument ist nun, dass ja der Code die Doku sein, aber allein diese Aussage disqualifiziert jeden Teilnehmer einer Diskussion als ahnungslos. Code war nie Doku, Code ist keine Doku und Code wird nie Doku sein. Er kann höchstens Doku unterstützen.
Was machen wir also? Das Spielchen weiter mitzuspielen und munter Portierungen zu versuchen ist gescheitert. Man muss die Strategie wechseln. Im einzelnen ist FreeBSDs beste Chance im Moment:
1. Wir FreeBSDler müssen uns Nvidia warm halten, denn ohne deren Blob geht nichts.
2. Wir sollten versuchen AMD zu überzeugen einen "Catalyst for FreeBSD" zu bauen.
3. Wir sollten Intels GPU-Team animieren, FreeBSD explizit zu unterstützen
h^2
hat ne Keule +1
Eine Entschuldigung gabs immerhin:
http://www.phoronix.com/scan.php?page=news_item&px=MTE5MDM
Trotzdem muss ich auch mal kritisch an das FreeBSD-Lager fragen: Kommuniziert der Typ, der die Sachen portiert eigentlich mit Intel upstream? Wenn ja, müsste er dann nicht frühzeitig einen Hinweis bekommen haben, dass alles was er da gerade auf FreeBSD-kernel umstrickt bald deprecated wird?
Warum sagt er dazu nichts? Und was ist jetzt der Plan? Auf neuen Intel-Code umsteigen oder einen nicht mehr weiterentwickelten eigenen Intel-Branch fahren?
darktrym
Fahnenträger
Intel ist keine kleine Klitsche, auch ist Intel guter Linux Support sehr wichtig.
Eine ganze Abteilung arbeitet für den Linux Support.
FreeBSD allen voran der Desktop ist unter den Nischen selbst eine Nische.
Und der Linux Desktop ist ja bekanntlich alles andere als planbar, nun will man auch noch DRI3 entwickeln.
Eine ganze Abteilung arbeitet für den Linux Support.
FreeBSD allen voran der Desktop ist unter den Nischen selbst eine Nische.
Und der Linux Desktop ist ja bekanntlich alles andere als planbar, nun will man auch noch DRI3 entwickeln.
So wie sich der Kommentar des Intel-Entwicklers liest, war sein "sorry" mehr ein "schade" denn ein "Entschuldigung".
Hat sich jemand seinen 40-minütigen Vortrag angeschaut? Falls FreeBSD erwähnt wird, würde mich die Stelle interessieren.
Als Softwareentwickler kann ich seine Position nachvollziehen; es liest sich eher wie ein übliches Refactoring:
Er legt auch gleich den Finger in die Wunde:
Ich glaube kaum, dass Intel hier in die Bresche springt.
darktrym
Fahnenträger
Der Typ ist aber auch ein Spaßvogel.
Bei Intel arbeiten dutzende Leute am Intel DRM Kram.
Dazu kommen noch andere freie Commiter.
Dann noch einige von Wayland/X.ORG und den Subprojekten wie Tizen, Android-x86.
Kein Wunder das man Langeweile verspürt und aus Pflicht einen Arbeitsnachweis zu erbringen, Refactoring betreibt. Den reicht ja nicht eine Baustelle, die machen lieber gleich 2(DRI3, DRM2) neue auf. XLIB und GLX soll ja auch aus X fliegen.
Bei Intel arbeiten dutzende Leute am Intel DRM Kram.
Dazu kommen noch andere freie Commiter.
Dann noch einige von Wayland/X.ORG und den Subprojekten wie Tizen, Android-x86.
Kein Wunder das man Langeweile verspürt und aus Pflicht einen Arbeitsnachweis zu erbringen, Refactoring betreibt. Den reicht ja nicht eine Baustelle, die machen lieber gleich 2(DRI3, DRM2) neue auf. XLIB und GLX soll ja auch aus X fliegen.
Zuletzt bearbeitet:
Dafür gibt es in großen Unternehmen einfachere und weniger arbeitsintensive Methoden.
Refactoring ist unerlässlich. Wie hat er so schön geschrieben:
Was würdest du an seiner Stelle machen? Die Bugs nicht fixen und die Architektur so lassen?
darktrym
Fahnenträger
Bisher waren es immer Frickelprojekte wie Nouveau die alle paar Jahre ein fast kompletten Rewrite machten, aber die hatten keine Dokus und wussten nicht was da kommt.
Das färbt wohl auch auf Intel ab.
Auch die Bugs werden nur spärlich behoben.
War das nicht der Intel Treiber der die meisten Defekte hatte?
Der Support ist dann doch reichlich eingeschränkt.
Erst ab Sandy Bridge profitiert man von den neuen Entwicklungen, gott bewahre man besitzt doch noch ältere Sachen.
Clover Trail mit seinen PowerVR Kern geht wahrscheinlich mal wieder leer aus.
Da wird wie bei Poulsbo nichts investiert um mal anstädnige Treiber auf den Weg zu bringen.
Naja wenigstens entwickeln die nicht noch am Intel Gallium Treiber herum, zuzutrauen wäre es ihnen.
Das färbt wohl auch auf Intel ab.
Auch die Bugs werden nur spärlich behoben.
War das nicht der Intel Treiber der die meisten Defekte hatte?
Der Support ist dann doch reichlich eingeschränkt.
Erst ab Sandy Bridge profitiert man von den neuen Entwicklungen, gott bewahre man besitzt doch noch ältere Sachen.
Clover Trail mit seinen PowerVR Kern geht wahrscheinlich mal wieder leer aus.
Da wird wie bei Poulsbo nichts investiert um mal anstädnige Treiber auf den Weg zu bringen.
Naja wenigstens entwickeln die nicht noch am Intel Gallium Treiber herum, zuzutrauen wäre es ihnen.
Intel macht keinen Rewrite, nur ein stinknormales Refactoring. Eine überschaubare Änderung, die bei jedem Projekt dieser Komplexität ständig stattfindet; zumal ständig neue Hardware unterstützt werden muss.
Wie lange hatten nVidia und ATI (inzwischen AMD) gebraucht, um ordentliche Treiber auf die Beine zu stellen?
Wenn die Grafiktreiber-Entwicklung so trivial ist, dann kann es für einen FreeBSD-Entwickler ja nicht so schwer sein, einen Intel-GPU-Treiber mal eben nebenher in der Mittagspause zu entwickeln.
Meinst du Intels SNA (Sandy Bridge New Acceleration)? Ist dir bewusst, dass von SNA auch ältere Chipsetsunterstützt werden und diese davon profitieren?
Seit 2 Monaten ist SNA auch die Voreinstellung für alle GPUs im Intel-Treiber.
Intel unterstützt also mit seiner Neuentwicklung also sämtliche Hardware im Treiber, auch alle alten Sachen.
Nein: Intel plant Clover-Trail-Variante für Linux.
Clover Trail bekommt anscheinend die gleiche GPU wie die normalen Intel-CPUs, weswegen der Support kein Problem sein dürfte.
Poulsbo (d.h. der ursprüngliche Atom) hat keine GPU von Intel, sondern von Imagination Technologies (PowerVR); sie wurde nicht von Intel entwickelt, sondern zugekauft.
Intel darf dafür vertraglich gar keine Open-Source-Treiber herausbringen, sondern ist auf die Zulieferung von Imagination Technologies angewiesen. Von der Seite wird aber wohl nicht viel kommen.
Nein; Intel hat nie Gallium-Treiber veröffentlicht! Die Treiber kamen von Tungsten Graphics, die von VMware gekauft wurden.
Intel sagte schon vor längerer Zeit, dass in Zukunft alle Intel-Chips auch Intel-GPUs integrieren werden. PowerVR wird es nicht mehr geben. Das ist auch ganz logisch, schließlich hat man nicht unwesentliche Mengen in die Entwicklung einer halbwegs brauchbaren Low-End-GPU gesteckt, nur um weiterhin Produkte von Drittanbietern lizenzieren zu müssen.
http://www.pcper.com/reviews/Editor...ntel-Graphics-Ray-Tracing-and-Voxels-and-moreJohn Carmack schrieb:
darktrym
Fahnenträger
Wenn man an Konzepten dreht, die einen Haufen Änderungen nach sich ziehen, ist der Unterschied zum Rewrite nicht allzu groß. Die Änderungen im Modesetting haben nichts mit neurer Hardwareunterstützung zu tun. Mich nervt nur langsam das hier so getan wird, als ob andere OSe nicht nachziehen wollen. Natürlich können die nicht, kein Wunder wenn ständig Änderungen fabriziert werden, vorallem wenn schon bekannt ist, dass der Kernel so nicht lange Bestand haben wird. Wegen DRM2(GEM Split) müsste der Treiber ohnehin bald wieder überarbeitet werden, tiefere Integration von dma_buf(DRI3) ist auch nötig für Optimus. Es ist nicht besonders motivierend wenn eine Portierung mit Geld und Zeit verbunden ist, die die Intel Typen ja reichlich haben, nach 6 Monaten deutlich wird, dass man wieder in einer Sackgasse sich befindet. So schwer kann es nicht sein, wenigstens zwei Branches zu pflegen. Da muss ja nicht viel dran gemacht werden, nur die unterstützte Hardware nachziehen.
Klingt für mich wie eine Strategie. Vorallem bleibts dabei nicht, früher oder später müssen Fremdbibliotheken(libdrm, Mesa) eingefroren werden, was fehlende Updates bei Anwendungen nach sich ziehen. Das führt dazu das ständig das komplette System betroffen ist, statt nur fehlende Feature und alten Treibern. Ich sehn' mich an die Zeit zurück, wo X noch von Hause aus brauchbar war. Wieviele Grafiktreiber sind heute noch nutzbar?
Es ist gar nicht mal so aufwendig einen Treiber zu basteln, der wenigstens schlierenfreie Fensterschubsen(2D) ermöglicht(siehe r128, aufgepimpten Virtualisierungstreiber für Grafik). Für einige mal das ausreichen, mich einbegriffen. Das sollte aber auch Aufgabe von Hardwarehersteller sein, wenn sie schon die Landschaft vorsetzlich zertrümmern oder in Zukunft noch was verkaufen wollen. Und komme mir nicht mit vesa Qual-ität.Wie lange hatten nVidia und ATI (inzwischen AMD) gebraucht, um ordentliche Treiber auf die Beine zu stellen?
Wenn die Grafiktreiber-Entwicklung so trivial ist, dann kann es für einen FreeBSD-Entwickler ja nicht so schwer sein, einen Intel-GPU-Treiber mal eben nebenher in der Mittagspause zu entwickeln.
Sämliche schon gar nicht, die Priorität liegt schon bei Sandy Bridges und aufwärts. Und ob ich mit SNA 8,2 oder 8,4 FPS bekomme macht ehrlich keinen Unterschied, unbenutzbar ist es trotzdem.
Intel hat in der Tat irgendwas angekündigt, aber keiner weiß wie das gehen soll(billig Atom + teurer Grafik?). Interessanterweise hatte damals Intel verlautbart nicht mehr auf PowerVR setzen zu wollen. Für Smartphones/Tablets mag das jetzt wohl wieder akzeptabel sein, ich hatte irgendwie gehofft man kann sich auf Intels Wort verlassen. Auch denke ich das Intel keine kleine Chinabude ist, die kann, wenn sie will, entsprechend Druck ausüben. Bei Nvidia hat's ja auch geklappt, die werden Dokumente zu Tegra2/3 Grafik(!) veröffentlichen.
Hab ich auch nicht behauptet, nur Intel in Form von Daniel Vetter hat recht häufig commitet. Gallium3d und GEM sind 2 Versuche, den Entwicklungs- und Portierungsaufwand zu verringern.
h^2
hat ne Keule +1
Also ich verstehe hier schon die Aufregung, aber ich denke ernsthaft, dass FreeBSD anscheinend auch nicht immer super kommuniziert hat mit upstream. Man war halt von früher gewohnt, dass DRM out-of-kernel entwickelt wird und einfach zu portieren ist. Und man war den nvidia-binary-treiber gewöhnt, wo man nicht viel tun musste.
Jetzt haben sich die Strukturen zu unserem Nachteil verändert und einige Top-Leute, wie Eric Anholt, die früher FreeBSD user waren sind es nicht mehr. Dann hat man erstmal lange garnichts gemacht und gehofft es wird von alleine besser. Dann als die Strukturen schon komplett anders waren, man noch weniger beeinflussen konnte und der Portierungsaufwand riesig, und man anscheinend keinen Draht mehr hatte zu den upstream-Entwicklern hat man kib bezahlt irgendwas zu portieren.
Das hat er nun gemacht, anscheinend dabei aber nicht allzu viel mit upstream kommuniziert, zumindest wussten da anscheinend wenige, dass überhaupt was bei uns passiert. Jetzt haben wir einen veralteten Intel-Branch, der noch nicht mal default mit entsprechendem X ausgeliefert wird, keine Hoffnung auf funktionierende AMD-Treiber oder offene nvidia-Treiber und eine Entwickler der das ganze als Job umgesetzt hat, der wohl zeitlich befristet ist oder war.
Das heißt alles ist noch mehr im Arsch und es gibt keinen Plan, wie es besser werden soll, zumindest keinen Plan, der öffentlich kommuniziert würde.
Das ist bei aller berechtigter Kritik an allen anderen trotzdem ein mieses Fazit, vor allem für ein OS, dass sich ansonsten eher dem Pragmatismus, als dem Idealismus verpflichtet fühlt.
Jetzt haben sich die Strukturen zu unserem Nachteil verändert und einige Top-Leute, wie Eric Anholt, die früher FreeBSD user waren sind es nicht mehr. Dann hat man erstmal lange garnichts gemacht und gehofft es wird von alleine besser. Dann als die Strukturen schon komplett anders waren, man noch weniger beeinflussen konnte und der Portierungsaufwand riesig, und man anscheinend keinen Draht mehr hatte zu den upstream-Entwicklern hat man kib bezahlt irgendwas zu portieren.
Das hat er nun gemacht, anscheinend dabei aber nicht allzu viel mit upstream kommuniziert, zumindest wussten da anscheinend wenige, dass überhaupt was bei uns passiert. Jetzt haben wir einen veralteten Intel-Branch, der noch nicht mal default mit entsprechendem X ausgeliefert wird, keine Hoffnung auf funktionierende AMD-Treiber oder offene nvidia-Treiber und eine Entwickler der das ganze als Job umgesetzt hat, der wohl zeitlich befristet ist oder war.
Das heißt alles ist noch mehr im Arsch und es gibt keinen Plan, wie es besser werden soll, zumindest keinen Plan, der öffentlich kommuniziert würde.
Das ist bei aller berechtigter Kritik an allen anderen trotzdem ein mieses Fazit, vor allem für ein OS, dass sich ansonsten eher dem Pragmatismus, als dem Idealismus verpflichtet fühlt.
Das glaube ich nicht. FreeBSD auf dem Desktop ist zu unbedeutend und fällt einfach hinten runter (siehe unten).
Vermutlich die wenigsten. Die Anforderungen an die Grafik sind aber auch entsprechend gestiegen.
Anscheinend lohnt sich der Aufwand für "einige" nicht.
Wieviel Umsatz zusätzlich würden die Hersteller (egal ob Intel oder Imagination Technologies) mit vernünftigen FreeBSD-Treibern machen?
Wieviel Umsatz geht Ihnen durch die fehlende FreeBSD-Unterstützung verloren?
FreeBSD ist doch schon im Server-Bereich kommerziell unbedeutend, auf dem Desktop ist es eine Nische in der Nische.
Das liegt aber daran, das die alten GPUs einfach zu schwachbrüstig sind - unter Windows ist die 3D-Performance ja genauso unzureichend.
Warum sollte Intel sich auf juristische Streitereien einlassen, wenn sich der Aufwand und das Risiko nicht rechnet?
Im Gegensatz zu Intel bei PowerVR hat Nvidia in diesem Fall Kontrolle darüber, was sie veröffentlichen und was nicht.
h^2
hat ne Keule +1
Wie kann man unter einem 9.1-RELEASE das KMS ausschalten?
Ich habe die neuen XORG-Pakete installiert und xf86-video-ati-6.14.3_1. Laut allen mir vorliegenden Informationen unterstützt dieser ATI-Treiber noch UMS, wenn auch zu KMS defaultet.
KMS failt natürlich, nun ist die Frage, wie kann ich ihm sagen, dass er UMS machen soll? Unter Linux merkt der Treiber ob die Kernel KMS advertised und richtet sich danach. Gebe ich der Kernel ein "nomodeset" mit, advertised sie das nicht mehr und der Treiber schaltet auf UMS um. Wie kann ich der FreeBSD-Kenerle das sagen?
[jetzt sagt mir nicht, ich soll den alten Xserver nehmen, die verwendete Software sollte es auf jeden Fall noch hinkriegen und ich will vielleicht mit dem neuenKernelcode mal rumspielen]
edit: VESA tut stinken tun, ich sags euch!
Ich habe die neuen XORG-Pakete installiert und xf86-video-ati-6.14.3_1. Laut allen mir vorliegenden Informationen unterstützt dieser ATI-Treiber noch UMS, wenn auch zu KMS defaultet.
KMS failt natürlich, nun ist die Frage, wie kann ich ihm sagen, dass er UMS machen soll? Unter Linux merkt der Treiber ob die Kernel KMS advertised und richtet sich danach. Gebe ich der Kernel ein "nomodeset" mit, advertised sie das nicht mehr und der Treiber schaltet auf UMS um. Wie kann ich der FreeBSD-Kenerle das sagen?
[jetzt sagt mir nicht, ich soll den alten Xserver nehmen, die verwendete Software sollte es auf jeden Fall noch hinkriegen und ich will vielleicht mit dem neuenKernelcode mal rumspielen]
edit: VESA tut stinken tun, ich sags euch!
Zuletzt bearbeitet:
h^2
hat ne Keule +1
Für nouveau Leute gibts doch den Binary-Treiber -- zumindest als Übergangslösung bis TTM läuft. Und OpenChrome ist doch sicher noch langsamer als Software-Rendering auf einer aktuellen CPU...
Aber sollte der OpenChrome, nicht auch mit den 'neuen XServer' (ohne KMS) gehen?
Naja, mal wieder ein Konservatismus, den ich nicht verstehe. Besonders, weil der Maintainance overhead durch den extra XServer, plus die geringere Anzahl an Testern bei dem Neuen, ja auch letztlich die Entwicklung hin zu einem funktionierendem Setup für alle verlangsamt...