FreeBSD Gaming Thread

Yamagi schrieb:
Die 5500XT ist ja noch mal neuer und war in 5.4 nur experimentell, meine ich. Ich fürchte, ohne wirklich sehr aktuellem Kernel und Mesa3D wird da nicht allzu viel gehen. Und Debian ist ja auch in Sid eher konservativ und merged nicht gleich jedes Update rein. Vor allem nicht von erfahrungsgemäß nicht unproblematischen Sachen wie Mesa3D.
Zum Vergrößern anklicken....
Interessanterweise bieten AMD auf ihrer Seite Treiber für RHEL, CentOS, SLES und Ubuntu an. Mal schauen, für RHEL habe ich eh noch ne Developer-Lizenz...
 
Zuletzt bearbeitet:
Vulkan funktioniert unter FreeBSD mit den freien Treibern im Moment übrigens gar nicht.
Zum Vergrößern anklicken....
Also mit meiner Radeon RX560 und amdgpu scheint Vulkan zu funktionieren. Jedenfalls mit games/vkquake.

Die beiden Unigine Benchmarks hab ich auch gerade mit dieser Karte getestet mit jeweils ca. 40 FPS bei 1920x1080 auf meinem betagten i7 2660K.

Außerdem läuft bei mir noch GTA4 recht gut mit i386-wine-devel.
Und Unreal mit dem c7 Linuxulator. Hier funktioniert aber die Musik nicht mehr seit dem ich wegen der Radeon von linux-c6 auf linux-c7 umgestiegen bin.
Achso und Doom3 sowie Quake4 hab ich auch noch mit dem Linuxulator am laufen.

Sind aber alles auch schon recht alte Spiele.
 
Ich habe es noch mal getestet:
  • Auf dem i5-8500T im Büro ist Vulkan ums Erbrechen nicht hinzubekommen. YQ2 mit recht experimenteller und es vielleicht nie in ein Release schaffender Vulkan-Renderlib bekommt den Kontext noch aufgebaut, bei der ersten Allokation ist aber Schluss. Das mag daran liegen, dass die CPU und damit auch die GPU recht neu sind.
  • Auf dem i7-6700K funktioniert es tatsächlich, zumindest solange man nicht so wahnsinnig ist die Renderlib mit ASan zu bauen. Aber gut, irgendwas ist halt immer und so sehr traue ich diesem mit der heißen Nadel gestrickten auch noch nicht.
Also ich hab nichts gesagt und ihr den denkwürdigen Tag erlebt, dass ich Unrecht hatte. ;)
 
Doom 3 gibts auch nativ für FreeBSD als dhewm:
Zum Vergrößern anklicken....
Ja, darauf hat mich schon mal wer aufmerksam gemacht. Habs aber noch nicht installiert, da ich es (zur Zeit) sowieso nicht spiele.

Overload von GOG hab ich auch noch installiert. Das gibt es auch als Linux Version, diese läuft aber bei mir nicht. Deshalb hab ich die Windows Version mit wine installiert. Die gibt es zur Zeit wieder als i386 Version. (War eine Zeit lang nur für x86_64 zu haben)

[edit]
Aber was mir am allermeisten fehlt ist das mangelhaft unterstützte openCL. Damit wäre die Bildbearbeitung in darktable um längen schneller. Leider hat openCL auf FreeBSD keinen image support.
Code: 
[opencl_init] discarding device 0 `Radeon RX 560 Series (POLARIS11, DRM 3.23.0, 12.1-RELEASE-p1, LLVM 8.0.1)' - The OpenCL driver doesn't provide image support. See also 'clinfo' output
[/edit]
 
Yamagi schrieb:
Also: amdgpu ist unter Linux die erste, unter FreeBSD aber die dritte Wahl, wenn man ernsthaft was mit 3D-Grafik machen will.
Zum Vergrößern anklicken....

Hm, ich habe deswegen auch wieder eine NVIDIA genommen. Eine RTX 2060S... aber wirklich glücklich bin ich damit auch nicht muss ich sagen.

Vulkan: Nein
CUDA: Nein
Wayland/sway support: Nein

Die paar Sachen spieletechnisch, die ich mit dem 3D-Support und Linux-Compat zum Laufen bringen konnte haben regelmäßig ein kurzes "Lag"/Zucken das auf Linux auf der gleichen Kiste nicht auftritt.

Kombiniert mit dem schlechten Zustand der Linux-Compat stimmt mich das alles nicht sehr optimistisch. Insbesondere was die Zukunft angeht. Ich habe einen Monitor der HDR10 kann, ob das je gehen wird?
 
h^2 schrieb:
Insbesondere was die Zukunft angeht. Ich habe einen Monitor der HDR10 kann, ob das je gehen wird?
Zum Vergrößern anklicken....

Schwieriges Thema... Das Problem ist nicht so sehr FreeBSD, sondern der immer noch oder vielleicht auch wieder sehr bescheidene Gesamtzustand des freien Grafikstacks und Desktops. Da ist X11, die ewige Katastrophe. Seit mindestens 20 Jahren obsolet, vor 15 Jahren noch mal groß aufgebohrt um Zeit für die Entwicklung eines Nachfolgers zu finden, aber immer noch alternativlos. Irgendwie findet sich immer noch jemand, der Unterstützung für neue Entwicklungen reinhackt - und sei es nur nur als über auf X11 laufende Compositoren. Dann hat man Wayland, den ewigen designierten Nachfolger, den man inzwischen wohl als halb-gescheitert betrachten kann. Wayland wurde bis ganz wenige Ausnahmen, Sway ist da wohl die bekannteste, nur von den großen Desktopumgebungen implementiert und auch da ist es eher durchwachsen. Die meisten Window Manager Entwickler haben damals sofort den Stinkefinger gezeigt und dabei ist es dann auch geblieben. Auch 12 Jahre, nachdem Wayland zur großen Hoffnung wurde, wird es nur selten eingesetzt; Ubuntu hat zum Beispiel letztens gerade noch mal klargestellt, dass man bis auf Weiteres auf Xorg bleibt.

Es ist eine sichere Wette zu sagen, dass Xorg in den nächsten 5 Jahren der Standard bleiben wird. Wayland mag noch etwas Auftrieb bekommen, aber dass es X11 jemals wirklich ersetzt, ist inzwischen wohl ausgeschlossen. Und eine andere, dritte Lösung ist nicht in Sicht. Das heißt aber auch, dass FreeBSD - und die anderen BSDs - gezwungen sind das Monster zu porten. Nun ist Xorg ein halbwegs angenehmer Upstream, der andere Plattformen neben Linux durchaus ernst nimmt und auch FreeBSD ist klar, dass man dort etwas entgegenkommen muss. So hat man ja als Beispiel evdev implementiert, um libinput zu ermöglichen. Aber Xorg ist eben auch ein antiquitiertes Monster mit 1001 Fallstricken, es zu portieren und die Ports zu betreuen ist ein Tanz auf Eierschalen und entsprechend unbeliebt. Wenn man mal eine funktionierende Kombination der Komponenten gefunden hat, bleibt man daher erst einmal auf der, entsprechend ist FreeBSD zumindest auf Aktualität Wert legenden Linux-Distributionen immer hinterher.

Schlimmer wird es darunter. Grafiktreiber sind höllisch komplex, Linux hat keine definierte KPI und erlaubt keine Abstraktionsschichten. Meiner Meinung legt man sich damit hauptsächlich selbst Steine in den Weg, aber das ist ein anderes Thema. Zumindest macht es das Portieren der Kernelkomponente der Treiber sehr kompliziert. FreeBSD hat inzwischen aufgegeben zu portieren, man entwickelt stattdessen einen Linux->FreeBSD-KPI-Wrapper. Es ist nicht einfach, Linux-Komponenten wie RCU sind halt komplex und konzeptionell teilweise ohne Entsprechung im FreeBSD-Kernel. Ich vermute, dass viele Probleme der freien Grafiktreiber unter FreeBSD daher kommen, dass der Wrapper nicht so optimal ist, wie er sein müsste. Andererseits ist es gelungen auf Seite der Treiberentwickler Verständnis dafür zu wecken, dass es noch andere Plattformen außer Linux gibt und man sehr helfen kann, wenn man bei der Verwendung von KAPIs etwas konservativer ist. Zumindest mit den Entwicklern des i915 läuft die Zusammenarbeit wohl ganz gut.

Nur man ist Linux halt prinzipbedingt immer hinterher. Und das wird durch simple Tatsachen wie dem hohen Manpower-Bedarf zur Betreuung der Grafiktreiber und das es schon einiges an Kenntnis von Linux- und FreeBSD-Interna benötigt, um den KPI-Wrapper zu entwickeln, nicht besser. Außerdem sollen Kernelseite und Userland zwar zumindest in einem gewissen Rahmen zueinander agnostisch sein, aber ich habe bei meinem Abenteuern mit der Radeon 5700XT unter Linux selbst sehr schmerzhaft erfahren müssen, dass Kernel, Mesa3D und LLVM dann doch halbwegs zusammenpassen müssen. Das limitiert dann wiederum FreeBSDs Möglichkeiten im Userland, nicht umsonst ist man bei Mesa3D weit hinter Linux zurück. Vor allem für Vulkan ist das problematisch.

Bei Nvidia sieht es nicht besser aus. Ihre FreeBSD-Treiber ist auch nur ein Best-Efford Ansatz; sie supporten FreeBSD halt soweit es ihnen nicht allzu viel Arbeit macht, aber nicht mehr. Was ich durchaus verständlich finde, Nvidia ist ein kommerzielles Unternehmen und FreeBSD-User dürften kaum nennenswerten Anteil am Umsatz haben. Da geht es mehr um Freundlichkeit FreeBSD gegenüber, vielleicht einem weiteren Haken auf der Featureliste, dass mehr Plattformen besseres Testing bedeuten... Alles relevante Sachen, aber eben auch nichts, wo man groß Ressourcen investiert.

Trotzdem ist das Glas im Moment eher halb voll als halb leer. Der Misserfolg von Wayland bedeutet auch, dass sich da für FreeBSD so schnell keine weitere Baustelle ergeben wird, der aktuelle Minimalport reicht erstmal. Durch den KPI-Wrapper sieht es beiden freien Grafiktreiber besser als die meiste Zeit zuvor aus. amdgpu kommt sicher auch noch in Form, es braucht nur Zeit. Und mal schauen was mit Intels Xe wird, erste Hardware soll es ja im nächsten Jahr geben. Aber die Hoffnung, dass FreeBSD in Sachen Grafik mit Linux in allen Belangen gleichziehen kann, muss man sich eher nicht machen. Das wird höchst wahrscheinlich nicht so schnell passieren.
 
sterum schrieb:
Die beiden Unigine Benchmarks hab ich auch gerade mit dieser Karte getestet mit jeweils ca. 40 FPS bei 1920x1080 auf meinem betagten i7 2660K.
Zum Vergrößern anklicken....

Das hört sich doch ganz gut an. Also nach den hier zusammengetragenen Informationen scheinen Unterstützung und Performance für AMD-Karten mit amdgpu unter FreeBSD fast so gut zu sein wie mit nvidia?
 
Habe heute Unigine_Tropics-1.3 installiert aber auch diese Demo läuft nicht und gibt eine Fehlermeldung,weis aber nicht was ich da machen soll.Hat jemand einen Tip?

Code: 
Loading "/usr/home/karl/Downloads/tropics/bin/../data/unigine.cfg"...
Engine::init(): clear video settings for "Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2)  3.0 Mesa 18.3.4"
Loading "libGL.so.1"...
Loading "libopenal.so.1"...
AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"
ALSA lib conf.c:3652:(config_file_open) cannot access file /etc/alsa/conf.d/50-pulseaudio.conf
ALSA lib conf.c:3572:(snd_config_hooks_call) function snd_config_hook_load returned error: No such file or directory
ALSA lib conf.c:4026:(snd_config_update_r) hooks failed, removing configuration
AL lib: (EE) ALCplaybackAlsa_open: Could not open playback device 'default': No such file or directory
ALExt::init(): can't open device
Set 1920x1080 fullscreen video mode

Unigine fatal error
Engine::init(): clear video settings for "Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2)  3.0 Mesa 18.3.4"
ALExt::init(): can't open device
Received invalid memory reference signal
Shutdown
 
Yamagi schrieb:
Dann hat man Wayland, den ewigen designierten Nachfolger, den man inzwischen wohl als halb-gescheitert betrachten kann.
Zum Vergrößern anklicken....

Erlebe ich eher anders. Klar, wenn man nur auf kleinere Window-Manager schaut, die praktisch nicht portiert werden können, dann mag der Eindruck entstehen. Aber reine Windows-Manager sind eine Nische. Wayland war halt kein Kompromiss, so wie die ganze Xorg+AIGLX+GLAMOUR+Compositor Rotze davor.
Bei so ziemlich jeder Distribution, die z.B. ein normales GNOME ausliefert ist Wayland Standard. D.h. bei Debian, ArchLinux und Klonen oder RedHat und Klonen.

Es braucht natürlich Zeit bis nach und nach alles umgestellt ist und es ist verständlich, dass eine solche Umstellung bei Chrome, FireFox und Co. nicht die oberste Priorität hat bzw. hatte. XWayland als Fallback funktioniert auch erstaunlich gut. Bei FireFox z.B. gibt es bereits Arbeiten VAAPI im Browser zu unterstützen, bisher Wayland-only.

Ich weiß auch ehrlich gesagt nicht, warum die Leute in Punkto Wayland immer alles bis gestern haben wollen. Dass Wayland gescheitert ist, lese ich schon seit Jahren und seit Jahren wird Wayland besser und besser. Klar, den Xorg-WM von Anno-Dazumal wirst du nie auf Wayland sehen. Aber das ist auch gar nicht der Punkt von Wayland.

Vor 15-20 Jahren war der OpenSource-Grafikstack von Linux auch noch eine mittlere Katastrophe. Heute nutzt ihn sogar Google für Stadia.
 
-Nuke- schrieb:
Dass Wayland gescheitert ist, lese ich schon seit Jahren und seit Jahren wird Wayland besser und besser.
Zum Vergrößern anklicken....

Vielleicht ist beim vermeintlichen Ableben von Wayland der Wunsch der Vater des Gedankens, ähnlich wie beim prophezeiten Scheitern von systemd, das zur Spontanimplosion aller Server führen sollte. :ugly:

Die Zukunft von X.org sieht sehr düster aus, wenn man Gefühle beiseite lässt und einfach mal nur die nackten Fakten betrachtet:
With Red Hat shifting their support to Wayland and expecting the X.Org Server to go into a hard maintenance mode quickly, in 2019 indeed it did.

Without any other companies investing significantly into the X.Org Server itself with engineering resources, the X.Org Server is seeing little work these days beyond work to XWayland for running X11 applications on top of Wayland and also work to GLAMOR as the 2D acceleration code over OpenGL. It's rare seeing activity elsewhere sans the occasional commits to the xf86-video-modesetting DDX driver.

[...]

So on both a commit and lines of code basis, the X.Org Server in 2019 slowed to a point not seen since the early 2000s prior to the modern X.Org Foundation.

Work these days is going into Wayland itself and various Wayland compositors along with the likes of Mesa, libinput, and other areas.

[...]

So to not much surprise, X.Org Server development has virtually halted with Wayland continuing to be the principal focus of upstream Linux desktop developers.

[...]
Zum Vergrößern anklicken....
 
Moment: Ich habe nicht nicht gesagt, das X11 generell und X.org eine Zukunft haben. Falls es oben nicht deutlich genug war, die ganze X-Suppe soll bitte so schnell wie möglich in Höllenflammen vergehen. Ich habe gesagt, dass Wayland weder X11, noch X.org in absehbarerer Zukunft, wahrscheinlich sogar niemals. verdrängen wird. Und da bleibe ich bei.

-Nuke- schrieb:
Bei so ziemlich jeder Distribution, die z.B. ein normales GNOME ausliefert ist Wayland Standard. D.h. bei Debian, ArchLinux und Klonen oder RedHat und Klonen.
Zum Vergrößern anklicken....
Es ist Standard, weil die Voreinstellung im GDM so ist. Das heißt aber im Umkehrschluss nicht, dass die Nutzer es auch nutzen würden und nicht auf die X.org-Session umstellen. Ich habe seit 2013 auf verschiedenen Firmenlaptops Arch Linux mit Gnome 3 (beim Vertriebler vom sieht sowas einfach professioneller als Openbox aus) und in den inzwischen 7 Jahren ist Wayland nicht wesentlich besser geworden. Ja, einige Kleinigkeiten sind verbessert worden. So funktioniert das Clipboard inzwischen zuverlässig, auf Nvidia-Karten ist aus "geht gar nicht" immerhin ein "geht leidlich geworden und noch ein paar andere Dinge. Aber die wesentlichen Punkte sind immer noch offen und seit Jahr und Tag unverändert. Gerade erst vor ein paar Wochen wieder probiert:
  • Es läuft nicht stabil. Je nach Version des Mutter Compositors und der eingesetzten GPU ist es ein Freeze pro Tag oder auch nur ein Freeze die Woche, aber immer noch zu viel um es akzeptieren zu können. Vor allem das Freeze bedeutet, dass man bestenfalls in die Konsole wechseln und Mutter abschießen muss, schlimmstenfalls das Laptop neu starten muss. Alle ungesicherte Arbeit ist damit weg. Und das es nicht nur mir so geht, beweisen diverse Google-Treffer. Bei KDE mit Kwin scheint es nicht wesentlich besser zu sein.
  • Multimonitoring, vor allem Hotplugging von Displays, ist eine Katastrophe. Ab und an klappt es, dann landet man wieder im Freeze. Oder es tun sich Renderartefakte auf, oft auf einzelne Fenster (Wayland-Clients) beschränkt. Ganz besonders schön ist auch, wenn man das Laptop am Dock hatte, abzieht und nach dem nächsten Suspend-Resume-Zyklus Mutter stumpf wieder über das Dock auszugeben versucht. Kann man es nicht anschließen, hilft nur Mutter abschießen und von vorne.
  • Immer noch werden Fenster außerhalb des sichtbaren Bereichs platziert. Das geschieht hauptsächlich, wenn sich das Layout des Desktops während der Session verändert hat. Gut, daran sind meist die Anwendungen schuld. Aber Fenster in den sichtbaren Bereich zu zwingen habe ich vor 15 Jahren in Openbox implementiert, könnte Mutter also bitte auch. Außerdem kann Mutter es in der X11 Session offensichtlich.
  • Es ist recht einfach Mutter zum Ruckeln zu bekommen. Es reicht teilweise schon Youtube spielen zu lassen und schon klappen Desktopwechsel nicht mehr sauber, Fenster verschieben hakelt und so weiter. Es mag an der GPU liegen, aber sooo langsam sind aktuelle Intel GPUs nun auch nicht mehr. Außerdem nervt es (mich) tierisch.
Natürlich sind das alles Probleme des Mutter Compositors und nicht des Protokolls an sich. Aber wenn nicht einmal Mutter, der Compositor mit den meisten Ressourcen, dessen Mutterprojekt dazu noch sehr aggressiv in Richtung Wayland prügelt, nach so vielen Jahren nicht wirklich ausgereift ist, wie soll es denn jemals was werden.

Dazu kommen eben die Sünden Vergangenheit. Der endlose, ideologisch motivierte und letztendlich schlicht überflüssige Streit um GBM. Das es erst einen Hobbyentwickler brauchte um wlroots zu schreiben. Die Bibliothek hätte schon vor 10 Jahren von den Wayland-Entwicklern selbst anstelle von Weston kommen müssen. Und jetzt aktuell die beginnende Diskussion um Vulkan statt OpenGL ES, was wieder grundlegende Änderungen an den Compositoren und Clients bräuchte, wenn es sich denn materialisiert...

Gnome, KDE und daran hängende Projekte mögen Wayland früher oder später nach der "Friss oder stirb"-Methode durchsetzen, indem sie die X11-Unterstützung einfach einstellen. Vielleicht haben sie es bis dahin stabil hin oder man muss halt mit den Problemen leben, wenn man einen solchen Desktop einsetzt. Aber für alles andere sehe ich das beim nicht. Dafür muss Wayland einiges an liefern, was sie in den letzten 12 Jahren nicht haben.
 
Da wir gerade beim Thema Wayland <-> Xorg sind und ich das auch mal zu verstehen versuche

Wenn ich die Arch von Wayland richtig verstehe, verlagert es vieles in den Kernel, was der Xorg in seinem eigenem Bereich macht. Sprich es flutscht dann nur noch im Linux-systemd-Wayland-KDE Verbund? Persönlich ist das für mich das Gegenteil von Modularisierung mit sauberen Schnittstellen.
Wayland sagt, daß X11 überfrachtet ist und eine Menge Altlasten mitzieht. Könnte man diese "Altlasten" bei Xorg evtl. in eine Wrapper Schicht auslagern und als Kern ein "Xorg-Reloaded" fahren? NB Ich denke, daß viele "alte" X-Anwendungen nach dem Prinzip "Funktioniert es - lass es wie es ist" noch Jahrzehnte laufen werden (müssen).
Wird die GraKa Treiber Entwicklung dann für Wayland einfacher oder bleibt das Problem, daß es auf GraKa Ebene keine genormte Schittstelle für die GraKa Kommandos gibt und deswegen die Treiberentwicklung und das Reengineering oft lange dauert?
Kann Wayland wie X über das Netzwerk arbeiten? Ich habe jetzt von den ersten Anwendungen gesehen in denen ein MCU Shield mit WLAN Anschluß über X-Protokoll Daten auf einem Tablett / Mobile darstellt (Tablett ist sozusagen das X Terminal).
 
ich verstehe nicht genug davon, aber schon vor gefühlten 20 Jahren habe ich gegen X-org für Desktops gewettert, weil es eben für einen Durchschnitts-Nutzer viel zu weit geht, viel zu viel kann und verlangt.
Meine nicht qualifizierte Kritik daran liegt lange vor Wayland und ich nahm es sehr wohlwollend wahr, dass da etwas Neues am entstehen war, das auch im Open-Source-Umfeld eine schmalere, besser und genauer für Desktops und Einzelplatz-PCs geeignete Möglichkeit präsentiert. "Auch im Open-Source-Umfeld", weil es eine Lösung für (Mac)OS-X gibt. Die nutzen schon lange kein X11 mehr, wenn man es nicht dezidiert installiert und sofern ich das richtige gesehen hatte (so bei Version 10.6 oder so) auch kein Wayland.

Alle oben beschriebenen Nachteile von X11 oder Fehlentwicklungen von Wayland und alles, was man sich als Desktop-End-User wünschen kann, funktioniert in einem OS-X gnadenlos gut und vollkommen ohne X11 und Wayland!

Sind die Ziele in Open-Source einfach zu motiviert?
Will man immer doch noch alles machen, was X immer parat gehalten hatte?
Ist es wirklich kompliziert, so etwas zu bauen, was OS-X nutzt?

Ich wäre jedenfalls (vermutlich) froh, wenn ich einen einfachen Desktop an einem einzigen PC betreiben könnte, ohne Netzwerk-Transparenz und wer weiß was noch. Einfach nur Grafik, vielleicht Composite-Manager und ich ganz alleine. Kein Multi-User! Aber vielleicht, wenn ich einen Beamer anstecke, automatisch erkennen und verfügbar machen. Das wäre schon geil.

Aber ich kenne natürlich auch das Argument: dann nimm halt dein OS-X oder Windows oder sonst was proprietäres.

Meine Vermutung ist, dass jede OpenSource-Entwicklung bisher nicht dahin geht, mich und meine Bedürfnisse zu befriedigen. Also nicht den Enduser mit seinem einen Desktop ganz alleine auf einem PC.
 
serie300 schrieb:
Wayland sagt, daß X11 überfrachtet ist und eine Menge Altlasten mitzieht. Könnte man diese "Altlasten" bei Xorg evtl. in eine Wrapper Schicht auslagern und als Kern ein "Xorg-Reloaded" fahren?
Zum Vergrößern anklicken....

Die "Altlasten" sind der Kern von X11 bzw. Xorg und unzertrennbar damit verbunden.

Man könnte natürlich ein Xorg-Reloaded basteln und mit massiver Manpower eine Kompatibilitätsschicht einziehen, die jegliches bestehende X11-Verhalten emuliert, damit jede existierende X11-Anwendung ohne Anpassungen weiterhin funktioniert und man trotzdem zeitgenössische Anforderungen erfüllen kann. So wie Windows alte Bugs in neueren Windows-Versionen nachahmt, damit Altanwendungen trotzdem unter neueren Windows-Versionen laufen, aber man den Rest des Systems weiterentwickeln kann.

Aus dem Bauch heraus sollte man das mit einigen dutzend Entwicklern, ein paar hundert Testern plus entsprechendem Projektmanagement-Overhead bewerkstelligen können. 500 Millionen Euro Budget verteilt auf 7-10 Jahre und Xorg-Reloaded erreicht den heutigen Stand von Wayland (plus Features wie Netzwerktransparenz).
 
Yamagi schrieb:
Natürlich sind das alles Probleme des Mutter Compositors und nicht des Protokolls an sich. Aber wenn nicht einmal Mutter, der Compositor mit den meisten Ressourcen, dessen Mutterprojekt dazu noch sehr aggressiv in Richtung Wayland prügelt, nach so vielen Jahren nicht wirklich ausgereift ist, wie soll es denn jemals was werden.
Zum Vergrößern anklicken....

Mutter muss aber auch auf 3 Hochzeiten gleichzeitig tanzen (X11, Wayland, NVidia-Wayland) und hat, trotz dass es ein RedHat Projekt ist, auch nicht unendlich "Mitarbeiter". Nebenbei drückt auch der Saftladen NVidia hier ordentlich auf die Bremse (wie auch bei OpenCL und FreeBSD, nech?). Sie haben nunmal 80% Marktanteil und unterstützen Wayland nicht sinnvoll. Selbst wenn du "ihren" Weg gehst, funktioniert XWayland nicht und sie haben auch aktuell kein Interesse dies zu ändern. Und das liegt zu 100% bei NVidia. Klar wird der Umstieg auf Wayland somit lange dauern bis für (wie schon immer) ihro Gnaden NVidia der Zeitpunkt richtig ist.

Klar kann man sagen "das wird nie was", aber derweil kehre ich NVidia einfach den Rücken und kaufe Hardware von anderen Unternehmen, bei denen man nicht auf Steinzeit-Software festgelegt ist. Deine Probleme selbst kann ich in der Gänze übrigens selbst nicht nachvollziehen, aber ich vermute du hast eh kein Interesse daran das Problem zu untersuchen. Das Wayland+Compositoren bereits perfekt sind, sagt übrigens auch niemand.

Yamagi schrieb:
Die Bibliothek hätte schon vor 10 Jahren von den Wayland-Entwicklern selbst anstelle von Weston kommen müssen. Und jetzt aktuell die beginnende Diskussion um Vulkan statt OpenGL ES, was wieder grundlegende Änderungen an den Compositoren und Clients bräuchte, wenn es sich denn materialisiert...
Zum Vergrößern anklicken....

Es gibt sowas wie wlroots von den Wayland-Entwickler, die nennt sich libweston. wlroots entstand, weil den Leuten libweston nicht gefallen hat und man sich dafür entschieden hat lieber selbst was zu machen, statt an libweston mitzuarbeiten. Klassische Software-Entwicklung lief hier ab. Nebenbei konnte, im Gegensatz zu Weston/libweston, wlroots auf jahrelange Wayland-Erfahrung zurückblicken und "Clean-Room" mäßig anfangen... kennt man ja. So sind auch Dinge wie ZFS entstanden die vollkommen überraschenderweise nicht auch schon 1995 verfügbar waren.

Mit Wayland hast du wenigstens eine Basis die man aktiv an die aktuellen und zukünftigen Herausforderungen anpassen kannst, ganz im Gegensatz zu Xorg, was schon bei simplen Sachen von anno-dazumal wie V-Sync komplett auseinanderfällt. Und jetzt sind wir schon in einer Zeit in der VSync selbst schon veraltet ist, weil immer mehr Bildschirme Adaptive-Sync unterstützen.

serie300 schrieb:
Wenn ich die Arch von Wayland richtig verstehe
Zum Vergrößern anklicken....

Nein, tust du nicht. So ziemlich alles was du geschrieben hattest ist falsch, bzw. hat mit Wayland selbst nichts zu tun ;)

Azazyel schrieb:
(plus Features wie Netzwerktransparenz).
Zum Vergrößern anklicken....

Netzwerktransparenz ist übrigens auch nur so ein Checklisten-Feature der Kritiker... man braucht keine Netzwerk-Transparenz im Kern des Display-Servers, nur um ein Bild auf einen anderen PC zu übertragen.
 
-Nuke- schrieb:
Klar kann man sagen "das wird nie was", aber derweil kehre ich NVidia einfach den Rücken und kaufe Hardware von anderen Unternehmen, bei denen man nicht auf Steinzeit-Software festgelegt ist. Deine Probleme selbst kann ich in der Gänze übrigens selbst nicht nachvollziehen, aber ich vermute du hast eh kein Interesse daran das Problem zu untersuchen. Das Wayland+Compositoren bereits perfekt sind, sagt übrigens auch niemand.
Zum Vergrößern anklicken....
Tja, ich dagegen schon. Ich hab auf Arbeit ein Thinkpad T470s mit zwei externen Monitoren, OS Centos 7. Und immer wieder mal fällt eine Anzeige, machmal auch beide Anzeigen aus. I.d.R. sieht es aus, als ob der Monitor in den Schlafmodus geht, nur habe ich den weder angeordnet, noch lässt er sich beenden. Auf virtuelle Konsolen umschalten funktioniert ebenfalls nicht mehr, sodass ich die Kiste nur noch hart ausschalten kann.
Blöderweise ist das Verhalten nicht reproduzierbar, mal läuft die Kiste wochenlang und dann zickt sie wieder des öfteren rum.
Und auch ich bin davon massiv genervt... Beim letzten Mal hat mich der Mist bei nem Service-Upgrade erwischt. Zum Glück war es nur der DryRun und das eigentliche Upgrade habe ich dann in ner Tmux-Session durchgeführt.

Was die Netzwerktransparenz anbelangt, ist das für mich kein Checklisten-Feature. Bisher hat es einfach funktioniert und wird in der täglichen Arbeit genutzt.
 
foxit schrieb:
Ich habs nicht mehr auf dem Radar aber CentOS 7 ist wie alt? Und war da Wayland nicht als "Technology preview" gekennzeichnet? Ich hoffe nicht, dass dieser Thread jetzt zu einer Wayland Grunddiskussion wird.
Zum Vergrößern anklicken....
Nein, ganz sicher will ich keine Grundsatzdiskussion führen. :-)
Ich wollte nur kurz darstellen, dass Yamagi mit seinen Problemen nicht alleine ist. Und zum Thema CentOS 7, ja es ist gefühlt aus der Kreidezeit wird aber noch immer unterstützt, allerdings hatte ich die Probleme ebenfalls mit Fedora 29 und 30...
 
Bin gestern zufällig auf "devilutionX" gestoßen. Wer noch eine alte Diablo-CD hat, darf sich freuen. Habe es gerade installiert und angespielt, wirklich nett. Dürfte wohl auch mit jeder integrierten Grafiklösung laufen, da nur 2D.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben