Neuere Version von Kodi funktioniert nicht mehr auf altem Prozessor - Spezielles Komplilieren möglich?

cabriofahrer

Well-Known Member
Auf einem alten Rechner mit einem Athlon 64 konnte ich immer problemlos Kodi bis einschließlich Version 17.6 betreiben. Doch die neueste Version in den Packages oder kodi-devel funktionieren nicht mehr:

Code:
$ kodi

******************************************************************
* FATAL ERROR:                                                   *
* This OpenCV build doesn't support current CPU/HW configuration *
*                                                                *
* Use OPENCV_DUMP_CONFIG=1 environment variable for details      *
******************************************************************

Required baseline features:
SSE - OK
SSE2 - OK
SSE3 - NOT AVAILABLE
OpenCV(3.4.1) Error: Assertion failed (Missing support for required CPU baseline features. Check OpenCV build configuration and required CPU/HW setup.) in initialize, file /wrkdirs/usr/ports/graphics/opencv-core/work/opencv-3.4.1/modules/core/src/system.cpp, line 487
Crash report available at /home/susy/kodi_crashlog-20201029_084417.log

Die Fehlermeldung sagt klar was fehlt: Der Prozessor hat kein SSE3. Das Problem scheint aber nicht das Paket Kodi zu sein, sondern OpenCV.
Meine Frage jetzt: Kann OpenCV speziell kompiliert werden, dass es auf Prozessoren ohne SSE3 läuft? Schließlich hatte Kodi in der Vergangenheit mit älteren Versionen von Packages funktioniert.

Alternativ könnte ich natürlich mit Poudriere die gesamten Packages für das System von einem älteren Portstree kompilieren, die Option gefällt mir aber nicht, weil ich sonst nie mehr ein pkg upgrade machen könnte.
 
Du könntest mal versuchen in der /etc/make.conf die Option CPUTYPE=athlon64 zu setzten und dann graphics/opencv aus den Ports zu bauen. EDIT: Dass die Option wirksam ist siehst Du an den Compilerausgaben, da steht dann irgendwo -march=athlon64.
 
Ich habe festgestellt, dass opencv gar nicht installiert ist, sondern opencv-core. Zudem kann man im Portverzeichnis von multimedia/kodi ein make config machen und da kann man das Kreuz von sse3 entfernen. Das habe ich getan und dann ein make deinstall und ein make reinstall. Trotzdem wieder die gleiche Fehlermeldung. Ich habe hier noch eine Frage zu

Du könntest mal versuchen in der /etc/make.conf die Option CPUTYPE=athlon64 zu setzten und dann graphics/opencv aus den Ports zu bauen. EDIT: Dass die Option wirksam ist siehst Du an den Compilerausgaben, da steht dann irgendwo -march=athlon64.

Ist das denn nötig, wenn der Prozessor, auf dem man kompiliert, ein Athlon64 ist? Sollte ich vielleicht mal versuchen, kodi mit allen Abhängigkeiten, also inkl. opencv-core mit CPUTYPE=athlon64 zu kompilieren?
 
Ist das denn nötig, wenn der Prozessor, auf dem man kompiliert, ein Athlon64 ist?
Nein, nur die Architektur.

Die Frage ist, ob kodi oder opencv ohne SSE3 noch zum Ziel führen bzw. ob alles läuft wie gewünscht.
Sonst bist du auf die letzte Version ohne SSE3-Pflicht angewiesen, hinsichtlich kodi und opencv.
 
Die Frage ist, ob kodi oder opencv ohne SSE3 noch zum Ziel führen bzw. ob alles läuft wie gewünscht.
Theoretisch sollte es das tun. Wenn ich richtig verstanden hab, war das nur eine allgemeine Performance-Optimierung die man nun aber per default macht, weil "keiner" mehr CPUs ohne SSE3 hat.
Funktionieren tut es auch so. Nur eben ohne diese Optimierung. Es läuft also quasi wie vorher.
 
Also ich habe mal versucht, mit poudriere Packages ohne SSE3 zu kompilieren, indem ich in /usr/local/etc/poudriere.d/ eine athlon64-make.conf mit dem Inhalt CPUTYPE=athlon64 erstellt habe:

Code:
# more /usr/local/etc/poudriere.d/athlon64-make.conf
CPUTYPE=athlon64
#

Danach auf dem Zielrechner alle Pakete gelöscht und die von poudriere installiert. Dann alle anderen benötigten Packages. Es hat nichts gebracht. Ich weiß jetzt nicht, ob die athlon64-make.conf nicht beachtet wurde oder ob CPUTYPE=athlon64 nichts bewirkt.
Zum Glück hatte ich auf einem anderen Rechner noch eine ältere Installation, von der ich mittels pkg create -a ein Backup machen konnte. Diese Packages habe ich jetzt installiert und Kodi 17.6 funktioniert wunderbar. Durch das Einbauen einer alten Nvidia Geforce 210, die VDPAU unterstützt, habe ich mit dem alten Prozessor sogar nur eine Belastung von 12-25%!
Wenn man also eine Graka hat, die hardwaremäßig Video dekodiert und man dann nur noch eine so geringe Prozessorbelastung hat, wozu braucht man dann für Kodi SSE3 oder mehr als einen Prozessorkern?
Umso unverständlicher erscheint es mir, dass die Entwickler einfach hergehen und die Unterstützung für CPU's ohne SSE3 kappen.

Natürlich kann ich jetzt an diesem System keine Updates mehr vornehmen oder neuere Packages installieren, die alte Abhängigkeiten updaten wollen, deswegen ärgert mich das Ganze so sehr...
 
Durch das Einbauen einer alten Nvidia Geforce 210, die VDPAU unterstützt, habe ich mit dem alten Prozessor sogar nur eine Belastung von 12-25%!
Eben, das ist das beste theoretische Beispiel. VDPAU ist ein HW-Feature, wie SSE3. Stell dir vor, deine CPU hat nur einen Kern, der beim Abspielen von z.B. HEVC irgendwo bei 96%-98% Last schwitzt und dadurch ruckelt das Video sogar beim Abspielen. Das Team rund um kodi könnte jetzt zur nächsten Version vdpau voraussetzen - oder eben nicht. In beiden Fällen kriegst das video nicht flüssig abgespielt, wenn deine HW vdpau nicht bringt.

Was genau jetzt wegen SSE3 ist, hat Andy ja schon angedeutet. Irgendwo irgendwie findest du z.B. immer noch einen Meckerpeter, weil i386 gekickt wurde. ;)

Wenn die CPU älter als 5-6 Jahre ist, macht doch Kompilieren eh keinen Spaß mehr?

Hast du dir mal https://libreelec.tv angeschaut?
 
Also ich habe mal versucht, mit poudriere Packages ohne SSE3 zu kompilieren, indem ich in /usr/local/etc/poudriere.d/ eine athlon64-make.conf mit dem Inhalt CPUTYPE=athlon64 erstellt habe:

Code:
# more /usr/local/etc/poudriere.d/athlon64-make.conf
CPUTYPE=athlon64
Das ist nicht der übliche Ort für die poudriere make.conf.
 
Die Überlegung kann aber auch noch eine ganz andere sein.

Die Hardware ist alt und das man in solche Probleme läuft wird eher zunehmen als abnehmen. Also selbst wenn man das jetzige Problem noch irgendwie hingefrickelt kriegt, bedeutet das ja nicht das man dann für die nächsten Jahre Ruhe hat.

Auf der anderen Seite kriegt man für nen schmalen Taler schon Kleinstcomputer wie dem Raspberry Pi, der nicht nur wunderbar mit KODI funktioniert, sondern auch passiv gekühlt werden kann (Geräuschentwicklung!; für nen Videoplayer nicht ganz uninteressant) und eine dramatisch geringere Leistungsaufnahme hat als ein typischer Athlon Rechner. Selbst die sparsamste Athlon64-CPU genehmigt sich unter Last bis zu 35 Watt (und das sind dann schon die sparsamen Mobilvarianten). So ein ganzer Raspberry Pi braucht je nach Modell ein bisschen unterschiedlich, aber es sind immer deutlich unter 10W (und damit ist der ganze Raspberry gemeint; und nicht nur die CPU).

Gut das sind immer Maximalwerte. Und je nach Anforderung usw. können die anders ausfallen und sind damit nicht direkt vergleichbar. Aber es zeigt schön in welchen Größenordnungen wir uns da bewegen.

All das nährt ja vielleicht die Überlegung, ob es sich überhaupt noch lohnt für den Zweck den Athlon beizubehalten.
 
Ob sich etwas lohnt oder nicht ist zunächst mal auch sehr subjektiv. Ich hatte mal ein Raspberry Pi3 in den Händen und installierte auf dem vorhandenen System Kodi mittels apt-get install kodi, was auch funktionierte. Danach die ZDF 2016 Mediathek App. Letztendlich bekam ich aber beim Anklicken einer Sendung nur ewig einen drehenden blauen Kreis zu sehen und es funktionierte letzendlich nicht.
Der Grafikchip hat unter FreeBSD keine 2D/3D-Beschleunigung und für NetBSD, wo Hardwarebeschleunigung unterstützt wird, ist Kodi bei Version 15 stehengeblieben. Hingegen funzt Kodi 17.6 auf einem Athlon64 wunderbar. Also was loht sich hier nicht?
Ich würde mal ganz generell und grob sagen, dass eine Hardware sich nicht mehr lohnt, wenn sie mit einem Programm oder den Programmen, die man benutzen will, wesentlich überlastet ist. Das ist hier nicht der Fall, wie ich dargelegt habe.
Können wir also bitte beim Thema bleiben, wie man ein neues open-cv ohne SSE3 hinkriegt?
Wie gesagt, mit alten Packages auf dem Stand von Kodi 17.6 kann ich es ja einfach so lassen, ohne eben upzudaten. Wenn man sonst nichts anderes mit dem Rechner anfangen will, kann man es auch dabei belassen, da kann sogar die FreeBSD-Version irgendwann EOL sein. Ich würde aber lieber neuere Packages haben, deshalb nochmal: opencv-core ohne SSE3?
 
Ich kompiliere OpenCV 3.4.1 unter Windows problemlos mit CPUBaseLine=SSE2. Das funktioniert hier auch. Deshalb denke ich, dass es auch unter FreeBSD gehen sollte. Das muss man nur passend in den pourdiere build einbauen. Ih hab hier nur gerade kein BSD zur Hand um das auszuprobieren.

Das ist der Knackpunkt.
 

Anhänge

  • Baseline.PNG
    Baseline.PNG
    44,2 KB · Aufrufe: 163
Ich kompiliere OpenCV 3.4.1 unter Windows problemlos mit CPUBaseLine=SSE2. Das funktioniert hier auch. Deshalb denke ich, dass es auch unter FreeBSD gehen sollte. Das muss man nur passend in den pourdiere build einbauen. Ih hab hier nur gerade kein BSD zur Hand um das auszuprobieren.

Es müsste nur jemand sagen können, wo man es genau in die Makefile des Ports eintragen muss, dann würde ich es auch lokal kompilieren können. Und in Bezug auf poudriere kann ich mir vorstellen, dass man eben dort genauso die Makefile im Portstree der jeweiligen Jail modifizieren muss. Darf ich mal fragen, welches Interesse Du am Kompilieren von OpenCV mit SSE2 (unter Windows) hast?
 
Unter Windows hab ich beruflich einige Projekte mit OpenCV am laufen. Da hab ich teilweise noch T7400 welche auch kein SSE3 haben ;)

EDIT: Doch SSE3 haben die ..... warum war das dann SSE2? *Kopfkratz* :confused:
 
Ob sich etwas lohnt oder nicht ist zunächst mal auch sehr subjektiv.
Klar. Ich hab ja nicht gesagt, das Du es so machen sollst oder machen musst, sondern eher als Gedanken ins Spiel gebracht.

Also was loht sich hier nicht?
Naja. Die Chance ist größer, das Hardwarebeschleunigungsunterstützung in eines der BSDs wandert (die Hauptarbeit ist ja im Prinzip schon gemacht) als das es in absehbarer Zeit noch auf dem Athlon läuft.

Wie gesagt, Die Überlegung dahinter ist ja, das solcherlei Probleme eher zunehmen werden. Athlon64-Systeme sind halt kaum im Einsatz. Das bedeutet
1.das Bugs nicht so leicht auffallen und es
2.auch kaum Interesse daran gibt solche Bugs zu fixen

Man kann das ja auch alles doof finden und so. Aber so ist die Welt nun mal. Und jetzt kann man sich überlegen: Nutzt man das Wissen um diese Mechanismen um die Wahrscheinlichkeit für Probleme zu reduzieren oder schaltet man auf stur und "verschwendet" seine Energie daran da irgendwie doch den eigenen Willen durchzusetzen.
Ich will das auch gar nicht werten oder so. Das muss jeder selbst wissen.
Ich wollte das halt nur aufzeigen.
Also keinen Grund gleich in Schnappatmung zu verfallen. :-)

Der Grafikchip hat unter FreeBSD keine 2D/3D-Beschleunigung
Keine Ahnung wie flexibel Du bist. Aber unter Linux ist das kein Problem. KODI unter Linux sieht auch nicht anders aus als KODI unter BSD. Von daher ists erst mal egal was darunter werkelt.
Kann man ja auch erst mal als Übergangslösung nehmen bis Hardwarebeschleunigung unter FreeBSD und Co verfügbar ist.

Können wir bitte beim Thema bleiben, wie man ein neues open-cv ohne SSE3 hinkriegt?
Hast Du denn mal die (Poudiere-)Logs gecheckt, ob die Compileroptionen korrekt gesetzt werden?
Also im Prinzip die Frage, die schon im zweiten Posting gestellt wurde und Du aber immer noch nicht geschafft hast zu beantworten. :-)
 
Hab gerade ein frisches Freebsd 12.2-RELEASE in einer VM installiert und kodi mit pkg installiert. Leider inst in den Port das Flag CPU_BASELINE nicht zu finden.

Code:
root@fbsd:/usr/ports # fgrep -rin cpu_baseline *
root@fbsd:/usr/ports #

Deshalb muss man das /usr/ports/graphics/opencv/Makefile anpassen
Code:
....
                -DWITH_GDAL:BOOL=OFF \
                -DWITH_GPHOTO2:BOOL=OFF \
                -DWITH_LAPACK:BOOL=OFF \
                -DWITH_ITT:BOOL=OFF \
                -DCPU_BASELINE=SSE2 \
                -DCPU_DISPATCH=SSE2
...

Dann ein "make reinstall BATCH=yes" und er baut es neu. (aber halt alles wass von opencv anhängt). Es ist aber immer noch sauber installiert :) Der patch ist halt beim nächsten Update weg ......
 
Hast Du denn mal die (Poudiere-)Logs gecheckt, ob die Compileroptionen korrekt gesetzt werden?
Also im Prinzip die Frage, die schon im zweiten Posting gestellt wurde und Du aber immer noch nicht geschafft hast zu beantworten. :-)

Weil mir die Angaben leider nicht genau genug sind. Ich bin mit poudriere noch sehr unerfahren. Genauer Pfad der Logs? Die Frage interessiert mich natürlich selbst, wie es denn mit der make.conf gelaufen ist.

Naja. Die Chance ist größer, das Hardwarebeschleunigungsunterstützung in eines der BSDs wandert (die Hauptarbeit ist ja im Prinzip schon gemacht) als das es in absehbarer Zeit noch auf dem Athlon läuft.

Über diese frohe Botschaft in der Zukunft werde ich mich dann freuen. In der Zwischenzeit bis jetzt gerade habe ich mir u.a. noch das Ende eines Films, ein Kapitel einer Serie und die ZDF-Nachrichten angeguckt. Später mehr. Das hat sich gelohnt und wird sich noch monatelang lohnen...

@schorsch_76 , vielen Dank, das hört sich sehr gut an! Allerdings wird ja nicht opencv, sondern opencv-core als Abhängigkeit von Kodi installiert. Gehe ich also richtig in der Annahme, dass komplette Lösung wäre:

1. pkg delete -a
2. Kompilieren von opencv mit allen Abhängigkeiten (opencv-core wäre ja darunter) nach Deiner Anleitung
3 Installieren von Kodi und aller anderen benötigten Packages mittels pkg install
 
Allerdings wird ja nicht opencv, sondern opencv-core
Die beiden Ports sind fast identisch.
Der Port opencv-core verweist sogar auf opencv
Deshalb ist das Makefile auch so klein. Die meiste Arbeit macht der opencv-Port. Da stehen dann auch schon cmake-Argumente drin, wo Du 'schorchs' Kram einfach anhängen kannst, wo beschrieben.
Das müsste eigentlich schon reichen.
 
Genauer Pfad der Logs?
Das hängt so ein bisschen davon ab, wie Du Dein Poudriere konfiguriert hast.
Im Poudriere-Basis-Verzeichnis sollte es ein Unterverzeichnis namens logs geben.

Ich bin mit poudriere noch sehr unerfahren.
Im Prinzip brauchst Du für einzelne Packages nicht zwingend ein Poudriere. Du kannst auch einfach ein Jail erstellen und darin ein normales FreeBSD mit PortsTree fahren und dann alles so machen, wie Du es auch bei einem nativen FreeBSD machst.
Packages baust Du dann aus den Ports einfach mit make package und erhältst dann eine .txz-Datei die Du einfach auf die entsprechende Zielmaschine bringst und dort mit pkg add /path/to/mypackage.txz installierst.

Ist dann zwar alles etwas Quick&Dirty und nicht ganz so komfortabel in der Benutzung, aber funktioniert und kommt ohne spezielles Know-How und Poudriere-Setup aus.
 
@cabriofahrer : Ja genau. Ports laden, patchen und opencv bauen.
Dann den Rest nachziehen. Ein ZFS dataset für /usr/local ist sicher hilfreich ;)

Die ganzen Optionen sind alle im opencv Port gesetzt. Ich hab nur die 2 Cpu Optionen angehängt.
 
Zurück
Oben