Created attachment 17172 [details] shadowtex_image System Environment: -------------------------- Host: 945 Arch: i386 Kernel: 2.6.26-rc5 Libdrm_gem:drm-gem branch 3e48e144992fb11b31875989d45bc8a7c041cdef Mesa_gem: drm-gem branch 407ce3da3c53c9ebba0fbf827d7b0f610122d44b Xserver: master 8c9234a163eceda2abc0a2523e0f5587ea399935 Xf86_video_intel_gem:drm-gem branch d775ddc64dc8349b8ef9e85b0be9e93cb1997fea Bug detailed description: -------------------------- start X,then run 'shadowtex' with GEM ,it displays nothing but a black window as is shown in the attached image. Reproduce steps: ---------------- 1.xinit& 2../shadowtex
Created attachment 17173 [details] Xorg.0.log
Created attachment 17175 [details] xorg conf file
Also seen on my system. Unclear what's going on.
with the latest commit, this bug still exists.
Created attachment 17751 [details] Image of shadowtex on 965G I get different incorrect results on my 965G system. When run in fixed function mode, shadowtex just modulates the surface color with the shadow depth value. It effectively uses the depth image as a GL_LUMINANCE texture. In fragment program mode correct results are produced. This is with bits recent as of last night on a x86_64 build.
it still exists with the latest GEM.
We've just tried the latest drm-gem for all components except drm module and kernel from anholt's linux-2.6 tree drm-gem-merge branch.this issue still exists.
this issue still exists in the latest commit of master.
this issue still exists in the latest commit.
this issue still exists with the latest master and drm-intel-next kernel.
still exists against below: xf86_video_intel xf86-video-intel-2.6-branch commit b156b3165e1aae5df0353737d0335ac2e653f5fd mesa intel-2008-q4 branch commit 154a9e5317f890618932cea0129ef887e16baf84 kernel for-airlied branch commit 66647dc60d16fae9f6963fd98b6d9baa1a8dac69 libdrm master branch commit b0d93c74d884b40bd94469a5ef75fdb2fef17680 xserver 1.6
(In reply to comment #11) > still exists against below: > xf86_video_intel xf86-video-intel-2.6-branch > commit b156b3165e1aae5df0353737d0335ac2e653f5fd > > mesa intel-2008-q4 branch > commit 154a9e5317f890618932cea0129ef887e16baf84 > > kernel for-airlied branch > commit 66647dc60d16fae9f6963fd98b6d9baa1a8dac69 > > libdrm master branch > commit b0d93c74d884b40bd94469a5ef75fdb2fef17680 > > xserver 1.6 > GEM kernel (for-airlied)6c76409370d7ee18208a7adfa5f8dabf8a42a274
(In reply to comment #11) > still exists against below: > xf86_video_intel xf86-video-intel-2.6-branch > commit b156b3165e1aae5df0353737d0335ac2e653f5fd > > mesa intel-2008-q4 branch > commit 154a9e5317f890618932cea0129ef887e16baf84 > > kernel for-airlied branch > commit 66647dc60d16fae9f6963fd98b6d9baa1a8dac69 > > libdrm master branch > commit b0d93c74d884b40bd94469a5ef75fdb2fef17680 > > xserver 1.6 > GEM kernel (for-airalied)6c76409370d7ee18208a7adfa5f8dabf8a42a274
This has been going on since the previous release (basically, since FBO support landed), and I don't think it's release-blocker quality.
(In reply to comment #14) > This has been going on since the previous release (basically, since FBO support > landed), and I don't think it's release-blocker quality. > still exists with below commits: Libdrm: (master)4a0d19ef4f210cea9e60c5acc355df03723ef808 Mesa: (mesa_7_4_branch)e2092bb23c956ba9ab940935f803ef843db81af2 Xserver: (server-1.6-branch)4557b3f6c4273cd83b701beaf7a150c806fed298 Xf86_video_intel: (master)81c652e9a666a7459bcc5217c8a5ec518b6e00da GEM_kernel: (for-airlied)99d31f896d243c13bb90b56620d33b416a5cffa7
verified against: Libdrm: (master)2e2e8575b1ed4703653a72ac2b60b75316c388d7 Mesa_stable: (mesa_7_4_branch)a8528a2e8653b5237c1d1d66fe98c6e031d007f9 Xserver:(server-1.6-branch) 60c161545af80eb78eb790a05bde79409dfdf16e Xf86_video_intel: (2.7)238c2c40afd9f8b61479b8640d53f20d52fd7ddf Kernel: (for-airlied)dc529a4fe1ae4667c819437a94185e8581e1e680
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.