12 replies to this topic

[Zuppelan]

Hallo,

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?

[pieterg]

dat bepaalt libdvdcss zelf, ik neem aan dat het een autotools projectje is, in dat geval configure.ac(/.in) of in de Makefile.am.
Als ook daar geen custom CFLAGS in staan, is het gewoon -O2

[Zuppelan]

Oke, dan ga ik eens kijken of ik een compiler geinstalleerd krijg en zelf even prutsen, wellicht dat het lukt een bibliotheek te krijgen die wel snel genoeg is.

[pieterg]

ik denk eerlijk gezegd niet dat je meer dan een paar procent zult kunnen optimaliseren.
css is gewoon een vrij zware taak.

[Zuppelan]

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. 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.

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'.

[pieterg]

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)

[Zuppelan]

lk heb de machinecode ernaast gehad: Openvouwen betekent dat ongeveer 3 assemblerinstructies minder per iteratie uitgevoerd moeten worden. En het valt niet mee, GCC leest ook bij een opengevouwen lus effectief 1 byte per keer uit uit geheugen. Dan is er dus geen 32-bit alignment meer. Met handmatige optimalisatie kan hier wat bereikt worden.

[pieterg]

ok, mipsel is flink sub-optimaal (of dat aan gcc ligt of aan de instructieset durf ik niet te zeggen), maar het lijkt mij heel vreemd als gcc default byte alignment zou gebruiken op mips(el).
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?

[Zuppelan]

De MIPS-instructieset is behoorlijk kreupel (heb er een hekel aan), maar de oorzaak ligt hier bij GCC. De C-broncode werkt per byte. Als je 4 maal uitvouwt kan je de leesinstructies combineren en in plaats van een byte per keer 4 byte per keer uit uit het geheugen lezen. Dat is een optimalisatie die GCC niet uitvoert.

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.

[pieterg]

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.

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?

[MiLo]

Even een losse flodder, die ik bij DTS ook al eens geprobeerd heb.

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.

[Sjaaky]

De dvd speler gaat om gstreamer heen.

edit: of bedoel je dat het via gstreamer kan puur om het css gedeelte te testen?

[Zuppelan]

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.