Mistä ja mikä mäkki 1920x1200 "cinemalle

[chiruchi]

Kaipaisin jotain sopivaa omenaa mac-maailmaan tutustumiseen ja mahdollisesti siirtymiseen. Pääpiirteittäin macin käyttö tulisi olemaan alkuun kokeiluluontoista ja jos sillä asiat ottavat luistaakseen niin voin harkita hieman isommankin investoinnin tekemistä, mutta nyt alkuun pitäisi päästä vähän edullisemmin, mahdollisesti maksimissaan n. 1000e sijoituksella.

Toivelistalla olisi että tuo masiina pystyisi ampumaan kunnollista 1920x1200 kuvaa LCD-näytölle (vastaava kuin tuo keskikokoinen cinema), ja sen verran muistia että photoshoppaus onnistuu edes välttävästi ja java-sorsat kääntyvät

Aikaisempi kokemus on melko lyhyt, silloin iMac@800:sta, jossa tuo kiinteä näyttö rajoitetun resoluutionsa (1024x768) vuoksi siirtyi eteenpäin. Nopeusluokaltaan vastasi kyllä näitä tarpeita hyvin, varsinkin kun muistia oli vähän reilummin.

Ennen kuin joku sanoo että "osta mini", olen ymmärtänyt että siitä tuota kunnollista 1920x1200 kuvaa nimenomaan ei saa ja näytönohjain ei käsittääkseni ole vaihdettavissa?

Kannettavuutta en myöskään toistaiseksi pidä suuressa arvossa, sitä varten on firman puolesta PC-rautaa

Vaan mikäpä olisi sopiva ja mistä sellaista etsimään jos käytettyä halajaa? Millainen näytönohjain olisi minimi?

Ainiin,ja ipodi on jo

-c-

[kallekilponen]

Luulempa että melkein mikä tahansa G5 sopisi tarkoituksiisi. Jos mahdollista niin suosittelen näytönohjaimeksi ainakin Radeon 9600 XT:tä.

[chiruchi]

Kotona roikkuu ylimääräisenä yksi Radeon 9800 XT AGP. Käykö se mäkkiin suoraan?

Tätä en tullut edes ajatelleeksi

[Repe Ruutikallo]

Kotona roikkuu ylimääräisenä yksi Radeon 9800 XT AGP. Käykö se mäkkiin suoraan?

Eih.

[nege]

Sun budjetti ei oikein anna myöten kilposen ehdottamaan G5:een, mutta käytettynä saisit varmasti jonkun G4-tornin johon voi vaihtaa helposti näytönohjaimenkin vastaamaan tarpeitasi. Käytettyjä löytyy tämän foorumin osto- ja myyntipalstalta. Useissa on ollut muistiakin valmiina gigakaupalla..

[Hene1]

Mac minissä on DVI-liitäntä jossa tuki 1920x1200 resoluutiolle. DVI-liitäntää käytettäessä kuva on tietysti "täydellinen", koska kaikki tieto kulkee digitaalisena. Näyttömuistia minissä on vain 32 MB, mikä aiheuttaa ehkä satunaisten efektien nykimisen, mutta ei se ole vakavaa.

[Jamac]

Ennen kuin joku sanoo että "osta mini", olen ymmärtänyt että siitä tuota kunnollista 1920x1200 kuvaa nimenomaan ei saa ja näytönohjain ei käsittääkseni ole vaihdettavissa?

Minin specksit:
www.apple.com/macmini/specs.html

"DVI video output for digital resolutions up to 1920 x 1200 pixels; supports 20-inch Apple Cinema display and 23-inch Apple Cinema HD display; supports coherent digital displays up to 154MHz; supports non-coherent digital displays up to 135MHz
VGA video output (using included adapter) to support analog resolutions up to 1920 x 1080 pixels"

[kallekilponen]

Kotona roikkuu ylimääräisenä yksi Radeon 9800 XT AGP. Käykö se mäkkiin suoraan?

Tätä en tullut edes ajatelleeksi

Se pitäisi flashata macille.

Sun budjetti ei oikein anna myöten kilposen ehdottamaan G5:een, mutta käytettynä saisit varmasti jonkun G4-tornin johon voi vaihtaa helposti näytönohjaimenkin vastaamaan tarpeitasi. Käytettyjä löytyy tämän foorumin osto- ja myyntipalstalta. Useissa on ollut muistiakin valmiina gigakaupalla..

No voisi sillä saada käytetyn Rev. A 1.6 G5 sinkun. Käytetyn G4:n osto voi olla vähän kannattavuuden rajoilla tuon Mac minin takia...

[chiruchi]

Hmm, sain tältä ihmiseltä vain tietoa, keneltä hankin tuon HP:n 23" näytön, jotta hän joutui nimenomaan luopumaan Mac Ministä, koska sen tuottama kuva ei ollut riittävän laadukasta samanlaiselle näytölle. En sen enempää ole asiaan edes perehtynyt.

Eli teknisesti pystyy antamaan tuon 1920x1200 resoluution, mutta kuvanlaatu on ilmeisesti huono? Ehkä tämä pitäisi itse käydä testaamassa jossain omenakaupassa, mikäli niillä sellainen kokoonpano sattuu jossain olemaan, ja todeta itse, mutta 32Mt muisti ei kyllä todellakaan kuulosta kovin isolta tuolle resoluutiolle.

G4-tornia olenkin etsinyt, mutta aika nopeasti tuntuvat menevän kaupaksi jos hinta vain on realistinen. Vaan nopeat syövät jne

[CaptainNapalm]

Hmm, sain tältä ihmiseltä vain tietoa, keneltä hankin tuon HP:n 23" näytön, jotta hän joutui nimenomaan luopumaan Mac Ministä, koska sen tuottama kuva ei ollut riittävän laadukasta samanlaiselle näytölle. En sen enempää ole asiaan edes perehtynyt.

Eli teknisesti pystyy antamaan tuon 1920x1200 resoluution, mutta kuvanlaatu on ilmeisesti huono? Ehkä tämä pitäisi itse käydä testaamassa jossain omenakaupassa, mikäli niillä sellainen kokoonpano sattuu jossain olemaan, ja todeta itse, mutta 32Mt muisti ei kyllä todellakaan kuulosta kovin isolta tuolle resoluutiolle.

G4-tornia olenkin etsinyt, mutta aika nopeasti tuntuvat menevän kaupaksi jos hinta vain on realistinen. Vaan nopeat syövät jne

Minäkin nyt vaan höpisen ilman käytännön kekemusta (Macminillä kyllä kokemusta 1680*1050 resoluutiolla) mutta todella vaikea kuvitella, että DVI:n kautta kuva voisi olla jotenkin huono tuolla resoluutiolla ja Macminillä. Ettei vain olisi niin, että näyttöä on yritetty käyttää VGA:lla 1920*1200 resoluutiolla, mitä ko. sydeemi ei tue?

Ja 32 MB näyttömuisti ko. resoluutiolle on moninkertaisesti yli tarpeen.

[Turmeric]

Pääsin liikkeessä testaamaan hetken verran 23" Applen näyttöä ja miniä. Kuvanlaatu oli erinomainen, mutta kun pistin Exposen päälle, niin ikkunat liikkuivat nykien. Se 32 megaa on kuitenkin aika pieni määrä muistia ja ei oikein riitä bufferoimaan jos ikkunoita on useita.

[BlueTide]

Minäkin nyt vaan höpisen ilman käytännön kekemusta (Macminillä kyllä kokemusta 1680*1050 resoluutiolla) mutta todella vaikea kuvitella, että DVI:n kautta kuva voisi olla jotenkin huono tuolla resoluutiolla ja Macminillä. Ettei vain olisi niin, että näyttöä on yritetty käyttää VGA:lla 1920*1200 resoluutiolla, mitä ko. sydeemi ei tue?

1920x1200 on kieltämättä vähän perus DVI speksien rajoilla. Tuosta johtuen ei olisi sinällään yllättävää jos jotain outoutta eri laitteilla esiintyisi.

Ja 32 MB näyttömuisti ko. resoluutiolle on moninkertaisesti yli tarpeen.

Tuo on toki riittävästi 2d kuvalle, jota varten tarvitaan 1920 x 1200 x 3 / 1024 / 1024 * 2 = n. 13MB.

Tämä tosin ei huomioi sitä, että OS X piirtää ikkunat OpenGL pintoina ja ne teksturoidaan.

[mikastus]

BlueTide:

Tuo on toki riittävästi 2d kuvalle, jota varten tarvitaan 1920 x 1200 x 3 / 1024 / 1024 * 2 = n. 13MB.

Hetkonen, mistäs tuo viimonen 2x tulee ? En nyt heti minuutissa hoksannut..
Mika

[Jamac]

Arvaan: miksikäöhän sitäs sanotaan, siis kun on kuva "nyt" monitorilla ja sitten tarvitaan toinen muistitila mihin piirretään uusi kuva ennen kuin se näytetään monitorille.?

[BlueTide]

Arvaan: miksikäöhän sitäs sanotaan, siis kun on kuva "nyt" monitorilla ja sitten tarvitaan toinen muistitila mihin piirretään uusi kuva ennen kuin se näytetään monitorille.?

Jeah, "double buffering". Jos tätä ei tehdä (sitä ei TARVITSE tehdä), niin kuva välkkyy niin helvatisti kun on liikkuvaa tavaraa ruudulla. Tai vaikka ei olisikaan.

Mä niin tiesin että joku tarttuisi tuohon.

[mikastus]

Ja sitten se tarkempi selitys, kiitos.
Systeemiväylä sun muut kyllä riittää siirtämään tavaraa ihan riittävän vilkaasti varmaankin..??
Kun ei se kuva välkkynyt silloin 10-15 vuotta sittenkään..
(Ymmärrän toki jos selitetään seikkaperäisesti..)
Mika

[Jamac]

Mä niin tiesin että joku tarttuisi tuohon.

doublebufferig

[BlueTide]

Ja sitten se tarkempi selitys, kiitos.
Systeemiväylä sun muut kyllä riittää siirtämään tavaraa ihan riittävän vilkaasti varmaankin..??
Kun ei se kuva välkkynyt silloin 10-15 vuotta sittenkään..
(Ymmärrän toki jos selitetään seikkaperäisesti..)

"Double buffering" menetelmä ei ole mitenkään uusi. Sitä on käytetty yli 10-15 vuotta ja juuri välkkymisen estämiseksi. Jotkut jopa kokeilivat käytää "triple buffering" tekniikkaa toivoen nopeuttavansa prosessia. Wormsien joku ensimmäisistä versioista taisi olla tälläinen, muisti tosin voi tässä vähän pettää...

Oletetaan, että piirrämme suoraan ruudulle. Ensimmäiseksi piirrämme taustan, joka tulee täten käyttäjän näkyviin heti. Taustan päälle tulee ikkuna. Tämän käyttäjä näkee noin nanosekunttia myöhemmin (heitetty hatusta, esimerkin kannalta tällä ei ole merkitystä). Ikkunan päälle tulee joku kontrolli, vaikka valinta lista. Tämä piirretään taas aavistus myöhemmin. Ikkunan päälle tulee ikkuna, ja sen päälle taas jotain.

Kun koko ruutu on saatu piirrettyä, piirtäminen aloitetaan alusta ja ensimmäiseksi läiskäistään se taustakuva, ja kaikki muut ikkunat ja kontrollit peittyvät. Ja sitten ne piirretään taas uusiksi. Tämä näkyy välkkymisenä, joka on sitä ärsyttävämpää mitä kauemmin tuossa piirtämisessä kestää. Ja nykyäänkin se on havaittavissa vaikka käytetäänkin suhteellisen nopeita laitteita.

"double buffering" kiertää tämän ongelman niin, että kaikki komennot piirretään muistialueeseen, jota ei piirretä näytölle. Kun ikkunat ja kaikki muut on piirretty valmiiksi, tämä lopputulos kopioidaan siihen muistiin, josta näyttö piirtää kuvansa.

Systeemiväylät ja vastaavat eivät varsinaisesti liity asiaan, mutta näytönohjaimella oleva muisti on huomattavasti nopeampaa kuin muistin käyttäminen keskusmuistista. Pääsääntöisesti 3d kiihdytetyissä tietokoneissa 3d pinnoille tulevat tekstuurit ladataan näytönohjaimen muistiin juuri tämän takia (*sigh* SGI, missä oot...). Muistia toki käytetään myös muuhun, tarvitsemme esimerkiksi tietoa myös millä syvyydellä mikäkin pikseli on. Tähän tietoon käytetään yleensä aluetta nimeltä z-buffer, mutta sen koon määrittäminen ei ole aivan yhtä yksiselitteistä.

Ihan vain vertailun vuoksi teoriaa: Näytönohjaimen ( kuvitteellinen ) muistista voidaan lukea nopeudella 256bit (väylä) * 700 MHz ( väylän nopeus ) * 2 (DDR) = n 45GB / s. Näin muistikuvan persusteella arvot ovat aika lähellä uutta Radeonia ja Geforce 7xxx sarjaa. Vastaavasti AGP 8x muistiväylä näytönohjaimen ja prosessorin välillä on luokkaa 2.1GB/s. PCI-E parantaa tätä tilannetta, mutta esimerkiksi käytiksen suunnittelussa ei voida olettaa, että immeisillä on uusimmat koneet. Ja kuten näkyy, vaikka näyttiksen arvo ei ole todellinen, niin näkeehän tuosta helposti, että liikutaan aivan eri skaalassa. Ja sanotaan nyt vaikka yksinkertaisesti, että tuolle nopeudelle on myös käyttöä.

Mä voisin muutenkin aloittaa ruinausta systeemiväylän riittämättömyydestä, mutta jos nyt ei kuitenkaan tällä kertaa..

[mikastus]

Kiitokset selvennyksestä BlueTide.

OK, ymmärrän kyllä - osittain. Ja periaatteena kuulostaakin järkevältä.

Tuo varmaankin tehtiin sitten keskusmuistissa aiemmin.
Esim. Powermacit 2MB:n tai 4MB:n näyttömuisteilla kuitenkin toimivat silloisilla sovelluksilla ihan OK. (1024, 1152, 1280 resoilla, ja miljoonilla 24 bit tai tuhansilla 16bit väreillä) Ei kuitenkaan ollut tilaa tuplabufferille noin pienillä näyttömuisteilla.
Ja toisaalta, pitäähän se tieto kuitenkin kuljettaa sinne näytönohjaimelle jossain välissä.

Tästä poislukien tietysti 3D-prosessointi (OpenGL jne..), joista en kyllä niistäkään ole perillä juuri markkinointimateriaalitekstejä enempää ;-)

Eli 1920*1200*3*/1024/1024 = 6,591 MB
Näyttö näyttää vaikkapa 80 Hz kuvaa (eli päivittyy 80 kertaa sekunnissa)
6,591*80=527,343 = n.528 MB sekunnissa
Eikö tällä jo päästä yksinkertaisimmassa tapauksessa niin välkkymättömään kuvaan kuin on kuvan näyttävä tekniikkakin ? Siis silti vaikka piirtyisi pikku palikoita tai osia millä ajastuksella tahansa.

Täytyypä yrittää ajatella noita juttuja vielä ihan rauhassa. Kumman monta mutkaa on matkassa.

Offtopicci nostaa jo näemmä päätään ;-), sori.
Eipä tästä nyt tarvitsisi sen isompaa stressiä repiä, mutta itsellä on lähinnä mietityttänyt tuon HD-videon vaatimukset koneelta ja väyliltä, ihan vaikka vaan katsoessa. Pullonkaulojen ja tekniikoiden tajuaminen auttaisi ymmärtämään ja hyväksymään erilaiset ongelmat ja rajoitukset.

Vaatimottamat laskelmani noista erilaisista kapeikoista:
1080i tökkii

Mika

[BlueTide]

Tää voi mennä off-topikiksi, mutta otetaan vaan se riki että Jamac suuttuu ja alkaa kurittaa... Näköjään meillä on osittain samoja mielenkiinnon kohteita joten mua ei haittaa asiasta jauhaminen. Tuleepahan samalla kelattua näitä juttuja taas itsekin.

Tuo varmaankin tehtiin sitten keskusmuistissa aiemmin. ... Ja toisaalta, pitäähän se tieto kuitenkin kuljettaa sinne näytönohjaimelle jossain välissä.

Totta, tuo voidaan tehdä myös keskusmuistissa. Se, missä se tehdään, ei ole efektin kannalta merkityksellistä. Itseasiassa, verrattuna siihen että joutuisit kuljettamaan päällekkäisiä bittikarttoja näytönohjaimelle kompositoitavaksi, on rajallisen väylän tapauksessa tehokkaampaa suorittaa kompositointi keskusmuistissa ja lähettää vain pelkkä lopputulos.

Tämä vain ei enää ole kovin realistista koska se 3D kiihdytys tehdään kortilla ja kuva muodostuu vasta siellä.

Eli 1920*1200*3*/1024/1024 = 6,591 MB
Näyttö näyttää vaikkapa 80 Hz kuvaa (eli päivittyy 80 kertaa sekunnissa)
6,591*80=527,343 = n.528 MB sekunnissa
Eikö tällä jo päästä yksinkertaisimmassa tapauksessa niin välkkymättömään kuvaan kuin on kuvan näyttävä tekniikkakin ? Siis silti vaikka piirtyisi pikku palikoita tai osia millä ajastuksella tahansa.

Käytännössä hankalaa. Ensinnäkin, sun täytyisi olla varma, että sä pystyt päivittämään sitä framebufferia (näyttömuisti) 80 kuvaa sekunnissa. Tämä ei ole mitenkään taattua, johtuen siitä että emme tiedä kuinka paljon mikäkin ohjelma piirtää, miten paljon prossu kerkeää tuota piirtämistä käsitellä ja kuinka nopea näytönohjain on. Toinen seikka on sitten se, että sun täytyy synkata piirto CRT monitorin elektronisuihkun paikkaan. Eli et päivitä framebufferia silloin kun suihku on puolessa välissä ruutua. Tämä tosin on ratkaistu ja V-Sync optio näytönohjaimelle tekee tämän.

Mutta tuota ylempää syytä et voi kiertää mitenkään helposti. Toisekseen tuo datavirta olettaa, että sä et lähetä kortille mitään päällekkäistä vaan ainoastaan sen lopullisen kuvan. Tää tarkoittaa sitä, että joudut tekemään kaikki mahdolliset kompositoinnit ja transformaatiot prossulla, joka hidastaa piirtämistä.

Mutta joo, jossain tietyssä ympäristössä ja tietyllä ohjelmalla sä voisit saada ton kyllä toimimaan.

Eipä tästä nyt tarvitsisi sen isompaa stressiä repiä, mutta itsellä on lähinnä mietityttänyt tuon HD-videon vaatimukset koneelta ja väyliltä, ihan vaikka vaan katsoessa. Pullonkaulojen ja tekniikoiden tajuaminen auttaisi ymmärtämään ja hyväksymään erilaiset ongelmat ja rajoitukset.

Jep, niin minuakin, lähinnä miten tuommoista kuvamateriaalia voidaan käsitellä editissä ja pakkaamattomana. Joskus tässä valitin, että semmoista softaa ei ole Macille, erinäisistä syistä. Toki tuota studiossa pääsee näpräämään kalliilla laitteella, mutta se ei ole urheiluhenkistä :-).

DISCLAIMER: Jos joku rahoittaa ja haluaa 24p filkkatason (HD, 2k+) reaaliaikaisen EDITOINTI softan niin ottakaa yhteyttä. Riippuen vaatimuksista mä voin tehdä tuollaisen luokkaa 6kk jos vaatimuksista ja rahasta päästään yhteisymmärrykseen. Omalla ajalla (ilmaiseksi) en varmaan saa tehtyä kun tulee muu elämä väliin.

Takaisin vastaukseen. Kun puhutaan kuluttajaformaateista, kuten H.264, väylistä ei niin hirveästi tarvitse välittää. H.264 kodekin ensimmäinen pullonkaula on prosessori.

Vaatimottamat laskelmani noista erilaisista kapeikoista:
1080i tökkii

Noi oli päällisin puolin ja ilman ajatusta luettuna ihan ok laskelmat. Ei kovin tarkkaa, mutta suhdeluku oli niin riittävän selvä, että niistä voi vetää johtopätöksiä kuten yllä.

Pelkän datavirran seuraamiseen täytyy selvittää seuraava kulku.

Kovalevyltä muistiin. Eli keskimääräinen pakatun materiaalin lukunopeusvaatimus. Tiedoston koko / kestolla voisi olla tarpeeksi hyvä approksimaatio ja tämä sitten suhteutettuna kovalevyn lukunopeuteen + overhead. Pakattu data muistista prosessorille. Prosessorin aika purkaa pakkaus ja kopioida se takaisin muistiin. Muistista prosessorin kautta näytönohjaimelle.

Tähän kaikkeen täytyy lisätä overhead, ja tuntea h.264 kodekin toiminta paremmin kuin minä tunnen. Esim OS X piirtää ikkunat OpenGL pintoina, joten tuo video on itseasiassa tekstuuri. Ja tämä tarkoittaa että sinne näyttikselle menee paljon muutakin kuin pelkkä video.Toisekseen, voi olla mahdollista käyttää näyttistä purkamaan tuota H.264 kuvaa. En tiedä tehdäänkö näin nykyisillä Maceillä vai ei.