Mail Archives: djgpp/1998/01/08/19:01:08
From: | Larry Swanson <laswanson AT mwci DOT net>
|
Newsgroups: | comp.os.msdos.djgpp,comp.graphics.algorithms
|
Subject: | Why are screen pixels faster than double buffer?
|
Date: | Thu, 08 Jan 1998 16:51:43 -0600
|
Organization: | MidWest Communications, Inc.
|
Lines: | 45
|
Message-ID: | <34B5587E.C14B18B8@mwci.net>
|
NNTP-Posting-Host: | dial-71.man.mwci.net
|
Mime-Version: | 1.0
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
I recnetly started profiling my code using the rdtsc command in a NASM
procedure. I was suprised to see exactly how many cycles things took to
happen. For example:
-----Procedure--------------------------How many
Cycles---------------------
Pixel to screen: 250 cycles
Pixel to double buffer in ram 1500 cycles
Fill screen 16bit 290000 cycles
Fill RAM double buffer 330000 cycles
As you can see, it takes 8 times as long to plot to memory. I'm just
curious as to why, because I've always read that VRAM is slower than
RAM. Also, doesn't 250 cycles seem like a long time for a pixel plot
any way? I always thought it would be at least less than 75.
I'm using far pointers so the code is the same for each procedure.
Here's how I profile kjust in case i'm doing it all wrong...
----profile.asm---
section .text
global _Cycle_Fv
_Cycle_Fv:
rdtsc;
ret
------my c++ file (relevant porion at least)----
extern unsigned volatile long long Cycle();
DISABLE();//so interrupts don't slow us down
unsigned long long before = Cycle();
Test .Pixel(0);// or the_screen.Pixel();
unsigned long long after =Cycle();
ENABLE();//turn on interrupts
cout<< after-before<<endl;
If anyone could tell me why video memory is so fast compared to ram, or
point out a better way to profile this, I would be very thankful.
Thanks for reading this far,
Jordan Swanson
- Raw text -