|Summary:||[G965, G45, ILK] GL_POLYGON in GL_POINTS mode fails (glean pointSprite)|
|Component:||Drivers/DRI/i965||Assignee:||Intel 3D Bugs Mailing List <intel-3d-bugs>|
|Status:||RESOLVED MOVED||QA Contact:||Intel 3D Bugs Mailing List <intel-3d-bugs>|
|Priority:||low||CC:||christophe.prigent, imamdxl8805, rhyskidd|
|i915 platform:||i915 features:|
Description fangxun 2009-11-05 02:13:54 UTC
Created attachment 30976 [details] Xorg log System Environment: -------------------------- Arch x86_64 Platform 965GM Libdrm: (master)b0b96636dbf93445dd532b09b21fa4fc5ce6bdc7 Mesa: (master)644d8fd363ca7d8f40f4fa319919985cc002df9e Xserver: (master)412c56ef3332d09efbd861e41c3e985f44729729 Xf86_video_intel: (master)10946118dd3a63f1375a1bfde0b2f054 Kernel: (drm-intel-next)a83a4400415893d2599a256f6842ac4d871dffd7 Bug detailed description: ------------------------- Glean case pointsprite.c fails on 965GM, which used to fail. Reproduce steps: ---------------- 1.xinit& 2.run glean/pointsprite.c
Comment 1 Eric Anholt 2009-11-05 16:25:49 UTC
Do you mean "used to pass"? If so, bisect.
Comment 2 zhao jian 2009-11-12 01:09:45 UTC
We find the culprit commit is commit 5340b6dff73a0a23531ce2a5f28fba8303adab6e. Maybe its makefile has some problem then, the i965_dri.so is always not built, which makes it run with software raster. This complexed our bisecting. Finally we will build the dri in its directory seperately, and find the culprit commit is a merge commit, and its parents commit works well. commit 5340b6dff73a0a23531ce2a5f28fba8303adab6e Merge: 9fd26da ee4c921 Author: Brian Paul <email@example.com> Date: Tue Feb 10 16:44:02 2009 -0700 Merge commit 'origin/gallium-master-merge' This is the big merge of the gallium-0.2 branch into master. gallium-master-merge was just the staging area for it. Both gallium-0.2 and gallium-master-merge are considered closed now. Conflicts: progs/demos/Makefile src/mesa/main/state.c src/mesa/main/texenvprogram.c
Comment 3 Eric Anholt 2010-07-22 10:47:38 UTC
Note: the failure is only in the GL_POLYGON mode.
Comment 4 Ian Romanick 2011-07-29 13:21:35 UTC
*** Bug 39669 has been marked as a duplicate of this bug. ***
Comment 5 Eric Anholt 2013-02-20 22:34:22 UTC
I've looked at this a bit more: the gen4 SF code doesn't do point handling for unfilled polygons.
Comment 6 Rhys Kidd 2015-07-12 08:40:45 UTC
Hello Eric, Would you mind provide me a few pointers on the code section to look at, which you identified as problematic on gen4? I've presumed this would be one of the following based on your comment: - brw_sf.c - brw_sf_emit.c - brw_sf_state.c
Comment 7 Matt Turner 2015-07-12 19:01:19 UTC
I'm not familiar with the code, but I suspect it's in brw_clip_unfilled.c
Comment 8 GitLab Migration User 2019-09-25 18:48:54 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1371.