From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper) Date: Sat, 21 Sep 2013 01:09:56 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2004796002==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 9A6DBE5D32 for ; Fri, 20 Sep 2013 18:09:56 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============2004796002== Content-Type: multipart/alternative; boundary="1379725796.bA46d0D2.14966"; charset="us-ascii" --1379725796.bA46d0D2.14966 Date: Sat, 21 Sep 2013 01:09:56 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=66067 --- Comment #13 from Roland Scheidegger --- (In reply to comment #12) > (In reply to comment #11) > > > ARB_fragment_program_shadow may leave it undefined, but the GL spec ... > > > > Which spec exactly? GL specifications only cover GLSL shaders. > > ARB_fragment_program is separate from that and has its own rules. The > > extension specification clearly states that behaviour is undefined. > > > Section 8.23.1 of the GL 4.4 spec, which I paraphrased in comment #9. This only covers the DEPTH_TEXTURE_MODE but not the shadow target of arb_fragment_program_shadow. To quote from there: How should ARB_fragment_program_shadow function? a. Simply remove the interaction with ARB_shadow so that TEXTURE_COMPARE_MODE behaves exactly as specified in the OpenGL 1.4 specification. b. Add "SHADOW" targets to texture lookup instructions. TEXTURE_COMPARE_MODE is ignored. For samples from a SHADOW target TEXTURE_COMPARE_MODE is treated as COMPARE_R_TO_TEXTURE; otherwise, it is treated as NONE. c. Like (b), but with undefined results if TEXTURE_COMPARE_MODE and/or the internal format of the texture does not match the target. d. A hybrid of (a) and (b), where the SHADOW target means to use the TEXTURE_COMPARE_MODE state. RESOLVED - Option c, undefined behavior when the target and mode do not match. So if the cg compiler really does something as you suggested it is simply crazy to expect this to work. At least I see absolutely nothing why that GL wording somehow would apply to this (non-core) extension. -- You are receiving this mail because: You are the assignee for the bug. --1379725796.bA46d0D2.14966 Date: Sat, 21 Sep 2013 01:09:56 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 13 on bug 66067 from 
(In reply to comment #12)
> (In reply to comment #11)
> > > ARB_fragment_program_shadow may leave it undefined, but the GL spec ...
> > 
> > Which spec exactly? GL specifications only cover GLSL shaders.
> > ARB_fragment_program is separate from that and has its own rules. The
> > extension specification clearly states that behaviour is undefined.
> > 
> Section 8.23.1 of the GL 4.4 spec, which I paraphrased in comment #9.

This only covers the DEPTH_TEXTURE_MODE but not the shadow target of
arb_fragment_program_shadow.
To quote from there:
How should ARB_fragment_program_shadow function?
        a. Simply remove the interaction with ARB_shadow so that
           TEXTURE_COMPARE_MODE behaves exactly as specified in the
           OpenGL 1.4 specification.
        b. Add "SHADOW" targets to texture lookup instructions.
           TEXTURE_COMPARE_MODE is ignored.  For samples from a SHADOW target
           TEXTURE_COMPARE_MODE is treated as COMPARE_R_TO_TEXTURE;
           otherwise, it is treated as NONE.
        c. Like (b), but with undefined results if TEXTURE_COMPARE_MODE and/or
           the internal format of the texture does not match the target.
        d. A hybrid of (a) and (b), where the SHADOW target means to use the
           TEXTURE_COMPARE_MODE state.

      RESOLVED - Option c, undefined behavior when the target and
      mode do not match.

So if the cg compiler really does something as you suggested it is simply crazy
to expect this to work. At least I see absolutely nothing why that GL wording
somehow would apply to this (non-core) extension.

You are receiving this mail because:
  • You are the assignee for the bug.
--1379725796.bA46d0D2.14966-- --===============2004796002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============2004796002==--