Diskussion zu: AMD ersetzt Catalyst durch "Radeon Software"

[Leonidas]

Link zur News:
http://www.3dcenter.org/news/amd-ersetzt-catalyst-durch-radeon-software

[OBrian]

man darf aber nicht vergessen, daß Microsoft damals .NET als DEN Standard der Zukunft promotet hat, die Radeontreiber-Macher also davon ausgehen mußten, daß es in den zukünftigen Windows-Versionen praktisch unmöglich ist, ohne .NET auszukommen.

[Ludi]

Auch wenn alle .Net hassen, auf Grund der Tatsache, dass es von Microsoft ist, ist es nicht daran Schuld, dass das alte Control-Center scheiße aussieht und Ewigkeiten zum Starten gebraucht hat. Das haben ganz alleine die Entwickler bei AMD verbockt, und hätten es wohl auch damals mit nativem Code verbockt.

[ottoman]

Das sehe ich ähnlich. Andere .Net Programme haben diese Probleme jedenfalls nicht. Die Schuld würde ich also auch eher bei ATI/AMD vermuten.

[FlashBFE]

Ich frage mich als .NET-Programmierer, warum so darauf herumgehackt wird. Man ersetzt doch nur ein Framework durch ein anderes, was plattformunabhängiger ist.

Die Startzeiten und das m.M.n. unpraktische UI ist doch nicht die Schuld des Frameworks. Es wird auch hier im Artikel impliziert, dass .NET eine allgemeine Performancebremse wäre, was völliger Blödsinn ist. Die könnte man mit QT genauso verbocken.

Anfangs war .NET deshalb unbeliebt, weil man zu XP-Zeiten das nicht gerade leichtgewichtige Framework noch extra herunterladen und installieren musste und ja, natürlich, weil es von Microsoft ist.

[El_Presidente]

ich denke das ist eine konzession an steamos, denn die neue qt oberfläche läßt sich ungleich leichter portieren als .net (auch wenn das ja inzwischen auch langsam open source wird)

[Virtuo]

Die nvidia-Treiber, zumindest das Geforce Experience Center, basieren doch auch auf dem .net-Framework. Die starten jedenfalls deutlich schneller. Aber ich erinnere mich das nvidia anfangs auch Probleme mit der Startgeschwindigkeit hatte. Die haben das dann irgendwann in den Griff bekommen.

[seba86]

Doch, es hängt teilweise DOCH von der Entwicklungs-Umgebung ab... .NET Anwendungen brauchen wie Java-Anwendungen oft erhebliche Wartezeiten beim Starten. Auch MiniApps brauchen beim Starten ein vielfaches an Zeit. Auch wenn simple Einstellungs-Dialoge angezeigt werden, gibt es gerade bei oben genannten Apps beim ersten Laden Denkpausen etc.

Ich habe einige Monate mit .NET (C#) programmiert, bisschen Ahnung habe ich schon.

Delphi + C++ Anwendungen sind dagegen absolut performant..

[sloth9]

Auch wenn alle .Net hassen, auf Grund der Tatsache, dass es von Microsoft ist, ist es nicht daran Schuld, dass das alte Control-Center scheiße aussieht und Ewigkeiten zum Starten gebraucht hat. Das haben ganz alleine die Entwickler bei AMD verbockt, und hätten es wohl auch damals mit nativem Code verbockt.

+1
Das CC war immer ein Grund imho, keine ATi zu kaufen.

[Gast]

@sloth9

Keins Sorge du wirst weiterhin einen Grund finden kein AMD zu kaufen...

Und ja es hängt auch teilweise von .net ab, da auch hier wie bei Java zur Laufzeit kompeliert wird.

[Pirx]

Nö, es war sehr brauchbar, nur ganz am Anfang war es crap.

[samm]

Doch, es hängt teilweise DOCH von der Entwicklungs-Umgebung ab... .NET Anwendungen brauchen wie Java-Anwendungen oft erhebliche Wartezeiten beim Starten. Auch MiniApps brauchen beim Starten ein vielfaches an Zeit. Auch wenn simple Einstellungs-Dialoge angezeigt werden, gibt es gerade bei oben genannten Apps beim ersten Laden Denkpausen etc.

Ich habe einige Monate mit .NET (C#) programmiert, bisschen Ahnung habe ich schon.Arbeite nun schon lange mit .net GUIs in diversen Zusammenhängen, und muss bislang feststellen, dass es nicht GUI Code an sich ist, der lahm ist, sondern wenn etwas lahmt, stammt es von schlecht programmierten Schnittstellen zu externen Daten wie z.B. zu Datenbanken, oder suboptimalen weil allzu abstrahierten Frameworks.

Aber klar finde ich den Schritt weg vom Catalyst GUI (das in letzter Zeit doch deutlich besser bedienbar geworden ist) zu einem neuen begrüssenswert. Und zu Qt sowieso, macht AMDs Entwicklerressourcen frei für andere Dinge als Portieren und Kompatibilitätstests.

Schlecht vom Marketing finde ich aber den Namen. "Radeon Software Crimson YY.MM"? Wenn Crimson schon den Jahrgang impliziert, würde z.B. "Radeon Crimson MM" genügend genau sein, so ist das wieder genauso dämlich wie die Präfixe bei den Radeon Grafikkarten: Weshalb muss da noch "R9" stehen, wenn nachher "290" schon Generation und Level angibt? Und weshalb braucht es noch ein Suffix X für die vollen Varianten?

[seba86]

suboptimalen weil allzu abstrahierten Frameworks
Ja, es ist ähnlich wie bei Java die Echtzeit-Kompilierung während des Betriebes...

Ansonsten ist mir gleich, auf was der Treiber aufsetzt/benannt oder wie die Karten heißen etc. Stabil laufen tuts ja. Bin aber nicht mehr so der ProGamer...

[Kickstart]

Ich verstehe nicht wirklich wieso hier ausschließlich über vergangenes bzw. über .net diskutiert wird. Was nützt es über eine lang zurückliegende Entscheidung zu diskutieren die AMD in Bälde revidieren wird?
Ich für meinen Teil bin positiv überrascht und freue mich darauf die neue Software ausprobieren zu können.
Den das CCC und insbesondere die Raptr Software halte ich von der Benutzerführung bzw. Bedienbarkeit her für eine absolute Katastrophe. Ich bin froh das sich da etwas tut.

[FlashBFE]

Ich verstehe nicht wirklich wieso hier ausschließlich über vergangenes bzw. über .net diskutiert wird. Was nützt es über eine lang zurückliegende Entscheidung zu diskutieren die AMD in Bälde revidieren wird?
Ich für meinen Teil bin positiv überrascht und freue mich darauf die neue Software ausprobieren zu können.
Den das CCC und insbesondere die Raptr Software halte ich von der Benutzerführung bzw. Bedienbarkeit her für eine absolute Katastrophe. Ich bin froh das sich da etwas tut.
Dann lies den Artikel noch mal:
Markanter Punkt ist dabei das neue Control-Panel, welches durch den Verzicht auf .NET nunmehr deutlich schneller starten soll. Damit hat AMD schon nach nur elf Jahren endlich begriffen, daß jenes .NET zumindest für diesen Anwendungszweck ein Fehlgriff war – nicht, daß man dies nicht bereits anno 2004 zum Start des ersten Catalyst-Treibers mit .NET-Zwang mittels der Nutzer- und Presserückmeldungen hätte wissen können. Leicht irritierend auch, daß .NET nunmehr auf den PCs des Jahres 2015 als ein Performanceproblem angesehen wird, auf den PCs des Jahres 2004 dieses vom seinerzeitigen Unternehmen ATI jedoch nicht so gesehen wurde.
Zusammenfassung: .NET ist an Allem Schuld und war es schon immer. Dabei habe ich nicht mal in AMDs Folien ein Zusammenhang zwischen Performance und dem Hinweis auf den Frameworkwechsel gefunden.

Aber egal des Frameworks freue ich mich auch über die neue Oberfläche. Im Endeffekt zählt, was die Programmierer draus machen.