139 lines
8.9 KiB
HTML
139 lines
8.9 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
|
|
<META NAME="GENERATOR" CONTENT="Mozilla/4.5b2 [en] (X11; I; Linux 2.0.30 i486) [Netscape]">
|
|
<TITLE>Graphics Muse
|
|
</TITLE>
|
|
</HEAD>
|
|
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#660000" VLINK="#666666" ALINK="#FF6600">
|
|
<!-- =============================================================
|
|
These pages are designed by Michael J. Hammel. Permission to
|
|
use all graphics and other content is granted provided you give
|
|
me (or the original authors/artists) credit for the work and this
|
|
copyright notice is not removed.
|
|
|
|
(c)1997, 1998 Michael J. Hammel (mjhammel@graphics-muse.org)
|
|
============================================================= !-->
|
|
|
|
<BR><IMG SRC="../gx/hammel/musings.jpg" HEIGHT=50 WIDTH=245>
|
|
<TABLE WIDTH="100%" >
|
|
<TR>
|
|
<TD ALIGN=RIGHT WIDTH="100%"><FONT SIZE=-2>© 1998 <A HREF="mailto:mjhammel@graphics-muse.org">Michael
|
|
J. Hammel</A></FONT></TD>
|
|
</TR>
|
|
|
|
<TR>
|
|
<TD VALIGN=TOP BGCOLOR="#000000" cellpadding="0" cellspacing="0"><IMG SRC="images/cleardot.gif" ALT="indent" ALIGN=LEFT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
<I><FONT FACE="Arial,Helvetica"><FONT SIZE=-1><B><FONT COLOR="#993300">'Muse</FONT></B>:
|
|
Paul Sargent over at 3Dlabs was quite helpful in the writing of this article.
|
|
When I started researching video cards I found I'd fallen way behind on
|
|
hardware memory types. I asked him for short descriptions or
|
|
definitiions and he came through with a terrific response. I've included
|
|
it here. Its a little more technical than the rest of the article,
|
|
but will definitely be of interest if you have a need to understand the
|
|
hardware a little better.</FONT></FONT></I><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><B><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>EDO RAM</FONT></FONT></B><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>This is the stuff that was
|
|
found in PC's about two years ago. Basically it's normal DRAM with
|
|
_E_nhanced _D_ata _O_ut functionality. This means that the graphics
|
|
controller can perform burst reads on the memory, hence increasing the
|
|
amount of read bandwidth from the memory. For example this would
|
|
make the read half of a BLIT that much quicker. It's a single ported
|
|
memory (see below).</FONT></FONT><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><B><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>VRAM</FONT></FONT></B><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>This is normal DRAM (sometimes
|
|
with EDO functionality). It's big thing is that it's dual ported. I'll
|
|
deal with Dual Vs Single ports a bit later. It also has some special features
|
|
like block writes (see SGRAM)</FONT></FONT><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><B><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>SDRAM</FONT></FONT></B><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>Synchronous DRAM is the stuff
|
|
you find in your new PC's (Pentium II's and such like). This type of memory
|
|
tends to run about 3-4 times as fast as EDO DRAM. It supports functions
|
|
such as burst writes and burst reads. All Synchronous Memory I've
|
|
ever heard of is Single Ported.</FONT></FONT><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><B><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>SGRAM</FONT></FONT></B><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>Synchronous Graphics RAM
|
|
is the same stuff as SDRAM, but it contains various features that are graphics
|
|
specific. For example, Block Writes allow an area of memory to be filled
|
|
with a single colour by issuing only one write. Combine that with Masked
|
|
writes (another SGRAM feature) where you can load a bit mask to say which
|
|
pixels are written to and you have a very powerful mechanism for drawing
|
|
things like single colour text.</FONT></FONT><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><B><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>WRAM: Windows RAM</FONT></FONT></B><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>WRAM was developed by Mitsubishi
|
|
for E&S (I believe) and is a variant on VRAM. They included some more
|
|
special feature that are graphics related, but it's based on old technology.
|
|
It's dual ported like VRAM.</FONT></FONT><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><B><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>Single Vs Dual Ports:</FONT></FONT></B><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>Imagine a RAMDAC. It needs
|
|
to send signals to the monitor each 75th of a second to refresh the display,
|
|
therefore it needs to know what colour all the pixels should be. Therefore
|
|
one way or another the graphics controller must supply the RAMDAC with
|
|
the full contents of the framebuffer each frame. There are two ways it
|
|
can do this.</FONT></FONT><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>1) It can periodically read
|
|
a batch of pixels from the Frambuffer and squirt these down a dedicated
|
|
pixel bus that lies between the Graphics controller and the RAMDAC. The
|
|
trouble is, while it's doing this the graphics controller can't do any
|
|
reads or writes to the framebuffer for normal jobs. This becomes more of
|
|
a problem as the screen resolution goes up. More reads have to be
|
|
performed to keep the RAMDAC fed. If this doesn't occur the display would
|
|
have artefacts, so these reads takes priority over everything else. The
|
|
net result is as the display resolution goes up, the performance of the
|
|
graphics card goes down.</FONT></FONT><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>2) The RAMDAC can have it's
|
|
own connection to the graphics memory. By doing this the data stream required
|
|
to refresh the display doesn't get in the way of the graphics controller.
|
|
Therefore screen resolution tends not to impact performance (i.e. a 100x100
|
|
pixel BLIT will take the same amount of time, but remember that you now
|
|
have a larger screen to fill. The graphics controller tends to do more
|
|
work at higher res's anyway)</FONT></FONT><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>Method 1 is the only option
|
|
with single ported RAM (EDO, SDRAM, SGRAM) and Method 2 is a better if
|
|
your using Dual ported RAM (VRAM, WRAM)</FONT></FONT><FONT FACE="Arial,Helvetica"><FONT SIZE=-1></FONT></FONT>
|
|
<P><FONT FACE="Arial,Helvetica"><FONT SIZE=-1>The thing is that these days
|
|
the memory bandwidth has got large enough that the bandwidth needed to
|
|
refresh the screen is becoming less of a problem, and there are no fast
|
|
Dual ported memories any more.</FONT></FONT>
|
|
<BLOCKQUOTE><I><FONT FACE="Arial,Helvetica"><FONT SIZE=-1><B><FONT COLOR="#993300">'Muse:</FONT></B>
|
|
What are the differences between these? My understanding is that
|
|
VRAM and EDO RAM are primarily used on older cards (>2 years old) and SGRAM
|
|
is the latest thing, fastest because of how its integrated with the video
|
|
processor. Am I close?</FONT></FONT></I></BLOCKQUOTE>
|
|
<FONT FACE="Arial,Helvetica"><FONT SIZE=-1>You're time scales are about
|
|
right, for reason of speed see above.</FONT></FONT>
|
|
<BLOCKQUOTE><I><FONT FACE="Arial,Helvetica"><FONT SIZE=-1><B><FONT COLOR="#993300">'Muse:</FONT></B>
|
|
An old article from ComputerShopper.com says that 3D cards (from early
|
|
1997) used VRAM for displaying video and DRAM for offscreen display and
|
|
textures. How does DRAM fit into the current picture then?</FONT></FONT></I></BLOCKQUOTE>
|
|
<FONT FACE="Arial,Helvetica"><FONT SIZE=-1>Cards tend to only have one
|
|
type of memory on them these days, and the Graphics controller stores everything
|
|
in it. That said, if we were to make a card with a memory arrangement like
|
|
that on it, we would replace the VRAM with SGRAM and the DRAM with SDRAM.</FONT></FONT>
|
|
<BLOCKQUOTE><I><FONT FACE="Arial,Helvetica"><FONT SIZE=-1><B><FONT COLOR="#993300">'Muse: </FONT></B>
|
|
Boy, no wonder the average person gets lost trying to set up X on Linux.</FONT></FONT></I></BLOCKQUOTE>
|
|
<FONT FACE="Arial,Helvetica"><FONT SIZE=-1>This sort of stuff doesn't need
|
|
to be visible to the end user, and hopefully more recent cards are getting
|
|
better at hiding it.</FONT></FONT>
|
|
<BLOCKQUOTE><I><FONT FACE="Arial,Helvetica"><FONT SIZE=-1><B><FONT COLOR="#993300">'Muse:</FONT></B>
|
|
Thanks Paul!</FONT></FONT></I></BLOCKQUOTE>
|
|
|
|
<TABLE WIDTH="100%" >
|
|
<TR>
|
|
<TD VALIGN=TOP COLSPAN="4" BGCOLOR="#000000" cellpadding="0" cellspacing="0"><IMG SRC="images/cleardot.gif" ALT="indent" ALIGN=LEFT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
<TABLE WIDTH="100%" >
|
|
<TR>
|
|
<TD ALIGN=RIGHT><FONT SIZE=-2>© 1998 by <A HREF="mailto:mjhammel@graphics-muse.org">Michael
|
|
J. Hammel</A></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
</BODY>
|
|
</HTML>
|