Freie 3D-Grafik unter (Free)BSD, aktueller Stand und Zukunft

h^2

h^2

hat ne Keule +1
Yamagi schrieb:
Dazu kommt unter FreeBSD ja noch das Problem, dass es nach wie vor kein Mixed Mode DRM gibt und sicher auch nicht so schnell geben wird. D.h. mit freien Treibern kann man ein 32-Bit Programm auf einem 64-Bit Host nicht ohne weiteres beschleunigen...
Zum Vergrößern anklicken....
Gibt es eigenjtlich irgendo eine Ressource (Liste/Blog?)[1], die die Entwicklungen im mesa/drm-Bereich unter FreeBSD beleuchtet? Ich lese viel Phoronix und werde immer traurig, weil es die ganzen Sachen nicht unter FreeBSD gibt ;'(
Das zweite FrickelOS, GenodeOS, hat jetzt schon GEM und Gallium-Unterstützung…

[1] auf freebsd-x11 scheint nicht so viel rüberzukommen…
 
Nein, sowas gibt es nicht. Es hat auch einen schlichten Grund: An der Kernelseite arbeitet im Moment schlicht und ergreifend niemand. Robert Noland hat keine Zeit (Familie, Job, Leben) und keinen Bock, jemand anders war nicht bereit in die Lücke zu springen und damit steht der Kram still und nVidia freut sich.
 
Yamagi schrieb:
Nein, sowas gibt es nicht. Es hat auch einen schlichten Grund: An der Kernelseite arbeitet im Moment schlicht und ergreifend niemand. Robert Noland hat keine Zeit (Familie, Job, Leben) und keinen Bock, jemand anders war nicht bereit in die Lücke zu springen und damit steht der Kram still und nVidia freut sich.
Zum Vergrößern anklicken....

Das heißt also, dass langsam aber sicher keine Updates mehr für freie Treiber eintrudeln werden? Und XServer-Updates dann auch nicht mehr, wegen Kompatiblität?

Das ist ja großartig :|

Wenn sowas wenigstens öffentlich gesagt würde, könnte man ja versuchen Geld zusammeln oder die Foundation nerven mehr in die Entwicklung von FreeBSD als Desktop-Betriebsystem zu investieren…
 
Wenn wir es mal klipp und klar aussprechen, wird genau das passieren. xf86-video-intel ist schon heute nicht mehr aktualisierbar, weshalb die Ironlake-GPU der Core i3 und i5 Prozessoren nicht unterstützt wird. Ab Anfang 2011 bringt Intel mit Sandy Bridge eine neue Micorarchitektur, die wahrscheinlich eine überarbeitete Ironlake-Karte haben wird. Und Intel wird damit den gleichen Weg wie AMD gehen, jede Intel-CPU - egal ob billig oder verdammt teuer - wird dann eine integrierte Grafikkarte haben. Sie ist auf dem gleichen Die wie die CPU selbst untergebracht, da Intel traditionell das ganze Produktprogramm aus nur zwei bis drei unterschiedlichen Wavern schneidet, kann man sie auch überall aktiviert lassen. Man muss sie ja nicht nutzen, wenn man nicht will, genauso wie man die inzwischen kaum mehr vermeidbare AMD-IGP nicht nutzen muss.
Dann ist das xf86-video-ati, der angeblich umbenannt werden soll, wenn die Marke ATI nun verschwindet und die Grafikkarten wohl ab der nächsten Generation auch unter dem Namen AMD segeln werden. Noch läuft er ohne KMS und co, allerdings schon heute wesentlich schlechter als unter Linux. Auch da ist das Ende absehbar, die HD5000 Serie wird bis heute von FreeBSD nicht unterstützt, die HD6000-Serie startet in einigen Wochen...
Alles andere neben diesen beiden Großen kannst du praktisch in Tonne treten, wenn es um Xorg geht. xf86-video-openchrome gibt es noch, die zugehörigen Karten sind einzeln aber praktisch nicht aufzutreiben und eine VIA-CPU wird sich heute niemand mehr in den Desktop-Rechner stecken wollen. Bleibt als pragmatische Lösung halt der nVidia-Blob. Auch wenn es böse klingt, C. Zander von nVidia ist so gesehen ein Geschenk Gottes für FreeBSD-Desktop-Grafik. Nicht umsonst steht eine nVidia-Karte (wahrscheinlich eine GTX 460) im Moment ganz oben auf der Einkaufsliste.

Was kann man machen? Spenden sammeln wäre eine Idee. Aber da der Ekelfaktor für DRI / DRM groß ist und der Rückstau ebenfalls, muss das schon eine nennenswerte Summe sein. Rechnen wir mal 50 Arbeitsstunden, um den Anschluss an Linux wiederzufinden. Allein das ist nur dann realistisch, wenn jemand in die Tasten haut, der in der Materie steckt. Die Arbeitsstunde bekommen wir zum Freundschaftspreis von ca. 75 Euro. Das ist in etwa das, was andere bezahlte Commiter für spezifische Aufgaben genommen haben. Bei Doug Barton war sein "Portmaster Funding" z.B. mit 100$ die Stunde kalkuliert. Ich weiß, es klingt viel. Aber man muss bedenken, dass davon normalerweise noch Steuern abgehen, Sozialversicherung und co. Das wären dann 50 * 75 = 3750, eine Menge Holz. Da müsste man schon international einen Spendenaufruf machen, BSDForen.de ist zu klein.

Bleibt also Möglichkeit 2, die FreeBSD Foundation. Da könnte man schon eher was machen. Einfach mal anfragen, wie es aussieht. Vielleicht kann man auch was organisieren, dass man unter die Mail die Namen von mehreren Nutzern schreibt, wie wir es schon mal in einem (missglückten) offenen Brief an freebsd-current@ zu einem anderen Thema gemacht hatte. Eventuell gleich mit dem Hinweis, dass jeder 25 Euro (oder meinetwegen auch mehr, je nach Rahmen der Möglichkeiten) geben würde.
 
Yamagi schrieb:
Bleibt also Möglichkeit 2, die FreeBSD Foundation. Da könnte man schon eher was machen. Einfach mal anfragen, wie es aussieht. Vielleicht kann man auch was organisieren, dass man unter die Mail die Namen von mehreren Nutzern schreibt, wie wir es schon mal in einem (missglückten) offenen Brief an freebsd-current@ zu einem anderen Thema gemacht hatte. Eventuell gleich mit dem Hinweis, dass jeder 25 Euro (oder meinetwegen auch mehr, je nach Rahmen der Möglichkeiten) geben würde.
Zum Vergrößern anklicken....

Ich bin dabei, also was gemeinsamen Brief und 25€-Pledge angeht. Vielleicht kriegt man ja das ganze BSDForen.de-Team (und natürlich möglichst viele User) dazu und vielleicht auch noch andere deutsche BSDler, die BSDGroup? [ist ja für nen guten Zweck]
 
Aber wie ich im anderen Thread schrieb. Bedenkt, dass ein größeren Problem neben Geld sein dürfte, jemanden zu finden, der die Drecksarbeit machen will. :)
 
Ich denke, das ist nicht das Problem, sondern eher jemanden zu finden, der die Faehigkeiten besitzt damit zu arbeiten, das ganze voran zu bringen _und_ bereit es fuer wenig Ruhm und Geld zu tun.
Jeder der mal einen Blick in radeon_cp.c und radeon_cs.c geworfen hat kriegt nachts Albtraeume und wacht morgens schweiss gebadet auf.
 
Also radeon_cp.c ist nicht so schlimm (Registeradressierung, sieht auch ziemlich sauber aus). Die andere _cs finde ich schon etwas schwieriger (hier muss man ziemlich genau wissen wie zwischen Kernel und radeon kommuniziert wird).

Das größte Problem ist, dass man davon nichts hat, wenn man weiß wie eine Grafikkarte eines bestimmten Herstellers intern funktioniert. Da haben recht wenige Leute Lust, sich damit zu beschäftigen. Das Wissen was Du da sammelst kannst Du auch nirgendwo großartig einsetzen, außer zur Kernelprogrammierung... und das ist nunmal DRM.

Vor allem ist blöd, dass man solche Module wie radeon.ko nicht einfach vernünftig entladen und neu laden kann. Da muss man immer den Rechner komplett neu starten, um was auszuprobieren (wenn man was neues geschrieben hat). Da gibt es einige Races im Kernel für einige Module.

--
Edit:
Ich sehe gerade, dass für Linux HD5000-Treiber mit 2D und 3D unterwegs sind. Wir haben noch nichtmal 3D für HD2xxx. Das ist eine Katastrophe... :(
 
Zuletzt bearbeitet:
Wir haben 3D bis einschließlich HD4000-Serie. Also auch für die HD2000...
 
Aber einmal davon abgesehen, halte ich persönlich DRM für grundlegend fehlkonstruiert. Das der Kernel keinerlei Kenntnis über das hat, was man ihn reichschickt ist einfach Murks. Großer Murks. Diese ganze DRM-Geschichte ist im Wesentlichen ein "Friss oder stirb"-Ansatz, der jeden Versuch die Kommunikation zwischen Userland und Kernel zu debuggen unmöglich macht. Er macht es auch extrem schwer und eklig unterschiedliche Bittiefen in Kernel und Userland zu haben, weshalb kein BSD im Moment "Mixed Mode"-DRM hat. Linux hat es und frickelt es über zwei parallel existierende und laufende DRM-Implementierungen hin...
 
Wäre es dann nicht sinnvoll, das Kernel-DRM aus dem System-Baum komplett zu entfernen und in den Ports-Tree aufzunehmen?

Und dann - ähnlich wie bei webcamd + cuse4bsd - einen Wrapper drumherum zu schreiben, so dass die Linux-Sourcen ohne Modifikationen verwendet werden können?
 
Ach... ich hab den "Cheatcode" für die Ports gefunden, der 3D hinzufügt. Ist aber auch blöd, dass das nicht irgendwie bei den Ports signalisiert wird.

In make.conf (oder wie bei mir in buildflags.conf):
Code: 
WITHOUT_NOUVEAU = yes
 
Ja, das stand mal in UPDATING, ist inzwischen aber wohl meilenweit runtergerutscht und man sucht auch nicht unbedingt danach...
 
waki87 schrieb:
Ich wollte nochmal darauf hinweisen, daß es dieses Jahr auch ein GSoC-Projekt gibt, um möglichst große Teile des Linux-DRMs auf *BSD zu portieren. Das ganze läuft zwar zunächst auf DragonFlyBSD, hat aber auch explizit zum Ziel, den anderen BSDs zu KMS/GEM zu verhelfen: http://www.dragonflybsd.org/docs/developer/GEMdrmKMS/
Zum Vergrößern anklicken....

Ah, sehr interessant. Es scheint also auf jeden Fall Leute zu geben, die da Skills haben. Ich wäre dafür, dass wir erstmal abwarten was bei dem SoC-Projekt rauskommt (die müssten doch bald fertig sein, oder?) und dass wir danach nochmal überlegen eine Initiative zu starten an die FreeBSD-Foundation.
 
Nun ich hoffe es, nur manchmal habe ich das Gefühl, daß FreeBSD zu DragonFlyBSD steht, wie NetBSD zu OpenBSD. Nicht das kein Austausch bestehen würde, aber oftmals wurde schon etwas ob eines Politikums gecancelt, wie damals beispielsweise die Portierung des Sensor-Frameworks von OpenBSD auf FreeBSD.

Aber ich bin natürlich gespannt ...
 
Ich stimme dir vollkommen zu olhe...

Nach außen hin wird oft so getan, als wären die *BSDs eine große Familie, so ala Friede Freude Eierkuchen, aber andererseits wird da ganz gerne rumgegiftet. Schaut euch nur mal an, wie Matt Dillon teilweise angegangen wird, wenn er auf einer der FreeBSD-Listen posted. Gerade auch von alten Hasen wie Scott Long oder PHK.

Andererseits wurde z. B. in Dragonfly- und NetBSD LVM von Linux importiert, anstatt auf GEOM von FreeBSD zu setzen.

Irgendwie schade, aber was will man machen..
 
h^2 schrieb:
Ah, sehr interessant. Es scheint also auf jeden Fall Leute zu geben, die da Skills haben. Ich wäre dafür, dass wir erstmal abwarten was bei dem SoC-Projekt rauskommt (die müssten doch bald fertig sein, oder?) und dass wir danach nochmal überlegen eine Initiative zu starten an die FreeBSD-Foundation.
Zum Vergrößern anklicken....

Weiß jemand wie das Prjekt ausgegangen ist? Die SoC-Frist ist doch jetzt vorbei und die Informationen auf der Seite nicht sehr aktuell…
 
Also der Status sagt "The latest drm code from FreeBSD 9.x current has been successfully ported to DragonFly BSD" :)

Aber allgemein finde ich es schade das Hersteller wie Intel die freie Software Loben und selbst Software entwickeln die nicht wirklich frei ist weil sie auf ein bestimmtes System maßgeschneidert ist... Diese ganzen GPU in CPU Geschichten finde ich eh etwas seltsam. Es wird wahrscheinlich bald nur noch eine CPU mit Anschlüssen geben weil der Rest vom Mainboard in der cpu ist :)

Grüße
 
christian83 schrieb:
Also der Status sagt "The latest drm code from FreeBSD 9.x current has been successfully ported to DragonFly BSD" :)

Aber allgemein finde ich es schade das Hersteller wie Intel die freie Software Loben und selbst Software entwickeln die nicht wirklich frei ist weil sie auf ein bestimmtes System maßgeschneidert ist... Diese ganzen GPU in CPU Geschichten finde ich eh etwas seltsam. Es wird wahrscheinlich bald nur noch eine CPU mit Anschlüssen geben weil der Rest vom Mainboard in der cpu ist :)

Grüße
Zum Vergrößern anklicken....

Hehe, CPU mit USB-Buchse und Batteriefach:D
 
Besonders bitter daran ist, dass der Intel-Treiber maßgeblich von Eric Anhold geschrieben wird. Der war lange Zeit FreeBSD-Committer, hat z.B. den initialen DRM-Port geschrieben. Er sollte also wissen, dass Linux nicht das einzige System dort draußen ist. Aber wer weiß, was seine Chefs so denken...

Und GPUs und CPUs. Das bietet natürlich gewisse sehr interessante technische Vorteile. Die GPU übernimmt die Rolle der FPU, CPU und GPU teilen sich einen Adressraum, können durch einen gemeinsamen Befehlsstrom gefüttert werden. Aber bis das passiert, dürfte noch viel Wasser die Elbe hinabfließen. Gerade bei Intel, den für sowas im Moment schlicht noch die Technologie fehlt. Zur Zeit geht es eher um Monopole. Die GPU in die CPU zu flanschen ermöglicht sowohl Intel als auch AMD es die ungeliebte Konkurrenz von nVidia zu eliminieren. Chipsätze dürfen sie (für Intel) schon nicht mehr bauen, nun verlieren sie das extrem umsatzstarke Segment der Low-End Grafikkarten und mittelfristig auch die untere Mittelklasse. Oder anders gesagt, Intel und AMD wollen einfach die komplette Plattform selbst liefern und sie wollen vor allem kein nVidia oder sonstwen durchfüttern, die sich durch GPGPU und weiteres zur ernsthaften Konkurrenz auswachsen könnten.

Besonders bitter ist das für uns BSDler. Wir FreeBSDler haben nun endlich unseren amd64-Blob, prompt gerät nVidia in ziemlich raues Fahrwasser. Klar, sie versuchen mit Tegra (embedded) und Tesla (GPGPU) die Fluch nach vorn. Aber wird es reichen? Keine Ahnung, aber Aktien würde ich von ihnen nicht kaufen... Es ist doch alles zum Kotzen.
 
christian83 schrieb:
Also der Status sagt "The latest drm code from FreeBSD 9.x current has been successfully ported to DragonFly BSD" :)
Zum Vergrößern anklicken....
Aber das ist doch kein wirklicher Fortschritt. Das Projekt heißt Port of GEM and KMS, es geht also darum Linux-Technologie nach *BSD zu rbingen und nicht FreeBSD9-Code nach DfBSD. Wenn FreeBSD9 schon GEM und KMS hätte, würde mich als FreeBSD-User ja nicht primär die Arbeit der DfBSD interessieren ;)
Also prinzipiell natürlich schon, ihr wisst was ich meine.
 
@Yamagi:
Sehe es nicht so negativ, nvidia hat es zwar etwas schwerer als früher aber denke so tragisch ist es auch noch nicht. Vor allem hat Intel ja keine Hardware zu bieten die für mehr als Desktop betrieb reicht, mit mühe und not kann man mal Solitär spielen das ist aber auch schon an der grenze der Leistungsfähigkeit :)

Wo wir gerade beim Thema sind, wie sieht es mit Matrox Karten unter FreeBSD aus?

Grüße
 
Ot

Yamagi schrieb:
Und GPUs und CPUs. Das bietet natürlich gewisse sehr interessante technische Vorteile. Die GPU übernimmt die Rolle der FPU, CPU und GPU teilen sich einen Adressraum, können durch einen gemeinsamen Befehlsstrom gefüttert werden. Aber bis das passiert, dürfte noch viel Wasser die Elbe hinabfließen. Gerade bei Intel, den für sowas im Moment schlicht noch die Technologie fehlt. Zur Zeit geht es eher um Monopole. Die GPU in die CPU zu flanschen ermöglicht sowohl Intel als auch AMD es die ungeliebte Konkurrenz von nVidia zu eliminieren. Chipsätze dürfen sie (für Intel) schon nicht mehr bauen, nun verlieren sie das extrem umsatzstarke Segment der Low-End Grafikkarten und mittelfristig auch die untere Mittelklasse. Oder anders gesagt, Intel und AMD wollen einfach die komplette Plattform selbst liefern und sie wollen vor allem kein nVidia oder sonstwen durchfüttern, die sich durch GPGPU und weiteres zur ernsthaften Konkurrenz auswachsen könnten.
Zum Vergrößern anklicken....
Interessant ist in dem Zusammenhang auch GOD, Game On Demand. Da liest man im Moment recht viel von. Wenn das mehr Verbreitung findet, könnte das auch am Markt von dedizierten GKs nagen, weil es dann immer weniger Leute gibt, die sich die neuesten Games, und in folge dessen, auch nicht mehr die neueste SuperDuper hastenichgesehen GKs kaufen. Die Konsolen exerzieren es ja schon vor. In den USA ist das natürlich schon viel verbreiteter als in good old europe, wiedereinmal.

c.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben