[asembler] - koprocesor

Printable View

Zobrazit 100 příspěvků z tohoto threadu na stránku

09.01.2004, 16:15
Glottis

[asembler] - koprocesor

cau, mam problem
zkosuim pocitat neco v koprocesoru a nejak to nechodi. napr zkusim tot a to to pocita spatne

Kód:

finit fild y fild f320 fmul fild x fadd fistp di_n fwait

a pritom by to melo byt podle me stejne jako tohle a to pocita jak ma jen bez kopru

Kód:

mov ax,y mov dx,y shl ax,8 shl dx,6 add ax,dx add ax,x add ax,cx mov di_n,ax

promene jsou takto definovane

Kód:

X Dw 0h Y dw 0h DI_n dw 0h F320 DW 320

nevite nekdo? neni u kopru nejaka bota? sakra to musi fungovat :( potrebuju v nem siny a cosiny a kdyz nespocitam ani tole sme nahranej :(
14.01.2004, 10:54
RayeR

Na chybu kopru bych to hnbed nehazel (pokud nemas nahodou stare P60 :)
Bohuzel s koprem sem si nikdy nehral, tak neporadim, ale docela by me to i zajimalo. BTW jakej pouzivas ASM prekladac?
14.01.2004, 15:46
Glottis

uz to mam vyresene, sice ne k plne dokonalosti ale mam.

pouzivam tasm. turbo assembler, ze

k te chybe. bylo to rukama, jak jinak. potreboval sme arctan jenze arctan jakozto FPATAN nedela jen ten arctan ale dela i deleni, takze to ma dva argemnty. ty to podeli a udela arctan.
ten ukazkovej kond jak sem zjistil nefunguje jen v tom jednom mem programu. nevim proc ale pocita to jen pro 32000 pixelu co tam davam souradnice, nechapu, ale to je fuk, to ponasibim v v normal cpu. asi nejak blbe nastavene ds nebo es nebo cokoliv :/ kazdopadne z toho vznikl nejpomalejsi rotozoomer :))))
14.01.2004, 18:34
miho

Citace:

Původně odeslal Glottis

ten ukazkovej kond jak sem zjistil nefunguje jen v tom jednom mem programu. nevim proc ale pocita to jen pro 32000 pixelu co tam davam souradnice, nechapu, ale to je fuk, to ponasibim v v normal cpu.

Ty dva uryvky kodu nejsou ekvivalentni. Koproc, pokud vim, ocekava cislo se znamenkem takze ti tam muze dojit po prekroceni 32767 k rozsireni vysledku na dvojite slovo (nesouvisi to s tim problemem, ze ti to funguje jen do 32000?). Oproti tomu v te prvni verzi pocitas jako bys mel neznamenkove cislo.

Chtel jsem se zeptat zda jsi delal testy rychlosti obou verzi? Mne prijde ten dvojity posuv a secteni jako rychlejsi nez to pasirovat pres koprocesor...
14.01.2004, 21:39
RayeR

Glottis> Muzes prozradit na cem to robis, ze delas nakou grafiku pres FP funkce? Se mi zda, ze to asi pak nebude nejrychlejsi. Ja bych nejake ty vyssi operace sveril radeli GCC kompilatoru at dela co umi, pokud teda netrvas na pure ASM (asi kuli male velikosti).

Ja sem jednou zkousel delat takovy malicky programek v ASM, ktery nakresli Svejcarskou vlajku (byla to soutez Vyhen coding compo) a docela mi to stacilo. Muj kod mel asi 78 Bajtu, zatimco nejlepsi borci to meli asi na 40 ;D
Takze po te, co sem narazil na limity Pascalu sem se donutil do Cecka...
14.01.2004, 22:22
Glottis

miho: to me nenapadlo ze by mi to mohlo pretect! na tom neco je. zkusim. kdyz to pujde zkusim posoudit rychlost ale ty posuvy budou asi rychlejsi. asi jak na jakem procesoru. p4 a tak maj kopr uz vymaklej, nejspis :) apson co sem slysel

RayeR: aaaale delam semestralku na strojove orientovane jazyky. sem si vybral ze udelam rotozoomer tak ho pisu. musi to byt v asm. a nebo vkladany asm ale rotozoomer je tak jednoduchej ze to je lepsi napsat pure asm. jiank mas pravdu, neni to nejrychlejsi :/ naopak, je to nejpomaljis :))) na p3 mi to bezi tak nejak OK ale na p200 uz to je slideshow

tady se mzuete mrknout :) http://michal.inorg.net/asm/sem/
14.01.2004, 22:36
Glottis

mno tak je to opravdu tim intem ze ho bere zapornej a jen do 32000. takova blbost a ja na to zapomenu.

jinak subektivne se mi zda ze ty posuvy jsou rychlejsi, toci se to o kapaaanek rychleji ale porad nic moc. tam je pruser pocitani te rotace. je tam arctg a sin a cos a to fakt trva :( lepsi by byli tabulky predpocitanych hodnot ale zase kolik by tech hodnot muselo byt, ze, prece jen dva pixeli od sebe to je minimalni zmena uhlu.
tady je kod jak to rotuju :) je to osklive :) ale kdyz nekoho napadne jak to zrychlit muzu to zkusit. kdyz nenapadne tak je to fuk. to by bylo uz jen pro me aby ztoho nebyl nejpomalejsi rotozoomer :)

Kód:

PUSHA MOV AX, @DATA ; NASTAVÍ SPRÁVNÝ DATA SEGMENT MOV DS, AX FINIT FILD F160 ;POSUN NULOVEHO BODU FILD XI1 FSUB FIST XI1 FILD F100 FILD YI1 FSUB FIST YI1 FPATAN ;VYPOCET UHLU BODU ALFA = ATAN(X/Y) FLD INCANGLE FADD FSTP ALFA FILD XI1 ;VYPOCET VZDALENOSTI OD STREDU FILD XI1 ;SQRT(XI1*XI1 + XI2*XI2) FMUL FILD YI1 FILD YI1 FMUL FADD FSQRT FLD SCALE ;PRIPADNE ZVETSENI ZMENSENI FLD INCSCALE FADD FMUL FISTP R FILD F160 ;POSUN NULOVEHO BODU ZPET FLD ALFA ;VYPOCET NOVYCH SOURADNIC FSIN ;R*SIN ALFA FILD R FMUL FSUB FISTP X1 FILD F100 FLD ALFA FCOS ;R*COS ALFA FILD R FMUL FSUB FISTP Y1 FWAIT MOV AX,Y1 ;320*Y+X MOV DX,Y1 SHL AX,8 SHL DX,6 ADD AX,DX ADD AX,X1 MOV DI_N,AX POPA
14.01.2004, 23:06
miho

Mas to hezke. Pripomnelo mi to demicka na amize :-)

Kreslis predpokladam primo zapisem do segmentu $a000?

Ty predpocitane fce to neni spatny napad. atan pocitas pro hodnoty x a y obe promenne v rozsahu velikosti obrazu. Cela tabulka se ti vejde do segmentu tak proc jeste vahas? ;-) Usetris deleni a arkustangentu to je oproti vypoctu offsetu do tabulky (v podstate ty stejne posuny jako na konci) cela vecnost.
To stejne pro pocitani vzdalenosti (2xnasobeni, scitani a odmocnina).
Od ceho ty procesory ty dodatecne segmentove registry maji :-)
Sinus takto nezoptimalizujes ale staci ti zase jen ctvrt periody, zbytek jsou symetrie. Cos je posunuty sinus.
Bez do toho, drzim ti palce :!:
14.01.2004, 23:26
Glottis

jeste je jedna rotace :) brutalne rychla

a to tato

x=x´-y´*incalfa
y=y´+x´*incalfa

sice to neni az tak presne ale co :) bohuzel se mi to nari nejak rozume rozjet. jen to tim otocim asi o 90stupnu ale je to rychlejsi asi 100 000 :))) jako opravdu. stim predpocitanim to prad nevidim tak dobre. do segmentu se mi to asi nevejde. protoze obyc float ma 4byty, leda ulozit jen ctvrtinu a uhly jsou pak symetricke. uvidimjak bude cas a chut, odevzdavam uz v patek takze moc casu neni :)
jj kreslim primo kopii do a000h
15.01.2004, 09:57
RayeR

Glottis>
Pekny, na nasem skolnim P4 to bezi asi 5fps ;D
Za ty tabulky bych se docela premlouval, jednou sem dal takovy mikro demo, ktery melo bezet na XT (bez kopru), byla tam rotace 3D krychle, tak sem si udal tabulku sinu pro kazdej stupen a jak to panecku frcelo. Tady byde asi potreba vic hodnot, ale myslim ze by se to do 64k veslo.

Schvalne to zkusim napsat v C a uvidime kolikrat to bude rychlejsi. Akorat to nebude mit 1,5kB...

Ale nenech se odradit, ja ASMisty docela obdivuju, uz bych na to nemel nervy... (max tak na nakym mikropocitaci, ale to je zas vo necem jinym)

Jinak muj oblibenej prekladac na assembler je NASM.
15.01.2004, 11:13
Glottis

nasm me nejak moc neuchvatil

btw na p4 5FPS :)) to to na me p3 jede mnohem rychleji :)
15.01.2004, 13:03
RayeR

Tady sou "jen" 1,5GHz P4, schvalne to zkusim este pustit doma. Jinak NASM se hodi kdyz delas naky programky do BIOSu, nebo MBR, kde chces primo flat binary a ne com/exe.
15.01.2004, 13:11
Rainbow

Na Cyrixe mi to ide asi 4 FPS, takze ta P4ka by sa mala hanbit ;D
15.01.2004, 13:38
Glottis

je to podivne :) na p100 mi to beha asi 2FPS (odhadem), na 486 33 tak neco pod 1FPS. na mojim uz se to toci hezky, ve skole na p4 1,5 neco mezi tou p100 a mojim hodn edobre to beha v jedne ucebne kde jsou nejake 500ky snad a bratrovy s p4 1,7 to beha hur nez me. zajimalo by me co to brzdi :) jestli pamet grafiky take? mno je to zajimave :)
15.01.2004, 13:58
miho

Tento programek bude na P4 urcite pomerne pomaly protoze pouziva FPU. P4 ma bohuzel jen jednu plnohodnotnou FPU jednotku (P III a Athlony maji dve) a spoleha na SIMD instrukce.

Kdysi jsem napsal clanecek na toto tema
http://www.zive.cz/h/Testcentrum/Ar....AI=2073&CHID=3
(psano pro prumerneho ctenare zive.cz, pocitejte s tim :-) )
15.01.2004, 14:32
RayeR

Me se zda ze to nebude jen v CPU ale prave asi i dost v prenosu do VRAM. Tady je naka integrovana nvidia Vanta=sacka, a ma to zrejmne sdilenou pamet, tazke proto asi.
15.01.2004, 14:35
Rainbow

P4ka je na normalne veci slaba...
15.01.2004, 15:51
Glottis

peknej clanek
udivuje me ze by p4 nemela na posuvy barell shifter chmmm

a nenni nekde nejakej tutorialek jak na sse a mmx instrukce v asm?
16.01.2004, 00:11
RayeR

Tak sem to poustel na mym stroji a bezi to jakstaks plynule, rozhodne lip jak na tom skolnim stroji. Ale videl bych to fak v ty gfx, ne v P4. Jinak clanek byl dobrej...
16.01.2004, 11:25
Rainbow

IMHO to musi bezat nezavisle od grafiky bez problemov - to by malo aj na standardnej IBM VGA alebo Trident 9000 behat priblizne rovnako. Ked si spomeniem, co dokaze na 486ke s ISA grafikou robit demo Second Reality :-)
17.01.2004, 03:49
RayeR

Tak sem zkousel neco naprogramit v C, sice to rotuje rychle (rychles nez refresh monitoru), ale je to naky buggy, v tom obraze sou pri natocenim jinym nez 0,90,180,270... prazny pixely. Ja sem na to pouzil uz napsanou fci na kresleni obecny cary, takze rotuju jen pocatecni a koncovy body tech car, ktery se misto konstantni barvy krmi radkama z toho obrazku, jenze proste nak nesedou presne jedna vedle druhy. Asi uz bych se na to mel v tuhle hodinu vys.rat :idea:
17.01.2004, 10:13
Glottis

:) nj kreslit carou to nejde. a kdyz po pixelech tak pro cilovej pixel pocitat zdrojeovej a ne naopak
18.01.2004, 03:19
RayeR

Sakra, tak by me zajimalo, kde se bere ta chyba. Zistil sem, ze pri nepravym uhlu obcas dojde k tomu, ze se spocitana sourarnice, napr y posune o 1 driv nez by mela a na obrazovce pak zustane neprekresleny bod, tj prosvita pod nim pozadi. Dale pak zas dochazi k tomu, ze se nektery bod prekresli 2x, coz se v obraze okem nepozna, vysledkem je toto:

http://www.volny.cz/xfer/4all/bug.gif
(zvetseny vyrez)
Rozlozeni tech neprekreslenych bodu zavisi na uhlu, rek bych ze nejvic jich je tak pri 60 stupnich. Tohle bylo tusim pro 20 stupnu.

Stejnej problem samozrejme mam i pokud se pokousim nakreslit jen natocenej obdelnik.

Dalsi vec, co by se mela resit je pixel aspect ratio, pri ty rotaci totiz obraz nevypadal pravouhly.

Zistil sem, ze kdyz ten obraz trochu zmensim (staci tak na 80%) tak se diky vicenasobnymu prekreslovani zaceli ty prazny mista, ale neni to rozhodne cisty reseni.

Jinak ted pouzivat tuhle transformaci, po bodech (floaty):

Kód:

for (j=0; j<img.yres; j++) for (i=0; i<img.xres; i++) { x=mag*(i*cos(angle)-j*sin(angle)); y=mag*(i*sin(angle)+j*cos(angle)); vesa_putpixel(x,y,img.p_imgbuf[i+j*img.xres]); }

Tady je pak muj programek:
http://www.volny.cz/xfer/4all/rotate2.exe
a obrazek:
http://www.volny.cz/xfer/4all/a1.tga

Rotuje to po 1 stupni se zaplym vsync;

Jo este, u tebe sem koukal, ze ten obrazek taky nevyplnuje celou obrazovku, ac je 320x200 a zkousels co se stane kdyz pred kazdym snimkem smazes VRAM?
18.01.2004, 09:10
Glottis

mazat vram sem nezkousel.

me prijde ze to prave delas obracene nez bys mel, proto ti tam vznikaj ty dirky. ten tvuj algoritmus pocita souradnice kam bude keslit, ne? zkus to obracene. pro souradnici kam kreslit pocitej souradnice co budes kreslit.

kdyby jsi necekal na retrace jak by se to tocilo rychle? 1° je asi 0,017 radianu coz sem tam mel krok take (priblizne, mel sme tam 0,01). tak jestli to je rychlejsi nebo ne.
18.01.2004, 23:50
RayeR

Citace:

Původně odeslal Glottis

mazat vram sem nezkousel.

Notak si to schvalne zkus. Nejlip indexem 255. Pokud pozadi nemazu, tak
to vypada taky pekne, protoze pod tema dirkama prosvita puvodni obraz takze to nepoznas.

Citace:

Původně odeslal Glottis

me prijde ze to prave delas obracene nez bys mel, proto ti tam vznikaj ty dirky. ten tvuj algoritmus pocita souradnice kam bude keslit, ne? zkus to obracene. pro souradnici kam kreslit pocitej souradnice co budes kreslit.

Ano pocitam KAM budu kreslit. Nejak nechapu jak by to melo vypadat obracene. Kdyz ted zapomenu na rotaci obrazku, predstav si, ze bych stel nakreslit pouze natoceny obdelnik. Tak bych to udal stejne, akorat budu kreslit konstantni barvou. Pritom tam budu mit "dirky" ale taky.

Napred sem myslel, ze ty svine vznikaj pri zaokrouhlovani float->int
http://www.volny.cz/xfer/4all/zaokr.jpg
, ze se to tam vlivem naky chyby jako zateteli a padne spatna hodnota. Jak sem ale zistil, tak naky pixely se zas prekryvaji. Ty muzu aspon detekovat (podle toho, ze pred zapisem zkontroluju framebuffer jesi uz tam neni neco zapsano) a tak sem si vypsal jejich souradnice a zistil, ze se zdaleka ne vzdy jedna o cisla s desetinou casti kolem rozhodovaci urovne. Spis me napada, jesi to neni naka nepresnot ty samotny funkce sin a cos.
Kontorloval sem taky jesi mi da x^2+y^2=i^2 to je celkem OK, semtam odchylka asi na 5 des. miste.

Citace:

Původně odeslal Glottis

kdyby jsi necekal na retrace jak by se to tocilo rychle? 1° je asi 0,017 radianu coz sem tam mel krok take (priblizne, mel sme tam 0,01). tak jestli to je rychlejsi nebo ne.

Bez vsync asi 2x rychlejs, zatim tu rychlost moc neresim, neni to vubec optimalizovany. Do toho se pustim az to bude kreslit korektne.

Jinak tady je este druhej programek, kde to neni nijak vosetreny ty "dirky" http://www.volny.cz/xfer/4all/rotate1.exe

Co je taky zajimavy, ze se to nemeni at pouzivam float nebo long double.

Zobrazit 100 příspěvků z tohoto threadu na stránku