[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification

Let me just state by way of introduction in my usually offensively unproductive flamboyant manner: I'm really annoyed at this culture of "let's just half-arse it"

To illustrate why nobody is getting around translation and why you can't sweep it under the rug as "meh", here I quote the ESSL 1.00/3.00 standard (section 3.4):

#line must have, after macro substitution, one of the following two forms:
#line line
#line line source-string-number
where line and source-string-number are constant integer expressions. 

The language contains a facility to provide line and file numbers (not filenames). It contains that facility in recognition that shaders are often composites of multiple files and snippets. In case we're not clear on that fact, here's some examples:
And in case there's any lingering doubt that translation is indeed what happens a lot, here's some examples of that:
To wit, I'm pretty sure that most of you have translation in your own utility code, and that none of you would want to be debugging your shaders (single or multi file) based on raw error logs as they come out.

On Thu, Jan 8, 2015 at 12:50 AM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
I am not convinced translation is necessary
It is, demonstrated above.
, or that without translation, the logs are useless.
They are, demonstrated in the last message.
Further, it's not guaranteed that all errors are caught by ANGLE. Even if we assume ANGLE is perfect, sometimes there are GL implementations that are too strict. These would generate non-standard error logs. We don't want to get involved with translating error logs.
That's true, see my comment about a culture of half-arsing it.
Since it seems the main benefit for devs is having the error line displayed, I recommend requesting this functionality from browser vendors. I think trying to codify a log format just so devs can write parsing translators is the wrong way to go about this.
Wrong assertion for three reasons.
  1. The ESSL compiler doesn't have the necessary information to produce usable error logs. Providing that information would require changing the language standard, which is something I'm pretty sure WebGL can't do.
  2. Even if you had the relevant information and could produce a nice error log, that doesn't necessairly mean you'll get the same format of error log from different vendors, which is a usability impediment.
  3. Even if you had consistent and readable error logs, errors aren't always displayed as a log, sometimes they're tied in with a variety of editing tools (see shadertoy, glslsandbox, vim/websocket hookups, etc.)
In closing: This problem isn't going to go away. Ignoring it isn't going to solve it. Somebody has to do the hard work to make sure that error message are relevant, parsable and presentable, and the best crew to do this are browser vendors.