From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 26769] New: r600: wrong fragment shader input when using gl_fragCoord. Date: Fri, 26 Feb 2010 03:02:12 -0800 (PST) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.sourceforge.net To: dri-devel@lists.sourceforge.net List-Id: dri-devel@lists.freedesktop.org http://bugs.freedesktop.org/show_bug.cgi?id=26769 Summary: r600: wrong fragment shader input when using gl_fragCoord. Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: wielkiegie@gmail.com Created an attachment (id=33583) --> (http://bugs.freedesktop.org/attachment.cgi?id=33583) Fragment shader to reproduce bug Consider simple shader in attachment. It works as expected, samples texture depending on input variable from vertex shader and puts texel as color. Uncommenting first comment shouldn't change anything (gl_FragDepth just defaults to gl_FragCoord.z), but it's not the case. In fact when I do so, fp_texCoord is always vec2(0.0). Well, I'm not sure about that, but it gives same results (e.g. all triangles are red, as is 0.0, 0.0 coordinate). Note that using gl_FragCoord in *any* way (that is not optimized away) causes this failure. For example uncommenting second comment gives same results. I can include vertex shader (that is also simple, just multiplies matrix with gl_Position and copies texCoord into fp_texCoord) and sample program, if that matter. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev --