What is the difference between AGP video card and regular video card?

What is the basic difference between AGP video card and regular video
card? I saw some AGP cards with notations of 4X, 6X, etc. What is
that? Are there some requirements/sychronizations between AGP video
cards and monitors? [e.g. for CRTs, the practical vertical frequency
is the lower common denominator between the video card and monitor.
i.e. if you have a monitor capable of 100Hz at 1024 x 780 resolution,
you need a video card with that capability; otheewise it will run at
the lower frequency of the video card; and vice versa.)

Can I use a AGP video card (nVidia Vanta16 RivaTNT2 16MB AGP Video
Card) with an old Sony monitor (Trinitron multiscan 200ES)?

TIA

The term AGP refers to the socket and chipset on the motherboard that the
video card plugs into. You have to match the AGP speed, and hence voltage,
of the model of video card and the model of motherboard you are intending to
use.

--
DaveW



<0b3hks001@sneakemail.com> wrote in message
news:64e817b9.0410081500.1aba098a@posting.google.com...
> What is the basic difference between AGP video card and regular video
> card? I saw some AGP cards with notations of 4X, 6X, etc. What is
> that? Are there some requirements/sychronizations between AGP video
> cards and monitors? [e.g. for CRTs, the practical vertical frequency
> is the lower common denominator between the video card and monitor.
> i.e. if you have a monitor capable of 100Hz at 1024 x 780 resolution,
> you need a video card with that capability; otheewise it will run at
> the lower frequency of the video card; and vice versa.)
>
> Can I use a AGP video card (nVidia Vanta16 RivaTNT2 16MB AGP Video
> Card) with an old Sony monitor (Trinitron multiscan 200ES)?
>
> TIA

> What is the basic difference between AGP video card and regular video
> card? I saw some AGP cards with notations of 4X, 6X, etc. What is

AGP is just way to connect the graphics card to your motherboard. The 2X,
4X, 8X are connection speed, 4X is twice the speed of 2X, 8X is twice the
speed of 4X and so on. You can for example put AGP 8X card into AGP 4X
motherboard but the speed will only be 4X.

> that? Are there some requirements/sychronizations between AGP video
> cards and monitors? [e.g. for CRTs, the practical vertical frequency

None, AGP is a bus which connects the graphics card into the motherboard of
your computer. The graphics card is connected to the display device using
different kinds of connectors like DB15, BNC, DVI and others. Usually
graphics cards (for PC) have either DB15 or DVI output connector(s) and DVI
can be usually converted to DB15 because DVI-I connectors should have DVI-A
(A= Analogic) pins connected and used. There are different kinds of
connectors at both ends: graphics card and monitor and you can try to
determine what you got and maybe ask here what recommendations you are
given. For example if you have DVI on both monitor and graphics card it
should be the best choise.

> Can I use a AGP video card (nVidia Vanta16 RivaTNT2 16MB AGP Video
> Card) with an old Sony monitor (Trinitron multiscan 200ES)?

I am not going to check from the web what the specs of 200ES are but it very
likely has DB15 and/or BNC input. As long as you have the right cable you
can hook it up to the TNT2 and it should work (I cannot guarantee that the
card or monitor are not broken). <- Sick world that have to put that kind of
disclaimers, but the world changes.. if I don't it is a bomb-sure invitation
for someone to find 'error' and bash for it. *sigh*

Have fun!

"assaarpa" <redterminator@fap.net> wrote in message
news:ck77ja$hkp$1@phys-news1.kolumbus.fi...
>> What is the basic difference between AGP video card and regular video
>> card? I saw some AGP cards with notations of 4X, 6X, etc. What is
>
> AGP is just way to connect the graphics card to your motherboard. The 2X,
> 4X, 8X are connection speed, 4X is twice the speed of 2X, 8X is twice the
> speed of 4X and so on. You can for example put AGP 8X card into AGP 4X
> motherboard but the speed will only be 4X.
>

Small correction: The AGP 'speed' does not make any significant difference
performance-wise. Advanced Graphics Port is just a different (newer) standard to
Peripheral Component Interconnect. By definition all AGP cards should be faster than PCI
cards. Newer cards (mostly with 8X emblazoned on them) may not work in older computers due
to them using a different voltage.

-
Ad

> Small correction: The AGP 'speed' does not make any significant difference
> performance-wise. Advanced Graphics Port is just a different (newer)
standard to

Same way as having car with top speed of 300 kph and 150 kph, if you don't
drive faster than 150 kph, indeed there is no difference. AGP 8x _does_ have
twice the _bandwidth_ over AGP 4x, it is a different matter if this is used
by applications. But that is nitpicking so chill out ffs, always, always
have to mention every minute little tiny dickwick detail otherwise someone
corrects you.

Alright. Background information: I work for a 3D graphics hardware vendor
and I have been programming for 15+ years and have a fairly good idea what
AGP 8x can and cannot do. Thank you. <- Does that make any difference to
anything? No. Why then it is important to mention? I don't know, you tell
me.

"assaarpa" <redterminator@fap.net> wrote in message
news:ck96es$t3b$1@phys-news1.kolumbus.fi...
>> Small correction: The AGP 'speed' does not make any significant difference
>> performance-wise. Advanced Graphics Port is just a different (newer)
> standard to
>
> Same way as having car with top speed of 300 kph and 150 kph, if you don't
> drive faster than 150 kph, indeed there is no difference. AGP 8x _does_ have
> twice the _bandwidth_ over AGP 4x, it is a different matter if this is used
> by applications. But that is nitpicking so chill out ffs, always, always
> have to mention every minute little tiny dickwick detail otherwise someone
> corrects you.
>
> Alright. Background information: I work for a 3D graphics hardware vendor
> and I have been programming for 15+ years and have a fairly good idea what
> AGP 8x can and cannot do. Thank you. <- Does that make any difference to
> anything? No. Why then it is important to mention? I don't know, you tell
> me.
>
Okay. I'll go into detail. AGP 'speed' only means anything when transferring textures from
main memory. Most cards have enough memory on board for that not to be an issue. AGPX8 is
slow. AGPX4 is slower etc.... You wouldn't want to use this feature of AGP which was only
included to sell video cards to the uninformed.

-
Ad

> Okay. I'll go into detail. AGP 'speed' only means anything when
transferring textures from
> main memory.

Before we waste any time, you are a programmer, or end user?

> Most cards have enough memory on board for that not to be an issue.

I am curious, how does that change the fact that AGP 8x has twice the
bandwidth over the AGP 4x? That is completely separate issue from the
question if the bandwidth is needed or not.

When GAME application is written, it must work on as wide range of hardware
as possible. This means the application is specificly engineered to work
from lower end to the higher end of the hardware spectrum, this fact must
have given you the impression that higher bandwidth is NEVER advantageous or
even usefull. You are plain wrong with this conclusion.

> AGPX8 is slow. AGPX4 is slower etc.... You wouldn't want to use this
feature of AGP which was only
> included to sell video cards to the uninformed.

What feature are you referring to, the higher bandwidth, or DIME? I am
curious again, what practical experience you have on the topic? It would be
interesting to know if I am merely wasting my time or having a good
discussion.

>> Okay. I'll go into detail. AGP 'speed' only means anything when
> transferring textures from
>> main memory.
>
> Before we waste any time, you are a programmer, or end user?
>

I am an end user with a little programming experience.

>> Most cards have enough memory on board for that not to be an issue.
>
> I am curious, how does that change the fact that AGP 8x has twice the
> bandwidth over the AGP 4x? That is completely separate issue from the
> question if the bandwidth is needed or not.
>
> When GAME application is written, it must work on as wide range of hardware
> as possible. This means the application is specificly engineered to work
> from lower end to the higher end of the hardware spectrum, this fact must
> have given you the impression that higher bandwidth is NEVER advantageous or
> even usefull. You are plain wrong with this conclusion.
>
>> AGPX8 is slow. AGPX4 is slower etc.... You wouldn't want to use this
> feature of AGP which was only
>> included to sell video cards to the uninformed.
>
> What feature are you referring to, the higher bandwidth, or DIME? I am
> curious again, what practical experience you have on the topic? It would be
> interesting to know if I am merely wasting my time or having a good
> discussion.
>

I would like to have a good discussion about this because end users seem to be hung up on
the AGP 'speed' when this generally has very little bearing on the performance of their
graphics card. DIME is hardly ever used by games programmers otherwise cards wouldn't have
so much memory on them. AGPX8 bandwidth is only about 2GB/s whereas the latest cards have
about 30GB/s. Sure, high AGP bandwidth is 'good' but not if graphics card bandwidth is
increasing as well. I really don't understand the point of AGP DMA or DIME unless its to
keep costs down.
And texture loading bandwidth doesn't really matter because most games load up the
graphics card memory with textures before the game or 'level' starts.

-
Ad

> I would like to have a good discussion about this because end users seem
to be hung up on
> the AGP 'speed' when this generally has very little bearing on the
performance of their
> graphics card. DIME is hardly ever used by games programmers otherwise
cards wouldn't have

Sir, you misunderstand me completely! I am not advocating DIME, on the
contrary for the reasons you outline below I came to the same conclusion --
in 1998! (could have been 1999, cannot recall, I could check.. whenever the
Matrox G200 came out, I was the son of bitch who wrote the graphics engine
used in the technology demo that shipped with the card! I believe it was one
of the first applications ever to see the light of day in consumer hands to
use DIME.. and probably the last one, too, where it was used seriously! ;-)
The framerate was fraction of one when using local memory, I cannot quite
precise figures but something like 1/3 or similiar sounds correct enough).

Since then the situation has just grown 'worse', if that expression can be
used. 3DLabs uses similiar technique in their line of graphics products few
years back at driver-level (as far as application developer was concerned,
naturally this also required hardware on-chip support but I don't believe
it was a big success outside the community that needed 'MASSIVE' amounts of
texture memory, could be wrong on that one but generally speaking I think
that is close enough to the truth.

But that is not what am 'defending', I said that the AGP 8x has twice the
bandwidth than the AGP 4x and still believe that is pretty close to being
correct statement.

> so much memory on them. AGPX8 bandwidth is only about 2GB/s whereas the
latest cards have
> about 30GB/s. Sure, high AGP bandwidth is 'good' but not if graphics card
bandwidth is
> increasing as well. I really don't understand the point of AGP DMA or DIME
unless its to
> keep costs down.

You're preaching to the choir and secondly you have grossly misunderstood my
position on this issue. I was curious what specific AGP 'feature' you had in
mind, I suggested DIME since you seemed to be stuck on textures and
bandwidth requirements and texture fetching usage pattern. I could tell a
thing or two how even the bandwidth inside the GPU is not enough for the
sample starved shading units. To overcome these limitations a few steps are
taken to keep things up to speed.

First, the memory/caching system for texture sampling is designed based on
assumption that the texel:fragment ratio is close to 1.0, which means that
storing rectangular area of texels is advantageous to be a, in optimum case,
a single read through the bus from slower, say, DDR2 memory installed on the
card. Compressed textures using scheme like S3TC or DXTn is ideal for this
kind of reading pattern, let's say we have a 4 by 4 block of texels which
takes 64 bits of storage (16 bits for basecolor0 and 16 bits for basecolor1,
and 16 2-bit samples taking 32 bits, total: 64 bits

When we need a sample from a 4x4 area of texture, we can look into texture
cache, which is on-chip very fast storage area. If this block is
decompressed in the cache, we can very quickly retrieve a value. If not,
read request goes into the memory controller and when the read comes through
it goes through decompression circuitry and the value is available. Ofcourse
this would introduce horrible latency, this is why the read requests are
done ahead of the time the results are needed, this is a solved problem so I
won't comment on that in greater detail.

Now when we do, say, bilinear sampling from a texture, the 2x2 region fits
_4_ times in a row into same "cache page" (4x4 region), so only every one
out of four samples miss the cache in the WORST case. Pretty neat, 75% of
the read requests hit the cache pretty much automatically. Then we have a
little bit larger cache and there we go, the memory system doesn't need to
be Ultra Fast. What we want is that the system is low-latency, so that we
don't have to look up the values TOO MUCH ahead.. since if we want to do
that efficiently we need either of these two things:

1. longer pipeline so that the overhead/latency is amortized
2. large buffer so that we can keep a queue of read requests in..

Both of these choises suck in their own ways, so best is if the latency can
be kept lower.. this is where the AGP burns our fingers really badly, since
it is HIGH-LATENCY.. it is much bigger problem than the bandwidth, but
indeed the bandwidth is a problem too.. but much, much later than the
latency one! Since that is not fixed there is no point arguing if the
bandwidth is adequate or whatnot, it's a MOOT POINT! Now you see why I don't
consider it a very interesting issue?

There are applications where AGP bus cannot be avoided, think of softbody
skinning for example. There just aren't enough constants in vertex shaders
to keep enough matrices at hand! A common workaround is to do the skinning
with the CPU, filling a VertexBuffer and tween in vertex shader between two
existing buffers so that, say, every 4 frame only is a real computed
"tweening keyframe" and the three between the keyframes are just linearly
interpolated. This is a design choise to balance the CPU workload, bandwidth
usage and GPU utilization into somekind of solutioin that doesn't stall too
much. Unreal Engine for instance atlesat in it's older incarnations for
instance do software skinning, don't know if they skin every frame or tween
the gaps but that is just a minor detail.

Ofcourse the skinning can be done completely within the GPU, but this
assumes that the model is broken into lots of batches so that the constants
can be updated between the batches. This is actually less efficient than
just going out and skinning with the CPU! Sick but true. VS3 model allows to
do the skinning on the GPU so that the bones are stored in textures, but the
problem with this is that with current hardware that can do this (GeForce
6800 series) the vertex sampler latency is horrible, strange that they can
do this so slow in vertex shader when the operation of sampling from texture
is ultra-optimized on pixel shaders. I guess this is because this is, once
again, first-generation implementation of something "new".. remember
GeForce3? Too slow to use the pixelshaders a lot of the time.. gamers did
cry how it sucks, developers thought: "great, finally have hardware to work
with even if slow!" Same thing is happening now, except, well, to be honest
the speed problem is not as obvious as it was few years back!

The point is, that a lot of data has to be synthesized on the CPU side,
still! The problem isn't bandwidth, but latency.. but when the bandwidth is
twice as fast, the latency is halved-- this is assuming we transfer
*batches*, so, we don't need to take the roundtrip from driver to hardware
to wherever into consideration, only the fact that "how long" does it take
for some data to get to the GPU local memory so that it can be efficiently
used. Twice the bandwidth DOES cut this time into half!

This has _nothing_ to do with textures, ummm, or gamers playing happily
their games that are designed to work "great" even on GeForce256 and heck,
even older graphics processors! If there is not enough texture memory, what
you think the developers do: endure the swapping!? Or cut the resolution,
dropping from 512x512 to 256x256 cuts memory requirement into 1/4 .. if you
ever developed application that runs out of texture memory, you know how
****ing slowly it'll run, you won't be laughing that AGP 8x is "useless"--
but-- it's better to make the game worse looking than unplayable!

> And texture loading bandwidth doesn't really matter because most games
load up the
> graphics card memory with textures before the game or 'level' starts.

The problem with your opinion you stated three times now is that:

- I agree with the statement that texture loading bandwidth doesn't matter:
it's too slow anyway..
- .. but that was irrelevant for what I was saying!

The problem most gamers have with "just to sell more graphics cards" is that
they do believe a lot of trash they read and after a while they think it is
true. This is caused by the fact that the progress is done in minute, very
small increments. If no progress was being made, we would still use 16-bit
ISA bus and be happy with it. Some of us would not be happy with it, and
seek ways for faster ways to do things. Then VESA local bus would be
introduced, then PCI bus.. then 64-bit PCI-X, 66, 100 Mhz PCI buses and AGP
.... then AGP 2x, AGP 4x.. AGP 8x.. when you look and compare AGP 4x to 8x,
the difference isn't mind-boggling, but when you look back to 1x, oops.. I
wouldn't want one of those!

With motherboard side, I don't think it is "cashing" or "milking the cow"
since I never seen ANYONE to upgrade their motherboard just to get a little
bit faster AGP bus! I guess some are stupid enough to do that, but we can
ignore that category let's talk about NORMAL people.. some people said, back
whenever, when I got my P4 1.7 Ghz, that it idiotic thing to do as "Athlon
is much faster", well, I didn't really care what they said since I was a
programmer and wanted to program SSE2 and Athlon did barely have SSE in
AthlonXP models!) .. a year or maybe year and a half goes by.. these Athlon
Boys were running, guess what? Pentium4 Northwoods! Now I was idiot for
having old Willamette core, since the "motherboard isn't upgradeable"! Yeah,
what a maroon, I missed 2.0 Ghz P4 "only" had a 1.7Ghz P4... what a massive
loss! I never upgraded the CPU. Heck, only CPU upgrade I ever done to a MOBO
is 486DX33 -> DX4-100 upgrade.

The Pentium4 1.7Ghz, which was "stupid purchase" is running SuSE Linux 9.1
happily as I type this, what, 3-4 years after purchasing it and still
working great and very fast for the job it is doing (fileserver for my home
LAN!, sheesh...)

That was a story of a zealot, very arrogantly told and so on.. and
pointless? No, there is a point in all this.. buy smart and don't have to
upgrade every 6 months, buy what you need and ignore assholes telling you
what to buy. In short, the " feature of AGP which was only included to sell
video cards to the uninformed" -argument doesn't float very well with me.
The fact of the day was, that the bandwidth of the PCI bus was getting short
bandwidth starved applications of the day. PCI-X was way too expensive
replacement bus so something cheap was needed and AGP fit the bill.

Speaking of bandwidth and bus'es, a lot of chit-chat has been going on about
if PCI Express is needed or not.. most arguments revolve around the fact
that current applications don't, quite, "need it", well no **** they don't
need it as there won't be applications designed to take advantage of it
before there is hardware to do that on! Basicly, what these new technologies
enable are New Ways to write applications.. a new breed of applications is
possible to develop! PCI Express will be very useful for image editing work,
while 32-bit per channel is not enough for some folks, it is a lot for some
fields of application.. imagine a photoshop-like software, where the
processing can be done using GPU -and- that the results are possible to
access *realtime* by the CPU! Current buses like AGP 8x have excruciatingly
slow read bandwidth.. virtually useless for *smooth* realtime work. All
developments in this direction give me erection, but that's just me.

Hope this explains my position on the issue better.

> slow read bandwidth.. virtually useless for *smooth* realtime work. All
> developments in this direction give me erection, but that's just me.

Example of this, don't even have to think of filters or brushes or.. simple
things like layers would be ultra-smooth when done with GPU's -- even better
if can modify the layers directly inside the GPU, even if not, we can still
transfer modified regions to the GPU for layer composition (which can be
very flexible to configure since it can be done with fragment processor!).

Basic image transformations while editing such as scaling, rotation and
panning will be virtually free with GPU aswell. These operations burn a lot
of CPU per pixel when done using traditional methods. This is possible, up
to a degree, even with current BUS protocols.. but full duplex connection
between the host system and the graphics processor can't be bad for giving
more flexibility for the application.

Any bets if the Photoshop 10.0 has "PCI Express required" sticker on the
box? (If Adobe won't do that, someone else will and grab the market, mark my
words..)

Also, more bandwidth and especially fast both write AND read from the GPU
will mean that very, very large pictures will also be feasible with this
kind of system-- you need only to fit the # of pixels you are working with
and a little bit extra for buffering so that transfers can be done in the
background in case the client scrolls, scales or whatnot. The Worst Case
would be when a HUGE image, say, 80K by 80K is fully zoomed out.. obviously
in this kind of situation the software would have to track where the
cursor/brush is at, and keep a 1:1 copy of that region-of-interest so that
any brush ops will be efficient.

Even worse is that if that 80K by 80K image is "select all" 'd and some
filter is run, it will in no hell fit completely in the GPU local memory
(well how would I know, maybe in 2006 we have 120 GB of memory in the
graphics card.. or let's make it 2010

Still, if we process the image in block of, say, 4096x4096.. and swap the
results back into the system ram the process would be a hell of a lot faster
than doing all with CPU. That's where we want the bandwidth for, among other
things!

Photoshop, Gimp, Paintshop are all neat little programs.. but if the thought
of 100% smooth, realtime image editing with very complex brushes, filters,
fully programmable layering and what not doesn't wet the appetite I don't
know what will! Gamers ofcourse won't be impressed but to hell with them!