Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Nachgefragt: Ein stabiler Kernel…

Und trotzdem keine standard kernel abi für module

  1. Thema

Neues Thema Ansicht wechseln


  1. Und trotzdem keine standard kernel abi für module

    Autor: anonymous 17.08.06 - 12:31

    Nach Aussagen aus dem Artiel gibt es nicht mal genug Entwickler alle Fehler zu beheben, statt dessen/trotzdem passen die Leute alle Treiber immer wieder an die neuen Kernelversionen an. Ist das nicht Arbeit an der falschen Stelle eingestezt? Ob nun opensource treiber oder nicht, wäre es nicht sinnvoll wenigstens stufenweise kernel api für treiber module einzurichten?!

  2. Re: Und trotzdem keine standard kernel abi für module

    Autor: soc 17.08.06 - 12:44

    anonymous schrieb:
    -------------------------------------------------------
    > Nach Aussagen aus dem Artiel gibt es nicht mal
    > genug Entwickler alle Fehler zu beheben, statt
    > dessen/trotzdem passen die Leute alle Treiber
    > immer wieder an die neuen Kernelversionen an. Ist
    > das nicht Arbeit an der falschen Stelle
    > eingestezt?
    es sind oftmals verschiedene personen, die neue treiber schreiben und die, die fehler beheben. warum sollte sich ein entwickler der firma xyz um irgendwelche kernel-bugs z. b. in linux/mm/madvise.c kümmern, wenn er angestellt ist einen treiber für ein neues produkt zu schreiben.

    > Ob nun opensource treiber oder nicht,
    > wäre es nicht sinnvoll wenigstens stufenweise
    > kernel api für treiber module einzurichten?!
    und jetzt noch mal auf deutsch?
    es gibt bereits eine api.

  3. Re: Und trotzdem keine standard kernel abi für module

    Autor: Hello World 17.08.06 - 14:57

    soc schrieb:
    -------------------------------------------------------
    > kernel api für treiber module einzurichten?!
    > und jetzt noch mal auf deutsch?
    > es gibt bereits eine api.
    Ja, eine die alle drei Releases geändert wird -.-

  4. Re: Und trotzdem keine standard kernel abi für module

    Autor: föhn 17.08.06 - 16:11

    Hello World schrieb:
    -------------------------------------------------------
    > soc schrieb:
    > --------------------------------------------------
    > -----
    > > kernel api für treiber module
    > einzurichten?!
    > und jetzt noch mal auf
    > deutsch?
    > es gibt bereits eine api.
    > Ja, eine die alle drei Releases geändert wird

    was aber für OSS treiber die im kernel enthalten sind unwesentlich ist, da diese imho von den kernel-maintainern angepasst werden.

    die philosophie ist ja eben die möglichst nur OSS im kernel zu haben.
    deshalb wird es anbietern die nur CSS treiber bereitstellen nicht grade erleichtert - in dem man eben keine rücksicht auf dieselbigen nimmt und wenn nötig mirnichtsdirnichts die api ändert.

  5. Re: Und trotzdem keine standard kernel abi für module

    Autor: kalikiana 17.08.06 - 17:46

    >
    > die philosophie ist ja eben die möglichst nur OSS
    > im kernel zu haben.
    > deshalb wird es anbietern die nur CSS treiber
    > bereitstellen nicht grade erleichtert - in dem man
    > eben keine rücksicht auf dieselbigen nimmt und
    > wenn nötig mirnichtsdirnichts die api ändert.

    Und dann geht es nach Hinten los wenn Firmen wie z.B. ATI einfach kein Interesse an aktuellen Linuxtreibern haben. :(

  6. Ursache an der Wurzel bekämpfen

    Autor: iggy 17.08.06 - 18:25

    Ich fände es klüger, wenn man sich endlich vom Monolithischem Kernel verabschieden würde und mehr in Richtung Microkernel arbeiten würde.
    Gerade jetzt, da ohnehin auf dualcore-cpu, quad-cpu usw. gearbeitet wird, fielen einige der ursprünglichen Nachteile des Microkernel ohnehin gen Vergangenheit.

    Natürlich hat das Monolithische System seine Vorteile. Aber man sieht ja, wie die Nachteile langsam die Vorzüge in den Schatten stellen.
    Ich denke, auch das Treiberproblem könnte so besser gelöst werden.

  7. Ursache an der Wurzel bekämpfen

    Autor: iggy 17.08.06 - 18:26

    Ich fände es klüger, wenn man sich endlich vom Monolithischem Kernel verabschieden würde und mehr in Richtung Microkernel arbeiten würde.
    Gerade jetzt, da ohnehin auf dualcore-cpu, quad-cpu usw. gearbeitet wird, fielen einige der ursprünglichen Nachteile des Microkernel ohnehin gen Vergangenheit.

    Natürlich hat das Monolithische System seine Vorteile. Aber man sieht ja, wie die Nachteile langsam die Vorzüge in den Schatten stellen.
    Ich denke, auch das Treiberproblem könnte so besser gelöst werden.

  8. na fang doch an damit

    Autor: xXXXXx 17.08.06 - 19:59

    wozu sollte man das bei linux tun? kommt doch demnächst GNU HURD. :D

  9. Re: Und trotzdem keine standard kernel abi für module

    Autor: Marek 17.08.06 - 21:42

    Was wiederum für ATI nach hinten los gehen würde.
    Naja "würde" denn AMD hat ja angekündigt OSS Treiber zu veröffentlichen..
    Wer die Kunden nicht nötig hat lässt es eben...aber auch wenn es nach Getrolle klingt: die Verbreitung steigt und wird mit Vista noch mehr steigen. TCPA oder wie auch immer MS das nun nennt sei dank.
    Hab mit der Beta 2 von Vista 3 Tage rumspielen dürfen und es ist schon nevigt bei JEDEM Programm eine "Nicht zertifiziertes Programm" - Meldung wegzuklicken.. Ausserdem ist es auf der 3 Mhz Maschine mit 3/4 Gig unglaublich langsam..

  10. Re: Und trotzdem keine standard kernel abi für module

    Autor: XeniosZeus 17.08.06 - 22:08

    föhn schrieb:
    -------------------------------------------------------
    > die philosophie ist ja eben die möglichst nur OSS
    > im kernel zu haben.
    Das ist ja genau das Dilemma. Um immer möglichst viele neue Hardware zu unterstützen, wird der Kernel immer schneller weiterentwickelt. Schnell und stabil passt aber nicht zusammen.

    > deshalb wird es anbietern die nur CSS treiber
    > bereitstellen nicht grade erleichtert - in dem man
    > eben keine rücksicht auf dieselbigen nimmt und
    > wenn nötig mirnichtsdirnichts die api ändert.
    Das nächste Dilemma. Beispiel Cherry.
    Für die Linux-Tastatur CyMotion gibt es 6 verschiedene Treiber - Fedora 4.0, Debian 3.1, Mandrake 10.1, Suse 9.x und 10.0 sowie den Source-Code Treiber.
    Schaut man in die entsprechenden Foren, gibt es trotz vorbildlicher Treiberunterstützung von Cherry viele nervige Probleme. Im Kernel wird die Tastatur nicht unterstützt, obwohl der Source-Code vorliegt.
    Da entscheidet eine kleine Gruppe, was neu in den Kernel kommt. Der Hersteller der Hardware hat darauf keinen Einfluss. Seine eigenen Treiber laufen wegen ständiger Änderung der Programmierschnittstelle (API) mehr schlecht als recht.
    Warum sollte ein Hardwarehersteller überhaupt noch Linux unterstützen?
    Über die Aufnahme im Kernel entscheidet er nicht und schlecht funktionierende Treiber schädigen den Ruf.
    Die Philosophie ist falsch! Problem ist nur zu lösen, wenn alles in Frage gestellt wird.


  11. Re: na fang doch an damit

    Autor: Mog 18.08.06 - 09:30

    xXXXXx schrieb:
    -------------------------------------------------------
    > wozu sollte man das bei linux tun? kommt doch
    > demnächst GNU HURD. :D

    Und das schon seit ueber 30 Jahren. ^^d

  12. Re: Und trotzdem keine standard kernel abi für module

    Autor: paddor 18.08.06 - 11:29

    XeniosZeus schrieb:
    -------------------------------------------------------
    > föhn schrieb:
    > --------------------------------------------------
    > -----
    > > die philosophie ist ja eben die möglichst nur
    > OSS
    > im kernel zu haben.
    > Das ist ja genau das Dilemma. Um immer möglichst
    > viele neue Hardware zu unterstützen, wird der
    > Kernel immer schneller weiterentwickelt. Schnell
    > und stabil passt aber nicht zusammen.
    >
    > > deshalb wird es anbietern die nur CSS
    > treiber
    > bereitstellen nicht grade erleichtert
    > - in dem man
    > eben keine rücksicht auf
    > dieselbigen nimmt und
    > wenn nötig
    > mirnichtsdirnichts die api ändert.
    > Das nächste Dilemma. Beispiel Cherry.
    > Für die Linux-Tastatur CyMotion gibt es 6
    > verschiedene Treiber - Fedora 4.0, Debian 3.1,
    > Mandrake 10.1, Suse 9.x und 10.0 sowie den
    > Source-Code Treiber.
    > Schaut man in die entsprechenden Foren, gibt es
    > trotz vorbildlicher Treiberunterstützung von
    > Cherry viele nervige Probleme. Im Kernel wird die
    > Tastatur nicht unterstützt, obwohl der Source-Code
    > vorliegt.
    > Da entscheidet eine kleine Gruppe, was neu in den
    > Kernel kommt. Der Hersteller der Hardware hat
    > darauf keinen Einfluss. Seine eigenen Treiber
    > laufen wegen ständiger Änderung der
    > Programmierschnittstelle (API) mehr schlecht als
    > recht.
    > Warum sollte ein Hardwarehersteller überhaupt noch
    > Linux unterstützen?
    > Über die Aufnahme im Kernel entscheidet er nicht
    > und schlecht funktionierende Treiber schädigen den
    > Ruf.
    > Die Philosophie ist falsch! Problem ist nur zu
    > lösen, wenn alles in Frage gestellt wird.
    >
    >


    loool, du troll
    hast du gedacht, alles kommt einfach so in den offiziellen kernel rein, nur weil die source verfügbar ist?
    1. heisst ist es nicht zwingend, dass die software unter der GPL steht, wenn deren source verfügbar ist (und GPL wird von den kernel-entwicklern bevorzugt/vorgeschrieben)
    2. kann man ja eigene treiber (sogar während laufendem betrieb) einbinden!
    3. wollen die kernel-entwickler auch sicher sein, dass die software durch und durch getestet ist und einwandfrei läuft! denn sie sind unabhängig, da geht's nicht um geld.. sie haben das recht und die freiheit dazu (darum ist reiser4 immer noch nicht drin, obwohl herr reiser dauernd stürmt)
    4. ist so eine tastatur nicht gross verbreitet
    5. wäre der kernel dann innerhalb von einer woche 5gb gross, wenn jeder treiber einfach so rein kommen würde

    und ganz nebenbei. was ist denn daran falsch, dass es jetzt eine neue kernel-serie gibt? ist doch ne super initiative, da die entwickler selber merken und auch zugeben, dass die neuen kernel im gegenstaz zu den älteren kerneln recht viele fehler enthalten (meiner meinung nach immer noch um welten besser als bei M$)

  13. Re: Ursache an der Wurzel bekämpfen

    Autor: paddor 18.08.06 - 11:30

    iggy schrieb:
    -------------------------------------------------------
    > Ich fände es klüger, wenn man sich endlich vom
    > Monolithischem Kernel verabschieden würde und mehr
    > in Richtung Microkernel arbeiten würde.
    > Gerade jetzt, da ohnehin auf dualcore-cpu,
    > quad-cpu usw. gearbeitet wird, fielen einige der
    > ursprünglichen Nachteile des Microkernel ohnehin
    > gen Vergangenheit.
    >
    > Natürlich hat das Monolithische System seine
    > Vorteile. Aber man sieht ja, wie die Nachteile
    > langsam die Vorzüge in den Schatten stellen.
    > Ich denke, auch das Treiberproblem könnte so
    > besser gelöst werden.


    ACK. GNU/Hurd soll endlich fertig werden! :P

  14. Re: na fang doch an damit

    Autor: iggy 18.08.06 - 11:30

    Nein, im Ernst.
    Wär doch ein guter Vorsatz für Kernel 3.0
    Bzgl. Gnu HURD: Was ist das genau? Wie weit ist das Einsetzbar?
    Sollte es nicht möglich sein, den GNU HURD-Code für ein neues Linux zu benutzen?

    xXXXXx schrieb:
    -------------------------------------------------------
    > wozu sollte man das bei linux tun? kommt doch
    > demnächst GNU HURD. :D


  15. Re: Und trotzdem keine standard kernel abi für module

    Autor: XeniosZeus 18.08.06 - 17:38

    paddor schrieb:
    -------------------------------------------------------
    > loool, du troll
    > hast du gedacht, alles kommt einfach so in den
    > offiziellen kernel rein, nur weil die source
    > verfügbar ist?
    Nein, hab ich nicht. Ich habe nur den derzeitigen Stand dargestellt, mit dem ein Hardwarehersteller zu kämpfen hat.
    Den Troll geb ich wieder zurück, der fühlt sich bei dir wohler.

    > 1. heisst ist es nicht zwingend, dass die software
    > unter der GPL steht, wenn deren source verfügbar
    > ist (und GPL wird von den kernel-entwicklern
    > bevorzugt/vorgeschrieben)
    Cherry war hier nur als Beispiel gedacht. Der Treiber von Cherry steht übrigens unter der GPL.

    > 2. kann man ja eigene treiber (sogar während
    > laufendem betrieb) einbinden!
    Das ist nicht das Thema. Beim Beispiel Cherry gibt es ja auch genügend Treiber. Ich wollte das Problem darstellen, dass der Hardwarehersteller keinen Einfluss auf den Kernel hat und er Treiber für verschiedene Distributionen und Kernelversionen herstellen muss, weil durch Fehler im Kernel laufend neue Versionen erscheinen. Deshalb ja auch der Ruf nach einem stabilen Kernel, auf dem aufgebaut werden kann.

    > 3. wollen die kernel-entwickler auch sicher sein,
    > dass die software durch und durch getestet ist und
    > einwandfrei läuft! denn sie sind unabhängig, da
    > geht's nicht um geld.. sie haben das recht und die
    > freiheit dazu (darum ist reiser4 immer noch nicht
    > drin, obwohl herr reiser dauernd stürmt)
    Genau! Welchen Teil des Golem-Beitages hast du dann nicht verstanden?
    Darum geht es. Ein stabiler Kernel wird gefordert. Da kann dann auch der Hardwarehersteller drauf aufbauen und muss nicht andauernd neue Treiber erstellen, weil Kernelpatches und Neuerungen zusammen als neue Kernelversion erscheinen, die dann wieder gepatcht werden muss, weil Fehler in den Neuerungen sind usw.

    > 4. ist so eine tastatur nicht gross verbreitet
    Typisches Grosskotzgehabe der Kernel-Maintainer. Kann für einen mittelständischen Hardwarehersteller nur heißen: Finger weg von der Unterstützung für Linux, oder was?

    > 5. wäre der kernel dann innerhalb von einer woche
    > 5gb gross, wenn jeder treiber einfach so rein
    > kommen würde
    Sag ich doch, die Philosophie ist falsch. Man kann nicht auf der einen Seite Treiber auf Basis der GPL einfordern und dann nicht im Kernel integrieren und auf der anderen Seite durch permanente unsichere Kernelversionen die Treiber der Hardwarehersteller unbrauchbar machen, um dann genau auf diese Treiber wieder zu schimpfen.

    > und ganz nebenbei. was ist denn daran falsch, dass
    > es jetzt eine neue kernel-serie gibt? ist doch ne
    > super initiative, da die entwickler selber merken
    > und auch zugeben, dass die neuen kernel im
    > gegenstaz zu den älteren kerneln recht viele
    > fehler enthalten (meiner meinung nach immer noch
    > um welten besser als bei M$)
    Falsch daran ist, dass Fehler UND neue Features zusammen in einen neuen Kernel eingebaut werden. Neue Features haben nun mal auch Fehler, somit bleibt der neue Kernel weiterhin fehlerhaft und zerstört ggf. Funktionen, die im alten Kernel noch einwandfrei liefen.
    Es wird ein stabiler Kernel verlangt. Keiner spricht davon, die Entwicklung neuer Features und Einbindung neuer Treiber einzustellen.
    Was hier gefordert wird, ist die Pflege des alten Kernels bei zusätzlicher Entwicklung einen neuen Kernels. Und das klappt höchstwahrscheinlich nicht, weil es zu wenige Entwickler gibt.
    Wichtige Sache für Firmen und Behörden, die Linux als OS haben. Die PCs werden vielleicht alle 3 bis 5 Jahre ausgetauscht und die Änderungen in der Software sind in der Regel nicht umwälzend. Da zählt nur Sicherheit. Wenn Sicherheit nur durch einen neuen Kernel mit dann zusätzlich neuen, aber nicht benötigten Funktionen erreicht werden kann, könnte die Sache kritisch werden. Immerhin sollen die Kisten nach einem Kernelupdate auch weiterhin laufen.


  16. Re: Und trotzdem keine standard kernel abi für module

    Autor: ich auch 18.08.06 - 17:47

    paddor schrieb:

    > loool, du troll
    > hast du gedacht, alles kommt einfach so in den
    > offiziellen kernel rein, nur weil die source
    > verfügbar ist?

    Wäre ja auch zuviel Arbeit. Das beweist das ein Monolithen Kernel nie komplette Hardwareunterstützung liefern kann. Zeit das Modell des Monolithen zu überdenken? Nicht für die Linusjünger...

    > 1. heisst ist es nicht zwingend, dass die software
    > unter der GPL steht, wenn deren source verfügbar
    > ist (und GPL wird von den kernel-entwicklern
    > bevorzugt/vorgeschrieben)

    VORGESCHRIEBEN, alles andere darf nicht gegen die GPL software gelinkt werden, so es veröffentlicht wird. Sourcen wirklich freier Lizenzen wie BSD werden kurzerhand assimiliert!

    > 2. kann man ja eigene treiber (sogar während
    > laufendem betrieb) einbinden!

    Genau. Am besten gleich selbst schreiben die Treiber. Und das Akrobatenstück mit dem laufenden betrieb ist auch ganz toll nützlich. Zum einbau der Hardware musst du einen normalen Rechner zwar sowieso ausschalten, hauptsache die Theorie stimmt. Und die ganzen leute die ihre lebenswichtigen Server zu hause haben soll man nicht vergessen. Da wo die Atomkraftwerke drannhaengen und so...

    > 3. wollen die kernel-entwickler auch sicher sein,
    > dass die software durch und durch getestet ist und
    > einwandfrei läuft!

    Und wieso braucht es dann jetzt den Stabilen Kernel wenn das so ist?

    > denn sie sind unabhängig, da
    > geht's nicht um geld..

    Genau. Und wie war das mit OS lässt sich Geld verdienen? Die machen das alles nur für die Liebe der "Community", lässt sich auch prima davon leben, wenn man Stüze kassiet. Den erwirtschaftbaren gewinn schöpft dann IBM am oberen Ende wieder ab.

    > sie haben das recht und die
    > freiheit dazu (darum ist reiser4 immer noch nicht
    > drin, obwohl herr reiser dauernd stürmt)

    Genau. Weil der böse Herr Reiser nämlich ganz viel Geld dafür bekommt wenn die sein FS einbauen. Vielleicht haben Sie auch einfach nur mal lust ihre MACHT auszukosten...

    > 4. ist so eine tastatur nicht gross verbreitet

    Genau. Linux unterstüzt ja fast alles an Hardware was auch Windows unterstüzt. Es sei denn es ist eben nicht so gross verbreitete Hardware. Dann kauf deine Hardware halt Linuxgerecht von GROSSEN Firmen wie Logitech. Nicht das da irgendwie diese ganze "freie" software geschichte nach hinten losgeht!

    > 5. wäre der kernel dann innerhalb von einer woche
    > 5gb gross, wenn jeder treiber einfach so rein
    > kommen würde

    Eben. Vielleicht doch an der zeit das Konzept zu überdenken, das der Kernel die Treiber stellt?

    > und ganz nebenbei. was ist denn daran falsch, dass
    > es jetzt eine neue kernel-serie gibt? ist doch ne
    > super initiative, da die entwickler selber merken
    > und auch zugeben, dass die neuen kernel im
    > gegenstaz zu den älteren kerneln recht viele
    > fehler enthalten (meiner meinung nach immer noch
    > um welten besser als bei M$)

    Und die meinug der "Community" ist hier bei weitem wichtiger...


  17. tanenbaum vs. torvalds

    Autor: iggy 19.08.06 - 13:11

    würde linus torvalds sich endlich mit hr. tanenbaum zusammensetzen und nicht immer auf stur stellen, wenns um das thema microkernel geht, hätte er sich vielleicht schon am hurd-projekt beteiligt. wie gesagt: kernel 3.0

    aber stolz und einsicht vertragen sich eben nicht.




    2 mal bearbeitet, zuletzt am 19.08.06 13:15 durch iggy.

  18. Re: Und trotzdem keine standard kernel abi für module

    Autor: meyerm 19.08.06 - 14:51

    Hallo Marek,

    Marek schrieb:
    -------------------------------------------------------
    > Naja "würde" denn AMD hat ja angekündigt OSS
    > Treiber zu veröffentlichen..

    Das ist doch eine sehr erfreuliche Nachricht! Könntest Du mir noch einen Verweis auf einen Artikel oder gar Presseerklärung schicken, um da etwas mehr nachlesen zu können? Vielen Dank dafür!

    M

  19. Re: Und trotzdem keine standard kernel abi für module

    Autor: cos3 21.08.06 - 15:12

    > Ausserdem ist es auf der 3 Mhz
    > Maschine mit 3/4 Gig unglaublich langsam..

    bei 3 mhz wudert mich das garnicht..


  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. BWI GmbH, Meckenheim
  2. Universität Paderborn, Paderborn
  3. Camelot Management Consultants AG, Mannheim, Köln, München, Basel (Schweiz)
  4. ITEOS, Karlsruhe

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-75%) 3,75€
  2. 33,95€
  3. (-88%) 3,50€
  4. 2,19€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Raumfahrt: Galileo-Satellitennavigation ist vollständig ausgefallen
Raumfahrt
Galileo-Satellitennavigation ist vollständig ausgefallen

Seit Donnerstag senden die Satelliten des Galileo-Systems keine Daten mehr an die Navigationssysteme. SAR-Notfallbenachrichtigungen sollen aber noch funktionieren. Offenbar ist ein Systemfehler in einer Bodenstation die Ursache. Nach fünf Tagen wurde die Störung behoben.


    Projektorkauf: Lumen, ANSI und mehr
    Projektorkauf
    Lumen, ANSI und mehr

    Gerade bei Projektoren werden auf Plattformen verschiedener Onlinehändler kuriose Angaben zur Helligkeit beziehungsweise Leuchtstärke gemacht - sofern diese überhaupt angegeben werden. Wir bringen etwas Licht ins Dunkel und beschäftigen uns mit Einheiten rund um das Thema Helligkeit.
    Von Mike Wobker


      iPad OS im Test: Apple entdeckt den USB-Stick
      iPad OS im Test
      Apple entdeckt den USB-Stick

      Zusammen mit iOS 13 hat Apple eine eigene Version für seine iPads vorgestellt: iPad OS verbessert die Benutzung als Tablet tatsächlich, ein Notebook-Ersatz ist ein iPad Pro damit aber immer noch nicht. Apple bringt aber endlich Funktionen, die wir teilweise seit Jahren vermisst haben.
      Ein Test von Tobias Költzsch

      1. Tablets Apple bringt neues iPad Air und iPad Mini
      2. Eurasische Wirtschaftskommission Apple registriert sieben neue iPads
      3. Apple Es ändert sich einiges bei der App-Entwicklung für das iPad

      1. Festnetz: Deutsche Telekom hat mehr FTTH als Deutsche Glasfaser
        Festnetz
        Deutsche Telekom hat mehr FTTH als Deutsche Glasfaser

        Die Deutsche Telekom hat überraschend den Spitzenplatz bei der Versorgung mit FTTH für sich beansprucht. Zugleich gibt die Telekom zu, dass deutlich weniger als die Hälfte der versorgten Haushalte FTTH auch buchen.

      2. Arbeitsspeicher: Ryzen 3000 rechnet mit DDR4-3733-CL16 am schnellsten
        Arbeitsspeicher
        Ryzen 3000 rechnet mit DDR4-3733-CL16 am schnellsten

        AMDs Zen-2-CPUs unterstützen offiziell DDR4-3200, können aber auch mit deutlich höher getaktetem Speicher umgehen. Ein umfangreicher Test zeigt, dass DDR4-3733 mit relativ straffen Latenzen derzeit das Optimum für die Ryzen 3000 darstellt, weil so auch die interne Fabric-Geschwindigkeit steigt.

      3. UL 3DMark: Feature Test prüft variable Shading-Rate
        UL 3DMark
        Feature Test prüft variable Shading-Rate

        Nvidia unterstützt es bereits, AMD und Intel in den nächsten Monaten: Per Variable Rate Shading werden in PC-Spielen bestimmte Bereiche mit weniger Aufwand gerendert, idealerweise solche, die nicht ins Auge fallen. Der 3DMark zeigt bald, wie unter Direct3D 12 die Bildrate ohne größere Qualitätsverluste steigen soll.


      1. 19:25

      2. 18:00

      3. 17:31

      4. 10:00

      5. 13:00

      6. 12:30

      7. 11:57

      8. 17:52