www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1993/08/19/11:28:12

Date: Thu, 19 Aug 93 10:38:14 -0400
From: DJ Delorie <dj AT ctron DOT com>
To: Peter DOT Rojsel AT maxlab DOT lu DOT se
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: More video benchmarks

> I think that selling a VLB for a graphics accelerator card is like 
> selling orange coloured golfballs for playing in the snow. 
> VLB may be useful for a non accelerator card and for disc controllers, 
> but not for graphics accelerators. The small traffic on the bus to the 
> card just does not justify it.

> I also wonder (forgive my ignorance but) how do I interpret the figures 
> your benchmark produces? what is 'waits' ? Waitstates??? What is the 
> source when the header says ->s or ->v and the target when it says s-> 
> and v-> ?

The above benchmark determines how fast it can cram raw data onto the
video screen in 320x200x256 mode, which is the most common mode for
video games.  It also indirectly measures "Video for Windows"
performance, and other types of blit operations.  It specifically does
NOT measure text or accelerator performance.  For accelerator
performance, use WinMarks.

The raw numbers are Kilobytes per second.  Given the CPU type and
speed (that's why I asked), the program can determine the theoretical
maximum transfer rate, and from that determine the number of
additional clock cycles per byte transferred.  These additional cycles
are called "wait states" because that's when the CPU waits for the
information to be ready.

The columns are transfer types:

	s->s	system RAM -> system RAM (movs opcode)
	s->v	system RAM -> video RAM
	(etc)
	s->	reading system RAM (lods opcode)
	->s	filling system RAM (stos opcode)
	(etc)


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019