News Project Limitless: Qualcomm zeigt Snapdragon- vor Intel-Notebook

Lizenznehmer siehe Link (Wikipedia). Aktiv baut(e?) VIA noch x86-CPUs. Ansonsten sind tatsächlich derzeit nur noch Intel und AMD im Rennen. Wobei man die x86_64-Erweiterung - auch bekannt als AMD64 - ja nicht von Intel sondern AMD lizensieren muss. Intel darf die ja auch nur wegen eines Cross-Licensing-Vertrages nutzen, mit dem AMD dann wieder an Befehlssätze wie AVX_XYZ rankommt.

Regards, Bigfoot29
 
Qualcomm und Lenovo, interessant. Mal sehen, wie lange die noch miteinander dürfen ... :).
 
WinnieW2 schrieb:
Das Konzept finde ich schon interessant, aber die Sache steht und fällt mit dem Gerätepreis u. der Verfügbarkeit von nativen Win-ARM64-Programmen.

In meinen Augen steht und fällt sie mit der Verfügbarkeit eines Linux-Bootloaders. Denn Microsoft wird seinem aktuellen Rohrkrepierer nicht auf ewig immer neue Würste um den Hals hängen (Geld zahlen) damit wenigstens der Hund (Qualcom) damit spielt.

Und kommt mir nicht mit "diesmal...". Das hab ich die letzten drei Mal noch geglaubt :-)
 
  • Gefällt mir
Reaktionen: Cruentatus
Hayda Ministral schrieb:
In meinen Augen steht und fällt sie mit der Verfügbarkeit eines Linux-Bootloaders.
Mit einem Linux-Bootloader alleine ist es ja nicht getan, es werden ja auch Treiber für die ganzen Hardwarekomponenten benötigt.
Entweder der Gerätehersteller müsste diese bereitstellen oder die Spezifikationen der Hardwareschnittstellen offen legen damit die Linux-Community passende Treiber entwickeln kann.
 
WinnieW2 schrieb:
Mit einem Linux-Bootloader alleine ist es ja nicht getan, es werden ja auch Treiber für die ganzen Hardwarekomponenten benötigt.
Entweder der Gerätehersteller müsste diese bereitstellen oder die Spezifikationen der Hardwareschnittstellen offen legen damit die Linux-Community passende Treiber entwickeln kann.
Ich weiss nicht was ihr immer habt.
1. Man kann auf Linux aktiv teilnehmen und einen Treiber auch selber schreiben wenns mal wieder länger dauert, ist mindestens genauso sinnvoll wie auf einen WindowsClosedSourceTreiberUpdate zu warten.
2. Geht bei meiner Skylake x86 Hardware auch die Hälfte nicht auf Linux dank, genau scheiss Microsoft und ClosedSource Hardware Bussen und Komponenten die man als Linuxer sowieso schön reverse engineeren darf.
 
BiGfReAk schrieb:
Der Chip kann h265 en- und decodieren.
Wie ist denn die Leistung mit Handbrake ne Bluray in h265 (bzw x265) zu codieren? Theoretisch müsste die Leistung weit über die von Intel liegen, da die Chips ja auch den Videostream in den Handys beim Aufnehmen eines Videos direkt in h265 codieren können. Würde mich nicht wundern wenn der kleine Chip die großen Intel und AMD Modelle in der Hinsicht schlagen könnte. Und Nvidia mit NVENC zumindest in Sachen Qualität ebenso.
Naja.. x265 ist aber ein Softwareencoder, der Hardwareencoder müsste erstmal unterstützt werden. Sehe gerade, VCE wird ja dann auch endlich unterstützt.. dann hilft nur ein Vergleich zwischen QSV, NVENC, VCE und "ARMenc".
 
Da es den vermutlich nur für x86 oder mittlerweilen sogar x86_64 gibt, wohl eher nicht. Die Emulationsleistung hilft ja letztlich niemandem. :D

Regards, Bigfoot29
 
@Bigfoot29: x86_64 wird nicht kommen da Intel bereits klar gemacht hat dass sie ihre Patente verteidigen. Was angekündigt wurde ist ein Compiler der x86_64 Source entgegen nimmt und nach native ARM kompiliert. Angesichts des riesigen Erfolges von Windows on ARM wird das ein ganz großes Ding werden da bin ich da ist Mikrosoft sich sicher.
 
Das x86_64 -> native ARM halte ich für ein Gerücht. Das geht schon heute nicht so ohne Weiteres. Andere Befehlssätze kann man nicht einfach 1:1 umwandeln. Klar, ein "print 'hello world'" geht. Ein "1+1" geht auch. Aber spätestens, wenn man eine Funktion hat, die es auf System A nicht genauso auch auf System X gibt, wird es schwierig. Wie fängt man Spezialfälle von A ab, die es auf X nicht gibt?

Nicht umsonst sind die derzeit am weitesten verbreiteten High-Level sprachen welche, die Bytecode erzeugen. Also eine Art OS- und CPU-unabhängiger Mittelschicht. Das macht Java so und Python auch. Es gibt dann für die jeweilige Zielplattform einen eigenen Interpreter, der das zur Laufzeit in nativen Systemcode umsetzt. Das gab es zu C64-Zeiten schon. Keine Ahnung, wie der damals hieß. Damals war der Interpreter abzutippen, damit man anschließend obendrauf Code verwenden konnte, dessen Listings auch für Atari und Co verwendet werden konnten.

Regards, Bigfoot29
 
Zurück
Oben