[Mplayer-felhasznalok] AMD64

[Arpi]

Hi,

> "Arpi" <arpi at mplayerhq.hu> írta 2004-12-05 14:03-kor:
> > persze hogy tud, nem mondtam hogy nem.
> > 
> > a baj az, - ezexerint nem sokat programoztal assemblyben - hogy
> .gy van, assembly-ben nem szoktam :-P
> 
> > maskepp kell megirni 32 bites cpura es maskepp a 64 bitesre az
> > assembly kodot. es mivel az osszes mmx/sse optim assemblyben van...
> > es ezek nincsenek megirva 64 bitre, csak 32-re.
> Ahá. *bólogat* .rtem.

vagy legalabbis ugy teszel :)

> > > Ráadásul ebben a szerverben csak egy ilyet mutat az lspci:
> > > 0000:01:04.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
> > vidix-el elmenne
> De volna értelme? .gy értem, h. "hw-bõl adja" azt a gyorsítást?

mar miert ne lenne?

> > > > a win32 codecek viszont 100% hogy nem fognak 64 biten menni.
> > > Szerintem nem lenne nagy poén elérni, hogy menjenek...
> > > Bármikor tudok pl. olyat csinálni, hogy debootstrap-el egy i386-os debiant
> > > felinstallálok egy könyvtárba, és chroot -al belemegyek, és futnak csont
> > > nélkül a chroot-ban levõ i386-os binárisok.
> > > Vagyis csak azon múlik, hogy be tudja-e tölteni a "libeket"...
> > hat figy.
> > egy app (vagy inkabb taszk, processz) vagy 32 bites, vagy 64.
> > ha 32, akkor minden (app, libekk, .dll-ek) 32 bites. ha 64, akkor
> > minden (app, libek, dll-ek) 64 bites kell legyen.
> > 
> > olyat nem lehet, hogy egy 64 bites kod meghiv egy 32 bites fuggvenyt
> > (egy 32 bites .dll-bol).
> Akkor, hogy picit jobban értsem a szitut: a chroot parancs ilyenkor azért
> tud mûködni, mert a chroot() után csinál egy exec()-et is, és a saját
> 64-bites "taszkját" kicseréli egy 32-bites "taszkra"?

nyilvan.
es a chrooton belul meg mar 32 bites minden, a libek is, appok is.

> > esetleg azt lehetne, hogy irni egy daemont, ami 32 bitesre van
> > leforditva, ez tolti be a .dll-t es mondjuk tcp/ip-n at szolgaltatja
> > a codec funkcioit, amit a 64 bites mplayer processz elerne... jo lassan...
> > de ez uber-gany.
> .s ha "egyéb" kommunikáció pl. unix domain socketen megy, és a gyorsan
> átpakolandó adatok meg shared mem-en?

lehet ganyolni, de attol meg lassu marad...
lasd -vo x11

> > nem, a tobbieknek halvany fogalma van arrol hogy mi is ez a x86-64.
>  :-)
> 
> > > BTW.: .rpi, ha már itt tartunk kiváncsi lennék a véleményedre errõl a
> > > kártyáról:
> > > 0000:02:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100
> > > QY [Radeon 7000/VE]
> > > 
> > > Ez mennyire tud hw-bõl bármit? Mert az egyik opteronos szerverünkben ilyen
> > vidix elmegy vele, 3d-re nem nagy cucc...
> > nekem ilyeb van a munkahelyi gepemben.
> Ok. .rtve.
> 
> > > van... Jól gondolom, hogy ezen talán már van értelme kisérletezni, vagy
> > > pl. al3x-et fegyverrel melléjetuszkolni? :-) (pls. most tekintsünk el a
> > > személyes viszonyotoktól)
> > mi celbol?
> Nu, nem azér' hogy lelõjem, mer' akkor takaríthatnám a monitort :-)
> Hanem, hogy a "hiányzó részeket" meg tudja rajta írni, és ki tudja

mi hianyzik? a vidix muxik vele most is.

> tesztelni. Pl. a 64 bites sse2 meg 3dnowext és stb. optimalizációkat.

alex? na ne rohogtess mar...


A'rpi / MPlayer, Astral & ESP-team

--
Girls are like internet domain names, the ones I like are already taken.