Fast pixel rendering

Drawing 20 million pixels one-by-one per second is going to be hard. It''s akin to 640x480 animation at over 60 frames per second. Ouch.

If you restrict your thinking to individual pixels, it''s going to be hard for you to make use of the card''s native 3D accelerator. What is your application?

Are you looking for pixel rendering, or polygons? If you want to manually mess with pixels, you''re probably best with DirectDraw. If you want polygons you need to give people more information on what your project is.

---

Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions

Generate a new Texture based on your Pixel Data,
apply those to a billboarded Polygon and
just render that stuff, but 20 Million Pixs ...

If you wanna render a video on screen, you could
pre-create the texture objects in ogl

Clarifications
--------------


The application is going to be (hopefully) a realtime raytracer. The 20 million pixels/second number is based on appx. 26 frames per second (my dream goal) at 1024x768. Of course that is still a very rough estimate, but its a good thing to shoot for.

Since each pixel has to be calculated individually each frame, a fast pixel plotting function is a must.

If need be, the 20 million goal can be sacrificed for 16 million, but more is better.

Apoch
Lead Developer
The Freon Project

If you were thinking you need PutPixel(x,y,colour) then forget about it. With raytracing your stepping across the frame buffer one pixel at a time anyway, so you might as well just ''poke'' to memory. Use DirectDraw for accessing video memory (which is faster!) and get a standard pointer to memory so that:

int offset = 0;
for(int y=0; y<768; y++ )
for(int x=0; x<1024; x++,offset++ )
pVideoMem[offset] = CalculatePixel(x,y);

( Just accurred to me how oldschool this is However this might not be very efficient depending on how you designed your engine (ie the calculations of pixel colour at the object).

p.s Nice to see some Frank Black fans out there

If you want to fling bytes as fast as you can at the card, you want to use DirectDraw. Direct3D and OpenGL have their place, and this is not it. For straight access to the video memory, you''re not going to do any better than DirectDraw. If I were you, I would use the newest version: DirectDraw7.

Personally, if I had to do per-pixel twiddling and I couldn''t use any 3D hardware to help with things like filling and copying, I probably wouldn''t try to do stuff straight into video memory.

Video memory is sat on the other side of the graphics bus (i.e. much slower than access to main memory), and is totally non-cacheable. As an example of what just being able to use the cache buys you, throughput from main memory on a P2 system is around 800MB/s whereas from the L2 cache it''s 1.3GB/s. Furthermore access to something in the cache takes around 4 cycles and an uncached access direct to the same memory takes around 39!

So what I''d do (probably using DirectDraw if D3D wasn''t an option):
- create 2 surfaces in either system or AGP memory
- lock a surface, write pixels and unlock
- Blt()/BltFast() that surface onto the video primary surface
- next frame, use the *other* system/AGP surface

Going straight to AGP or system makes the most of CPU throughput. If the pixels are written to memory in a sequential order you''ll maximise use of burst writes and caching.

On modern cards, the Blt/BltFast calls will use DMA to transfer the data over the bus into video memory. The idea of using two system memory surfaces is that the DMA can be active transferring the current frame while you do all the CPU intensive pixel writing for the *next* frame.


If I could rely on hardware 3D I''d probably go for more of a hybrid approach:

- do the same as the above, except onto dynamic textures rather than DD surfaces.

- slap those textures onto screen space quads (or low-polygon "proxy" geometry) - these can even be stacked in Z space for things like translucency etc.

- use 3D hardware to do surface filling, instancing, hardware Z buffering, anti-aliasing, filtering etc etc


The second approach could use knowledge of the scene such as which objects intersect to optimise the above.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com