Hi Henri and everybody else on the list,
Am Dienstag, den 12.07.2011, 19:01 +0200 schrieb Henri Verbeet:
> I guess my point was mostly that there's not much of a point in doing
> the clamping both through BLEND_CLAMP and the fragment shader. Also, I
> guess we need this for EG+ as well.
Oh, I got quite a problem here: After your mail I created patches to
push the changes to r600g separately into master. While doing so I also
checked that there are no piglit regressions, unfortunately the
"arb_color_buffer_float" test is now failing.
After reading "ARB_color_buffer_float" extension (again) and checking
that against the r600 documentation, I realized that the behavior of the
BLEND_CLAMP bit on r600 hardware has nothing todo with clamping the
fragment color.
As the name of this (well documented) hardware flag already implies: It
just disabled clamping the output of the fragment shader BEFORE blending
to a normalized buffer.
My problem now is that I can't find any OpenGL extension that controls
such a behavior, and also Direct 3D doesn't seems to have such a flag.
So what I got now is a hardware feature that makes perfectly sense for
video decoding, but doesn't seems to have an equivalent in the 3D world.
The situation is very similarly to the "interlaced" textures feature, it
doesn't makes sense for a 3D app to use such a feature, so mesa doesn't
have an interface for it, but it would be really (REALLY) useful if you
want to decode video streams.
So any ideas guys? Should I just add an additional flag to the blender
and hope that the other hardware vendors do it in the same way? Or do I
need to find a workaround to do this without this feature?
Or maybe anybody know a OpenGL extension that's currently not
implemented and does exactly what BLEND_CLAMP does?
Regards,
Christian.