| Szerző |
Üzenet |
dezz
Tag
|
# Elküldve: 2009. Máj. 31. 13:51 - Szerkesztve: dezz
dino: Miért, video slot fetisiszta vagy, vagy mi? :D (Épp most volt a tévében egy nőiláb-fetisiszta. :) [Jó fej srác volt, nem azért mondom.]) Na majd ha úgy jön ki, összerakok neked egyet. :) Csak kár, hogy olyan nagy nyák kell hozzá.
Tényleg! Az ECS Amigák tudják az SHRes-t 2 bitplénnel, ugye? Ezt használja az SJ2 is a chunky (LoRes 1-byte paletted, ExLoRes 2-byte RGB565 és YUV4:2:2) módokhoz... Csak nem tudom, mennyire lenne itt lassú.
|
rachy
Tag
|
# Elküldve: 2009. Máj. 31. 14:41
@dezz
Nagyon. Az ECS SHires mod gyakorlatilag hasznalhatatlanul tetu, sajnos pontosan emlekszem a megdobbenesemre anno, mikor kiprobaltam.
|
dezz
Tag
|
# Elküldve: 2009. Máj. 31. 15:05
Aham (gondolom, mint a 8 bitplénnel AGA-n), akkor inkább csak állóképekre lenne jó, de ilyen kis felbontásokban nem sok értelme. Pedig poén lett volna. :)
|
dino
Kék troll
|
# Elküldve: 2009. Máj. 31. 22:22
Quoting: dezz dino: Miért, video slot fetisiszta vagy, vagy mi? :D (Épp most volt a tévében egy nőiláb-fetisiszta. :) [Jó fej srác volt, nem azért mondom.]) Na majd ha úgy jön ki, összerakok neked egyet. :) Csak kár, hogy olyan nagy nyák kell hozzá.
Ooo, ez a harisnyas sex baromsag? :) Igen speciel video slot buzi vagyok, csak azert mert abban azert sztem fixebben all, kevesebb elmozdulasi lehetoseg van. Akarhogyis nezem az a jobb megoldas egy high end Amiga szamara.
Quoting: dezz Na majd ha úgy jön ki, összerakok neked egyet. :)
Ugy legyen am! ;)
|
rachy
Tag
|
# Elküldve: 2009. Jún. 01. 10:14
@dezz
Annal rosszabb a helyzet, egyszer majd probaldi ki! :)
|
Cobra
Piros troll
|
# Elküldve: 2009. Jún. 01. 15:40 - Szerkesztve: Cobra
dezz: Nekem ugy remlik hogy ECS-nel SuperHiresben nem csak a szinmelyseg volt 2 bitre korlatozva, hanem a paletta szinmelysege is csokkentett volt, vagyis nem 4-bit/komponens volt hanem 2 vagy 3.
egy dolog eszembe jutott. Amit most a SJ2 tud YUV-t az konkretan YUV422 mod, ugye? Ami olyan hogy Y0 U0 Y1 V0 ... es az U/V adat kozos minden egymas melletti ket pixelre. Nem lehetne esetleg egy olyan YUV mode-ot csinalni, ahol nem csak X hanem Y iranyban is felezodik a U/V felbontas? Tehat YUV420, ami effektive csak 12 bit/pixel. A legtobb video (gyakorlatilag szinte minden MPEG-alapu codec) ilyen formatumban enkodol, es pl. Radeonon is sokat gyorsit ha nem kell YUV422-ba felkonvertalni a frameket (es feleslegesen tobb adatot attolni a buszon). YUV420-nal altalaban kulon veszik a Y, U es V adatot harom bitmap-be (ezt hivjak planar YUV-nek, de semmi koze az Amigas planar mode-okhoz mert itt nem bitenkent van plane-ekre bontva), vagyis nincs osszefuzve mint a YUV422 eseteben. A Radeonnal peldaul altalaban az Y jon eloszor, alatta pedig a fele akkora felbontasu U es V egymas mellett, igy a pitch/modulo/bytesperrow ugyanaz az U/V-re mint az Y-ra.
Es persze vannak meg egyeb YUV modeok is, peldaul a YUV9, amit az Indeo Video-nal hasznaltak, ott 4x4 (16) pixelre van egy U+V adat, ami effektiv 9 bit/pixel, vagy a PicassoIV-en hasznalt Cirrus Logic-fele ACCUPAK mod, ahol 32-bitenkent van tarolva 2x2 5-bit Y, 6-bit U es 6-bit V, ami effektiv 8 bit/pixel.
|
dezz
Tag
|
# Elküldve: 2009. Jún. 01. 18:44 - Szerkesztve: dezz
rachy: Mitől lenne lassabb? Lényegében ugyebár abban tud többet az AGA, hogy 16 helyett 64 bitet tud beolvasni a bitplének számára a chipramból 280 ns-onként, így 4x több bitplén számára jut adat. De pl. a proci hozzáférése a chipramhoz nem változott, és a blitter sem lett önmagában gyorsabb (csak több idejük marad megegyező számú bitplén mellett, de esetünkben 4x többről van szó). Mit hagyok ki a számításból?
Cobra: A paletta kisebb színmélysége nem jelentene gondot.
Igen, 4:2:2-ben megy. Ez a digitális-videós chip adottsága (ez a bevett formátum nem-számítógépes digitális videónál [de pl. Mpeg2-től ott is, sőt HD-nál a 4:4:4 sem ritka, persze ezek itt nem annyira szempont]).
Annyit tudtam tenni a CPLD-ben (ami egy nagyobb CPLD, egy kisebb FPGA-nak felel meg), hogy forrásfelbontástól függetlenül mindig (16bpp) 768xXXX-ben kapja meg a chip az YUV adatot (csak ezt felbontást támogatja). Amit te írsz, ahhoz több sort kellene tárolni, amire nincs mód a jelen hw-rel. De az SJ3-nál szóba jöhet! :)
Egyébként most UYVY-ben (más nevei is vannak) várja az adatot, azaz U0-Y0-V0-Y1, stb., mert több helyen azt olvastam, hogy ez a legelterjedtebb 4:2:2-ben (és sok codec ismeri). Pl. itt: LINK
De ha úgy gondolod, jobb lenne előre venni az Y-okat, lehet róla szó. (Talán az átválthatóság is belefér még, illetve az U-V sorrend felcserélhetőségére is van talán mód.)
A 4:2:0 -> 4:2:2 "konverzió" elintézhető annyiból, hogy a 2. sorokban újraküldöd ugyanazt az U/V adatot...
|
Cobra
Piros troll
|
# Elküldve: 2009. Jún. 01. 20:38 - Szerkesztve: Cobra
dezz: azt konkretan nem ertem, mi elonye van ECS-nel a 2-bit SuperHires-nek egy 4-bit HiRes-el szemben? Mindkettobol lehet 8-bit LoRes-t osszerakni, nem?
Szerintema YUV422-nel a bytesorrend tok mindegy, mert nagyjabol ugyanannyi bitmaszkolas/orolas osszerakni. Viszont mivel az Amiga big-endian procit hasznal, ezert az Y0-U0-Y1-V0 lenne a logikus, nem pedig egy little-endian valtozat.
A 420->422 konverzio ugy nez ki, hogy a 420 adatnal kulon bitmapekben van az Y, U es V adat, vagyis egy loopban be kell olvasni harom kulonbozo pointerrel es shift-maszkolassal osszerakni 32-bites regiszterbe majd kiirni chipramba. Azert szamit olyan sokat a YUV420 mod, mert:
1. Kevesebb adatot kell attolni a korlatozott savszelessegu chipramba (16bpp helyett csak 12bpp)
2. Egy mezei copyloop sokkal gyorsabb es cache-baratabb, sot ha van DMA lehetoseg akkor plane jo.
Viszont ha pl. a Rivarol van szo, akkor egy YUV422 mod is sokat dobhat a lejatszas sebessegen es minosegen, mert a jelenlegi DHAM8 mod (ami AGAn a legjobb minosegu mod) is 2 pixelt hasznal 1 pixel megjelenitesere (tehat pl. egy 320 szeles videonal 640-es HAM8 screent nyit), csak ott meg lassit a YUV->RGB konverzio, illetve a chunky-to-planar rutin. Igaz, csak 6 plane-t ir ki, nem 8-at, merta HAM control plane-ek elore vannak fillezve es nem valtoznak, szoval elkepzelheto hogy nem lenne sokkal gyorsabb, csak a minoseg lenne jobb.
Es olyat esetleg lehetne csinalni, hogy egymas mellett 4 pixelre letarolni 4db 5-bites Y-t, majd 6-bit U es 6-bit V? Tehat igy neznenek ki a bitek:
Y0 Y0 Y0 Y0 Y0 Y1 Y1 Y1 Y1 Y1 Y2 Y2 Y2 Y2 Y2 Y3 Y3 Y3 Y3 Y3 U0 U0 U0 U0 U0 U0 V0 V0 V0 V0 V0 V0
Azt hiszem a Cirrus Logic-fele Accupak konkretan ilyen (hogy 4x1-es pixelcsoportokra van kozos U/V), nem pedig 2x2-es ahogy korabban irtam, valoszinuleg hasonlo hardverlimitaciok miatt.
|
dezz
Tag
|
# Elküldve: 2009. Jún. 01. 22:10 - Szerkesztve: dezz
Az SJ2 szempontjából a következő:
A "planar"-to-chunky "engine" (ami a chipsettől egymás után kapott pixelekből visszaállítja a chunky adatokat) 16 bites adat-szavakkal dolgozik, ebben a formában várja az adatot:
0. bitplane: 0. word, 2. word, 4. word, stb.
1. bitplane: 1. word, 3. word, 5. word, stb.
A következő okból van éppen így:
1. 2db 32 bites shiftregiszter (+ 2nd buffer) nem fért el, csak 2db 16 bites.
2. 4 bitplénhez hasonlóan 16 bites szervezésben 2x ennyi kellene... 4x8 bites szervezéssel elférne (mint amilyen pl. a Graffity volt), de az nem sokat gyorsítana.
3. Sikerült olyan rutint írni 030-ra (*), ami copy-speeddel csoportosítja át és írja ki 2x16=32 bitenként az eredetileg sorfolytonos 16 bites (RGB565 v. YUV888-4:2:2) vagy paletted (**) 8 bites adatokat 2 bitplénbe. 4x8 bitre lassabban lehet szétszedni.
A chipsetnek (akár ECS, akár AGA) meg mindegy, mert a kettő (4xHiRes vs. 2xSHiRes) kb. egyforma sebességű (ECS-nél lassú, AGA-nál elég gyors)...
* Ezek tehát a chunky módok, amikkel elsősorban 030/040 lett megcélozva, 160xXXX@16bpp és 320xXXX@8bpp felbontásokban, többet nem is nagyon bírnak (real-time). A 060 már képes a 8 bitplénes chunky-to-planar konverzióra, így az a planar alapú 16bpp-s módokkal is elboldogul...
** Ez egy utólagos "hack", és sajnos 256 helyett csak 220-as lehet itt a paletta (de 24 bites :P ). :) 256x24=6144 bit egy kicsit sok egy CPLD-nek, de még egy nem nagy FPGA gyomrát is megfekszi... :) Így egy trükkel valósítottam meg, jobb-mint-ha-nem-is-lenne alapon.
Az a bizonyos DHAM8 nem inkább 3 pixelt használ (1xR, 1xB, 1xG)?
Értem, miért lenne jobb a 4:2:0, de ezen most nem tudok változtatni. Az SJ3-nál valószínűleg lesz erre és a többi felvetésedre mód. Azon egy (nem is a legkisebb) FPGA lesz.
Jut eszembe, nem lenne jobb az RGB565-öt így kezelni?:
G5,G4,G3,R4,R3,R2,R1,R0, G2,G1,G0,B4,B3,B2,B1,B0
És nem pedig:
R4,R3,R2,R1,R0,G5,G4,G3, G2,G1,G0,B4,B3,B2,B1,B0
(Talán 1-2 shifteléssel kevesebb kell a fentihez, RGB888-ból való átszámolásnál, de még nem gondolkodtam rajta el jobban.)
|
dezz
Tag
|
# Elküldve: 2009. Jún. 01. 22:35 - Szerkesztve: dezz
Amúgy azt meg lehet tenni, hogy a planar alapú módoknál nincs mind a 8 bitplén használva, szal nem 8 bites az Y/U/V, hanem csak 7 vagy 6... :) Bár még nem próbáltam, hogy néz ki. 7 bitnél (kb.) 2^21 = 2 097 152, 6 bitnél meg 2^18 = 262 144 lenne a színválaszték. (Utóbbi megegyezik a HAM8-cal, de a nagyobb felbontású világossági információ miatt élesebb képpel.)
|
Cobra
Piros troll
|
# Elküldve: 2009. Jún. 01. 22:46 - Szerkesztve: Cobra
dezz: Ezt ertsem ugy, hogy ha pl. 8 bitplane van (AGA), akkor az adatoknak ugy kell lennie hogy:
bitplane 0: 0. word, 8. word, 16. word, stb.
bitplane 1: 1. word, 9. word, 17. word, stb.
...
bitplane 7: 7. word, 15. word, 23. word, stb.
Vagy rosszul ertelmeztem?
060-on van valami elonye ha a planar alapu 16bpp modeokat hasznalod a chunky alapuak helyett? Csak mert ha a chunky valtozat ugyanolyan gyors 060-on mint a planar alapuak akkor szerintem nincs is szukseg a planar alapuakra (minel kevesebb mode-ot kell egy programnak tamogatni annal jobb).
A DHAM8 nem 3 hanem 2 pixelbol csinal egyet, ugy hogy R G - B G - R G - B G ... vagyis a zoldet minden pixelre updatelem mert abban van a fenyero nagy resze, a pirosat/keket csak minden 2. pixelre. Hasonloan mukodik mint a YUV-nel ahol a szinadat csak minden 2. pixelnel valtozik, es eleg jo eredmenyt ad videokkal.
Majd megnezem a riva kodjat, hogy melyik 16 bites formatumra hany utasitas a konverzio, de szerintem jelentos kulonbseg nem volt.
|
Cobra
Piros troll
|
# Elküldve: 2009. Jún. 01. 22:55 - Szerkesztve: Cobra
Az Accupak ahol 5-bit Y es 6-bit U/V van nem nez ki valami jol, igazabol valami 15/16 bites mode-hoz hasonlit. En a DvPlayerbe irtam RGB16-hoz realtime animalt dither rutint ami PPC-n egyaltalan nem lassit es hihetetlen jo minoseget produkal az animalas miatt (LCD-k is altalaban igy novelik a szinmelyseget), de 68k-n szerintem ez mar lassitana, raadasul felezett felbontasu U/V-t nem akarsz ditherelni mert az mar elegge meglatszana.
El kell vele jatszani hogy mi nez ki jol, szerintem 6-bit Y/U/V mar egesz jol nezne ki, akkor az ebben a felallasban 12bpp lenne. A Rivaban sikerult osszehozni egy eleg gyors 6-bites c2p rutint DHAM8 mode-hoz ami joval gyorsabb mint egy full 8-bites.
|
dezz
Tag
|
# Elküldve: 2009. Jún. 01. 23:22 - Szerkesztve: dezz
A chunky módokból (amiknél bejátszik ez a wordös móka) csak azok vannak, amiket fent írtam (ja, és egy 160xXXX@8bpp, ha csak 1 bitplén van bekapcsolva), okokat is lásd fent.
Hogy lehet egyszerre két színt update-elni HAM-ben?
Persze, az 5+6+6 az már elég kevés. De ha 6 bites az Y is, akkor 2x annyi világossági fokozat van, amire ugye eléggé érzékeny a szem: 32 helyett 64, ami már nem olyan rossz. Kérdés, ez mekkora sebességkülönbéget jelent. (Megjegyzem, többet gyorsít, mint a 6-bit c2p vs. 8-bit c2p, + copyzás önmagában, mert a chipram-elérési sávszélből is több marad valamennyivel.) Persze ez csak egy lehetőség.
ps. csak a vacakabb LCD-k csinálnak 6+6+6 bitből különféle ditherelésekkel v. FRC-vel 8+8+8 bitet. :) A normálisabbak natívan 8+8+8 bitesek. A legjobbak meg az eredetileg 8+8+8 bites panelokat 10+10+10, vagy akár 12+12+12 bitesre bővítik hasonló módon (ez már persze sokkal kevésbé feltűnő) -- csak szemét módon nem támogatják még a HDMI DeepColor-ját, az nyilván majd egy későbbi "bőr" lesz.
|
Cobra
Piros troll
|
# Elküldve: 2009. Jún. 02. 20:48
dezz: oke, igy mar minden vilagos, tehat a chunky mode-ok gyakorlatilag minden esetben kizarolag 2 bitplane-es superhires mode-ok. Egyebkent mukodne ECS-en a dolog, es nem hiszem hogy lassabb lenne a SuperHires 2-bit mint a HiRes 4-bit, a HiRes 4-bit is bun lassu OCS/ECS-en.
Nem update-elek ket szint HAM-ben. Kepzelj el egy HiRes (640 szeles) screen-t, amin a szinkomponenseket a kovetkezokeppen updatelem: R G B G R G B G ... Tehat a Green-t minden masodik pixelen update-elem, a Red es Blue-t csak minden negyediknel. Namost mivel a fenyero nagy resze a Green-ben van, ezert a fenyerovaltozasok minden masodik pixelen megtortennek, amig a kek/zold komponensekre a fenyeronek egy sokkal kisebb resze jut, ezert nem gond ha azok csak minden 4. pixelen vannak updatelve. Igy a 640-szeles screenen gyakorlatilag egy olyan hatast kelt ez a mode, hogy a fenyero felbontas 320 szeles, a chroma (szin) felbontas pedig a fele (160 szeles). Vagyis ez a mode is a YUV-hoz hasonloan kihasznalja azt hogy az emberi szem erzekenyebb a fenyerovaltozasokra mint a szinvaltozasokra. Termeszetesen nem annyira tokeletes mint a valodi YUV, eles konturoknal elofordul kis kekes/pirosas elszinezodes a szeleken amit HAM modban megszoktunk, de mivel a felbontas duplaja a megjeleniteni kivant pixelek szamanak, ezert nem olyan feltuno.
|
dezz
Tag
|
# Elküldve: 2009. Jún. 02. 22:00
Cobra: Ja, már értem, csak megzavart, hogy egy-egy pixelnek nevezted az R-G, B-G párosokat, ami egy kicsit "önkényes". Amúgy jópofa. Persze az YUV term. jobb (mármint azonos színmélységnél is), mert a fekete-fehér-szürkeárnyalatos élek vagy vékony vonalak teljesen élesek, elszíneződésmentesek, és az U+V által kódolt színváltások is kevésbé feltűnőek.
|
dezz
Tag
|
# Elküldve: 2009. Jún. 03. 15:34
Csináltam teszteket a csökkentett bitszámú YUV-vel. 6+6+6 biten elég érdekesen nézett ki... Szürkeárnyalatokban megvolt a 64 fokozat, de az alapszínek hasonló fokozataiban (vöröstől feketéig, stb.) már inkább valahol az RGB555 és 666 (HAM8) között volt. (De lehet, hogy az RGB->YUV konverzió precízebbé tételével lehet javítani ezen, vagy ha eleve YUV-ben van az adat.) 7+7+7 biten szürkeárnyalatokból term. 128 volt, és itt már egy fokkal jobbak voltak a színes fokozatok is, mint az RGB666/HAM8. (A 8+8+8 persze mindent vitt.) És persze nem jelentkeztek a HAM-ra jellemző elszíneződések, szín-zajok. (További körülmény, hogy az SJ nem támogatja a natív SHiRes-t, itt minden első pixelt vesz.)
|
Cobra
Piros troll
|
# Elküldve: 2009. Jún. 03. 16:05
dezz: jah, nyilvan extra hardverrel mint az SJ2 jobbat lehet elerni, bar a DHAM8 is meglepoen jo eredmenyt ad, csak kicsit lassu, annak ellenere hogy gyakorlatilag egy 6-bites c2p-bol all, foleg azert mert 2x annyi adatot kell kiirnia. Csinaltam belole HAM6 valtozatot is, az mar joval gyorsabb AGA-n, de a 12-bit kicsit keves, szoval nem tul szep.
Kozben jott egy masik otlet, Mondtad hogy a SJ2 kepes a YUV es egyeb mode-ok kozott kepernyo kozben atvaltani, akkor elmeletileg lehetne vele csinalni YUV overlayt is, nem? Vagy csak sor elejen megy ez a valtas?
|
dezz
Tag
|
# Elküldve: 2009. Jún. 03. 16:23 - Szerkesztve: dezz
Épp most módosítottam ezen a részen, mert az eredeti megoldás 3-4 sor alatt váltott RGB és YUV között, ami nem volt az igazi. Most azonnali a váltás (ahogy átírásra kerül a megfelelő regiszter-bit). Este kipróbálom, mi történik, ha sor közben van a váltás. Nem biztos, hogy megfelelően működik ez (elronthatja az időzítéseket, stb.).
|
Cobra
Piros troll
|
# Elküldve: 2009. Jún. 03. 16:26
A YUV 6-6-6 az biztos nem fog tul jol kinezni, mert arra emlexem hogy az Accupak (ami 5-6-6) is eleg gyatran nezett ki, egy fokkal annal jobb lehet ha a fenyesseg 2x olyan melysegu. Ha az U/V felbontast horizontalisan felezni tudnad, tehat egymas mellett 4 Y-ra jutna egy U/V paros, akkor nem kell egy sort letarolni mint a YUV420-nal, es 8-8-8-ban akkor csak 12 bit/pixel lenne. Ha ezt meg valami trukkel meg lehetne oldani a SJ2-ben akkor az baromi jo lenne gyors videolejatszasra.
|
dezz
Tag
|
# Elküldve: 2009. Jún. 03. 17:58
A 4:1:1-re gondolsz? Megpróbálom megoldani...
|
Cobra
Piros troll
|
# Elküldve: 2009. Jún. 03. 21:32
dezz: igen, YUV411 az. Jut eszembe, amikor lattam hogy a felezett U/V felvontas (YUV422) miatt az egerpointer piros resze kicsit "erdekes", azon filoztam, hogy ha a video IC interpolalni tudja Y iranyban a kepet (amit ki/be kapcsolgattal), nem tudja veletlen az U/V adatot horizontalisan interpolalni? Vagy esetleg az RGB->YUV konverzional simitast vegezni. Ha tud valami ilyesmit akkor az lehet hogy segitene azon a probleman.
|
dezz
Tag
|
# Elküldve: 2009. Jún. 03. 22:33 - Szerkesztve: dezz
Na, elméletileg működhet a dolog. (Szempontok: 1., fix ütemezés szerint kapom és küldöm az adatokat, 4 byte-os ki- és bemeneti regiszterrel (nem fifo buffer, mert nem sorrendben megy). 2., 16 bites kihagyásnak a chipramba írásban nincs értelme [az is egy ciklus meg a 32 bit is], tehát beírt v. be nem írt longwordökkel lehet játszani.)
Nos, (nagyjából) így lennének az adatok a chipramban:
0. longword: U0-Y0-V0-Y1
1. longword: U1-Y2-V1-Y3
2. longword: Y6-Y4-Y7-Y5
3. longword: --------------
4. longword: U2-Y8-V2-Y9
...
De hogy belefér-e még a keretbe, az majd kiderül.
ps. másféle simítást nem tud. (Egyébként ez a sor-interpoláció elvileg kikapcsolhatatlan lett volna, csak egy trükkel lehetett megszabadulni tőle. Amikor mondtam a gyártónak, hogy sikerült, nem hitték el. :P Mint ahogy azt sem, hogy VGA jelet is át tudok küldeni rajta. :) )
|
dezz
Tag
|
# Elküldve: 2009. Jún. 04. 03:14 - Szerkesztve: dezz
Uhh, basszus, itt közben máson járt az agyam, és teljesen megfeledkeztem róla, hogy itt planar (kiinduló) pixelekről van szó, nem chunky. :P Szal nem longwordök azok, hanem 4-es pixelcsoportok. Így ezzel akkor csak 16 pixelenként 4 pixel c2p konverzióját lehet megspórolni, de ugyanannyi a copy a chipramba... Nem tudom, mennyit gyorsítana ez így... (De ha így is érdemes, kicsit más elrendezés lesz számomra az optimális: rendes sorrend, egyes U/V tárolások kihagyásával.)
Apropó, chunky: jobb lenne, ha így lennének az adatok (főleg a 030/040 szempontjából)?:
0. bitplane: Y0-Y1, Y2-Y3, Y4-Y5, ...
1. bitplane: U0-V0, U1-V1, U2-V2, ...
(1-1 pár 1-1 word)
Most így van:
0. bitplane: U0-Y0, U1-Y2, U2-Y4, ...
1. bitplane: V0-Y1, V1-Y3, V2-Y5, ...
A planároknál is mehet ilyen elrendezésben (csak word helyett pixelpár), ha optimálisabb a playereknek. (Vagy ha más nem, legalábbis előre tudom venni az Y-t, ha azt mondod, mindegy, vagy úgy még jobb is.) Tehát ha a 4:2:2, mint forrás nem túl gyakori, és inkább 4:2:0 van, amit úgyis át kell rendezni.
Egyébként hogy vannak a codec-ek Amigán? Ezek nyílt forrású cuccok portjai, amik módosításra is kerülnek, vagy eredeti formában futnak, és aztán a kimenő adatokat használod belátásod szerint? Lehet választani ezeknél a codeceknél kimeneti formátumot? (Ezeket a dolgokat jó lett volna élőben megbeszélni, ha nem lettem volna teljesen kialvatlan.)
Ha meglépem ezeket a változtatásokat, az RGB565-re is kell gondolni, mivel jó lenne, ha azt nem kellene külön eset(ek)ként kezelni a belső adatkezelésben. De talán annak sem árt az átrendezés: ugyebár többnyire az RGB adat is RGB888-ként van kezelve és tárolva a fastramban, és onnan van átszámolva. Szal jó lehet, ha 2x5 bit R és 2x5 bit B ugyanabban az 1-1 wordben van, persze 3-3 bit G mellett.
|
Cobra
Piros troll
|
# Elküldve: 2009. Jún. 04. 09:32
dezz: ahha ertem, elvileg ez mukodhet, ha nem lassitja a copyloopot, hogy nem folyamatosan ir kifele a chipramba hanem atugrik itt-ott long-okat. Pl. PCI-nal ez kapasbol keresztbe tenne neki mert burst mode akkor elfelejtve, stb. AGA-n nem tudom mi a helyzet.
Ami a chunky YUV-t illeti, a bytesorrend teljesen mindegy, mert a source buffer az 3 pointerbol all, egy Y, egy U es egy V, az pedig tok mindegy hogy milyen sorrendben olvasod ki az adatokat a bufferbol. Mondjuk ha nem byte-onkent akarod olvasni a source-t hanem word vagy long darabokban amit utana maszkolgatsz at, akkor lehet hogy nem mindegy, de ahhoz meg kene irni a rutint hogy lasd van-e kulonbseg, illetve gyorsabb-e ha nagyobb darabokban olvasod a source-t es maszkolod at, mintha egyszeruen byteonkent olvasnad. Ezzel el kell jatszani.
Ami az RGB16-t illeti, ossze kene raknom otthon az A4k-mat hogy megnezzem a regi forrasaimat, melyik elrendezeshez milyen maszkolasos kod kellett, csak helyhiany miatt ez most maceras, szoval azt majd a hetvegen.
Szoval sok a hidden feature a video IC-ben? A vegen meg kiderul hogy tud ez a chip YUV444-et is :D
|
rachy
Tag
|
# Elküldve: 2009. Jún. 04. 09:47
@Cobra
Szerintem AGA-n nincs kulonbseg a linearis es a random memoriahozzaferes kozott, semmilyen pufferelest vagy adatok osszevonasat sem alkalmaztak. Tobbek kozt ennek koszonheto a gyalazatos hozzaferesi ido.
|
Cobra
Piros troll
|
# Elküldve: 2009. Jún. 04. 09:53
Ja codec-ekkel kapcsolatban, minden modern video codec valamelyik YUV formatumot hasznalja, es kulon dolgozik a 3 komponenssel, vagyis azok kulonallo bitmapek (tipikusan 8bpp), mert igy a leghatekonyabb a decoder munkaja. Tehat a vegeredmeny altalaban valamilyen planar YUV ahol kulon van az Y, U es V adat. Ha a megjelenites nem tamogatja ezt a formatumot kozvetlen, akkor jon ugye a konverzio. MPEG1-nel kizarolag YUV420P van hasznalva, MPEG2-nel lehet YUV422 is, de meg a DVD-k nagy resze is siman YUV420P-t hasznal. Persze DVD-t szerintem nem fog senki classic Amigan nezni, mert meg egy overclocked 66MHz-es 060 se birja a negyed akkora felbontasu VideoCD-t skip nelkul jatszani, videokartyaval se. PPC-nel is csak a 200MHz folottiek birjak el a VCD-t. A DivX az altalaban gyorsabb mint az MPEG, es az is YUV420P-t hasznal.
Mindenesetre szerintem a YUV mode-ok elsosorban videolejatszasra lesznek hasznosak, mert kepmegjelenitesre altalaban tul kicsi az a 320-as felbontas, videolejatszasra viszont pont eleg, mert annal nagyobb felbontasu videokat amugy se birna el a proci.
|
Cobra
Piros troll
|
# Elküldve: 2009. Jún. 04. 09:56
rachy: a hozzaferesi ido annyira nem gyalazatos ha azt nezzuk hogy egy atlag Zorro3-as videokartya mint a PicassoIV kb. 10MB/sec-et hoz irasban, AGA-n egy 060-assal pedig kb. 6-7MB/sec-et kapsz. Viszont 030/040-el ha jol emlekszem lassabb volt a chipmem iras mint 060-on, de azt nem tudom miert.
|
Chain-Q
Divatamigás
|
# Elküldve: 2009. Jún. 04. 12:17
A 68060 storebuf-jat hogy erinti a nemlinearis eleres? Ott nem kell 'sorban' lenni a dword-oknek?
|
Cobra
Piros troll
|
# Elküldve: 2009. Jún. 04. 12:52
ChainQ: szerintem egyszeruen csinalni kell egy teszt progit, es lemerni.
|
dezz
Tag
|
# Elküldve: 2009. Jún. 04. 14:45 - Szerkesztve: dezz
Cobra: Az a long-kihagyás sajnos mégsem játszik, legalábbis planár alapú módnál, mint negyed 4-kor hirtelen rájöttem. :) Annyi lenne, hogy 16 pixelből csak 12-t kellene c2p-zni, de ugyanannyi copy művelet lenne. Az a kérdés, ez mennyit gyorsít.
(Ahol bejátszhat még ez a long-kihagyás, azok a chunky módok, de csak úgy, ha az U/V felbontás nem 1/4-e lesz az Y-nak [4:1:1], hanem 1/6-a. Nem tudom, ennek lenne-e értelme, hiszen ez a chunky eleve kis felbontású. Word kihagyással persze lehetne 4:1:1, de 1-1 wordöt meg megint csak nincs értelme kihagyni.)
Esetleg még azt lehetne, hogy 6 bitplénen kapott adatokat úgy rendezni, hogy 8+8+8-as 4:1:1 jőjjön ki. Ezen még nem filóztam, de a kötöttségek miatt nem valószínű, hogy működik. Szerk: Közben elgondolkodtam rajta, és van némi esélye.
Az YUV-s képmegjelenítést nagyobb felbontású planar alapú módra bízni gondoltam. A chunky módok, felbontásuknál fogva real-time dolgokra valók. :)
rachy, Cobra: 030/040-nél számítana a long-kihagyás, a 060-nál a Csárli által említett storebuffer miatt valószínűleg nem, mert oda is kellene írni dummy adatot. (Sima copy-nál gyorsítana a dolog, mert ahhoz nem szükséges a storebuffer, anélkül is lehet full-speed, de ha még c2p is van, akkor már valószínűleg kell hozzá.)
030-cal is meg tud lenni a maximális 7.x MB/s! Sikerült is egy olyan full-speed fast-2-chip copy rutint írnom 030-ra, ami a fastramban word-ök soraként meglévő adatot (persze longwordökben olvassa be) néhány regiszterben átrendez a 2009. Jún. 01. 22:10-esben vázolt elrendezésnek megfelelően, ugyancsak longwordönként kiírva a chipbe.
De ha nem wordösen vannak az összetartozó adatok (1 byte Y, 1 byte U/V, vagy egy RGB565 word), akkor más a leányzó fekvése... Itt jöhet be a 2009. Jún. 04. 03:14-esben írt újabb chunky elrendezés (Y-ok sorban), ami elsősorban a 030/040 számára lenne optimálisabb: byte alapú rendezkedés helyett (ami már nem megy copy-speeddel), az Y-ok esetén simán longwordokat kell így másolni, és csak az U-kat és V-ket kell byte-onként összefűzögetni. (A 060-nak persze mindegy.)
Most már csak az a kérdés, 030/040-nel ki lehet-e egyátalán tömöríteni legalább kisebb felbontású videókat, megfelelő sebességgel. :)
|
