Forums > Jitter

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 //

http://www.vade.info
abstrakt.vade.info


May 16, 2007 | 11:24 pm


May 16, 2007 | 11:46 pm


May 16, 2007 | 11:59 pm


May 17, 2007 | 12:25 am


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 //

http://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 //
>
> http://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 //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>

v a d e //

http://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 //
>
> http://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.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 437 421 74 196617 shader normal;
#P newex 619 358 251 196617 jit.gl.shader v001 @file co.normal.jxs
@name normal;
#P newex 431 379 96 196617 jit.gl.texture v001;
#P message 476 331 30 196617 read;
#P newex 434 356 107 196617 jit.qt.movie @adapt 1;
#P message 338 424 78 196617 shader overlay;
#P message 291 424 40 196617 shader;
#P newex 617 409 259 196617 jit.gl.shader v001 @file co.overlay.jxs
@name overlay;
#P newex 246 387 96 196617 jit.gl.texture v001;
#P newex 246 458 127 196617 jit.gl.slab v001 @inputs 2;
#P message 288 336 30 196617 read;
#P newex 226 565 269 196617 jit.gl.videoplane v001 @transform_reset 2
@automatic 0;
#P newex 246 361 107 196617 jit.qt.movie @adapt 1;
#P newex 246 287 65 196617 qlim 33.333;
#P newex 226 264 30 196617 t b b;
#P toggle 71 155 15 0;
#P newex 71 181 51 196617 qmetro 2;
#P newex 71 219 58 196617 t b b erase;
#P newex 134 708 157 196617 jit.window v001 @depthbuffer 1;
#P newex 71 372 92 196617 jit.gl.render v001;
#P window linecount 2;
#P comment 486 160 341 196617 this patch does not have render to
texture enabled for simplicities sake , so just disabled the
videoplane if you wish to test your geometry effects.;
#P connect 20 0 11 0;
#P connect 18 0 11 1;
#P connect 12 0 11 0;
#P connect 14 0 11 0;
#P connect 15 0 11 0;
#P connect 11 0 9 0;
#P connect 16 0 18 0;
#P connect 7 0 8 0;
#P connect 7 0 16 0;
#P connect 17 0 16 0;
#P connect 8 0 12 0;
#P connect 10 0 8 0;
#P connect 6 1 7 0;
#P connect 6 0 9 0;
#P fasten 3 1 6 0 100 250 231 250;
#P connect 3 0 1 0;
#P connect 3 2 1 0;
#P connect 4 0 3 0;
#P connect 5 0 4 0;
#P window clipboard copycount 21;

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 //
>>
>> http://www.vade.info
>> abstrakt.vade.info
>>
>>
>>
>>
>>
>>

v a d e //

http://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 //
>>
>> http://www.vade.info
>> abstrakt.vade.info
>>
>>
>>
>

v a d e //

http://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 //

http://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 //

http://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


Viewing 17 posts - 1 through 17 (of 17 total)