GEM / KMS für Intel in FreeBSD 10-CURRENT commitet

[Elwood]

3 Kommentare, 3 bsdforen.de-User

[h^2]

Ich würde da aber jetzt nicht zu stark abranten, sonst schaltet der einfach ab.

[darktrym]

phoronix:

- "New i915 modeset infrastructure code. My blog post about it caught the wrath of some *bsd guys so some explaining might be in order." This comes down to his massive re-write of the Intel driver mode-setting code, which is now not using the shared DRM code and thus might cause some extra pain for the BSD developers with their lagging DRM/KMS support.

[Yamagi]

Naja, immerhin... Mal schauen, ob es irgendwelche Konsequenzen mit sich bringt. Ich denke eher nicht...

[h^2]

Zitat von Yamagi

Naja, immerhin... Mal schauen, ob es irgendwelche Konsequenzen mit sich bringt. Ich denke eher nicht...

Eine Entschuldigung gabs immerhin:
http://www.phoronix.com/scan.php?pag...tem&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]

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.

[Azazyel]

Zitat von Yamagi

Naja, immerhin... Mal schauen, ob es irgendwelche Konsequenzen mit sich bringt. Ich denke eher nicht...

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:

Well, let me clarify a bit first: This patch set is not a complete rewrite of the modeset code, all the low-level hw-frobbing parts are still all the same. The code mostly just reworks the interfaces a bit and makes the logic that drives the modeset sequence intel-specific. And we need that, because with the current generic framework we flat-out can't fix a few bugs.

So this patch series isn't more work for porting than any other patch series, and if you can't keep up with the development pace of drm/i915 with porting, you have a serious problem no matter what.

Er legt auch gleich den Finger in die Wunde:

I guess that only leaves the issue that bsd simply has too few people working on low-level graphics drivers to sustain a porting effort. I can't really fix that ...

Ich glaube kaum, dass Intel hier in die Bresche springt.

[darktrym]

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.

[Azazyel]

Zitat von darktrym

Kein Wunder das man Langeweile verspürt und aus Pflicht einen Arbeitsnachweis zu erbringen, Refactoring betreibt.

Dafür gibt es in großen Unternehmen einfachere und weniger arbeitsintensive Methoden.

Refactoring ist unerlässlich. Wie hat er so schön geschrieben:

And we need that, because with the current generic framework we flat-out can't fix a few bugs.

Was würdest du an seiner Stelle machen? Die Bugs nicht fixen und die Architektur so lassen?

[darktrym]

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.

[Azazyel]

Zitat von darktrym

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.

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.

Zitat von darktrym

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.

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.

Zitat von darktrym

Erst ab Sandy Bridge profitiert man von den neuen Entwicklungen, gott bewahre man besitzt doch noch ältere Sachen.

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.

Zitat von darktrym

Clover Trail mit seinen PowerVR Kern geht wahrscheinlich mal wieder leer aus.

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.

Zitat von darktrym

Da wird wie bei Poulsbo nichts investiert um mal anstädnige Treiber auf den Weg zu bringen.

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.

Zitat von darktrym

Naja wenigstens entwickeln die nicht noch am Intel Gallium Treiber herum, zuzutrauen wäre es ihnen.

Nein; Intel hat nie Gallium-Treiber veröffentlicht! Die Treiber kamen von Tungsten Graphics, die von VMware gekauft wurden.

[Yamagi]

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.

[Kamikaze]

Zitat von John Carmack

I don’t worry about the GPU hardware at all, I worry about the drivers

http://www.pcper.com/reviews/Editori...oxels-and-more

[darktrym]

Zitat von Azazyel

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.

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?

Zitat von Azazyel

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.

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.

Zitat von Azazyel

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.

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.

Zitat von Azazyel

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.

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.

Zitat von Azazyel

Nein; Intel hat nie Gallium-Treiber veröffentlicht! Die Treiber kamen von Tungsten Graphics, die von VMware gekauft wurden.

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]

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.