Bug 19016

Created attachment 21038 [details]
xorg conf file

GEM_kernel:       (for-airlied)6c76409370d7ee18208a7adfa5f8dabf8a42a274

Eric, please take this as high priority. It impacts QA's testing as we set timeout for 20mins. For now, we are temporarily disabling the case.

Some additional information is going to be required.  I also run this test, and it takes less than 1 minute.  I'm running for-airlied kernel and master of all other trees.  spop.c has completed in less than 20 minutes on my system since at least WW42.  My weekly test results e-mail contains commit IDs as far back as WW43.

This week's bits are:

Mesa:             759000ff4fd1716edee4734a023ffcb61b443764
xf86-video-intel: 80e2d90139dd99f50beb4f9353599608624b777d
libdrm:           9583c099b4a08b49e03f7b461c344b6d277fd262
xserver:          119d9c46e841f5fa35610f557e6fa1ec58587c24
kernel:           8b1fae4e4200388b64dd88065639413cb3f1051c

I'm running a 64-bit kernel, and my X.org log says:

(--) PCI:*(0@0:2:0) Intel Corporation 82G965 Integrated Graphics Controller rev 2, Mem @ 0xd0200000/1048576, 0xc0000000/268435456, I/O @ 0x00002140/8

Also, a bug that affects an oglconform testcase completion (not even locking up the hardware!) doesn't seem appropriate to be high priority, compared to numerous other bugs we have reported that relate to hanging the chip with user code.

Ian, thanks for sharing your result. So the difference is you are using driver master branch while Haien is using release branch. Haien, please try master also.

Eric, I admit it's wrong to set high priority. Thanks for pointing this out.

(In reply to comment #6)
> Ian, thanks for sharing your result. So the difference is you are using driver
> master branch while Haien is using release branch. Haien, please try master
> also.
> 
> Eric, I admit it's wrong to set high priority. Thanks for pointing this out.
> 

same issues exits with master on our 965, we tried it with below commits:
Libdrm: master c86d431fe6174b1c2de531929213ea7dbd92326d
Mesa:master 1126aa86bf9ca223218695eec1f41c6523068961
xserver:master f1c9b5ab230cbb4124d8d476ae4886d05022adcb
Xf86-video-intel :master ea2b6b405e4c8b1bfb4bc568d0453a39a9194a8f

(In reply to comment #4)
> Some additional information is going to be required.  I also run this test, and
> it takes less than 1 minute.  I'm running for-airlied kernel and master of all
> other trees.  spop.c has completed in less than 20 minutes on my system since
> at least WW42.  My weekly test results e-mail contains commit IDs as far back
> as WW43.
> 
> This week's bits are:
> 
> Mesa:             759000ff4fd1716edee4734a023ffcb61b443764
> xf86-video-intel: 80e2d90139dd99f50beb4f9353599608624b777d
> libdrm:           9583c099b4a08b49e03f7b461c344b6d277fd262
> xserver:          119d9c46e841f5fa35610f557e6fa1ec58587c24
> kernel:           8b1fae4e4200388b64dd88065639413cb3f1051c

Small update.  Moving from WW49 (kernel 66647dc60d16fae9f6963fd98b6d9baa1a8dac69) to WW50 (kernel 8b1fae4e4200388b64dd88065639413cb3f1051c) I am now able to reproduce this bug.  When I posted the above my system was still set to boot from the older kernel. :(

With the two-way kernel merging (from the various DRM trees to Linus and back), the older SHA1 no longer exists.  I believe this corresponded to the commit "drm/i915: Disable the GM965 MSI errata workaround."  Instead of having all the patches from DRM grouped and all the upstream kernel changes grouped, this particular change is in the middle of a sea of non-DRM changes.  I have the feeling this is going to be git-bisect hell.

(In reply to comment #8)

> Small update.  Moving from WW49 (kernel
> 66647dc60d16fae9f6963fd98b6d9baa1a8dac69) to WW50 (kernel
> 8b1fae4e4200388b64dd88065639413cb3f1051c) I am now able to reproduce this bug.

I hit commit too soon.  My test times have gone from <1 minute to ~15 minutes on this test.

I probably shouldn't post bug updates late on Sunday night. :P

Did another review of my changes for glBitmap metaops, and found the two bugs I was looking for.  Changes pushed -- spop.c now completes in a couple minutes for me (with DRI2, which punishes us for calling glViewport so much).

commit e1a92175542c6645c23cc78f2a4fcd36dd0235e6
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Dec 31 00:02:43 2008 -0800

    intel: Add support for glBitmap as metaops using GL calls.
    
    This lets us avoid software fallbacks when clients forget to turn some state
    off (engine demo) or just do crazy things to test conformance (OGLC).
    
    This should probably be brought into mesa generic code so other drivers can
    make use of it.
    
    Bug #19016.

(In reply to comment #10)
> Did another review of my changes for glBitmap metaops, and found the two bugs I
> was looking for.  Changes pushed -- spop.c now completes in a couple minutes
> for me (with DRI2, which punishes us for calling glViewport so much).
> 
> commit e1a92175542c6645c23cc78f2a4fcd36dd0235e6
> Author: Eric Anholt <eric@anholt.net>
> Date:   Wed Dec 31 00:02:43 2008 -0800
> 
>     intel: Add support for glBitmap as metaops using GL calls.
> 
>     This lets us avoid software fallbacks when clients forget to turn some
> state
>     off (engine demo) or just do crazy things to test conformance (OGLC).
> 
>     This should probably be brought into mesa generic code so other drivers can
>     make use of it.
> 
>     Bug #19016.
> 

thanks,it works for me against master branch, we won't verify this bug util this commit is cherry-picked to intel-2008-q4 branch.

verified against:
Libdrm:		(master)badc63464cbd64606c6dff9ea561a787d072fd5f
Mesa:		(intel-2008-q4)eef0dcc298f65158dc750a09f80317ded1101dc7
Xorg:		7.2
Xserver:	(server-1.6-branch)1ffd9ec7606606570980490b91b780e02bc29d7d
Xf86_video_intel:		(xf86-video-intel-2.6-branch)
                            4447973345a2a7af20ba1d6cb18c5f1ed8949d00
GEM_kernel:       (drm-intel-2.6.28)e1a6fcee467556a7e955fe1f7ccc134dd2f974e7

  spop.c run slow(more then 20 minutes) recently,I try to bisect and find below commit cause this regression:

72ee0e247d799c85612c72bbd2257648e11fa583 is first bad commit
commit 72ee0e247d799c85612c72bbd2257648e11fa583
Author: Brian Paul <brianp@vmware.com>
Date:   Mon Jan 26 14:22:30 2009 -0700

    intel: check if stencil test is enabled in intel_stencil_drawpixels()

:040000 040000 6da523034e04d6b3599138a817e9734e63b75a10 b33df7a1e4812d5854ad48753dd4daa5cd8efe46 M      src

A conformance test doing stupid things and being slow is *certainly* not a release blocker.

Eric,
If you think it's a case issue, please explain offline to us. We need fix the case.
Otherwise I assume it indicates a driver performance regression, which certainly possible to impact the release. I didn't mark it as high priority major bug to be a true release blocker.
btw, I thought contributing a bisect result will get it as high priority for the bug owner. With time going farther, I'm afraid the bisect result will be less useful.

(In reply to comment #15)
> Eric,
> If you think it's a case issue, please explain offline to us. We need fix the
> case.
> Otherwise I assume it indicates a driver performance regression, which
> certainly possible to impact the release. I didn't mark it as high priority
> major bug to be a true release blocker.
> btw, I thought contributing a bisect result will get it as high priority for
> the bug owner. With time going farther, I'm afraid the bisect result will be
> less useful.


The particular case is one of the "upstream" conformance tests, so we can't change it.  Previously we had a work around in the driver to ignore stencil test in the glBitmap case.  However, this is not correct.  Fixing the correctness regressed the performance.  The only way to fix it is to write new glBitmap acceleration code.  Real applications should not do this, so that makes this a very low priority issue.

(In reply to comment #16)
> The particular case is one of the "upstream" conformance tests, so we can't
> change it.  Previously we had a work around in the driver to ignore stencil
> test in the glBitmap case.  However, this is not correct.  Fixing the
> correctness regressed the performance.  The only way to fix it is to write new
> glBitmap acceleration code.  Real applications should not do this, so that
> makes this a very low priority issue.

Thanks for the explanation. Sounds reasonable to be low priority.

Is this still a problem?  On my i965 system this test only requires ~2 minutes using Mesa master.

(In reply to comment #18)
> Is this still a problem?  On my i965 system this test only requires ~2 minutes
> using Mesa master.
> 

Yes, this case now run only for 2 minutes on G45, I'd try to enable this case in our nightly testing to see if it's really gone.

This bug is gone

verified on 945GM and G45 with:
Kernel 	(drm-intel-next)a83a4400415893d2599a256f6842ac4d871dffd7
Libdrm 	(master)0d7ad7e43ca212b1e9f16cd18f36493cab455e61
Mesa 	(master)59b29516af2d4d8f83723559921a3709eb77a7d2
Xserver 	(master)fab74d1081270fb8f1d231e6e10d10aa33e164da
Xf86_video_intel 	(master)10946118dd3a63f1375a1bfde0b2f0542a93c1c2