Created attachment 30313 [details] xorg.0.log System Environment: -------------------------- Arch: x86_64 Platform: G45 Libdrm: (master)a107e5b12960f64722bff424502a4fc0ad33dc8f Mesa: (master)150d4968e31e4600f9479c53f83d810b92b59cf7 Xserver: (master)1088073b11ed488c0df45af3867b900ef93c6fe1 Xf86_video_intel: (master)1556c62e0336ea2fef866722ee44d2d188e318f3 Kernel: (drm-intel-next)8d91104aac6e21e6ca2a56124e2e47b0db043ea8 Bug detailed description: ------------------------- piglit/texturing/tfp failed on G45 64bit and it passed on 32 bit platforms. The error output is: Probe at (176,48) Expected: 1.000000 0.000000 0.000000 Observed: 0.000000 0.000000 0.000000 Probe at (208,48) Expected: 0.500000 0.000000 0.000000 Observed: 0.000000 0.000000 0.000000 Probe at (176,80) Expected: 0.000000 1.000000 0.000000 Observed: 0.000000 0.000000 0.000000 Probe at (208,80) Expected: 0.000000 0.500000 0.000000 Observed: 0.000000 0.000000 0.000000 Reproduce steps: ---------------- 1. xinit& 2. run the case.
bisect?
(In reply to comment #1) > bisect? I find it even failed with our Q2 and Q1 release code.
This is a bug in the testcase in computing the color to fill the pixmap with. The correct solution is to fix the testcase to use Render to set up the pixmap.
commit 32e43775fd786b9b05f545a802f5ac5ff9a6cd90 Author: Eric Anholt <eric@anholt.net> Date: Wed Jun 1 00:20:04 2011 -0700 glx-tfp: Use XRender to correctly set up alpha channel. The previous way of initializing the "alpha" channel of the pixmap was to just set the pixel bits other than r, g, b, to 1.0 or 0.5 times their maximum value. However, thanks to the delights of xlib, a pixel value is a long, not a sized integer. So, when we set alpha to half of ~(r, g, b,), on 64-bit that was half of 0xffffffffff000000 instead of half of 0xff000000, which resulted in black. XRender is the correct X rendering API for working with alpha channels, so use that instead. The ugly bit here is that to preserve the existing test behavior, we have one of the colors filled be (1.0, 0.0, 0.0, 0.5), which is non-premultiplied and thus not really proper Render rendering. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=24491
(In reply to comment #4) > commit 32e43775fd786b9b05f545a802f5ac5ff9a6cd90 > Author: Eric Anholt <eric@anholt.net> > Date: Wed Jun 1 00:20:04 2011 -0700 > glx-tfp: Use XRender to correctly set up alpha channel. > The previous way of initializing the "alpha" channel of the pixmap was > to just set the pixel bits other than r, g, b, to 1.0 or 0.5 times > their maximum value. However, thanks to the delights of xlib, a pixel > value is a long, not a sized integer. So, when we set alpha to half > of ~(r, g, b,), on 64-bit that was half of 0xffffffffff000000 instead > of half of 0xff000000, which resulted in black. > XRender is the correct X rendering API for working with alpha > channels, so use that instead. The ugly bit here is that to preserve > the existing test behavior, we have one of the colors filled be (1.0, > 0.0, 0.0, 0.5), which is non-premultiplied and thus not really proper > Render rendering. > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=24491 Yes. It now passed. So verified. test with: Libdrm: (master)2.4.26-2-gce317a6d09bb93cff73703b06e5a5bc3cc0b1c6a Mesa: (master)0aed27ee37860ba332df776425d89d97ca1168b2 Xserver: (master)xorg-server-1.10.99.901-115-g73864a87aacbce85b520ccaa6e360b82c0e99716 Xf86_video_intel: (master)2.15.0-206-g1b9e82b4b59dd50c1b057f58d71d5c04dcc648a7 Cairo: (master)1b888c4c3a3f7002dc092fd48088cd0b5031e12c Libva: (master)cdcb15eeaf9cd6687cc40c75a9f91f40ceff898c Kernel: (drm-intel-next) cf96e46fcd147856fd8151fab91c410f0ec16c47
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.