On 13.07.2011 12:29, Christian König wrote:
> 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.
>From ARB_color_buffer_float:

3. How does the clamping control affect the blending equation?

       RESOLVED:  For fixed-point color buffers, the inputs and the
       result of the blending equation are clamped.  For floating-point
       color buffers, no clamping occurs.

So you want to clamp the colour only before blending but NOT after ?

I suggest you just deactivate automatic clamping and perform it at the
end of the shader instead.
Unless you also need the input of the blend equation to be clamped ...
> 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. 
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to