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

Re: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification



On Thu, Jan 8, 2015 at 11:01 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Fri, Jan 9, 2015 at 12:45 AM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
I (at least) debug my shaders with the logs spewed from GL.
Which means that the shaders that you write are single file per stage without any automatic modification (such as including boilerplate and utilities), inclusion of other files, require system, composition or other transformations. This isn't actually how most WebGL shaders are written. I'm sure you realize this. Have you reviewed sketchfabs WebGL Insights chapter? Did you look at glslify?  Mathbox? Did you look into the crop of popular frameworks around WebGL?
gl.getShaderSource()
 
Is it required to debug shaders? No.
It's absolutely required because beyond "hello world" usage, line numbers shift, and file numbers start meaning something. File numbers are a ESSL language feature you know? I've shown that, I've quoted the section. Did you see that? Did you realize that nobody in his right mind maps file-numbers to file names/paths in their heads? That nobody adjusts for line-shift due to composition in their head? Isn't that quite obvious and straightforward to understand? What's exactly unclear about this? Didn't I just provide plenty of examples and reasoning why that is so? Why do you keep rejecting an obviously unrejectable argument? Why do I even have to point this out to you? It's exceedingly obvious.
gl.getShaderSource() + JS helpers. Would it be nicer if this were fully-automated? Yes. I don't think it's critical to fix right now though.
 
The specs say a lot of things. Implementations do a lot of things. Unfortunately, neither is a subset of the other. A good portion of my time goes to dealing with bad behavior from non-spec-compliant implementations. I'm not excited to invest even more time in this just so that error messages are prettier. (They seem sufficiently functional at present to me)
They're functional because, as you've stated, that most errors are generated by the Angle validator, and most vendors use Angle, and so the format is semi-standard. It's only a semi-standard, because sometimes garbage does get piped trough from the underlying backend, and at least one vendor, who isn't using Angle, isn't implementing that format. You're lulled into a false complacency to think things are ok, because they seem to work alright (did I mention I didn't like this kind of half-arsing, I mentioned that, didn't I? I'm pretty sure I did.). I'm not saying this isn't going away because I won't shup about it, no, sooner or later even I will get tired of pointing the bleedingly obvious. No, this problem isn't going to go away, because the future holds more variety of WebGL implementations, and possibly more errors that need to get piped trough from the backend as language features expand and you can produce errors for source that's syntactically correct, but cannot be compiled or linked regardless.
We should avoid standardizing with the assumption that ANGLE will always be used. It's already not used in IE.
If you want standardized error messages, and don't use something like ANGLE, there's a bunch of work needed to parse error messages from different drivers, not just different vendors.
 
If it's so easy to do, why not have a library which does it. That would at least halve the development time required. Submit bugs to browsers if they emit error logs that don't match the GLES spec.
The GLES spec doesn't have a specification of the errors yet. I fooolishly thought it'd be easier to find UA vendor consensus on an obvious API intended for both human and machine consumption before I'd have to attempt to force UA vendors to conform to the ES spec by changing the ES spec.
If errors aren't specified, I really really don't want to commit to a universal error format right now, given finite resources.
 
It's a nice thought, but it's too low in terms of ROI compared to other things we're working on right now. It takes time just to standardize things, not to mention the long tail of driver-specific log parsers this might eventually entail.

Phrased as an optional extension, it's more viable. We could simply choose to stop offering it if we need to change something, or are on a configuration where we don't generate errors ourselves.

However, the more time we spend on this low-ROI work item now, the longer WebGL 2 is going to take.