Is it possible to use fragment shader during glCopyPixels? I was try everything but seems that shader are not executed at all.
Even more, if I write simple fragment shader like:
void main(void)
{
gl_FragCoord = vec4(1,0,0,0);
}
result is color of pixels but not red color, ie… shader are not executed!
btw… Im using FX5900 with drivers FW 66.81. My friend do the same test on 3dLabs Relizm and we got same results.
yooyo
Fragment programs/shaders are for writing to pixels, not reading from them. They cover all, and only, writing operations, not glReadPixels or glCopyPixels.
Something strange in this forum… My posts are dissapear immediatly after posting !?
According to this picture from ARB_fragment_shader spec (find Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization) in ARB_fragment_shader and take look at picture, it is possible to use fragment shaders for DrawPixels. But in my tests with glDrawPixels fragment shader are not executed.
Also… this is from OpenGL Shading Language 1.10.59, Page 79. Issues
- Should there be a separate programmable unit for doing the pixel transfer operations?
DISCUSSION:We originally had the concept of a separate pixel shader where the pixel and imaging
operations would be done. On further consideration it seemed very unlikely that anyone would
implement this as an independent functional unit but rather do them in the fragment shader behind the
scenes. OpenGL treats pixel and fragment operations as mutually exclusive so sharing one
processing unit is a natural implementation. Forcing an abstraction that differed from reality seemed
to be a hindrance apart from increasing the amount of work.
RESOLVED on October 12, 2001: No, the fragment processor will be used to process both geometry
and pixel data.
CLOSED on September 10, 2002.
yooyo
I assume you meant gl_FragColor instead of gl_FragCoord?
Nico
Originally posted by Korval:
Fragment programs/shaders are for writing to pixels, not reading from them. They cover all, and only, writing operations, not glReadPixels or glCopyPixels.
I think that glCopyPixels produces fragments (if is color data), so the fragment shader should be executed, but… after some tests, it seems that the fragment shader isn’t executed.
And another problem, if yooyo and me are right, how can access the incoming color data from in the fragment shader?
glDrawPixels is different from glCopy/ReadPixels. The drawing function clearly produces fragments, while the read function clearly does not. The draw function does because it is passing fragments to the framebuffer. glDrawPixels is succeptable to blend mode and other “fragment-level” operations.
The read function does not produce fragments because… well, what would that even mean? The blend mode is irrelevant to reading, and so it should be with the fragment mode.
The copy function could, theoretically, produce fragments, since it is moving pixel data from one section of card memory to another. However, since copying does not involve the blend mode, I would say that copying should happen without regard to the fragment mode as well.
Here’s a relevant take out from the NV_float_buffer spec.
What are the semantics for DrawPixels when using a floating-point color buffer? How about CopyPixels?
RESOLVED: DrawPixels generates fragments with the originally specified color values; components are not clamped to [0,1]. For fixed-point color buffers, DrawPixels will generate fragments with clamped color components.
CopyPixels is defined in the spec as a ReadPixels followed by a DrawPixels, and will operate similarly.
This mechanism allows applications to write floating-point data directly into a floating-point color buffer without any clamping.
Since DrawPixels and CopyPixels generate fragments and fragment programs are required to render to floating-point color buffers, a fragment program is still required to load a floating-point color buffer using DrawPixels.
Hope it helps,
Nico
Huh! Well, who is right? Korval or NiCo?
Or it’s a another confusion in ARB spec!?
Come on… can someone from ARB group confirm should be possible to use fragment shaders during CopyPixels call.
I think that CopyPixels generate fragments and fragment shaders should work. But there is a another question. How to access to incoming pixels color? There is no any sampler or texcoord. I suppose I should use gl_Color in fragment shader but Im not sure.
yooyo
Originally posted by Korval:
glDrawPixels is succeptable to blend mode and other “fragment-level” operations.
.
.
.
The copy function could, theoretically, produce fragments, since it is moving pixel data from one section of card memory to another. However, since copying does not involve the blend mode, I would say that copying should happen without regard to the fragment mode as well.
I am sure that glCopyPixels produces fragments and is affected by blending and other per-fragment operations (you can blend the framebuffer content with the copied pixels with glCopyPixels), and I tested with glReadPixels/glDrawPixels and the fragment shader is not applied too, so this left clear the fact that here are something wrong (maybe in the GLSL spec, maybe in the GLSL implementation…) It seems like ARB people forgot glCopyPixels/glDrawPixels/glBitmap in the GLSL spec (it has no mention to how to access the incoming color copied from in the fragment shader)
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.