GL_ARB_fragment_program and glDrawPixels

[wprice99]

I am trying to get a fragment program to modify the pixels drawn using a glDrawPixels() call. The spec seems to imply that this should work, but my pixels remain the same.

The fragment shader is definately working as a rectangle drawn using glBegin(GL_TRIANGLE_STRIP), glVertex2f(), glEnd() is shaded.

Any ideas anyone?

This is using a GeForce FX5800 on Linux, using the latest driver 53.28

[Humus]

I don't think you're supposed to be able to run shaders on glDrawPixels() pixels.

[wprice99]

That's not quite how I understood it from the specification here: http://oss.sgi.com/projects/ogl-samp...nt_program.txt

Specifically, these parts:

Lines 353-359:

(17) Should fragment programs affect all fragments, or just those produced by the rasterization of points, lines, and triangles?

RESOLVED: Every fragment generated by the GL is subject to fragment program mode. This includes point, line, and polygon primitives as well as pixel rectangles and bitmaps.

And lines 1039-1063

 
                 _ +---------------+   FRAGMENT_PROGRAM_ARB
                 /| |    Point      |          enable
                /  | Rasterization |\           |
               /   +---------------+ \          V  o-------------+
       From   /    +---------------+  \                          |
    Primitive ---> |     Line      |---+++--->o    o             |
     Assembly \    | Rasterization |  / | |         |             |
               \   +---------------+ /  | |         |             |
                \  +---------------+/   | |   +-----+-----+  +----+-----+
                 \| |    Polygon    |    | |   | Texturing |  | Fragment |
                 - | Rasterization |   / |   +-----+-----+  | Program  |
                   +---------------+  /  |         |        +----+-----+
                   +---------------+ /   |   +-----+-----+       |
                   |     Pixel     |/    |   | Color Sum |       |
    DrawPixels --> |   Rectangle   |    /    +-----+-----+       |
                   | Rasterization |   /           |             V
                   +---------------+  /      +-----+-----+
                   +---------------+ /       |    Fog    |---> Fragments
      Bitmap ----> |    Bitmap     |/        +-----------+
                   | Rasterization |
                   +---------------+

[wprice99]

Some sample code which demonstrates this problem can be found here:
http://www.miramar.uklinux.net/opengl/drawpixels.cpp

When running, press 'R', 'G', 'B', 'A' to toggle masking of r/g/b colours on/off


[This message has been edited by wprice99 (edited 01-23-2004).]

[zeckensack]

Actually it should work. The color data can be referenced in the shader as "fragment.color".

I'm somewhat disappointed by the performance of current glDrawPixels implementations (on consumer boards) though, and I'd recommend looking into rectangle textures as a replacement. They seem to begenerally faster to render and also lend themselves well to asynchronous usage models. I.e. you'll reduce pipeline stalls as rendering can be separated from data pulling.

[wprice99]

That was my conclusion... that it should work. If anyone can get it to work, I'd be grateful to know how!

[zeckensack]

Originally posted by wprice99:
That was my conclusion... that it should work. If anyone can get it to work, I'd be grateful to know how!

I've only just now realized that I had this implemented for quite some time and it always worked.

!!ARBfp1.0
MOV result.color,fragment.color;
END

Radeon 9500Pro, starting from Catalyst 3.7 or so, and it still works with Cat 4.1.
However, I'm no longer using it because I switched to textures. That's how I found it

[wprice99]

From the code I have (which doesn't work), I have:

!!ARBfp1.0
PARAM u0 = program.local[0];
MUL result.color, u0, fragment.color.primary;
END

So each element of the glDrawPixels() should be multiplied by the constant program variable.

This doesn't seem to work with glDrawPixels(), but it does with a normal polygon. So, this appears to be a graphic-card dependant problem if it works with your Radeon 9500Pro.

[m2]

I'm somewhat disappointed by the performance of current glDrawPixels implementations (on consumer boards)

Actually it's very dependent on the driver version and on the format you use. Want to be sure which is faster? Benchmark at runtime.

[zeckensack]

Originally posted by m2:
Actually it's very dependent on the driver version and on the format you use. Want to be sure which is faster? Benchmark at runtime.

Ummm, I seriously believe I've used glDrawPixels in the optimum way. Currently, both NVIDIA and ATI offer quite acceptable if not very good througput figures for glDrawPixels(<...>,GL_RGBA,GL_UNSIGNED_BYTE);.

But that's not the point. Texturing gives me more consistent performance. Do not try to benchmark DrawPixels alone, mix it with some 'normal' geometry rendering and see what happens then. Asynchronous pull/draw is good.