Abo
  1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › Grafikunterstützung: KWin bald…

Ich kapiers nicht

  1. Thema

Neues Thema Ansicht wechseln


  1. Ich kapiers nicht

    Autor: ursfoum14 21.02.12 - 12:09

    Es muss doch möglich sein eine Schnittstelle zu schaffen die erweitert werden kann, und fehlende Funktionen der Hardware über Software nachbildet.
    Dann wird es halt langsamer. Aber es läuft weiter!
    So muss nicht gleich immer neue Hardware erworben müssen.
    Gerade bei Grafik unter Linux ist das ja alles andere als einfach ersatz zu finden. LEIDER!

    Das hat DirectX für Windows ja auch im Ursprung mal gemacht.

  2. Re: Ich kapiers nicht

    Autor: Gigadoc 2 21.02.12 - 13:42

    Also ich versuch jetzt mal mit meinem Halbwissen zu Antworten, kann sein dass ich völlig danebenliege, dann bitte nicht böse sein.

    Aber so wie ich das sehe ist OpenGL selbst diese Schnittstelle, ähnlich wie DirectX. Du kannst ja OpenGL auch per Software ausführen, ist halt dann nur langsam wie sonstwas.

    Was du ansprichst, wenn ich dich richtig verstehe, ist das Emulieren von OpenGL-Funktionen, die die Hardware nicht kann, durch Software. Dafür ist aber gar keine neue Zwischenschicht nötig, denn das wäre der Zuständigkeitsbereich des Grafiktreibers. Der ist ja dafür zuständig, die von OpenGL geforderten Funktionen auf der Grafikhardware, die intern vielleicht ganz anders tickt, umzusetzen. Der Treiber könnte dabei (und tun einige vielleicht schon) auch auf die CPU zurückgreifen. Es gibt ja auch Treiber um vollständig auf der CPU zu rendern.

    Das Problem für AMD-Nutzer ist also genau die Schnittstelle die du meinst, denn Probleme ergeben sich ja in diesem Fall durch die proprietäre Natur der fgrlx-Treiber. Dass dieser selbst auf neueren Karten nur OpenGL 1.0 unterstützt wusste ich gar nicht, aber dass die Linux-Unterstützung grausig ist, habe ich schon erfahren dürfen. Aber deswegen jetzt alle unsere Anwendungen mit OpenGL 1.0 kompatibel zu halten, ist für mich keine Lösung. Damit tun wir AMD ja eigentlich einen Gefallen, denn so können sie in Ruhe weiter machen, und es wird dann auch immer Linuxnutzer geben, die ihre Produkte kaufen.

    Bei Intel ist das ein wenig anders, denn dort ist die Hardware tatsächlich nicht in der Lage, neuere OpenGL-Funktionen bereitzustellen, aber hier per Software nachzuhelfen ist meines Ermessens nicht sinvoll, denn Systeme mit integrierten Intel-Grafikchipsätzen sind meist sowieso nicht so leistungsfähig. Auf denen muss man dann eben auf Effekte verzichten, wobei das ja auch nur auf ältere Systeme zutrifft.

    Jetzt noch eine Schicht zwischen Grafiktreiber und Anwendung zu schieben, um die Fehler der proprietären Software auszubügeln, halte ich für nicht umsetzbar (denn du weisst ja nicht was der Treiber eigentlich macht); und selbst wenn, wäre es klüger lieber direkt an den freien Treibern weiterzuarbeiten.

    Neue Hardware kaufen muss man sich wegen dieser Änderung allerdings nicht unbedingt. Wenn man Intel mal ausser Acht lässt, muss man schon sehr alte Hardware hervorkramen, um etwas zu finden was nicht OpenGL 2.0 kann. Die hat dann (wie auch im Artikel beschrieben) AGP- oder sogar noch PCI-Anschlüsse, und ist damit nur noch auf alten Systemen vorhanden, auf denen man sowieso keine Desktopeffekte (und vielleicht auch kein KDE) nutzen sollte.
    Nutzer von Nvidia-Karten, oder von freien AMD-Treibern müssen sich da keine Sorgen machen.

    Der Punkt Grafik ist unter Linux ja seit jeher problematisch und vieldiskutiert. Mein Motto war bisher, möglichst nur Nvidia-Grafik zu kaufen, auch wenn es etwas mehr kostet. Doch auch das ändert sich langsam, da Nvidia mit ihrem ziemlich stabilen Treiber zwar immer die neuste Version von X und OpenGL unterstützen, aber das längst überfällige KMS (und auch ein paar andere Dinge) nicht implementieren, den Support für Wayland von vorneherein verneinen, und die 2D-Performance immer schlechter wird. Zudem bastelt Nvidia ja gerne Eigenlösungen für schon vorhandene Dinge (wie TwinView), welche dann leicht für Verwirrung sorgen können.
    Im Moment würde ich also raten gerade keine neue Hardware zu kaufen, und auf die immer besser werdenden freien Treiber zu warten.
    Einige Distributionen, wie z.B. Arch, fangen ja bereits an die proprietären Treiber rauszuwerfen, fgrlx meist als erstes.

    Entweder holen die freien Treiber die proprietären irgendwann ein, oder einer der beiden Grafikriesen möchte sich doch noch die Gunst der Linuxgemeinde sichern, und überholt seine Treiber. Was ich auch nicht ausschliessen würde, ist dass Intel irgendwann Hardware rausbringt, die fähig genug ist, wenigstens die Funktionalität (sprich OpenGL, HDMI-Out, etc.) einer Nvidia oder AMD zu ersetzen.

  3. Re: Ich kapiers nicht

    Autor: nille02 21.02.12 - 17:15

    Gigadoc 2 schrieb:
    --------------------------------------------------------------------------------
    > Dass dieser selbst auf neueren Karten nur OpenGL 1.0
    > unterstützt wusste ich gar nicht, aber dass die Linux-Unterstützung grausig
    > ist, habe ich schon erfahren dürfen. Aber deswegen jetzt alle unsere
    > Anwendungen mit OpenGL 1.0 kompatibel zu halten, ist für mich keine Lösung.

    Der fglrx unterstützt OpenGL 3.3/4 per direct Rendering. KDE nutzt aber hier das indirect rendering was schon alt ist und eigentlich wegen der Performance schon lange nicht mehr genutzt wird. Und hier bietet AMD eben weil es nicht mehr genutzt wird nur OpenGL1.5 an.

    KDE (Martin Gräßlin) könnte nun entwerder seinen OpenGL 2+ Renderpfad Fixen oder sich mit AMD zusammen setzten das sie ihren Treiber fixen falls da der Fehler liegt. Oder er benutzt einfach die OpenGL ES 2.0 Implementierung des fglrx.

  4. Re: Ich kapiers nicht

    Autor: scroogie 22.02.12 - 09:36

    Unsinn, kwin kann auch Direct Rendering, nur fglrx nicht. Der Treiber ist blacklisted weil er eben nur Schrott produziert, visuelle Fehler wie Flackern usw. Mit "KWIN_DIRECT_GL=1 kwin --replace" kann man aber auch direct rendering mit fglrx aktivieren.

    > KDE (Martin Gräßlin) könnte nun entwerder seinen OpenGL 2+ Renderpfad
    > Fixen oder sich mit AMD zusammen setzten das sie ihren Treiber fixen falls
    > da der Fehler liegt.

    Der Pfad funktioniert einwandfrei, das Problem ist der Treiber. Kontakt mit AMD wurde wohl auch schon versucht, aber AMD bewegt sich da seit Jahren nicht. Jetzt durch den Blogpost gab es allerdings eine Antwort, siehe hier: http://ati.cchtml.com/show_bug.cgi?id=312

  5. Re: Ich kapiers nicht

    Autor: scroogie 22.02.12 - 09:40

    Übrigens hat Gnome die gleichen Probleme: http://ati.cchtml.com/show_bug.cgi?id=99

    Wenn man den bugtracker etwas durchgeht sieht man auch wo das Problem liegt...

  6. Re: Ich kapiers nicht

    Autor: nille02 22.02.12 - 11:17

    scroogie schrieb:
    --------------------------------------------------------------------------------
    > Übrigens hat Gnome die gleichen Probleme: ati.cchtml.com
    >
    > Wenn man den bugtracker etwas durchgeht sieht man auch wo das Problem
    > liegt...

    Dann ist doch alles klar. Aber dennoch ist es alles andere als Praktisch sich bei einem Bug Tracker zu melden der nicht von AMD kommt. Man kommt auch besser an jemanden von AMD ran.

  7. Re: Ich kapiers nicht

    Autor: scroogie 22.02.12 - 12:21

    Erzähl das mal den Leuten von AMD. Die wollen ja keinen eigenen einrichten. Wie kommt man denn besser an einen Mitarbeiter ran? Sicherlich nicht über die öffentlichen Mail-Adressen. Die gehen entweder in Kundensupport oder Marketing, und landen danach in Ablage P.

  8. Re: Ich kapiers nicht

    Autor: nille02 22.02.12 - 14:01

    KDE könnte sich auch einfach mal an AMD wenden um "Partner" zu werden. Dann hast du immer jemanden mit dem sie Reden können.

    Alternativ können sie versuchen direkt über RedHat einen an die Strippe zu bekommen.

    PS: Die Reports auf dem BugTracker sind leider oft nicht wirklich hilfreich.



    1 mal bearbeitet, zuletzt am 22.02.12 14:04 durch nille02.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Universität der Bundeswehr München, Neubiberg
  2. OSRAM Opto Semiconductors Gesellschaft mit beschränkter Haftung, Regensburg
  3. TÜV SÜD Gruppe, München
  4. ENGAGEMENT GLOBAL gGmbH, Bonn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u. a. Wolfenstein: Youngblood, Days Gone, Metro Exodus, World War Z)
  2. 2,99€
  3. 2,99€
  4. (-60%) 23,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Elektromobilität: Die Rohstoffe reichen, aber ...
Elektromobilität
Die Rohstoffe reichen, aber ...

Brennstoffzellenautos und Elektroautos sollen künftig die Autos mit Verbrennungsantrieb ersetzen und so den Straßenverkehr umweltfreundlicher machen. Dafür sind andere Rohstoffe nötig. Kritiker mahnen, dass es nicht genug davon gebe. Die Verfügbarkeit ist aber nur ein Aspekt.
Eine Analyse von Werner Pluta

  1. Himo C16 Xiaomi bringt E-Mofa mit zwei Sitzplätzen für rund 330 Euro
  2. ADAC-Test Hohe Zusatzkosten bei teuren Wallboxen möglich
  3. Elektroroller E-Scooter sollen in Berlin nicht mehr auf Gehwegen parken

Google Maps: Karten brauchen Menschen statt Maschinen
Google Maps
Karten brauchen Menschen statt Maschinen

Wenn Karten nicht mehr von Menschen, sondern allein von Maschinen erstellt werden, erfinden diese U-Bahn-Linien, Hochhäuser im Nationalpark und unmögliche Routen. Ein kurze Liste zu den Grenzen der Automatisierung.
Von Sebastian Grüner

  1. Kartendienst Google bringt AR-Navigation und Reiseinformationen in Maps
  2. Maps Duckduckgo mit Kartendienst von Apple
  3. Google Maps zeigt Bikesharing in Berlin, Hamburg, Wien und Zürich

Harmony OS: Die große Luftnummer von Huawei
Harmony OS
Die große Luftnummer von Huawei

Mit viel Medienaufmerksamkeit und großen Versprechungen hat Huawei sein eigenes Betriebssystem Harmony OS vorgestellt. Bei einer näheren Betrachtung bleibt von dem großen Wurf allerdings kaum etwas übrig.
Ein IMHO von Sebastian Grüner


    1. Apple: Mitarbeiter hörten bis zu 1.000 Siri-Schnipsel am Tag
      Apple
      Mitarbeiter hörten bis zu 1.000 Siri-Schnipsel am Tag

      Bevor Apple die Auswertung von Siri-Sprachdateien gestoppt hat, mussten Mitarbeiter in Irland teilweise bis zu 1.000 Audio-Schnipsel pro Schicht auswerten. Meist handelte es sich nur um Sprachkommandos, manchmal waren aber auch persönliche Informationen darunter.

    2. ISS: Sojus-Kapsel mit Roboter an Bord bricht Andockmanöver ab
      ISS
      Sojus-Kapsel mit Roboter an Bord bricht Andockmanöver ab

      Eine Sojus-Kapsel mit dem russischen Testroboter Fedor an Bord konnte nicht wie geplant an die ISS andocken - wegen eines Problems des automatisierten Andocksystems des Stationsmoduls. Ein zweiter Versuch ist bereits geplant.

    3. Raumfahrt: Nasa untersucht möglicherweise erstes Verbrechen im Weltraum
      Raumfahrt
      Nasa untersucht möglicherweise erstes Verbrechen im Weltraum

      Ein Scheidungskrieg scheint sich bis auf die ISS ausgeweitet zu haben: Die Astronautin Anne McClain hat von einem Computer der Raumstation auf das Onlinekonto ihrer Ex-Frau zugegriffen und deren Finanzen kontrolliert. Die Nasa untersucht das mutmaßlich erste Verbrechen im Weltraum.


    1. 14:15

    2. 13:19

    3. 12:43

    4. 13:13

    5. 12:34

    6. 11:35

    7. 10:51

    8. 10:27