PowerPC - Linux - Ati

[blueint]

Framtidens lösning? Project VGA samt den saftigare Open Graphics Project.

[Jolles]

Håller med dig om bsd där, men är en grym grund på en server! Efterssom så mycket öppen mjukvara online finns för att kompillera själv så vil jag inte gå miste om det, bara för att det kan vara rena döden att få det att kompillera på en debian/ubuntu-burk, så 90-tal eller ej - det funkar!
Bland det första jag lärde mig i linuxmiljö var att kompillera min kärna (genom telefon-kontakt med brorsan) då i RH 5.4, på den vägen är det hehe

blueint: definitivt min melodi

[Glenn]

Jo, när jag började använda linux seriöst så var det ju en fight att få igång saker, man fick kompilera egna kärnor för "allt", och att få igång allt samtidigt var ett jäkla meck, speciellt wavelan var en massa strul..

Idag tar man en helt ny modell av en laptop, packar upp den ur lådan och installerar fedora och sitter och gapar över att all hårdvara hittades, och networkmanager kastar upp en fråga vilket wavelan man vill koppla upp sej på vid första inloggningen.. sen kan man installera i princip vilka program man vill genom att klicka i ett gui eller skriva "yum install fobar" rakt av..

Saker har hänt på *ix-fronten de senaste 10-15 åren

[blueint]

* Vilka 3D operationer är det som gör stor skillnad att accelerera? (och lämpar sig för implementation i t.ex OGP)

* Någon tillverkare/modell av grafikkort som har bra 3D stöd ..?

Problemet med Projekt VGA är att den saknar all acceleration, och OGP kräver stora tillverkningsresurser (flerlager, BGA osv..). Ett kort med t.ex XC3S500-E i kluster samt PCI-express transceiver chip skulle få snabb överföringshastighet, bra kraft, vara rimligt att tillverka själv, och kunna skicka DVI osv.

Loadable kernel modules (.lkm) gör att man slipper kompilera mycket nuförtiden. Samt att bussar som PCI gör att man slipper att gissa. Innan var det till att skriva ner I/O + IRQ från MS-Win för att få till det i unix..

[Nerre]

Kompliera själv är säkert kul om man har moderna snabba maskiner med mycket disk. Vem vill sitta och kompilera Gentoo på min PII 450 MHz 256 MB RAM som jag kör som MythTV backend? OS-disken där är dessutom bara på 1 GB (det är två speglade 1 GB-diskar), jag tvivlar på att källkoden ens får plats.

[Jolles]

Vem vill sitta och kompilera Gentoo på min PII 450 MHz 256 MB RAM

hehe men kompillera får den la göra när man är på jobbet eller sover eller vad som helst Innan jag gav mig in i gentoo testade jag Crux lite snabbt, det visade sig vara RIKTIGT jobbigt, jag skulle dra in Enlightenment där, och det visade sig att jag fick hem en bunt paket ~40st kanske som skulle kompilleras en efter en, och varje program krävde i princip att ett annat av programmen var installerat redan, så fick man hålla på o testa varenda program så tills något kompillerade, men då skrev jag ett script istället som gjorde samma sak, och tog bort ett program från en lista när det lyckats kompillera så på så sätt blev det färre och färre, men ack..!
(Jag måste ha missat nått väldigt grundligt skikt i hur det os'et skulle fungera, för så kan man ju inte hålla på)

[arvidb]

ATIs kort stöds numera i princip så bra som grafikkort kan stödjas under Linux och X i dag.

Drivrutinen för RV280 heter xf86-video-ati. Den acceleration som finns som är till nytta vid filmtittning är framför allt skalning och "color conversion" via Xv. Mer detaljer här: http://www.x.org/wiki/RadeonFeature

Har du en ny X-server och kärna så får du även "Kernel mode setting" och DRI2 med "Textured XV"; i princip betyder det att film kan visas på 3D-ytor, bra om du vill köra "compositing" desktop. (Ursäkta svengelskan... )

Vad gäller videoavkodning så saknas ännu ett API för det i X, även om utveckling pågår för att använda grafikkortens vertex shaders (eller vad det nu heter) via Gallium etc. Om ett år kanske. Men då kommer det för både Intel och ATI.

NVidia stödjer inte alls Linux på något bra sätt, men de har drivrutiner i binärformat som kan fungera riktigt bra om man råkar köra "rätt" versioner av kärnan och X. Sen finns det ett projekt för att reverse-engineera NVidias drivrutiner som har kommit rätt långt nu och klart kan vara värt att testa om man har oturen att sitta med ett NVidia-kort och vill ha någon frihet: nouveau.

Videoavkodning är nu inte den tunga biten, men har man en klen CPU så kan det så klart vara avgörande, särskilt om man ska kolla på 1080p.

[Jolles]

Tyverr går den gränsen betydligt lägre än 1080 skulle jag säga, i det fall man har en långsam dator. Jag kan dock inte minnas att jag någonsin hade problem att spela upp video på äldre maskiner, åtminstonde dem ner till ~300mhz p2.
Videon då bestod väl visserligen mest omkring just divx, men det funkade ju på dem, och det är precis vad denna mac på 1.4ghz orkar med också, med då betydligt mer ram.

Har kikat runt blandannat här: http://en.gentoo-wiki.com/wiki/Radeon och enablat lite mer i xorg.conf, samt testade med att enabla KMS (Kernel Mode Setting) för radeon, men då startade aldrig systemet upp änns. se bild.
http://upload.snelhest.org/images/10063 ... _small.JPG
Det enda felet jag finner är "...Unable to locate a BIOS ROM"
Nu vet jag inte om igentliga fördelar med KMS, men det var ett försök att testa nått annat iaf.
Systemet är i övrigt helt up to date.

[arvidb]

Har du rätt use flags? (D.v.s. vet du om ditt videouppspelarprogram ens försöker använda xv?)

Om du kör mplayer så kan du göra nåt i stil med 'mplayer -vo help' för att se vilka devices som finns tillgängliga; det ska finnas en 'xv' så att det funkar att köra 'mplayer -vo xv <fil>'.

Med fungerande xv så ska det ta ganska exakt lika mycket cpu att spela upp en film i säg 320x240 som samma film skalad till fullskärm.

KMS vs UMS spelar nog ingen större roll i detta fall. Man får lite mer godis och en modernare, mer "framtidssäker" kodbas med KMS, men det går inte fortare - inte än iaf.

[Jolles]

use-flags har jag reducerat till att så gott som att inte använda kde/qt eller gnome/gtk, samt enablat en massa som har med min arkitektur att göra, och om det dyker upp nått på vägen som behövts... har inte vart skitpetig där, men ändå.

Jodå -vo har jag lekt med så de blir över Har testat samtliga som finns i den där listan, och med när man hittat lite ideer här o var på nätet. Jag rörde tydligen runt lite i grytan nu tydligen när jag uppdaterade senaste ati-drivern från 6.12.5 till 6.12.6 så nu funkar inte längre gl-drivern jag kört på hittills, utan ger ifrån sig en blå ruta, samma med gl2.

Jag blev trots allt positivt förvånad när jag nu fick hårdvaruaccelleration med xvidix på video, en dvd gick mycket väl att spela upp och cpu'n var i princip på idle då - däremot blev inte bilden vad jag hälst hade hoppats på, någon som vet varför?? Jag ser detta som ett major breakthrough ändå!
mitt screenshotprogram tog inte med video, så det blir kameran igen.
dvd med xvidix:
http://upload.snelhest.org/images/10063 ... xvidix.jpg

Detta är dessvärre även den ENDA som ger video just nu.

Kod: Markera allt

Available video output drivers:
	xv	X11/Xv
	x11	X11 ( XImage/Shm )
	xover	General X11 driver for overlay capable video output drivers
	gl	X11 (OpenGL)
	gl2	X11 (OpenGL) - multiple textures version
	v4l2	V4L2 MPEG Video Decoder Output
	directfb	Direct Framebuffer Device
	dfbmga	DirectFB / Matrox G200/G400/G450/G550
	xvidix	X11 (VIDIX)
	cvidix	console VIDIX
	null	Null video output
	mpegpes	MPEG-PES to DVB card
	yuv4mpeg	yuv4mpeg output for mjpegtools
	png	PNG file
	jpeg	JPEG file
	tga	Targa output

Från min nuvarande xorg.conf:

Kod: Markera allt

Section "Device"
        Identifier           "Card0"
        Driver                "radeon"
        Option                "AGPMode"       "4"
        Option                "BusType"       "auto"
        Option                "RenderAccel"   "true"
EndSection

[blueint]

Testa olika upplösningar, bitplanes (8,15,24 osv), refresh mm. Samt ev olika drivers.
En del lägen kanske bara fungerar i 15 bpp pga av att datahastigheten blir för stor annars mm. Eller 24 bpp men inte 32 bpp pga konstruktion osv.

[Jolles]

Testa olika upplösningar, bitplanes (8,15,24 osv), refresh mm. Samt ev olika drivers.
En del lägen kanske bara fungerar i 15 bpp pga av att datahastigheten blir för stor annars mm. Eller 24 bpp men inte 32 bpp pga konstruktion osv.

Hmm det där får du gärna förklara lite grundligare

Ser ju ut som om den vänt på pixlarna i "raderna" på bilden, hur kan det bli så?

[Jolles]

Hmm det här var intressant, sedan jag börjat köra 2.6.32 har systemet helt fryst när jag avslutar X, eller gör en reboot, jag kom underfund med kopplingen till kärnan tidigare idag, och bestämde mig för att testa den gamla igen, så det var ju snabbt fixat, nu är det okay igen, MEN något måste jag ha enablat i 2.6.32, efterssom vad jag trodde var uppdateringen av ati-drivern när xvidix började funka, och alla andra slutade, så var det något jag enablat i kärnan, för med 2.6.31 så är grafiken som tidigare igen, alltså tillbaka på gl. Varför kärnan var och är som den är går ju att fixa, det är ju bra att jag har en fungerande video-driver igen, även om det bara är software-render, men frågan kvarstår helt klart om varför åtta (?) pixels breda linjer blir vända, eller speglade...
Det känns helt klart som att jag inte bör vara den enda som sett detta, och det bör finnas en enkel förklaring till problemet.

[blueint]

Prova att slå av:

Kod: Markera allt

        Option                "RenderAccel"   "true"

Och all annan acceleration. Förutom Xv då.

[arvidb]

xvidix? Aldrig hört talas om. Efter lite googling verkar det som att senaste stabila versionen har dryga tre år på nacken; grattis om du får det att fungera med någon nyare Xserver!

Jag är rätt säker på att det är -vo xv som gäller.

Ska du köra med KMS så tror jag att du behöver xf86-video-ati-6.13.0 eller senare (finns som unstable). Dessutom behöver du firmware-filer från ATI (Gentoo-paket "radeon-ucode"). Men det ska som sagt gå lika fint att kolla på film med UMS (userland mode setting).

Tänk på att det finns en del beroenden mellan kärnan och drivrutinerna; mesa (som står för OpenGL-funktionaliteten) och övrig acceleration beror av libdrm, som måste byggas mot aktuell kärna. Så byter du kärna utan att köra emerge libdrm så kan du få problem.

Testa följande:

1) Skapa/sätt länken /usr/src/linux så att den pekar på källkoden till den kärna du vill köra. På min burk:

Kod: Markera allt

$ ls -l /usr/src/
lrwxrwxrwx  1 root root   12 2010-05-22 18:05 linux -> linux-2.6.34
drwxr-xr-x 24 root root 4096 2010-05-22 18:06 linux-2.6.34

Detta behövs för att bygget av libdrm ska bli rätt.

2) Lägg till en rad

Kod: Markera allt

x11-drivers/xf86-video-ati ~ppc

i /etc/portage/package.keywords. Jag brukar inte köra unstable, men för ati-drivarna är det värt det.

3) Kör 'emerge -av1 libdrm xf86-video-ati mesa' (--ask --verbose --oneshot) (jag är inte säker på att mesa behövs för video, men det är inte omöjligt, särskilt inte om du får textured xv nu med lite nyare drivisar).

4) Boota om med kärnan du valde i 1).

5) Skapa en ny ren X-konfiguration genom att köra 'Xorg -configure' som root. (Spara undan din nuvarande xorg.conf först och kopiera den nygenererade till /etc/X11/ eller var den nu ligger på ditt system.)

Starta X och testa mplayer -vo xv.