Summary: | [i965 gem] glsl/pointcoord fails | ||
---|---|---|---|
Product: | Mesa | Reporter: | lin, jiewen <jiewen.lin> |
Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
Status: | VERIFIED DUPLICATE | QA Contact: | libo <bo.c.li> |
Severity: | normal | ||
Priority: | medium | CC: | eric, kassah |
Version: | unspecified | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
log
conf screenshot |
Created attachment 20986 [details]
conf
Created attachment 20987 [details]
screenshot
On the pic, the left window is software rendering(normal), and the right
one is direct rendering.
The case is under mesa/progs/glsl/ This issue still eixsts with current build. Works fine on master and 7.4. Gah, wrong tab. This issue still eixsts on G45 with following commits: Libdrm: (master)121b9648f846d900e67818869974ee82046e9b25 Mesa: (mesa_7_6_branch)9216b4e7be942fed432ceb42a4337d7298d0bc6c Xserver: (server-1.6-branch)3044711412d0a08ba65a491bd2441c0c8980f5e2 Xf86_video_intel: (master)94fc93d4e2b88565dca17f72903d8991213c9ee8 Kernel: (master)e07cccf4046978df10f2e13fe2b99b2f9b3a65db It works well on GM965. It failed on GM965 and G45. (In reply to comment #7) > This issue still eixsts on G45 with following commits: > Libdrm: (master)121b9648f846d900e67818869974ee82046e9b25 > Mesa: (mesa_7_6_branch)9216b4e7be942fed432ceb42a4337d7298d0bc6c > Xserver: (server-1.6-branch)3044711412d0a08ba65a491bd2441c0c8980f5e2 > Xf86_video_intel: (master)94fc93d4e2b88565dca17f72903d8991213c9ee8 > Kernel: (master)e07cccf4046978df10f2e13fe2b99b2f9b3a65db > > It works well on GM965. (In reply to comment #8) > It failed on GM965 and G45. > So... does it work on GM965 or not? These two comments are contradictory. (In reply to comment #9) > (In reply to comment #7) > > This issue still eixsts on G45 with following commits: > > Libdrm: (master)121b9648f846d900e67818869974ee82046e9b25 > > Mesa: (mesa_7_6_branch)9216b4e7be942fed432ceb42a4337d7298d0bc6c > > Xserver: (server-1.6-branch)3044711412d0a08ba65a491bd2441c0c8980f5e2 > > Xf86_video_intel: (master)94fc93d4e2b88565dca17f72903d8991213c9ee8 > > Kernel: (master)e07cccf4046978df10f2e13fe2b99b2f9b3a65db > > > > It works well on GM965. > > (In reply to comment #8) > > It failed on GM965 and G45. > > > > So... does it work on GM965 or not? These two comments are contradictory. Never mind. I re-read it and figured out that #8 is a correction of #7. I started looking at this today. The code in the 965 driver is completely wrong. When point-sprite mode is enabled (via glEnable(GL_POINT_SPRITE)), fragment shaders get an extra input called gl_PointCoord. This should always be done. If a particular texture unit has GL_COORD_REPLACE set, this value should be copied to the appropriate gl_TexCoord entry. This is not what happens. To be honest, I can't (yet) make heads or tails of what is happening. In addition: * GL_POINT_SPRITE_COORD_ORIGIN is not respected for gl_PointCoord * GL_POINT_SPRITE_R_MODE_NV is completely ignored In the SF we should calculate per-vertex texture coordinates according to the ARB_point_sprite spec for gl_PointCoord: s = 1/2 + (x_f + 1/2 - x_w) / size t = 1/2 - (y_f + 1/2 - y_w) / size or s = 1/2 + (x_f + 1/2 - x_w) / size t = 1/2 + (y_f + 1/2 - y_w) / size according to the setting of the point sprite coordinate origin. size is the point's size, x_f and y_f are the (integral) window coordinates of the fragment, and x_w and y_w are the exact, unrounded window coordinates of the vertex for the point. This should be passed to the WM. The "regular" texture coordinates should also be passed to the WM. In the WM, each coordinate that is replaced (via GL_COORD_REPLACE) should have some combination of values from gl_PointCoord, gl_TexCoord[n], and {0, 0, 0, 1} copied to it. This allows all the possible point sprite R-mode settings to be supported. Marking this as a dupe of the simpler, piglit test for gl_PointCoord. *** This bug has been marked as a duplicate of bug 28749 *** Platform: Sandybrige Libdrm: (master)2.4.24-6-g3b04c73650b5e9bbcb602fdb8cea0b16ad82d0c0 Mesa: (7.10)3ed9054cc598a38d2cbcadd3f81943635148514c Xserver: (master)xorg-server-1.10.0 Xf86_video_intel: (master)2.14.901-2-g049ce4397ddf7fd088ce364cbb53cacf5133176f Cairo: (master)f1d313e042af89b2f5f5d09d3eb1703d0517ecd7 Kernel: (drm-intel-fixes)467cffba85791cdfce38c124d75bd578f4bb8625 This bug is existing in Sandybrige Rev09 bug 28749 has been fixed. Li Bo to verify if this bug gone on SNB. The demo still has render error on SNB but I don't they are the same question. It's duplicate with Bug 46376. |
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.
Created attachment 20985 [details] log System Environment: -------------------------- --Platform: 965 --Architecture(32-bit,64-bit,compatiblity): 32-bit --2D driver: (xf86-video-intel-2.6-branch) 6ca0d7e6ff05bff2bb88bfae64c2d79ac115bd38 --3D driver: (intel-2008-q4)154a9e5317f890618932cea0129ef887e16baf84 --DRM:shipped with kernel 2.6.28-rc6 for-airlied --libdrm: (master)c99566fb810c9d8cae5e9cd39d1772b55e2f514c --Xserver: (server-1.6-branch)b268458eab2f213ec14dfe8013aa714c187e3aab --Kernel: 2.6.28-rc6 for-airlied Bug detailed description: -------------------------- start X and run pointcoord, the display is not correct. Details could be got in the attachment screenshot. Reproduce steps: ---------------- 1. xinit & 2. ./pointcoord