jit.gl.slab/shader - maximum shader file/length ?


    May 16 2007 | 10:56 pm
    hello, I have a rather straightforward glsl shader that just happens
    to be rather.. ahem.. long and large, not overly complicated just
    lengthy. When loading the shader I get very long delays where max
    hangs (im assuming while it is trying to compile), and if it passes a
    certain length (a bunch of if statements for those who care), the
    shader refuses to run.
    Is there a length limit or a size limit for shader files?
    My shader is 20k in size and is around 1000 lines.
    I can send the shader off list for those interested. Its a multi mix
    mode 8 channel mixer, for those that care, that implements all the
    blend modes and is selectable for each input. Pretty straightforward
    code wise.
    Thanks, very curious about this.
    Max 4.6.2, Jitter 1.6.3b2.
    v a d e //
    www.vade.info
    abstrakt.vade.info

    • May 16 2007 | 11:24 pm
    • May 16 2007 | 11:59 pm
    • May 17 2007 | 5:10 am
      Two tips here:
      1. avoid if statements where possible (calculate all branches and use
      mix operator for boolean logic, as demonstrated in co.hardlight.jxs).
      2. if this isn't enough, use separate shaders with the different
      cases. switching shaders after they've been loaded is quite quick
      since they are cached.
      -Joshua
    • May 17 2007 | 6:23 pm
      Hi Joshua - thanks for the info.
      Question regarding caching -
      if I load one shader with a shader file, is that shader cached for
      any other shader that references that file, or only for that
      particular instance of a slab/shader?
      Thanks again!
      On May 17, 2007, at 1:10 AM, Joshua Kit Clayton wrote:
      >
      > Two tips here:
      >
      > 1. avoid if statements where possible (calculate all branches and
      > use mix operator for boolean logic, as demonstrated in
      > co.hardlight.jxs).
      >
      > 2. if this isn't enough, use separate shaders with the different
      > cases. switching shaders after they've been loaded is quite quick
      > since they are cached.
      >
      > -Joshua
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • May 17 2007 | 6:32 pm
      That particular instance.
      wes
      On 5/17/07, vade wrote:
      > Hi Joshua - thanks for the info.
      >
      > Question regarding caching -
      >
      > if I load one shader with a shader file, is that shader cached for any other
      > shader that references that file, or only for that particular instance of a
      > slab/shader?
      >
      >
      > Thanks again!
      >
      > On May 17, 2007, at 1:10 AM, Joshua Kit Clayton wrote:
      >
      >
      > Two tips here:
      >
      > 1. avoid if statements where possible (calculate all branches and use mix
      > operator for boolean logic, as demonstrated in co.hardlight.jxs).
      >
      > 2. if this isn't enough, use separate shaders with the different cases.
      > switching shaders after they've been loaded is quite quick since they are
      > cached.
      >
      > -Joshua
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
      >
      >
      >
    • May 17 2007 | 6:33 pm
      Er. That makes little sense. Sorry im a bit crazy right now.
      if I load shader a for jit.gl.slab 1, does jit.gl.slab 2 use the
      cached instance of shader a if I tell it to load shader a, or will it
      hit the disk?
      Thanks - apologies for the gibberish :)
      On May 17, 2007, at 2:23 PM, vade wrote:
      > Hi Joshua - thanks for the info.
      >
      > Question regarding caching -
      >
      > if I load one shader with a shader file, is that shader cached for
      > any other shader that references that file, or only for that
      > particular instance of a slab/shader?
      >
      > Thanks again!
      >
      > On May 17, 2007, at 1:10 AM, Joshua Kit Clayton wrote:
      >
      >>
      >> Two tips here:
      >>
      >> 1. avoid if statements where possible (calculate all branches and
      >> use mix operator for boolean logic, as demonstrated in
      >> co.hardlight.jxs).
      >>
      >> 2. if this isn't enough, use separate shaders with the different
      >> cases. switching shaders after they've been loaded is quite quick
      >> since they are cached.
      >>
      >> -Joshua
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • May 17 2007 | 6:37 pm
      how about making a jit.gl.shader object that references that shader,
      and having the multiple referencing slabs @shader that object?
      On May 17, 2007, at 2:23 PM, vade wrote:
      > Hi Joshua - thanks for the info.
      >
      > Question regarding caching -
      >
      > if I load one shader with a shader file, is that shader cached for
      > any other shader that references that file, or only for that
      > particular instance of a slab/shader?
      >
      > Thanks again!
      >
      > On May 17, 2007, at 1:10 AM, Joshua Kit Clayton wrote:
      >
      >>
      >> Two tips here:
      >>
      >> 1. avoid if statements where possible (calculate all branches and
      >> use mix operator for boolean logic, as demonstrated in
      >> co.hardlight.jxs).
      >>
      >> 2. if this isn't enough, use separate shaders with the different
      >> cases. switching shaders after they've been loaded is quite quick
      >> since they are cached.
      >>
      >> -Joshua
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
    • May 17 2007 | 6:42 pm
      Thanks. Here is a workaround Joshua Goldberg and I just "discovered"
      that makes a lot of sense.
      Problem solved. Thanks guys :)
      On May 17, 2007, at 2:32 PM, Wesley Smith wrote:
      > That particular instance.
      >
      > wes
      >
      > On 5/17/07, vade wrote:
      >> Hi Joshua - thanks for the info.
      >>
      >> Question regarding caching -
      >>
      >> if I load one shader with a shader file, is that shader cached for
      >> any other
      >> shader that references that file, or only for that particular
      >> instance of a
      >> slab/shader?
      >>
      >>
      >> Thanks again!
      >>
      >> On May 17, 2007, at 1:10 AM, Joshua Kit Clayton wrote:
      >>
      >>
      >> Two tips here:
      >>
      >> 1. avoid if statements where possible (calculate all branches and
      >> use mix
      >> operator for boolean logic, as demonstrated in co.hardlight.jxs).
      >>
      >> 2. if this isn't enough, use separate shaders with the different
      >> cases.
      >> switching shaders after they've been loaded is quite quick since
      >> they are
      >> cached.
      >>
      >> -Joshua
      >>
      >> v a d e //
      >>
      >> www.vade.info
      >> abstrakt.vade.info
      >>
      >>
      >>
      >>
      >>
      >>
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • May 17 2007 | 6:47 pm
      The issue with this is that the individual jit.gl.shader isntance has
      control over the specs of the shader, not the slab instances themselves.
      so if 2 slabs reference the same shader, they have the same values.
      On May 17, 2007, at 2:37 PM, joshua goldberg wrote:
      > how about making a jit.gl.shader object that references that
      > shader, and having the multiple referencing slabs @shader that object?
      >
      >
      > On May 17, 2007, at 2:23 PM, vade wrote:
      >
      >> Hi Joshua - thanks for the info.
      >>
      >> Question regarding caching -
      >>
      >> if I load one shader with a shader file, is that shader cached for
      >> any other shader that references that file, or only for that
      >> particular instance of a slab/shader?
      >>
      >> Thanks again!
      >>
      >> On May 17, 2007, at 1:10 AM, Joshua Kit Clayton wrote:
      >>
      >>>
      >>> Two tips here:
      >>>
      >>> 1. avoid if statements where possible (calculate all branches and
      >>> use mix operator for boolean logic, as demonstrated in
      >>> co.hardlight.jxs).
      >>>
      >>> 2. if this isn't enough, use separate shaders with the different
      >>> cases. switching shaders after they've been loaded is quite quick
      >>> since they are cached.
      >>>
      >>> -Joshua
      >>
      >> v a d e //
      >>
      >> www.vade.info
      >> abstrakt.vade.info
      >>
      >>
      >>
      >
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • May 17 2007 | 6:52 pm
      Each instance has it's own version of whatever was on disk at the time
      the file was loaded. You can test this with 2 videoplanes and 2 slabs
      and loading the file in one of them after modification. Having them
      erefernece other objects is not really worth it. What if they were in
      different contexts? There are other issues as well. Anyway, I don't
      think the current behavior is unreasonable.
      wes
    • May 17 2007 | 6:57 pm
      If it is a really big issue, why not just procedurally load each
      possible shader in each slab instance at load time?
      That way you can take advantage of caching without any wonky workarounds...
      :)
      AB
    • May 17 2007 | 7:06 pm
      Oh, im not complaining at all! Im just strategizing for optimum
      performance and um, elegance. No issues, just thinking out loud :)
      On May 17, 2007, at 2:52 PM, Wesley Smith wrote:
      > Each instance has it's own version of whatever was on disk at the time
      > the file was loaded. You can test this with 2 videoplanes and 2 slabs
      > and loading the file in one of them after modification. Having them
      > erefernece other objects is not really worth it. What if they were in
      > different contexts? There are other issues as well. Anyway, I don't
      > think the current behavior is unreasonable.
      >
      > wes
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • May 17 2007 | 7:08 pm
      But Wesley just said it will only work for that particular instance,
      unless, you mean, for every jit.gl.slab, have it load every possible
      shader I would ever need.
      Thats doable, but a bit overkill I think, no? Anyway, not a HUGE
      issue, just good to know how things work behind the scenes. Thanks
      again guys.
      Btw, dont assume im complaining when I send messages, you'll know
      when im complaining :D
      Thanks again!!
      On May 17, 2007, at 2:57 PM, andrew benson wrote:
      > If it is a really big issue, why not just procedurally load each
      > possible shader in each slab instance at load time?
      >
      > That way you can take advantage of caching without any wonky
      > workarounds...
      >
      > :)
      >
      > AB
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • May 17 2007 | 7:45 pm
      Actually, sorry for any misinformation. My memory was a little bit
      rusty. The cache was only implemented for the old school Cg compiler
      for GLSL. Since the Cg GLSL compiler and our requisite text
      replacement operations on its assembly output was slow, this was
      important. This cache was global across all instances of jit.gl.slab/
      shader, and would only be reloaded if the modtime on disk had changed.
      As of 10.4.3 or a decent Windows driver, GLSL is compiled by the
      OpenGL driver. This is typically quite fast, and we don't have a
      cache in place. As already mentioned you won't want to do the
      jit.gl.shader workaround unless you really want to share parametric
      settings across shaders (or dump all relevant settings to each
      required object for each render call), or keep GPU shader resources
      at a minimum.
      Hope this helps clarify things a tad.
      -Joshua