Decora <> Open Shading Language?
james.graham at oracle.com
Thu Feb 14 14:43:17 PST 2013
Rich's analysis is spot on from my perspective. I don't have much time
to work on Decora these days and most of my plans for what I would do
are more tweaking and fixing issues that cause us headaches for our
current usage. For example, it was originally written to be a
standalone package that could be integrated into Swing apps or any other
infrastructure out there, but we've since broken just about any
generalized mechanism in it through disuse and lack of maintenance.
Since we don't really believe that it would ever be a standalone module
any more, it would integrate a whole lot more directly and simply if we
redid the interface to it to be Prism-specific.
The only "marketing bullet point" advantages to switching from Decora
would likely be possibly enabling user-supplied shaders, and also using
it for the greater needs of 3D apps that go beyond basic pixel-shaders.
We'd love to be able to leverage Decora at runtime for user-supplied
shaders, but that is a daunting amount of work since much of its actions
rely on being able to use javac and/or a native C, GSL, or HLSL compiler
to finish the work after the "decora compiler" does the translations -
i.e. it translates form HSL into various other forms of source code and
then runs other compilers on those. What we would probably have to do
is to provide a way for a developer to run the decora compiler alongside
his FX app and then include the various compiled alternative results,
but that would require building on multiple platforms to produce all of
the necessary files that are needed on an arbitrary target computer
(minimally, building on Windows could net a GLS, an HLSL, and a Java
version of the shader so that may be enough, but Mac developers would be
out of luck for producing Win-specific output). We'd also have to do a
security analysis of accepting compiled GSL and HLSL shaders in a
non-privileged deployment (the least common denominator work around
would be to only allow the Java-compiled versions of the shaders in the
absence of a signed app, but the performance on those would likely be
lower than something that the developer wrote themselves in hand-tuned
Java). So, there are a lot of issues to consider and work on there
before we could use Decora to provide user-supplied shaders.
It may be less work to provide the GPU plugins for OSL than to figure
out a workaround for the need for a compiler in Decora. We'd also
leverage a larger development community for the more common parts of it.
But, we'd also have to do a large security review of it every single
time we brought over a new source drop from it and the complexity of
that security review would involve analyzing the byte-code they produce
and all elements of their runtime to make sure that a hostile OSL
byte-code file couldn't break us. Using this "off the shelf" technology
sounds attractive, but integrating a 3rd party solution often has its
own headaches that you don't see when you are in the honeymoon phase
after having read all of the marketing bullet points. :(
I think a first task should be to get to the point where "Jim" isn't the
only engineer with more than a passing understanding of what goes on
with Decora under the hood - particularly since I don't have much time
to do a more indepth analysis of competing technologies like this. Any
volunteers that are fascinated by the world of shaders?
On 2/14/13 1:52 PM, Richard Bair wrote:
> Hi Philip,
> Very interesting link. I didn't clone the repo and check, I'm not sure how long it has been around. We've had Decora for 5 years I think, so we may predate it substantially.
> Adobe also has a shader technology called Pixel Bender (http://www.adobe.com/devnet/pixelbender.html). The nice thing about their language is that their designer tools support Pixel Bender (and I guess AGAL and Pixel Bender 3D https://www.adobe.com/devnet/flashplayer/articles/what-is-agal.html).
> Although we use Decora for our shaders, we haven't done much more than keep it running. Jim Graham has had a number of ideas about things he wanted to do to move Decora forward (maybe he can chime in with those).
> There are Pros / Cons to each:
> - It looks like Sony Pictures is continuing to work on OSL, it wasn't a dump & forget.
> - Any time multiple companies can contribute to the same thing, the better chance of broader adoption (& tools etc)
> - Being able to leverage other's work instead of doing all the work ourselves could free us from some maintenance costs
> - Different design center -- doesn't yet support GPUs for instance
> - Lack of tooling
> Pixel Bender:
> - Great tooling support
> - Same design center -- shaders for 2D / 3D applications
> - Robust
> - Leverage Adobe's investment
> - License is proprietary according to wikipedia, not sure myself
> - Not sure of the runtime size
> - Needs to be vetted for security risks
> - Does exactly what we need -- no more
> - Small size (no features we don't need)
> - No time to invest in serious upgrades
> - No tooling support
> I think that's a fair portrayal of the situation. From a pragmatic perspective it seems like supporting Pixel Bender would be a great way forward, but I don't know what the license situation is (i.e.: would we have to provide our own compiler, or could we reuse their compiler? Can we even do that much?). Given we haven't had time to spend improving decora, replacing it would be even more work.
> However, I wouldn't be opposed to using OSL or Pixel Bender or any other system if the benefits outweigh the costs.
> On Feb 14, 2013, at 1:49 AM, Philipp Dörfler <phdoerfler at gmail.com> wrote:
>> Here is the link:
>>  http://opensource.imageworks.com/?p=osl
>> Am 14.02.2013 um 10:48 schrieb Philipp Dörfler <phdoerfler at gmail.com>:
>>> I stumbled upon the Open Shading Language  which seems to be an already established standard and uses LLVM to optimize shaders. I wonder why this is not used instead of / as a backend for Decora. Might you please shed some light on that?
>>> Cheers and thanks in advance
>>> ~ Philipp
More information about the openjfx-dev