I did the test on this setup:

Pentium 4 1.3 ghz (i know... its a p.o.s. with the 256k l2 cache...)
128 PC600 RDRAM
4x agp slot (obviously since it is such an old mother-board)
and last and most definately least... a Tnt2 pro running at 170 core and 190 memory

When i tested using the software... my Tnt2 got...
about 120 fps in the windowed mode at 720x480 without downloading the images
it got approx. 130 fps when downloading the images and the transfer was anywhere from 120 mb/s minimum to 160 mb/s maximum (and those arent peak values... its ran at about 123 mb/s during one test... about 140 mb/s 1 test and about 160 mb/s one test... so you be the judge of which to believe)

So... anyone who cares to read this... read away....

Daniel

Meckano again.

Just did the feared, uninstall of the directx 'core' Win98se. All works like before, no improvements. Reinstallation took 2 hrs. of waiting for video driver.
- Startup of other programs took time too, like Unreal Tournament, had to re-initialize I guess. :)

Me again, 3rd posting in a row :)
I just installed the latest supported driver from ATI, May 15/03, fps dropped to 189, and 6.3 respectively.

Now that ATI has redone their site, it seems the file Date Dec.09/02 was not for win98se.

~~~ And the band played on.

This and the previous poste from meckano@yahoo.com

and I have win98se, and poste time well, right now it's 8:39, think there is a bug there too. I asked for GMT -5 correctly.

It may be the chipset?
I have:
GA-7DXR M/B
- AMD 761+686B AGPset chipset
AMD Athalon XP 2400+
512M DDR
ATI 7200 64M SDR (with a DX2 cpu fan, self installed)
- Running in 4x with fast write off; 256M aperture was only thing that slowed results a little.

With the default screen size, I was getting:
- 277fps
- 10.07fps @ 14.6MB/s after pressing 'T'(downloading)

Hope this helps someone :D

Quick comments regarding PCI-riser cards...

A one-to-one PCI-riser is fairly simple to do, as it just extends one existing PCI-slot.
But there are also one-to-many (2 or 3 is what I have seen).
Those require you to take certain signals that has to be unique for each PCI-slot, from either other existing PCI-slots or from pins on the mobo (provided that there are such signals available on the mobo of course)

Hmm, on a quite offtopic thing... i want a comments quickedit button.

Hey Ruy... i looked at the spec for AGP 3.0 just now... guess what i found.. [qnfortunately there is no such thing as a AGP to AGP bridge, thus it's impossible.
[/q] Well,, the specs refer do devices that would work as agp bridges, or fan-out devices. To add a multiport capability to the AGP3.0 controller. But still, as the AGP is a port its only capabal of one device, hence some extra enumeration schemes that must be transparat for the cards. I dont know of any existing devices, but they are possible from AGP3.0 at least.

And for the people saying its a bus. Go read the spec. It may look like a bus in some ways, it may even use some of the pci transfer schemes. Although this is mostly between itself and the main memory. But by definition its not called Accelerated Graphics [b]Port[/b] for nothing. A bus is not usually a single device implementation even though it can be used for it.

And yes, i also think the term bus is getting looser and looser. Thats one of the things with language. Words tend to drift from one meaning to another over the course of time.

AG #107, it depends on the implementation of the pci bus in question. You can implement a pci bus so its only made for one device, then you must have a pci-bridge device to add more devices.

What a bridge as the intel 21150 Transparent PCI-to-PCI Bridge
does is that it couples to the primary bus and add a secondary bus with its own arbiter and extra clock signals, live insertion support, etc.

So if the primary bus support 6 devices. A bridge can make you use more then that. If i got the information correctly.

So in effect it splits the bus.

A riser on the other hand doesnt add any capabilities beyond what the chipset implementation can take. Many oem's just use risers on their uATX boards to switch it from a tower to desktop format etc. Or to minimize the room a say.. 4 device pci bus take on the mobo.

Ryu, why would it require a PCI to PCI bridge? You can buy PCI risers in some off-beat stores, they don't have any special hardware on board.

OK, some facts for the melting pot. I wrote a benchmark last night that did DirectDraw and OpenGL pixelblock transfers, both ways across the AGP bus. Now, I wouldn't call my results totally rigorous (there are various versions of drivers, no Win9x machines, a couple WinXP & the rest are Win2k), but I ran many of them multiple times, on a selection of machines/cards, & got pretty consistent numbers each time. Also, the DirectDraw readback numbers agreed fairly closely with the Studio Magic Direct3D results.

(Write denotes system to gfx card, Read denotes gfx card to system)

ATI Radeon 8500DV / P4 1.4 GHz

DDraw Write: 358.20 MB/s Read: 6.70 MB/s
OpenGL Write: 56.36 MB/s Read: 96.60 MB/s

ATI Radeon 7200 / Athlon 2100+ x 2

DDraw Write: 345.04 MB/s Read: 12.26 MB/s
OpenGL Write: 50.93 MB/s Read: 75.83 MB/s

ATI Radeon 7200 / Athlon 1700+ x 2

DDraw Write: 347.28 MB/s Read: 12.24 MB/s
OpenGL Write: 51.06 MB/s Read: 107.21 MB/s

ATI Rage 128 PCI / Celeron 300A @ 450 MHz x 2

DDraw Write: 113.75 MB/s Read: 8.54 MB/s
OpenGL Write: 47.98 MB/s Read: 2.58 MB/s

nVidia Quadro DCC / P4 Xeon 1.5 GHz x 2

DDraw Write: 265.70 MB/s Read: 8.67 MB/s
OpenGL Write: 482.03 MB/s Read: 157.60 MB/s

nVidia GeForce 4MX 440 / P4 Xeon 1.7 GHz x 2

DDraw Write: 315.47 MB/s Read: 8.67 MB/s
OpenGL Write: 411.88 MB/s Read: 126.17 MB/s

SGI 320 Cobalt / P3 450 MHz x 2

DDraw Write: 189.52 MB/s Read: 18.92 MB/s
OpenGL Write: 304.52 MB/s Read: 183.97 MB/s

Matrox G400 / Celeron 433 MHz x 2

DDraw Write: 133.27 MB/s Read: 11.33 MB/s
OpenGL Write: 2.42 MB/s Read: 2.17 MB/s

A few things struck me:

- OpenGL does [b]WAY[/b] faster readbacks, especially on nVidia hardware.
- OpenGL is faster for writes too, on nVidia, but a lot slower on ATI
- ATI seem to optimise more for DirectX
- The SGI's unified memory architecture does help, though not as much as I would have expected.
- Matrox's OpenGL drivers sucked big time.
- These numbers would look better in one of Damage's graphs.

Anyway, I'm convinced that there's no particular hardware problems involved, other than perhaps readback being limited to PCI66 speeds. I have no idea why DirectX readbacks are so much slower - can it really be that every single company just hasn't bothered to optimise this path, even though they have for OpenGL? Or is there something within DirectX itself that's holding them all back?

BTW, if anyone wants a copy of the bench program, email me:
d a n i e l @ e y e o n l i n e . c o m.

[quote]A motherboard with a single PCI slot and a VLink or something connecting the NB to SB (meaning no additional devices are dongled off the PCI) is still a bus because it CAN support multiple devices, even if only one slot is IMPLEMENTED.[/quote]

Actually. I do believe such a riser would require a PCI to PCI bridge in order to support multiple devices from a single connection point. Likewise the AGP bus could support multiple devices, unfortunately there is no such thing as a AGP to AGP bridge, thus it's impossible.

The lack of the bridge does not make it something other than what it is.

100, put an AGP riser card in your AGP slot and then connect multiple AGP graphics cards to it. Go ahead, I dare you. It's a bus, right? I can do that with my PCI slots because THEY'RE a bus.

100 is mistaken in calling AGP a bus, just because it cribs off of PCI (as I commented earlier). AGP itself is not a bus. If it were, the single AGP controller could handle multiple AGP cards.

A motherboard with a single PCI slot and a VLink or something connecting the NB to SB (meaning no additional devices are dongled off the PCI) is still a bus because it CAN support multiple devices, even if only one slot is IMPLEMENTED.

That's the difference. It may be a semantic argument, but it's a legitimate one.

Originally Posted by sschaem
Post 100:

What you mentioned do not explain the number from the benchmark.

Taking the Geforce4 as example.

If OpenGL can deliver 200 meg second but Directx8 only deliver 10meg, its clearly not a AGP/CPU issue. But a driver or possibly drive/API/OS architecture issue.

It would be allot to ask for Intel to redesign the AGP spec, and then have every single company comply to the spec.
But this is not needed, the spec is good as is. It \'only\' need consistency in the DirectX driver to match at least OpenGL performance.
Going from 10meg to 200meg in the case of the geforce4 is a 20x speedup, with no HW redesign.

Also, lets not forget that even nvidia TNT core come with DMA support for video->system transfer. All VIVO capable core do, and that include the majority of the cards.
All motherboard that support VIVO card support DMA.
(I dont know of any MB that dont support AGP DMA)

AGP, GPU, MB core fully support DMA. Its just not enabled in the majority of the GFX card drivers for graphics.
(But it is already for video capture, it wouldn\'t work otherwise)

To post 99: What make more sense, update the driver to use
DMA or develope a multipass DVI capture system and synchronization software? (Note: you can only capture what is visible with grabber HW)

Stephan

Told you it was a bus.

Can somebody please clear up this Win9x / WinNT discrepancy?

The readback performance is usually limited by quite a few constraints.

First off, AGP is a CPU memory to GPU bus. The reverse direction is more or less a 66MHz 32bit wide PCI bus, with a maximum bandwidth of 252MB/sec (assuming burst cycles).

Most graphics chips do not implement a GPU to CPU DMA capability, so that one has to read back the image via normal CPU accesses. Each of those CPU read accesses tend to be not pipelined, and not burstable, which essentially
gets your normal available read bandwidth over the bus down to around 16MB/sec.

Assuming you had DMA capability from GPU to CPU, then the AGP GART is not usable, as there is no bus-snooping between AGP and PCI cycles (and hence doing such a thing would lead to inconsitencies). Hence you have to DMA to normal PCI memory (i.e. cachable CPU memory). Many OSes limit the maxmimum number of contingous pages to a very small number (something like 64k in total). Those small sizes are not very usefull, if you want to transfer 16MB for one single frame.

- Thomas

Has anybody bothered to test this with PCI cards?

Also, Would a DVI -> HDTV Tuner work?

If you wanted, Im sure you could tweak the output so that each fram was only 1/4 the image so you would get an image 2x2 as large as the HDTV format. You could also output 64 bit colour by outputting the 1st 32 bits as one image and then the next 32 bits as another. Granted these are hacks, but they should do until Cardmakers to a bottom down redesign of their cards.

I have seen a bus go to only two points on it's route so its still a bus. It cost $1.75 to ride

I agree that the download bandwith is not any good. But there
is a major point being missed.

If you want to accelerate complex scene rendering with the help of
3D graphics card you will *not* be creating scenese that can
be rendered at 30Hz!
You will create scenes that will take several seconds or minutes
to render with the help of acceleration. Then suddenly the
download rate doesn't have to be such a big bottle neck (ofcourse
it should be fixed nontheless).

/RC

btw, 89, re-read the definition you qouted. It clearly denotes the plural.

AG89: You are mistaken. While the use of 'bus' may be gradually BECOMING something like your definition from mis-use, it has nothing to do with parallel connections.

The term 'bus' comes from old-school electrical wiring, where a bus could be something as simple a copper rod feeding multiple service connections inside a breaker panel.

A 'bus' on a PC is technically a connection that can service multiple devices, like PCI. AGP cannot do this, AGP is not a 'bus'. If it were, you could connect multiple graphics adapters to this AGP 'bus'. Again: It has nothing to do with the number of parallel traces. A point-to-point topology is, BY DEFINITION, not a bus.

Originally Posted by sschaem
to post 90:

Why? the cards can already deliver 100-200meg across AGP.

Any HW hack would be just that, a hack.

Stephan

Originally Posted by sschaem
to post 88:

Nvidia already got their driver already optimized for OpenGL..

Why create a new concept just for a single driver optimization?

70$ VIVO cards already have much, much more complex code when they offer full WDM capture.

Should we all pay more for dual head because of the driver feature? Not everyone use dual head.

Stephan

Originally Posted by sschaem
To post #87.

Not all game have special code that can do non realtime replay.
This require input capture code and replay code, all that because drivers are not doing their job.

This would help doing video capture of games for article, marketing preview, etc..
And if you think outside the \'game box\' you see that people
also capture productivity app output for tutorial and whatnot.

Nobody argue that this is THE killer app to make readback
optimized in drivers... Its just one of the so many thing that is
now imposible to do.

Stephan

Originally Posted by sschaem
To post 85:

The fact that win9x post number like 80 -130 meg second.

The fact that OpenGL deliver 130-200 meg second.

The fact DMA over AGP is available since the i740.
This is how all VIVO card transfer video to system memory
at 20+ meg second with little overhead.

But its true... it might not be the drivers, but an OS issue...

Now that this article is out, and people start talking we are
bound to find out.

Stephan

Build a card that splits the digital data heading to the RAMDAC and pipe it through an MPEG compression chip then out a proprietary digitial interface that can be trademarked and licensed. Something like the current SP/DIF optical audio.

AG#86 bus: A parallel circuit that connects the major components of a computer, allowing the transfer of electric impulses from one connected component to any other.

There is a such thing as a point to point bus. AGP has a bus.

Just my thoughts. I believe that the statements are ture in this article. However I would not go anywhere as far as to call it a problem. We have to consider the market and use for which these products were desingned. They are supposed to run fast and discard. There are some solutions to this delima.

1. Buy the version of the card desinged for the other less entertaiment uses (quadro instead of Geforce)

2. Companies could release XXX drivers like CAD or render in general. ATI use to do this for some cards but I think they have stopped. These driver would allow for max render ability but probally would suck at games.

3. A capture device just for the card renders. Something like

System -> AGP bus -> VPU -> capture device. (probally all or mostly digital capable of highbandwidth transfers and captures. No actual video output.)

Just my thoughts

Video of my game play saved out?

Why would anyone want that?

Quake provides a much better, space efficient method, which even allows for postproduction angle changing.

It merely saves the game play data, and lets the game engine render it out on 'playback'.

This is used extensively on Machinima.

My point is that one of those points in pointless. =)

Alan