output parameter whose default value comes from "init ops" but which actually got an instance value, and was also connected to a downstream layer, could be eliminated but incorrectly, by passing along to the downstream shader the constant value it would have been assigned by default, rather than the constant instance value.
so that colors vs vectors are interchangeable for closure construction arguments (this can arise because of coalescing of temporaries). Also improve a nearby error message.
work to allow shader parameters that are arrays of unspecified length.
becomes definite when an instance value is attached, or when a connection is made. This was always intended but missing logic to make it work properly. This is primarily the work of Max Liani. Some debug/cleanup, comments, and test cases added by LG follow in the next checkin.
call -- take BOTH a filename and texture handle. Filename is always passed, handle may optionally be passed, and optionally used by the renderer. Compatibility break.
I decided that the RendererServices methods that take texture handles should also still be passed the filenames. That really simplify things for some renderers that have cases internally where they need both. Sorry about the compatibility break. There's been more churn on this matter in the past couple weeks than I like, but then again, this is the master branch where we say APIs are subject to change.
TextureSystem::Perthread* to use for that context. This is helpful for renderers that want to save a bit of time by allocating such things up front.
…d_alpha. There was no benefit to the code duplication of these subtly different funcs.
TL;DR: If the runtime optimizer can figure out which texture file is needed for a texture call, it can ask for an opaque texture handle ahead of time and avoid the filename-to-handle lookup on each individual texture call. Details: Additions to RendererServices: * Calls to retrieve opaque TextureHandle* from the underlying texture system, given a known texture name. * New (additional) entry points for texture(), texture3d(), environment(), and get_texture_info() that take a TextureHandle* rather than a filename. Note that renderer implementations will need to add the new virtual functions to their subclass of RendererServices. It's ok to define them trivially (i.e., just do nothing and return false) as long as the renderer doesn't turn on the opt_texture_handle (see below). New optimization option: "opt_texture_handle". For now, the default is false. A renderer should explicitly turn it on if it supports this feature with nontrivial versions of those aforementioned RendererServices methods. Now then, when generating JIT code for a texture call, if at that point it can figure out exactly which texture is being referenced (if the filename is a known string constant, at that point in optimization), it will generate a call to an alternate texture function that takes the handle directly, rather than the filename. The bottom line is that this speeds up texture calls by about 10% (using OIIO's texture system, for other texture systems YMMV).
…text*, and if NULL, execute() will get and release the context for you. Easy.
RuntimeOptimizer::optimize_instance() was getting really big and unwieldy. This refactor, which just moves code without changing any behavior, breaks it into two pieces: (1) optimize_instance still loops over passes, and does per-pass optimizations and other housekeeping; (2) optimize_ops does all the per-op optimizations, over a range of ops. So the guts of the loop over ops has just been broken out into a separate function. The added benefit, which will be apparent in a future review of something I'm working on, is that there is utility in calling the optimize_ops over shorter ranges of ops, for particular purposes. Stay tuned.
…ing is disabled This fixes a performance regression that is particularly noticeable for small shaders executed from many threads