Beiträge von ironman

    Das Eurosport FTA ist hängt mit der Übertragung der Olympischen Winterspiele zusammen, hier eine Meldung über freenetTV (DVB-T2):

    http://www.digitalfernsehen.de…schluesselt.161495.0.html


    Ob das für HD+ (Sat) auch irgendwo ofiziell verkündet wurde weiß ich nicht,....

    Ja, gilt auch für Astra und im übrigen auch für TLC HD: https://www.infosat.de/digital…l-sselt-auf-astra-192-ost


    Beide Sender sind bei mir seit Gestern ohne irgendwelches Zutun meinerseits (d.h. ohne Anpassung der CAID und Einsatz von verbotenen Plugins) hell.


    Code
    1. Eurosport 1 HD;SES ASTRA:11111:HC23M5O35P0S1:S19.2E:22000:767=27:0;771=deu@106:0:0:12502:1:1043:0
    2. TLC HD;BetaDigital:10964:HC23M5O35P0S1:S19.2E:22000:255=27:0;259=deu@106:32:0:10100:1:1033:0

    VDPAU geht auch mit den OSS nouveau Treibern für Nvidia, aber es fehlen halt genau der "heiße Scheiß", temporal, temporal-spatial, gab's auch nie für AMD.


    Temporal Deinterlacing gibt's auch für AMD schon seit ein paar Jahren, siehe Grafikkarten 2015 - Nvidia/VDPAU noch sinnvoll bei Haswell CPU/GPU ?


    Temporal Spatial war auch in Arbeit, aber keine Ahnung wie weit das mittlerweile gediehen ist.

    Ich nutze den radeon Treiber....
    Ich war der Überzeugung das nur der mit dieser APU funktioniert und ich hier vdpau nutzen kann.


    Edit: amdgpu funktioniert schon mal nicht.

    DIe APU Athlon 5350 kann wohl nicht mehr:


    Code
    1. DISPLAY=:0 glxinfo | grep GLSL
    2. OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10


    Ich hab auch nen Athlon 5350 und auch das selbe Problem mit softhddevice-openglosd. Laut https://www.x.org/wiki/RadeonFeature/ unterstützen die Kabini APUs sowohl Hardware- als auch (Kernel-) Treiberseitig OpenGL 4.5 (und damit auch GLSL 4.50). Sofern ich das bei meinen Recherchen damals richtig verstanden habe hängt die unter Linux tatsächlich untersützte GLSL Version aber vom Mesa Treiber ab. Und die hängen da traditionell etwas hinterher. Ich nutze aktuell die yaVDR 0.6 Pakte unter Ubuntu 14.04.5 mit aktuellem Mainline Kernel und dem Xenial Hardware Enablement Stack. Sprich Mesa 11.2 und somit auch nicht das neuste. Mehr wie GLSL 1.30 ist damit leider nicht drin. Ab Mesa 12.0 wird dann immerhin mal OpenGL 4.3 untersützt. Welche Mesa Version verwendest du denn bei dir?

    Zwar nicht direkt mit yaVDR 0.6, aber mit Ubuntu 14.04.5 LTS und den Paketen von yaVDR 0.6. Läuft hier seit rund einem halben Jahr bestens. Ich hatte das davor auch bereits 2 Jahre lang genau so stabil laufen mit den yaVDR 0.5 Paketen unter Ubuntu 12.04 + Trusty HWE Stack, siehe Offiziell VDPAU mit AMD Grafikkarten.


    Ubuntu 14.04 bringt im Gegensatz zu 12.04 grundsätzlich bereits von Haus aus alles mit was man zwingend für VDPAU mit Kabini bzw. dem radeon Treiber allgemein benötigt:
    - Kernel Version >= 3.15.3 (für das radeon Kernel Modul)
    - Mesa Version >= 10.1.3 (für den radeon Mesa Treiber)
    - Kabini Firmware aus dem Paket firmware-nonfree


    Aktuell läuft bei mir VDR v2.2.0 und SoftHDDevice v0.6.1rc1 (aus dem yaVDR 0.6 PPA) sowie Kodi v16.1 (aus dem team-xbmc PPA) auf dem Xenial HWE Stack (Mesa v11.2.0 + Kernel 4.4). Nicht dass es unbedingt nötig wäre, aber als aktiven Kernel fahr ich allerdings den neusten Ubuntu Mainline , aktuell v4.9.x.

    Am liebsten haette ich eine umschaltloesung, die von menueintraegen kommt:


    A) Was wuerde man denn heute als plugin nehmen, dass man im VDR menu einen eintrag mit namen hinkriegt der irgendein programm/script aufruft. Und den menueintrag dann auch passend in der menuliste plazieren laesst ? Script um VDR zu stoppen/KODI zu starten ist dann ja kein problem.


    Das Externalplayer Plugin bietet diese Funktionalität. Gibt hier im Forum auch einige Beiträge dazu mit den entsprechenden Configs für das Plugin und Startscripten für Kodi.



    B) Kriegt man dasselbe im KODI hin ? Also evtl. im KODI garnicht "Live TV" konfigurieren, sondern ebenso im Hauptmenu einen Eintragen, eg> "VDR" haben...


    Idealerweise sollte man ja KODI/VDR nicht killen muessen beim umschalten, sondern irgendwie bloss suspenden, damit das umschalten besser flutscht, aber ich befuerchte mal, dass das nicht geht


    Um via Externplayer Plugin automatisch zum VDR zurückzukehren muss man Kodi lediglich beenden. Das entspricht dann zwar nicht exakt dem was du willst, aber es funktioniert. Also zumindest im Zusammenspiel mit SoftHDDevice. Inwiefern sich das beim RPIHDDevice genau so verhält kann ich dir nicht sagen.

    Zu AMD kann ich nicht viel sagen, da ich es nicht richtig verfolgt habe,
    Mein letzter Stand ist, daß es immer noch keine gute Deinterlacer gibt.
    Aber BOB war ausreichend gut.


    Es gibt seit geraumer Zeit auch nen Temporal Deinterlacer für AMD [1] [2], der sich hinter dem Temporal Deinterlacer von Nvidia imho nicht zu verstecken braucht.


    Und wenn ich mir die folgende Unterhaltung im Radeon Channel anschaue, bin ich mir nicht sicher ob es sich dabei nicht sogar schon um Temporal Spatial Deinterlacing handelt, mit dem hier das VDPAU "Temporal" Profil impelentiert:


    http://people.freedesktop.org/~cbrill/dri-log/?channel=radeon&date=2013-09-18


    Die Unterhaltung war ca. 3 Monate bevor die entsprechenden Patches hochgeladen wurden. Und wenn nicht sollte Temporal Spatial ja auf jeden Fall auch noch in Arbeit sein. Müsste man ggf. mal genau nachfragen.


    Ich hab ja seit längerem einen Kabini (Athlon 5350) auf dem MSI AM1I Board im Betrieb, siehe Radeon/VDPAU Thread (dort gibt's auch Messwerte vom qvdpautest). Ich fahre mittlerweile Kernel 3.18 und hab keine Probleme mehr. Vorher lief das soweit zwar auch schon alles schon ganz gut, allerdings gab's ab und an mal noch ne Kernel Panic wegen dem radeon Modul. Stromverbrauch mit SoftHDDevice - heute neu gemessen - liegt bei 20,5W bei 576i (DMAX), 21,6W bei 720p (ARD) und 22,4W bei 1080i (ServusTV). Zum Vergleich: auf dem Desktop im Idle bei gestopptem VDR sind's 13,6W. Unter Last war der Verbrauch bei allen Formaten bei früheren Messungen auch schon mal ca. 1-1,5W besser. Allerdings gab es seitdem Änderungen an den Powerstates mit Kernel 3.17 und ich habe einen Atric IRWakeupUSB eingebaut sowie den RAM gewechselt von DDR3-1066@1.5V zu DDR3-1600@1,35V. Keine Ahnung was da jetzt genau welchen Einfluss hatte. Mit Powertop konnte ich damals bei den Tests mit allen aktivierten Optionen im Idle auch noch 2-3W mehr rausholen. Allerdings hat dann meine Logitech K400 Tastatur extrem träge reagiert und danach habe ich mich nicht mehr näher damit beschäftigt welche der einzelnen Optionen sinnvoll wären weil ich auch ohne Powertop schon zufrieden war. Es gäbe da also auch noch durchaus Potential für weitere Optimierungen.


    Ich habe zwar keinen direkten Vergleich, aber ich bilde mir ein dass das Temporal Spatial Deinterlacing auf der GT220 von meiner vorherigen Nvidia Kiste schon noch nen Tick besser ausgesehen hat. Aber was das Deinterlacing angeht ist das wohl jammern auf hohem Niveau. Da vermisse ich eher das HQ Upscaling. Mir war aber in erster Linie wichtig dass sich das ganze deutlich unter 25W bewegt und in ein ITX Gehäuse passt (ich hab dieses: Silverstone Milo ML05). Nvidia + DD Cine geht im ITX Format ja quasi nicht. Man braucht dann immer noch 2 PCIe Steckplätze und ITX Mainboads mit FullSize Mini PCIe Slot für die Octopus Bridge sind äußerst rar gesät...

    fstab:

    Code
    1. /dev/sr0 /cd auto user,noauto 0 0


    Kannst du mal die DVD von Hand nach /media/... mounten, z.B. nach /media/dvd und schauen ob das XBMC sie dann vielleicht erkennt? Ich vermute mal dass das XBMC die dort erwartet. Wie in dem anderen Thread geschrieben funktioniert das bei mir ja mittlerweile mit der Erkennung. Und bei mir wird eine DVD nach dem Einlegen von Ubuntu ohne weiteres Zutun dynamisch nach /media/<VOLUME> gemountet.

    Das Problem hatte ich auch mal. Eigentlich sollte es beim Confluence Skin ja so sein: Man legt eine DVD ein, und es erscheint im Hauptmenü ein Eintrag "Disc Abspielen" mit Untermenü "Öffnen/Schließen". Und zwar zwischen "Programme" und "System", und nicht etwa als Untermenü von "Video". Das funktionierte bei mir allerdings nur dann, wenn der eingelegte Datenträger vom Betriebssystem (bei mir Ubuntu 12.04) nach dem Schließen des Trays auch direkt automatisch eingebunden wurde. Dazu musste ich unter "Einstellungen" -> "Wechseldatenträger- und Medieneinstellungen" -> "Datenträger" die Option "Wechselmedien beim Einlegen einhängen" aktivieren. Aber keine Ahnung wie man das unter yaVDR macht.


    Eine Skin-Einstellung um das "Disc Abspielen" immer anzeigen zu lassen gibt es für das Confluence Skin nicht. Man kann allerdings auch in der Datei "/usr/share/xbmc/addons/skin.confluence/Home.xml" rumpfuschen. Wenn man dort nach dem DVD Code sucht und dort das <visible>System.HasMediaDVD</visible> entfernt, wird der Hauptmenü-Eintrag immer angezeigt unabhängig davon ob eine Disc eingelegt ist bzw. korrekt erkannt wurde oder nicht.

    Hmm, komisch... Ich nutze ja libav weil Ubuntu 12.04 standardmäßig damit daher kommt. Allerdings ohne dass ich das SoftHDDevice extra dafür selbst gebaut hätte bzw. hätte müssen. Ich hab das ganz normale yaVDR Paket aus dem Testing PPA drauf. Wenn yaVDR 0.5 aber doch ffmpeg nutzt (oder etwa nicht?!?), müsste doch das SoftHDDevice demnach auch für ffmpeg gebaut sein. Aber wieso funktioniert bei mir libav dann trotzdem ?(


    Ich war sowieso gerade letztens erst hier im Forum auf das Thema libav/ffmpeg bei SoftHDDevice gestoßen und frage mich die ganze Zeit schon was denn für SoftHDDevice die bessere Lösung ist und warum? Soweit ich das jetzt sehe braucht's für ffmpeg unter Precise sowieso schon mal eine externe Paketquelle. Und für ffmpeg >= 2.2 brauchst's dann auch noch ein neueres SoftHDDevice als das aus yaVDR Stable bzw. Testing mit entsprechendem Fix. Lohnt sich der Aufwand überhaupt?

    Ich würd auch auf ffmpeg tippen. Denn was mir aufgefallen ist: Boss666 nutzt mit yaVDR 0.5 ffmpeg. Ich nutze unter meinem Ubuntu + yaVDR PPA hingegen libav. Und bei mir läuft SD Material aber ja ohne Probleme, obwohl wir ansonsten seit der Aktualisierung des yaVDR Stable Repos ja quasi auf die gleiche Art unterwegs sind...

    Brauchst du jetzt (oder auch in absehbarer Zeit) eine Low Profile Karte? Dann würd ich nämlich eher die Zotac empfehlen. Die ist zwar ein paar Euro teuerer, hat aber im Gegensatz zu Palit und Gainward auch ein LP Slotblech mit dabei. Das müsstest du sonst teuer nachkaufen. Wie das bei den Karten von ASUS und PNY aussieht weiß ich nicht.

    Mit dem Konglomerat kam kein Bild. Da ich auch per ssh nicht mehr auf den VDR drauf komme, wird es wohl Probleme mit der Hardware (Ethernet-Onboard) im Zusammenhang mit dem Kernel geben. Ich werde mal schauen, dass ich auch testweise mal den 3.15.3er Mainline-Kernel installiert bekomme.


    'Kein Bild' heißt kein TV-Bild vom VDR? Oder lief der xserver auch schon nicht?


    Zu dem Netzwerkproblem: Abgesehen davon, dass bei dem LTS Trusty Stack Firmware-Dateien für das r8169 Modul fehlen (diese hatte ich mir aus dem Debian Wheezy Paket firmware-realtek geholt), scheint da ab Kernel 3.13 irgendwas mit dem r8169 Modul für die Realtek NICs nicht mehr zu passen. Ich hatte nach dem Upgrade auf den Trusty Stack auf 2 verschiedenen Systemen ebenfalls Probleme damit. Bei der Realtek RTL8111DL auf dem MSI 785GM-E65 von meinem Produktiv-VDR half es das r8169 Paket zu Blacklisten und stattdessen das r8168-dkms Paket zu nutzen. Da dies aber momentan gegen Kernel 3.15 nicht mehr baut, war das für die Realtek RTL8111G auf dem MSI AM1I von meinem Kabini System aber keine Lösung. Nachdem ich bei dem System im syslog Fehler vom dnsmasq entdeckt hatte, konnte ich die Probleme dort vorerst damit gelösen dass ich dnsmasq im NetworkManager einfach deaktiviert hab. Nachträglich hab ich dann gesehen dass das hier z.B. auch geholfen hatte.


    Ist halt noch der wackelige Punkt mit SoftHDDevice aus dem yaVDR Stable- oder doch besser Testing-Repo.


    Daran sollte es dann jetzt auch nicht mehr scheitern :)
    Updates für yaVDR 0.5 stable: VDR 2.0.6, XBMC Gotham, Lirc usw.

    Ubuntu 12.04 LTS + LTS Trusty Enablement Stack ist erledigt. Um den Mainline-Kernel würde ich - wenn möglich - gern einen Bogen machen.


    Der 3.13.0er Kernel den du jetzt benutzt ist suboptimal, siehe Radeon OSS with vdpau (howto) - History im XBMC Forum:

    Zitat

    2014/02/24: Updated to kernel 3.13.5 this adds two important fixes for HD 7xxx and Kabini

    Und wie man dort nachlesen kann gab's danach noch weitere Fixes mit Kernel 3.15, sowie auch problematische Änderungen die erst mit Kernel 3.15.3 wieder herausgenommen wurden. Deshalb hab ich auch genau den genommen, siehe Link in meinem letzten Posting.


    blablubb@VDR-HD-Emmering:~$ sudo apt-get install xserver-xorg-video-radeon xserver-xorg-video-ati

    Damit versuchst du die Installation der Radeon Pakete für den Standard xserver von Ubuntu 12.04 OHNE die Benutzung eines der HWE Stacks. Das ist nicht das was du brauchst und das kann auch nicht funktionieren wenn du den Trusty Stack bereits installiert hast. Was du brauchst sind die Pakete xserver-xorg-video-radeon-lts-trusty und xserver-xorg-core-lts-trusty passend zum LTS Trusty Stack, und die hast du laut aptitude ja auch bereits drauf. Und soweit ich das anhand deinem xorg Log beurteilen kann wird auch das radeon Kernel-Modul zumindest mal geladen. Hast du die notwendigen radeon bzw. Kabini Firmware Dateien drauf? Die befinden sich im Paket linux-firmware-nonfree, und wenn noch was fehlen sollte siehe Link oben.


    Meine xorg.conf hab ich komplett neu erstellen lassen, so wie unter http://askubuntu.com/questions…g-conf-file/281685#281685 beschrieben. Ich hab lediglich kontrolliert ob in der Section "Device" der radeon Driver benutzt wird sowie den folgenden Abschnitt ergänzt um wegen dem bekannten Tearing-Problem das Compositing abzuschalten:

    Code
    1. Section "Extensions"
    2. Option "Composite" "0"
    3. EndSection


    Ob die Versionen im yaVDR Stable Repository ausreichen kann ich nicht genau sagen. Ich denke aber schon da man damit afaik ja SoftHDDevice mit VDPAU auf Nvidia-Basis auch problemlos nutzen kann. Voraussetzung ist auf jeden Fall dass du auch das Paket mesa-vdpau-drivers-lts-trusty installiert hast.

    Ich wollte an dieser Stelle eh nochmal von meinen Erfahrungen zu dem Thema berichten. Ich hab zwar nicht direkt yaVDR 0.5 am laufen, aber Ubuntu 12.04 mit yaVDR-Paketen. Hardware-Basis ist ein MSI AM1I mit einem Athlon 5350 (siehe Gesucht: MiniITX mit VDPAU/VAAPI/AMD Kabini und Sat-Tuner-Karte). Also ebenfalls ein Kabini, allerdings mit einer HD 8400 (Radeon R3 @ 600MHz). Ich hatte mich u.a. wegen der Software-Seite lange vor der Anschaffung eines AMD-Systems gescheut, aber mittlerweile ist das absolut kein Problem mehr das zum Laufen zu kriegen. Meine verwendete Software (in Klammern die Quellen für meine Recherchen):

    *seit heute gibt's auch schon Kernel v3.15.6, was neueres als v3.15.3 hab ich aber noch nicht getestet


    Da ich keine Lust auf eine Neuinstallation hatte, hab ich als Software-Basis die Ubuntu-Installation von meinem Produktiv-VDR (Athlon 260u + Nvidia GT220) verwendet. VDR-seitig war daher bereits alles vorhanden was man für VDPAU braucht und XBMC Gotham hatte ich da auch schon drauf. Nachdem ich das System erfolgreich auf die neue SSD meiner AMD-Plattform geklont hatte, hab ich erst mal den Kernel 3.15.3 installiert wie hier beschrieben. Während der der Installation wurden beim Erstellen der init.rd fehlende Firmware-Dateien für diverse Radeon Chips bemängelt. Die hab ich mir dann von http://people.freedesktop.org/~agd5f/radeon_ucode/ besorgt und nach "/lib/firmware/radeon/..." kopiert.


    Danach hab ich den vorhandenen LTS Saucy Stack auf Trusty hochgezogen. Da ich damals schon Probleme bei der Installation des Saucy Stacks hatte (die Pakete ließen sich nur mit dem Suffix ":i386" installieren da es sonst nicht erfüllte Abhängigkeiten gab), gab's jetzt auch Probleme beim direkten Upgrade von Saucy auf Trusty. Deshalb musste ich den Saucy Stack so wie er drauf gekommen war erst wieder sauber deinstallieren, bevor ich ganz normal den Trusty Stack installieren konnte. Abgesehen davon ging das alles problemlos. Danach hab ich lediglich noch eine passende xorg.conf erstellt und fertig.


    Das was ich bisher damit getestet habe lief soweit ganz gut. Abgesehen von ein paar Problemchen mit der sonstigen Hardware des Mainboards (Knallen des angeschlossenen Boxensystems beim Ein- und Auschalten des PCs, 1x Kernel-Panic wegen ALSA, fehlende Realtek LAN-Firmware + Aussetzer bei der Netzwerkverbindung mit dem LTS Trusty Stack), hatte ich bislang nur einmal folgendes Problem: nach der Rückkehr zum VDR aus dem XBMC über das Externalplayer-Plugin hatte ich Bildruckeln auf dem getunten Sender. Nachdem ich ein mal umgeschaltet hatte war das aber wieder weg. Unter SoftHDDevice und XBMC läuft alles flüssig, das Temporal-Deinterlacing funktioniert und es gibt so gut wie keine Framedrops. Was die Bildqualität angeht sieht das alles auch ganz nett aus. An mein Nvidia-System mit Temporal+Spatial-Deinterlacing und HQ-Upscaling kommt es aber selbstverständlich nicht ganz ran - verbraucht andererseits aber auch locker weniger als die Hälfte davon. Aber vermutlich ist das Jammern auf hohem Niveau. Die Thematik Temporal vs. Temporal+Spatial wurde ja an diversen anderen Stellen bereits zur Genüge diskutiert. Mir persönlich würde das Temporal-Deinterlacing reichen, das einzige was ich mir für die AMD Lösung noch wünschen würde wäre das HQ-Upscaling [Update: das "temporal" Profil des AMD Deinterlacers von zgreg implementiert vermutlich sogar bereits ein Temporal-Spatial Deinterlacing, siehe Grafikkarten 2015 - Nvidia/VDPAU noch sinnvoll bei Haswell CPU/GPU ?]. Ich hoffe dass ich morgen mal dazu komme in dem anderen Thread noch die Messwerte vom Stromverbrauch zu posten. Hier mal noch ein paar Infos:


    Systeminfos:


    vdpauinfo:


    qvdpautest:

    Zu beachten wäre hier dass ich momentan nur einen 4GB DDR3-1066 Riegel drin hab. Mit 1600er RAM sehen die Werte noch entsprechend besser aus.


    VDR vdpau Unterstützung:


    Grüße
    ironman

    Die Diskussion passt ja gerade ganz gut, ich hatte mir letzte Woche mal ne Athlon 5350/MSI AM1I Kombo bestellt und heute beim Hardwareluxx mal meine Testergebnisse vom Wochenende zusammengefasst. Mit einer dazugesteckten DD/L4M Cine S2 Rev. 5.5 (weder SAT-Anlage noch Stromstecker angeschlossen) habe ich mit auf dem Board angeschlossenem CPU-Lüfter und ansonsten gleichen Bedingungen 13,3W im Idle gemessen.


    Heute hatte ich das System dann auch mal auf VDR-Tauglichkeit getestet. Das lief soweit ganz gut (Ubuntu 12.04. + yaVDR PPA + Kernel 3.15.3 + Mesa 10.1.3 via Trusty LTS Enablement Stack, näheres dazu bei Gelegenheit im Radeon/VDPAU-Thread). Messwerte vom Stromverbrauch unter Ubuntu versuch ich morgen mal nachzuliefern.


    DDD : du bist nicht zufällig -DDD- beim Luxx, der dort nach dem S5 Verbrauch gefragt hat? :D

    Mal sehen ob eine etwaiges Maxwell basiertes Produkt dann noch sparsamer bei gleicher Leistung ist, cool fände ich ja max. 14W bei gleicher VDPAU Leistung wie die GT630 ... :whistling:


    So in etwa hätte ich mir das auch erhofft ;-)


    Naja, denke kaum dass maxwell da noch wesentlich mehr an Effizienz rausholt als der GK208-301-A1.


    Naja, der GK208 ist und bleibt am Ende ein Kepler. Und ich denke dass die Effizienz-Vergleiche zwischen dem GK107 und dem GM107 in den Reviews von Mitte Februar beim Launch der GTX 750 und GTX 750 TI schon gezeigt haben dass da noch was geht. Zumal ja beide bislang noch in gleicher Strukturbreite von 28nm gefertigt werden. Zugegebenermaßen, der Vergleich mit dem GK208 hinkt. Schließlich handelt es sich dabei im Gegensatz zum GK107 um die 2. Kepler Generation. Allerdings ist der 28nm GM107 wohl auch nur der Testlauf für Maxwell bevor man bei Nvidia bei der 800er Serie auf 20nm-Fertigung umstellt. Und spätestens dann wird Maxwell zwangsläufig nochmal effizienter.


    Hier ist noch eine nette Übersicht über die 730er-Varianten:
    http://www.3dcenter.org/news/n…-geforce-gt-730-serie-vor


    Das Entscheidende:

    Zitat

    Die "GeForce GT 730 128-Bit" ist im übrigen ein direktes Rebranding der früheren GeForce GT 430, genauso wie die "GeForce GT 730 64-Bit DDR3" ein direktes Rebranding der GeForce GT 630 64-Bit darstellt. Zwischen der "GeForce GT 730 64-Bit GDDR5" und der früheren GeForce GT 640 GDDR5 liegt dann nur ein gewisser Unterschied beim Chiptakt, ansonsten ist es aber die gleiche Hardware.


    Also nichts neues. Schade... Ich hatte auf neue Low-Cost Karten auf Maxwell-Basis gehofft da die GTX 750 mit Maxwell extrem vielversprechend aussieht. Aber so heißt es dann wohl nochmal 1 Jahr warten bis zur 800er Serie...