Hírek | Archívum | Fórum | IRC | Amiga | AmigaOS | FAQ | RSS

 - Fórumok - Keresés - Statisztika - Szabályzat - Pegasos.hu fórum
forum.amigaspirit.hu / Fejlesztés / Általános fejlesztési kérdések
<< 1 ... 9 . 10 . 11 . 12 . 13 . 14 . 15 . 16 . 17 . >>
Szerző Üzenet
BSzili
Tag

# Elküldve: 2017. Máj. 21. 11:49 - Szerkesztve: BSzili


Ha jól tudom az Intel azért használta az FPU regisztereket MMX-hez, hogy ne kelljen új utasítás az MMX regiszterek lementéséhez. Elég barbár megoldás csak azért, hogy működjön a már kint lévő Windows verziókon :D Az SSE-nél már nem bohóckodtak ezzel, ott volt külön FXSAVE és FXRSTOR utasítás.
Az MMX valóban nem a SIMD csúcsa, az SSE mindent tud amit az MMX és tud float-okkal is dolgozni. MMX-et főleg color blending meg DSP effekteknél láttam használva (az első Unreal Engine például használja több helyen is).

Chain-Q
Divatamigás

# Elküldve: 2017. Máj. 21. 12:15


A korabeli demoscene is használta, és valóban, főleg ARGB bitmapok blendingjéhez, ami jól ment az akkoriban domináló 320x200, truecolorban futó késői DOS-os PC demókhoz. Így annyira nem fájt az MMX-et együtt használni az FPU-val, mert ugye leszámoltad a geometriát floatban, de a raszterizer meg fixed pointtal ment, ergó miután az összes érték megérkezett fixpointra, átváltottad a procit MMX módba, aztán gyia, ment a képkirajzolás, blending, mittudomén, amihez nem kellett FPU, vagy legalábbis meg lehetett oldani nélküle. Végül újra visszaváltottad FPU módba a következő kör geometriához.

Logostino
Tag

# Elküldve: 2017. Máj. 21. 17:31 - Szerkesztve: Logostino


Tudom hogy a kutya nem használta annak idején , de ha az MMX ment akkor már csinálhattak volna 3DNow kompatibilitást is, és lett volna floating point SIMD is. Bár mit is beszélek, még egy sima FPU-ra sem futja... :S :)

"hogy az MMX-et elég nehéz C-ből használni"
Most egy ideje nem tájékozódtam a témában, de én nem emlékszem hogy nagyon volt olyan SIMD amit nem úgy kellett C-ből használni hogy egy assembly utasítás = egy C utasítás. Még az Intel C++ -ban is csak intrinsics-ekkel lehetett/lehet? SSE(akármennyit) használni.

Chain-Q
Divatamigás

# Elküldve: 2017. Máj. 21. 17:34


A 3DNow tok jo volt, csak azert nem hasznalta senki mert AMD only volt. Egyebkent a legujabb AMD procik sem tamogatjak mar, de most mar nem is kell, mert SSE akarhany megoldja ugyanazt.

Logostino
Tag

# Elküldve: 2017. Máj. 21. 17:43


Quoting: charlie
Egyebkent a legujabb AMD procik sem tamogatjak mar, de most mar nem is kell, mert SSE akarhany megoldja ugyanazt.


Nyilván ma már nincs létjogosultsága. Csak elmélkedek.

BSzili
Tag

# Elküldve: 2017. Máj. 21. 20:09


A modernebb C fordítók tudnak olyat, hogy x87 kód helyett SSE-t fordítanak a lebegőpontos műveletekre, meg van "Automatic vectorization" is, de azért meg vannak a korlátai:
https://locklessinc.com/articles/vectorize/

Chain-Q
Divatamigás

# Elküldve: 2017. Máj. 22. 04:17


Manapság minden x86-os fordítónak tudni illik SSE2-t fordítani x87 helyett, mivel a 64bites Windowsban a Microsoft deprecated státuszba rakta a hagyományos FPU-t, ergó az elvárás, hogy ne azzal számolj hanem SSE2-vel. Így a Free Pascal is tud SSE2-s float kódot fordítani. Persze az autovektorizáció más tészta...

Logostino
Tag

# Elküldve: 2017. Máj. 23. 09:00


Quoting: charlie
mivel a 64bites Windowsban a Microsoft deprecated státuszba rakta a hagyományos FPU-t

Na ez nekem totál kimaradt. Tehát akkor ha én csak két single-t akarok összeadni, akkor 64bit alatt simán ADDSS-re fordul a kód FADD helyett?

Azért kíváncsi vagyok meddig lehet még foltozni az x86-ot...

dh1
Mr. DTP

# Elküldve: 2017. Máj. 23. 23:18


Kizart, en FADDi vagyok, tudnek rola ... muhahahahaaaaaa :D

Chain-Q
Divatamigás

# Elküldve: 2017. Máj. 23. 23:31


@Logostino:
Elvileg igen. Linux alatt mondjuk tovabbra is tamogatott az x87 FPU, szoval lehet h. a Linuxos GCC mashogy viselkedik. (Nem tudom fejbol.)

Yellow Dog
Tag

# Elküldve: 2017. Máj. 25. 20:00


PC-re van (talán Topaz) Amiga font?

Chain-Q
Divatamigás

# Elküldve: 2017. Máj. 25. 20:58


https://github.com/rewtnull/amigafonts ?

Yellow Dog
Tag

# Elküldve: 2017. Máj. 25. 21:40


Köszönöm, ezeket megtaláltam, de hiába másolom a Fonts mappába, nem jelennek meg pl. Word-ben, illetve a "Betűkészletek"-ben sem. És jobb gombra sem hozza fel a telepítés lehetőségét.

Chain-Q
Divatamigás

# Elküldve: 2017. Máj. 25. 22:09


Readme?

"Go to 'control panel -> fonts -> file -> install new font'. Browse to the fonts and select the ones you want to install and click 'OK'."

Yellow Dog
Tag

# Elküldve: 2017. Máj. 25. 22:26 - Szerkesztve: yellowdog


Win7 alatt nekem a Fonts ablakon nincsenek menü elemek, csak intézőben a jobb gombra jön fel a telepítés pl. egy TOPAZ8.FON esetében (ez is Amiga), de ha a fenti TTF-ekre megyek akkor nem jelenik meg a lehetőség :-(

Szerk.:
Oké, hülye voltam, a TTF társítva volt az ACDSee programhoz, nem a font nézőhöz...

dh1
Mr. DTP

# Elküldve: 2017. Máj. 25. 23:10


Amiga Maniaban a tartalomjegyzek Topazzal van! ;)

Yellow Dog
Tag

# Elküldve: 2017. Máj. 26. 06:29


Helyes :-)

Chain-Q
Divatamigás

# Elküldve: 2017. Máj. 28. 01:50 - Szerkesztve: charlie


Ha mar itt ment a Vampire vs. 68060 tema:

Ma osszeultunk Alb42-vel a berlini Amiga Klubban. Ott volt a Vampire-ja, es az en 060-am. Leforditottuk ugyanazt a SciMark-ot es nehany mas szoftvert a Free Pascal softfpu-javal, illetve a nativ 68060/FPU koddal, mivel Alb42-nek olyan hirei vannak a Vampire hazatajarol, hogy vizsgalgatjak a softFPU lehetoseget, vagyis szoftverbol emulalni az FPU-t a Vampire-on. Hat mi most kiprobaltunk egy ilyet, ha mar az FPC tud szoftveresen, FPU nelkul lebegopontos szamokkal dolgozni.

A vegeredmeny nem tul meglepo: a szetfikazott, "doglassu" '060 FPU megette reggelire a Vampire-t. Atlag 50x (otvenszer) gyorsabb a hardveres "lassu" 68060 FPU, mint a szoftveresen a Vampire-on futu softFPU. Kulonbozo taskokban 5-200x-os kulonbsegek voltak a 060 javara, attol fuggoen hogy az adott benchmark mennyire hasznalta a lebegopontos egyseget.

Persze kozismert, hogy a Free Pascal softFPU-ja eleg lassu, meg egy softFPU-hoz kepest is (mondjuk kicsit beleoptimalizaltam ma, gyorsitottam rajta vagy 30%-ot, es ezek a szamok mar a gyorsabb verzioval jottek ki). Tetelezzuk fel, hogy valaki ir 10x gyorsabbat. Sok sikert ehhez, de tetelezzuk fel. Meg akkor is 5x lesz lassabb mint egy 060/50. 060/10. Na csak ennyire nem kell az FPU, a lebegopontos szamokhoz.

BSzili
Tag

# Elküldve: 2017. Máj. 28. 09:52


Ez röhej, hogy softFPU-ról beszélnek amikor állítólag ott a 060-nál 1000x gyorsabb Apollo Core FPU. Egyszerűen nem tudom elképzelni miért akarnak szoftveresen FPU-t emulálni, hacsak nem azért mert tényleg nem fér bele az FPGA-ba, vagy nem sikerült nekik 68k kompatibilis FPU-t csinálni. Az a gond hogy nem hajlandóak egyenesen lekommunikálni mi a helyzet, csak a hülyítés megy.

Chain-Q
Divatamigás

# Elküldve: 2017. Máj. 28. 15:05 - Szerkesztve: charlie


Ezt az "1000x gyorsabb" allitast is vizsgalgattuk. A 060-as mereseinket alapul veve kiszamoltuk, hogy mekkora orajelen kene jarni a Vampire-nak jarni, es/vagy hany utasitast kene parhuzamosan vegrehajtani, hogy kijojjon az 1000x gyorsabb. Meg hogy Gigaflops nagysagrendu legyen a lebegopontos teljesitmeny, amirol szinten szo volt (persze azota alaposan toroltek a threadet...). Kijott, hogy kb. 10 utasitast kene egyszerre vegrehajtani a Vampire FPU-janak parhuzamosan, ha a kozelebe akar kerulni ennek az erteknek. Ez meg akkor is egy nagysagrenddel off, ha a SIMD lebegopontos utasitasokrol beszelgetunk amik pl. 4 utasitast vegeznek el egyszerre.

Alb42 azt is nehezmenyezi, hogy az Apollo Core-hoz mindenhol fel van sorolva hogy FPU FPU FPU a feature listaban, kiveve valami wiki oldalon, ahol megcsillagozott aprobetuben irjak, hogy "coming soon". Coming soon, 2014 ota.

Ismetlem, nem az a bajom, hogy a Vampire tudja-e vagy nem tudja az FPU-t. A kodositessel meg a vetitessel van bajom, meg hogy kokemenyen "cenzuraznak" barkit, aki kenyelmetlen kerdeseket tesz fel. Ahogy BSzili is irta, hogy csak a hulyites megy.

Chain-Q
Divatamigás

# Elküldve: 2017. Máj. 28. 15:25 - Szerkesztve: charlie


Alb42 is irt egy blogpostot a tegnapi eredmenyekrol, meg tobb konkretummal:

https://blog.alb42.de/2017/05/28/to-fpu-or-not-to-fpu/

(Szerk: Mellekesen megjegyzem, hogy ennek milyen uzenete van pl. az A1222/Tabor-ra es az inkompatibilis FPU-jara nezve, hogy azzal majd emulaljak a sima PPC FPU-t, azt is kinek-kinek belatasara bizom. Valszeg nem lesz 50x lassabb, de hogy nem lesz gyors (ellenben lassu lesz) az biztos.)

anchor
Tag

# Elküldve: 2017. Máj. 28. 17:34


na pont ezt akartam belinkelni ide :)

BSzili
Tag

# Elküldve: 2017. Máj. 29. 08:25


Ja, még az Apollo Core honlapján is ott büszkélkednek a double/extended
fully pipelined FPU"-val. Most ehhez képest eljutottunk a "nem kell extended", sőt "jó lesz a softfpu is" verzióhoz a fórumokban. Gunnar panaszkodik, hogy állandóan az FPU-val zaklatják, ugyanakkor állítja hogy nincs érdeklődés az FPU iránt. Most akkor melyik az igazság? Vagy ugyanaz a pár ember "zaklatja" megállás nélkül? Aligha hiszem.

Apropó Tabor, érdekes a párhuzam a két rajongótábor között. Miután kiderült, hogy nem lesz kompatibilis FPU, hirtelen mindenki rájött, hogy mennyire felesleges, és tulajdonképpen nekik nem is kell. Biztosan van valami elnevezése ennek a megerősítési torzításnak :)

Chain-Q
Divatamigás

# Elküldve: 2017. Máj. 29. 08:50


Na ebbe a valosagtorzitasi effektbe meg az amigasokba ne menjunk bele, orakig tudnek rantelni rajta... De csak egy eset a minaprol: szinten a berlini Amiga Klubban sikerult egy OS4 usernek belekotni a MorphOS "Taskmanager"-ebe, azzal a felkialtassal, hogy ez mar miez, egy "Taskmanager" az ilyen Linuxos dolog, es ez is bizonyitja hogy a MorphOS az ilyen nem amigas dolog, bezzeg az OS4.

Visszakerdeztunk, hogy ugyan a Scout-ban levo Task lista ablakot vajon latta-e mar. "Lattam, de az mas." "Akkor jo..."

BSzili
Tag

# Elküldve: 2017. Máj. 29. 09:59


"A feature hiánya is feature" - tartja a népi Amiga közmondás.

AliveMOon
Tag

# Elküldve: 2017. Máj. 29. 10:32 - Szerkesztve: alivemoon


Szerintem az lehet a háttérben, hogy AGA és Pamela miatt fogy a hely erősen az FPGA-ban. Közben látják, hogy problémásan fog elférni, a korábbi FPU kódjuk.

Chain-Q
Divatamigás

# Elküldve: 2017. Máj. 29. 11:38 - Szerkesztve: charlie


Az remek, ezt mondtam enis vagy 2 hete, hogy valszeg nem fer az FPU bele mar, azert megy a mismasolas. De ezt miert nem lehet megmondani? Miert kell a kodosites? Barmilyen technikai okot megertek... Amugy meg, miert nem lehet opciot adni a nepnek, ha mar Pamelalucyellie meg az osszes ribanc a Dallaszbol kepbe kerult. Van aki FPU-t akarna, van aki AGA-t meg megtobb RTG ficsort. Ezzel nincs semmi baj. De ha tenyleg csak ennyi a problema, miert nem lehet kiadni ket kulonbozo core-t? Miert kell helyette vadul azt bizonygatni, hogy az FPU hulyeseg.

Na mindegy. Koltoi kerdesek ezek.

AliveMOon
Tag

# Elküldve: 2017. Máj. 29. 12:22 - Szerkesztve: alivemoon


Szerintem tök egyszerű. Nem akarnak 2 változatot menedzselni.
A másik szempont, hogy maga a csapatnak nem fontos az FPU. Inkább AGA-s játékokkal akarnak előbb játszani. Aztán ha az megvan majd tökölnek az FPU-val.

BSzili
Tag

# Elküldve: 2017. Máj. 29. 12:23


Én is pont erre gondoltam, hogy az AGA chipset emuláció nekem nem hiányzik az A500-ból, és máshol se láttam hogy nagyon tolonganának érte. Scandoubler-ből is van választék, szóval ennek majd a standalone verzióban lesz jelentősége, ahol nincs a kártya alatt egy Amiga.
A 16 bites audio már izgalmasabban hangzik, de ha Pamela és FPU között kell választani, akkor 10 mosógép-szerelőből 9 még mindig az FPU-t ajánlja.

AliveMOon
Tag

# Elküldve: 2017. Máj. 29. 21:23 - Szerkesztve: alivemoon


Én mondjuk x64-en assemblyben gyakorlatilag kizárólag SSE utasításokat használom, szerintem nem lenne hülyeség, ha csak annyit csinálnak meg, hogy lebegő pontos összeadás, szorzás, reciprok, pow, cos és acos legyen amiből egyszerre négyet is megtud csinálni, esetleg mad és dot, meg sufle oszt csókolom, többi mehetne szoftveresen.

<< 1 ... 9 . 10 . 11 . 12 . 13 . 14 . 15 . 16 . 17 . >>
forum.amigaspirit.hu / Fejlesztés / Általános fejlesztési kérdések
 
 

Powered by bulletin board software miniBB™ © 2001-2019