#1
Posted 7 October 2010 - 17:21
Sedert de laatste driverupdate begint het afspelen van DVD's opeens supergoed te werken. Ik heb echter nog steeds een paar DVD's die niet goed afspelen, er is daar gebrek aan rekenkracht van de processor. De meest waarschijnlijke oorzaak is de libdvdcss, bij DVD's waar geen CSS op zit zie ik aanzienlijk lagere processorbelasting dan bij DVD's waar wel CSS op zit.
Ik probeer uit te vinden met welke compileropties libdvdcss gecompileerd wordt, wellicht valt er hier wat te tunen. Maar, redelijk onbekend met hoe de boel werkt, ik kijk naar het bestand packages/libdvdcss/libdvdcss_1.2.9.bb en daar is niet heel veel info uit te halen. Waar vind ik dit wel?
Re: Compileropties libdvdcss #2
Re: Compileropties libdvdcss #3
Re: Compileropties libdvdcss #4
Re: Compileropties libdvdcss #5
Posted 7 October 2010 - 22:14
Je zou -funroll-loops op zich kunnen gebruiken, het levert een paar procent winst op (misschien goed voor een DVD'tje dat net op de rand zit). De te gebruiken compileropties zijn dan '-O2 -funroll-loops'.
Re: Compileropties libdvdcss #6
Posted 7 October 2010 - 23:48
Na een avondtje prutsen: Standaard wordt inderdaad -O2 gebruikt. De critieke code zit in 1 lus. Om die te versnellen moet die opengevouwen worden. -funroll-loops helpt daarbij, en die zorgt inderdaad dat de compiler de lus openvouwt.
Dat is niet per definitie het geval. -funrull-loops (of de andere unroll flags) zitten niet voor niks in geen enkele -O variant.
Vooral als echt vrijwel alle tijd in een loop wordt doorgebracht (en er dus ook veel iteraties zijn), betekent dat in de regel dat uitschrijven juist een verslechtering geeft.
Om er echter goed snelheid mee te winnen zou de compiler de gegevens dan per 4 bytes uit het geheugen moeten laden (en weer wegschrijven) i.p.v. per byte. De compiler is niet slim genoeg om dat te doen, dit zou door handmatige optimalisatie bereikt moeten worden.
denk dat dat wel goed gaat, gcc genereert default 32bit aligned access op 32bit systemen.
Maar voor alle compiler flags geldt; benchmarken. Winst/verlies beredeneren is vrijwel onogelijk.
(zo blijkt op een embedded systeem vanwege trage storage juist vaak -Os de winnaar te zijn, compacte code, dus weinig inlinen, en zo veel mogelijk code hergebruiken, dus het tegenovergestelde van unloopen)
Re: Compileropties libdvdcss #7
Posted 8 October 2010 - 07:44
Re: Compileropties libdvdcss #8
Posted 8 October 2010 - 08:21
Of zitten er attributes voor byte alignment in de code?
gcc doet met -O2 wel een poging om de loops zelf op 32bit boundaries te krijgen (-falign-loops), dus daar zou het ook niet aan mogen liggen.
Maar, als je de machinecode hebt kunnen vergelijken, heb je dus ook 2 versies die je kan benchmarken?
Re: Compileropties libdvdcss #9
Posted 8 October 2010 - 11:53
In principe kan ik beiden benchmarken, maar het is even lastig een goede benchmark te verzinnen. Met de DVD die ik heb storen beiden, ik zou idealiter een benchmark moeten hebben die het aantal MB/s wat ontcijferd kan worden kan meten. Of een bepaalde vaste hoeveelheid gegevens ontcijfert, zodat de tijd gemeten kan worden.
Re: Compileropties libdvdcss #10
Posted 8 October 2010 - 12:04
Momenteel leest hij zo te zien gewoon het eerste blok, en probeert dat te decrypten.
daar kan je waarschijnlijk nog geen tijdverschil in ontdekken. Maar met meerdere blokken zou er toch een verschil zichtbaar moeten zijn, als het echt een verbetering is.
btw, zit even in de code te neuzen, bedoel je de while loop in _dvdcss_unscramble?
Daarvan is compiletime, en zelfs runtime, niet bekend hoeveel iteraties die heeft.
In dat geval zal volgens de specs -funroll-loops niet ingrijpen. Of heb je het over een andere loop?
Re: Compileropties libdvdcss #11
Posted 8 October 2010 - 13:19
Als de CSS decoder in een gstreamer pipeline zit, kun je die misschien ontkoppelen naar een losse thread. De VU heeft een dual-threading CPU, maar gstreamer draait standaard zoveel mogelijk in een enkele thread. Met twee threads kan hij ongeveer 70% extra performance halen t.o.v. single threaded.
Als je handmatig een pipeline opgeeft (je kunt een DVD dan ook afspelen van de commandline als E2 niet draait), zou je dit kunnen proberen.
Re: Compileropties libdvdcss #12
Re: Compileropties libdvdcss #13
Posted 8 October 2010 - 14:04
er is een csstest, die tot benchmark zou kunnen worden omgebouwd.
Momenteel leest hij zo te zien gewoon het eerste blok, en probeert dat te decrypten.
daar kan je waarschijnlijk nog geen tijdverschil in ontdekken. Maar met meerdere blokken zou er toch een verschil zichtbaar moeten zijn, als het echt een verbetering is.
Hmmm... interessant. Ik zal 'ns kijken of ik daar iets mee kan.
btw, zit even in de code te neuzen, bedoel je de while loop in _dvdcss_unscramble?
Daarvan is compiletime, en zelfs runtime, niet bekend hoeveel iteraties die heeft.
In dat geval zal volgens de specs -funroll-loops niet ingrijpen. Of heb je het over een andere loop?
Dat is inderdaad de betreffende while-loop. Dus lus heeft wel degelijk een vast aantal iteraties omdat the blokgrootte een constante is (gedefinieerd in dvdcss.h). GCC heeft prima door dat het aantal iteraties constant is, en verwijdert dan ook netjes de loop-test tussen de verschillende uitvouwingen.
Also tagged with one or more of these keywords: VU+DUO
Dateiformat .m4k nicht lesbar.Started by Gummivernichter, 28 Mar 2020 Vu+Duo, m4k, Dateiformat, OpenPLi |
|
|||
Webif benaderen via telefoonStarted by Tw-er, 15 Feb 2017 Vu+Duo |
|
|||
Autotimer goneStarted by jort38, 9 Feb 2016 VU+DUO |
|
|||
Stream vanaf http://www.watchdartsforfree.tk/ naar Vu+duoStarted by wieckbud1, 29 Nov 2015 VU+Duo |
|
|||
Toch geen clean installStarted by Alain_sat, 15 Jan 2015 VU+Duo |
|
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users