On Wed, 2012-08-22 at 11:16 -0700, Anuj Phogat wrote: > On Wed, Aug 22, 2012 at 12:48 AM, Vadim Girlin <[email protected]> wrote: > > Hi, > > > > It seems there is a problem with alpha-to-coverage-dual-src-blend test. > > > > AFAICS the test uses DrawPixels with dual source blending and > > fixed-function fragment pipeline. According to GL and > > ARB_blend_func_extended specs: > > > > "Rendering using any of the blend functions that consume the second > > input color (SRC1_COLOR, ONE_MINUS_SRC1_COLOR, SRC1_ALPHA or > > ONE_MINUS_SRC1_ALPHA) using fixed function will produce undefined > > results." > > > > So it looks like the test relies on the undefined behaviour. Here is the > > part of the stack for that DrawPixels call: > > > > 12 visualize_image() common.cpp:1775 > > 11 draw_image_to_window_system_fb() draw-buffers-common.cpp:704 > > 10 draw_reference_image() draw-buffers-common.cpp:823 > > 9 piglit_display() alpha-to-coverage-dual-src-blend.cpp:104 > > > > Probably blending should be temporarily disabled in that case. > Yes. Blending can be temporarily disabled in visualize_image function. > I'll send out a small patch to fix this. Patch won't make any difference > to the test output. Test is already passing on AMD, Intel and NVIDIA drivers. > Thanks for noticing this.
In fact there was some difference on AMD hardware with r600g, that's how I noticed it :) . It required special handling to convert one kind of "undefined results" (GPU lockup leading to system reboot) to another by reproducing the behaviour of other drivers for compatibility: http://cgit.freedesktop.org/mesa/mesa/commit/?id=8d1a9a984f33d8e45f932a9f47cdd57da617a919 But some driver could simply ignore invalid draw call, and I think the test without a fix would then result in false "FAIL". Thanks for fixing this. Vadim _______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
