System Environment: -------------------------- --Platform: Q965 --Architecture(32-bit,64-bit,compatiblity): 32-bit --2D driver: xf86-video-intel-2.5-branch 8408995ffbf705aa0bc09ab72c58c2e31a4b70c3 --3D driver: intel-2008-q3 branch e636f5b76bbcfef95092d21646c844c0dfe770e0 --DRM:shipped with kernel 2.6.27-rc5 --libdrm: master 2db8e0c8ef8c7a66460fceda129533b364f6418c --Xserver: 1.5.1 --Kernel: 2.6.27-rc5 Bug detailed description: -------------------------- with mesa intel-2008-q3 branch, glean get 11 more failures than mesa_7_2: fragProg1 maskedClear orthoPosTinyQuads orthoPosVLines orthoPosPoints paths pixelFormats pointSprite readPixSanity texRect vertProg1 Reproduce steps: ---------------- 1.xinit& 2../glean -r log
Created attachment 19224 [details] xorg conf
texCube is also affected.
Created attachment 19425 [details] patch to fix write_domain and static BOs issue. Hi, Eric When I investigate glean/texCube issue(bug#17705), I notice fake_bufmgr allocates backing store for a non-static BOs, and it copies data from backing store into card memory when invalidating a BO. Sometimes the contents in the card memory allocated for a BO is changed by some operations such as BLT, (for example, use BLT to copy teximage's contents at its level into a mimmap tree). However the backing store isn't updated at the same time, so that the fake_bufmgr will copy stale data from backing store into card memory if this BO is marked as 'dirty' again (for examle: bo_map with writing enabled). It seems some 3D games such as torcs, ut2004 also are impacted by this issue (but #17182). The drm commit 073cb5ee1d12a7f1a18b7d732f346c16eb740f49 tries to fix this issue. However the bo_fake->write_domain is always set to 0 currently, so this issue still exists. Another problem is that currently fences aren't applied to all static BOs. Hence sometimes ReadPixels with a back/front buffer gets stale data. The attached patch tries to fix write_domain and static BO issue, please take a look. With this patch, these glean cases except vertProg1 (it triggers a assertion failure which should be a mesa bug) all pass, and torcs and ut2004 also works fine for me. Thanks Haihao
fixed in drm 604759d4a78efcef0abdb40bfc215526cdcf1122 and vertProg1 passes too.
verified against drm 1150a42d4398b14c5db2f34a5beba613528df147
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.