News Weitere Details zu AMDs „Kabini“ sickern durch

nille02 schrieb:
Die CPU braucht aber auch ein vielfaches der Watt/h wie der Hardware-Decoder.

Bleibt nur die Frage wie gut der Hardware-Decoder ist. Wenn da das Bild nicht gut ist wird das encoding auch schlecht. Dennoch ist die Hilfe, die die GPU bieten kann recht gering. Abgesehen vom lookahead (Wenn man den wert mal etwas anhebt.) ist der Rest eher neben bei erledigt für eine CPU.
Ich hoffe hier ja auf den Nachfolger von h264. h265 soll man deutlich besser über die GPU Decodieren und Encodieren können.

Diese Einwände sind durchaus berechtigt. Es ist natürlich ärgerlich, wenn die CPU-Kerne das Decoding machen müssen. Gerade bei den kleineren APUs reicht die CPU-Leistung dafür auch nur bedingt oder eben gar nicht.

Was die Qualität und Geschwindigkeit von OpenCL-Encoding mit Handbrake angeht, kann ich mich nur auf den schon oben erwähnten AnandTech-Artikel berufen:

http://www.anandtech.com/show/5835/testing-opencl-accelerated-handbrakex264-with-amds-trinity-apu

While video transcoding is significantly slower on Trinity compared to Intel's Sandy Bridge on the traditional x86 path, the OpenCL version of Handbrake narrows the gap considerably. A quad-core Sandy Bridge goes from being 73% faster down to 7% faster than Trinity. Ivy Bridge on the other hand goes from being 2.15x the speed of Trinity to a smaller but still pronounced 29.6% lead. Image quality appeared to be comparable between all OpenCL outputs, although we did get higher bitrate files from the x86 transcode path. The bottom line is that AMD goes from a position of not really competitive, to easily holding its own against similarly priced Intel parts.

Der Treppenwitz ist natürlich, dass jede intel-CPU (oder AMD-CPU) mit zusätzlicher NVidia- bzw. AMD-Graka auch von OpenCL optimierter Software profitieren wird. Dann ist es mit einem "Vorsprung" durch die APU schnell mal vorbei.

In Anlehnung an das bisher von mir Geschriebene zum AMD-Grafik-Treiber, würde ich mir aber auch mehr Engagement von intel in Sachen QuickSync wünschen. Einerseits wird QuickSync sogar unter Windows nur von sehr wenigen Programmen wirklich eingesetzt und unter Linux liegt die QuickSync-Engine ganz brach. Über die unterschiedlichen Qualitäten der Outputs von x86-, QuickSync- und OpenCL-Encoding könnte man wohl auch eine Doktorarbeit verfassen. Irgendwie vergleicht man da auch Äpfel mit Birnen, auch wenn der Output von der Qualität her sehr ähnlich erscheint.
 
2L84H8 schrieb:
In einem anderen Thread habe ich unter ein paar AMD-Fanboys einen veritablen Shitstorm losgetreten, da ich mir angemasst habe, die AMD-Treiber im Generellen und speziell eben auch unter Linux zu kritisieren. Bei AMD-Fanboys ist konstruktive Kritik häufig nicht erwünscht.

Wenn du schon von Fanboys redest, kann ich mir vorstellen wie konstruktiv die Kritik war. Letztlich wird aber meist nur beklagt, dass der Support für neue Kernel und X-Server Versionen viel zu lange braucht. AMD macht es sich hier leider zu einfach indem sie sagen, dass sie nur Distributionen unterstützen und keine Komponenten für sich.

2L84H8 schrieb:
Es zählen eben nicht immer nur "harte" Fakten (=>HW), sondern auch die "weichen" Faktoren (=>SW).

So ist es. Die Treiber von AMD und Nvidia finde ich aber etwa gleich gut/schlecht. Bei AMD gibt es aber leider kaum Support für Entwickler und das schon seit Jahren. Daher ist es kaum verwunderlich das viele Firmen und Studios meist mit Nvidia zusammenarbeiten.
 
Zuletzt bearbeitet:
2L84H8 schrieb:
n einem anderen Thread habe ich unter ein paar AMD-Fanboys einen veritablen Shitstorm losgetreten, da ich mir angemasst habe, die AMD-Treiber im Generellen und speziell eben auch unter Linux zu kritisieren.
du hast auch extrem übertrieben.
Ergänzung ()

2L84H8 schrieb:
Ich kann mich auch noch gut an Matrox erinnern. Die waren mal (unter Windows) für einen sehr guten Treiber und exzellenten Support bekannt. Zeitweise gab es auch einen recht guten Open-Source-Treiber für Linux. Damals hat manch einer auch über die Hardware-Leistung hinweggeschaut, weil der Treiber eben einfach top war. Das ist aber schon lange Geschichte und Matrox ist völlig in der Bedeutungslosigkeit verschwunden. Nicht nur wegen der überhaupt nicht mehr konkurrenzfähigen Hardware, sondern auch, weil der Treibersupport mittlerweile schon fast legendär MIES ist.

Es zählen eben nicht immer nur "harte" Fakten (=>HW), sondern auch die "weichen" Faktoren (=>SW).
und matrox hat noch immer top treiber.
du kannst nur alles grundlos schlecht reden ohne damit erfahrung zu haben?
 
2L84H8 schrieb:
Der Treppenwitz ist natürlich, dass jede intel-CPU (oder AMD-CPU) mit zusätzlicher NVidia- bzw. AMD-Graka auch von OpenCL optimierter Software profitieren wird. Dann ist es mit einem "Vorsprung" durch die APU schnell mal vorbei.
Die GPU kann nur bis zu einem gewissen Grad die CPU unterstützen. Ab einer Gewissen CPU/GPU Leistung wird das Offloading auf die GPU nichts mehr bringen. Das Decoding etc wird ja vom ASIC gemacht und es bleibt nur noch das lookahead. Zur Qualität wird leider eben nicht wirklich drauf eingegangen, nur das sie unter allen OpenCL Ausgaben vergleichbar waren. Das der CPU Output eine höhere Bitrate hat wird schon für sich sprechen ...

2L84H8 schrieb:
In Anlehnung an das bisher von mir Geschriebene zum AMD-Grafik-Treiber, würde ich mir aber auch mehr Engagement von intel in Sachen QuickSync wünschen. Einerseits wird QuickSync sogar unter Windows nur von sehr wenigen Programmen wirklich eingesetzt und unter Linux liegt die QuickSync-Engine ganz brach.

Soll wohl daran liegen, dass die API kaum Möglichkeiten zu den Einstellungen überlässt. Aber wegen Linux, kann die VA-API nicht auch encoding machen? Zumindest wird das immer als der Vorteil genannt wenn es mal wieder Diskussionen zu VA-API und VDPAU gibt.
Ergänzung ()

Elkinator schrieb:
und matrox hat noch immer top treiber.
du kannst nur alles grundlos schlecht reden ohne damit erfahrung zu haben?

Die Zeiten liegen doch auch schon sehr lange zurück. In den letzten 10 Jahren habe ich nichts gutes mehr gehört wenn es um Matrox und GPU ging.
 
Zuletzt bearbeitet:
Paradox.13te schrieb:
Um AVX zu bekommen langt sogar schon ein i3 Sandy Bridge.
Langt schon is arg übertrieben. Kabini ist der direkte Konkurrent zu den Atoms, dann kommt noch celeron und pentium zwischen atom und i3...
Man kann kann hier zweifelsohne sagen: Amd bietet hier die dicken Features für kleines Geld und ist Intel mal wieder klar im Atom/Brazos/Kabini Segment überlegen.
 
Elkinator schrieb:
du hast auch extrem übertrieben.
Ergänzung ()

und matrox hat noch immer top treiber.
du kannst nur alles grundlos schlecht reden ohne damit erfahrung zu haben?

Wenn in dem besagten Thread jemand übertrieben hat, dann wohl eine ganze Reihe von anderen Leuten. Der Tonfall im Thread war auch ohne mich (nach meinem letzten Post) sehr gehässig und alles andere als konstruktiv. Von gewissen Postern in diesem Thread habe ich mir auch noch ein paar andere Beiträge in anderen Threads angesehen und auch dort häufig die gleiche Gehässigkeit angetroffen. Dass ich dann das Wort "Fanboy" in den Mund nehme, kommt dann auch nicht von ungefähr. Es ist auch bezeichnend, dass gewisse der Thread-Teilnehmer in gleicher Rudelformation in anderen Threads auch auf anderen Leuten rumgehackt haben. Ich habe es über die Suchfunktion zu den jeweiligen CB-Usern sehr einfach nachvollziehen können. Gewisse von diesen CB-Usern (aber nicht alle) waren auch fast nur in derartigen Threads aktiv.

Man kann hier übrigens alles nachlesen:
https://www.computerbase.de/forum/threads/amds-neue-a-6000-serie-kuendigt-sich-an.1153895/


Ich habe übrigens durchaus meine Erfahrungen mit Matrox-Grafik gemacht. Matrox ist leider nicht mehr das, was es einmal war. Zur Zeit gibt es auch nur noch Produkte für absolute Nischenmärkte. Und ganz offen gesagt, finde ich auch den AMD-Treiber um ein Vielfaches besser als den von Matrox.
 
der neue atom soll angeblich auch AVX bekommen
Ergänzung ()

was soll den an dem matrox treibern schlecht sein?
das die karten nicht für spiele geeignet sind hat ja damit nichts zu tun.
 
nille02 schrieb:
Die GPU kann nur bis zu einem gewissen Grad die CPU unterstützen. Ab einer Gewissen CPU/GPU Leistung wird das Offloading auf die GPU nichts mehr bringen. Das Decoding etc wird ja vom ASIC gemacht und es bleibt nur noch das lookahead. Zur Qualität wird leider eben nicht wirklich drauf eingegangen, nur das sie unter allen OpenCL Ausgaben vergleichbar waren. Das der CPU Output eine höhere Bitrate hat wird schon für sich sprechen ...

Soll wohl daran liegen, dass die API kaum Möglichkeiten zu den Einstellungen überlässt. Aber wegen Linux, kann die VA-API nicht auch encoding machen? Zumindest wird das immer als der Vorteil genannt wenn es mal wieder Diskussionen zu VA-API und VDPAU gibt.

Schon wieder zwei sehr gute Einwände. :D

Vermutlich ist es noch offen, wo den der heilige Gral der Programmierung bzw. der Vorteile von CPU- vs. GPU-Computing liegt.

Was VA-API und VDPAU angeht, muss ich jetzt leider passen. Da kenne ich mich nicht im Detail aus. Die Frage ist aber schon mal sehr interessant. Vielleicht kann da sonst noch jemand was dazu beitragen.
 
Der Treppenwitz ist natürlich, dass jede intel-CPU (oder AMD-CPU) mit zusätzlicher NVidia- bzw. AMD-Graka auch von OpenCL optimierter Software profitieren wird. Dann ist es mit einem "Vorsprung" durch die APU schnell mal vorbei.
Erm nein ? weil eben die APU alles sofort berechnen kann ohne ständig Daten vom CPU zum GPU Speicher und zurück kopieren zu müssen und die CPU bei einigen Aufgaben schnell mal eingreifen kann, wenn diese die Aufgabe schneller erledigen kann.
Somit muss nicht ständig so lange gewartet werden.

Damit man es nicht gleichsetzt, aber HSA ist nicht CPU + gpgpu !
http://www.tomshardware.com/reviews/fusion-hsa-opencl-history,3262-9.html
Lines-of-Code-and-Performance.jpg

Eisenfaust
jup bin auch gespannt ob die ganze Plattform wirklich nicht mehr als 25 watt tdp beim topmodell verbraucht.

Es wird langsam zeit dass man diese Boards mit den neuen Kabini x4 Chips updatet.
http://geizhals.at/?cat=mbson&xf=1123_AMD+E-450~1123_AMD+E-350~1123_AMD+E-240~1123_AMD+C-60#xf_top

http://geizhals.at/617294
http://www.tomshardware.de/e-350-Mainboard-Vergleichstest-brazos-Fusion,testberichte-240818-16.html
image017.png
(Verbrauch der gesamten Plattform
 

Anhänge

  • amd-fusion,5-7-347515-3.jpg
    amd-fusion,5-7-347515-3.jpg
    36,1 KB · Aufrufe: 455
Zuletzt bearbeitet:
2L84H8 schrieb:
Der Treppenwitz ist natürlich, dass jede intel-CPU (oder AMD-CPU) mit zusätzlicher NVidia- bzw. AMD-Graka auch von OpenCL optimierter Software profitieren wird. Dann ist es mit einem "Vorsprung" durch die APU schnell mal vorbei.
es gibt aber leute die einfach keine extra grafikkarte brauchen.
warum sollte man für einen office pc eine cpu + gpu kaufen wenn man dadurch nur mehr strom braucht ohne das man einen nutzen hat?

geschwindigkeit bringt keinen vorteil wenn man sie nicht braucht.
 
SSE4 bekommt er ziemlich sicher.
videobeschleunigung auch, er bekommt die gpu vom haswell mit 4 EUs.
Ergänzung ()

die jaguar kerne unterstützen auch AES, das einzige was fehlt ist die FMAC fähigkeit der fpu
 
News schrieb:
Bei den TDP-Einstufungen gibt es noch keine klare Aussage, Fudzilla selbst stellt die Vermutungen an, dass die beiden Dual-Core-Varianten unter 15 Watt agieren, der X4-4410 bei exakt 15 Watt agiert und das Topmodell X4-5110 mit 18 Watt spezifiziert wird.
Witzig wie hier immer spektakuliere Sachen von AMD runtergespielt wird, indem man sie nebenbei erwähnt.
Einen Kabini in 18 statt 25W-TDP zu bringen wäre eine verdammte Überraschung, weil es a) von offiziellen Aussagen (siehe Folie) abweicht und b) eine große Verbesserung von früheren Aussagen darstellt.
Einen ca. 30% geringeren TDP, was im Notebook-Bereich meistens 30% geringeren Last-Verbrauch darstellt, wäre eine große Verbesserung, wenn wenn wenn die Takte gleich wären.
Und solbst weniger Takt als früher geplant, muss auch nicht gleich <2,0 Ghz bedeuten.
Genauere Informationen zu den Taktraten liegen in allen Fällen noch nicht vor, was dem vermuteten Starttermin geschuldet sein dürfte, der frühestens im Juni 2013 liegen soll. Folglich fällt die Einordnung der neuen Modelle derzeit entsprechend schwer, lediglich die Aussagen eines AMD-Mitarbeiters von der Hot-Chips-Konferenz aus dem August 2012, die von etwa zehn Prozent Leistungszuwachs über den Takt sprechen, stehen derzeit wieder als „neue Meldung“ im Raum. Dabei bezieht man sich jedoch auf einen hypothetischen „Bobcat“, der ebenfalls in 28 nm gefertigt würde – diese gibt es jedoch nur in 40-nm-Fertigung.

Schließlich sagt man ja, dass Kabini +10% mehr Takt gegenüber eines nichtveröffentlichen 28nm-Bobcat zulegen wird/könnte, der aber ebenfalls 10% gegenüber einen 40nm-Bobcat (1,7 Ghz) schneller sein kann.
Das würde schon einen 2,0+ Ghz-Kabini bedeuten.

Masko schrieb:
egal wie gut die neune APUs werden, die Blaue Fraktion wird wieder jammer wie sch**** die APU ist.
So ist es.
Eigentlich kann keine CPU/MCP/SoC an Kabini ranreichen.
Denn während ein 17W-Hasswell nur eine MCP ist und keine SoC, sind die Tablet-ARM-Konkurrente in der iGPU ein x-faches schlechter. Schließlich könnte ein SoC mehr Stromspartechniken umsetzen als ein MCP, während im Tablet-Markt AFAIK die Konkurrenz noch immer nicht DX11 und schon garnicht DX11.1 hat.

Falls Kabini 2,0-Ghz-Quad-18W-HSA-SoC dahertanzen würde, dann wäre das jetzt viel Interessanter als Bobcat damals weil dieser dann auch im Low-End-Notebook/Desktop ernsthaft konkurrieren könnte. Unmöglich ist das nicht, da die Bobcat-Kerne @ 40nm mit je 5mm² nur noch ein kleiner Teil des 75mm² Dies ausmachen und somit mehr Verbesserungen/Vergrößerungen (als nur die CPU-Kerne) durch Fertigungs-Verbesserungen möglich sind.

Interessant, dass man nach AVX, AES, DX11.1, HSA, SoC und jetzt 18W-TDP immer noch neue spektakuläre Informationen über Kabini hört. Jetzt kann man gespannt sein, ob sie die 18W-TDP wirklich bestätigen und ob uns AMD mit einem 2,0 Ghz-Kabini sowie einer 2. CU (128-SP) überrascht.


Mr.Kaijudo schrieb:
4x1,8Ghz + 15% mehr IPC macht sich da AMD nicht selber Konkurrenz?
Ich wüsste nicht, warum das bei AMD ein Problem sein muss, während Intel da immer einige unterschiedliche Dies macht, die sich da meistens in großen Teilen vollständig konkurrieren. Und das wird bei Intel viel unproblematischer gesehen.
Hingegen zu Intels selbstkonkurrierende Dies könnte Kabini nicht im >18/25W-Bereich gegen Kaveri/Richland konkurrieren, weil Kabini mit dem TDP-Bereich nicht weiter raufgehen kann. Also, im 35W-TPD-Notebook-Bereich sowie 45/65/95-W-TDP-Bereich könnte Kabini nie konnkurrieren, da Kabini nicht weiter über 20W bzw. 2.0 Ghz gehen kann.

Im 17W-Markt könnte Kabini & Kaveri/Richland sehrwohl parallel existieren, wo der eine mit mehr Performance teurer verkauft wird und der andere mit weniger Performance billiger.
 
Elkinator schrieb:
es gibt aber leute die einfach keine extra grafikkarte brauchen.
warum sollte man für einen office pc eine cpu + gpu kaufen wenn man dadurch nur mehr strom braucht ohne das man einen nutzen hat?

geschwindigkeit bringt keinen vorteil wenn man sie nicht braucht.

Das ist mir bewusst. Ich wollte damit nur aussagen, dass es für OpenCL eben bereits auch leistungsfähigere Alternativen in Form von Grakas gibt. AMD möchte mit den Trinitys und OpenCL-Software zu den intel-CPUs aufschliessen. Das geht im Prinzip. Nur läuft OpenCL halt nicht nur auf den APUs sondern auch auf anderer Grafikhardware.

pipip schrieb:
Erm nein ? weil eben die APU alles sofort berechnen kann ohne ständig Daten vom CPU zum GPU Speicher und zurück kopieren zu müssen und die CPU bei einigen Aufgaben schnell mal eingreifen kann, wenn diese die Aufgabe schneller erledigen kann.
Somit muss nicht ständig so lange gewartet werden.

Damit man es nicht gleichsetzt, aber HSA ist nicht CPU + gpgpu !
http://www.tomshardware.com/reviews/fusion-hsa-opencl-history,3262-9.html
Anhang anzeigen 312984

Tatsache ist doch, dass die leistungsfähigsten OpenCL-Lösungen momentan auf den grossen Grakas bzw. den speziell dafür gebauten Steckkarten (ohne Schnittstellen für Displays) laufen. OpenCL-Software ist es so ziemlich egal, wo sie drauf läuft. Daneben sieht eine APU (leistungsmässig) im Moment SEHR mickrig aus. OpenCL ist eben OPEN und nicht auf irgendwelche Hardware bzw. Hersteller beschränkt. CUDA war die erste Implementierung des GPGPU-Konzepts (zumindest das erste, welches Verbreitung gefunden hatte) und lief/läuft halt nur auf NVidia-Hardware. Deshalb ja auch die Entwicklung von OpenCL als gemeinsamen Standard für alle Hersteller.

Klar ist CPU+GPGPU nicht gleich HSA. Und von HSA habe ich auch nirgends geredet. AMD ist ja mit der HSA noch gar nicht an dem Punkt, wo sie mal sein wollen (sprich der totalen Verschmelzung von CPU+GPU). Trinity ist einfach der aktuellste Zwischenstand und bereits einen Schritt weiter als Llano. Auf HSA kann man ja eben auch OpenCL-Software laufen lassen. Es ging mir schlicht um die OpenCL-Leistung der APUs, genauer noch im Zusammenhang mit Handbrake.

http://de.wikipedia.org/wiki/Heterogeneous_System_Architecture

HSA wird sicher interessant. Trinity ist aber nur ein Schritt auf dem Weg dorthin.

Was mich speziell and HSA interessiert ist die HSA-Programmierung mit C++. Setzt das im Moment schon jemand ein? Ist solcher Code dann nur auf HSA lauffähig? OpenCL-Software sollte auf jeder Hardware laufen, welche OpenCL unterstützt.
 
aylano schrieb:
Eigentlich kann keine CPU/MCP/SoC an Kabini ranreichen.
Denn während ein 17W-Hasswell nur eine MCP ist und keine SoC, sind die Tablet-ARM-Konkurrente in der iGPU ein x-faches schlechter. Schließlich könnte ein SoC mehr Stromspartechniken umsetzen als ein MCP, während im Tablet-Markt AFAIK die Konkurrenz noch immer nicht DX11 und schon garnicht DX11.1 hat.
Der Vergleich mit den 15W-Haswells zieht allerdings nur bedingt, da selbst ein Quad-Core-Kabini auf 2,0 GHz in der CPU-Performance völlig chancenlos gegen einen Dual-Core (oder im Zweifelfall gar Single-Core) Haswell sein wird.
 
ein quadcore kabini muß nicht zwangsweise langsamer als ein dualcore haswell sein, kommt ddrauf an wie hoch intel den haswell bei 15W TDP takten kann..
 
Elkinator schrieb:
die behauptung stimmt ja auch, oder hat amd beim K7 damals als intel leistungsmässig sehr weit hinten nach war funktionen beschnitten?
Intel war zu K7 Zeiten weit hinten? Das war nen Kopf an Kopf Rennen wo mal der eine und mal der andere vorne lag. Weit hinten traf auf K8 vs. P4 zu.

pipip schrieb:
Klingt mir etwas zu schwach für die größte Ausbaustufe. Wobei man wird wohl auch die Anbindung (Speichercontroller) nicht übertreiben, damit die DIE nicht zu groß wird.
Hab bisher auch gedacht, dass nen 128 bit Speicherinterface hinderlich ist um nen kleinen Die zu fertigen. Aber der Valleyview bekommt es, selbst in der Tablet Version. Ich bin gespannt wie sich das auswirken wird. Der Kabini hätte es aufgrund der stärkeren GPU eigentlich nötiger.

Wenn man also den Takt hochansetzen kann aber, könnte man trotzdem eine HD 4000 erreichen, sogar eventuell mehr :) Ab der 7600 G ist man schneller als eine HD 4000.
Naja ich denke nciht dass man die GPU so fett macht, gerade in Hinblick auf die Speicherbandbreite. Im Trinitytest sieht man ja wie stark die Leistung schon vom Speichertakt abhängt, und das bei 128 bit Busbreite.

Aber für die HD4000 dürften ja schon 128 SP reichen, in dem Bereich wird man wohl irgendwo landen. Fragezeichen evtl. beim Speicher.


sacridex schrieb:
Langt schon is arg übertrieben. Kabini ist der direkte Konkurrent zu den Atoms, dann kommt noch celeron und pentium zwischen atom und i3...
Man kann kann hier zweifelsohne sagen: Amd bietet hier die dicken Features für kleines Geld und ist Intel mal wieder klar im Atom/Brazos/Kabini Segment überlegen.
Naja das ist aber schon einseitig betrachtet. Noch bieten sie gar nichts, denn der Kabini ist noch gar nicht da.
Anfang des Jahres bot AMD mit Brazos/Llano nicht mal ne SSE4.1, AES oder AVX. Was Intel seit nem Jahr oder noch länger unterstützte.
Bis Kabini da ist, stehen vielleicht schon die neuen Atom oder Haswell i3/Pentium vor der Tür, wer weiss was die bieten.

Sicher kastriert Intel die CPUs bei den Features ziemlich stark und fängt da mit den i3 schon relativ weit oben an. Das sollte man nicht schön reden. Aber man sollte das etwas objektiver sehen und nicht alte Produkte mit noch kommenden Vergleichen. Geht ja sogar so weit, dass Manche der Meinung sind nur der i7 würde AVX bieten.
 
Zuletzt bearbeitet:
Elkinator schrieb:
ein quadcore kabini muß nicht zwangsweise langsamer als ein dualcore haswell sein, kommt ddrauf an wie hoch intel den haswell bei 15W TDP takten kann..
1,5 GHz Basis-Takt sollten reichen und der Single-Core-Turbo bis 2,5 GHz macht dann den Rest.
 
bei anwendungen die alle 4 kerne auslasten würde es mich trotzdem wundern wenn der kabini nicht vorne liegt oder mindestens gleichwertig ist.

wenn der kabini 4x 2ghz erreichen wird.
 
Zurück
Oben