vade

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 

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 

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.

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.

jit-gl-slabshader-maximum-shader-filelength

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 

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.

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 

On May 17, 2007, at 1:10 AM, Joshua Kit Clayton wrote:

> 1. avoid if statements where possible (calculate all branches and 

> use mix operator for boolean logic, as demonstrated in 

> 2. if this isn't enough, use separate shaders with the different 

> cases. switching shaders after they've been loaded is quite quick 

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?

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

> 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

> On May 17, 2007, at 1:10 AM, Joshua Kit Clayton wrote:

> 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

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


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 

> 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 

>> 1. avoid if statements where possible (calculate all branches and 

>> use mix operator for boolean logic, as demonstrated in 

>> 2. if this isn't enough, use separate shaders with the different 

>> cases. switching shaders after they've been loaded is quite quick 

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?

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

how about making a jit.gl.shader object that references that shader, 

and having the multiple referencing slabs @shader that object?

how about making a jit.gl.shader object that references that shader,  
and having the multiple referencing slabs @shader that object?

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


Thanks. Here is a workaround Joshua Goldberg and I just "discovered" 

On May 17, 2007, at 2:32 PM, Wesley Smith wrote:

>> if I load one shader with a shader file, is that shader cached for 

>> shader that references that file, or only for that particular 

>> On May 17, 2007, at 1:10 AM, Joshua Kit Clayton wrote:

>> operator for boolean logic, as demonstrated in co.hardlight.jxs).

>> switching shaders after they've been loaded is quite quick since 

Thanks. Here is a workaround Joshua Goldberg and I just "discovered"  
that makes a lot of sense.

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

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:

>> any other shader that references that file, or only for that 

>>> 1. avoid if statements where possible (calculate all branches and 

>>> use mix operator for boolean logic, as demonstrated in 

>>> 2. if this isn't enough, use separate shaders with the different 

>>> cases. switching shaders after they've been loaded is quite quick 

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.

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

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.

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.

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

If it is a really big issue, why not just procedurally load each
possible shader in each slab instance at load time?

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.

Oh, im not complaining at all! Im just strategizing for optimum  
performance and um, elegance. No issues, just thinking out loud :)

> 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

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 

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 

Btw, dont assume im complaining when I send messages, you'll know 

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 

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

> 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

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 

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.

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