News Intel MKL: Matlab R2020a beinhaltet offiziellen AMD-Workaround

@gaelic
Ja, das ist schon klar. Ich meinte den im Zitat angesprochenen Fall, dass Intel die MKL komplett zu anderen Herstellern inkompatibel macht. Sprich MKL würde nur und ausschließlich auf Intel laufen. Ich sehe darin kein rechtliches Problem.

Das derzeit (ohne Hack) die MKL auf Via und AMD nur SSE und kein AVX aktiviert ist klar.
 
Es hat sehr viel mit der Lizenz zu tun.
Etwas unter Lizenz zu bauen, bedeutet, dass du den gleichen Standard wie der Konkurrent dem Kunden zur Verfügung stellst und zwar anhand einer Vereinbarung mit dem Konkurrenten.

Wo würden wir denn heute stehen wenn alle nach Intel's Prinzip agieren würden?

Du würdest auf den Flugticket-Portalen business Tickets kaufen, die beim Boarding plötzlich als economy umplatziert werden.
usw.
 
  • Gefällt mir
Reaktionen: s0UL1, denglisch, Volkimann und eine weitere Person
biohaufen schrieb:
So eine millionenschwere Software gibt es btw. auch von AMD.
Sie wird nur eben nicht in führenden Produkten eingesetzt...
https://developer.amd.com/amd-aocl/amd-math-library-libm/
Auch zusätzlich die ACML

Ist schon interessant zu sehen wie verblendet der ein oder andere ist :)

Dir ist schon klar, dass es nicht um die Existenz der Software geht, sondern darum, dass Intel hier absichtlich AMD ans Bein pisst? Intel suggeriert, dass ihre Library auch auf AMD Produkten laeuft, "vergessen" aber zu erwaehnen, dass sie Befehlssaetze der letzten 2 Jahrzehnte nicht nutzen wenn AMD entdeckt wurde.

gaelic schrieb:
Ich kann mich deiner Meinung anschließen. Obwohl es natürlich "nicht nett" von Intel ist.
Die Vorgehensweise ist ja folgende:
Code:
if "Intel"+"CPUgen": CPU Featurenutzung -> schnell
else: Fallback -> langsam
und nicht:
Code:
if "AMD": Fallback -> langsam
else: CPU Featurenutzung -> schnell

Fall 2 wäre klare Benachteiligung
Fall 1 hingegen ist einfach das linksliegenlassen der Konkurrenz

edit: auf jeden Fall gut daß hier Matlab mal vorangeht.

Beide deine Beispiele machen keinen Sinn. Es gibt standardisierte Features und deren Abfrage. Das einzige was Sinn machen wuerde ist erst die Featureabfrage zu nutzen, und dann, falls Intel, zusaetzliche Optimierungen zu laden. Damit haette keiner Probleme, aber so wie sie es jetzt machen warten sie nur darauf wieder eins auf die Finger zu bekommen. Standardisierte Features bei der Konkurrenz nicht zu nutzen obwohl sie da sind ist schlichtweg Manipulation. Gerade in dem Zusammenhang da sie ja den Eindruck erwecken wollen, dass sie auf allen x86_64 Systemen optimal laufen.

Tzk schrieb:
Der Witz daran ist eigentlich das es auf exakt das gleiche Ergebnis hinausläuft. Würde man das ordentlich machen wollen, dann wäre z.B. sowas denkbar:

Code:
if "Vendor ID = Intel": CPU Featurenutzung + spezielle optimierungen -> extra schnell
else: check CPU Featurelevel -> schnell

und alle wären glücklich. Also alle außer Intel... :D

Das waere auch der einzige rechtssichere Weg und in der Tat koennte sich niemand beschweren. Aber genau das tut Intel eben nicht.

Tzk schrieb:
Ne... @ZeroStrat ist die Problematik wohlbewusst. Er vertritt hier einfach nur ne unpopuläre Meinung. zu den Gründen musste ihn aber selbst fragen.

Da habe ich grosse Zweifel, da er explizit von Optimierungen fuer AMD spricht. Die hat niemand gefordert, das einzige was man fordert ist das existierende Featureset zu nutzen und nicht aufgrund der Vendor ID alle Features der letzten 2 Jahrzehnte zu ignorieren. Da er sich aber auf Optimierungen versteift hat er es entweder nicht verstanden, will es nicht verstehen, oder ist zu bloed es zu verstehen. Ich tippe auf zweiteres.

Tzk schrieb:
Wo soll das illegal sein? Wenn Intel klar kommuniziert das die MKL nur auf Intel läuft (sprich schmeisst einen Fehler wenns keine Intel Cpu ist), dann sehe ich dabei kein Problem. Wenn man die Mitbewerber aktiv bremst, dann ist das ein Problem. Wobei die MKL eher ne passive denn aktive Bremse ist und deshalb zwar unschön ist, aber vermutlich nicht illegal.

MKL funktioniert aber auf AMD, da kommt kein Fehler. Wenn ein Fehler kommt, kein Ding, passt. Aber das will Intel ja gar nicht. Die wollen suggerieren, dass es bei allen Herstellern funktioniert, aber Intel so viel besser ist. Dass das ganze auf ziemlich simpler Manipulation aufbaut, geschenkt. Vor allem, selbst wenn sie verurteilt werden, dann werden die Strafzahlungen Peanuts sein gegenueber dem was Intel damit gewonnen hat.
 
  • Gefällt mir
Reaktionen: Asmudeus, s0UL1, denglisch und eine weitere Person
Kacha schrieb:
Beide deine Beispiele machen keinen Sinn. Es gibt standardisierte Features und deren Abfrage.
Das einzige was Sinn machen wuerde ist erst die Featureabfrage zu nutzen, und dann, falls Intel, zusaetzliche Optimierungen zu laden.
Macht Intel aber nicht. Ist das lieb und nett von Intel: nein. Es ist deren Software und niemand muss sie verwenden.

Ich auch nicht auf dem Threadripper nei mir hier, leider ist die mkl noch immer wesentlich schneller als openblas.
Ergänzung ()

Argoth schrieb:
Du würdest auf den Flugticket-Portalen business Tickets kaufen, die beim Boarding plötzlich als economy umplatziert werden.
:confused_alt:

Kannst du bitte einen Autovergleich machen.
 
Kacha schrieb:
Dir ist schon klar, dass es nicht um die Existenz der Software geht, sondern darum, dass Intel hier absichtlich AMD ans Bein pisst? Intel suggeriert, dass ihre Library auch auf AMD Produkten laeuft, "vergessen" aber zu erwaehnen, dass sie Befehlssaetze der letzten 2 Jahrzehnte nicht nutzen wenn AMD entdeckt wurde..

Lies mal im Kontext, dann wird genau klar, das ich das indirekt damit ausdrücken wollte, ohne Beleidigend zu werden ;D
ProTipp: der Begriff millionenschwer sollte das ironische im Bezug auf die vorherige Diskussion suggerieren ;)
 
  • Gefällt mir
Reaktionen: .Sentinel.
Kacha schrieb:
Intel suggeriert, dass ihre Library auch auf AMD Produkten laeuft, "vergessen" aber zu erwaehnen, dass sie Befehlssaetze der letzten 2 Jahrzehnte nicht nutzen wenn AMD entdeckt wurde.

Das stimmt nicht, es wird sowohl auf der Produktseite von Intel als auch bei der Installation der MKL direkt darauf hingewiesen, dass die Bibliothek nur Intel-CPUs unterstüzt und auch nur bestimmte Generationen. Und es gibt kein "AMD entdeckt", weil es schlicht eine Rückfalloption gibt für alle nicht unterstützten CPUs.

Aber darum ging es hierbei ohnehin niemals... ich sehe es noch wie damals: das Problem liegt bei Matlab bei Mathworks, nicht bei Intel... denn die müssen bei ihrer Software das passende Backend je nach CPU auswählen.

Mir als Kunde ist es egal, was Matlab für Bibliotheken verwendet... wenn angegeben ist, dass AMD unterstützt wird, dann erwarte ich auch, dass dem tatsächlich so ist.

Und Bibliotheken wie NumPy sind etwas ganz anderes... da kann ich selbst entscheiden, was für eine Bibliothek ich verwende... oder nehme je nach Problem einfach CuPy (die CUDA Variante), oder sonst etwas. Aber hier regen sich ohnehin nur Leute auf, die das alles nicht betrifft.

Davon abgesehen wäre es schön, wenn AMD in dieser Richtung mehr Support bietet, nicht nur bei CPUs.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: .Sentinel. und bad_sign
calluna schrieb:
Und es gibt kein "AMD entdeckt", weil es schlicht eine Rückfalloption gibt für alle nicht unterstützten CPUs.

Ohne den Rest deines Posts jetzt bewerten zu wollen, da gibt es einfach unterschiedliche Meinungen zu und die sind auch alle legitim. Aber das zitierte oben ist so nicht ganz 100% korrekt, denn es gibt nunmal eine Vendor ID Abfrage und diese alleine bestimmt über den "Fallback" auf SSE. Wenn da nicht GenuineIntel als Antwort kommt ist es eben egal was das Feature Set der CPU bietet. Wenn GenuineIntel als Antwort kommt, und nur dann, gibt es eine Feature Set Abfrage und keinen "SSE Fallback". Und da das nicht gerade gängige Praxis ist und auch in keinem Programmers Guide so empfohlen wird muss sich Intel da eben Fragen gefallen lassen. Und das ist ebenfalls legitim.
 
  • Gefällt mir
Reaktionen: Asmudeus, Tzk und Smartbomb
gaelic schrieb:
Macht Intel aber nicht. Ist das lieb und nett von Intel: nein. Es ist deren Software und niemand muss sie verwenden.

Damit sind sie rechtlich aber eben auf ziemlich duennem Eis.

biohaufen schrieb:
Lies mal im Kontext, dann wird genau klar, das ich das indirekt damit ausdrücken wollte, ohne Beleidigend zu werden ;D
ProTipp: der Begriff millionenschwer sollte das ironische im Bezug auf die vorherige Diskussion suggerieren ;)

Das war nicht ganz klar, selbst im Kontext. Ironie klappt nicht immer in Textform. ;)

calluna schrieb:
Das stimmt nicht, es wird sowohl auf der Produktseite von Intel als auch bei der Installation der MKL direkt darauf hingewiesen, dass die Bilbiothek nur Intel-CPUs unterstüzt und auch nur bestimmte Generationen. Und es gibt kein "AMD entdeckt", weil es schlicht ein Rückfalloption gibt für alle nicht unterstützten CPUs.

Aber darum ging es hierbei ohnehin niemals... wie sehe es noch wie damals: das Problem liegt bei Matlab bei Mathworks, nicht bei Intel... denn die müssen bei ihrer Software das passende Backend je nach CPU auswählen.

Davon abgesehen wäre es schön, wenn AMD in dieser Richtung mehr Support bietet, nicht nur bei CPUs.

Dann ist es ja ganz einfach, wird eine nicht Intel CPU verwendet gibt es eine Fehlermeldung und fertig. Genau das macht Intel aber nicht, weil sie suggerieren wollen, dass es eben doch geht. Es soll auch kein "AMD entdeckt" geben, sondern eine stinknormale Featureabfrage. Das unterlassen sie aber explizit wenn es sich nicht um Intel handelt. Und die Ergebnisse implizieren dann natuerlich, dass Intel viel besser performed.

Das Vorgehen sollte, gerade auch mit Matlab, ziemlich verstaendlich sein. Intel stellt ihre Software so hin, dass sie "offiziell" nur Intel unterstuetzt, aber dennoch mit allen anderen funktioniert um Herstellernwie Mathworks dazu zu bringen nur auf MKL zu setzen und dadurch Aufwand zu sparen. Machen sie das, steht Intel nachher natuerlich besser da und was glaubst du kaufen die Leute dann an Hardware? Genau das gleiche haben sie mit den Deals mit OEMs gemacht, mit deren Compiler, etc. Und sie kommen jedes mal damit durch, ihre Verkaufszahlen zeigen es. Man kann sich jetzt natuerlich hinstellen und sagen, ja aber, ist doch Intels Software und das ganze ignorieren, sollte sich dann aber niemals ueber die ganzen Konsequenzen davon beschweren. Und genau daran hapert es den meisten. Der Zusammenhang ist nicht klar. Gibt auch hier im Forum genug die AMDs Fastpleite komplett auf AMD und Bulldozer schieben ohne darueber nachzudenken, dass vielleicht entgangener Umsatz auf Jahre einen Einfluss haben koennte. Aber hey, die Welt ist einfach.

Zum Support, bietet AMD doch, die haben ihre eigene Library wie @biohaufen vorhin verlinkte. Oder meinst du, die sollen den gleichen Mist wie Intel machen und sich Vorteile zur Not einfach einkaufen? Bitte nicht, darauf kann man verzichten. Deren Weg lieber in Richtung Open Source zu gehen ist mir um einiges lieber.

Edit:

@Ned Flanders Hat eigentlich schon jemand die Vendorabfrage umgangen indem GenuineIntel zurueckgegeben wurde und getestet was dann geht? Denn wenn es dann einfach funktioniert ist es nochmal um einiges problematischer.
 
  • Gefällt mir
Reaktionen: Asmudeus, Smartbomb, jemandanders und eine weitere Person
Kacha schrieb:
Genau das macht Intel aber nicht, weil sie suggerieren wollen, dass es eben doch geht.

Diese Art von Alltagspsychologie, also den anderen Menschen Motive für ihre Handlungen zu unterstellen, funktioniert schon im Alltag nicht besonders gut. Ich glaube, in Bezug auf Firmen funktioniert das noch viel weniger. ;-)

Kacha schrieb:
Intel stellt ihre Software so hin, dass sie "offiziell" nur Intel unterstuetzt, aber dennoch mit allen anderen funktioniert um Herstellernwie Mathworks dazu zu bringen nur auf MKL zu setzen und dadurch Aufwand zu sparen.

Wie Ned Flanders schon schrieb... es gibt da verschiedene legitime Sichtweisen. Für mich ist die MKL Produktpflege, so wie CUDA bei Nvidia.
 
  • Gefällt mir
Reaktionen: .Sentinel.
Kacha schrieb:
@Ned Flanders Hat eigentlich schon jemand die Vendorabfrage umgangen indem GenuineIntel zurueckgegeben wurde und getestet was dann geht? Denn wenn es dann einfach funktioniert ist es nochmal um einiges problematischer.

Wenn man die mkl.dll patcht und die Zeichenfolge der korrekten Antwort der Vendor ID Abfrage von "GenuineIntel" auf "AuthenticAMD" ändert, läuft die MKL auf einem AMD FX mit AVX support, auf einem Ryzen mit AVX2 support und auf jeder Intel CPU im SSE Modus.

calluna schrieb:
Für mich ist die MKL Produktpflege, so wie CUDA bei Nvidia.

Das ist sie auch, mit dem Unterschied das CUDA auf AMD Karten nicht läuft (auch nicht im CUDA 1.0 Mode) und von Nvidia auch nicht mit "runs well on non Nvidia GPUs" beworben wird. Was ich meine, bei CUDA ist sich jeder klar was für eine Entscheidung er eingeht. Bei der MKL nicht wirklich und deswegen galt die MKL auch landläufig jahre lang als "schlecht optimiert" auf AMD CPUs dabei ist sie im grunde "gut pessimiert" wenn du weist was ich meine. Aber wir können uns da wirklich problemlos einigen das wir uns da nicht einig sind. Wie gesagt, beide Sichtweisen sind für mich absolut legitim.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Asmudeus, Tzk, Smartbomb und 7 andere
@Colindo

Ein Verhalten kann moralisch "verwerflich" und dennoch "nachvollziehbar" sein im Sinne von: "Was du getan hast, ist nicht nett, es ist nicht fair, aber aus das Perspektive eines Aktienunternehmens dennoch rational nachvollziehbar und vernünftig."

Oder anders gesagt: Unternehmen sind keine Personen und es gelten nicht die moralischen Regeln aus unserem zwischenmenschlichen Alltag.
 
Mal eine andere Perspektive: Microsoft wurde ja auch nicht umsonst oefters mal wegen Monopolmissbrauch verurteilt. Ging da zwar mehr um Zusatzprogramme, die andere Hersteller vor Einnahmeprobleme stellt und die Wettbewerbsfaehigkeit vermindert. Aber ist durchaus vergleichbar.

In dem Fall ist einfach so, dass man mit dem Thema der Vendor-ID die Wettbewerbsfaehigkeit des kleineren Mitbewerbers minimiert. Ein Monopolist hat und sollte nicht die gleichen Rechte der kleiner Mitbewerber haben, wie am Markt agiert wird. AMD-Prozessoren werden zwar jetzt nicht ausgeschlossen, aber die IT orientiert sich auch an Anwendungspwrformance und somit haette Intel einen fuer mich einen unlauteren Vorteil erzielt, wenn das Featureset kompatibel ist.
 
Zuletzt bearbeitet:
Ned Flanders schrieb:
Wenn man die mkl.dll patcht und die Zeichenfolge der korrekten Antwort der Vendor ID Abfrage von "GenuineIntel" auf "AuthenticAMD" ändert, läuft die MKL auf einem AMD FX mit AVX support, auf einem Ryzen mit AVX2 support und auf jeder Intel CPU im SSE Modus.

LOL :-).

Nur genau diese Abfrage unterbleibt im Falle von "non-Intel", was eindrucksvoll das "patchen" der mkl.dll zeigt.

Tja, das Problem ist eben das allein die Vendor ID ja auch nicht reicht um irgendwas zu optimieren. Dazu frägt die MKL eben die Features sets der Intel CPUs ab. Mit exakt derselben Abfrage könnte man bei allen "kompatibel" zu Intel Konstruierten CPUs somit praktisch genausogut fahren. Wenn Intel hier noch einen speziellen Intel-Voodoo macht können sie das ja noch gerne extra coden durch die Kombination von Genuine Intel + Feature Set. Ich bezweifele jedoch stark daß die MKL irgendeine "Handoptimierung" von Code abseits der simplen Abfrage des Feature sets beinhaltet.

Gibt es eigentlich irgendwo Benchmarks wo man einen Intel mit und ohne "GenuineIntel" testet vs eine AMD CPU mit und ohne.
Dann könnte man ja aus so einem 1:1 Vergleich der "Performance" Verlust sehen ob hier noch ein "Secret Sauce" drin ist der Intel CPUs nochmal einen extra boost gibt.

Also Testfeld:
AMD CPU mit normaler mkl.dll = AMD-100% Performance
AMD CPU mit gepatchted mkl.dll = AMD-Patched%-Performance (relativ zu AMD-100%)
Intel CPU mit normaler mkl.dll = Intel-100% Performance
Intel CPU mit gepatchted mkl.dll = Intel-Patched%-Performance (relativ zu Intel-100%)

Wenn sagen wir AMD hier +100% gewinnt (weil durchs patchen die features frei geschaltet werden) umgekehrt aber die Intel Performance NICHT auf 50% dropped, würde man direkt sehen ob es hier noch zusätzliche Optimierungen gibt :-).
 
  • Gefällt mir
Reaktionen: Asmudeus
Argoth schrieb:
Es hat sehr viel mit der Lizenz zu tun.
Etwas unter Lizenz zu bauen, bedeutet, dass du den gleichen Standard wie der Konkurrent dem Kunden zur Verfügung stellst und zwar anhand einer Vereinbarung mit dem Konkurrenten.

Wo würden wir denn heute stehen wenn alle nach Intel's Prinzip agieren würden?
Vollkommen richtig, Intel und AMD haben ein Patent- und Lizenztausch /-abkommen.

Man stelle sich vor was los wäre wenn zB AMD in den - von Intel lizenzierten - x86-64 Code eine Vendor ID eingebaut und in zB jegliches Microsoft OS hätte einbauen lassen, um dort dann per Vendor ID Check trotz 64 nur 32Bit zuzulassen.

Das ganze Verhalten seitens Intel führt eine Lizenzierung bzw einen Lizenztausch absurdum.
 
  • Gefällt mir
Reaktionen: denglisch und Iscaran
Mal für all jene, welche Intel hier so sehr im Recht sehen:

Die haben 2009 mit AMD eine Vereinbarung getroffen.(Settlement Agreement)
Danach hat sich Intel verpflichtet in seinen Produkten keine Maßnahmen zu ergreifen, welche AMD Produkte benachteiligen.

Link:> http://download.intel.com/pressroom/legal/AMD_settlement_agreement.pdf <

Ich habe da mal eine mMn entscheidende Passage der besseren Lesbarkeit halber, ins Deutsche übersetzt.
Ich fand die deepl Übersetzung des Namens "Intel" ziemlich witzig, deshalb hab ich s mal stehen gelassen. :D
Nomen est Omen ;)
Original:
SETTLEMENT AGREEMENT BETWEEN
ADVANCED MICRO DEVICES INC. AND
INTEL CORPORATION

2.3 TECHNICAL PRACTICES
Intel shall not include any Artificial Performance Impairment in any Intel product or require any Third Party to include an Artificial Performance Impairment in the Third Party's product. As used in this Section 2.3, "Artificial Performance Impairment" means an affirmative engineering or design action by Intel (but not a failure to act) that (i) degrades the performance or operation of a Specified AMD product, (ii) is not a consequence of an Intel Product Benefit and (iii) is made intentionally to degrade the performance or operation of a Specified AMD Product. For purposes of this Section 2.3, "Product Benefit" shall mean any benefit, advantage, or improvement in terms of performance, operation, price, cost, manufacturability, reliability, compatibility, or ability to operate or enhance the operation of another product.
In no circumstances shall this Section 2.3 impose or be construed to impose any obligation on Intel to (i) take any act that would provide a Product Benefit to any AMD or other non-Intel product, either when such AMD or non-Intel product is used alone or in combination with any other product, (ii) optimize any products for Specified AMD Products, or (iii) provide any technical information, documents, or know how to AMD.
Übersetzung:

VERGLEICHSVEREINBARUNG ZWISCHEN
FORTSCHRITTLICHE MIKROGERÄTE INC. UND
GEHEIMDIENST-KORPORATION
[...]
2.3 TECHNISCHE PRAKTIKEN
Intel darf keine künstliche Leistungsbeeinträchtigung in ein Intel Produkt aufnehmen oder von einer Drittpartei verlangen, eine künstliche Leistungsbeeinträchtigung in das Produkt der Drittpartei aufzunehmen. Wie in diesem Abschnitt 2.3 verwendet, bedeutet "künstliche Leistungsbeeinträchtigung" eine positive technische oder konstruktive Maßnahme von Intel (jedoch keine Untätigkeit), die (i) die Leistung oder den Betrieb eines spezifizierten AMD-Produkts verschlechtert, (ii) nicht die Folge eines Produktvorteils von Intel ist und (iii) absichtlich die Leistung oder den Betrieb eines spezifizierten AMD-Produkts verschlechtert. Für die Zwecke dieses Abschnitts 2.3 bedeutet "Produktvorteil" alle Vorteile, Nutzen oder Verbesserungen in Bezug auf Leistung, Betrieb, Preis, Kosten, Herstellbarkeit, Zuverlässigkeit, Kompatibilität oder die Fähigkeit zum Betrieb oder zur Verbesserung des Betriebs eines anderen Produkts.
Dieser Abschnitt 2.3 verpflichtet Intel unter keinen Umständen dazu, (i) eine Handlung vorzunehmen, die einen Produktvorteil für ein AMD oder ein anderes Nicht-Intel-Produkt bietet, entweder wenn dieses AMD oder Nicht-Intel-Produkt allein oder in Kombination mit einem anderen Produkt verwendet wird, (ii) Produkte für bestimmte AMD-Produkte zu optimieren oder (iii) technische Informationen, Dokumente oder Know-how an AMD weiterzugeben.


Jetzt dürft ihr euch alle euren Teil denken.

Ich für meinen Teil meine jedenfalls, das Intel hier klar eine Benachteiligung eingebaut hat.
Sie hätten natürlich für ihre CPUs noch spezielle Optimierungen einbauen können und dürfen, aber alle AMD CPUs einfach auf eine alte SSE Erweiterung beschränken, geht so nicht.
Genau das gleiche Spiel läuft mit deren Compiler.
Die werden sich nie ändern. Das scheint irgendwie in ihrer "Firmen DNA" drin zu sein.
Rein vom Ethischen Standpunkt aus gesehen, ist das in meinen Augen, der letzte Sauhaufen. Dabei hätten sie das eigentlich nicht nötig.
Ich hatte mich mal dem Trugbild hingegeben, sie hätten sich irgendwie geändert.
Aber wie Blöd kann man sein, daran zu glauben?

Edit: Ich lade mal das OCR Ergebnis des Intel PDF noch als txt Datei hier hoch. Dann ist das auch durchsuchbar.
 

Anhänge

Zuletzt bearbeitet: (Ergänzt)
  • Gefällt mir
Reaktionen: Asmudeus, Argoth, Kodak und 8 andere
Zurück
Oben