Created attachment 67959 [details] mesa: git bisect I discovered this bug while running Dante (https://github.com/omcfadde/dante) on i965 Sandybridge. I have attached the `git bisect' log, along with two screenshots. The first screenshot shows Mesa unmodified. The second screenshot shows Mesa with the Guard Band test commit reverted. The following is my analysis of the performance impact of reverting the commit on Sandybridge. > Dante: +timedemo 1 - with Mesa commit 85cd30406ff8414bc6ac6de1064d059a4c564160 (bad) > MessageBox: Time Demo Results - 2148 frames rendered in 46.2 seconds = 46.5 fps > > Dante: +timedemo 1 - without Mesa commit (good) > MessageBox: Time Demo Results - 2148 frames rendered in 46.5 seconds = 46.2 fps This bug is possibly present on Ivybridge, however I do not have hardware available to verify this suspicion. Because this is a major rendering regression, causing polygons to either partially or completely disappear from the scene, I would propose the following commits are reverted from master branch and all stable/release branches: > 610910a66d1a97ca51ad8a003bdeadfe9563d721 i965: Implement guardband clipping on Ivybridge. > 85cd30406ff8414bc6ac6de1064d059a4c564160 i965: Implement guardband clipping on Sandybridge.
Created attachment 67960 [details] Screenshot 1 (bad)
Created attachment 67961 [details] Screenshot 2 (good)
Created attachment 67962 [details] Screenshot 1 JPG (bad)
Created attachment 67963 [details] Screenshot 2 JPG (good)
Unfortunately it appears that Bugzilla has somehow corrupted the image data in both PNG and JPG formats, which in itself is an infrastructure bug. Upon request I will send the images as a reply to the automated mails from Bugzilla (on the mailing list.)
Created attachment 67990 [details] Bad screenshot
Created attachment 67991 [details] Good screenshot
(In reply to comment #5) > Unfortunately it appears that Bugzilla has somehow corrupted the image data > in both PNG and JPG formats, which in itself is an infrastructure bug. Upon > request I will send the images as a reply to the automated mails from > Bugzilla (on the mailing list.) Bugzilla image upload was fixed, and I've uploaded the images again.
Oliver, How can I reproduce this? I don't own Doom 3. Could you perhaps take an apitrace of Dante? Also, could you try adjusting this line in gen6_viewport_state.c? const float maximum_post_clamp_delta = 16384; Try changing it to, say, 8000, and see if that solves your problem. I may have been too aggressive...maybe even forgotten to divide by 2 when computing the maximums. --Ken
(In reply to comment #9) > Oliver, > > How can I reproduce this? I don't own Doom 3. Could you perhaps take an > apitrace of Dante? > > Also, could you try adjusting this line in gen6_viewport_state.c? > > const float maximum_post_clamp_delta = 16384; > > Try changing it to, say, 8000, and see if that solves your problem. I may > have been too aggressive...maybe even forgotten to divide by 2 when > computing the maximums. Reducing to 8000 helps but not significantly; there are still major rendering errors. I have uploaded APItrace files for Dante running with vanilla Mesa (Mesa 9.1-devel (git-336cc64)) and with your suggested modification of 'const float maximum_post_clamp_delta = 8000;' The uncompressed APItrace files are quite large, each trace is approximately 500 MB uncompressed and 190 MB when compressed with bzip2 using best compression. You will need to bunzip2 the files before they are useful for the APItrace tools: http://people.freedesktop.org/~omcfadde/
Oliver, it looks like this is a hardware bug. If you'd like, you could build intel-gpu-tools from git://anongit.freedesktop.org/xorg/app/intel-gpu-tools and try: sudo intel_reg_write 0x2090 0xffff0020 This should change the value of the register from 0 to 0x20...which should enable a workaround for the bug. That fixes the rendering in your trace.
Oh yeah, I should mention: guardband clipping appears to work just fine on IVB. I can only reproduce this on Sandybridge.
*** This bug has been marked as a duplicate of bug 53946 ***
(In reply to comment #12) > Oh yeah, I should mention: guardband clipping appears to work just fine on > IVB. I can only reproduce this on Sandybridge. Should I then pick the IvyBridge guardband commit back onto the 9.0 stable branch? I'm a bit hesitant because of your workaround for SandyBridge on the kernel side, although that should be fine considering it's in a gen6_* function.
Enabling it on Ivybridge seems okay to me - as far as I can tell, no one ever actually observed a problem with guardband clipping on Ivybridge. And Dante worked fine for me. We were just being cautious with the revert. This was roughly 4% on Citybench, so it'd be nice to reclaim that...but then again, I'm not sure how important Citybench is these days. I hadn't observed much of a speedup on other workloads (but then again I haven't measured it on our newer ones). It's just performance, but then again, it was on master for ages and even 9.0 until recently and no one observed a problem. Ian, do you have an opinion?
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.