AGP texturing in Win2k

[dZeus]

Hi, everybody already knows about the Win2k 15.8MB limitation on AGP textures in system RAM (the so called non-local textures) with the G400. Matrox said that the GART driver (in my case a Intel BX chipset GART driver) was the problem. Intel said that juridically Matrox is responsable for providing GART drivers, but hinted that I should ask Microsoft about this issue. Microsoft, of course, have not yet responded to me about this.

While I assumed that the GART drivers would show the problem regardless of the videocard installed, I decided to test it on a nVidia based Win2k system, just to be sure.

Surprisingly, on those systems (tried 2 different nVidia-based systems so far), there is absolutely no non-local texture memory at all. The nVidia cards use the DMA AGP texturing implementation, opposed to Matrox who uses DIME. May this be the difference, or did nVidia disable AGP texturing completely in Win2k?

Can anyone with a non-nVidia (or nVidia for that matter) check how much non-local AGP memory they can address? This can best be tested with PowerStrip, available from www.entechtaiwan.com

When you load powerstrip, click on the information icon on the right of the toolbar, and check the "OpenGL-DirectX" tab for non-local texture memory.

Thanks

[dZeus]

Possible bug in Powertrip??!!

When I ran 3DMark on one of the 2 systems with the nVidia card (16MB TNT1), I could run the 32MB texturing test! System Info in 3Dmark2000 showed that there was 31.6MB of non-local texture memory, exactly double the texture memory of what I can address with the G400... maybe due to the DMA implementation? Very weird, but anyway, you should now check for the 3DMark system info rather than PowerStrip's findings.

To get the amount of non-local texture memory, substract the amount of memory on your card from the result it shows for 'total video memory (NOT total texture memory).
----------------------------------------------------

Update:

I deducted the following from what 3DMark2K's System Info reports:

Matrox G400:
Total Video Memory = Actual amount of memory on the videocard (32MB in this case) + max. addressable non local texture memory (15.8MB in this case)
Total Texture Memory = 'Total Video Memory' - framebuffer size

nVidia TNT-1 and Geforce:
Total Video Memory = Actual amount of memory on the videocard (32MB in this case) - framebuffer size
Texture memory = 'Total Video memory' + max. addressable non-local texture memory (31.6MB in this case)

so.... Does anyone know a bit how DIME and DMA work? I am confused!

[This message has been edited by dZeus (edited 28 November 2000).]

[DosFreak]

With the 7.17 drivers I can run the 64m test just fine at 74+fps. Witht the 6.x the 64m test is like 0.1fps.

[kjliew]

AGP DMA
The textures stored in system memory have to be copied to local memory prior to any processing can be done by the graphics processor.

AGP DIME
The textures stored in system memory can be directly "executed" or processed by graphics processor.

Which is better?? Well Technically speaking, AGP DIME sounds better because it doesn't have the overhead of copying the textures from system memory to local memory before processing the texture. There is also more efficient use of local memory.

In real world, it all depends on the implementation. The overhead of copying the texture from system memory to local memory is negligible when proper scheduling and look-ahead is being done within the DMA engine, ie. the DMA engine will finish the copying before the texture is needed by the graphics processor. It's the same technique as instruction/data prefetch used in modern processors to prevent stalls in the execution pipelines. When this is done correctly, you can see that AGP DMA is actually faster then AGP DIME, because once copying is done, the graphics processor enjoys the enormous bandwidth of local memory during texture processing.

AGP DIME has better performance handling large texture. As texture size grows, the overhead of copying also increase. For AGP DIME, there is hardly any impact from texture size as only texture vertices need to travel across AGP traffic.

[dZeus]

Dosfreak: was that in Win2k? and how many MP does your videocard have on-board? What does 3DMark2K report as values in the System Info program?

Kjliew: thanks for the explanation... I guess this is also the reason of the different way that 3DMark displays the free texture memory: on the G400 it shows the non-local texture memory, as if it is coupled 'more closely together' with the onboard video memory.

[DosFreak]

1. Yes, Windows 2000 Pro.
2. Geforce 2 GTS 64m
3. Don't Remember.
4. This was on a Soyo SY-5EMA+ (K63-400@433 124mhz FSB X3.5 and a Abit BE6 P3550@630)

[dZeus]

If you have a 64MB videocard, you should be able to run the 64MB AGP texture test without a problem, because the total texture memory (64MB - framebuffer + 31.6MB max. addressable non-local AGP texture memory) exceeds the 64MB test with quite a margin. So nothing unusual going on there

[Raptor^]

dZeus - I first looked into this issue a long time ago when the first G400 drivers for win2k were released.

They actually tried to use textures beyond the amount the GART driver gave them and ended up
1. Crashing (most of the time )
2. Texture stuff with random parts of memory for a new and funky effect

At that time, I tried the same sort of test on a TNT2. It didn't crash, but its AGP memory reported was nowhere near the AGP aperture size of the machine. I would have discounted any differences between the reported memory sizes because of the bug in the G400 driver and that the TNT2 was in another machine.

If you ask me there is definitely a problem in the GART driver (not sure who's responsibilty this is, poss MS) or possibly some more underlying code. I'm not sure its limited to Intel chipset boards.

[dZeus]

I am absolutely sure it is the GART driver, and possibly a Win2k limitation that the GART driver can't work around... maybe this is one of the excuses of MS that Win2k is not a 'consumer/gaming os', but a 'business os'. The other main limitation being the lack of support for multiple monitors off one vga core.

Oh, and, surprise surprise, MS haven't responded to my email I sent them a week ago yet. Probably never will.

Very funny how this goes:
- Matrox says it is the GART driver
- Intel says the videocard manufacturer juridically is responsible for the GART driver, but hints *ask MS*.
- MS says... nothing