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

Re: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification



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?
 
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.
 
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.
 
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.