Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
AMD und die Grafik...
7 views
Skip to first unread message
Sieghard Schicktanz
Apr 29, 2012, 4:28:54 PM4/29/12
to
Hallo beinand'
so, damit wär' so ziemlich die letzte Hürde beim Umbau meiner Kiste auf die
neue Hauptplatine genommen.
Nachedem mit "tatkräftiger Mithilfe" von grml EFI beigegeben und einen
Boot-Eintrag zugelassen hat, war im wesentlichen noch eine Baustelle die
neue Grafik-, naja, nicht -Karte, sondern schon integriert. Eine AMD-Ati,
aus der Radeon-Reihe, die vor langen Jahren mal bei München am Starnberger
See ihren Ursprung genommen hat... ;-)
lspci -nn listet die so:
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
nee ATI BeaverCreek [Radeon HD 6530D] [1002:964a]
Nett, nicht? Vor allem das "née";-)
Der erste Ansatz mit dem Radeon-Treiber im Kernel hat bei Xorg nur den
VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht. Auch nicht nach
diversen Überredungsversuchen, es blieb bei VESA.
Aber es gibt da doch den schönen originalen Hersteller-Treiber mit dem
dekorativen Namen "fglrx". Der soll sogar schon diesen Chip unterstützen,
und das sogar im Kernel im Textmode. Also holen und ...
Ja, holen - Arch bietet den nicht an, also vom Hersteller. Der ist da sogar
zu finden, und sogar für mein (immer noch) 32-bittiges System. Nach
Runterladen ans Kompilieren gehen - geht nicht. Na schön, er stört sich am
Radeon-Treiber im Kernel. Also 'runter in'n Textmode, Radeon nicht
mitgeladen, neu versucht. Geht nicht - Fehler beim Kompilieren. Es fehlt
ein Symbol, "TS_USEDFPU". Häh?
Also Suche danach - jibtsnich. Was soll das?
Also internet - doch, das Problem ist schon bekannt, das Symbol gibt's
nicht bei den neueren Kerneln, nicht mehr bei meinem (inzwischen) 3.3er.
Und es gibt sogar einen Patch, zwei Patches, und einen dritten, der den
zweiten automatisiert.
Ja, aber wie einbauen? Patch während der Bearbeitung anwenden geht nicht -
das File ist geändert, aber benutzt wird trotzdem das unveränderte!? Kann
doch nicht sein - Sucherei - jawashamdiedenn da gemacht? Da wird zwar das
ganze Archiv schön in ein Zwischenverzeichnis entpackt, aber _garbeitet_
wird dann aus einem ganz _anderen_ Verzeichnis! Das steck im Modul-
Verzeichnis und bleibt dort auch liegen, aber Hinweis drauf gibt's im
Installationsprozess keinen, nichtmal im ausgegebenen Log...
Nagut, dann erstmal Verfahrensmöglichkeit gesucht, den Installationsprozess
zu übertölpeln - es gibt die Option, das Archiv nur zu entpacken, dort kann
dann gepatcht werden. Es gibt dann aber keine Option, das von dort zu
kompilieren - sehr schlau ausgedacht. Man muß sich da erstmal das
zuständige Skript im Shell-Archiv suchen (ati-installer.sh), seine
Parameter ausfindig machen und decodieren (es möchte als erstes die
Versionsnummer - nicht die, dieim Namen steht, sondern die des Treibers
selber - und dann die Aktion), dann kann das Kompilieren laufen. Damit
geht's dann, aber bevor alles fertig ist, muß noch in einem weiteren
Verzeichnis ein Installationsskript aufgerufen werden - _das_ steht
allerdings sogar direkt im Kompilier-Log.
Danach ist derTextmode kaputt. D.h. die Auflösung stimmt nicht mehr für
meinen Monitor (1600x1200), es wird nur in 1280x1024 angezeigt und läßt sich
in keiner Weise beeinflussen. Unschön. Naja, der Aufwand war ja auch für
X11 gedacht, also testen. Nach einigem Probieren, weil sich der Xorg-Server
reichlich ziert, das Ergebnis: geht nicht.
Nagut, wir haben ja noch einen anderen Patch. Probiert, selbiges Ergebnis:
_Es geht nicht_.
Also wieder VESA eingebaut (inzwischen ist die Xorg-Konfiguration für die
Tests so flexibilisiert, daß da nur noch eine Datei zu kopieren ist;), und
wieder im internet gesucht. Ja, auch _der_ Fehler ist bekannt, aber nur in
ganz anderen Zusammenhängen, mit kdm und so, was ich nicht habe.
Aber da gibt's auch noch einen Bug-Report, der genau mein Problem enthält,
und da gibt's ein paar Kommentare, die die Ursache diskutieren: Xorg.
Xorg hat mal wieder am Server gedreht und eine Inkompatibilität eingebaut,
ab Version 1.12 funktioniert der fglrx-Treiber nicht mehr, er steigt mit
einem "signal 11 (Segmentation fault)" aus. Mit der Vorversion soll's noch
gegangen sein...
Und ich hatte grade alles für das neue Brett "upgedatet" - hicks
('tschullng, bei dem Ausdruck muß ich immer aufstoßen;).
Naschön, kann man ja mal probieren - also alten X-Server wieder reaktiviert.
Ja, was der so alles mitzieht... Aber schließlich ist alles vorhanden und
konsistent, und jetzt noch den flglrx "einladen" - und er kommt!
Funktioniert also alles, nach kaum ein paar Tagen 'rumwerkeln an diversen
Systemfehlern und -inkonsistenzen läßt sich auch ein Linux mit X11 auf
einem aktuellen Mainboard mit AMD-Ati-Grafik richtig betreiben!
Zwar geht die Textmode-Darstellung nicht richtig, KMS wird da großzügig
ignoriert (aber vorausgesetzt), aber unter X11 funktioniert die Karte.
Man darf nur keinen Xorg-Server >= 1.12 benutzen und muß der Treiber-
Installation hinterlistig den _richtigen_ Patch unterschieben, den nämlich,
der die drei Zeilen in der Funktion mit dem Symbol "TS_USEDFPU", die für
32-Bit-Systeme sein sollen, durch zwei andere, ähnliche Zeilen ersetzt. (Der
andere Patch, der einfach die gleiche Funktion wie bei 64-Bit-Systemen
einfügt, funktioniert bei mir _nicht_.)
Alles ganz einfach. Wenn man weiß, wie man's machen muß.
Aber trotzdem furchtbar unnötig umständlich, und obwohl die Fehler bekannt
sind, wurde nicht mal bei der während der o.g. Aktivitäten erschienen
_neuen_ Version des fglrx von AMD das Problem beseitigt. Aber deren
Entwickler haben anscheinend keinen internet-Zugang, das machen dort wohl
die Kaufleute. Ähnlich läuft's scheint's bei Xorg, da sind's dann wohl eher
die Juristen, die das letzte Wort haben...
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
so, damit wär' so ziemlich die letzte Hürde beim Umbau meiner Kiste auf die
neue Hauptplatine genommen.
Nachedem mit "tatkräftiger Mithilfe" von grml EFI beigegeben und einen
Boot-Eintrag zugelassen hat, war im wesentlichen noch eine Baustelle die
neue Grafik-, naja, nicht -Karte, sondern schon integriert. Eine AMD-Ati,
aus der Radeon-Reihe, die vor langen Jahren mal bei München am Starnberger
See ihren Ursprung genommen hat... ;-)
lspci -nn listet die so:
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
nee ATI BeaverCreek [Radeon HD 6530D] [1002:964a]
Nett, nicht? Vor allem das "née";-)
Der erste Ansatz mit dem Radeon-Treiber im Kernel hat bei Xorg nur den
VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht. Auch nicht nach
diversen Überredungsversuchen, es blieb bei VESA.
Aber es gibt da doch den schönen originalen Hersteller-Treiber mit dem
dekorativen Namen "fglrx". Der soll sogar schon diesen Chip unterstützen,
und das sogar im Kernel im Textmode. Also holen und ...
Ja, holen - Arch bietet den nicht an, also vom Hersteller. Der ist da sogar
zu finden, und sogar für mein (immer noch) 32-bittiges System. Nach
Runterladen ans Kompilieren gehen - geht nicht. Na schön, er stört sich am
Radeon-Treiber im Kernel. Also 'runter in'n Textmode, Radeon nicht
mitgeladen, neu versucht. Geht nicht - Fehler beim Kompilieren. Es fehlt
ein Symbol, "TS_USEDFPU". Häh?
Also Suche danach - jibtsnich. Was soll das?
Also internet - doch, das Problem ist schon bekannt, das Symbol gibt's
nicht bei den neueren Kerneln, nicht mehr bei meinem (inzwischen) 3.3er.
Und es gibt sogar einen Patch, zwei Patches, und einen dritten, der den
zweiten automatisiert.
Ja, aber wie einbauen? Patch während der Bearbeitung anwenden geht nicht -
das File ist geändert, aber benutzt wird trotzdem das unveränderte!? Kann
doch nicht sein - Sucherei - jawashamdiedenn da gemacht? Da wird zwar das
ganze Archiv schön in ein Zwischenverzeichnis entpackt, aber _garbeitet_
wird dann aus einem ganz _anderen_ Verzeichnis! Das steck im Modul-
Verzeichnis und bleibt dort auch liegen, aber Hinweis drauf gibt's im
Installationsprozess keinen, nichtmal im ausgegebenen Log...
Nagut, dann erstmal Verfahrensmöglichkeit gesucht, den Installationsprozess
zu übertölpeln - es gibt die Option, das Archiv nur zu entpacken, dort kann
dann gepatcht werden. Es gibt dann aber keine Option, das von dort zu
kompilieren - sehr schlau ausgedacht. Man muß sich da erstmal das
zuständige Skript im Shell-Archiv suchen (ati-installer.sh), seine
Parameter ausfindig machen und decodieren (es möchte als erstes die
Versionsnummer - nicht die, dieim Namen steht, sondern die des Treibers
selber - und dann die Aktion), dann kann das Kompilieren laufen. Damit
geht's dann, aber bevor alles fertig ist, muß noch in einem weiteren
Verzeichnis ein Installationsskript aufgerufen werden - _das_ steht
allerdings sogar direkt im Kompilier-Log.
Danach ist derTextmode kaputt. D.h. die Auflösung stimmt nicht mehr für
meinen Monitor (1600x1200), es wird nur in 1280x1024 angezeigt und läßt sich
in keiner Weise beeinflussen. Unschön. Naja, der Aufwand war ja auch für
X11 gedacht, also testen. Nach einigem Probieren, weil sich der Xorg-Server
reichlich ziert, das Ergebnis: geht nicht.
Nagut, wir haben ja noch einen anderen Patch. Probiert, selbiges Ergebnis:
_Es geht nicht_.
Also wieder VESA eingebaut (inzwischen ist die Xorg-Konfiguration für die
Tests so flexibilisiert, daß da nur noch eine Datei zu kopieren ist;), und
wieder im internet gesucht. Ja, auch _der_ Fehler ist bekannt, aber nur in
ganz anderen Zusammenhängen, mit kdm und so, was ich nicht habe.
Aber da gibt's auch noch einen Bug-Report, der genau mein Problem enthält,
und da gibt's ein paar Kommentare, die die Ursache diskutieren: Xorg.
Xorg hat mal wieder am Server gedreht und eine Inkompatibilität eingebaut,
ab Version 1.12 funktioniert der fglrx-Treiber nicht mehr, er steigt mit
einem "signal 11 (Segmentation fault)" aus. Mit der Vorversion soll's noch
gegangen sein...
Und ich hatte grade alles für das neue Brett "upgedatet" - hicks
('tschullng, bei dem Ausdruck muß ich immer aufstoßen;).
Naschön, kann man ja mal probieren - also alten X-Server wieder reaktiviert.
Ja, was der so alles mitzieht... Aber schließlich ist alles vorhanden und
konsistent, und jetzt noch den flglrx "einladen" - und er kommt!
Funktioniert also alles, nach kaum ein paar Tagen 'rumwerkeln an diversen
Systemfehlern und -inkonsistenzen läßt sich auch ein Linux mit X11 auf
einem aktuellen Mainboard mit AMD-Ati-Grafik richtig betreiben!
Zwar geht die Textmode-Darstellung nicht richtig, KMS wird da großzügig
ignoriert (aber vorausgesetzt), aber unter X11 funktioniert die Karte.
Man darf nur keinen Xorg-Server >= 1.12 benutzen und muß der Treiber-
Installation hinterlistig den _richtigen_ Patch unterschieben, den nämlich,
der die drei Zeilen in der Funktion mit dem Symbol "TS_USEDFPU", die für
32-Bit-Systeme sein sollen, durch zwei andere, ähnliche Zeilen ersetzt. (Der
andere Patch, der einfach die gleiche Funktion wie bei 64-Bit-Systemen
einfügt, funktioniert bei mir _nicht_.)
Alles ganz einfach. Wenn man weiß, wie man's machen muß.
Aber trotzdem furchtbar unnötig umständlich, und obwohl die Fehler bekannt
sind, wurde nicht mal bei der während der o.g. Aktivitäten erschienen
_neuen_ Version des fglrx von AMD das Problem beseitigt. Aber deren
Entwickler haben anscheinend keinen internet-Zugang, das machen dort wohl
die Kaufleute. Ähnlich läuft's scheint's bei Xorg, da sind's dann wohl eher
die Juristen, die das letzte Wort haben...
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Andreas Hartmann
Apr 30, 2012, 1:57:27 AM4/30/12
to
Sieghard Schicktanz schrieb:
> Hallo beinand'
[...]
[...]
> Ja, holen - Arch bietet den nicht an, also vom Hersteller. Der ist da sogar
> zu finden, und sogar für mein (immer noch) 32-bittiges System. Nach
> Runterladen ans Kompilieren gehen - geht nicht. Na schön, er stört sich am
> Radeon-Treiber im Kernel. Also 'runter in'n Textmode, Radeon nicht
> mitgeladen, neu versucht. Geht nicht - Fehler beim Kompilieren. Es fehlt
> ein Symbol, "TS_USEDFPU". Häh?
Falsche Distri :-). Hättest mal openSUSE verwendet, hättest Dir viel
Zeit erspart. Siehe:
http://www.sebastian-siebert.de/2012/04/25/opensuse-proprietaeren-grafik-treiber-amd-catalyst-12-4-als-rpm-installieren/
>
> Also Suche danach - jibtsnich. Was soll das?
> Also internet - doch, das Problem ist schon bekannt, das Symbol gibt's
> nicht bei den neueren Kerneln, nicht mehr bei meinem (inzwischen) 3.3er.
> Und es gibt sogar einen Patch, zwei Patches, und einen dritten, der den
> zweiten automatisiert.
Bekannt. Reife Leistung von Torvalds:
http://www.sebastian-siebert.de/2012/03/07/opensuse-proprietaeren-grafik-treiber-amd-catalyst-12-2-als-rpm-installieren/
[...]
> Xorg hat mal wieder am Server gedreht und eine Inkompatibilität eingebaut,
> ab Version 1.12 funktioniert der fglrx-Treiber nicht mehr, er steigt mit
Auch bekannt :-).
[...]
> Naschön, kann man ja mal probieren - also alten X-Server wieder reaktiviert.
> Ja, was der so alles mitzieht... Aber schließlich ist alles vorhanden und
> konsistent, und jetzt noch den flglrx "einladen" - und er kommt!
>
> Funktioniert also alles, nach kaum ein paar Tagen 'rumwerkeln an diversen
> Systemfehlern und -inkonsistenzen läßt sich auch ein Linux mit X11 auf
> einem aktuellen Mainboard mit AMD-Ati-Grafik richtig betreiben!
>
> Zwar geht die Textmode-Darstellung nicht richtig, KMS wird da großzügig
> ignoriert (aber vorausgesetzt),
fglrx unterstützt kein kms - das muß explizit abgeschaltet sein. V.a.
auch in der initrd (das wird manchmal vergessen).
[...]
> Alles ganz einfach. Wenn man weiß, wie man's machen muß.
> Aber trotzdem furchtbar unnötig umständlich, und obwohl die Fehler bekannt
> sind, wurde nicht mal bei der während der o.g. Aktivitäten erschienen
> _neuen_ Version des fglrx von AMD das Problem beseitigt. Aber deren
> Entwickler haben anscheinend keinen internet-Zugang, das machen dort wohl
> die Kaufleute.
Du beschimpfst die Falschen ... .
> Ähnlich läuft's scheint's bei Xorg, da sind's dann wohl eher
> die Juristen, die das letzte Wort haben...
Gruß,
Andreas
> Hallo beinand'
[...]
> lspci -nn listet die so:
> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices
> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices
> nee ATI BeaverCreek [Radeon HD 6530D] [1002:964a]
> Der erste Ansatz mit dem Radeon-Treiber im Kernel hat bei Xorg nur den
> VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht. Auch nicht nach
> diversen Überredungsversuchen, es blieb bei VESA.
nicht überraschend.
> VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht. Auch nicht nach
> diversen Überredungsversuchen, es blieb bei VESA.
[...]
> Ja, holen - Arch bietet den nicht an, also vom Hersteller. Der ist da sogar
> zu finden, und sogar für mein (immer noch) 32-bittiges System. Nach
> Runterladen ans Kompilieren gehen - geht nicht. Na schön, er stört sich am
> Radeon-Treiber im Kernel. Also 'runter in'n Textmode, Radeon nicht
> mitgeladen, neu versucht. Geht nicht - Fehler beim Kompilieren. Es fehlt
> ein Symbol, "TS_USEDFPU". Häh?
Zeit erspart. Siehe:
http://www.sebastian-siebert.de/2012/04/25/opensuse-proprietaeren-grafik-treiber-amd-catalyst-12-4-als-rpm-installieren/
>
> Also Suche danach - jibtsnich. Was soll das?
> Also internet - doch, das Problem ist schon bekannt, das Symbol gibt's
> nicht bei den neueren Kerneln, nicht mehr bei meinem (inzwischen) 3.3er.
> Und es gibt sogar einen Patch, zwei Patches, und einen dritten, der den
> zweiten automatisiert.
http://www.sebastian-siebert.de/2012/03/07/opensuse-proprietaeren-grafik-treiber-amd-catalyst-12-2-als-rpm-installieren/
[...]
> Xorg hat mal wieder am Server gedreht und eine Inkompatibilität eingebaut,
> ab Version 1.12 funktioniert der fglrx-Treiber nicht mehr, er steigt mit
[...]
> Naschön, kann man ja mal probieren - also alten X-Server wieder reaktiviert.
> Ja, was der so alles mitzieht... Aber schließlich ist alles vorhanden und
> konsistent, und jetzt noch den flglrx "einladen" - und er kommt!
>
> Funktioniert also alles, nach kaum ein paar Tagen 'rumwerkeln an diversen
> Systemfehlern und -inkonsistenzen läßt sich auch ein Linux mit X11 auf
> einem aktuellen Mainboard mit AMD-Ati-Grafik richtig betreiben!
>
> Zwar geht die Textmode-Darstellung nicht richtig, KMS wird da großzügig
> ignoriert (aber vorausgesetzt),
auch in der initrd (das wird manchmal vergessen).
[...]
> Alles ganz einfach. Wenn man weiß, wie man's machen muß.
> Aber trotzdem furchtbar unnötig umständlich, und obwohl die Fehler bekannt
> sind, wurde nicht mal bei der während der o.g. Aktivitäten erschienen
> _neuen_ Version des fglrx von AMD das Problem beseitigt. Aber deren
> Entwickler haben anscheinend keinen internet-Zugang, das machen dort wohl
> die Kaufleute.
> Ähnlich läuft's scheint's bei Xorg, da sind's dann wohl eher
> die Juristen, die das letzte Wort haben...
Andreas
Thomas Richter
Apr 30, 2012, 2:34:10 AM4/30/12
to
Am 29.04.2012 22:28, schrieb Sieghard Schicktanz:
> Hallo beinand'
/* snip */
> Alles ganz einfach. Wenn man weiß, wie man's machen muß.
> Aber trotzdem furchtbar unnötig umständlich, und obwohl die Fehler bekannt
> sind, wurde nicht mal bei der während der o.g. Aktivitäten erschienen
> _neuen_ Version des fglrx von AMD das Problem beseitigt. Aber deren
> Entwickler haben anscheinend keinen internet-Zugang, das machen dort wohl
> die Kaufleute. Ähnlich läuft's scheint's bei Xorg, da sind's dann wohl eher
> die Juristen, die das letzte Wort haben...
Herzliches Beileid. Da haben wir mal wieder das Hauptproblem von Linux:
Man ist sich zu schade, mal irgendein Interface stabil zu halten, gegen
das man programmieren könnte - alle paar Monate wird etwas geändert. Ja,
ich benutze Linux selbst.
Grüße,
Thomas
> Hallo beinand'
/* snip */
> Alles ganz einfach. Wenn man weiß, wie man's machen muß.
> Aber trotzdem furchtbar unnötig umständlich, und obwohl die Fehler bekannt
> sind, wurde nicht mal bei der während der o.g. Aktivitäten erschienen
> _neuen_ Version des fglrx von AMD das Problem beseitigt. Aber deren
> Entwickler haben anscheinend keinen internet-Zugang, das machen dort wohl
> die Kaufleute. Ähnlich läuft's scheint's bei Xorg, da sind's dann wohl eher
> die Juristen, die das letzte Wort haben...
Man ist sich zu schade, mal irgendein Interface stabil zu halten, gegen
das man programmieren könnte - alle paar Monate wird etwas geändert. Ja,
ich benutze Linux selbst.
Grüße,
Thomas
Joseph Terner
Apr 30, 2012, 4:49:53 AM4/30/12
to
On Sun, 29 Apr 2012 22:28:54 +0200, Sieghard Schicktanz wrote:
> [...] der Radeon-Treiber mochte nicht.
> [...] Aber es gibt [...] "fglrx".
> [...] Arch bietet den nicht an,
> [...] Fehler beim Kompilieren. Es fehlt ein Symbol, "TS_USEDFPU". Häh?
> [...] Symbol gibt's nicht [...] bei meinem (inzwischen) 3.3er.
Fazit: Rolling Release + BLOB = Schmerzen.
> Funktioniert also alles, nach kaum ein paar Tagen 'rumwerkeln an
> diversen Systemfehlern und -inkonsistenzen läßt sich auch ein Linux mit
> X11 auf einem aktuellen Mainboard mit AMD-Ati-Grafik richtig betreiben!
Was Du erwählst, wird Dir zuteil. ;-)
ciao, Joseph
> [...] der Radeon-Treiber mochte nicht.
> [...] Aber es gibt [...] "fglrx".
> [...] Arch bietet den nicht an,
> [...] Fehler beim Kompilieren. Es fehlt ein Symbol, "TS_USEDFPU". Häh?
> [...] Symbol gibt's nicht [...] bei meinem (inzwischen) 3.3er.
Fazit: Rolling Release + BLOB = Schmerzen.
> Funktioniert also alles, nach kaum ein paar Tagen 'rumwerkeln an
> diversen Systemfehlern und -inkonsistenzen läßt sich auch ein Linux mit
> X11 auf einem aktuellen Mainboard mit AMD-Ati-Grafik richtig betreiben!
ciao, Joseph
Clemens Ladisch
Apr 30, 2012, 6:35:08 AM4/30/12
to
Sieghard Schicktanz schrieb:
wenn es nicht zu offensichtlich ist, wird der Moderator es auch annehmen).
Der Biberbach sollte seit Kernel 3.0 unterstützt werden.
> Der erste Ansatz mit dem Radeon-Treiber im Kernel hat bei Xorg nur den
> VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht.
Gibt es zu dem "mochte nicht" irgendeine Fehlermeldung? (dmesg)
Der Kernel hat hoffentlich alle notwendigen Schalter wie CONFIG_AGP_AMD64,
CONFIG_DRM_RADEON, CONFIG_FB_RADEON, CONFIG_FRAMEBUFFER_CONSOLE, und
CONFIG_FIRMWARE_IN_KERNEL, und /lib/firmware/radeon/SUMO_*.bin existiert?
> Aber es gibt da doch den schönen originalen Hersteller-Treiber
Aber die Fehlersuche war wohl nicht so schön wie beim Kernel-Treiber ...
Gruß
Clemens
> lspci -nn listet die so:
> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
> nee ATI BeaverCreek [Radeon HD 6530D] [1002:964a]
> Nett, nicht? Vor allem das "née";-)
Auf pciids.sf.net kann man jeden beliebigen Blödsinn reinschreiben (und
> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
> nee ATI BeaverCreek [Radeon HD 6530D] [1002:964a]
> Nett, nicht? Vor allem das "née";-)
wenn es nicht zu offensichtlich ist, wird der Moderator es auch annehmen).
Der Biberbach sollte seit Kernel 3.0 unterstützt werden.
> Der erste Ansatz mit dem Radeon-Treiber im Kernel hat bei Xorg nur den
> VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht.
Der Kernel hat hoffentlich alle notwendigen Schalter wie CONFIG_AGP_AMD64,
CONFIG_DRM_RADEON, CONFIG_FB_RADEON, CONFIG_FRAMEBUFFER_CONSOLE, und
CONFIG_FIRMWARE_IN_KERNEL, und /lib/firmware/radeon/SUMO_*.bin existiert?
> Aber es gibt da doch den schönen originalen Hersteller-Treiber
Gruß
Clemens
Marcel Müller
Apr 30, 2012, 8:10:57 AM4/30/12
to
Hallo,
On 30.04.2012 07:57, Andreas Hartmann wrote:
> fglrx unterstützt kein kms - das muß explizit abgeschaltet sein. V.a.
> auch in der initrd (das wird manchmal vergessen).
? - ich habe die Tage ein Ubuntu mit AMD Board installiert. Die Grafik
ging sowohl mit dem eingebauten Treiber als auch mit Catalyst. Es war
allerdings die letzte LTS-Version, also 10.04, falls das einen
Unterschied macht. An KMS habe ich nicht herum gespielt. Hätte das
schief gehen müssen?
Es hat mich nur eine Weile gekostet, biss ich die Bildwiderholfrequenz
auf CRT-Niveau bekommen habe. Aber das war bei Matrox nicht anders. Vor
allem wenn man hochwertige BNC-Kabel nutzt, stellt sich Linux
mittlerweile genauso bockig wie einst Win95.
Das einzige, was mit Catalyst immer wieder Bildfehler produzierte: ich
hatte auf dem System mit 4GB RAM und aktivierten Memory-Remapping (also
faktisch mehr als 4GB) versehentlich die 32-Bit Version von Ubuntu
erwischt. Ich wusste nicht, dass bereits die CD eine andere ist. Nochmal
neu mit 64 Bit installiert, und die Fehler waren verschwunden.
Marcel
On 30.04.2012 07:57, Andreas Hartmann wrote:
> fglrx unterstützt kein kms - das muß explizit abgeschaltet sein. V.a.
> auch in der initrd (das wird manchmal vergessen).
ging sowohl mit dem eingebauten Treiber als auch mit Catalyst. Es war
allerdings die letzte LTS-Version, also 10.04, falls das einen
Unterschied macht. An KMS habe ich nicht herum gespielt. Hätte das
schief gehen müssen?
Es hat mich nur eine Weile gekostet, biss ich die Bildwiderholfrequenz
auf CRT-Niveau bekommen habe. Aber das war bei Matrox nicht anders. Vor
allem wenn man hochwertige BNC-Kabel nutzt, stellt sich Linux
mittlerweile genauso bockig wie einst Win95.
Das einzige, was mit Catalyst immer wieder Bildfehler produzierte: ich
hatte auf dem System mit 4GB RAM und aktivierten Memory-Remapping (also
faktisch mehr als 4GB) versehentlich die 32-Bit Version von Ubuntu
erwischt. Ich wusste nicht, dass bereits die CD eine andere ist. Nochmal
neu mit 64 Bit installiert, und die Fehler waren verschwunden.
Marcel
Andreas Hartmann
Apr 30, 2012, 11:48:12 AM4/30/12
to
Hallo Marcel!
Marcel Müller schrieb:
u.a. die Auflösung bereits beim Booten (also auf der Textkonsole) setzt.
Hierzu muß das entsprechende Module geladen sein (hier:radeon).
Zumindest bei openSUSE geschieht das bereits in der initrd. Ich denke,
das ist bei anderen Distris nicht anders (zumindest solange ein BIOS
vorliegt).
Wenn in der initrd bereits radeon geladen wurde, kann man hinterher
nicht zusätzlich fglrx aktivieren - das geht schief.
Die Installationsroutinen unterstützen genau diese Problematik und
stellen sicher, daß das nicht passiert (vorausgesetzt, sie sind auf die
jeweilige Distri und Version korrekt abgestimmt).
Wenn Du also eine supportete und funktionierende Installation
vorgenommen hast, solltest Du auf dieses Problem nicht gestoßen sein.
Ich hatte das nur deshalb erwähnt, weil es im Eifer des Gefechts gerne
mal vergessen wird, wenn man gezwungen ist, selbst an der Installation
zu arbeiten.
> Es hat mich nur eine Weile gekostet, biss ich die Bildwiderholfrequenz
> auf CRT-Niveau bekommen habe. Aber das war bei Matrox nicht anders. Vor
> allem wenn man hochwertige BNC-Kabel nutzt, stellt sich Linux
> mittlerweile genauso bockig wie einst Win95.
Ich glaube, daß Du hiermit nicht mehr zum erlauchten Kreis der 08/15
User gehörst (wie auch immer der definiert sein sollte). :-)
> Das einzige, was mit Catalyst immer wieder Bildfehler produzierte: ich
> hatte auf dem System mit 4GB RAM und aktivierten Memory-Remapping (also
> faktisch mehr als 4GB) versehentlich die 32-Bit Version von Ubuntu
> erwischt. Ich wusste nicht, dass bereits die CD eine andere ist. Nochmal
> neu mit 64 Bit installiert, und die Fehler waren verschwunden.
Danke für die Info! Weil ich dazu tendiere, auf 64bit-Hardware auch
64Bit-Software zu verwenden, wäre ich natürlich nie in diesen Fehler
gelaufen. Trotzdem gut zu wissen!
Gruß,
Andreas
Marcel Müller schrieb:
> Hallo,
>
> On 30.04.2012 07:57, Andreas Hartmann wrote:
>> fglrx unterstützt kein kms - das muß explizit abgeschaltet sein. V.a.
>> auch in der initrd (das wird manchmal vergessen).
>
> ? - ich habe die Tage ein Ubuntu mit AMD Board installiert. Die Grafik
> ging sowohl mit dem eingebauten Treiber als auch mit Catalyst. Es war
> allerdings die letzte LTS-Version, also 10.04, falls das einen
> Unterschied macht. An KMS habe ich nicht herum gespielt. Hätte das
> schief gehen müssen?
KMS ist ein Feature der Linux-Treiber (z.B. i915 oder radeon), welcher
>
> On 30.04.2012 07:57, Andreas Hartmann wrote:
>> fglrx unterstützt kein kms - das muß explizit abgeschaltet sein. V.a.
>> auch in der initrd (das wird manchmal vergessen).
>
> ? - ich habe die Tage ein Ubuntu mit AMD Board installiert. Die Grafik
> ging sowohl mit dem eingebauten Treiber als auch mit Catalyst. Es war
> allerdings die letzte LTS-Version, also 10.04, falls das einen
> Unterschied macht. An KMS habe ich nicht herum gespielt. Hätte das
> schief gehen müssen?
u.a. die Auflösung bereits beim Booten (also auf der Textkonsole) setzt.
Hierzu muß das entsprechende Module geladen sein (hier:radeon).
Zumindest bei openSUSE geschieht das bereits in der initrd. Ich denke,
das ist bei anderen Distris nicht anders (zumindest solange ein BIOS
vorliegt).
Wenn in der initrd bereits radeon geladen wurde, kann man hinterher
nicht zusätzlich fglrx aktivieren - das geht schief.
Die Installationsroutinen unterstützen genau diese Problematik und
stellen sicher, daß das nicht passiert (vorausgesetzt, sie sind auf die
jeweilige Distri und Version korrekt abgestimmt).
Wenn Du also eine supportete und funktionierende Installation
vorgenommen hast, solltest Du auf dieses Problem nicht gestoßen sein.
Ich hatte das nur deshalb erwähnt, weil es im Eifer des Gefechts gerne
mal vergessen wird, wenn man gezwungen ist, selbst an der Installation
zu arbeiten.
> Es hat mich nur eine Weile gekostet, biss ich die Bildwiderholfrequenz
> auf CRT-Niveau bekommen habe. Aber das war bei Matrox nicht anders. Vor
> allem wenn man hochwertige BNC-Kabel nutzt, stellt sich Linux
> mittlerweile genauso bockig wie einst Win95.
User gehörst (wie auch immer der definiert sein sollte). :-)
> Das einzige, was mit Catalyst immer wieder Bildfehler produzierte: ich
> hatte auf dem System mit 4GB RAM und aktivierten Memory-Remapping (also
> faktisch mehr als 4GB) versehentlich die 32-Bit Version von Ubuntu
> erwischt. Ich wusste nicht, dass bereits die CD eine andere ist. Nochmal
> neu mit 64 Bit installiert, und die Fehler waren verschwunden.
64Bit-Software zu verwenden, wäre ich natürlich nie in diesen Fehler
gelaufen. Trotzdem gut zu wissen!
Gruß,
Andreas
Sieghard Schicktanz
Apr 30, 2012, 1:33:14 PM4/30/12
to
Hallo Joseph,
Du schriebst am 30 Apr 2012 08:49:53 GMT:
> Fazit: Rolling Release + BLOB = Schmerzen.
...
Bist Du Kaufmann?
Du schriebst am 30 Apr 2012 08:49:53 GMT:
> Fazit: Rolling Release + BLOB = Schmerzen.
> Was Du erwählst, wird Dir zuteil. ;-)
Danke für Dein Mitgefühl.
Bist Du Kaufmann?
Sieghard Schicktanz
Apr 30, 2012, 2:50:12 PM4/30/12
to
Hallo Andreas,
Du schriebst am Mon, 30 Apr 2012 07:57:27 +0200:
> > 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices
> > nee ATI BeaverCreek [Radeon HD 6530D] [1002:964a]
>
> > Der erste Ansatz mit dem Radeon-Treiber im Kernel hat bei Xorg nur den
> > VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht. Auch nicht
> > nach diversen Überredungsversuchen, es blieb bei VESA.
>
> nicht überraschend.
Eigentlich schon, ein Radeon-Treiber sollte doch für eine Radeon-Karte
zuständig sein. Aber hier handelt es sich ja um Computer, da kommt man mit
Logik nicht weiter... ];->
...
sind mir viel zu naseweis.
> http://www.sebastian-siebert.de/2012/04/25/opensuse-proprietaeren-grafik-treiber-amd-catalyst-12-4-als-rpm-installieren/
Falsches Format - kein rpm hier.
> > Und es gibt sogar einen Patch, zwei Patches, und einen dritten, der den
> > zweiten automatisiert.
>
> Bekannt. Reife Leistung von Torvalds:
Naja, _das_ hat mich auch eher weniger überrascht. Da war fast mehr
überraschend, daß es dafür schon eine Umgehung gibt. Daß die Kernel-
Entwickler ihre Schräubchen nicht festdrehen wollen, ist ja schon lange
bekannt...
> > Xorg hat mal wieder am Server gedreht und eine Inkompatibilität
> > eingebaut, ab Version 1.12 funktioniert der fglrx-Treiber nicht mehr,
> > er steigt mit
>
> Auch bekannt :-).
Naschön, also alles olle Kamellen. Dann vergiß'es, was ich geschrieben hab'
- ich wollte nur mal meine kleine Odyssee und die Auswege zusammenfassen.
Wenn das alles bekannt ist - naja, nutzt's eben nischt.
> [...]
Installationsskript im Gegenteil sogar explizit ein installiertes KMS
_angefordert_, da habe ich erstmal sogar noch was nachinstalliert.
Oder, nee, war evtl. was anderes - das war ein sog. "DKMS" (blödsinnige
Abkürzungen, die immer wieder ganz was anderes bedeuten, als man meint),
das soll wohl eher für einen neuen Umweg zum Kompilieren von Kernel-Moduln
stehen. Hat aber grandios versagt, damit ging erstmal gleich _gar nischt_.
Erst nach dem Deinstallieren, nachdem alles sonst gepasst hat, ging's dann
wieder...
Ist wohl noch frühes Entwicklungsstadium.
> [...]
Außerdem habe ich nicht geschimpft, sondern nur festgestellt.
Außerdem war das Problem _und_ eine Lösung bekannt, _bevor_ AMD die neue
Version anbot, da hätte die kleine Änderung leicht "einfließen" können.
Sie hätten's ja nichtmal selber finden müssen, und die Art, wie die
Installation abläuft, kommt einer Korrektur ja auch nicht gerade entgegen.
Daß auf der anderen Seite die Kernel-Entwickler die "Nutzer-Basis" durch
geeignete Detail-Maßnahmen überschaubar halten wollen, ist doch inzwischen
schon lange ein, wie man so schön sagt, "offenes Geheimnis"... ];->
Du schriebst am Mon, 30 Apr 2012 07:57:27 +0200:
> > 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices
> > nee ATI BeaverCreek [Radeon HD 6530D] [1002:964a]
>
> > Der erste Ansatz mit dem Radeon-Treiber im Kernel hat bei Xorg nur den
> > VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht. Auch nicht
> > nach diversen Überredungsversuchen, es blieb bei VESA.
>
> nicht überraschend.
zuständig sein. Aber hier handelt es sich ja um Computer, da kommt man mit
Logik nicht weiter... ];->
...
> > Es fehlt ein Symbol, "TS_USEDFPU". Häh?
>
> Falsche Distri :-). Hättest mal openSUSE verwendet, hättest Dir viel
> Zeit erspart. Siehe:
Ich habe aber keine SuSi, und ich will auch keine, auch kein Debian - die
>
> Falsche Distri :-). Hättest mal openSUSE verwendet, hättest Dir viel
> Zeit erspart. Siehe:
sind mir viel zu naseweis.
> http://www.sebastian-siebert.de/2012/04/25/opensuse-proprietaeren-grafik-treiber-amd-catalyst-12-4-als-rpm-installieren/
Falsches Format - kein rpm hier.
> > Und es gibt sogar einen Patch, zwei Patches, und einen dritten, der den
> > zweiten automatisiert.
>
> Bekannt. Reife Leistung von Torvalds:
überraschend, daß es dafür schon eine Umgehung gibt. Daß die Kernel-
Entwickler ihre Schräubchen nicht festdrehen wollen, ist ja schon lange
bekannt...
> > Xorg hat mal wieder am Server gedreht und eine Inkompatibilität
> > eingebaut, ab Version 1.12 funktioniert der fglrx-Treiber nicht mehr,
> > er steigt mit
>
> Auch bekannt :-).
- ich wollte nur mal meine kleine Odyssee und die Auswege zusammenfassen.
Wenn das alles bekannt ist - naja, nutzt's eben nischt.
> [...]
> fglrx unterstützt kein kms - das muß explizit abgeschaltet sein. V.a.
> auch in der initrd (das wird manchmal vergessen).
_Das_ ist jetzt aber interessant - wenn ich mich recht erinnere, hat das
> auch in der initrd (das wird manchmal vergessen).
Installationsskript im Gegenteil sogar explizit ein installiertes KMS
_angefordert_, da habe ich erstmal sogar noch was nachinstalliert.
Oder, nee, war evtl. was anderes - das war ein sog. "DKMS" (blödsinnige
Abkürzungen, die immer wieder ganz was anderes bedeuten, als man meint),
das soll wohl eher für einen neuen Umweg zum Kompilieren von Kernel-Moduln
stehen. Hat aber grandios versagt, damit ging erstmal gleich _gar nischt_.
Erst nach dem Deinstallieren, nachdem alles sonst gepasst hat, ging's dann
wieder...
Ist wohl noch frühes Entwicklungsstadium.
> [...]
> > erschienen _neuen_ Version des fglrx von AMD das Problem beseitigt.
> > Aber deren Entwickler haben anscheinend keinen internet-Zugang, das
> > machen dort wohl die Kaufleute.
>
> Du beschimpfst die Falschen ... .
Kaufleute sind in dem Zusammenhang nie die falschen.
> > Aber deren Entwickler haben anscheinend keinen internet-Zugang, das
> > machen dort wohl die Kaufleute.
>
> Du beschimpfst die Falschen ... .
Außerdem habe ich nicht geschimpft, sondern nur festgestellt.
Außerdem war das Problem _und_ eine Lösung bekannt, _bevor_ AMD die neue
Version anbot, da hätte die kleine Änderung leicht "einfließen" können.
Sie hätten's ja nichtmal selber finden müssen, und die Art, wie die
Installation abläuft, kommt einer Korrektur ja auch nicht gerade entgegen.
Daß auf der anderen Seite die Kernel-Entwickler die "Nutzer-Basis" durch
geeignete Detail-Maßnahmen überschaubar halten wollen, ist doch inzwischen
schon lange ein, wie man so schön sagt, "offenes Geheimnis"... ];->
Sieghard Schicktanz
Apr 30, 2012, 3:04:33 PM4/30/12
to
Hallo Clemens,
Du schriebst am Mon, 30 Apr 2012 12:35:08 +0200:
> > lspci -nn listet die so:
...
Och, so unsinnig schien mir das bisher nichtmal zu sein.
> Der Biberbach sollte seit Kernel 3.0 unterstützt werden.
Wird er ja auch, mit den Kernel-Moduln und dem VESA-X11-Treiber ging's ja
auch.
> > Der erste Ansatz mit dem Radeon-Treiber im Kernel hat bei Xorg nur den
> > VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht.
>
> Gibt es zu dem "mochte nicht" irgendeine Fehlermeldung? (dmesg)
Nicht daß mir was erinnerlich wäre - es wurde einfach nur kommentarlos der
VESA-Treiber geladen, und mit dem lief X11 dann auch, sogar mit der
richtigen Auflösung (1600x1200).
> Der Kernel hat hoffentlich alle notwendigen Schalter wie CONFIG_AGP_AMD64,
> CONFIG_DRM_RADEON, CONFIG_FB_RADEON, CONFIG_FRAMEBUFFER_CONSOLE, und
> CONFIG_FIRMWARE_IN_KERNEL, und /lib/firmware/radeon/SUMO_*.bin existiert?
Bis auf "...FB_RADEON" alles, das ist inzwischen ein Distributions-Kernel
"mit allen Schikanen".
> > Aber es gibt da doch den schönen originalen Hersteller-Treiber
>
> Aber die Fehlersuche war wohl nicht so schön wie beim Kernel-Treiber ...
Das ist ein Oxymoron - "Fehlersuche" in Verbindung mit "schön"...
Du schriebst am Mon, 30 Apr 2012 12:35:08 +0200:
> > lspci -nn listet die so:
Och, so unsinnig schien mir das bisher nichtmal zu sein.
> Der Biberbach sollte seit Kernel 3.0 unterstützt werden.
auch.
> > Der erste Ansatz mit dem Radeon-Treiber im Kernel hat bei Xorg nur den
> > VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht.
>
> Gibt es zu dem "mochte nicht" irgendeine Fehlermeldung? (dmesg)
VESA-Treiber geladen, und mit dem lief X11 dann auch, sogar mit der
richtigen Auflösung (1600x1200).
> Der Kernel hat hoffentlich alle notwendigen Schalter wie CONFIG_AGP_AMD64,
> CONFIG_DRM_RADEON, CONFIG_FB_RADEON, CONFIG_FRAMEBUFFER_CONSOLE, und
> CONFIG_FIRMWARE_IN_KERNEL, und /lib/firmware/radeon/SUMO_*.bin existiert?
"mit allen Schikanen".
> > Aber es gibt da doch den schönen originalen Hersteller-Treiber
>
> Aber die Fehlersuche war wohl nicht so schön wie beim Kernel-Treiber ...
Andreas Hartmann
Apr 30, 2012, 4:50:29 PM4/30/12
to
Hallo Sieghard,
Sieghard Schicktanz schrieb:
> ...
>>> Es fehlt ein Symbol, "TS_USEDFPU". Häh?
>>
>> Falsche Distri :-). Hättest mal openSUSE verwendet, hättest Dir viel
>> Zeit erspart. Siehe:
>
> Ich habe aber keine SuSi, und ich will auch keine, auch kein Debian - die
> sind mir viel zu naseweis.
Ich wollte Dich zu nichts zwingen - war einfach nur eine Feststellung -
mehr nicht.
Was mich jetzt interessieren würde. kannst Du Dir ja denken: In wieweit
naseweis?
>
>> http://www.sebastian-siebert.de/2012/04/25/opensuse-proprietaeren-grafik-treiber-amd-catalyst-12-4-als-rpm-installieren/
>
> Falsches Format - kein rpm hier.
Das schon. Aber die Automation und die nötigen Patche sind vorhanden.
[...]
>>> Xorg hat mal wieder am Server gedreht und eine Inkompatibilität
>>> eingebaut, ab Version 1.12 funktioniert der fglrx-Treiber nicht mehr,
>>> er steigt mit
>>
>> Auch bekannt :-).
>
> Naschön, also alles olle Kamellen. Dann vergiß'es, was ich geschrieben hab'
> - ich wollte nur mal meine kleine Odyssee und die Auswege zusammenfassen.
Ist doch ok. Ich habe da nichts dagegen und ich gratuliere Dir zu Deinem
Erfolg! Du hast mit Sicherheit wieder dazugelernt!
> Wenn das alles bekannt ist - naja, nutzt's eben nischt.
Quatsch! Es nutzt anderen! Gut, daß Du es geschrieben hast!
Ich habe mit dem "bekannt" nur darauf hinweisen wollen, daß es bereits
Lösungen gibt und daß Du offene Türen eingerannt hast :-).
[...]
>>> erschienen _neuen_ Version des fglrx von AMD das Problem beseitigt.
>>> Aber deren Entwickler haben anscheinend keinen internet-Zugang, das
>>> machen dort wohl die Kaufleute.
>>
>> Du beschimpfst die Falschen ... .
>
> Kaufleute sind in dem Zusammenhang nie die falschen.
> Außerdem habe ich nicht geschimpft, sondern nur festgestellt.
-> Das ist kein AMD-Problem!
> Außerdem war das Problem _und_ eine Lösung bekannt, _bevor_ AMD die neue
> Version anbot, da hätte die kleine Änderung leicht "einfließen" können.
Eine Firma, welche auch nur ein wenig auf ihren Ruf bedacht ist, wird
Änderungen zuerst testen, bevor sie sie auf die Massen losläßt (=
offiziell supported). Anders als die OSS-Entwickler. Daher dauert das
eben etwas. Man will ja auch evtl. Seiteneffekte erkennen. Nicht alles,
was kompiliert, funktioniert auch wie erwartet.
> Sie hätten's ja nichtmal selber finden müssen, und die Art, wie die
> Installation abläuft, kommt einer Korrektur ja auch nicht gerade entgegen.
Sowohl Kernel 3.3 als auch X 1.12 sind nicht offiziell supported. Du
darfst Dich also nicht beklagen, daß es nicht out of the box funktioniert.
Das alles wäre ja kein Problem, wenn die Schnittstellen kompatibel
wären. Sind sie aber nicht. Wofür aber AMD nichts kann ... .
Gruß,
Andreas
Sieghard Schicktanz schrieb:
> Hallo Andreas,
>
> Du schriebst am Mon, 30 Apr 2012 07:57:27 +0200:
>
>>> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices
>>> nee ATI BeaverCreek [Radeon HD 6530D] [1002:964a]
>>
>>> Der erste Ansatz mit dem Radeon-Treiber im Kernel hat bei Xorg nur den
>>> VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht. Auch nicht
>>> nach diversen Überredungsversuchen, es blieb bei VESA.
>>
>> nicht überraschend.
>
> Eigentlich schon, ein Radeon-Treiber sollte doch für eine Radeon-Karte
> zuständig sein. Aber hier handelt es sich ja um Computer, da kommt man mit
> Logik nicht weiter... ];->
:-))
>
> Du schriebst am Mon, 30 Apr 2012 07:57:27 +0200:
>
>>> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices
>>> nee ATI BeaverCreek [Radeon HD 6530D] [1002:964a]
>>
>>> Der erste Ansatz mit dem Radeon-Treiber im Kernel hat bei Xorg nur den
>>> VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht. Auch nicht
>>> nach diversen Überredungsversuchen, es blieb bei VESA.
>>
>> nicht überraschend.
>
> Eigentlich schon, ein Radeon-Treiber sollte doch für eine Radeon-Karte
> zuständig sein. Aber hier handelt es sich ja um Computer, da kommt man mit
> Logik nicht weiter... ];->
> ...
>>> Es fehlt ein Symbol, "TS_USEDFPU". Häh?
>>
>> Falsche Distri :-). Hättest mal openSUSE verwendet, hättest Dir viel
>> Zeit erspart. Siehe:
>
> Ich habe aber keine SuSi, und ich will auch keine, auch kein Debian - die
> sind mir viel zu naseweis.
mehr nicht.
Was mich jetzt interessieren würde. kannst Du Dir ja denken: In wieweit
naseweis?
>
>> http://www.sebastian-siebert.de/2012/04/25/opensuse-proprietaeren-grafik-treiber-amd-catalyst-12-4-als-rpm-installieren/
>
> Falsches Format - kein rpm hier.
[...]
>>> Xorg hat mal wieder am Server gedreht und eine Inkompatibilität
>>> eingebaut, ab Version 1.12 funktioniert der fglrx-Treiber nicht mehr,
>>> er steigt mit
>>
>> Auch bekannt :-).
>
> Naschön, also alles olle Kamellen. Dann vergiß'es, was ich geschrieben hab'
> - ich wollte nur mal meine kleine Odyssee und die Auswege zusammenfassen.
Erfolg! Du hast mit Sicherheit wieder dazugelernt!
> Wenn das alles bekannt ist - naja, nutzt's eben nischt.
Ich habe mit dem "bekannt" nur darauf hinweisen wollen, daß es bereits
Lösungen gibt und daß Du offene Türen eingerannt hast :-).
[...]
>>> erschienen _neuen_ Version des fglrx von AMD das Problem beseitigt.
>>> Aber deren Entwickler haben anscheinend keinen internet-Zugang, das
>>> machen dort wohl die Kaufleute.
>>
>> Du beschimpfst die Falschen ... .
>
> Kaufleute sind in dem Zusammenhang nie die falschen.
> Außerdem habe ich nicht geschimpft, sondern nur festgestellt.
> Außerdem war das Problem _und_ eine Lösung bekannt, _bevor_ AMD die neue
> Version anbot, da hätte die kleine Änderung leicht "einfließen" können.
Änderungen zuerst testen, bevor sie sie auf die Massen losläßt (=
offiziell supported). Anders als die OSS-Entwickler. Daher dauert das
eben etwas. Man will ja auch evtl. Seiteneffekte erkennen. Nicht alles,
was kompiliert, funktioniert auch wie erwartet.
> Sie hätten's ja nichtmal selber finden müssen, und die Art, wie die
> Installation abläuft, kommt einer Korrektur ja auch nicht gerade entgegen.
darfst Dich also nicht beklagen, daß es nicht out of the box funktioniert.
Das alles wäre ja kein Problem, wenn die Schnittstellen kompatibel
wären. Sind sie aber nicht. Wofür aber AMD nichts kann ... .
Gruß,
Andreas
Sieghard Schicktanz
Apr 30, 2012, 8:17:35 PM4/30/12
to
Hallo Andreas,
Du schriebst am Mon, 30 Apr 2012 22:50:29 +0200:
> > Ich habe aber keine SuSi, und ich will auch keine, auch kein Debian -
> > die sind mir viel zu naseweis.
...
Konfiguration mehr nach den Vorstellungen der Distributions-Entwickler
vornehmen als nach den Wünschen und dem Bedarf des Benutzers. Man _kann_ da
zwar dran vorbei konfigurieren, muß aber immer gewärtig sein, daß das
wieder rückgängig gemacht wird. Und wenn man sich in das Skriptsystem so
'reingearbeitet hat, daß man tatsächlich seine eigenen Vorstellungen
realisieren kann, kennt man nicht mehr die Programmkonfiguration, sondern
spezifisch die der Distribution. Und hat immer noch die gute Chance, daß
sich bei einer Folgeversion Teile der Vorgänge ändern und einem doch wieder
ins Handwerk pfuschen.
> > Falsches Format - kein rpm hier.
>
> Das schon. Aber die Automation und die nötigen Patche sind vorhanden.
Die habe ich jetzt auch so gefunden. Ohne rpm kommt man halt etwas schlecht
an den Inhalt, und ohne "apt" dasselbe für Debian-Pakete. Es _geht_ zwar,
aber eben nicht direkt. (Außerdem ist derzeit bei meinem mc das cpio-"VFS"
irgendwie kaputt, er kann keine cpio-Archive bearbeiten. Warum, konnte ich
noch nicht nachprüfen, es geht eben einfach nicht. mc V.4.3.8.)
[neue fglrx-Version enthält Problem immer noch]
> Eine Firma, welche auch nur ein wenig auf ihren Ruf bedacht ist, wird
> Änderungen zuerst testen, bevor sie sie auf die Massen losläßt (=
Sollte wohl so sein. Sie sollte aber auch darauf bedacht sein, bekannte
Probleme möglichst zügig zu beseitigen.
> offiziell supported). Anders als die OSS-Entwickler. Daher dauert das
> eben etwas. Man will ja auch evtl. Seiteneffekte erkennen. Nicht alles,
^^^^^^^^^^^^^Nebenwirkungen
Jajaja, nur ist es oft halt auch so, daß die Dauer bis zur Freigabe
umgekehrt proportional zur Komplexität der Beseitigung ist - die
schwierigeren Probleme haben Vorrang. Sie sind ja auch interessanter. ;->
> > Sie hätten's ja nichtmal selber finden müssen,...
Und da spielt wohl auch noch das "NIH-Syndrom" "ein wenig" mit...
> Sowohl Kernel 3.3 als auch X 1.12 sind nicht offiziell supported. Du
> darfst Dich also nicht beklagen, daß es nicht out of the box funktioniert.
Tu' ich ja auch nicht, schließlich funktioniert's ja mit ein bisserl
Nacharbeit. Es wäre aber eben recht einfach möglich, zumindest im Fall des
Kernels die Nacharbeit unnötig zu machen, und da kann das eben nur AMD
machen, auch wenn die Ursache bei Linux liegt. Ich hätte ja nichtmal was
gesagt, wenn es eine _einfache_ Möglichkeit gäbe, eine Korrektur (aka
"Patch") unterzubringen, während oder bevor der Treiber erstellt wird.
Aber _genau da_ ist die Installation "mit Brettern vernagelt". Und _das_
ist AMDs Schuld und Zuständigkeit.
> Das alles wäre ja kein Problem, wenn die Schnittstellen kompatibel
> wären. Sind sie aber nicht. Wofür aber AMD nichts kann ... .
Dafür nicht, richtig.
Du schriebst am Mon, 30 Apr 2012 22:50:29 +0200:
> > Ich habe aber keine SuSi, und ich will auch keine, auch kein Debian -
> > die sind mir viel zu naseweis.
> Was mich jetzt interessieren würde. kannst Du Dir ja denken: In wieweit
> naseweis?
Es wird zuviel mit distributionsspezifischen Skripten hantiert, die die
> naseweis?
Konfiguration mehr nach den Vorstellungen der Distributions-Entwickler
vornehmen als nach den Wünschen und dem Bedarf des Benutzers. Man _kann_ da
zwar dran vorbei konfigurieren, muß aber immer gewärtig sein, daß das
wieder rückgängig gemacht wird. Und wenn man sich in das Skriptsystem so
'reingearbeitet hat, daß man tatsächlich seine eigenen Vorstellungen
realisieren kann, kennt man nicht mehr die Programmkonfiguration, sondern
spezifisch die der Distribution. Und hat immer noch die gute Chance, daß
sich bei einer Folgeversion Teile der Vorgänge ändern und einem doch wieder
ins Handwerk pfuschen.
> > Falsches Format - kein rpm hier.
>
> Das schon. Aber die Automation und die nötigen Patche sind vorhanden.
an den Inhalt, und ohne "apt" dasselbe für Debian-Pakete. Es _geht_ zwar,
aber eben nicht direkt. (Außerdem ist derzeit bei meinem mc das cpio-"VFS"
irgendwie kaputt, er kann keine cpio-Archive bearbeiten. Warum, konnte ich
noch nicht nachprüfen, es geht eben einfach nicht. mc V.4.3.8.)
[neue fglrx-Version enthält Problem immer noch]
> -> Das ist kein AMD-Problem!
Aber nur AMD kann das Problem lösen.
> Eine Firma, welche auch nur ein wenig auf ihren Ruf bedacht ist, wird
> Änderungen zuerst testen, bevor sie sie auf die Massen losläßt (=
Probleme möglichst zügig zu beseitigen.
> offiziell supported). Anders als die OSS-Entwickler. Daher dauert das
> eben etwas. Man will ja auch evtl. Seiteneffekte erkennen. Nicht alles,
Jajaja, nur ist es oft halt auch so, daß die Dauer bis zur Freigabe
umgekehrt proportional zur Komplexität der Beseitigung ist - die
schwierigeren Probleme haben Vorrang. Sie sind ja auch interessanter. ;->
> > Sie hätten's ja nichtmal selber finden müssen,...
Und da spielt wohl auch noch das "NIH-Syndrom" "ein wenig" mit...
> Sowohl Kernel 3.3 als auch X 1.12 sind nicht offiziell supported. Du
> darfst Dich also nicht beklagen, daß es nicht out of the box funktioniert.
Nacharbeit. Es wäre aber eben recht einfach möglich, zumindest im Fall des
Kernels die Nacharbeit unnötig zu machen, und da kann das eben nur AMD
machen, auch wenn die Ursache bei Linux liegt. Ich hätte ja nichtmal was
gesagt, wenn es eine _einfache_ Möglichkeit gäbe, eine Korrektur (aka
"Patch") unterzubringen, während oder bevor der Treiber erstellt wird.
Aber _genau da_ ist die Installation "mit Brettern vernagelt". Und _das_
ist AMDs Schuld und Zuständigkeit.
> Das alles wäre ja kein Problem, wenn die Schnittstellen kompatibel
> wären. Sind sie aber nicht. Wofür aber AMD nichts kann ... .
Helmut Hullen
May 1, 2012, 1:54:00 AM5/1/12
to
Hallo, Sieghard,
Du meintest am 01.05.12:
[...]
>> Das schon. Aber die Automation und die nötigen Patche sind
>> vorhanden.
> Die habe ich jetzt auch so gefunden. Ohne rpm kommt man halt etwas
> schlecht an den Inhalt, und ohne "apt" dasselbe für Debian-Pakete. Es
> _geht_ zwar, aber eben nicht direkt. (Außerdem ist derzeit bei meinem
> mc das cpio-"VFS" irgendwie kaputt, er kann keine cpio-Archive
> bearbeiten. Warum, konnte ich noch nicht nachprüfen, es geht eben
> einfach nicht. mc V.4.3.8.)
Da solltest Du vielleicht updaten. Ich habe hier mc 4.7.5.2, aktuell ist
4.8.1.3
Damit kann ich die allermeisten "*.rpm"- und "*.deb"-Pakete "öffnen" und
entpacken, damit kann ich auch die "initrd" studieren (nach Umbenennung
in "initrd.cpio.gz").
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Du meintest am 01.05.12:
[...]
>> Das schon. Aber die Automation und die nötigen Patche sind
>> vorhanden.
> Die habe ich jetzt auch so gefunden. Ohne rpm kommt man halt etwas
> schlecht an den Inhalt, und ohne "apt" dasselbe für Debian-Pakete. Es
> _geht_ zwar, aber eben nicht direkt. (Außerdem ist derzeit bei meinem
> mc das cpio-"VFS" irgendwie kaputt, er kann keine cpio-Archive
> bearbeiten. Warum, konnte ich noch nicht nachprüfen, es geht eben
> einfach nicht. mc V.4.3.8.)
4.8.1.3
Damit kann ich die allermeisten "*.rpm"- und "*.deb"-Pakete "öffnen" und
entpacken, damit kann ich auch die "initrd" studieren (nach Umbenennung
in "initrd.cpio.gz").
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Andreas Hartmann
May 1, 2012, 2:33:36 AM5/1/12
to
Hallo Sieghard,
Sieghard Schicktanz schrieb:
Sieghard Schicktanz schrieb:
> Hallo Andreas,
>
> Du schriebst am Mon, 30 Apr 2012 22:50:29 +0200:
>
>>> Ich habe aber keine SuSi, und ich will auch keine, auch kein Debian -
>>> die sind mir viel zu naseweis.
> ...
>> Was mich jetzt interessieren würde. kannst Du Dir ja denken: In wieweit
>> naseweis?
>
> Es wird zuviel mit distributionsspezifischen Skripten hantiert, die die
> Konfiguration mehr nach den Vorstellungen der Distributions-Entwickler
> vornehmen als nach den Wünschen und dem Bedarf des Benutzers. Man _kann_ da
> zwar dran vorbei konfigurieren, muß aber immer gewärtig sein, daß das
> wieder rückgängig gemacht wird.
Ich mache da eigentlich sehr viel an der offiziellen Automation vorbei
>
> Du schriebst am Mon, 30 Apr 2012 22:50:29 +0200:
>
>>> Ich habe aber keine SuSi, und ich will auch keine, auch kein Debian -
>>> die sind mir viel zu naseweis.
> ...
>> Was mich jetzt interessieren würde. kannst Du Dir ja denken: In wieweit
>> naseweis?
>
> Es wird zuviel mit distributionsspezifischen Skripten hantiert, die die
> Konfiguration mehr nach den Vorstellungen der Distributions-Entwickler
> vornehmen als nach den Wünschen und dem Bedarf des Benutzers. Man _kann_ da
> zwar dran vorbei konfigurieren, muß aber immer gewärtig sein, daß das
> wieder rückgängig gemacht wird.
und habe bisher eigentlich keine Probleme damit gehabt. Ja, man muß es
wissen, aber man kann sich problemlos und einfach und dauerhaft dagegen
wehren :-).
> Und wenn man sich in das Skriptsystem so
> 'reingearbeitet hat, daß man tatsächlich seine eigenen Vorstellungen
> realisieren kann, kennt man nicht mehr die Programmkonfiguration, sondern
> spezifisch die der Distribution.
(für mich), dann mache ich das nach Standard. Fertig. Bei mir wird der
Networkmanager z.B. grundsätzlich als erstes entfernt, weil er meinen
Anforderungen nicht gerecht wird. Teilweise nutze ich das ifup-System,
teilweise fahre ich die Interfaces komplett selbst hoch, mit komplett
eigener Automation.
[...]
Insgesamt hätte ich da jetzt eigentlich einen anderen Einspruch erwartet.
>
>>> Falsches Format - kein rpm hier.
>>
>> Das schon. Aber die Automation und die nötigen Patche sind vorhanden.
>
> Die habe ich jetzt auch so gefunden. Ohne rpm kommt man halt etwas schlecht
> an den Inhalt, und ohne "apt" dasselbe für Debian-Pakete. Es _geht_ zwar,
> aber eben nicht direkt. (Außerdem ist derzeit bei meinem mc das cpio-"VFS"
> irgendwie kaputt, er kann keine cpio-Archive bearbeiten. Warum, konnte ich
> noch nicht nachprüfen, es geht eben einfach nicht. mc V.4.3.8.)
>
> [neue fglrx-Version enthält Problem immer noch]
>> -> Das ist kein AMD-Problem!
>
> Aber nur AMD kann das Problem lösen.
Warum _muß_ sich eine Firma um die Probleme kümmern, welche von ihr
nicht verursacht werden? Warum muß eine Firma auf zig unterschiedliche
Distris eingehen, bloß weil die sich auf keinen durchgängigen Standard
einigen wollen? Ich würde das als Firma auch nicht tun.
>> Eine Firma, welche auch nur ein wenig auf ihren Ruf bedacht ist, wird
>> Änderungen zuerst testen, bevor sie sie auf die Massen losläßt (=
>
> Sollte wohl so sein. Sie sollte aber auch darauf bedacht sein, bekannte
> Probleme möglichst zügig zu beseitigen.
>> offiziell supported). Anders als die OSS-Entwickler. Daher dauert das
>> eben etwas. Man will ja auch evtl. Seiteneffekte erkennen. Nicht alles,
> ^^^^^^^^^^^^^Nebenwirkungen
>
> Jajaja, nur ist es oft halt auch so, daß die Dauer bis zur Freigabe
> umgekehrt proportional zur Komplexität der Beseitigung ist - die
> schwierigeren Probleme haben Vorrang. Sie sind ja auch interessanter. ;->
Konfigurationsänderung kann fatalere Auswirkungen haben als eine große
Änderung im Code. Daher muß jeder Change, und sei es nur ein Bit,
intensiv getestet werden, um die Qualität sicherzustellen. Eine Denke,
die im OSS-Umfeld leider nicht so oft zu finden ist.
>>> Sie hätten's ja nichtmal selber finden müssen,...
>
> Und da spielt wohl auch noch das "NIH-Syndrom" "ein wenig" mit...
>
>> Sowohl Kernel 3.3 als auch X 1.12 sind nicht offiziell supported. Du
>> darfst Dich also nicht beklagen, daß es nicht out of the box funktioniert.
>
> Tu' ich ja auch nicht, schließlich funktioniert's ja mit ein bisserl
> Nacharbeit. Es wäre aber eben recht einfach möglich, zumindest im Fall des
> Kernels die Nacharbeit unnötig zu machen, und da kann das eben nur AMD
> machen, auch wenn die Ursache bei Linux liegt. Ich hätte ja nichtmal was
> gesagt, wenn es eine _einfache_ Möglichkeit gäbe,
> eine Korrektur (aka
> "Patch") unterzubringen, während oder bevor der Treiber erstellt wird.
> Aber _genau da_ ist die Installation "mit Brettern vernagelt". Und _das_
> ist AMDs Schuld und Zuständigkeit.
Du nicht drumrum.
Christian Siebert ist eine hervorragende Brücke zwischen AMD und OSS
(für openSUSE), zumindest was Schnittstellenprobleme angeht. Er
integriert den Treiber dort sehr gut, so daß selbst Kernelwechsel,
solange sie supported sind von ihm, ohne Neuinstallation von fglrx und
ohne Eingriff des Users von statten gehen. Das macht er hervorragend. Er
hat die Möglichkeiten, sehr schnell auf die Anforderungen, welche sich
aus dem OSS-Umfeld ergeben, zu reagieren. Er kann nach dem Motto, "no
risk, no fun" operieren. Ihn kann man für nichts verantwortlich machen.
Bei AMD sieht das ganz anders aus.
Christian Siebert beweist, daß es problemlos möglich ist, die beiden
Welten zu verbinden - man muß nur wollen und die ideologischen
Scheuklappen ablegen!
Gruß,
Andreas
Clemens Ladisch
May 1, 2012, 3:36:14 AM5/1/12
to
Sieghard Schicktanz wrote:
> Du schriebst am Mon, 30 Apr 2012 12:35:08 +0200:
>> ... sollte seit Kernel 3.0 unterstützt werden.
> Du schriebst am Mon, 30 Apr 2012 12:35:08 +0200:
>
> Wird er ja auch, mit den Kernel-Moduln und dem VESA-X11-Treiber ging's ja
> auch.
Ich meinte natürlich radeon.
> Wird er ja auch, mit den Kernel-Moduln und dem VESA-X11-Treiber ging's ja
> auch.
>>> Der erste Ansatz mit dem Radeon-Treiber im Kernel hat bei Xorg nur den
>>> VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht.
>>
>> Gibt es zu dem "mochte nicht" irgendeine Fehlermeldung? (dmesg)
>
> Nicht daß mir was erinnerlich wäre - es wurde einfach nur kommentarlos der
> VESA-Treiber geladen, und mit dem lief X11 dann auch, sogar mit der
> richtigen Auflösung (1600x1200).
Gruß
Clemens
Andreas Hartmann
May 1, 2012, 4:50:28 AM5/1/12
to
Hallo Clemens,
Clemens Ladisch schrieb:
schlechteren Treiber installieren sollte, wenn er auch einen um Längen
besseren haben kann!
Gruß,
Andreas
Clemens Ladisch schrieb:
> Sieghard Schicktanz wrote:
>> Du schriebst am Mon, 30 Apr 2012 12:35:08 +0200:
>>> ... sollte seit Kernel 3.0 unterstützt werden.
[...]
>> Du schriebst am Mon, 30 Apr 2012 12:35:08 +0200:
>>> ... sollte seit Kernel 3.0 unterstützt werden.
>>> Gibt es zu dem "mochte nicht" irgendeine Fehlermeldung? (dmesg)
>>
>> Nicht daß mir was erinnerlich wäre - es wurde einfach nur kommentarlos der
>> VESA-Treiber geladen, und mit dem lief X11 dann auch, sogar mit der
>> richtigen Auflösung (1600x1200).
>
> Was steht denn in /var/log/Xorg.0.log?
Begründe doch einmal bitte, warum er sich Deiner Meinung nach einen
>>
>> Nicht daß mir was erinnerlich wäre - es wurde einfach nur kommentarlos der
>> VESA-Treiber geladen, und mit dem lief X11 dann auch, sogar mit der
>> richtigen Auflösung (1600x1200).
>
> Was steht denn in /var/log/Xorg.0.log?
schlechteren Treiber installieren sollte, wenn er auch einen um Längen
besseren haben kann!
Gruß,
Andreas
Sieghard Schicktanz
May 1, 2012, 1:44:23 PM5/1/12
to
Hallo Helmut,
Du schriebst am 01 May 2012 07:54:00 +0200:
> > mc das cpio-"VFS" irgendwie kaputt, er kann keine cpio-Archive
> > bearbeiten. Warum, konnte ich noch nicht nachprüfen, es geht eben
> > einfach nicht. mc V.4.3.8.)
Hoppala - ^^^ 8.3, "natürlich"...
> Da solltest Du vielleicht updaten. Ich habe hier mc 4.7.5.2, aktuell ist
> 4.8.1.3
Du bist etwas hintennach... ;-)
> Damit kann ich die allermeisten "*.rpm"- und "*.deb"-Pakete "öffnen" und
> entpacken,
"Ein echter Hullen." ];-) Kannst Du das auch noch, wenn Du /usr/bin/rpm
und .../apt beseitigst? (Mußt sie ja nicht gleich löschen, wegschieben
reicht ja;) (Es sollte auch mit Ersatzprogrammen gehen, aber dann nicht
mehr mit den originalen Skripten.)
> entpacken, damit kann ich auch die "initrd" studieren (nach Umbenennung
> in "initrd.cpio.gz").
Ja, mit der Vorversion ging das hier auch noch. Da ist wohl was am Skript
verschlimmbessert worden - aber ich bin noch nicht dazugekommen, mir das
anzuschauen.
Du schriebst am 01 May 2012 07:54:00 +0200:
> > mc das cpio-"VFS" irgendwie kaputt, er kann keine cpio-Archive
> > bearbeiten. Warum, konnte ich noch nicht nachprüfen, es geht eben
> > einfach nicht. mc V.4.3.8.)
> Da solltest Du vielleicht updaten. Ich habe hier mc 4.7.5.2, aktuell ist
> 4.8.1.3
> Damit kann ich die allermeisten "*.rpm"- und "*.deb"-Pakete "öffnen" und
> entpacken,
und .../apt beseitigst? (Mußt sie ja nicht gleich löschen, wegschieben
reicht ja;) (Es sollte auch mit Ersatzprogrammen gehen, aber dann nicht
mehr mit den originalen Skripten.)
> entpacken, damit kann ich auch die "initrd" studieren (nach Umbenennung
> in "initrd.cpio.gz").
verschlimmbessert worden - aber ich bin noch nicht dazugekommen, mir das
anzuschauen.
Helmut Hullen
May 1, 2012, 3:45:00 PM5/1/12
to
Hallo, Sieghard,
Du meintest am 01.05.12:
Du meintest am 01.05.12:
>> Da solltest Du vielleicht updaten. Ich habe hier mc 4.7.5.2, aktuell
>> ist 4.8.1.3
> Du bist etwas hintennach... ;-)
>> Damit kann ich die allermeisten "*.rpm"- und "*.deb"-Pakete "öffnen"
>> und entpacken,
> "Ein echter Hullen." ];-) Kannst Du das auch noch, wenn Du
> /usr/bin/rpm und .../apt beseitigst?
"rpm" liegt hier unter "/bin", wird benötigt. "apt" gibt es hier nicht.
>> ist 4.8.1.3
> Du bist etwas hintennach... ;-)
>> Damit kann ich die allermeisten "*.rpm"- und "*.deb"-Pakete "öffnen"
>> und entpacken,
> "Ein echter Hullen." ];-) Kannst Du das auch noch, wenn Du
> /usr/bin/rpm und .../apt beseitigst?
Wird also nicht benötigt.
>> entpacken, damit kann ich auch die "initrd" studieren (nach
>> Umbenennung in "initrd.cpio.gz").
> Ja, mit der Vorversion ging das hier auch noch. Da ist wohl was am
> Skript verschlimmbessert worden - aber ich bin noch nicht
> dazugekommen, mir das anzuschauen.
Bei *.deb muss ich bei obiger mc-Version derzeit stattdessen
"debian2slack" aus dem Paket
<http://arktur.shuttle.de/CD/beta/slack/ap1/alien2slack-0.22-noarch-3hln.tgz>
benutzen. Oder eine ältere "mc"-Version.
Sieghard Schicktanz
May 1, 2012, 2:16:05 PM5/1/12
to
Hallo Andreas,
Du schriebst am Tue, 01 May 2012 08:33:36 +0200:
> >> naseweis?
> >
> > Es wird zuviel mit distributionsspezifischen Skripten hantiert, die die
...
peinlichst alle distributionsspezifischen Aktionen und hebt sich immer
einen Satz der Konfiguration auf, um nach einem Update/grade die eigenen
Einstellungen rekonstruieren zu können (der mc ist da extrem lästig).
> > Und wenn man sich in das Skriptsystem so
...
schon auch stehen, wenn sie paßt. Leider ist das in vielen Fällen nicht
_ganz_ passend.
> Networkmanager z.B. grundsätzlich als erstes entfernt, weil er meinen
Und wie verhinderst Du dann, daß er bei einem Update/grade wieder
installiert wird, weil ihn irgendein Programm als Abhängigkeit verlangt?
Da gehen die Probleme schon los.
> [...]
> Insgesamt hätte ich da jetzt eigentlich einen anderen Einspruch erwartet.
Welchen?
> > [neue fglrx-Version enthält Problem immer noch]
> >> -> Das ist kein AMD-Problem!
> >
> > Aber nur AMD kann das Problem lösen.
>
> Nein. Siehe Sebastian Siebert.
Ok, muß ich mir anschauen. Bin ich noch nicht dazugekommen.
> Warum _muß_ sich eine Firma um die Probleme kümmern, welche von ihr
> nicht verursacht werden? Warum muß eine Firma auf zig unterschiedliche
> Distris eingehen, bloß weil die sich auf keinen durchgängigen Standard
> einigen wollen? Ich würde das als Firma auch nicht tun.
^wollen
Du würdest es als Firma in vielen Fällen einfach tun _müssen_. Ein recht
schlecht beseitigbarer Grund wären z.B. neue Vorschriften, oder einfach ein
neu aufgekommener Kundenwunsch. Oder eben - wie im Fall der Distributionen
- "der Markt". Daß die Firmen das nicht _wollen_, merkt man ja daran, wie
langsam die Reaktionen sind, sie werden halt an den Umsatzerwartungen
ausgerichtet. Schließlich ist _der_ (der Umsatz, für die Kaufleute) "das
Maß aller Dinge".
> > Probleme möglichst zügig zu beseitigen.
>
> Ein QA-Prozeß braucht Zeit. Das geht nicht in 5 Minuten.
Bei kleinen Änderungen reichen ein paar Tage problemlos. Hier sind's ja
schon Wochen.
> > schwierigeren Probleme haben Vorrang. Sie sind ja auch
> > interessanter. ;->
>
> Das Eine hat mit dem Anderen nicht zwangsweise was zu tun. Eine einfache
Schon. Aber die Ressourcen-Zuteilung erfolgt nach angenommenem Bedarf, und
der ist nicht objektiv messbar, sondern wird geschätzt.
> Konfigurationsänderung kann fatalere Auswirkungen haben als eine große
> Änderung im Code. Daher muß jeder Change, und sei es nur ein Bit,
> intensiv getestet werden, um die Qualität sicherzustellen. Eine Denke,
> die im OSS-Umfeld leider nicht so oft zu finden ist.
Im kommerziellen auch nur dann, wenn evtl. zu erwartende Probleme absehbar
zu größeren Kosten führen können. (Gibt's da nicht eine große amerikanische
Software-Firma, die für sowas bekannt sein soll?)
> Einfach ist es für jeden, der weiß, wie es geht :-).
Klar.
> > eine Korrektur (aka
> > "Patch") unterzubringen, während oder bevor der Treiber erstellt wird.
> > Aber _genau da_ ist die Installation "mit Brettern vernagelt". Und _das_
> > ist AMDs Schuld und Zuständigkeit.
>
> Christian Siebert hat aber das Gegenteil bewiesen - sorry :-). Da kommst
> Du nicht drumrum.
Gutgut - muß ich erstmal durchlesen. Erstmal muß man den ja schließlich
kennen, und dann auch noch wissen, was mit dem los ist. Ein einsamer Link
sagt da noch nichts.
Wenn der aber einen Haufen auch noch distributionsspezifischer Skripte dazu
brauchen sollte, dann ist das _kein_ Gegenargument.
> Christian Siebert ist eine hervorragende Brücke zwischen AMD und OSS
Gut, wenn so jemand vorhanden ist.
> Christian Siebert beweist, daß es problemlos möglich ist, die beiden
> Welten zu verbinden - man muß nur wollen und die ideologischen
> Scheuklappen ablegen!
Das ist sicher nicht zu bestreiten... _auch_ in anderen Zusammenhängen!
Du schriebst am Tue, 01 May 2012 08:33:36 +0200:
> >> naseweis?
> >
> > Es wird zuviel mit distributionsspezifischen Skripten hantiert, die die
> Ich mache da eigentlich sehr viel an der offiziellen Automation vorbei
> und habe bisher eigentlich keine Probleme damit gehabt. Ja, man muß es
> wissen, aber man kann sich problemlos und einfach und dauerhaft dagegen
> wehren :-).
Ja, geht wohl, ist aber eben zusätzlicher Aufwand - oder man vermeidet
> und habe bisher eigentlich keine Probleme damit gehabt. Ja, man muß es
> wissen, aber man kann sich problemlos und einfach und dauerhaft dagegen
> wehren :-).
peinlichst alle distributionsspezifischen Aktionen und hebt sich immer
einen Satz der Konfiguration auf, um nach einem Update/grade die eigenen
Einstellungen rekonstruieren zu können (der mc ist da extrem lästig).
> > Und wenn man sich in das Skriptsystem so
> Mache ich nicht so. Wenn ich der Meinung bin, daß Standard besser ist
> (für mich), dann mache ich das nach Standard. Fertig. Bei mir wird der
Wenn der Standard die Distributions-Einstellung ist, dann laß' ich die
> (für mich), dann mache ich das nach Standard. Fertig. Bei mir wird der
schon auch stehen, wenn sie paßt. Leider ist das in vielen Fällen nicht
_ganz_ passend.
> Networkmanager z.B. grundsätzlich als erstes entfernt, weil er meinen
installiert wird, weil ihn irgendein Programm als Abhängigkeit verlangt?
Da gehen die Probleme schon los.
> [...]
> Insgesamt hätte ich da jetzt eigentlich einen anderen Einspruch erwartet.
> > [neue fglrx-Version enthält Problem immer noch]
> >> -> Das ist kein AMD-Problem!
> >
> > Aber nur AMD kann das Problem lösen.
>
> Nein. Siehe Sebastian Siebert.
> Warum _muß_ sich eine Firma um die Probleme kümmern, welche von ihr
> nicht verursacht werden? Warum muß eine Firma auf zig unterschiedliche
> Distris eingehen, bloß weil die sich auf keinen durchgängigen Standard
> einigen wollen? Ich würde das als Firma auch nicht tun.
Du würdest es als Firma in vielen Fällen einfach tun _müssen_. Ein recht
schlecht beseitigbarer Grund wären z.B. neue Vorschriften, oder einfach ein
neu aufgekommener Kundenwunsch. Oder eben - wie im Fall der Distributionen
- "der Markt". Daß die Firmen das nicht _wollen_, merkt man ja daran, wie
langsam die Reaktionen sind, sie werden halt an den Umsatzerwartungen
ausgerichtet. Schließlich ist _der_ (der Umsatz, für die Kaufleute) "das
Maß aller Dinge".
> > Probleme möglichst zügig zu beseitigen.
>
> Ein QA-Prozeß braucht Zeit. Das geht nicht in 5 Minuten.
schon Wochen.
> > schwierigeren Probleme haben Vorrang. Sie sind ja auch
> > interessanter. ;->
>
> Das Eine hat mit dem Anderen nicht zwangsweise was zu tun. Eine einfache
der ist nicht objektiv messbar, sondern wird geschätzt.
> Konfigurationsänderung kann fatalere Auswirkungen haben als eine große
> Änderung im Code. Daher muß jeder Change, und sei es nur ein Bit,
> intensiv getestet werden, um die Qualität sicherzustellen. Eine Denke,
> die im OSS-Umfeld leider nicht so oft zu finden ist.
zu größeren Kosten führen können. (Gibt's da nicht eine große amerikanische
Software-Firma, die für sowas bekannt sein soll?)
> Einfach ist es für jeden, der weiß, wie es geht :-).
> > eine Korrektur (aka
> > "Patch") unterzubringen, während oder bevor der Treiber erstellt wird.
> > Aber _genau da_ ist die Installation "mit Brettern vernagelt". Und _das_
> > ist AMDs Schuld und Zuständigkeit.
>
> Christian Siebert hat aber das Gegenteil bewiesen - sorry :-). Da kommst
> Du nicht drumrum.
kennen, und dann auch noch wissen, was mit dem los ist. Ein einsamer Link
sagt da noch nichts.
Wenn der aber einen Haufen auch noch distributionsspezifischer Skripte dazu
brauchen sollte, dann ist das _kein_ Gegenargument.
> Christian Siebert ist eine hervorragende Brücke zwischen AMD und OSS
> Christian Siebert beweist, daß es problemlos möglich ist, die beiden
> Welten zu verbinden - man muß nur wollen und die ideologischen
> Scheuklappen ablegen!
Sieghard Schicktanz
May 1, 2012, 3:05:14 PM5/1/12
to
Hallo Clemens,
Du schriebst am Tue, 01 May 2012 09:36:14 +0200:
> >>> VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht.
...
ausprobiert, und jetzt funktioniert der Radeon-Treiber doch. Das Nicht-
Funktionieren stammt dann wohl noch aus der Periode, wo ich entweder noch
nicht auf das KMS geachtet hatte oder wo ich schon den neueren Xorg-Server
1.12 installiert hatte (was letzteres auf einen Bock in diesem deuten würde
- aber _das_ werde ich jetzt nicht auch noch ausprobieren).
Die Arbeitsgeschwindigkeit ist natürlich nicht zu vergleichen - schließlich
gibt's ein "direct rendering: No" von glxinfo, und die glxgears- und
fgl_glxgears-Raten liegen um einen vollen Faktor 100 (Einhundert) niedriger.
Video ginge allerdings trotzdem, sogar ohne besondere Prozessorauslastung
(und obwohl ich das eher selten nutze).
(Das Xorg.log dazu habe ich mal aufgehobden, falls es jemanden interessieren
sollte.)
Du schriebst am Tue, 01 May 2012 09:36:14 +0200:
> >>> VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht.
> Was steht denn in /var/log/Xorg.0.log?
Oh, ich denke, ich muß das korrigieren - ich hab' das grade nochmal
ausprobiert, und jetzt funktioniert der Radeon-Treiber doch. Das Nicht-
Funktionieren stammt dann wohl noch aus der Periode, wo ich entweder noch
nicht auf das KMS geachtet hatte oder wo ich schon den neueren Xorg-Server
1.12 installiert hatte (was letzteres auf einen Bock in diesem deuten würde
- aber _das_ werde ich jetzt nicht auch noch ausprobieren).
Die Arbeitsgeschwindigkeit ist natürlich nicht zu vergleichen - schließlich
gibt's ein "direct rendering: No" von glxinfo, und die glxgears- und
fgl_glxgears-Raten liegen um einen vollen Faktor 100 (Einhundert) niedriger.
Video ginge allerdings trotzdem, sogar ohne besondere Prozessorauslastung
(und obwohl ich das eher selten nutze).
(Das Xorg.log dazu habe ich mal aufgehobden, falls es jemanden interessieren
sollte.)
Joseph Terner
May 1, 2012, 5:29:16 PM5/1/12
to
On Tue, 01 May 2012 20:16:05 +0200, Sieghard Schicktanz wrote:
> Hallo Andreas,
>
> Du schriebst am Tue, 01 May 2012 08:33:36 +0200:
>
>> >> naseweis?
>> >
>> > Es wird zuviel mit distributionsspezifischen Skripten hantiert, die
>> > die
> ...
>> Ich mache da eigentlich sehr viel an der offiziellen Automation vorbei
>> und habe bisher eigentlich keine Probleme damit gehabt. Ja, man muß es
>> wissen, aber man kann sich problemlos und einfach und dauerhaft dagegen
>> wehren :-).
>
> Ja, geht wohl, ist aber eben zusätzlicher Aufwand - oder man vermeidet
> peinlichst alle distributionsspezifischen Aktionen und hebt sich immer
> einen Satz der Konfiguration auf, um nach einem Update/grade die eigenen
> Einstellungen rekonstruieren zu können (der mc ist da extrem lästig).
Oder man vermeidet einfach Distributionen, die einem solche Knüppel
> Hallo Andreas,
>
> Du schriebst am Tue, 01 May 2012 08:33:36 +0200:
>
>> >> naseweis?
>> >
>> > Es wird zuviel mit distributionsspezifischen Skripten hantiert, die
>> > die
> ...
>> Ich mache da eigentlich sehr viel an der offiziellen Automation vorbei
>> und habe bisher eigentlich keine Probleme damit gehabt. Ja, man muß es
>> wissen, aber man kann sich problemlos und einfach und dauerhaft dagegen
>> wehren :-).
>
> Ja, geht wohl, ist aber eben zusätzlicher Aufwand - oder man vermeidet
> peinlichst alle distributionsspezifischen Aktionen und hebt sich immer
> einen Satz der Konfiguration auf, um nach einem Update/grade die eigenen
> Einstellungen rekonstruieren zu können (der mc ist da extrem lästig).
zwischen die Beine werfen. Ist nicht schwierig, gibt genügend Auswahl.
>> Mache ich nicht so. Wenn ich der Meinung bin, daß Standard besser ist
>> (für mich), dann mache ich das nach Standard. Fertig. Bei mir wird der
>> Networkmanager z.B. grundsätzlich als erstes entfernt, weil er meinen
>
> Und wie verhinderst Du dann, daß er bei einem Update/grade wieder
> installiert wird, weil ihn irgendein Programm als Abhängigkeit verlangt?
> Da gehen die Probleme schon los.
Man verhindert das dadurch, indem man eine Distribution verwendet, die
>
> Und wie verhinderst Du dann, daß er bei einem Update/grade wieder
> installiert wird, weil ihn irgendein Programm als Abhängigkeit verlangt?
> Da gehen die Probleme schon los.
"Abhängigkeiten" vermeidet, weil das sowieso ein völlig dysfunktionales
Konzept ist.
>> Warum _muß_ sich eine Firma um die Probleme kümmern, welche von ihr
>> nicht verursacht werden? Warum muß eine Firma auf zig unterschiedliche
>> Distris eingehen, bloß weil die sich auf keinen durchgängigen Standard
>> einigen wollen? Ich würde das als Firma auch nicht tun.
> Du würdest es als Firma in vielen Fällen einfach tun _müssen_. Ein recht
> schlecht beseitigbarer Grund wären z.B. neue Vorschriften, oder einfach
> ein neu aufgekommener Kundenwunsch. Oder eben - wie im Fall der
> Distributionen - "der Markt". Daß die Firmen das nicht _wollen_, merkt
> man ja daran, wie langsam die Reaktionen sind, sie werden halt an den
> Umsatzerwartungen ausgerichtet. Schließlich ist _der_ (der Umsatz, für
> die Kaufleute) "das Maß aller Dinge".
Wirtschaftsbetrieb namens AMD fortbestehen kann. Im Gegensatz zu Intel
besitzt er kein Monopol auf irgendeinem Gebiet und muß sich daher mittels
Geschäftstätigkeit über Wasser halten, wobei die Kosten die Erträge
langfristig nicht übersteigen dürfen, sonst kommt irgendwann der
Insolvenzverwalter.
>> > Probleme möglichst zügig zu beseitigen.
>>
>> Ein QA-Prozeß braucht Zeit. Das geht nicht in 5 Minuten.
>
> Bei kleinen Änderungen reichen ein paar Tage problemlos. Hier sind's ja
> schon Wochen.
meinen Boxen keine GPUs von AMD. Sind bei der Prüfung leider
durchgefallen. :-)
ciao, Joseph
Sieghard Schicktanz
May 1, 2012, 7:16:54 PM5/1/12
to
Hallo Joseph,
Du schriebst am 1 May 2012 21:29:16 GMT:
> > Ja, geht wohl, ist aber eben zusätzlicher Aufwand - oder man vermeidet
> > peinlichst alle distributionsspezifischen Aktionen und hebt sich immer
...
> > installiert wird, weil ihn irgendein Programm als Abhängigkeit verlangt?
> > Da gehen die Probleme schon los.
>
> Man verhindert das dadurch, indem man eine Distribution verwendet, die
> "Abhängigkeiten" vermeidet, weil das sowieso ein völlig dysfunktionales
> Konzept ist.
Also Slackware? Oder garkeine Distribution, alles selber gebaut.
Welche andere Distribution verwendet denn heue noch ein Paketmanagement
_ohne_ Abhängigkeitsverwaltung?
Das ist ja oft auch ganz nützlich, weil man da nicht vergessen oder
übersehen kann, was benötigtes mitzuinstallieren. Andererseits könnte man
manchmal die Paketbauer auch verfluchen, wenn die eine oder mehrere nicht
unbedingt nötige Optionen als feste Anforderungen einbauen (z.B. beim Qemu
alle möglichen Funk-Geschichten, IR-Fernseuerungen beim mplayer und solches
Zeugs).
> >> Warum _muß_ sich eine Firma um die Probleme kümmern, welche von ihr
> >> nicht verursacht werden? Warum muß eine Firma auf zig unterschiedliche
> >> Distris eingehen, bloß weil die sich auf keinen durchgängigen Standard
> >> einigen wollen? Ich würde das als Firma auch nicht tun.
>
> Man kann sich den Aufwand auch einfach bezahlen lassen.
Das wird _sowieso_ "auch" noch gemacht.
> > Du würdest es als Firma in vielen Fällen einfach tun _müssen_. Ein recht
...
Monaten sein werden kann, interessiert da keinen.
> >> Ein QA-Prozeß braucht Zeit. Das geht nicht in 5 Minuten.
...
in absehbarer Zeit _wirklicher_ Monpolist und kann die Preise beliebig
hochsetzen. Der Markt reguliert dann nur noch den Durchsatz, dann werden
halt wieder mehr Handarbeitsplätze eingerichtet statt zu automatisieren...
(Ein gutes Beispiel für die kurzfristige Beurteilung von Entwicklungen.)
Du schriebst am 1 May 2012 21:29:16 GMT:
> > Ja, geht wohl, ist aber eben zusätzlicher Aufwand - oder man vermeidet
> > peinlichst alle distributionsspezifischen Aktionen und hebt sich immer
> Oder man vermeidet einfach Distributionen, die einem solche Knüppel
Naja, warum könnte ich wohl Arch verwenden?
> > installiert wird, weil ihn irgendein Programm als Abhängigkeit verlangt?
> > Da gehen die Probleme schon los.
>
> Man verhindert das dadurch, indem man eine Distribution verwendet, die
> "Abhängigkeiten" vermeidet, weil das sowieso ein völlig dysfunktionales
> Konzept ist.
Welche andere Distribution verwendet denn heue noch ein Paketmanagement
_ohne_ Abhängigkeitsverwaltung?
Das ist ja oft auch ganz nützlich, weil man da nicht vergessen oder
übersehen kann, was benötigtes mitzuinstallieren. Andererseits könnte man
manchmal die Paketbauer auch verfluchen, wenn die eine oder mehrere nicht
unbedingt nötige Optionen als feste Anforderungen einbauen (z.B. beim Qemu
alle möglichen Funk-Geschichten, IR-Fernseuerungen beim mplayer und solches
Zeugs).
> >> Warum _muß_ sich eine Firma um die Probleme kümmern, welche von ihr
> >> nicht verursacht werden? Warum muß eine Firma auf zig unterschiedliche
> >> Distris eingehen, bloß weil die sich auf keinen durchgängigen Standard
> >> einigen wollen? Ich würde das als Firma auch nicht tun.
>
> Man kann sich den Aufwand auch einfach bezahlen lassen.
> > Du würdest es als Firma in vielen Fällen einfach tun _müssen_. Ein recht
> > Umsatzerwartungen ausgerichtet. Schließlich ist _der_ (der Umsatz, für
> > die Kaufleute) "das Maß aller Dinge".
>
> Der Gewinn ist das Maß aller Dinge, der bestimmt nämlich, inwieweit der
Ok, hast Recht. Noch dazu der _kurzfristige_ Gewinn - was in ein paar
> > die Kaufleute) "das Maß aller Dinge".
>
> Der Gewinn ist das Maß aller Dinge, der bestimmt nämlich, inwieweit der
Monaten sein werden kann, interessiert da keinen.
> >> Ein QA-Prozeß braucht Zeit. Das geht nicht in 5 Minuten.
> Einen funktionierenden QA-Prozeß habe dafür ich. Deshalb befinden sich in
> meinen Boxen keine GPUs von AMD. Sind bei der Prüfung leider
> durchgefallen. :-)
Schön für Dich, und noch schöner für intel. Wenn das alle machen, ist intel
> meinen Boxen keine GPUs von AMD. Sind bei der Prüfung leider
> durchgefallen. :-)
in absehbarer Zeit _wirklicher_ Monpolist und kann die Preise beliebig
hochsetzen. Der Markt reguliert dann nur noch den Durchsatz, dann werden
halt wieder mehr Handarbeitsplätze eingerichtet statt zu automatisieren...
(Ein gutes Beispiel für die kurzfristige Beurteilung von Entwicklungen.)
Andreas Hartmann
May 2, 2012, 3:51:50 AM5/2/12
to
Hallo Joseph,
Joseph Terner schrieb:
um jeden Preis sicherstellen will, daß zumindest die Voraussetzungen
alle vorhanden sind, daß ein Programm funktionieren kann. Es ist auch
geschickt, wenn man ein Programm deinstalliert und dann zusätzlich auch
alle Libraries entfernt werden, solange sie von keinem anderen Programm
mehr benötigt werden. Das schätze ich sehr.
Ich denke, die Wahrheit liegt mal wieder, wie so oft, in der Mitte.
Diese Funktionalität zu haben, ist gut und wichtig, jedoch muß sie
selektiv einfach beeinflußbar sein. Dann ist das eine feine Sache.
>>> Warum _muß_ sich eine Firma um die Probleme kümmern, welche von ihr
>>> nicht verursacht werden? Warum muß eine Firma auf zig unterschiedliche
>>> Distris eingehen, bloß weil die sich auf keinen durchgängigen Standard
>>> einigen wollen? Ich würde das als Firma auch nicht tun.
>
> Man kann sich den Aufwand auch einfach bezahlen lassen.
So läuft das dann ja auch. Ich hatte nur den üblichen OSS-Weg ohne
Bezahlung im Kopf.
>> Du würdest es als Firma in vielen Fällen einfach tun _müssen_. Ein recht
>> schlecht beseitigbarer Grund wären z.B. neue Vorschriften, oder einfach
>> ein neu aufgekommener Kundenwunsch. Oder eben - wie im Fall der
>> Distributionen - "der Markt". Daß die Firmen das nicht _wollen_, merkt
>> man ja daran, wie langsam die Reaktionen sind, sie werden halt an den
>> Umsatzerwartungen ausgerichtet. Schließlich ist _der_ (der Umsatz, für
>> die Kaufleute) "das Maß aller Dinge".
>
> Der Gewinn ist das Maß aller Dinge, der bestimmt nämlich, inwieweit der
> Wirtschaftsbetrieb namens AMD fortbestehen kann. Im Gegensatz zu Intel
> besitzt er kein Monopol auf irgendeinem Gebiet und muß sich daher mittels
> Geschäftstätigkeit über Wasser halten, wobei die Kosten die Erträge
> langfristig nicht übersteigen dürfen, sonst kommt irgendwann der
> Insolvenzverwalter.
Exakt. Und dann gibt es keine AMD-Graka's mehr, z.B. Das kann doch auch
keiner wollen, denn dann wird ein bestehendes Monopol noch weiter
verfestigt.
Andreas
Joseph Terner schrieb:
> On Tue, 01 May 2012 20:16:05 +0200, Sieghard Schicktanz wrote:
>
>> Hallo Andreas,
>>
>> Du schriebst am Tue, 01 May 2012 08:33:36 +0200:
[...]
>
>> Hallo Andreas,
>>
>> Du schriebst am Tue, 01 May 2012 08:33:36 +0200:
> Man verhindert das dadurch, indem man eine Distribution verwendet, die
> "Abhängigkeiten" vermeidet, weil das sowieso ein völlig dysfunktionales
> Konzept ist.
Würde ich jetzt so nicht ganz stehen lassen. Es hat Vorteile, wenn man
> "Abhängigkeiten" vermeidet, weil das sowieso ein völlig dysfunktionales
> Konzept ist.
um jeden Preis sicherstellen will, daß zumindest die Voraussetzungen
alle vorhanden sind, daß ein Programm funktionieren kann. Es ist auch
geschickt, wenn man ein Programm deinstalliert und dann zusätzlich auch
alle Libraries entfernt werden, solange sie von keinem anderen Programm
mehr benötigt werden. Das schätze ich sehr.
Ich denke, die Wahrheit liegt mal wieder, wie so oft, in der Mitte.
Diese Funktionalität zu haben, ist gut und wichtig, jedoch muß sie
selektiv einfach beeinflußbar sein. Dann ist das eine feine Sache.
>>> Warum _muß_ sich eine Firma um die Probleme kümmern, welche von ihr
>>> nicht verursacht werden? Warum muß eine Firma auf zig unterschiedliche
>>> Distris eingehen, bloß weil die sich auf keinen durchgängigen Standard
>>> einigen wollen? Ich würde das als Firma auch nicht tun.
>
> Man kann sich den Aufwand auch einfach bezahlen lassen.
Bezahlung im Kopf.
>> Du würdest es als Firma in vielen Fällen einfach tun _müssen_. Ein recht
>> schlecht beseitigbarer Grund wären z.B. neue Vorschriften, oder einfach
>> ein neu aufgekommener Kundenwunsch. Oder eben - wie im Fall der
>> Distributionen - "der Markt". Daß die Firmen das nicht _wollen_, merkt
>> man ja daran, wie langsam die Reaktionen sind, sie werden halt an den
>> Umsatzerwartungen ausgerichtet. Schließlich ist _der_ (der Umsatz, für
>> die Kaufleute) "das Maß aller Dinge".
>
> Der Gewinn ist das Maß aller Dinge, der bestimmt nämlich, inwieweit der
> Wirtschaftsbetrieb namens AMD fortbestehen kann. Im Gegensatz zu Intel
> besitzt er kein Monopol auf irgendeinem Gebiet und muß sich daher mittels
> Geschäftstätigkeit über Wasser halten, wobei die Kosten die Erträge
> langfristig nicht übersteigen dürfen, sonst kommt irgendwann der
> Insolvenzverwalter.
keiner wollen, denn dann wird ein bestehendes Monopol noch weiter
verfestigt.
Andreas
Andreas Hartmann
May 2, 2012, 3:39:40 AM5/2/12
to
Hallo Sieghard,
Sieghard Schicktanz schrieb:
Sieghard Schicktanz schrieb:
> Hallo Andreas,
>
> Du schriebst am Tue, 01 May 2012 08:33:36 +0200:
[...]
>
> Du schriebst am Tue, 01 May 2012 08:33:36 +0200:
>> Networkmanager z.B. grundsätzlich als erstes entfernt, weil er meinen
>
> Und wie verhinderst Du dann, daß er bei einem Update/grade wieder
> installiert wird, weil ihn irgendein Programm als Abhängigkeit verlangt?
> Da gehen die Probleme schon los.
konkreten Beispiel):
1. Wenn Networkmanager deinstalliert wird, wird dafür der traditionelle,
manuelle Weg installiert.
2. generischer Ansatz (falls 1 nicht vorhanden ist): manuelles,
einmaliges Sperren von Paketen. Braucht man ja auch dann z.B., wenn man
abweichende Versionen eines Programms installiert hat. Ich habe hier
über 20 Pakete gesperrt (darunter kdepim, akonadi, openSUSE-Spezifisches
(branding-Geraffel), smolt, ...).
3. (geht immer, hardcore-Variante): chattr +i file (mache ich hier bei
der kdm-Config so.
>
>> [...]
>> Insgesamt hätte ich da jetzt eigentlich einen anderen Einspruch erwartet.
>
> Welchen?
Gruß,
Andreas
Peter Lemken
May 2, 2012, 4:02:59 AM5/2/12
to
Sieghard Schicktanz <Sieghard....@schs.de> wrote:
> Die Arbeitsgeschwindigkeit ist natürlich nicht zu vergleichen - schließlich
> gibt's ein "direct rendering: No" von glxinfo, und die glxgears- und
> fgl_glxgears-Raten liegen um einen vollen Faktor 100 (Einhundert) niedriger.
> Video ginge allerdings trotzdem, sogar ohne besondere Prozessorauslastung
> (und obwohl ich das eher selten nutze).
grep mal nach dri in der Logdatei von Xorg - da ist definitiv noch was nicht
> Die Arbeitsgeschwindigkeit ist natürlich nicht zu vergleichen - schließlich
> gibt's ein "direct rendering: No" von glxinfo, und die glxgears- und
> fgl_glxgears-Raten liegen um einen vollen Faktor 100 (Einhundert) niedriger.
> Video ginge allerdings trotzdem, sogar ohne besondere Prozessorauslastung
> (und obwohl ich das eher selten nutze).
im grünen Bereich bei Dir.
Peter Lemken
+43-1
--
Nature abhors crude hacks.
Joseph Terner
May 2, 2012, 6:21:29 AM5/2/12
to
On Wed, 02 May 2012 01:16:54 +0200, Sieghard Schicktanz wrote:
> Hallo Joseph,
>
> Du schriebst am 1 May 2012 21:29:16 GMT:
>
>> > Ja, geht wohl, ist aber eben zusätzlicher Aufwand - oder man
>> > vermeidet peinlichst alle distributionsspezifischen Aktionen und hebt
>> > sich immer
> ...
>> Oder man vermeidet einfach Distributionen, die einem solche Knüppel
>
> Naja, warum könnte ich wohl Arch verwenden?
Das ist halt ein Moving Target. Gehört nicht zu AMDs Zielgruppe.
> Hallo Joseph,
>
> Du schriebst am 1 May 2012 21:29:16 GMT:
>
>> > Ja, geht wohl, ist aber eben zusätzlicher Aufwand - oder man
>> > vermeidet peinlichst alle distributionsspezifischen Aktionen und hebt
>> > sich immer
> ...
>> Oder man vermeidet einfach Distributionen, die einem solche Knüppel
>
> Naja, warum könnte ich wohl Arch verwenden?
>> > installiert wird, weil ihn irgendein Programm als Abhängigkeit
>> > verlangt? Da gehen die Probleme schon los.
>>
>> Man verhindert das dadurch, indem man eine Distribution verwendet, die
>> "Abhängigkeiten" vermeidet, weil das sowieso ein völlig dysfunktionales
>> Konzept ist.
>
> Also Slackware? Oder garkeine Distribution, alles selber gebaut. Welche
> andere Distribution verwendet denn heue noch ein Paketmanagement _ohne_
> Abhängigkeitsverwaltung?
>> > Umsatzerwartungen ausgerichtet. Schließlich ist _der_ (der Umsatz,
>> > für die Kaufleute) "das Maß aller Dinge".
>>
>> Der Gewinn ist das Maß aller Dinge, der bestimmt nämlich, inwieweit der
>
> Ok, hast Recht. Noch dazu der _kurzfristige_ Gewinn - was in ein paar
> Monaten sein werden kann, interessiert da keinen.
wenig kurzfristiger Gewinn ist. Und wenn da ein Vorstand auf die Idee
käme "Wir investieren jetzt mal $100 Mio. in Linux-Gaming", dann wäre er
kurze Zeit später abgelöst. :-)
>> >> Ein QA-Prozeß braucht Zeit. Das geht nicht in 5 Minuten.
> ...
>> Einen funktionierenden QA-Prozeß habe dafür ich. Deshalb befinden sich
>> in meinen Boxen keine GPUs von AMD. Sind bei der Prüfung leider
>> durchgefallen. :-)
>
> Schön für Dich, und noch schöner für intel.
auf dem Sektor heißt nVidia und hat zufällig hervorragend funktionierende
und performante Linux-Treiber, die sich auf allen gängigen Distributionen
installieren lassen. Das hat Gründe, die im Software-Design liegen:
nVidia verwendet für alle Plattformen und alle Zielgruppen dieselbe
Codebasis.
AMD hat den "Catalyst", der auch unter Windows nur mäßig funktioniert,
aber dessen Qualität für die Gamer-Zielgruppe ausreichend ist. Der Linux-
Treiber ist ein Abfallprodukt des FireGL-Treibers, welcher primär für die
gängigen Enterprise-Distris (RHEL, SLES) entwickelt wird. Entsprechend
fallen Kompatibilität und Performance aus.
ciao, Joseph
Heiko Rossmann
May 2, 2012, 1:18:36 PM5/2/12
to
On 05/02/2012 12:21 PM, Joseph Terner wrote:
> On Wed, 02 May 2012 01:16:54 +0200, Sieghard Schicktanz wrote:
>> Du schriebst am 1 May 2012 21:29:16 GMT:
> On Wed, 02 May 2012 01:16:54 +0200, Sieghard Schicktanz wrote:
>> Du schriebst am 1 May 2012 21:29:16 GMT:
>>> Einen funktionierenden QA-Prozeß habe dafür ich. Deshalb befinden sich
>>> in meinen Boxen keine GPUs von AMD. Sind bei der Prüfung leider
>>> durchgefallen. :-)
>>
>> Schön für Dich, und noch schöner für intel.
>
> Intel hat keine konkurrenzfähigen GPUs. Der kleine Marktbegleiter von AMD
> auf dem Sektor heißt nVidia und hat zufällig hervorragend funktionierende
> und performante Linux-Treiber, die sich auf allen gängigen Distributionen
> installieren lassen. Das hat Gründe, die im Software-Design liegen:
> nVidia verwendet für alle Plattformen und alle Zielgruppen dieselbe
> Codebasis.
Und nVidia gehört (mehrheitlich) wem?
>>> in meinen Boxen keine GPUs von AMD. Sind bei der Prüfung leider
>>> durchgefallen. :-)
>>
>> Schön für Dich, und noch schöner für intel.
>
> Intel hat keine konkurrenzfähigen GPUs. Der kleine Marktbegleiter von AMD
> auf dem Sektor heißt nVidia und hat zufällig hervorragend funktionierende
> und performante Linux-Treiber, die sich auf allen gängigen Distributionen
> installieren lassen. Das hat Gründe, die im Software-Design liegen:
> nVidia verwendet für alle Plattformen und alle Zielgruppen dieselbe
> Codebasis.
http://www.pcgameshardware.de/aid,680461/Streit-um-Lizenzrechte-Intel-kauft-Nvidia/Mainboard/News/
Tatsächlich sind damit bei PC-CPUs und -GPUs nur noch zwei große
Hersteller auf dem Markt. Was nicht heißen soll, dass das das einzige
Entscheidungskriterium beim Hardware-Kauf sein sollte...
MfG, Heiko
Sieghard Schicktanz
May 2, 2012, 3:50:07 PM5/2/12
to
Hallo Peter,
Du schriebst am Wed, 2 May 2012 08:02:59 +0000 (UTC):
> > Die Arbeitsgeschwindigkeit ist natürlich nicht zu vergleichen -
> > schließlich gibt's ein "direct rendering: No" von glxinfo, und die
...
dem hier eingebauten Chip [Radeon HD 6530D]. Aber den hatte ich da ja nur
zum Ausprobieren kurz eingehängt.
(Aber ich hab' das Log ja sogar noch - nee, eine Suche nach "dri" bringt
einwandfreie Funktion von "dri" und "dri2" "nach Aussage" vom Xorg-Server.
Kein Fehler, keine Warnung, kein Wieder-Abmelden. Müßte funktionieren/t
haben. An der "libglx.so" kann's auch nicht gelegen haben - zum einen hatte
ich die umgehängt, und zum anderen startet der Server mit der falschen gar
nicht erst.)
Mit dem fglrx geht's ja, und den habe ich jetzt eigentlich als
"Arbeitsversion" eingebaut. Soviel am System runflicken, daß alle
verfügbaren Treiber optimal laufen, kann ich mir dann auch nicht leisten,
da war eigentlich die geschilderte Odyssee schon sehr "grenzwertig"...
Du schriebst am Wed, 2 May 2012 08:02:59 +0000 (UTC):
> > Die Arbeitsgeschwindigkeit ist natürlich nicht zu vergleichen -
> > schließlich gibt's ein "direct rendering: No" von glxinfo, und die
> grep mal nach dri in der Logdatei von Xorg - da ist definitiv noch was
> nicht im grünen Bereich bei Dir.
Bei dem Radeon-Treiber? Kann der "direct rendering"? Dann evtl. nicht bei
> nicht im grünen Bereich bei Dir.
dem hier eingebauten Chip [Radeon HD 6530D]. Aber den hatte ich da ja nur
zum Ausprobieren kurz eingehängt.
(Aber ich hab' das Log ja sogar noch - nee, eine Suche nach "dri" bringt
einwandfreie Funktion von "dri" und "dri2" "nach Aussage" vom Xorg-Server.
Kein Fehler, keine Warnung, kein Wieder-Abmelden. Müßte funktionieren/t
haben. An der "libglx.so" kann's auch nicht gelegen haben - zum einen hatte
ich die umgehängt, und zum anderen startet der Server mit der falschen gar
nicht erst.)
Mit dem fglrx geht's ja, und den habe ich jetzt eigentlich als
"Arbeitsversion" eingebaut. Soviel am System runflicken, daß alle
verfügbaren Treiber optimal laufen, kann ich mir dann auch nicht leisten,
da war eigentlich die geschilderte Odyssee schon sehr "grenzwertig"...
Sieghard Schicktanz
May 2, 2012, 3:38:17 PM5/2/12
to
Hallo Andreas,
Du schriebst am Wed, 02 May 2012 09:39:40 +0200:
> > Und wie verhinderst Du dann, daß er bei einem Update/grade wieder
...
Es muß einfach möglich sein, das unerwünschte Paket _gar nicht_ zu
installieren, evtl. nicht mal ein Ersatzpaket, solange man nicht was
anderes installiert, was eine darin enthaltene Funktion unbedingt braucht.
Manche sagen sogar, _nichtmal_ _dann_ sollte was automatisch mitinstalliert
werden.
Aber so eine grundsätzlich nicht für die Systemfunktion nötige Software wie
der Networkmanager oder der "traditionelle, manuelle Weg" sollte nie
automatisch installiert werden - wobei ich mir eh nicht vorstellen kann,
was bei letzterem überhaupt zu "installieren" sein sollte.
> abweichende Versionen eines Programms installiert hat. Ich habe hier
> über 20 Pakete gesperrt (darunter kdepim, akonadi, openSUSE-Spezifisches
> (branding-Geraffel), smolt, ...).
Brauch' ich hier alles nicht zu machen - ich installier' das Zeugs einfach
nicht, was nicht gebraucht wird. Geht halt natürlich dann nicht, wenn in
einem erwünschten Paket eine fest einkompilierte Abhängigkeit zu einer
Komponente vorhanden ist, die in einem unerwünschten steckt....
Das wird Dir bei Deinen gesperrten Paketen aber nicht anders ergehen.
> >> [...]
> >> Insgesamt hätte ich da jetzt eigentlich einen anderen Einspruch
> >> erwartet.
> >
> > Welchen?
>
> Calling home ...
? Meinst Du, daß die aktuellen Programme gerne mal - _ohne_ zu fragen -
"zuhause" nachfragen was es Neues gibt?
Das Problem habe ich hier nicht - hier gibt es nur dann einen Zugang ins
internet, wenn ich das explizit (oder per cron-Job) starte. Ein Programm,
das das ohne Anmeldung bei mir zu irgendeiner anderen Zeit macht, fällt auf
die Schnauze, so daß ich das mitbekommen sollte.
Das geht natürlich nicht, wenn man einen Router im Netz hat, der ständig die
Haustür offenhält... ];->
Du schriebst am Wed, 02 May 2012 09:39:40 +0200:
> > Und wie verhinderst Du dann, daß er bei einem Update/grade wieder
> Gute Distris bieten Dir mindestens die beiden Möglichkeiten (am
> konkreten Beispiel):
>
> 1. Wenn Networkmanager deinstalliert wird, wird dafür der traditionelle,
> manuelle Weg installiert.
>
> 2. generischer Ansatz (falls 1 nicht vorhanden ist): manuelles,
> einmaliges Sperren von Paketen. Braucht man ja auch dann z.B., wenn man
Das geht _beides_ schon mindestens einen Schritt zu weit.
> konkreten Beispiel):
>
> 1. Wenn Networkmanager deinstalliert wird, wird dafür der traditionelle,
> manuelle Weg installiert.
>
> 2. generischer Ansatz (falls 1 nicht vorhanden ist): manuelles,
> einmaliges Sperren von Paketen. Braucht man ja auch dann z.B., wenn man
Es muß einfach möglich sein, das unerwünschte Paket _gar nicht_ zu
installieren, evtl. nicht mal ein Ersatzpaket, solange man nicht was
anderes installiert, was eine darin enthaltene Funktion unbedingt braucht.
Manche sagen sogar, _nichtmal_ _dann_ sollte was automatisch mitinstalliert
werden.
Aber so eine grundsätzlich nicht für die Systemfunktion nötige Software wie
der Networkmanager oder der "traditionelle, manuelle Weg" sollte nie
automatisch installiert werden - wobei ich mir eh nicht vorstellen kann,
was bei letzterem überhaupt zu "installieren" sein sollte.
> abweichende Versionen eines Programms installiert hat. Ich habe hier
> über 20 Pakete gesperrt (darunter kdepim, akonadi, openSUSE-Spezifisches
> (branding-Geraffel), smolt, ...).
nicht, was nicht gebraucht wird. Geht halt natürlich dann nicht, wenn in
einem erwünschten Paket eine fest einkompilierte Abhängigkeit zu einer
Komponente vorhanden ist, die in einem unerwünschten steckt....
Das wird Dir bei Deinen gesperrten Paketen aber nicht anders ergehen.
> >> [...]
> >> Insgesamt hätte ich da jetzt eigentlich einen anderen Einspruch
> >> erwartet.
> >
> > Welchen?
>
> Calling home ...
"zuhause" nachfragen was es Neues gibt?
Das Problem habe ich hier nicht - hier gibt es nur dann einen Zugang ins
internet, wenn ich das explizit (oder per cron-Job) starte. Ein Programm,
das das ohne Anmeldung bei mir zu irgendeiner anderen Zeit macht, fällt auf
die Schnauze, so daß ich das mitbekommen sollte.
Das geht natürlich nicht, wenn man einen Router im Netz hat, der ständig die
Haustür offenhält... ];->
Sieghard Schicktanz
May 2, 2012, 3:20:36 PM5/2/12
to
Hallo Joseph,
Du schriebst am 2 May 2012 10:21:29 GMT:
> >> Oder man vermeidet einfach Distributionen, die einem solche Knüppel
> >
> > Naja, warum könnte ich wohl Arch verwenden?
>
> Das ist halt ein Moving Target. Gehört nicht zu AMDs Zielgruppe.
Das ist eine Antwort auf eine ganz andere Frage.
> >> "Abhängigkeiten" vermeidet, weil das sowieso ein völlig dysfunktionales
> >> Konzept ist.
> >
> > Also Slackware? Oder garkeine Distribution, alles selber gebaut. Welche
> > andere Distribution verwendet denn heue noch ein Paketmanagement _ohne_
> > Abhängigkeitsverwaltung?
>
> Dpkg? SNCR ;-)
Kenn'ichnich. Ich hab' mir damals das Arch installiert, weil es nicht
dauernd dazwischen funkt. Ich hätte auch Slackware genommen, aber ich kann
mir sinnlose Buchstabenkombinationen ("Paketgruppennamen") so schlecht
merken.
> > Ok, hast Recht. Noch dazu der _kurzfristige_ Gewinn - was in ein paar
...
research" vornehmen, wenn sie gegen intel bestehen wollen.
> käme "Wir investieren jetzt mal $100 Mio. in Linux-Gaming", dann wäre er
> kurze Zeit später abgelöst. :-)
Nicht, wenn er damit Gewinn einführe (einfahren könnte).
> Intel hat keine konkurrenzfähigen GPUs. Der kleine Marktbegleiter von AMD
> auf dem Sektor heißt nVidia und hat zufällig hervorragend funktionierende
Häh? Bringst Du da nicht bisserl was durcheinander? AMD hat doch grade die
_Konkurrrenz_ von nVidia gekauft, und intel hat sein eigenes Grafiksystem -
nVidia ist da zur Zeit eher bisserl abgedrängt und bemüht sich heftig, im
"embedded"-Bereich mit ARM-basierten "APU"s Fuß zu fassen. (AMD nennt seine
Kombiprozessoren zwar auch "APU"s, die basieren aber auf intel-kompatibler
Technik.) nVidia ist inzwischen ja auch bei den "Handys" in Geschäft, wo's
bisher mit intel-CPU-Technik nicht weit her ist - zu stromfressend.
> und performante Linux-Treiber, die sich auf allen gängigen Distributionen
> installieren lassen. Das hat Gründe, die im Software-Design liegen:
> nVidia verwendet für alle Plattformen und alle Zielgruppen dieselbe
> Codebasis.
What wonder - schließlich wird der Code nur an den Grafik-Chip verfüttert,
der Haupt-CPU-Teil ist doch nur bisserl Kitt um den "Füllrüssel". ;-)
> AMD hat den "Catalyst", der auch unter Windows nur mäßig funktioniert,
> aber dessen Qualität für die Gamer-Zielgruppe ausreichend ist. Der Linux-
Da gilt halt "ausreichend" ist gut genug...
> Treiber ist ein Abfallprodukt des FireGL-Treibers, welcher primär für die
> gängigen Enterprise-Distris (RHEL, SLES) entwickelt wird. Entsprechend
> fallen Kompatibilität und Performance aus.
Mag sein - mir reicht letzteres bei weitem, und bei ersterem, naja, das hab'
ich ja jetzt auch hingekriegt. Was ich mich, wenn Deine Darstellung der
Zielgruppe zutrifft, dann nur wundert, ist, was eine "Enterprise-Distri"
(-bution) mit einem "Gamer"-Treiber anfangen soll?
Du schriebst am 2 May 2012 10:21:29 GMT:
> >> Oder man vermeidet einfach Distributionen, die einem solche Knüppel
> >
> > Naja, warum könnte ich wohl Arch verwenden?
>
> Das ist halt ein Moving Target. Gehört nicht zu AMDs Zielgruppe.
> >> "Abhängigkeiten" vermeidet, weil das sowieso ein völlig dysfunktionales
> >> Konzept ist.
> >
> > Also Slackware? Oder garkeine Distribution, alles selber gebaut. Welche
> > andere Distribution verwendet denn heue noch ein Paketmanagement _ohne_
> > Abhängigkeitsverwaltung?
>
> Dpkg? SNCR ;-)
dauernd dazwischen funkt. Ich hätte auch Slackware genommen, aber ich kann
mir sinnlose Buchstabenkombinationen ("Paketgruppennamen") so schlecht
merken.
> > Ok, hast Recht. Noch dazu der _kurzfristige_ Gewinn - was in ein paar
> Wenn Du mal bei AMD in die Quartalszahlen guckst, wirst Du sehen, daß da
> wenig kurzfristiger Gewinn ist. Und wenn da ein Vorstand auf die Idee
Jaschon - AMD speziell muß halt hohe Investitionen in den Bereich "legal
> wenig kurzfristiger Gewinn ist. Und wenn da ein Vorstand auf die Idee
research" vornehmen, wenn sie gegen intel bestehen wollen.
> käme "Wir investieren jetzt mal $100 Mio. in Linux-Gaming", dann wäre er
> kurze Zeit später abgelöst. :-)
> Intel hat keine konkurrenzfähigen GPUs. Der kleine Marktbegleiter von AMD
> auf dem Sektor heißt nVidia und hat zufällig hervorragend funktionierende
_Konkurrrenz_ von nVidia gekauft, und intel hat sein eigenes Grafiksystem -
nVidia ist da zur Zeit eher bisserl abgedrängt und bemüht sich heftig, im
"embedded"-Bereich mit ARM-basierten "APU"s Fuß zu fassen. (AMD nennt seine
Kombiprozessoren zwar auch "APU"s, die basieren aber auf intel-kompatibler
Technik.) nVidia ist inzwischen ja auch bei den "Handys" in Geschäft, wo's
bisher mit intel-CPU-Technik nicht weit her ist - zu stromfressend.
> und performante Linux-Treiber, die sich auf allen gängigen Distributionen
> installieren lassen. Das hat Gründe, die im Software-Design liegen:
> nVidia verwendet für alle Plattformen und alle Zielgruppen dieselbe
> Codebasis.
der Haupt-CPU-Teil ist doch nur bisserl Kitt um den "Füllrüssel". ;-)
> AMD hat den "Catalyst", der auch unter Windows nur mäßig funktioniert,
> aber dessen Qualität für die Gamer-Zielgruppe ausreichend ist. Der Linux-
> Treiber ist ein Abfallprodukt des FireGL-Treibers, welcher primär für die
> gängigen Enterprise-Distris (RHEL, SLES) entwickelt wird. Entsprechend
> fallen Kompatibilität und Performance aus.
ich ja jetzt auch hingekriegt. Was ich mich, wenn Deine Darstellung der
Zielgruppe zutrifft, dann nur wundert, ist, was eine "Enterprise-Distri"
(-bution) mit einem "Gamer"-Treiber anfangen soll?
Andreas Hartmann
May 2, 2012, 4:55:08 PM5/2/12
to
Hallo Sieghard,
Sieghard Schicktanz schrieb:
Sieghard Schicktanz schrieb:
> Hallo Joseph,
>
> Du schriebst am 2 May 2012 10:21:29 GMT:
[...]
>
> Du schriebst am 2 May 2012 10:21:29 GMT:
>> Treiber ist ein Abfallprodukt des FireGL-Treibers, welcher primär für die
>> gängigen Enterprise-Distris (RHEL, SLES) entwickelt wird. Entsprechend
>> fallen Kompatibilität und Performance aus.
>
> Mag sein - mir reicht letzteres bei weitem, und bei ersterem, naja, das hab'
> ich ja jetzt auch hingekriegt. Was ich mich, wenn Deine Darstellung der
> Zielgruppe zutrifft, dann nur wundert, ist, was eine "Enterprise-Distri"
> (-bution) mit einem "Gamer"-Treiber anfangen soll?
Andreas
Joseph Terner
May 2, 2012, 6:13:43 PM5/2/12
to
On Wed, 02 May 2012 21:20:36 +0200, Sieghard Schicktanz wrote:
> Hallo Joseph,
>
> Du schriebst am 2 May 2012 10:21:29 GMT:
>
> Hallo Joseph,
>
> Du schriebst am 2 May 2012 10:21:29 GMT:
>
>> >> "Abhängigkeiten" vermeidet, weil das sowieso ein völlig
>> >> dysfunktionales Konzept ist.
>> >
>> > Also Slackware? Oder garkeine Distribution, alles selber gebaut.
>> > Welche andere Distribution verwendet denn heue noch ein
>> > Paketmanagement _ohne_ Abhängigkeitsverwaltung?
>>
>> Dpkg? SNCR ;-)
>
> Kenn'ichnich.
Steht für "Debian PacKaGe" und installiert Dateien mit der Endung .deb.
>> >> dysfunktionales Konzept ist.
>> >
>> > Also Slackware? Oder garkeine Distribution, alles selber gebaut.
>> > Welche andere Distribution verwendet denn heue noch ein
>> > Paketmanagement _ohne_ Abhängigkeitsverwaltung?
>>
>> Dpkg? SNCR ;-)
>
> Kenn'ichnich.
Abhängigkeiten macht ein anderes Tool.
> Ich hab' mir damals das Arch installiert, weil es nicht
> dauernd dazwischen funkt. Ich hätte auch Slackware genommen, aber ich
> kann mir sinnlose Buchstabenkombinationen ("Paketgruppennamen") so
> schlecht merken.
werden können. Im Normalfall wird nämlich immer das Komplettpaket
installiert, da das Betriebssystem in diesem Zustand getestet und so als
Basissystem für 3rd-Party-Software vorgesehen ist.
Die "Paketgruppen" heißen korrekt Serien und dienen nur der sinnvollen
Verteilung auf mehrere Installationsdatenträger, falls der Platz auf
einem einzigen nicht ausreicht.
>> Wenn Du mal bei AMD in die Quartalszahlen guckst, wirst Du sehen, daß
>> da wenig kurzfristiger Gewinn ist. Und wenn da ein Vorstand auf die
>> Idee
>> käme "Wir investieren jetzt mal $100 Mio. in Linux-Gaming", dann wäre
>> er kurze Zeit später abgelöst. :-)
>
> Nicht, wenn er damit Gewinn einführe (einfahren könnte).
Damit kann man derzeit nur Geld verbrennen.
>> er kurze Zeit später abgelöst. :-)
>
> Nicht, wenn er damit Gewinn einführe (einfahren könnte).
>> Intel hat keine konkurrenzfähigen GPUs. Der kleine Marktbegleiter von
>> AMD auf dem Sektor heißt nVidia und hat zufällig hervorragend
>> funktionierende
>> und performante Linux-Treiber, die sich auf allen gängigen
>> Distributionen installieren lassen. Das hat Gründe, die im
>> Software-Design liegen: nVidia verwendet für alle Plattformen und alle
>> Zielgruppen dieselbe Codebasis.
>
> What wonder - schließlich wird der Code nur an den Grafik-Chip
> verfüttert, der Haupt-CPU-Teil ist doch nur bisserl Kitt um den
> "Füllrüssel". ;-)
Wenn dem so wäre, dann wäre die Erstellung von Open-Source-Treibern ja
>> Distributionen installieren lassen. Das hat Gründe, die im
>> Software-Design liegen: nVidia verwendet für alle Plattformen und alle
>> Zielgruppen dieselbe Codebasis.
>
> What wonder - schließlich wird der Code nur an den Grafik-Chip
> verfüttert, der Haupt-CPU-Teil ist doch nur bisserl Kitt um den
> "Füllrüssel". ;-)
ein Kinderspiel. Statt dessen steckt in GPU-Treiber genauso viel Know-How
wie im Grafikchip selbst, wenn nicht sogar mehr.
>> AMD hat den "Catalyst", der auch unter Windows nur mäßig funktioniert,
>> aber dessen Qualität für die Gamer-Zielgruppe ausreichend ist. Der
>> Linux-
>> Treiber ist ein Abfallprodukt des FireGL-Treibers, welcher primär für
>> die gängigen Enterprise-Distris (RHEL, SLES) entwickelt wird.
>> Entsprechend fallen Kompatibilität und Performance aus.
>
> Mag sein - mir reicht letzteres bei weitem, und bei ersterem, naja, das
> hab' ich ja jetzt auch hingekriegt. Was ich mich, wenn Deine Darstellung
> der Zielgruppe zutrifft, dann nur wundert, ist, was eine
> "Enterprise-Distri" (-bution) mit einem "Gamer"-Treiber anfangen soll?
Der "fglrx" ist eben kein Gamer-Treiber.
>> die gängigen Enterprise-Distris (RHEL, SLES) entwickelt wird.
>> Entsprechend fallen Kompatibilität und Performance aus.
>
> Mag sein - mir reicht letzteres bei weitem, und bei ersterem, naja, das
> hab' ich ja jetzt auch hingekriegt. Was ich mich, wenn Deine Darstellung
> der Zielgruppe zutrifft, dann nur wundert, ist, was eine
> "Enterprise-Distri" (-bution) mit einem "Gamer"-Treiber anfangen soll?
ciao, Joseph
Joseph Terner
May 2, 2012, 6:17:17 PM5/2/12
to
On Wed, 02 May 2012 19:18:36 +0200, Heiko Rossmann wrote:
> On 05/02/2012 12:21 PM, Joseph Terner wrote:
>> On Wed, 02 May 2012 01:16:54 +0200, Sieghard Schicktanz wrote:
>>> Du schriebst am 1 May 2012 21:29:16 GMT:
>>>> Einen funktionierenden QA-Prozeß habe dafür ich. Deshalb befinden
>>>> sich in meinen Boxen keine GPUs von AMD. Sind bei der Prüfung leider
>>>> durchgefallen. :-)
>>>
>>> Schön für Dich, und noch schöner für intel.
>>
>> Intel hat keine konkurrenzfähigen GPUs. Der kleine Marktbegleiter von
>> AMD auf dem Sektor heißt nVidia und hat zufällig hervorragend
>> funktionierende und performante Linux-Treiber, die sich auf allen
>> gängigen Distributionen installieren lassen. Das hat Gründe, die im
>> Software-Design liegen: nVidia verwendet für alle Plattformen und alle
>> Zielgruppen dieselbe Codebasis.
>
> Und nVidia gehört (mehrheitlich) wem?
> http://www.pcgameshardware.de/aid,680461/Streit-um-Lizenzrechte-Intel-
kauft-Nvidia/Mainboard/News/
Achte mal auf das Datum des Artikels. :-D
> On 05/02/2012 12:21 PM, Joseph Terner wrote:
>> On Wed, 02 May 2012 01:16:54 +0200, Sieghard Schicktanz wrote:
>>> Du schriebst am 1 May 2012 21:29:16 GMT:
>>>> Einen funktionierenden QA-Prozeß habe dafür ich. Deshalb befinden
>>>> sich in meinen Boxen keine GPUs von AMD. Sind bei der Prüfung leider
>>>> durchgefallen. :-)
>>>
>>> Schön für Dich, und noch schöner für intel.
>>
>> Intel hat keine konkurrenzfähigen GPUs. Der kleine Marktbegleiter von
>> AMD auf dem Sektor heißt nVidia und hat zufällig hervorragend
>> funktionierende und performante Linux-Treiber, die sich auf allen
>> gängigen Distributionen installieren lassen. Das hat Gründe, die im
>> Software-Design liegen: nVidia verwendet für alle Plattformen und alle
>> Zielgruppen dieselbe Codebasis.
>
> Und nVidia gehört (mehrheitlich) wem?
> http://www.pcgameshardware.de/aid,680461/Streit-um-Lizenzrechte-Intel-
kauft-Nvidia/Mainboard/News/
> Tatsächlich sind damit bei PC-CPUs und -GPUs nur noch zwei große
> Hersteller auf dem Markt. Was nicht heißen soll, dass das das einzige
> Entscheidungskriterium beim Hardware-Kauf sein sollte...
ciao, Joseph
Heiko Rossmann
May 3, 2012, 2:27:12 AM5/3/12
to
On 05/03/2012 12:17 AM, Joseph Terner wrote:
> On Wed, 02 May 2012 19:18:36 +0200, Heiko Rossmann wrote:
>> On 05/02/2012 12:21 PM, Joseph Terner wrote:
>>> On Wed, 02 May 2012 01:16:54 +0200, Sieghard Schicktanz wrote:
>>>> Du schriebst am 1 May 2012 21:29:16 GMT:
>>>>> Einen funktionierenden QA-Prozeß habe dafür ich. Deshalb befinden
>>>>> sich in meinen Boxen keine GPUs von AMD. Sind bei der Prüfung leider
>>>>> durchgefallen. :-)
>>>>
>>>> Schön für Dich, und noch schöner für intel.
>>>
>>> Intel hat keine konkurrenzfähigen GPUs. Der kleine Marktbegleiter von
>>> AMD auf dem Sektor heißt nVidia und hat zufällig hervorragend
>>> funktionierende und performante Linux-Treiber, die sich auf allen
>>> gängigen Distributionen installieren lassen. Das hat Gründe, die im
>>> Software-Design liegen: nVidia verwendet für alle Plattformen und alle
>>> Zielgruppen dieselbe Codebasis.
>>
>> Und nVidia gehört (mehrheitlich) wem?
>> http://www.pcgameshardware.de/aid,680461/Streit-um-Lizenzrechte-Intel-
> kauft-Nvidia/Mainboard/News/
>
> Achte mal auf das Datum des Artikels. :-D
Was möchtest du mir damit sagen? Du hättest jetzt entweder sagen: "Ja,
> On Wed, 02 May 2012 19:18:36 +0200, Heiko Rossmann wrote:
>> On 05/02/2012 12:21 PM, Joseph Terner wrote:
>>> On Wed, 02 May 2012 01:16:54 +0200, Sieghard Schicktanz wrote:
>>>> Du schriebst am 1 May 2012 21:29:16 GMT:
>>>>> Einen funktionierenden QA-Prozeß habe dafür ich. Deshalb befinden
>>>>> sich in meinen Boxen keine GPUs von AMD. Sind bei der Prüfung leider
>>>>> durchgefallen. :-)
>>>>
>>>> Schön für Dich, und noch schöner für intel.
>>>
>>> Intel hat keine konkurrenzfähigen GPUs. Der kleine Marktbegleiter von
>>> AMD auf dem Sektor heißt nVidia und hat zufällig hervorragend
>>> funktionierende und performante Linux-Treiber, die sich auf allen
>>> gängigen Distributionen installieren lassen. Das hat Gründe, die im
>>> Software-Design liegen: nVidia verwendet für alle Plattformen und alle
>>> Zielgruppen dieselbe Codebasis.
>>
>> Und nVidia gehört (mehrheitlich) wem?
>> http://www.pcgameshardware.de/aid,680461/Streit-um-Lizenzrechte-Intel-
> kauft-Nvidia/Mainboard/News/
>
> Achte mal auf das Datum des Artikels. :-D
aber Intel hat nVidia wieder verkauft, siehe <link>" oder "oh, das
wusste ich nicht" - beides hätte mir mehr geholfen als dieser Kommentar.
MfG, Heiko
Andreas Hartmann
May 3, 2012, 2:06:56 AM5/3/12
to
Joseph Terner schrieb:
[...]
dem Direct3D-Teil des Catalyst plus einer professionellen Version des
OpenGL-Parts.
Das fglrx-Module unter Linux ist ein Kürzel und steht für "FireGL and
Radeon for X"[2]. Praktisch also ein Stück Software, das den
FireGL-Treiber der Radeon Hardware zugänglich macht. Das würde ja
heißen, daß man mit dem Linux-Catalyst quasi eine qualitativ hochwertige
Profi-Treiberversion bekommt, also keinen speziellen Gamer-Treiber (was
nicht heißt, daß er hierfür nicht auch tauglich wäre[3]). Das erklärt
natürlich die Latenzen bei der Bereitstellung von Anpassungen erst recht.
[1] http://de.wikipedia.org/wiki/ATI_FireGL
[2] http://de.wikipedia.org/wiki/AMD_Catalyst
[3]
http://www.phoronix.com/scan.php?page=article&item=amd_catalyst_legacy2&num=4
Gruß,
Andreas
[...]
> Der "fglrx" ist eben kein Gamer-Treiber.
Lt. Wikipedia[1] besteht der FireGL-Treiber für die FireGL-Karten aus
dem Direct3D-Teil des Catalyst plus einer professionellen Version des
OpenGL-Parts.
Das fglrx-Module unter Linux ist ein Kürzel und steht für "FireGL and
Radeon for X"[2]. Praktisch also ein Stück Software, das den
FireGL-Treiber der Radeon Hardware zugänglich macht. Das würde ja
heißen, daß man mit dem Linux-Catalyst quasi eine qualitativ hochwertige
Profi-Treiberversion bekommt, also keinen speziellen Gamer-Treiber (was
nicht heißt, daß er hierfür nicht auch tauglich wäre[3]). Das erklärt
natürlich die Latenzen bei der Bereitstellung von Anpassungen erst recht.
[1] http://de.wikipedia.org/wiki/ATI_FireGL
[2] http://de.wikipedia.org/wiki/AMD_Catalyst
[3]
http://www.phoronix.com/scan.php?page=article&item=amd_catalyst_legacy2&num=4
Gruß,
Andreas
Henning Paul
May 3, 2012, 3:06:31 AM5/3/12
to
denen, die erst einmal einen bitterbösen Leserbrief schreiben, weil sie
Ironie nicht erkennen, selbst wenn sie ihnen ins Gesicht springt?
Gruß
Henning
Joseph Terner
May 3, 2012, 4:57:26 AM5/3/12
to
On Thu, 03 May 2012 08:06:56 +0200, Andreas Hartmann wrote:
> Joseph Terner schrieb:
> [...]
>> Der "fglrx" ist eben kein Gamer-Treiber.
>
> Lt. Wikipedia[1] besteht der FireGL-Treiber für die FireGL-Karten aus
> dem Direct3D-Teil des Catalyst plus einer professionellen Version des
> OpenGL-Parts.
Direct3D unter Linux? Seit wann?
> Joseph Terner schrieb:
> [...]
>> Der "fglrx" ist eben kein Gamer-Treiber.
>
> Lt. Wikipedia[1] besteht der FireGL-Treiber für die FireGL-Karten aus
> dem Direct3D-Teil des Catalyst plus einer professionellen Version des
> OpenGL-Parts.
> Das fglrx-Module unter Linux ist ein Kürzel und steht für "FireGL and
> Radeon for X"[2]. Praktisch also ein Stück Software, das den
> FireGL-Treiber der Radeon Hardware zugänglich macht. Das würde ja
> heißen, daß man mit dem Linux-Catalyst quasi eine qualitativ hochwertige
> Profi-Treiberversion bekommt,
Die Leute sollen ja schließlich die FirePro-Karten kaufen.
> also keinen speziellen Gamer-Treiber (was
> nicht heißt, daß er hierfür nicht auch tauglich wäre[3]). Das erklärt
> natürlich die Latenzen bei der Bereitstellung von Anpassungen erst
> recht.
als die Rendergeschwindigkeit, wobei erstere natürlich wiederum nur für
die Profi-Karten zertifiziert ist, die Performance aber trotzdem fehlt.
Gute Unterstützung nur für Enterprise-Linux, die sich naturgemäß wenig am
Release-Zyklus des Vanilla-Kernels orientieren.
ciao, Joseph
Andreas Hartmann
May 3, 2012, 8:50:46 AM5/3/12
to
Joseph Terner schrieb:
Gilt vermutlich nur für Windows. Die Aussage ist da nicht ganz scharf.
>> Das fglrx-Module unter Linux ist ein Kürzel und steht für "FireGL and
>> Radeon for X"[2]. Praktisch also ein Stück Software, das den
>> FireGL-Treiber der Radeon Hardware zugänglich macht. Das würde ja
>> heißen, daß man mit dem Linux-Catalyst quasi eine qualitativ hochwertige
>> Profi-Treiberversion bekommt,
>
> Natürlich nicht, die ganzen "Profi-Features" sind natürlich deaktiviert.
> Die Leute sollen ja schließlich die FirePro-Karten kaufen.
Oder sie sind nicht nutzbar, da hardwareseitig von Radeon-Karten nicht
unterstützt.
http://de.wikipedia.org/wiki/AMD_Catalyst unter "Linux":
Der Name "FireGL and Radeon for X" (fglrx) impliziert, daß ein Treiber
beide Karten unterstützen soll (anders als bei Windows, wo es zwei
unterschiedliche Treiber zu geben scheint).
>> also keinen speziellen Gamer-Treiber (was
>> nicht heißt, daß er hierfür nicht auch tauglich wäre[3]). Das erklärt
>> natürlich die Latenzen bei der Bereitstellung von Anpassungen erst
>> recht.
>
> Dafür halt die ganzen Nachteile: Korrektheit der Ausgabe höher gewichtet,
> als die Rendergeschwindigkeit, wobei erstere natürlich wiederum nur für
> die Profi-Karten zertifiziert ist, die Performance aber trotzdem fehlt.
Wie kommst Du darauf, daß die Performance fehlt (relativ wozu)? Hier
würden mich Fakten interessieren. Zumindest relativ zum OSS
radeon-Treiber ist der fglrx rasend schnell, wie man hier sehen kann:
http://www.phoronix.com/scan.php?page=article&item=amd_catalyst_legacy2&num=4
> Gute Unterstützung nur für Enterprise-Linux, die sich naturgemäß wenig am
> Release-Zyklus des Vanilla-Kernels orientieren.
Deckt sich ja mit meiner Aussage der Latenzen.
Ich sehe darin allerdings keine großen Nachteile, solange eine Brücke
zwischen den beiden Konzepten (OSS vs. Business) besteht.
Hmm, ich glaube ich muß mir diesbezüglich mal CentOS anschauen.
Gruß,
Andreas
> On Thu, 03 May 2012 08:06:56 +0200, Andreas Hartmann wrote:
>
>> Joseph Terner schrieb:
>> [...]
>>> Der "fglrx" ist eben kein Gamer-Treiber.
>>
>> Lt. Wikipedia[1] besteht der FireGL-Treiber für die FireGL-Karten aus
>> dem Direct3D-Teil des Catalyst plus einer professionellen Version des
>> OpenGL-Parts.
>
> Direct3D unter Linux? Seit wann?
http://de.wikipedia.org/wiki/ATI_FireGL unter "Treiber":
>
>> Joseph Terner schrieb:
>> [...]
>>> Der "fglrx" ist eben kein Gamer-Treiber.
>>
>> Lt. Wikipedia[1] besteht der FireGL-Treiber für die FireGL-Karten aus
>> dem Direct3D-Teil des Catalyst plus einer professionellen Version des
>> OpenGL-Parts.
>
> Direct3D unter Linux? Seit wann?
Gilt vermutlich nur für Windows. Die Aussage ist da nicht ganz scharf.
>> Das fglrx-Module unter Linux ist ein Kürzel und steht für "FireGL and
>> Radeon for X"[2]. Praktisch also ein Stück Software, das den
>> FireGL-Treiber der Radeon Hardware zugänglich macht. Das würde ja
>> heißen, daß man mit dem Linux-Catalyst quasi eine qualitativ hochwertige
>> Profi-Treiberversion bekommt,
>
> Natürlich nicht, die ganzen "Profi-Features" sind natürlich deaktiviert.
> Die Leute sollen ja schließlich die FirePro-Karten kaufen.
unterstützt.
http://de.wikipedia.org/wiki/AMD_Catalyst unter "Linux":
Der Name "FireGL and Radeon for X" (fglrx) impliziert, daß ein Treiber
beide Karten unterstützen soll (anders als bei Windows, wo es zwei
unterschiedliche Treiber zu geben scheint).
>> also keinen speziellen Gamer-Treiber (was
>> nicht heißt, daß er hierfür nicht auch tauglich wäre[3]). Das erklärt
>> natürlich die Latenzen bei der Bereitstellung von Anpassungen erst
>> recht.
>
> Dafür halt die ganzen Nachteile: Korrektheit der Ausgabe höher gewichtet,
> als die Rendergeschwindigkeit, wobei erstere natürlich wiederum nur für
> die Profi-Karten zertifiziert ist, die Performance aber trotzdem fehlt.
würden mich Fakten interessieren. Zumindest relativ zum OSS
radeon-Treiber ist der fglrx rasend schnell, wie man hier sehen kann:
http://www.phoronix.com/scan.php?page=article&item=amd_catalyst_legacy2&num=4
> Gute Unterstützung nur für Enterprise-Linux, die sich naturgemäß wenig am
> Release-Zyklus des Vanilla-Kernels orientieren.
Ich sehe darin allerdings keine großen Nachteile, solange eine Brücke
zwischen den beiden Konzepten (OSS vs. Business) besteht.
Hmm, ich glaube ich muß mir diesbezüglich mal CentOS anschauen.
Gruß,
Andreas
Joseph Terner
May 3, 2012, 1:26:02 PM5/3/12
to
On Thu, 03 May 2012 14:50:46 +0200, Andreas Hartmann wrote:
> Joseph Terner schrieb:
>> On Thu, 03 May 2012 08:06:56 +0200, Andreas Hartmann wrote:
>>
>>> Joseph Terner schrieb:
>>> [...]
>>>> Der "fglrx" ist eben kein Gamer-Treiber.
[...]
> Joseph Terner schrieb:
>> On Thu, 03 May 2012 08:06:56 +0200, Andreas Hartmann wrote:
>>
>>> Joseph Terner schrieb:
>>> [...]
>>>> Der "fglrx" ist eben kein Gamer-Treiber.
>>> also keinen speziellen Gamer-Treiber (was nicht heißt, daß er hierfür
>>> nicht auch tauglich wäre[3]). Das erklärt natürlich die Latenzen bei
>>> der Bereitstellung von Anpassungen erst recht.
>>
>> Dafür halt die ganzen Nachteile: Korrektheit der Ausgabe höher
>> gewichtet, als die Rendergeschwindigkeit, wobei erstere natürlich
>> wiederum nur für die Profi-Karten zertifiziert ist, die Performance
>> aber trotzdem fehlt.
>
> Wie kommst Du darauf, daß die Performance fehlt (relativ wozu)?
Relativ zum Windows-Catalyst. Und zwar recht happig. Von Dingen wie Video-
>>> nicht auch tauglich wäre[3]). Das erklärt natürlich die Latenzen bei
>>> der Bereitstellung von Anpassungen erst recht.
>>
>> Dafür halt die ganzen Nachteile: Korrektheit der Ausgabe höher
>> gewichtet, als die Rendergeschwindigkeit, wobei erstere natürlich
>> wiederum nur für die Profi-Karten zertifiziert ist, die Performance
>> aber trotzdem fehlt.
>
> Wie kommst Du darauf, daß die Performance fehlt (relativ wozu)?
Decoding usw. mal ganz abgesehen.
> Hier
> würden mich Fakten interessieren. Zumindest relativ zum OSS
> radeon-Treiber ist der fglrx rasend schnell
mit und kann die bezahlte Leistung nicht nutzen.
ciao, Joseph
Sieghard Schicktanz
May 3, 2012, 4:03:56 PM5/3/12
to
Hallo Joseph,
Du schriebst am 2 May 2012 22:13:43 GMT:
> >> > Welche andere Distribution verwendet denn heue noch ein
> >> > Paketmanagement _ohne_ Abhängigkeitsverwaltung?
> >>
> >> Dpkg? SNCR ;-)
...
Da, wo die Abhängigkeitsverwaltung excessiv betrieben wird. Andererseits
muß man zugestehen, daß es da auch optionale Abhängigkeiten gibt, die aber
auch wieder nicht dem Benutzer fallwesie selektv angeboten werden, sondern
mit einem "alles oder nichts"-Schalter behandelt oder zum Sissyphus-Job der
Vorausdefinition zu werden scheinen.
> Slackware ist in Packages unterteilt, damit problemlos Updates verteilt
> werden können. Im Normalfall wird nämlich immer das Komplettpaket
Schon recht, aber diese Sammlungen sind recht dekorativ, aber überhaupt
nicht kennzeichnend benannt. D.h. wenn man was sucht muß man immer wieder
_alle_ durchwühlen. Sie sind ja nichtmal recht thematisch sortiert.
> Die "Paketgruppen" heißen korrekt Serien und dienen nur der sinnvollen
> Verteilung auf mehrere Installationsdatenträger, falls der Platz auf
> einem einzigen nicht ausreicht.
Mehr leisten sie auch nicht. und das ist inzwischen eher überflüssig.
Sind die "Serien" eigentlich überhaupt noch ähnlich im Umfang? Nur dann
ergäbe diese Verteilung ja annähernd Sinn.
> > Nicht, wenn er damit Gewinn einführe (einfahren könnte).
>
> Damit kann man derzeit nur Geld verbrennen.
Ich habe nichts Gegenteiliges behauptet - das war nur ein Beispiel und
könnte auch was ganz anderes sein.
> > What wonder - schließlich wird der Code nur an den Grafik-Chip
> > verfüttert, der Haupt-CPU-Teil ist doch nur bisserl Kitt um den
> > "Füllrüssel". ;-)
>
> Wenn dem so wäre, dann wäre die Erstellung von Open-Source-Treibern ja
> ein Kinderspiel.
Eher nicht - ohne den GPU-Teil geht ja gerade _nichts_, egal wie gut der
CPU-Code "reverse engineered" ist.
> ein Kinderspiel. Statt dessen steckt in GPU-Treiber genauso viel Know-How
> wie im Grafikchip selbst, wenn nicht sogar mehr.
Eben, das ist ja der Teil, der nur binär vorliegt. Und den zu dekodieren
ist mangels der zugrundeliegenden Strukturen (Datenformate, Register,
Befehlscodes) praktisch unmöglich.
> Der "fglrx" ist eben kein Gamer-Treiber.
Mag sein - es gibt jedenfalls nur _sehr_ wenige Nicht-"Gamer"-Anwendungen,
für die er nicht weit mehr als ausreichend ist.
Du schriebst am 2 May 2012 22:13:43 GMT:
> >> > Welche andere Distribution verwendet denn heue noch ein
> >> > Paketmanagement _ohne_ Abhängigkeitsverwaltung?
> >>
> >> Dpkg? SNCR ;-)
> Steht für "Debian PacKaGe" und installiert Dateien mit der Endung .deb.
>
> Abhängigkeiten macht ein anderes Tool.
Ausgerechnet Debian...
>
> Abhängigkeiten macht ein anderes Tool.
Da, wo die Abhängigkeitsverwaltung excessiv betrieben wird. Andererseits
muß man zugestehen, daß es da auch optionale Abhängigkeiten gibt, die aber
auch wieder nicht dem Benutzer fallwesie selektv angeboten werden, sondern
mit einem "alles oder nichts"-Schalter behandelt oder zum Sissyphus-Job der
Vorausdefinition zu werden scheinen.
> Slackware ist in Packages unterteilt, damit problemlos Updates verteilt
> werden können. Im Normalfall wird nämlich immer das Komplettpaket
nicht kennzeichnend benannt. D.h. wenn man was sucht muß man immer wieder
_alle_ durchwühlen. Sie sind ja nichtmal recht thematisch sortiert.
> Die "Paketgruppen" heißen korrekt Serien und dienen nur der sinnvollen
> Verteilung auf mehrere Installationsdatenträger, falls der Platz auf
> einem einzigen nicht ausreicht.
Sind die "Serien" eigentlich überhaupt noch ähnlich im Umfang? Nur dann
ergäbe diese Verteilung ja annähernd Sinn.
> > Nicht, wenn er damit Gewinn einführe (einfahren könnte).
>
> Damit kann man derzeit nur Geld verbrennen.
könnte auch was ganz anderes sein.
> > What wonder - schließlich wird der Code nur an den Grafik-Chip
> > verfüttert, der Haupt-CPU-Teil ist doch nur bisserl Kitt um den
> > "Füllrüssel". ;-)
>
> Wenn dem so wäre, dann wäre die Erstellung von Open-Source-Treibern ja
> ein Kinderspiel.
CPU-Code "reverse engineered" ist.
> ein Kinderspiel. Statt dessen steckt in GPU-Treiber genauso viel Know-How
> wie im Grafikchip selbst, wenn nicht sogar mehr.
ist mangels der zugrundeliegenden Strukturen (Datenformate, Register,
Befehlscodes) praktisch unmöglich.
> Der "fglrx" ist eben kein Gamer-Treiber.
für die er nicht weit mehr als ausreichend ist.
Joseph Terner
May 3, 2012, 5:50:54 PM5/3/12
to
On Thu, 03 May 2012 22:03:56 +0200, Sieghard Schicktanz wrote:
> Hallo Joseph,
>
> Du schriebst am 2 May 2012 22:13:43 GMT:
>
>> >> > Welche andere Distribution verwendet denn heue noch ein
>> >> > Paketmanagement _ohne_ Abhängigkeitsverwaltung?
>> >>
>> >> Dpkg? SNCR ;-)
> ...
>> Steht für "Debian PacKaGe" und installiert Dateien mit der Endung .deb.
>>
>> Abhängigkeiten macht ein anderes Tool.
>
> Ausgerechnet Debian...
> Da, wo die Abhängigkeitsverwaltung excessiv betrieben wird.
Nicht exzessiver als bei anderen. Aber wie gesagt, das erledigt dort ein
> Hallo Joseph,
>
> Du schriebst am 2 May 2012 22:13:43 GMT:
>
>> >> > Welche andere Distribution verwendet denn heue noch ein
>> >> > Paketmanagement _ohne_ Abhängigkeitsverwaltung?
>> >>
>> >> Dpkg? SNCR ;-)
> ...
>> Steht für "Debian PacKaGe" und installiert Dateien mit der Endung .deb.
>>
>> Abhängigkeiten macht ein anderes Tool.
>
> Ausgerechnet Debian...
> Da, wo die Abhängigkeitsverwaltung excessiv betrieben wird.
Frontend.
>> Slackware ist in Packages unterteilt, damit problemlos Updates verteilt
>> werden können. Im Normalfall wird nämlich immer das Komplettpaket
>
> Schon recht, aber diese Sammlungen sind recht dekorativ, aber überhaupt
> nicht kennzeichnend benannt. D.h. wenn man was sucht muß man immer
> wieder _alle_ durchwühlen.
hilft dabei.
> Sie sind ja nichtmal recht thematisch
> sortiert.
>> Die "Paketgruppen" heißen korrekt Serien und dienen nur der sinnvollen
>> Verteilung auf mehrere Installationsdatenträger, falls der Platz auf
>> einem einzigen nicht ausreicht.
>
> Mehr leisten sie auch nicht. und das ist inzwischen eher überflüssig.
> Sind die "Serien" eigentlich überhaupt noch ähnlich im Umfang? Nur dann
> ergäbe diese Verteilung ja annähernd Sinn.
ciao, Joseph
Heiko Rossmann
May 4, 2012, 2:41:52 AM5/4/12
to
finden, und dachte, Joseph bezieht sich auf das Jahr...
Dann zieh ich alles zurück. Sorry.
MfG, Heiko
Andreas Hartmann
May 4, 2012, 7:41:28 AM5/4/12
to
Joseph Terner schrieb:
> On Thu, 03 May 2012 14:50:46 +0200, Andreas Hartmann wrote:
>> Joseph Terner schrieb:
>>> On Thu, 03 May 2012 08:06:56 +0200, Andreas Hartmann wrote:
>>>
>>>> Joseph Terner schrieb:
>>>> [...]
>>>>> Der "fglrx" ist eben kein Gamer-Treiber.
> [...]
>>>> also keinen speziellen Gamer-Treiber (was nicht heißt, daß er hierfür
>>>> nicht auch tauglich wäre[3]). Das erklärt natürlich die Latenzen bei
>>>> der Bereitstellung von Anpassungen erst recht.
>>>
>>> Dafür halt die ganzen Nachteile: Korrektheit der Ausgabe höher
>>> gewichtet, als die Rendergeschwindigkeit, wobei erstere natürlich
>>> wiederum nur für die Profi-Karten zertifiziert ist, die Performance
>>> aber trotzdem fehlt.
>>
>> Wie kommst Du darauf, daß die Performance fehlt (relativ wozu)?
>
> Relativ zum Windows-Catalyst. Und zwar recht happig. Von Dingen wie Video-
> Decoding usw. mal ganz abgesehen.
Video decoding kann fglrx zumindest teilweise via vaapi und vlc auch (ob
> On Thu, 03 May 2012 14:50:46 +0200, Andreas Hartmann wrote:
>> Joseph Terner schrieb:
>>> On Thu, 03 May 2012 08:06:56 +0200, Andreas Hartmann wrote:
>>>
>>>> Joseph Terner schrieb:
>>>> [...]
>>>>> Der "fglrx" ist eben kein Gamer-Treiber.
> [...]
>>>> also keinen speziellen Gamer-Treiber (was nicht heißt, daß er hierfür
>>>> nicht auch tauglich wäre[3]). Das erklärt natürlich die Latenzen bei
>>>> der Bereitstellung von Anpassungen erst recht.
>>>
>>> Dafür halt die ganzen Nachteile: Korrektheit der Ausgabe höher
>>> gewichtet, als die Rendergeschwindigkeit, wobei erstere natürlich
>>> wiederum nur für die Profi-Karten zertifiziert ist, die Performance
>>> aber trotzdem fehlt.
>>
>> Wie kommst Du darauf, daß die Performance fehlt (relativ wozu)?
>
> Relativ zum Windows-Catalyst. Und zwar recht happig. Von Dingen wie Video-
> Decoding usw. mal ganz abgesehen.
das dem entspricht, was unter Windows geht, weiß ich nicht).
>> Hier
>> würden mich Fakten interessieren. Zumindest relativ zum OSS
>> radeon-Treiber ist der fglrx rasend schnell
>
> Das ist keine Kunst. Trotzdem bezahlt man die Entwicklung des Catalyst
> mit und kann die bezahlte Leistung nicht nutzen.
dramatisch?
Gruß,
Andreas
Joseph Terner
May 4, 2012, 8:59:58 AM5/4/12
to
On Fri, 04 May 2012 13:41:28 +0200, Andreas Hartmann wrote:
> Joseph Terner schrieb:
>> On Thu, 03 May 2012 14:50:46 +0200, Andreas Hartmann wrote:
>>> Joseph Terner schrieb:
>>>> On Thu, 03 May 2012 08:06:56 +0200, Andreas Hartmann wrote:
>>>>
>>>>> Joseph Terner schrieb:
>>>>> [...]
>>>>>> Der "fglrx" ist eben kein Gamer-Treiber.
>> [...]
>>>>> also keinen speziellen Gamer-Treiber (was nicht heißt, daß er
>>>>> hierfür nicht auch tauglich wäre[3]). Das erklärt natürlich die
>>>>> Latenzen bei der Bereitstellung von Anpassungen erst recht.
>>>>
>>>> Dafür halt die ganzen Nachteile: Korrektheit der Ausgabe höher
>>>> gewichtet, als die Rendergeschwindigkeit, wobei erstere natürlich
>>>> wiederum nur für die Profi-Karten zertifiziert ist, die Performance
>>>> aber trotzdem fehlt.
>>>
>>> Wie kommst Du darauf, daß die Performance fehlt (relativ wozu)?
>>
>> Relativ zum Windows-Catalyst. Und zwar recht happig. Von Dingen wie
>> Video- Decoding usw. mal ganz abgesehen.
>
> Video decoding kann fglrx zumindest teilweise via vaapi und vlc auch
Der fglrx kann nur XvBA, das erheblich schlechter unterstützt als bspw.
> Joseph Terner schrieb:
>> On Thu, 03 May 2012 14:50:46 +0200, Andreas Hartmann wrote:
>>> Joseph Terner schrieb:
>>>> On Thu, 03 May 2012 08:06:56 +0200, Andreas Hartmann wrote:
>>>>
>>>>> Joseph Terner schrieb:
>>>>> [...]
>>>>>> Der "fglrx" ist eben kein Gamer-Treiber.
>> [...]
>>>>> also keinen speziellen Gamer-Treiber (was nicht heißt, daß er
>>>>> hierfür nicht auch tauglich wäre[3]). Das erklärt natürlich die
>>>>> Latenzen bei der Bereitstellung von Anpassungen erst recht.
>>>>
>>>> Dafür halt die ganzen Nachteile: Korrektheit der Ausgabe höher
>>>> gewichtet, als die Rendergeschwindigkeit, wobei erstere natürlich
>>>> wiederum nur für die Profi-Karten zertifiziert ist, die Performance
>>>> aber trotzdem fehlt.
>>>
>>> Wie kommst Du darauf, daß die Performance fehlt (relativ wozu)?
>>
>> Relativ zum Windows-Catalyst. Und zwar recht happig. Von Dingen wie
>> Video- Decoding usw. mal ganz abgesehen.
>
> Video decoding kann fglrx zumindest teilweise via vaapi und vlc auch
VDPAU. VA API ist für die Intel-Chipsätze.
>>> Hier
>>> würden mich Fakten interessieren. Zumindest relativ zum OSS
>>> radeon-Treiber ist der fglrx rasend schnell
>>
>> Das ist keine Kunst. Trotzdem bezahlt man die Entwicklung des Catalyst
>> mit und kann die bezahlte Leistung nicht nutzen.
>
> Wie sieht denn der Vergleich Windows / Linux bei nvidia aus? Auch so
> dramatisch?
mit VDPAU und CUDA auch APIs bereit, um die anderen GPU-Funktionen voll
nutzen zu können.
ciao, Joseph
Andreas Hartmann
May 5, 2012, 6:23:20 AM5/5/12
to
Joseph Terner schrieb:
http://freedesktop.org/wiki/Software/vaapi
> VDPAU. VA API ist für die Intel-Chipsätze.
VA API stammt zwar ursprünglich von Intel, ist aber nicht an die
Hardware gebunden. XvBA wurde von AMD als Konkurrenz zu VDPAU von nvidia
als Backend für die VA API bereitgestellt (wie VDPAU auch) - was ja auch
sinnvoll ist, damit Anwendungen nicht noch eine weitere Schnittstelle
programmieren müssen.
Details hier:
http://www.sebastian-siebert.de/2011/09/11/opensuse-hardware-videobeschleunigung-via-xvba-vom-amd-catalyst-nutzen/
Gruß,
Andreas
> On Fri, 04 May 2012 13:41:28 +0200, Andreas Hartmann wrote:
>> Joseph Terner schrieb:
>>> On Thu, 03 May 2012 14:50:46 +0200, Andreas Hartmann wrote:
[...]
>> Joseph Terner schrieb:
>>> On Thu, 03 May 2012 14:50:46 +0200, Andreas Hartmann wrote:
>>>> Wie kommst Du darauf, daß die Performance fehlt (relativ wozu)?
>>>
>>> Relativ zum Windows-Catalyst. Und zwar recht happig. Von Dingen wie
>>> Video- Decoding usw. mal ganz abgesehen.
>>
>> Video decoding kann fglrx zumindest teilweise via vaapi und vlc auch
>
> Der fglrx kann nur XvBA, das erheblich schlechter unterstützt als bspw.
Überall, wo va-api eben genutzt wird:
>>>
>>> Relativ zum Windows-Catalyst. Und zwar recht happig. Von Dingen wie
>>> Video- Decoding usw. mal ganz abgesehen.
>>
>> Video decoding kann fglrx zumindest teilweise via vaapi und vlc auch
>
> Der fglrx kann nur XvBA, das erheblich schlechter unterstützt als bspw.
http://freedesktop.org/wiki/Software/vaapi
> VDPAU. VA API ist für die Intel-Chipsätze.
Hardware gebunden. XvBA wurde von AMD als Konkurrenz zu VDPAU von nvidia
als Backend für die VA API bereitgestellt (wie VDPAU auch) - was ja auch
sinnvoll ist, damit Anwendungen nicht noch eine weitere Schnittstelle
programmieren müssen.
Details hier:
http://www.sebastian-siebert.de/2011/09/11/opensuse-hardware-videobeschleunigung-via-xvba-vom-amd-catalyst-nutzen/
Gruß,
Andreas
Patrick Rudin
May 7, 2012, 5:05:21 PM5/7/12
to
Joseph Terner wrote:
> Intel hat keine konkurrenzfähigen GPUs.
Äh?
> Intel hat keine konkurrenzfähigen GPUs.
Phoronix hat grad neulich das Ivybridge (HD 4000)-Geraffel grob
getestet. Meine Radeon 5750 (mit freiem Treiber) lag da recht
vergleichbar drin -- je nach Spiel etwas schlechter oder etwas besser.
Nur dass Intel funktionierendes Power-Management bietet. Und neu auch
drei Monitore gleichzeitig bedienen kann. Und die Treiber-Unterstützung
inzwischen recht aktuell ist.
Da muss man sich schon noch fragen, wer künftig noch eine
Unter-/Mittelklasse-Karte von AMD oder Nvidia kaufen soll.
Hardcore-Gamer (haben die Linux?) werden eh den Blob bevorzugen, und da
AMD gegenüber Nvidia wohl eher schlechte Karten.
Gruss
Patrick
Joseph Terner
May 7, 2012, 6:58:16 PM5/7/12
to
On Mon, 07 May 2012 23:05:21 +0200, Patrick Rudin wrote:
> Joseph Terner wrote:
>> Intel hat keine konkurrenzfähigen GPUs.
>
> Joseph Terner wrote:
>> Intel hat keine konkurrenzfähigen GPUs.
>
> Phoronix hat grad neulich das Ivybridge (HD 4000)-Geraffel grob
> getestet.
Mit 16 Streamprozessoren ist jetzt wohl auf dem Stand einer acht Jahre
> getestet.
alten Geforce 6800 angekommen. Gut, zum vorherigen Stand (entsprach etwa
2001-2003) ist das natürlich ein kleiner Fortschritt.
> Meine Radeon 5750 (mit freiem Treiber) lag da recht
> vergleichbar drin -- je nach Spiel etwas schlechter oder etwas besser.
schafft theoretisch ein TFLOP. Da muß man sich schon anstrengen, um gegen
den HD4000 (irgendwo unter 100 GFLOPs) zu verlieren.
> Nur dass Intel funktionierendes Power-Management bietet.
weitersäuft, wenn man sie im BIOS wegen einer dezidierten Grafikkarte
deaktiviert?
> Und neu auch drei Monitore gleichzeitig bedienen kann.
> Und die Treiber-Unterstützung inzwischen recht aktuell ist.
> Da muss man sich schon noch fragen, wer künftig noch eine
> Unter-/Mittelklasse-Karte von AMD oder Nvidia kaufen soll.
> Hardcore-Gamer (haben die Linux?) werden eh den Blob bevorzugen, und da
> AMD gegenüber Nvidia wohl eher schlechte Karten.
bevorzugen. Das ist nämlich die Hauptanwendung dieser GPUs für Linux.
ciao, Joseph
Patrick Rudin
May 8, 2012, 8:01:05 AM5/8/12
to
Joseph Terner wrote:
Die Frage ist doch einfach, ob AMD in den nächsten Jahren ihre freien
Treiber entsprechend verbessern werden.
>> > Nur dass Intel funktionierendes Power-Management bietet.
> Du meinst das Powermanagement, das so aussieht, daß die überflüssige GPU
> weitersäuft, wenn man sie im BIOS wegen einer dezidierten Grafikkarte
> deaktiviert?
Oki, unschön. Das ist aber Zeugs vor Sandybridge, oder?
AMD bietet leider in der Hinsicht gar nichts. Beim lokalen
Stromversorger kann man sich kostenlos Messgeräte holen, um mal zu
sehen, was man so zieht. Möchte schon länger wissen, was meine 5750 an
drei Monitoren im Desktop-idle(tm) so zieht. Aber ich trau mich nicht.
>> > Da muss man sich schon noch fragen, wer künftig noch eine
>> > Unter-/Mittelklasse-Karte von AMD oder Nvidia kaufen soll.
> Leute, die Phoronix nicht ganz so ernstnehmen wie Du. :-)
Ach komm, _der_ Vergleich war doch noch einigermassen praxisgerecht.
Gruss
Patrick
> Patrick Rudin wrote:
>> > Meine Radeon 5750 (mit freiem Treiber) lag da recht
>> > vergleichbar drin -- je nach Spiel etwas schlechter oder etwas besser.
> Kannst mal sehen, wie schlecht die "freien" Treiber sind.
Ja, streu Du nur Salz in die Wunden.
>> > Meine Radeon 5750 (mit freiem Treiber) lag da recht
>> > vergleichbar drin -- je nach Spiel etwas schlechter oder etwas besser.
> Kannst mal sehen, wie schlecht die "freien" Treiber sind.
Die Frage ist doch einfach, ob AMD in den nächsten Jahren ihre freien
Treiber entsprechend verbessern werden.
>> > Nur dass Intel funktionierendes Power-Management bietet.
> Du meinst das Powermanagement, das so aussieht, daß die überflüssige GPU
> weitersäuft, wenn man sie im BIOS wegen einer dezidierten Grafikkarte
> deaktiviert?
AMD bietet leider in der Hinsicht gar nichts. Beim lokalen
Stromversorger kann man sich kostenlos Messgeräte holen, um mal zu
sehen, was man so zieht. Möchte schon länger wissen, was meine 5750 an
drei Monitoren im Desktop-idle(tm) so zieht. Aber ich trau mich nicht.
>> > Da muss man sich schon noch fragen, wer künftig noch eine
>> > Unter-/Mittelklasse-Karte von AMD oder Nvidia kaufen soll.
> Leute, die Phoronix nicht ganz so ernstnehmen wie Du. :-)
Gruss
Patrick
Joseph Terner
May 8, 2012, 1:37:58 PM5/8/12
to
On Tue, 08 May 2012 14:01:05 +0200, Patrick Rudin wrote:
> Joseph Terner wrote:
>> Patrick Rudin wrote:
>>> > Meine Radeon 5750 (mit freiem Treiber) lag da recht vergleichbar
>>> > drin -- je nach Spiel etwas schlechter oder etwas besser.
>> Kannst mal sehen, wie schlecht die "freien" Treiber sind.
>
> Ja, streu Du nur Salz in die Wunden.
>
> Die Frage ist doch einfach, ob AMD in den nächsten Jahren ihre freien
> Treiber entsprechend verbessern werden.
AMD hat einen freien Treiber? Wo?
> Joseph Terner wrote:
>> Patrick Rudin wrote:
>>> > Meine Radeon 5750 (mit freiem Treiber) lag da recht vergleichbar
>>> > drin -- je nach Spiel etwas schlechter oder etwas besser.
>> Kannst mal sehen, wie schlecht die "freien" Treiber sind.
>
> Ja, streu Du nur Salz in die Wunden.
>
> Die Frage ist doch einfach, ob AMD in den nächsten Jahren ihre freien
> Treiber entsprechend verbessern werden.
>>> > Nur dass Intel funktionierendes Power-Management bietet.
>> Du meinst das Powermanagement, das so aussieht, daß die überflüssige
>> GPU weitersäuft, wenn man sie im BIOS wegen einer dezidierten
>> Grafikkarte deaktiviert?
>
> Oki, unschön. Das ist aber Zeugs vor Sandybridge, oder?
gemeint. Da sind durchaus bis zu 20 W zusätzlich drin. Aber die Profis
können ja Xeons kaufen, die haben keine GPU.
> AMD bietet leider in der Hinsicht gar nichts. Beim lokalen
> Stromversorger kann man sich kostenlos Messgeräte holen, um mal zu
> sehen, was man so zieht.
> Möchte schon länger wissen, was meine 5750 an
> drei Monitoren im Desktop-idle(tm) so zieht. Aber ich trau mich nicht.
Grafikchips. Fällt ja gegenüber den Monitoren auch nicht mehr sonderlich
ins Gewicht. :-)
ciao, Joseph
Patrick Rudin
May 9, 2012, 6:56:50 AM5/9/12
to
Joseph Terner wrote:
> AMD hat einen freien Treiber? Wo?
Afair arbeiten beim Radeon-Treiber auch AMD-Angestellte während der
> AMD hat einen freien Treiber? Wo?
Arbeitszeit kräftig mit.
> Aber die Profis können ja Xeons kaufen,
> die haben keine GPU.
> Mehrschirmbetrieb deaktiviert die Stromsparfunktionen
> der meisten Grafikchips.
Desktop-Idle sprechen kann. Mein Netbook jedenfalls läuft pro Akkuladung
deutlich kürzer als noch mit altem Gnome.
> Fällt ja gegenüber den Monitoren auch nicht mehr sonderlich
> ins Gewicht. :-)
Gruss
Patrick
Andreas Hartmann
May 10, 2012, 2:01:51 AM5/10/12
to
Patrick Rudin schrieb:
sicherlich auch aktiv zensiert zu werden), daß keine
marktwirtschaftlich, competitive relevanten Informationen (=
Betriebsgeheimnisse) in der erstellten Software enthalten oder ableitbar
sind. Ich beneide die nicht um ihren Job.
Aus Wettbewerbsgründen wirst Du in einem OS-Treiber immer nur das
finden, was unter allen konkurrierenden Anbietern sowieso common sense
ist. Egal, wer daran arbeitet.
Fazit:
Im Vergleich zu einem halbwegs ordentlichen closed source Treiber wird
der OS-Treiber immer schlechter sein müssen in einem Wettbewerbsumfeld
wie den Grakas z.B.
Andreas
> Joseph Terner wrote:
>> AMD hat einen freien Treiber? Wo?
>
> Afair arbeiten beim Radeon-Treiber auch AMD-Angestellte während der
> Arbeitszeit kräftig mit.
Ja. "Arbeiten" heißt an dieser Stelle: Sich selbst so zu zensieren (bzw.
>> AMD hat einen freien Treiber? Wo?
>
> Afair arbeiten beim Radeon-Treiber auch AMD-Angestellte während der
> Arbeitszeit kräftig mit.
sicherlich auch aktiv zensiert zu werden), daß keine
marktwirtschaftlich, competitive relevanten Informationen (=
Betriebsgeheimnisse) in der erstellten Software enthalten oder ableitbar
sind. Ich beneide die nicht um ihren Job.
Aus Wettbewerbsgründen wirst Du in einem OS-Treiber immer nur das
finden, was unter allen konkurrierenden Anbietern sowieso common sense
ist. Egal, wer daran arbeitet.
Fazit:
Im Vergleich zu einem halbwegs ordentlichen closed source Treiber wird
der OS-Treiber immer schlechter sein müssen in einem Wettbewerbsumfeld
wie den Grakas z.B.
Andreas
Patrick Rudin
May 14, 2012, 1:24:42 PM5/14/12
to
Andreas Hartmann wrote:
> Ja. "Arbeiten" heißt an dieser Stelle: Sich selbst so zu zensieren (bzw.
> sicherlich auch aktiv zensiert zu werden), daß keine
> marktwirtschaftlich, competitive relevanten Informationen (=
> Betriebsgeheimnisse) in der erstellten Software enthalten oder ableitbar
> sind. Ich beneide die nicht um ihren Job.
Das ist wohl so.
> Ja. "Arbeiten" heißt an dieser Stelle: Sich selbst so zu zensieren (bzw.
> sicherlich auch aktiv zensiert zu werden), daß keine
> marktwirtschaftlich, competitive relevanten Informationen (=
> Betriebsgeheimnisse) in der erstellten Software enthalten oder ableitbar
> sind. Ich beneide die nicht um ihren Job.
Doof ist das derzeit einfach, weil jetzt ja fglrx 12-5 kommt, und da
laufen nur noch Radeon 5000er oder neuere Karten. Bei nvidia sind die
Legacy-Treiber wegen eines geänderten ABI bei Xorg schon seit Ewigkeiten
aus Wheezy rausgeflogen.
> Aus Wettbewerbsgründen wirst Du in einem OS-Treiber immer nur das
> finden, was unter allen konkurrierenden Anbietern sowieso common sense
> ist. Egal, wer daran arbeitet.
ändert und das ganze streng behütete und geschützte Firmware-Zeugs kein
Hindernis mehr ist.
Gruss
Patrick
k...@familieknaak.de
May 14, 2012, 8:54:05 PM5/14/12
to
Patrick Rudin wrote:
> Bleibt wohl nur die Hoffnung, dass sich irgendwann die Architektur
> ändert und das ganze streng behütete und geschützte Firmware-Zeugs
> kein Hindernis mehr ist.
>
Ich hege lieber die Hoffnung, dass $MANAGER erkennen, wie viel
> Bleibt wohl nur die Hoffnung, dass sich irgendwann die Architektur
> ändert und das ganze streng behütete und geschützte Firmware-Zeugs
> kein Hindernis mehr ist.
>
Mehr-Umsatz sie machen, wenn sie den Open-Source-Kunden die
gleiche Leistung anbieten, wie den anderen. Dass die Offenlegung
einer Schnittstelle automatisch wesentliche Geheiumnisse der
Innereien preisgibt, glauben sie wahrscheinlich ohnehin selber
nicht. Wer diesem Glauben anhängt, der meint auch, dass der
Unterricht in der Fahrschule zur Konstruktuion eines Automobils
befähigt.
---<)kaiamrtin(>---
--
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53
Patrick Rudin
May 15, 2012, 12:12:56 PM5/15/12
to
k...@familieknaak.de wrote:
> Dass die Offenlegung einer Schnittstelle automatisch
> wesentliche Geheiumnisse der Innereien preisgibt,
> glauben sie wahrscheinlich ohnehin selber nicht.
Es geht ja nicht um die Schnittstelle, sondern um den konkreten Code für
> Dass die Offenlegung einer Schnittstelle automatisch
> wesentliche Geheiumnisse der Innereien preisgibt,
> glauben sie wahrscheinlich ohnehin selber nicht.
3D. Aber vermutlich sind Patentprobleme wohl tatsächlich der wichtigere
Grund, weshalb man das Zeugs unter dem Deckel halten will.
Fraglich, was denn wäre, wenn Intel nun auch noch anfangen würde,
richtige(tm) Graphikkarten anzubieten...
Gruss
Patrick
Michael Graf
Jun 5, 2012, 3:20:37 PM6/5/12
to
Hi!
Am 15.05.2012 18:12, schrieb Patrick Rudin:
[...]
> Fraglich, was denn wäre, wenn Intel nun auch noch anfangen würde,
> richtige(tm) Graphikkarten anzubieten...
Das hatten die angeblich sogar vor, aber die Idee dann wohl wieder
begraben...
Gruß
Michael
Am 15.05.2012 18:12, schrieb Patrick Rudin:
[...]
> Fraglich, was denn wäre, wenn Intel nun auch noch anfangen würde,
> richtige(tm) Graphikkarten anzubieten...
begraben...
Gruß
Michael
0 new messages