attament is the snapshot of drawpix.

Created attachment 17089 [details]
Xorg.0.log

Created attachment 17090 [details]
xorg conf file

The specs are wrong about the tile format on 965.  Fix pushed.

run drawpix using the latest commit of mesa as you said,but the issue still exists.
-----------------------------------
3D driver: drm-gem branch       64adeb163d7da6d75b5664cd2ee3783cadaf63d8

Created attachment 17206 [details]
tiling test app

Even if this fix didn't work on your hardware, it should have significantly changed the output.  Could you attach a screenshot produced using the gimp or imagemagick's import or whatever tool, instead of a photograph (where it's hard to discern the patterns of what's happening).

If my change did actually change the output but didn't fix the problem, please revert my change and try running the attached program with no_rast=true set in the environment, and attach a screenshot of the results.

Created attachment 17208 [details]
untile.png

your change changed the output but didn't fix the problem, I try to revert your change and run your attached "untile" with no_rast=true.untile.png,which is attached, is the snapshot of the result.

Created attachment 17209 [details]
after_change_image

attachment is the snapshot of "drawpix" after using your change,wish it can help you.

This is a hard issue -- we've now seen 3-4 different formats for the tiling layout, despite the docs only describing one.  We're working on getting the needed documentation on how to determine the layout before giving up and implementing a workaround.

*** Bug 16324 has been marked as a duplicate of this bug. ***

*** Bug 16371 has been marked as a duplicate of this bug. ***

I've added a workaround option to let us continue testing until we get a response on how to properly detect the tile swizzling.  There are now 3 tile swizzling modes in driconf, with no extra swizzling (0) being the default.  I have systems for both modes 1 and mode 2.  For this system, please set mode 1 (bit 6 ^ bit 9 ^ bit 10).  I'm still at a loss as to where those other two misplaced pixels are coming from.

To debug tile swizzling issues with software fallbacks:

1) Run drawpix with mode 0.  If it draws incorrectly, try swizzle modes 1 and 2.  If no mode works, post bug with untile output with mode 0 set.  Otherwise, leave that mode set for further testing.
2) Run the reflect demo.  Press 'd' to get the output of the depthbuffer.  If it looks scrambled (4x4 blocks swapped, things like that), set swizzle mode to 0 and post screenshot.

(In reply to comment #12)
> I've added a workaround option to let us continue testing until we get a
> response on how to properly detect the tile swizzling.  There are now 3 tile
> swizzling modes in driconf, with no extra swizzling (0) being the default.  I
> have systems for both modes 1 and mode 2.  For this system, please set mode 1
> (bit 6 ^ bit 9 ^ bit 10).  I'm still at a loss as to where those other two
> misplaced pixels are coming from.
> 
> To debug tile swizzling issues with software fallbacks:
> 
> 1) Run drawpix with mode 0.  If it draws incorrectly, try swizzle modes 1 and
> 2.  If no mode works, post bug with untile output with mode 0 set.  Otherwise,
> leave that mode set for further testing.
> 2) Run the reflect demo.  Press 'd' to get the output of the depthbuffer.  If
> it looks scrambled (4x4 blocks swapped, things like that), set swizzle mode to
> 0 and post screenshot.
> 


for  1) change to use swizzle_mode 1 make drawpix work well.
then 2) reflect's depthbuffer works well in swizzle_mode 1

This needs to be retested with the current code.  swizzle_mode no longer has an effect and it should be automatic.

(In reply to comment #14)
> This needs to be retested with the current code.  swizzle_mode no longer has an
> effect and it should be automatic.
> 

we've repull all components, but failed to build.
for drm/linux-core pci_read_base is used, but we only found pci_read_bases is defined in kernel. is it just a typo or a newly defined functoin?
for mesa, intel_region:tiled is changed into intel_region:tiling, but intel_region:tiled is still used in src/mesa/drivers/dri/i915/intel_pixel_read.c

Ooops, we tested this one on wrong drm module.
after change pci_read_base into pci_read_bases, the module can be loaded, but it will report 
[drm:i915_gem_detect_bit_6_swizzle] *ERROR* Couldn't map MCHBAR to determine tile swizzling

Could you tell us how to correctly build the drm module?

You've correctly built it as far as I know.  That error means "the hardware didn't do what we expected, so we disabled tiling".  I assume the demo works correctly, then?

(In reply to comment #17)
> You've correctly built it as far as I know.  That error means "the hardware
> didn't do what we expected, so we disabled tiling".  I assume the demo works
> correctly, then?
> 

We have apply the patch adding pci_read_base() to our kernel.
This demo still can't render correctly.
And just for your information, if we following modification can make drawpix and gearbox work well on our Q965:
 i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
 {
@@ -93,6 +94,10 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
        int mchbar_offset;
        volatile char *mchbar;
        int ret;
+       dev_priv->mm.bit_6_swizzle_x = swizzle_x;
+       dev_priv->mm.bit_6_swizzle_y = swizzle_y;
+       return;
+

That just disables tiling, which will be correct but slower.

What's the value of CHDECMISC that's being read out?  What's the memory configuration on your system?

(In reply to comment #19)
> That just disables tiling, which will be correct but slower.
> 
> What's the value of CHDECMISC that's being read out?  What's the memory
> configuration on your system?
> 

CHDECMISC = 0x000000ff
It have 1Gx2 memory. 

OK, that's the "your bridge isn't decoding the access" value.  You should see this line in dmesg:

[drm:i915_gem_detect_bit_6_swizzle] *ERROR* Couldn't map MCHBAR to determine
tile swizzling

You should see tiling getting disabled as a result

(II) intel(0): 0x01000000-0x01ffffff: depth buffer (16384 kB)
(II) intel(0): 0x02000000-0x02ffffff: back buffer (16384 kB)
(II) intel(0): 0x03000000-0x03ffffff: front buffer (16384 kB)
(none of them say X or Y tiled)

And the demos should work.  Is this not what's happening?

*** Bug 16324 has been marked as a duplicate of this bug. ***

*** Bug 16371 has been marked as a duplicate of this bug. ***

If you have commit 78f1fc9cbcb383d42d903a8b9febdcf3c438ea7c this should be fixed.  Is it?

mark as fixed and wait for QA to verify.

verified.

We've just tried drm-gem for all components except drm module and kernel
from anholt's linux-2.6 tree drm-gem-merge branch. This issue happens again. In dmesg we see:
[drm:i915_gem_detect_bit_6_swizzle] *ERROR* pci_read_base failed: -6

pci_read_base is entirely gone now and should no longer cause problems.

(In reply to comment #28)
> pci_read_base is entirely gone now and should no longer cause problems.
> 

yeah, it's working now with new codes.