dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 63579] Savage 2 Edges render white [r600g]
Date: Wed, 17 Apr 2013 21:19:00 +0000	[thread overview]
Message-ID: <bug-63579-502-IerIJl7b6s@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-63579-502@http.bugs.freedesktop.org/>


[-- Attachment #1.1: Type: text/plain, Size: 2211 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=63579

--- Comment #17 from Erik Faye-Lund <kusmabite@gmail.com> ---
(In reply to comment #16)
> (In reply to comment #15)
> > Thanks for the clarification, but I'm still not entirely convinced.
> > 
> > I've just tested the latter. So apparently, Mesa is the only major
> > OpenGL implementation that currently implements this.
> 
> They all support it in preprocessor directives.  We verified this in 2010
> when we added that level of support back.  As I said before, we've
> encountered shaders in games that use line continuation for multi-line
> macros.
> 
> #define foo(a, b) \
>     do { \
>         b = bar(a); \
>     } while(0)

That might very well be the case. But this ticket is not about line
continuation in pre-processor directives. My test were in comments, as is the
issue with this ticket. And none of them implementations listed above supports
them in comments before a "#version 420" statement (if supported at all).

> Making the support general (instead of just for preprocessor directives)
> simplified the code greatly.  Since I'm responsible for maintaining this
> code base as my job, that's a strong incentive for me.

I'm sorry if this is a bit blunt, but wow. That's one of the least appealing
arguments I've heard in a long time. Not only is someone paying you for your
time, you think that's a *justification* for not supporting the standard?
That's pretty much the oppositte of how this usually works.

So, as a paying customer of Intel, where would I file a bug-report that Intel
will deal with in a responsible way?

> > By the way, the WebGL conformance tests also checks that line continuation
> > does not work. So there are at least two known, publically available shaders
> > that depends on no line-continuation to work. Of course, the latter is
> > synthetic, but at least it's based on wording in a specification.
> 
> I'm not going to add complexity or overhead to the preprocessor for this
> case.  If WebGL tests non-continuation behavior, we can add the browsers to
> the workaround list.

Fair enough. At least when considered in isolation.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 3235 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2013-04-17 21:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-16  0:56 [Bug 63579] New: Savage 2 Edges render white [r600g] bugzilla-daemon
2013-04-16  0:57 ` [Bug 63579] " bugzilla-daemon
2013-04-16  0:58 ` bugzilla-daemon
2013-04-16  0:59 ` bugzilla-daemon
2013-04-16  2:11 ` bugzilla-daemon
2013-04-16  3:04 ` bugzilla-daemon
2013-04-16  3:37 ` bugzilla-daemon
2013-04-16  3:43 ` bugzilla-daemon
2013-04-16  4:37 ` bugzilla-daemon
2013-04-16  7:20 ` bugzilla-daemon
2013-04-16 17:25 ` bugzilla-daemon
2013-04-16 19:06 ` bugzilla-daemon
2013-04-17  8:32 ` bugzilla-daemon
2013-04-17 17:03 ` bugzilla-daemon
2013-04-17 17:10 ` bugzilla-daemon
2013-04-17 18:13 ` bugzilla-daemon
2013-04-17 18:51 ` bugzilla-daemon
2013-04-17 20:03 ` bugzilla-daemon
2013-04-17 20:52 ` bugzilla-daemon
2013-04-17 21:19 ` bugzilla-daemon [this message]
2013-04-17 21:38 ` bugzilla-daemon
2013-05-18  2:41 ` bugzilla-daemon
2013-05-18 12:37 ` bugzilla-daemon
2019-09-18 19:02 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-63579-502-IerIJl7b6s@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon@freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox