News Zwei neue Entwickler für Linux Radeon Treiber

[Faust2011]

@Iapetos Danke. Ich betreibe derzeit mein Ubuntu in einer VM unter Windows, möchte aber auch wieder eine native Installation.

 

[Iapetos]

"Mentale Tiefflüge", das hat die Grenze zur Beleidigung meinem Empfinden nach deutlich überschritten.
Man kann sich auch kultiviert unterhalten und muss nicht persönlich werden.

Natürlich kann ich mich auch kultiviert unterhalten. Dein vorheriger Post erweckte in mir allerdings den Anschein, dass du am Gegenteil interessiert seist, denn Polemik und Pauschalitäten haben in einer kultivierten Unterhaltung nichts verloren. Nimm es bitte nicht persönlich, das hätte ich auch jedem anderen an den Kopf geworfen, der jenen Nonsens von sich gegeben hätte. Vielleicht kannst du mich ja in Zukunft mit mentalen Hochflügen von deiner Fähigkeit, kultivierte Unterhaltungen zu führen, überzeugen.


@Faust2011:

Gern, die Zeit nehme ich mir.

 

[tsingtao]

"Mentale Tiefflüge", das hat die Grenze zur Beleidigung meinem Empfinden nach deutlich überschritten.
Man kann sich auch kultiviert unterhalten und muss nicht persönlich werden.

Kann man. Sollte man.
Vor allem sollte man bzw. in diesem Fall du die folgende Regel beachten:
"Diskussionen werden mit Argumenten geführt, nicht mit Meinungen"

Nun gern weiter im Thema.

 

[blackiwid]

Auf die Gefahr hin dass das keiner mehr liest oder antwortet:

1. Abschauen von Treibern oder Spezificationen:

das ist ein Mythos, ja ich bin auch kein Treiberentwickler aber habe von solchen relativ Glaubhaft versichert bekommen, dass da keine Gefahr besteht.

Warum, Spezificationen fuer Treiberentwickler sind andere als fuer Hardwareinternas oder Fuer Hartwarehersteller. Diese lassen sich also nicht her nehmen um die eigene Hardware besser zu machen. Auch die Treiber lassen sich dadurch nicht besser machen da es ja keine Anleitung ist wie man etwas implementiert sondern nur jemanden die Schnittstellen darunterliegend die register oder was auch immer gibt die ihm ermoeglicht fuer diese hardware nen treiber zu erstellen das wissen wie man aber einen guten treiber schreibt ist davon los geloest.

offene Treiber bringen auch sehr wenig, da sie weitgehend Hardwareabhaengig sind und die Treiberarchitekturen sind auch sehr unterschiedlich. Wie man nen basalen Treiber programmiert ist eh kein Staatsgeheimnis. Klar es bringt jemand was wenn er module direkt rein laden kann weil man die gleiche treiberbasis benutzt wie z.B Gallium. Aber man kanns ja gut sehen der Intel Treiber ist Opensource und der von AMD trotzdem auch wenn man copy & pasten koennte legal ohne ende bleibt ueber jaher ein Abstand zwischen AMD und Intel.

Wenn die voneinander so viel abschreiben koennten haette es schon lange alianzen gegeben um 90% der Kosten fuer Treiberentwicklung zu sparen. Die Architekturen sind zu unterschiedlich.

Wo man eventuell VIELLEICHT abschauen koennte waere optimierungen fuer einzelne Spiele. Diese helfen bei den geschlossenen aber auch nur so viel weil die generischen Treiber an sich so scheisse sind das man so viel bei den optimierungen herau holen kann. Das Konzept hinter den freien waere aber eher die generischen Codepfade nahe an das ran zu bringen was die optimierungen dann erreichen. Hat nachteile man wird wahrscheinlich immer minimal langsamer bleiben wie die propreitaeren, aber ein neues spiel ohne speziele neue Treiber wird direkt recht ordentlich laufen, und auch spiele die vielleicht zu unbekannt sind das die treiber speziel drauf optimiert sind wuerden damit dann theoretisch scheller laufen.

2. Warum geben die Firmen dann die Treiber Specs nicht frei?

1. kontrolle warscheinlich haette jemand in 2minuten ne Freesync unterstuetzung ein gebaut in den nvidea treiber z.B.

2. Klagen, die Treiber haben oft von 3. Firmen Code drin oder nicht alles wuerde ueberprueft ob man gegen patente oder anderes verstossen koennte.

3. Warum steckt AMD dann nicht 99% der Resourcen in den freien Treiber und laesst den propr. langsam sterben?

AMD verteilt die Resourcen anhand der Nachfrage, das heisst das sie mehr Leute fuer Windows Treiberentwicklung nehmen zum einen aber auch fuer den proprietaeren.

Warum den propr. ? Weil der Spielemarkt unter Linux noch sehr klein ist der proprietaere ist eigentlich nicht in erster Linie fuer Gamer gedacht sondern fuer Workstation benutzer Leute die mit Grafikkarten Bitcoins minen oder Wetter berechnen oder aehnliches.

Diese speziellen Grafikkarten kosten 1000 euro oder so daher ist jeder verkauf so wichtig wie 10 Linux gamer. Die ja auch nicht grade heufig an zu treffen sind.

Gleichzeitig spielt hier aber auch wieder Kontrolle eine Rolle da sonst jeder im Treiber Funktionen dieser Serverkarten in billigeren Gamerkarten frei schalten kann.

Kurzum gaebe es nicht diese Workstation Kunden haette AMD schon lange den Focus staerker auf die freien Treiber gerichtet.

4. Haben nun die Einstellungen etwas mit Steam zu tun?

davon geh ich sehr stark aus, der freie Treiber wird zumindest langfristig fuer Gamer der Treiber werden der AMD ihnen liefern will. Da auch pesimistische schaetzungen zu steamos in absehbarer Zeit die Linux Gamer Anteile um hunderte prozent relativ absolut von 1 auf vielleicht 5% anheben wird passt das zu amds strategie der nachfrage entsprechend entwickler fuer Treiber ein zu stellen.

Es gibt btw auch einige andere Gruende den freien Treiber zu bevorzugen, neber besserer Presse, Kostenloses maintainen der alten Karten. Und neu Valve und vielleicht auch enginehersteller koennten auch kostenlos den freien Treiber verbessern. Valve hat das teilweise schon gemacht. selbst Spielehersteller koenten da interese haben und zum Treiber beitragen, warum weil ihre Spiele oefter verkauft werden wenn sie auf den Setups der Kunden gut laufen.

 

[UNDERESTIMATED]

Keine Ahnung, Videos abspielen ohne all zu große CPU Last geht. Ob da nun Qucksync genutzt wird und/oder Encoding damit möglich ist -> keine Ahnung.

Schade. Mir ginge es Hauptsächlich um das schnellere Umwandeln von Inhalten für spezielle Endgeräte oder Inhalte - CPU Last wäre mir relativ Gurke, solange (beim abspielen) nichts ruckelt/hängt.

So habe ich die Wahl: Bezahle ich für Windows, wo das problemlos geht, oder für Wowza, wo das dann mit Problemen (wie ich hörte, Achtung imho) auch gehen soll.

Klar, man könnte jetzt sagen ich bin geizig, allerdings bin ich noch nie ein Fan davon gewesen, für etwas doppelt/dreifach zu zahlen (Ich erkaufe mir die Funktion ja schon mit der iGPU die ich mitbezahle)

In einem Auto die Klimaautomatik nur nutzen zu dürfen, wenn man zusätzlich bezahlt kommt aufs selbe raus. Zumindest unter Windows geht das aber seit Januar, hätte dennoch eher damit gerechnet, dass sie das Request-Ticket von vor 2 Jahren mal eher bearbeiten. Die Rede ist von ffmpeg als Beispiel, da dieses auf beiden Plattformen nahezu identisch ist und somit für den Anwender relativ egal sein dürfte auf welcher Plattform es läuft.

Ich wäre aber auch bereit auf etwas gänzlich anderes zu setzen, sofern:Kostenlos und Quicksync Kompatibel.

So gesehen und sorry für OT, macht mir der Intel Treiber unter Windows mehr "Spass" und mir wäre es relativ ob der unter Linux nun offen oder zu ist, solange alle Funktionen drin sind, die ich mit der CPU gekauft habe.

Bin aber auch gespannt, sie AMD das angeht, bisher war es ja nun leider zumeist so, dass in den freien Treibern doch mehr als nur 1-2 Sachen fehlten. Meist genau die, die einen dazu bewegen, genau dieses Produkt zu erwerben.

 

[Faust2011]

Auf die Gefahr hin dass das keiner mehr liest oder antwortet:

Doch, hier!

1. Abschauen von Treibern oder Spezificationen[/B]: das ist ein Mythos, ja ich bin auch kein Treiberentwickler aber habe von solchen relativ Glaubhaft versichert bekommen, dass da keine Gefahr besteht.

Interessant, was Du da schreibst. Und ich könnte mir auch vorstellen, dass nicht im Treiber interessante Algorithmen/Hardwareadressen stecken, die der Konkurrenz was nutzen, sondern tatsächlich eine Ebene (aus Softwaresicht) drüber, also in der Anwendung.

2. Klagen, die Treiber haben oft von 3. Firmen Code drin oder nicht alles wuerde ueberprueft ob man gegen patente oder anderes verstossen koennte.

Dieses 'Problem' haben die meisten Software-Firmen und ist eigentlich eine pure Frage der Organisation. Man muss eben Klarheit darüber haben, welche Fremdsoftware man einbindet, unter welcher Lizenz diese läuft und den Lizenz-Bedingungen entsprechend Hinweise (o.ä.) mit seiner Software ausliefern. Aufwändig, aber machbar.

AMD verteilt die Resourcen anhand der Nachfrage, das heisst das sie mehr Leute fuer Windows Treiberentwicklung nehmen zum einen aber auch fuer den proprietaeren.

Definitiv! Der Linux-Markt ist nicht mit dem Win-Markt vergleichbar.

Warum den propr. ? Weil der Spielemarkt unter Linux noch sehr klein ist der proprietaere ist eigentlich nicht in erster Linie fuer Gamer gedacht sondern fuer Workstation benutzer Leute die mit Grafikkarten Bitcoins minen oder Wetter berechnen oder aehnliches.

Mich stört, dass Du in Deiner Aufzählung für die prof. User zuerst die Miner nennst Und warum bieten sie dann Features wie Videoplayback? Und ein zuverlässiges Resume aus dem Schlafzustand? Natürlich macht sowas einen Treiber erst rund, aber das sind keine Features, mit denen ich prof. Workstation-User gewinne, oder?

 

[Zehkul]

1. Abschauen von Treibern oder Spezificationen:

das ist ein Mythos, ja ich bin auch kein Treiberentwickler aber habe von solchen relativ Glaubhaft versichert bekommen, dass da keine Gefahr besteht.

Warum, Spezificationen fuer Treiberentwickler sind andere als fuer Hardwareinternas oder Fuer Hartwarehersteller. Diese lassen sich also nicht her nehmen um die eigene Hardware besser zu machen. Auch die Treiber lassen sich dadurch nicht besser machen da es ja keine Anleitung ist wie man etwas implementiert sondern nur jemanden die Schnittstellen darunterliegend die register oder was auch immer gibt die ihm ermoeglicht fuer diese hardware nen treiber zu erstellen das wissen wie man aber einen guten treiber schreibt ist davon los geloest.

Es geht ja auch nicht wirklich um den Treiberunterbau, sondern um die OpenGL Implementierung, und da kann sehr wohl abgeschaut werden. Das ist nicht hardwareabhängig und Nvidia hat extrem viel Arbeit in deren OpenGL Implementierung gesteckt, deshalb bin ich mir auch recht sicher dass die nicht allzu begeistert von Vulkan & co sind. Läuft einfach etwas gegen Nvidia Firmenkultur, möglichst viel in Software zu lösen, während AMD einfach nur gute Hardware bauen möchte und Treiberentwicklung am liebsten ganz weglassen würde.

Wo man eventuell VIELLEICHT abschauen koennte waere optimierungen fuer einzelne Spiele. Diese helfen bei den geschlossenen aber auch nur so viel weil die generischen Treiber an sich so scheisse sind das man so viel bei den optimierungen herau holen kann.

Die generischen Treiber sind nicht scheiße, gerade im Fall von Nvidia ist der schon ziemlich optimal, allerdings eben immer noch so ungemein komplex mit jeder Menge Heuristik, die versucht zu erraten, was das Spiel nun eigentlich machen will (nötig für opengl und direct3d!), dass für maximale Performance eben noch jemand von Nvidia drüberschauen muss.

Das Konzept hinter den freien waere aber eher die generischen Codepfade nahe an das ran zu bringen was die optimierungen dann erreichen.

Nicht möglich, aber dank Vulkan auch gar nicht mehr nötig.

2. Warum geben die Firmen dann die Treiber Specs nicht frei?

1. kontrolle warscheinlich haette jemand in 2minuten ne Freesync unterstuetzung ein gebaut in den nvidea treiber z.B.

Im Falle von Nvidia ist es in vielen Fällen auch einfach

xD

Deren Liebe zu proprietärem Unfug ist meines Erachtens teilweise schon wirklich irrational und schlicht imageschädigend. Bei Freesync sollten sie zum Beispiel einfach einsehen, dass sie ihren proprietären Kack nicht weiter pushen sollten.

Schade. Mir ginge es Hauptsächlich um das schnellere Umwandeln von Inhalten für spezielle Endgeräte oder Inhalte - CPU Last wäre mir relativ Gurke, solange (beim abspielen) nichts ruckelt/hängt.

Es interessiert sich niemand sonderlich für Hardwareencoding, weil Geschwindigkeit und Qualität deutlich hinter dem guten alten x264 liegen.

Dieses 'Problem' haben die meisten Software-Firmen und ist eigentlich eine pure Frage der Organisation.

Bingo. Und genau diese Organisation hat AMD für die aktuelle Generation auch gemacht. AMD ist was open source angeht eigentlich ziemlich perfekt organisiert mittlerweile, man sieht nur nicht allzu viel vom Fortschritt, weil sie mit dem AMDGPU Kernelmodul beschäftigt sind. Sobald das draußen ist, kann man, denke ich, auch day1 open source Support erwarten.

Mich stört, dass Du in Deiner Aufzählung für die prof. User zuerst die Miner nennst Und warum bieten sie dann Features wie Videoplayback? Und ein zuverlässiges Resume aus dem Schlafzustand? Natürlich macht sowas einen Treiber erst rund, aber das sind keine Features, mit denen ich prof. Workstation-User gewinne, oder?

Simple Antwort: Weil der Treiber das alles schon kann. Wirklich Arbeit wird nicht reingesteckt. Videoplayback? Meinst du Hardwaredecoding? Das ist eine ganz lustige Geschichte. Das kann Catalyst gar nicht, bzw. nur mit absolut vorsintflutlicher Technik (xvba), die kaum eine Software unterstützt, weshalb du das durch einen mehr oder weniger unfunktionalen Wrapper zu VA-API jagen musst.
Währenddessen hat der freie Treiber wunderschönen funktionierenden VDPAU Support.

 

[VikingGe]

Was am Ende bei den kommenden propietären AMD-Treibern auch interessant wird, ist, was da für eine OpenGL-Implementierung da zum Einsatz kommt. Mesa kann man für aktuelles GL ziemlich in die Tonne treten und die vom Catalyst ist jetzt auch nicht der Bringer... ob da mal was grundlegend überarbeitetes kommt?

Das ist nicht hardwareabhängig und Nvidia hat extrem viel Arbeit in deren OpenGL Implementierung gesteckt, deshalb bin ich mir auch recht sicher dass die nicht allzu begeistert von Vulkan & co sind.

Vulkan werden sie aber hoffentlich trotzdem unterstützen. NVidia darf auch ruhig mal auf die F..sse bekommen, wenn sie die die eigene Marktmacht überschätzen oder die der Konkurrenz unterschätzen.

 

[Zehkul]

Was am Ende bei den kommenden propietären AMD-Treibern auch interessant wird, ist, was da für eine OpenGL-Implementierung da zum Einsatz kommt. Mesa kann man für aktuelles GL ziemlich in die Tonne treten und die vom Catalyst ist jetzt auch nicht der Bringer... ob da mal was grundlegend überarbeitetes kommt?

Die Catalyst OpenGL Implementierung bleibt. AMD hat einfach nicht die Ressourcen, da etwas vollkommen Neues aus dem Boden zu stampfen. OpenGL ist extrem komplex und eine gute Implementierung kostet viel. Langfristig wird AMD wohl eher Mesa auf Windows einsetzen als dass sie etwas Neues zusammenschrauben. Aber was die langfristige Zukunft bringt ist eh vollkommen ungewiss, vielleicht gibt es dann gar kein OpenGL mehr, sondern irgendwelche anderen auf Vulkan basierenden High Level APIs. Oder gar eine freie OpenGL Implementierung auf Vulkanbasis. Wer weiß.

Vulkan werden sie aber hoffentlich trotzdem unterstützen. NVidia darf auch ruhig mal auf die F..sse bekommen, wenn sie die die eigene Marktmacht überschätzen oder die der Konkurrenz unterschätzen.

Sie unterstützen es, was mich auch etwas überrascht hat. Ich hätte da mehr Torpedierversuche erwartet. Aber natürlich wissen wir nicht, was intern bei Khronos alles vorgefallen ist, und mit Valve wollen sie es sich vermutlich auch nicht verscherzen.

 

[Wolfsrabe]

Ich wollte schon fragen wie es mit dem Thema "Blender - Cycles - GPU Rendering - AMD -(Linux)" weitergeht, aber so wie ich das in dem einen oder anderen Blender-Foren herauslese, hat das wohl wenig mit dem Treiber zu tun. Wohl noch nicht mal mit Vulcan, obwohl es schon irgendwie um OpenCL geht...

So oder so, ich freue mich daß AMD hier weitermacht.

 

[think->write!]

Sie unterstützen es, was mich auch etwas überrascht hat. Ich hätte da mehr Torpedierversuche erwartet. Aber natürlich wissen wir nicht, was intern bei Khronos alles vorgefallen ist, und mit Valve wollen sie es sich vermutlich auch nicht verscherzen.

Mal geschaut wer alles entweder bei HSA Foundation dabei ist oder bei Mantle mitgemacht hat, dann bleibt kaum wer übrig welcher gegen Vulkan sein könnte, Mantle udn HSA supporter vereint ziemlich viel von den betroffenen Märkten, da ist selbst Intel kein grosser Fisch.