PDA

View Full Version : AGP pixel upload/download



Won
12-06-2002, 07:07 AM
Has anyone been successful in using the pixel data range extension to work? What are the bandwidth numbers? Does AGP (1x, 2x, 4x, 8x) make a difference?

-Won

Tom Nuydens
12-06-2002, 09:13 AM
I tried it out just last night, as a matter of fact. My glReadPixels() throughput went from 138 MPixels/sec to 745 MPixels/sec! It's a rather contrived benchmark at the moment, though, as all it does is render a single triangle and then do a glReadPixels() on the whole framebuffer. Nothing is ever done with the result of this readback.

I used (0, 0, 1) as the arguments to wglAllocateMemory(). Other settings result in much poorer performance. I haven't tried to fiddle with my AGP speed yet, nor have I benchmarked glDrawPixels() performance.

-- Tom

Won
12-06-2002, 09:57 AM
That is somewhat encouraging. With those arguments to wglAllocateMemory, aren't you getting video memory? In which case these results aren't all that interesting.

138 MPixels/sec => 552 MBytes/sec (assuming 32-bit pixels) is actually pretty good for AGP.

-Won

Adrian
12-06-2002, 10:28 AM
I now have it working, readpixels performance went from 40 Million pixels/sec to 50 Million pixels/sec. I don't understand why my figures are so much lower. (I haven't tried the 0,0,1 combination yet though) I have an XP2000,AGP4x + GF4600, latest detonators. I am using the accelerated format, BGRA and my memory is 32byte alligned. Tom what is the spec of your machine? can you release the exe so we can benchmark with it.

The async aspect is really cool!

[This message has been edited by Adrian (edited 12-06-2002).]

Diapolo
12-06-2002, 10:35 AM
Does anyone know, where I can find the latest header file for OGL extensions, that contains the latest ARB ones and the whole new bunch from NVIDIA?

DL link would be veryy nice, thanks http://www.opengl.org/discussion_boards/ubb/smile.gif.

Diapolo

Tom Nuydens
12-06-2002, 10:58 AM
Oops. I made a typo: the numbers I gave you aren't MPixels/sec, they're MBytes/sec. MPixels/sec would be four times lower, i.e. went from about 35M to 180M.

Yeah, (0, 0, 1) would give you video memory. I wouldn't say that it isn't interesting, though. I'm sure there's plenty of interesting things you can do with the data without ever having to touch it with the CPU. (Render-to-vertex-array?)

Adrian, my machine is an XP1600, GF4 4200, AGPx4, latest drivers. Your 40 MPixels/sec sounds about right, and the smaller increase you get with PDR is probably due to your using AGP memory instead of video memory. Which wglAllocateMemory() arguments did you use?

-- Tom

Adrian
12-06-2002, 11:51 AM
I used 1,0,1 and 1,0,.75 and they gave me similar results.

Initially I had problems getting the extension to work.

The first problem was that I was initialising my window with
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA);
This didn't give me an alpha buffer so readpixels fell back to unaccelerated synchronous mode.

glutInitDisplayMode(GLUT_SINGLE| GLUT_RGBA); does give an alpha buffer as does
glutInitDisplayMode(GLUT_DOUBLE| GLUT_RGBA |GLUT_ALPHA);

The second problem was that I was using glFlushPixelDataRangeNV as a flush to start the read pixels. It actually behaves more like glfinish, it hangs until the readpixels has finished. To start the readpixels asynchronously I should have used glflush.

Just thought I'd mention it in case others encounter the same problems.

Coriolis
12-06-2002, 12:00 PM
I think there is confusion about the arguments to wglAllocateMemoryNV. The read frequencies and write frequncies are NOT how often the video card will read or write the data. They say how often the program itself is going to read and write the data. Both values should be 0 in almost all cases, and I remember reading that anything above 0.25 for either value forces it to use system memory.

Won
12-08-2002, 12:10 PM
Well, about the read pixels to video memory not being interesting: I certainly agree that this is a useful feature. What isn't all that interesting is how fast it is. It is pretty darn fast, but is it as fast as you'd expect it to be considering the bus its going over? I would almost expect those numbers to be significantly higher. Besides, my particular application would require AGP downloads for it to be useful (the data needs to get streamed out of the computer after some processing).

Still, anyone with AGP 8x?

-Won

jra101
12-08-2002, 12:18 PM
Originally posted by Diapolo:
Does anyone know, where I can find the latest header file for OGL extensions, that contains the latest ARB ones and the whole new bunch from NVIDIA?

DL link would be veryy nice, thanks http://www.opengl.org/discussion_boards/ubb/smile.gif.

Diapolo

You can find one here: http://cvs1.nvidia.com/OpenGL/include/glh/GL/glext.h

Diapolo
12-08-2002, 12:49 PM
Great, thank you very much http://www.opengl.org/discussion_boards/ubb/smile.gif.

Diapolo

Adrian
12-09-2002, 07:17 AM
Originally posted by Coriolis:
Both values should be 0 in almost all cases, and I remember reading that anything above 0.25 for either value forces it to use system memory.

Although *readpixels* is faster with 0,0,1, any processing(by the cpu) on the data is extremely slow since it is in video memory. The best overall speed comes from using combinations that allocate system memory. Unsurprisingly if I just use malloc I get the same overall speed. I can't see how I can benefit from using wglAllocateMemoryNV with normal usage of readpixels.



[This message has been edited by Adrian (edited 12-09-2002).]

mcraighead
12-09-2002, 07:33 AM
From the extension spec:

* How should an application allocate its PDR memory?

The app should use wglAllocateMemoryNV, even for a read PDR in
system memory. Using malloc may result in suboptimal
performance, because the driver will not be able to choose an
optimal memory type. For ReadPixels to system memory, you might
set a read frequency of 1.0, a write frequency of 0.0, and a
priority of 1.0. The driver might allocate PCI memory, or
physically contiguous PCI memory, or cachable AGP memory, all
depending on the performance characteristics of the device.
While memory from malloc will work, it does not allow the driver
to make these decisions, and it will certainly never give you AGP
memory.

Write PDR memory for purposes of streaming textures, etc. works
exactly the same as VAR memory for streaming vertices. You can,
and in fact are encouraged to, use the same circular buffer for
both vertices and textures.

If you have different needs (not just streaming textures or
asynchronous readbacks), you may want your pixel data in video
memory.


In other words, malloc() will guarantee that you will never get faster than PCI readback speeds.

I put these details in the spec for a reason...

- Matt

mcraighead
12-09-2002, 07:40 AM
Originally posted by Tom Nuydens:
(Render-to-vertex-array?)

Right, this is the primary intended use of read PDR in vidmem. Of course, it's pretty difficult to use it this way unless you also have float buffers; 8-bit vertices aren't all that interesting. 16-bit half float vertices, on the other hand...

I would hope you could get better than 745 MB/s doing PDR ReadPixels to vidmem, depending on how much video memory bandwidth you have?

- Matt

V-man
12-09-2002, 07:52 AM
>>>The driver might allocate PCI memory, or
physically contiguous PCI memory, or cachable AGP memory, all
depending on the performance characteristics of the device.<<<

The first one means that the allocated space may not be contiguous?
cacheable AGP memory means what? You mean the video card will be doing the caching? AFAIK, AGP memory is not cached by the system cache, which I find a little odd.

I should really ask some of this on hardware groups http://www.opengl.org/discussion_boards/ubb/smile.gif

V-man

ericw1
12-09-2002, 08:50 AM
Originally posted by mcraighead:
Right, this is the primary intended use of read PDR in vidmem. Of course, it's pretty difficult to use it this way unless you also have float buffers; 8-bit vertices aren't all that interesting. 16-bit half float vertices, on the other hand...
- Matt

8-bit verticies aren't interesting, though 4x8-bit as a displacement fed into a vertex program can definitely be interesting.

~Eric

mcraighead
12-10-2002, 03:45 AM
Originally posted by V-man:
The first one means that the allocated space may not be contiguous?

Not necessarily physically contiguous. Most memory isn't.


Originally posted by V-man:
cacheable AGP memory means what? You mean the video card will be doing the caching?

No, AGP memory where the pages are marked as cacheable by the CPU. Most AGP memory is marked write-combined and uncacheable; in this case, you'd want it to be cacheable.

- Matt

Adrian
12-12-2002, 02:52 PM
You can benchmark glReadPixels performance with the Pixel Data Range extension using this app written by Matt Craighead. (Source included)
http://planet3d.demonews.com/PixPerf.zip

Run it with the following command line options:

pixperf -read -type ubyte -format bgra -size 128
pixperf -read -type ubyte -format bgra -size 128 -readpdr

On my GF4600 XP2000 AGP4x, latest detonators:
42.5 MPixels/sec without
50.7 MPixels/sec with the extension.

I would be particularly interested to see some AGP8x numbers.

[This message has been edited by Adrian (edited 12-12-2002).]

ScottManDeath
12-13-2002, 01:21 AM
HI

I run the app with following results:

GF4600 XP2400 AGP4x, DET 41.03:
41.6 MPixels/sec without
50.95 MPixels/sec with the extension.

Bye
ScottManDeath

Adrian
12-13-2002, 05:27 AM
On my other comp GF2 GTS P3 700 AGP2x, latest detonators:
34.1 MPixels/sec without
44.5 MPixels/sec with the extension.

Won
12-13-2002, 08:22 AM
Another thing I'd be interested to see is the "download" performance for the UMA nForces. Does wglAllocateMemory help at all in these architectures? Does it help to have "excess" bandwidth like with dual-channel DDR? What about when you use AGP instead of the integrated graphics?

These are alot of questions. It would be great if someone could try these out, but I bet that Matt could just answer these straight away...

-Won

abrodersen
12-13-2002, 09:31 AM
Hmmm. I get the following results

GF3 Atlon 1200 AGP4x, latest detonators:
10.9 MPixels/sec without
12.0 MPixels/sec with

That doesn't sound right! What could be wrong with my setup? The driver says it's running AGP4X.

Anders

Adrian
12-13-2002, 10:05 AM
Originally posted by abrodersen:
Hmmm. I get the following results

GF3 Atlon 1200 AGP4x, latest detonators:
10.9 MPixels/sec without
12.0 MPixels/sec with

That doesn't sound right! What could be wrong with my setup? The driver says it's running AGP4X.

Anders

FSAA effects performance but not enough to account for those figures.

abrodersen
12-13-2002, 10:09 AM
FSAA is disabled, so that shouldn't be the problem.

Anders

mcraighead
12-13-2002, 12:33 PM
My nForce1 integrated graphics do perform somewhat better than any AIC does on this benchmark, due to the internal "AGP 6x"-speed bus.

- Matt

Lars
12-14-2002, 03:51 AM
i have some very interesting results:

12.19 Mpixels/sec without PDR
46.89 Mpixels/sec with PDR

on a Geforce2Go AGP 4x Det 41.09

where does this extreme boost come from, or better why is it so slow without the extension ???

Lars

Melekor
12-15-2002, 03:54 PM
geforce 4 MX 440, athalon XP 1800+

without: 22.43 Mpixels / sec
with: 54.2 Mpixels / sec

Melekor
12-15-2002, 04:09 PM
How is my time with the extension better than the gf4 Ti guy and without, lower? Doesn't seem to make sense.

pocketmoon
02-17-2003, 02:13 PM
42 MPixels/s without pdr
48 MPixles/s with pdr

Geforce Quadro FX 2000 4xAGP bus.

glReadPixels VERY slow with floating point pbuffers http://www.opengl.org/discussion_boards/ubb/frown.gif (even reading back stencil)

0.8 MPix/second

Hoping this speeds up with future drivers!

[This message has been edited by pocketmoon (edited 02-17-2003).]

DFrey
02-17-2003, 04:17 PM
I'd like to try out that test, but the given url above is pointing to a 404 now.

Adrian
02-17-2003, 04:41 PM
This should work. http://ds.dial.pipex.com/town/plaza/yr20/PixPerf.zip
or http://www.adrian.lark.btinternet.co.uk/PixPerf.zip

DFrey
02-17-2003, 10:51 PM
Geforce 3 Ti 200 (stock clock), 700 MHz Duron
without: 31.3 Mpixels/sec
with: 48.6 Mpixels/sec

Eric
02-17-2003, 11:10 PM
Funny results:

Bi-Athlon MP 2000+, GF4 Ti4200, AGP 4x, Fast Writes enabled (does it matter?):

35.67MP/s without pdr
48.10MP/s with pdr

It looks strange that Melekor with a GF4MX440 gets higher results with pdr... I'd also like to hear some comment on Lars' question. Also, I am impressed by Adrian's results on his 2nd computer (GF2 GTS + P3 700).

Regards,

Eric

roffe
02-17-2003, 11:41 PM
The gf2 gts seems to be doing pretty well:

athlon 1gz,agp4x fast write,gf2 gts, latest drvs

41.41 Mpixels/sec without pdr
50.10 Mpixels/sec with pdr

kansler
02-18-2003, 12:16 AM
My turn!

PIII 866, AGP 2x, GF 2 MX400

32.0 Mpixels/sec
48.4 Mpixels/sec

Not too shabby.

Edit:

Does anybody know why bgra format is significantly faster compared to rgba?

[This message has been edited by kansler (edited 02-18-2003).]

ScottManDeath
02-18-2003, 12:21 AM
Hi

currently I use a glReadPixels(...DEPTH_COMPONENT...) followed by a glDrawPixels(...GL_LUMINANCE...) do display the contents of the depth buffer with plain memory.
Could this be accelerated using PDR ?? Perhaps alloate video memory and do a read draw without transfering the data into host memory ??

Bye
ScottManDeath

Adrian
02-18-2003, 12:54 AM
Originally posted by ScottManDeath:

Could this be accelerated using PDR ??

From the spec it looks like drawpixels isn't currently accelerated (see near bottom of page) http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_pixel_data_range.txt

Adrian
02-18-2003, 01:15 AM
This benchmark has raised more questions than answers.

I underclocked my XP2000 by 33% and the scores went down by about 5%. This implies that readpixels is only slightly dependent on the FSB or CPU. The AGP2x scores suggest that readpixels is only slightly effected by AGP speed. The graphics card also has little or no effect on the speed. So in the three years since the P3+GF2, readpixels speed seems to have hardly improved.

So what does effect readpixels speed? I can't think of anything else.

Adrian
02-18-2003, 01:33 AM
Originally posted by kansler:

Does anybody know why bgra format is significantly faster compared to rgba?



That question was answered here http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/004076.html

martin_marinov
02-18-2003, 11:27 AM
Hi,

I've ported the above program to linux. If someone is interested I can upload it somewhere or send it by e-mail.
The results are odd however:
Mandrake 9, NVDrivers 41.91
Toshiba Satellite 5105-S501 PIV 1.7GHz, GeForce4 Go, AGP 4x
w/o NV_pixel_data_range : 39MPx/s
with NV_ pixel_data_range : 37MPx/s

strange, ehh?
Also under WinXP on the same mashine:
w/o NV_pixel_data_range: 36 MP/s
with NV_ pixel_data_range : -------- (Nvidia/Toshiba still didn't released a recent driver version for GeForce4 Go. http://www.opengl.org/discussion_boards/ubb/frown.gif(, So I'm stuck with 28.xx drivers

But the most strangest thing is:
Suse 8.1, NVDrivers 41.91
Athlon XP 1800+(1533Mhz), GeForce4 Ti 4600, AGP 4x
w/o NV_pixel_data_range : 10.64MPx/s
with NV_ pixel_data_range : 10.56MPx/s
(no windowze on this mashine)

Any comments http://www.opengl.org/discussion_boards/ubb/smile.gif

Regards
Martin

MichaelNewman
02-18-2003, 02:23 PM
Does using VAR provide these same wacky results or is this just a PDR thing?

Looking at the results in this forum the gf2's seem to be doing better than the newer cards. Any ideas as to why this is the case?

V-man
02-18-2003, 04:17 PM
I think my system is a little slow. I'm getting a miserable 956 GPixels/sec
How can I improve the performance?

I:\PixPerf\Debug>pixperf -size 500 -color
3824301.500000 copies/sec
956075.375000 Mpixels/sec

I:\PixPerf\Debug>pixperf -size 500 -color -readpdr
22512868.000000 copies/sec
5628217.000000 Mpixels/sec

I:\PixPerf\Debug>pixperf -size 500 -color -readpdr -writepdr
25938738.000000 copies/sec
6484684.500000 Mpixels/sec

[This message has been edited by V-man (edited 02-18-2003).]

Adrian
02-18-2003, 04:31 PM
Originally posted by V-man:
I think my system is a little slow. I'm getting a miserable 956 GPixels/sec
How can I improve the performance?


Try running the same test as everyone else http://www.opengl.org/discussion_boards/ubb/smile.gif

pixperf -read -type ubyte -format bgra -size 128
pixperf -read -type ubyte -format bgra -size 128 -readpdr

with FSAA off.

Husted
02-19-2003, 12:06 AM
Hi,


Originally posted by martin_marinov:
Hi,

I've ported the above program to linux. If someone is interested I can upload it somewhere or send it by e-mail.
The results are odd however:


It is not very strange that you see these results on Linux. Although the Linux driver supports PDR, the driver does not allocate memory correctly. No matter which parameters you pass to glXAllocateMemory it always requests AGP memory, never system memory or video memory. Also the caching attributes are not set correctly - the driver never sets the mttr registers or the PAT entries. For fast readback you want cacheable system memory. For fast readback you may want to patch the drivers http://www.opengl.org/discussion_boards/ubb/smile.gif

Best regards,


Niels

[This message has been edited by Niels Husted Kjaer (edited 02-19-2003).]

martin_marinov
02-19-2003, 03:05 AM
Originally posted by Niels Husted Kjaer:
Hi,

It is not very strange that you see these results on Linux. Although the Linux driver supports PDR, the driver does not allocate memory correctly. No matter which parameters you pass to glXAllocateMemory it always requests AGP memory, never system memory or video memory. Also the caching attributes are not set correctly - the driver never sets the mttr registers or the PAT entries. For fast readback you want cacheable system memory. For fast readback you may want to patch the drivers http://www.opengl.org/discussion_boards/ubb/smile.gif

Best regards,


Niels

[This message has been edited by Niels Husted Kjaer (edited 02-19-2003).]


Hi,
Are you sure for this? I remember once I tested this with VAR and VAR performance was equal to the DLs - I though both are in the video memory. It is not surpising however if both are are cached in AGP mem (i.e. DL and VAR arrays).
But the difference between the atlon mashine and the pIV laptop..... http://www.opengl.org/discussion_boards/ubb/smile.gif

Regards
Martin

Husted
02-19-2003, 04:08 AM
Hi Martin,

I'm pretty sure about this. The problem is not the readback performance itself. The problem occurs when you try to use the memory you have just readback to, i.e. try to scan through (read from) the memory you have just read back.

Here is a couple of performance measures under Linux. The readback performance is measured with BGRA format, seq. access is a sequential scan (read) through the pixel data just read back, and rand access is a random scan (each element is accessed exactly once) through the pixel data.

Dual P3 1GHz (VIA chipset), GeForce Ti 4600, NVIDIA-1.0-4191:

PDR disabled:

readback: 112 MB/s
seq. access: 122 MB/s
rand access: 33 MB/s

PDR enabled:

readback: 191 MB/s
seq. access: 26 MB/s
rand access: 21 MB/s

1.6 GHz Intel P4 (mobile), GeForce4 440 Go, NVIDIA-1.0-4191:

PDR disabled:

readback: 150 MB/s
seq. access: 225 MB/s
rand access: 46 MB/s

PDR enabled:

readback: 175 MB/s
seq. access: 16 MB/s
rand access: 9 MB/s

So if you really want to use PDR under Linux you'll have to wait for NVIDIA to fix this - or do the patch yourself http://www.opengl.org/discussion_boards/ubb/wink.gif.

-- Niels

Lars
02-19-2003, 04:14 AM
Originally posted by martin_marinov:
(Nvidia/Toshiba still didn't released a recent driver version for GeForce4 Go. http://www.opengl.org/discussion_boards/ubb/frown.gif(, So I'm stuck with 28.xx drivers


I am using the 42.01 nvidia drivers on my toshiba with gf2go.
You can get mofied inf-files and info at http://www.geocities.com/madtoast/

I have also rerun my test with the newer drivers, and my results now seem to be "normal":
32.54 without
43.95 with pdr

dont know what has cuased this large difference in my first tests.

Lars

V-man
02-19-2003, 05:23 AM
Thanks Adrian for supplying the commands,

----------------------
GF3 Atlon 1200 AGP4x, latest detonators:
10.9 MPixels/sec without
12.0 MPixels/sec with
------------------------

Well I'm getting pretty sucky performance myself.
I have
GF2 GTS AGP 2x PIII 450 and FSAA is definitly off.
10.25 MPixels/sec without
11.59 MPixels/sec with

these drivers are not so great either 42.81. I had 41.09 before and they too had performance problems. With NV30emulate off, I get no difference. I really need that GFFX card!

Adrian
02-19-2003, 06:24 AM
I just set my machine to AGP1x via the BIOS and got exactly the same scores as when it was 4x???!!

Matt, in your post you suggested AGP was a factor in readpixels speed but I don't see any evidence of this. Can you explain where the bottleneck is, I can't find it.

What speeds do the ATI peeps get? you will need to comment out the code that initialises the pdr extension.

martin_marinov
02-19-2003, 10:30 AM
Originally posted by Lars:
I am using the 42.01 nvidia drivers on my toshiba with gf2go.
You can get mofied inf-files and info at http://www.geocities.com/madtoast/

I have also rerun my test with the newer drivers, and my results now seem to be "normal":
32.54 without
43.95 with pdr

dont know what has cuased this large difference in my first tests.

Lars




Man, you saved me... http://www.opengl.org/discussion_boards/ubb/smile.gif
I just though I will never have newer driver under windowze... That was not a big problem, since I'm using mainly linux, but anyway, it is good to have the new drivers, even for pure ... self esteam http://www.opengl.org/discussion_boards/ubb/smile.gif http://www.opengl.org/discussion_boards/ubb/smile.gif
I spend so much time looking for this before, really thank you very much http://www.opengl.org/discussion_boards/ubb/smile.gif

Regards
Martin

Hampel
02-19-2003, 11:25 PM
I, too, have very bad PDR results:

GF2MX, Athlon 1200, 41.09, FSAA off:

11,14 Mpixel/sec without PDR
11,82 Mpixel/sec with PDR

My experiments with VAR show strange results, too: the fastest code path was for memory allocated with malloc() instead of wglAllocateMemoryNV(). Every combination of read-frequency, write-frequency, and priority was worse than memory returned by malloc() (up to a factor of 2)!!! I only write to the memory in sequencial order (using memcpy() for at least 4kb chunks) and I use the NO-FLUSH-variante of VAR.

I've reinstalled my detonator yesterday (using the DriverCleaner from driverheaven).

Any suggestions?

azazello
02-21-2003, 02:45 AM
AMD762MPX, 2xDuron 1GHz, 512DDR200, GF2MX: WinXP, 41.09

- 36.63MPx/s
- 45.82MPx/s

azazello
02-21-2003, 07:13 AM
KT266, 1xAthlonTB 1GHz, 256DDR266, GF3ti500: Win2k, 40.72(AGP4x)

44.36 Mp/s
51.46 Mp/s

In next week I will test it on nForce2+2xDDR400+NV28(with and w/o AGP8x).

davej
02-22-2003, 01:46 PM
AthlonXP 2100+ nForce2 DDR400 GeForce 3 Ti200 Detonator 42.86 AGP 4x.

With the screen set to 32 bbp

35.5 MPixels/s without PDR
40.2 MPixels/s with PDR

With the screen set to 16 bpp

57.5 MPixels/s regardless of PDR setting.

Screen resolution and refresh rate don't seem to affect the results.

Nobody else seems to have mentioned bits per pixel. What colour depths are people running at?

dave j

azazello
02-26-2003, 12:56 AM
Niels Husted Kjaer was right about Linux(this problem exist even when both chips made by nVidia - NForce2+GF4)

KT266, 1xAthlonTB 1GHz, 256DDR266, GF3ti500: Win2k, 40.72(AGP4x)

44.36 Mp/s
51.46 Mp/s

under Linux(41.91)
41.494240 Mpixels/sec
41.994102 Mpixels/sec


nForce2, AthlonXP 2(166x12)GHz, 512DDR400, GF4ti4200with AGP 8x: Linux 41.91, SBA, FW enabled.

AGP 3.0 4x:
36.020668 Mpixels/sec
35.835522 Mpixels/sec

AGP 3.0 8x:
35.933765 Mpixels/sec
35.906204 Mpixels/sec

I think, I need to install Windows to nForce2 system and test one more time - by results is strange (KT266+DDR266 faster than nForce + Dual DDR400!!!)

Adrian
02-26-2003, 09:59 AM
Interesting results, thanks.

Though I am still none the wiser as to what effects readpixels performance.

The search continues http://www.opengl.org/discussion_boards/ubb/smile.gif

Davej, I think most people were running the test at 32bpp.