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

Yamagi

Possessed With Psi Powers
Teammitglied
Konstantin Belousov hat nach fast 18 Monaten Arbeit seinen GEM / KMS Treiber für Intel-Grafikkarten in 10-CURRENT commitet. Im Zusammenspiel mit einem aktuellen xf86-video-intel Userlandtreiber unterstützt er alle aktuellen Grafikkarten, inklusive den aktuellen Ivy Bridge Modellen. Die Treiber sollen vor 9.1 in 9-STABLE zurückfließen und werden daher wahrscheinlich Teil des nächsten Release sein.

Die Commits:
Code:
Author: kib
Date: Tue May 22 10:59:26 2012
New Revision: 235782
URL: http://svn.freebsd.org/changeset/base/235782

Log:
  A rewrite of the i810 bits of the agp(4) driver.  New driver supports
  operations required by GEMified i915.ko. It also attaches to SandyBridge
  and IvyBridge CPU northbridges now.
  
  Sponsored by:	The FreeBSD Foundation
  MFC after:	1 month

Code:
Author: kib
Date: Tue May 22 11:07:44 2012
New Revision: 235783
URL: http://svn.freebsd.org/changeset/base/235783

Log:
  Add the code for new Intel GPU driver, which supports GEM, KMS and
  works with new generations of GPUs (IronLake, SandyBridge and
  supposedly IvyBridge).
  
  The driver is not connected to the build yet.
  
  Sponsored by:	The FreeBSD Foundation
  MFC after:	1 week
 
Also landet das in den normalen Modulen, oder gibt es extra Module?

Und wird der neue Xorg-Server dann auch in den Ports default? Und wenn ja, geht dann alte ATI-Karten (HD3870) mit dem alten Treiber (r300c) unter dem neuen Xorg und dem neuen Mesa auf dem neuen FreeBSD? Ich bin verwirrt, irgendwie gibts hier zu viele Kombinationen :rolleyes:
 
Unter Vorbehalt, da aus diversen Threads zusammengereimt:
- Es werden neue Module: drm2.ko und i915gem.ko
- Der neue xf86-video-intelt wird gepatcht, damit er i915gem.ko lädt
- Das alte X.org bleibt Standard, da sonst die Nutzer von allem was nicht Intel und Nvidia ist in die Röhre schauen würden
 
Also wer den neuen Xorg nicht absichtlich baut bleibt von allem verschont, wer das tut, bekommt alles automatisch? Das hoert sich ja gut an, wobei es zunehmend kompliziert werden duerfte zwei Xorgs in den Ports zu pflegen...

Gibt es denn schon ganz wage Informationen zu TTM? Das waere doch der letzte Baustein bevor alle neuen Treiber und das ganze Galllium-Zeugs dann gehen, oder?
 
Ja, erstmal bleibt es optional. Aber wie du sagst, kann das nur eine Übergangslösung sein und früher oder später muss man jemandem weh tun. Die Frage ist nur, wie groß die Gruppe der Nutzer dann nicht mehr unterstützter Hardware sein mag. Ich denke mal, dass man damit leben könnte, wenn so Konsorten wie OpenChrome abgeschossen werden. Radeon wäre allerdings sehr bitter. Und dort ist das Letzte, was ich zu TTM hörte, dass kib@ keine Lust hat es zu portieren, aber vielleicht jemandem dabei unter die Arme greifen würde. Aber keine Ahnung, ob es noch aktuell ist...
 
Und es geht weiter:
Code:
Author: kib
Date: Wed May 23 17:09:14 2012
New Revision: 235846
URL: http://svn.freebsd.org/changeset/base/235846

Log:
  Add 'drmn' device as another drm child, to allow drm2 drivers to live
  in parallel with drm1.
  
  Sponsored by:	The FreeBSD Foundation
  MFC after:	1 month

Code:
Author: kib
Date: Wed May 23 17:10:22 2012
New Revision: 235847
URL: http://svn.freebsd.org/changeset/base/235847

Log:
  The drm2 modules makefiles commit.
  Still not attached to the build.
  
  Sponsored by:	The FreeBSD Foundation
  MFC after:	1 month
 
Und nun ist es aktiviert:
Code:
Author: kib
Date: Wed May 23 21:07:01 2012
New Revision: 235859
URL: http://svn.freebsd.org/changeset/base/235859

Log:
  Enable drm2 modules build.
  
  Sponsored by:	The FreeBSD Foundation
  MFC after:	1 month
 
Hi,

das heisst es muss nun nur noch FBSD Current installiert werden, die Option NEW_XORG in make.conf und xorg rekompilen, und dann mit dem "intel" Treiber die X-Config aktivieren und fertig?

Oder viel komplizierter? Würde das ja ganz gerne mal testen.

Hugly
 
Hat eigentlich jemand auf nem Notebook mit Intelgrafik und KMS mal suspend/resume ausprobiert?
Klappt das noch? Oder dann vielleicht erst?

Bei mir funktioniert das mit dem alten X.org noch wuderbar, deswegen mag ich KMS gar nicht ausprobieren. Und wie siehts inzwischen mit dem Stromverbrauch aus? Vor ein paar Wochen war der mit KMS ja noch viel höher als ohne, meine 5 Stunden Laufzeit würde ich ungern aufgeben...
 
Hi,

habe es mal probiert, xdm startet mit der korrekten Auflösung, aber dann crasht es:
XIO: fatal IO error 35 (Resource temporarily unavailable) on X server ":0"^M
after 440 requests (394 known processed) with 0 events remaining.^M
xdm info (pid 2351): Starting X server on :0
1 XSELINUXs still allocated at reset


Also einfach so geht noch nicht, aber wenn der X-Server prinzipiell läuft ist es ja schonmal auf einem guten Weg, evtl. liegts auch am xdm? - Wer weiss.
 
Hab mit KMS/dem neuen Intel-Treiber auch Probleme. Das System friert manchmal ein und GTK geht auch gern mal putt. Dass SDL-Applikationen jetzt endlich bei mir laufen, entschädigt aber.
 
Hi,

wollte mich nur mal melden.

Also ein Current vom 1.Juni läuft hier. Ebenfalls der xorg Port wurde nach dem setzen von WITH_NEW_XORG=true in /etc/make.conf neu gebaut, der Aufwand hielt sich in Grenzen.

Es läuft stabil, keinerlei Abstürze (arbeite an dem Notebook nun seit einer Woche täglich).

Lediglich ein bisschen langsam scheint es zu sein, auch im 2D Bereich beim schnellen verschieben von Fenstern etc. - ist nicht schlimm, man kann damit arbeiten, aber es fällt mir doch auf.

Hat dazu jemand Informationen?

hugly
 
Welche debugging-Optionen von Current hast du deaktiviert? Was hattest du vorher für eine FreeBSD Version?

Ich vermute -CURRENT reduziert mit den default-Werten (z.B. WITNESS) die Leistung mehr als man mit GEM/KMS gewinnt.

mousaka

Habe alle debugging Optionen deaktiviert.
 
GEM / KMS für Intel in FreeBSD 10-Current / FreeBSD 9

Ich habs gestern installiert (ASUS Zenbook mit Intel Graphic, FreeBSD 9)

WITH_NEW_XORG gesetzt, Xorg und Treiber xf86* neu gebaut.

Das Ganze war recht problemlos, aber unter dem neuen Intel-Treiber kann ich xorg nicht beenden, hängt am Schluss (schwarzer Bildschirm) und terminiert nicht. Umschalten mit CTRL-ALT-Fn funktioniert auch nicht richtig.

Wenn ich den VESA Treiber nehme funktioniert das alles.

Gruss
Georg
--
 
Habe ich mittlerweile auch rausgefunden, wird wohl irgendwann geändert.
Aber das der Xorg nicht terminiert, ist wohl nicht korrekt.

Gruss
Georg
 
Das ist das korrekte Verhalten.

LOL, ich dachte das ganze KMS-Zeug wurde erfunden, damit unter Ubuntu beim wechseln zwischen den ttys der Bildschirm nicht flackert. Ihn einfach ganz schwarz werden zu lassen, hätte man sicher auch einfacher hinbekommen, oder? ^^
 
So, ich habe das jetzt auch mal ausprobiert.

Sieht erst mal gut aus, aber X stürzt ab sobald ich glxinfo/glxgears oder ioquake3 starte. Nach dem Absturz kommt es mit verkleinertem Viewport hoch (schätze mal 800x600).

Ist jedenfalls nicht benutzbar und ich baue gerade zurück.
 
LOL, ich dachte das ganze KMS-Zeug wurde erfunden, damit unter Ubuntu beim wechseln zwischen den ttys der Bildschirm nicht flackert. Ihn einfach ganz schwarz werden zu lassen, hätte man sicher auch einfacher hinbekommen, oder? ^^

Nee, KMS hat nen anderen Hintergrund.. Hat mit protected mode und direktem Hardwarezugriff zu tun.
 
Zurück
Oben