There is a const qualifier in GLSL, and it should work on other
platforms without issue. The difference may be that OSX only supports
GLSL 1.20 currently, which is far behind most of NVidia's and ATI's
OpenGL implementations (GLSL 1.50 at least, more likely 3.30/4.10).
Perhaps this is the reason 'const' is required. Having a shader
compile across multiple GLSL versions and drivers can be tricky, and
I've run into a lot of issues on OSX that are simply GL version
related.

Mark

On Jan 16, 11:39 pm, Malcolm Humphreys <malcolmh...@...>
wrote:

Is the 'const' qualifier in glsl? I have to change the following to get the glsl shader to compile on OSX.

I'm cool to add another if glsl or cg block, just wondering if this could be something else.

.malcolm

diff --git a/src/core/Processor.cpp b/src/core/Processor.cpp
index 2f0f83b..c22770f 100644
--- a/src/core/Processor.cpp
+++ b/src/core/Processor.cpp
@@ -81,7 +81,7 @@ OCIO_NAMESPACE_ENTER
}
else throw Exception("Unsupported shader language.");

- shader << " const uniform sampler3D " << lut3dName << ") \n";
+ shader << " in sampler3D " << lut3dName << ") \n";
shader << "{" << "\n";

if(lang == GPU_LANGUAGE_CG)

Those who are having trouble with GLSL, are you on the most recent
version of OCIO?

I made a commit last week (which is in version 0.7.5), where on OSX
the const keyword would be omitted for GLSL 1.0 (which is what should
be used on OSX).

If you see line 79 in
http://github.com/imageworks/OpenColorIO/blob/master/src/core/Processor.cpp

And I confirmed that the ociodisplay app works on my osx 10.6.6
install. (A macbook laptop).

You'll see that in OCIO we currently distinguish the profile options
between GLSL 1.0, 1.3, and GG. And that only the CG and GLSL 1.3+
profiles use the const identifier. My hope was that we could get by
with the minimum language options necessary, and only add new glsl
versions if/when new language features are necessary.

-- Jeremy

No problem! Let me know if you have any troubles with the updated version.

I should also probably update the ociodisplay program to query the
glsl version, and select the best profile accordingly.

-- Jeremy

On Mon, Jan 17, 2011 at 1:46 PM, Malcolm Humphreys
<malcolmh...@...> wrote:

Oh snap, you have already fixed this. I haven't updated for a few days.

Sorry for the list noise.

.malcolm

On 18/01/2011, at 8:38 AM, Jeremy Selan wrote:

Those who are having trouble with GLSL, are you on the most recent
version of OCIO?

I made a commit last week (which is in version 0.7.5), where on OSX
the const keyword would be omitted for GLSL 1.0 (which is what should
be used on OSX).

If you see line 79 in
http://github.com/imageworks/OpenColorIO/blob/master/src/core/Processor.cpp

And I confirmed that the ociodisplay app works on my osx 10.6.6
install. (A macbook laptop).

You'll see that in OCIO we currently distinguish the profile options
between GLSL 1.0, 1.3, and GG. And that only the CG and GLSL 1.3+
profiles use the const identifier. My hope was that we could get by
with the minimum language options necessary, and only add new glsl
versions if/when new language features are necessary.

-- Jeremy

I already fixed this too; thought it was checked in last week.  hold
for details.

-- Jeremy

On Mon, Jan 17, 2011 at 3:21 PM, Malcolm Humphreys
<malcolmh...@...> wrote:

I'm having an unrelated problem when using a noop processor eg. scene_linear -> data on the gpu.

I'm getting a EXC_BAD_ACCESS when issuing glBegin(GL_QUADS). Having another shader for this case which doesn't reference 'tex2' fixes the problem. I have looked into it a little but it isn't clear why this is happening.

I'll be trying to commit some code that shows this soon.

.malcolm

On 18/01/2011, at 9:13 AM, Jeremy Selan wrote:

No problem!  Let me know if you have any troubles with the updated version.

I should also probably update the ociodisplay program to query the
glsl version, and select the best profile accordingly.

-- Jeremy

On Mon, Jan 17, 2011 at 1:46 PM, Malcolm Humphreys
<malcolmh...@...> wrote:

Oh snap, you have already fixed this. I haven't updated for a few days.

Sorry for the list noise.

.malcolm

On 18/01/2011, at 8:38 AM, Jeremy Selan wrote:

Those who are having trouble with GLSL, are you on the most recent
version of OCIO?

I made a commit last week (which is in version 0.7.5), where on OSX
the const keyword would be omitted for GLSL 1.0 (which is what should
be used on OSX).

If you see line 79 in
http://github.com/imageworks/OpenColorIO/blob/master/src/core/Processor.cpp

And I confirmed that the ociodisplay app works on my osx 10.6.6
install.  (A macbook laptop).

You'll see that in OCIO we currently distinguish the profile options
between GLSL 1.0, 1.3, and GG. And that only the CG and GLSL 1.3+
profiles use the const identifier.  My hope was that we could get by
with the minimum language options necessary, and only add new glsl
versions if/when new language features are necessary.

-- Jeremy

Yes, if you look att Processor.cpp : 381, you'll see that on apple
platforms we always insert a sampling of the tex2 even if it's not
needed. It appeared that without this, if the 3dlut was unused it
would be incorrectly optimized away and the app would crash.

In your shader you should see a line that looks like,
"// OSX segfault work-around: Force a no-op sampling of the 3d lut."

are you seeing this line and still having the crash? What platform are you on?

-- Jeremy

On Mon, Jan 17, 2011 at 3:27 PM, Jeremy Selan <jeremy...@...> wrote:

I already fixed this too; thought it was checked in last week. hold
for details.

-- Jeremy

On Mon, Jan 17, 2011 at 3:21 PM, Malcolm Humphreys
<malcolmh...@...> wrote:

I'm having an unrelated problem when using a noop processor eg. scene_linear -> data on the gpu.

I'm getting a EXC_BAD_ACCESS when issuing glBegin(GL_QUADS). Having another shader for this case which doesn't reference 'tex2' fixes the problem. I have looked into it a little but it isn't clear why this is happening.

I'll be trying to commit some code that shows this soon.

.malcolm

On 18/01/2011, at 9:13 AM, Jeremy Selan wrote:

No problem! Let me know if you have any troubles with the updated version.

I should also probably update the ociodisplay program to query the
glsl version, and select the best profile accordingly.

-- Jeremy

On Mon, Jan 17, 2011 at 1:46 PM, Malcolm Humphreys
<malcolmh...@...> wrote:

Oh snap, you have already fixed this. I haven't updated for a few days.

Sorry for the list noise.

.malcolm

On 18/01/2011, at 8:38 AM, Jeremy Selan wrote:

Those who are having trouble with GLSL, are you on the most recent
version of OCIO?

I made a commit last week (which is in version 0.7.5), where on OSX
the const keyword would be omitted for GLSL 1.0 (which is what should
be used on OSX).

If you see line 79 in
http://github.com/imageworks/OpenColorIO/blob/master/src/core/Processor.cpp

And I confirmed that the ociodisplay app works on my osx 10.6.6
install. (A macbook laptop).

You'll see that in OCIO we currently distinguish the profile options
between GLSL 1.0, 1.3, and GG. And that only the CG and GLSL 1.3+
profiles use the const identifier. My hope was that we could get by
with the minimum language options necessary, and only add new glsl
versions if/when new language features are necessary.

-- Jeremy

That's no problem at all.

FYI, this really easy to solve with the 'rebase' command. Say you
have a branch and you want to incorporate all changes on spi/master.

(I've already setup the spi remote, I am including my .git/config file
as an example. copy the 'spi' remote if you'd like).

git fetch --all (to get all branches up to date locally)
gitk --all (to visually inspect the commit tree)

git checkout photoshop (your branch name)
git rebase spi/master

If everything works, your new commits will be 'replayed' upon the
latest spi/master tree, bringing you up to date. If the rebase
doesn't work, you can always revert back with git rebase --abort.

-- Jeremy

On Mon, Jan 17, 2011 at 4:36 PM, Malcolm Humphreys
<malcolmh...@...> wrote:

Whoops, I should live by that mantra 'update or die'. I have a few
too many different checkouts of ocio, still a bit in svn land, goto to
get used to using local git branches.

This fixed this issue as well. :)

.malcolm