basic-shaders-only defined at runtime

Scripting Issues
1

Is it possible to switch on the advance shader profile dynamically rather than at the beginning of the program ?

2

Makes sense, sounds like a good idea. I’ll put it on my todo-list.

3

OK, I’ve implemented your suggestion.
I’ll commit it into CVS as soon as I’ve tested it a bit more. Since this is such a tiny feature, I think I can slip this into 1.6.1.

4

Just checked it into CVS, and slipped them into the 1.6 branch.
Now, there are two additional optional parameters added to Shader.load and Shader.make, those are the vprofile and fprofile (as string), respectively.
If they are set, and not empty, they are used to override all the other profile settings - even the basic-shaders-only flag.
So, something like:

shader = Shader.load("blah.sha", "gp4vp", "gp4fp")

I didn’t extend ShaderPool or loader.loadShader with the new parameters.

5

So quick !

Actually, I have a question on this parameter. As the Cg shader program itself can already specify the shader profiles it requires, why this parameter is used in the first place ?

After your fixes, does it mean that this parameter is no longer required and I can just specify in the Cg file ? Or I need to call the Shader interface like:
Shader.load(“blah.sha”, “gp4vp”, “gp4fp”)
?

6

I don’t understand your question. Let me explain how it used to work.
If basic-shaders-only is set, active profiles are set to arbvp1 and arbfp1.
If it is #f, however, the active profile is set to the latest your card can get.
Now I look further into the code, I don’t think the one specified in the shader gets actually used at all. Maybe that got removed with the last shader overhaul.

In the new code, specifying the profiles as extra parameters will force Panda to compile the shader with that profile, even when basic-shaders-only is set.

7

The solution seems cleaner if panda loader follows the profiles specified in the shader program, isn’t it ?

8

Well… my only objection against that is that we’d have even more panda-specific magic in the Cg code. (I was even thinking of removing the forced //Cg at the top.)
This is a compiler option and IMHO should really be specified at compile-time.
Is there any specific reason you’d really like to have it in the shader code itself?

Btw: Wasn’t what I just implemented what you meant by “dynamically rather than at the beginning of the program”?

9

May be I have a fundamental misunderstanding of this question/concept. Please correct me the following, if anything wrong.

My assumption is:

  1. each shader can be compiled and run with different profiles (say some of them is at arbvp1,arbfp1, and some others is in vp30,fp30)
  2. A panda program can have these shaders mixed at run time. Some nodepath use a basic shader program, some nodepath use complicated shader program needs advance profiles.

In panda 1.5.4, I observe:

  1. The basic-shaders-only setting may be set at the very beginning.

My previous idea is:

  1. to have the profile requirements kept in the shader program. 2. When Panda see that requirement, it compiled that shader accordingly.
  2. The need of “basic-shaders-only” is gone forever.
  3. The shader cache manager can still function and
    5 no need to change code in python program at all.

My understanding of your implementation is:

  1. The need of “basic-shaders-only” is gone forever
  2. The panda specific requirement on the shader program (i.e.:
    //Cg
    //profile requirements…)
    is removed.
  3. User has to specify the profile requirement through Shader.load
  4. As user load the shader itself, not through loader, the cache effect is gone.

Thank you very much.

10

Not really.

  • A profile is not a version number. A different profile can behave differently, give other performance, support more or less stuff. Some shaders are too complex for certain profiles (that’s when you get the ‘shader too complex for driver’ error.)
    Also, some profiles are specific to OpenGL or DirectX 8/9/10.
  • basic-shaders-only sets the default profile. That’s how it always used to work, and how it still works. If it’s set, the default profile is arbfp1 arbvp1. If not, the latest profile is the default.
    basic-shaders-only is set to #t by default, always been, still is.
  • There is no “//Cg profile”, or it does nothing, not in 1.5.4, not in 1.6.0, not on the head. I have no idea when it was removed, probably when Josh overhauled the shader system in 1.5.0.

We could do that. I’d need to write some code that parses “//Cg profile”.
As for 3.: no, it would still exist, to set the default profile.
However, this approach has several problems:

  1. I hate to have magic panda-specific code in a Cg shader.
  2. It’s sloppy, to have something meaningful in comments.
  3. There’s no way to detect whether the profile is actually supported or not. If you do it in your program, you can detect which profiles are supported and choose one. Different cards can support entirely different profiles which do the same thing. If you just encode one magic profile in the shader, there’s no mercy: that profile, or the shader won’t work.
    Also, since some profiles are specific to OpenGL or DirectX 8 or 9, you can’t specify a different profile per interface.
  4. IMHO it doesn’t make much sense to specify it in the shader, except that the capabilities of a certain profile may be required for certain shader features. Since this is a compiler option, it makes more sense to pass it where the shader is compiled.

I agree, it might be easier for people not to have to mess with the settings at all. That’s why there’s basic-shaders-only: just disable it, if the arbfp1 and arbvp1 profiles aren’t good enough.

Of course, if you bring up a good counter-argument, I might still consider implementing it that way.

  1. No, not at all. basic-shaders-only still specifies the default profile.
  2. No, it was already removed, I’m pretty sure. I couldn’t find any reference to code that parses it anymore in the panda source. If it still makes a difference setting it, please let me know.
  3. No. The user can specify them. If he doesn’t, it will just use the default profile, set by basic-shaders-only.
  4. You’re right. I’ll find a solution for that, shouldn’t be too hard. The only thing is that the same shader might be loaded twice but with a different profile - I’d need to think of a way to handle that correctly.
11

Thank you for your clarification. I believe I have a better idea now.

My knowledge on shader is limited and have no strong reasons for asking to use comments in shader to do the said features. follow your recommendations/implementation is good enough !