which way is faster?
in [ASM]
|
Prev: A little ASM 6809 program
Next: what is rsrc.rc?
From: Wolfgang Kern on 16 Jan 2008 22:09 Wannabee skrev: [...still about timing] >> What are you searching for? the code is still in this post. > whats is in this post is all but the code thats needs to be verfied. > (nothing novel about this code, has been cut and paste avail > from internet since 20 years) So what else do you mean is involved in a linear frame screen write ? the read of the VESA BIOS ahead of it ? Dirk posted it already. (Find all needed info for it at vesa.org) or how to switch to and from RM<>PM ? (AOD is full of variants) >> [SMC] > Does not explain VESA or 32 bit flat setup. > I would have clipped the code and pasted it directly into the post. And > explained every part in > detail. The full code for 32 bit mode setup, from dos, with detailed > explanation. Then the VESA setup, and the code for generating the bitmap > and bascially all the needed code (should not need to be that much). Oh I see, you wanted me to type an ASM-source with comments. > Then i would comment it heavy, like you did well with the Bitmap code. > Then it would be useful. The code posted is nice but not useful in order > to verify the numbers. > (not in any sense of the meaning, at all) My timing figures come from the debugger, please don't expect that I will convert 32 KB machine code into ASM-source and explain in detail how it works. This alone could fill a book. In short: I open the debugger, fill in all register values incl cs:eip and hit run, it reads TSC at start and reports the difference at the end. > Then i would add a link to the binary. you mean I should publish KESYS-internals ? > But I guess words are easier.... .... >>> 1000 copies a second is 256*256 dots /s = (65536 dots) * 1000 per sec. >>> that is 65_536_000 dots / sec. or 65 mega pixels. >>> For 32 cycles per pixel this gives a total of 2_097_152_000 or two Giga >>> cycles Which is impossible on a machine like that. >> Something in your calculator seem to be stuck ...? :) > You said to me that the app I posted a link to, printed 970 on the screen > when ran in 1024*768*32 ? > so the calculation is correct for that case. This 32 cycles per dot are the timing of my code. ~4mS = 250 fps But your code show 970 frames, which is almost four times faster, so I assume that 'some' hardware accelleration is active here. And I cannot disable the driver because windoze wont do it without. > 970 _copies_ of a bitmap that is 256*256 pixels ~ roughly 1000 * (65536) > (dots = pixels). If each pixel in your own code takes 33 cycles, then for > my code to be slower, it will have to use at least 33 cycles per dot. So > when multiplied out, 1000*65536*33 = 2_162_688_000 cycles _per second_ > > = you machine must be able to process 2 giga cycles per second. or 2Ghz. Wrong assumtion, windoze seem to need just ~9 cycles per dot with my graphic card, while my code needs ~32. btw: meanwhile I checked if MOVQ/MOVNTQ is any faster than REP MOVSD, it turned out to be quite slower (20%) on this machine. Ok, the new era begun already, so I'll check on 64' if MOVDQ/MOVNTDQ is faster in legacy 32-bit mode after I completed the toolbox for it. > My own K7 gives only around 460 copies a second, and runs on 1543 megaherz > currently. The machine you ran my code on is processing the pixels at > twice the effiency for memory, gc, and CPU, while you claim it is an > antiquated piece of garbage from about the stoneage. Yes, but I didn't invent this 970, perhaps your unicoloured picture helps windoze to tell the GPU just the x-y-size and let it just fill. > (btw, the 1/4 dot was a joke - bitblt process the entire bitmap per call, > 65536 pixels) That's what I thought, and it could also check for repeated patterns to speed the story up by using the GPU's bitblt features. Otherwise I cannot explain why it is faster than my code. >> I never said it was counted over 1000 copies. I reported ~2e6 cycles >> which turns out to be 3..4 times slower than your 'supported' variant. > Yes. But my code did 970 copies a second. On the same machine. (You said) Yes, and if my calculator still works then my code did just 250. It may be the driver software togheter with the graphic card which produces this 460/970 difference. >> I makes me sick to see it, but I cannot write my own hw-support >> for every new graphic card (like I had in the past for a few cards, >> which turned out to be three times faster than DirectX), perhaps >> you totally misunderstood and that's why insinst for more code ? > I misunderstand a lot of things. But I do know that in order to verify a > claim as for speed of some code, we need to see the two codes running, on > the same machine, and have the code so we can verify what it does. I could run both on one machine, even it needs a reboot to swap OS. Why can't you believe that windoze is faster than KESYS on this one ? >> OK, let's follow another absolute rule right now: >> * give windoze the same vendor support as I've got ['goanix','nada'] >> (I have only the information found in the VBIOS aka VESA) >> and the let's compare again: >> * set screen mode to 1024*768,32bit-colour >> * draw any picture or pattern (not just equal dots) >> * draw it to an unalinged position ie: x=15 y=13 > I have the deepest sympathy for that, and I think it is a crime. > But is not related to the VESA claim. > GDI doesnt use hardware acceleration. I'm not sure about this, it would need to analyse the drivers, which I promised to never do again, because my lifetime is limited. >> Oh, I see, the three latter above wont work, because windoze defaults >> to the old VGA-mode: 1024*768,4bit-colour and cannot set any other >> mode beside VGA 03 (blue screen of death) without a vendors driver >> or any other third party support. >>>>> You could even do it in windows. >>>> Sure, if you can tell me how to get direct access to the VRAM. >>> Write a driver, get ring 0 access, and take over the OS. >> If this would be that easy or possible, we would have heard already. > At least explain why its not possible. AFAIK all kernel mode drivers (XP) need an M$-verified key, and XP is kinda protected against 'nested' driver software that it sometimes rejects even M$-produced stuff. But you should ask this question in the re-engineering camp, I'm for sure not an expert on windoze internals. __ wolfgang
From: //o//annabee on 17 Jan 2008 13:43 P� Thu, 17 Jan 2008 04:09:45 +0100, skrev Wolfgang Kern <nowhere(a)never.at>: > I'm not sure about this, it would need to analyse the drivers, > which I promised to never do again, because my lifetime is limited. Hi wolfgang. Try to turn off hardware acceleration in the Display properties. Run the app again. What do you see then? > __ > wolfgang > > >
From: Dirk Wolfgang Glomp on 17 Jan 2008 14:01 Am Thu, 17 Jan 2008 04:09:45 +0100 schrieb Wolfgang Kern: > So what else do you mean is involved in a linear frame screen write ? > the read of the VESA BIOS ahead of it ? Dirk posted it already. > (Find all needed info for it at vesa.org) http://www.vesa.org/public/VBE/vbe3.pdf Dirk
From: //o//annabee on 17 Jan 2008 15:51 P� Thu, 17 Jan 2008 20:01:53 +0100, skrev Dirk Wolfgang Glomp <dirk(a)freecrac.dyndns.org>: > Am Thu, 17 Jan 2008 04:09:45 +0100 schrieb Wolfgang Kern: >> So what else do you mean is involved in a linear frame screen write ? >> the read of the VESA BIOS ahead of it ? Dirk posted it already. >> (Find all needed info for it at vesa.org) > > http://www.vesa.org/public/VBE/vbe3.pdf > > Dirk Do you have any links to the internet? I want todo 32 bit flat enduser coding. http://Internet.com/NewInventions/Flat/Fast/NoDos/VespaOrg/OnaSalVesa.pdf :))
From: Dirk Wolfgang Glomp on 18 Jan 2008 04:47
Am Thu, 17 Jan 2008 21:51:02 +0100 schrieb //\\\\o//\\\\annabee: > P� Thu, 17 Jan 2008 20:01:53 +0100, skrev Dirk Wolfgang Glomp > <dirk(a)freecrac.dyndns.org>: > >> Am Thu, 17 Jan 2008 04:09:45 +0100 schrieb Wolfgang Kern: >>> So what else do you mean is involved in a linear frame screen write ? >>> the read of the VESA BIOS ahead of it ? Dirk posted it already. >>> (Find all needed info for it at vesa.org) >> >> http://www.vesa.org/public/VBE/vbe3.pdf >> >> Dirk > > Do you have any links to the internet? Vesa in Ralf Browns Interrupt List: RBIL->inter61a.zip->Interrup.a --------V-104F00----------------------------- INT 10 - VESA SuperVGA BIOS (VBE) http://www.pobox.com/~ralf http://www.pobox.com/~ralf/files.html ftp://ftp.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/ > I want todo 32 bit flat enduser coding. PM with the 32 bit adressmode(using DOS/Windows/Linux/without any OS)? > http://Internet.com/NewInventions/Flat/Fast/NoDos/VespaOrg/OnaSalVesa.pdf The page with "Jupitermedia" shows: 404 - File not found Sorry, the file you have requested cannot be found on any of our servers. Please check the file name and try again, or try a search on search.internet.com. For your convenience, we have listed below an extended menu of Jupitermedia's sites. Dirk |