Verstanden. Bei NV12 sinds dann quasi w*h*12bit pro frame, also ~ 3MB
Gruß Andreas
sunxi-vdpau WIP (ehemals interlaced branch)
-
-
Ich habe mir mal einen Kernel mit höherem ve_mem kompiliert, zumindestens hoffe ich das. Kann man irgendwie kontrollieren wieviel Speicher zugewiesen außer die Differen vom eigentlichen Hautpspeicher zu angezeigtem Hauptspeicher zu berechnen (da stecken sicher auch noch ein paar Fehlerquellen drin). Wie sieht es mit dem G2D Speicher aus, der wird ja auch vom einen anderen Treiber (fbturbo?) benutzt, kann/sollte man den auch auch ändern?
-
Wenn du CMA aktiviert hast, sehe ich keinen Eintrag, der das loggt. Da müsstest du dir eine Zeile einfügen und den Wert ausgeben lassen. Aber wenn du ve_size setzt, würde ich mal davon ausgehen, dass das passt.
G2D braucht auch Speicher, das kümmert sich um das OSD. Aber wieviel, kann ich dir nicht sagen. Irgendwo gabs mal einen Kommentar von ssvb der mit dem G2D Speicher zu tun hatte ... Entweder als commit message oder im wiki oder auf der ml...
Gruß Andreas -
hm bei cubiuntu ist das cedarx Modul fest in den kernel gebaut
den ganzen kernel neu zu bauen ist blöd da könnte man sich ja auch fast mit dem arch beschäfftigen
naja der ferienjob ist endlich rum und bis mitte Oktober ist ja noch ein bisschen zeit
auf ein arm device gehört einfach ARCH das läuft meistens am besten (bisher meine Erfahrung)
debian zickt meistens rum oder hat sonst irgendwelche Krankheiten
-
auf ein arm device gehört einfach ARCH das läuft meistens am besten (bisher meine Erfahrung)
Nicht nur auf einem ARM Device. Auf x86 macht es sich auch sehr gut.Speziell im Fall des Cubieboard2 komme ich aber nicht wirklich weiter mit ArchARM. Ich habe das weiter oben schonmal erwähnt.
Und da das ganze Zeug keine wirklichen Error-Meldungen erzeugt macht es auch keinen Spaß dort weiterzutesten. -
ja ich hatte schon mal angefangen mich mit arch auf dem cubie zu beschäftigen aber das ist echt pervers
es gibt 2 dokus wie es laufen soll diese sind aber veraltet und gehen nicht mehr :-/ich warte grade auch 2x 6TB red dann wird die 4 TB red für den vdr frei dann fliegt das debian da auch runter
und es kommt ein arch draufdas behandeln von offensichtlichen Bugs in debian ist einfach zum kotzen
wenn die Programmierer der software eingestehen das es ein wirklich mieser bug ist und der paketierer meint es bestehe kein problem
ABER alle anderen distrie updaten nur debian nicht :-/wobei es erwiesen ist das das problem gravierend ist und den server kicken kann naja dann sollte man sich wohl von debian verabschieden
ubuntu server ist auch ok aber ich HASSE eigentlich ubuntu
ich hatte lange zeit sabayon im Einsatz aber fürs cubie siehts da schlecht aus von daher ist arch die erste Wahl wenn man sein netzt fast homogen haben will
yosemite + arch
wobei mir yosemite only am liebsten wäre nur die dvb-Treiber und der beschränkte vda-decoder
wobei der vdr seit mavericks ja wieder baut und prinzipiell mit sd fernsehen ja auch geht mittels streamdev oder mcli per netceiver
-
Wenn du CMA aktiviert hast, sehe ich keinen Eintrag, der das loggt.
Mein Kernel (danand latest) scheint CMA deaktiviert zu haben, damit zieht auch die Änderungen von ve_size nach dem #ifdef CONFIG_CMA nicht.
Man erkennt es übrigens im dmesg, war nur blind:
Hat jemand eine Idee wo man ve_size ändern kann wenn CMA deaktiviert ist? sehe sonst keine Definition in den Sourcen...EDIT: Selbst gefunden, 2 Einträge für ve_size in arch/arm/plat-sunxi/core.c probiere es jetzt mal mit 144M (SZ_128M + SZ_16M)
-
Ich weiß echt nicht was ihr gegen Debian habt - fahre seit Jahren gut damit.
Anyway, ich hab gestern ein bischen testen können - der entscheidende Punkt aus meiner Sicht ist nicht die Distribution sondern, ffmpeg/libav.
Mit ffmpeg 1.2 .. 2.3 funzt HD gut, aber SD bleibt dunkel - bei libav hatte ich mit 0.8.15 Glück (9.16 blieb HD dunkel, mit der bei aRuntu ich glaub 0.8.13 ging HD in Zeitlupe).
Dieses ganze ffmpeg / libav Gedöns ist wirklich nervig, aber wohl entscheidend.Auflösung: 1980x1080 @50Hz
softhddevice git : max_refs = 9
vdr 2.1.6
ve_mem : 140 MB reserved
--> Kernel 3.4.102-ct_r2+Damit funktioniert aktuell ServusTV mit OSD - beim Umschalten zu 720p kann es zum Absturz kommen.
Edit: passierte ein/zwei Mal vernachlässigbarBisher ganz brauchbar, gut deinterlacing auf SD wäre schön - übrigens mit cubietruck.
-
ich schaue mal wenn die sd-karte fertig geimaged ist ^^was beim cubiuntu installiert ist libav / ffmpeg
Zitatve_mem : 140 MB reserved
gut das es mit 140 MB geht
hast du die surfaces im softhddevice reduziert ???
falls nein kannst du es ja noch mal mit 9 probieren das ging recht gut -
auch mal schön so ein verregneter Bastelnachmittag. Den interlaced branch habe ich jetzt mit 1080p am laufen. Meine Einstellungen sind:
in sunxi_cedar.c: ve_size = 150 * SZ_1M;
in fex bin: fb0_framebuffer_num = 3
und in uEnv.txt: extraargs=disp.screen0_output_mode=1920x1080p50 sunxi_fb_mem_reserve=64
Es geht SD, 720p und 1080i. Getestet habe ich ServusTV. Bei ruhigem Bild ist es sehr gut. Kommt aber Bewegung rein sieht man das Deinterlacing nicht läuft.
Mit
Codeecho 'f1e000a0' > /sys/devices/virtual/misc/sunxi-dbgreg/rw/read
wollte ich mal schauen wie die Register des Deinterlacers gesetzt sind. Antwort ist aber nur 0x0.Ich pack hier mal messages hin
Obwohl im fexscript pll4 = 300 steht kommt in dmesg
CodeMali: mali clock set completed, clock is 288000000 HzGruss zille
-
Zitat
auch mal schön so ein verregneter Bastelnachmittag.
so ein mist bei mir regnets gar nicht ^^nur das rumpsteak liegt noch so komisch im Magen und macht Träge
-
Obwohl im fexscript pll4 = 300 steht kommt in dmesgCodeMali: mali clock set completed, clock is 288000000 Hz
Das ist ein Punkt über den ich auch gerade gestolpert bin, zumal hier cubiuntu andere Werte zu verwenden scheint.
Siehe auch die Diskussion hier: https://groups.google.com/foru…/HRT9ULqMS88/zqwHboElvDoJ -
Zitat
Obwohl im fexscript pll4 = 300 steht kommt in dmesg
Source code
1
Mali: mali clock set completed, clock is 288000000 HzInteressant, hab mal hier geschaut:
[ 18.564041] mali: use config clk_div 3
[ 18.567885] mali: clk_div 3
[ 18.568897] Mali: mali clock set completed, clock is 320000000 Hz
[ 18.577802] mali: use config clk_div 3
[ 18.580515] mali: clk_div 3
[ 18.591379] Mali: mali clock set completed, clock is 320000000 Hz
[ 18.742723] Mali DRM initialize, driver name: mali_drm, version 2.1
[ 18.754991] [drm] Initialized mali_drm 2.1.1 20101111 on minor 0
[ 18.764495] Mali DRM initialize, driver name: mali_drm, version 2.1
[ 18.770179] [drm] Initialized mali_drm 2.1.1 20101111 on minor 1script.bin hatte ich von aRuntu - installiert auf der SSD ist CTdebian jessie.
-
Ich habe noch massive Probleme mit dem Sound, musste da jemand (speziell CT) etwas manuell machen? Habe nur "schnarren" über HDMI.
Habe hdmi.audio=1 gesetzt (weil zum Boot-Zeitpunkt nicht zwangsläufig was per EDID erkennbar ist), und wenn ich softhddevice per "-a hw:3,0" starte oder mir auch die Karte "3" per asoundrc als default setze kommt nur besagtes schnarren. -
hm ich starte das softhd-device nur mit
Code-P"softhddevice -f"ich hab einen lustigen Effekt mit einer 8GB micro-sd karte
Code
Alles anzeigenroot@linaro-ubuntu-desktop:~# df -h Filesystem Size Used Avail Use% Mounted on /etc/mmcblk0p2 23G 9.7G 13G 45% / devtmpfs 381M 4.0K 381M 1% /dev /dev/root 23G 9.7G 13G 45% /var/log.hdd ramlog-tmpfs 477M 12M 466M 3% /var/log tmpfs 477M 8.0K 477M 1% /tmp none 96M 828K 95M 1% /run none 5.0M 0 5.0M 0% /run/lock none 477M 2.7M 475M 1% /run/shm /dev/mmcblk0p1 14M 5.0M 9.0M 36% /media/815B-BF7D /dev/mmcblk0p2 3.6G 3.3G 182M 95% /media/764506f2-95cd-48c9-8cde-a09534ff147e
df meldet mir das root 23G groß wäre und mit 9,7 belegt wäre das ist auch so
Die 23 gb gehen auch drauf / habe mal ne fette mov drauf kopiertevtl ist das eine runtergelabelte 32GB karte und das cubieboard tested wieviel die karte kann oder halt keine Ahnung wtf
-
mit der asound.conf von hier (von Fritz)
[WiP] Cubieboard: softhddevice über vdpau?
funktioniert die Soundausgabe auf dem CT. (softhddevice -a sunxihdmi)
-
Hallo,
muss mich mal wieder einschalten
den ganzen kernel neu zu bauen ist blöd da könnte man sich ja auch fast mit dem arch beschäfftigen
Naja, wenn du die Entwicklungsumgebung irgendwo fürs Cross-Building mal hergerichtet hast, geht das ruckzuck. Nur auf dem Device selber dauerts halt.
Hat jemand eine Idee wo man ve_size ändern kann wenn CMA deaktiviert ist? sehe sonst keine Definition in den Sourcen...
EDIT: Selbst gefunden, 2 Einträge für ve_size in arch/arm/plat-sunxi/core.c probiere es jetzt mal mit 144M (SZ_128M + SZ_16M)
Du kannst einen Kernel Parameter setzen: sunxi_ve_mem_reserve=140 Der greift dann, wenn CMA deaktiviert ist.Ich weiß echt nicht was ihr gegen Debian habt - fahre seit Jahren gut damit.
Fullack. Auf all meinen Rechnern uns SoCs läuft Debian und ich hatte bisher nie Probleme damit. Der armhf Port läuft sorgenfrei.Anyway, ich hab gestern ein bischen testen können - der entscheidende Punkt aus meiner Sicht ist nicht die Distribution sondern, ffmpeg/libav.
Das würde bedeuten, die Probleme hätten mit libvdpau-sunxi nichts zu tun, sondern in erster Linie mit softhaddevice bzw. den Paketversionen von ffmpeg/libav der Distribution.
MitCodeecho 'f1e000a0' > /sys/devices/virtual/misc/sunxi-dbgreg/rw/read
wollte ich mal schauen wie die Register des Deinterlacers gesetzt sind. Antwort ist aber nur 0x0.
Wo hast du die Adresse her? Vielleicht kannst du wg. deinterlacer mal diesen Branch testen: https://github.com/rellla/libvdpau-sunxi/tree/WIP/deint
Das ist ein Punkt über den ich auch gerade gestolpert bin, zumal hier cubiuntu andere Werte zu verwenden scheint.
Siehe auch die Diskussion hier: https://groups.google.com/foru…/HRT9ULqMS88/zqwHboElvDoJ
Mali hat erstmal mit libvdpau etc. gar nichts zu tun und könnte auch deaktiviert werden. Es ist nur für 3D zuständig.Und generelle Frage: Warum benutzt ihr alle eigentlich verschiedene Kernel und nicht den "Original" von linux-sunxi?
Gruß Andreas
-
Hallo rell
ZitatWo hast du die Adresse her?
http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf
ZitatMali hat erstmal mit libvdpau etc. gar nichts zu tun und könnte auch deaktiviert werden. Es ist nur für 3D zuständig.
Ja, stimmt. Aber PLL4 bestimmt auch die Clock der VE. Wenn Mali falsch taktet ... welchen Takt hat die VE?
Jetzt muss ich überlegen ob ich heute abend den neuen Branch teste oder das schicke zitieren lerne!?
Gruss zille.
-
wie ist das gemeint ???
Na ich verliere halt den Überblick über die ganzen verschiedenen zusammengewürfelten Images (Cubiez, Cubiuntu, ...) und die verpackten Kernels (danand, igor_pec.., -ct-..), bzw. ich hatte ihn noch nie. Hab mich noch nie damit befasst und wollte es auch nicht tun.
Ich gehe lieber den make-it-yourself Weg, und baue mir den Kernel selbst aus den Original-Quellen bzw. benutze die Nightlies von linux-sunxi.org, da ich dann weiß, was drin ist und sich mir nicht erschließt warum mögliche zusätzliche Patches von Dritten nicht in diesen Kernel bzw. auf die Mailing Liste wandern, wenn sie sinnvoll sind. Auch das Root-Filesystem ist wiederverwendbar, wenn es einmal auf dem Rechner liegt.
Daher meine Frage, warum die kernels und fex-files hier so wild gemischt zu sein scheinen und jeder "Distributor" sein eigenes Süppchen kocht. So sieht es jedenfalls für mich aus (- ohne näher hingeschaut zu haben).
Gruß
Andreas
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!