[Mesa-dev] Status of GL_ARB_separate_shader_objects? I would like to help.

[gregory hainaut]

Hello,

I would like to run PCSX2 on mesa drivers but unfortunately it miss a
couple of features, mostly the GL_ARB_separate_shader_objects extension.

I think I can help to implement this extension at least the opengl (ie
not glsl) plumbering part (with some piglit tests). The extension
GL_EXT_separate_shader_object is marked supported by the driver but I
don't know if GLSL fully support separate program or with limitation.

I already begun to implement the extension, enough to write some piglit
tests. However 2 parts on the specs are not clear for me.

* GenProgramPipelines doesn't create object!
... Spec extract:
These names are marked as used, for the purposes of GenBuffers only,
  but they acquire buffer state only when they are first bound with
  BindBuffer (see below), just as if they were unused.
...

Basically any command (like BindBuffer) that access the pipeline will
create the pipeline. It seems like vertex array object. From an
implemention point of view it seems much easier to create the object
during GenProgramPipelines call. However I don't know if
IsProgramPipeline must return FALSE if the object was never really
created (bind) like VAO.

* Mix between Pipeline object and the standard
  UseProgram/ActiveProgram. Here some extract of the spec:

# BindProgramPipeline may also be used
  to bind an existing program pipeline object.
If no current program object has been established by UseProgram, the
  pro- gram objects used for each shader stage and for uniform updates
  are taken from the bound program pipeline object, if any. If there is
  a current program object established by UseProgram, the bound program
  pipeline object has no effect on rendering or uniform updates. When a
  bound program pipeline object is used for rendering, individual
  shader executables are taken from its program objects as de- scribed
  in the discussion of UseProgram in section 7.3).

# glUseProgram
If program is non-zero, this command will make program the current
program object. This will install executable code as part of the
current rendering state for each shader stage present when the program
was last successfully linked. If UsePro- gram is called with program
set to zero, then there is no current program object.

From
http://www.opengl.org/registry/specs/ARB/separate_shader_objects.txt If
both extensions are supported, the rule giving priority to UseProgram
over pipeline objects needs to be updated, given that the single
UseProgram binding point is replaced by a collection of binding points.
We effectively treat this collection of binding points as another
pipeline object, and treat that object as higher priority if it has a
program attached to *any* attachment point.  The priority rules in this
spec are rewritten as follows:

      The executable code for an individual shader stage is taken from
      the current program for that stage.  If there is a current
      program object for any shader stage or for uniform updates
      established by UseProgram, UseShaderProgramEXT, or
      ActiveProgramEXT, the current program for that stage (if any) is
      considered current.  Otherwise, if there is a bound program
      pipeline object ...

    Note that with these rules, it's not possible to mix program
    objects bound to the context with program objects bound to a
    program pipeline object; if any program is bound to the context,
    the current pipeline object is ignored.


So how the following case must be handle?

case 1/
RESET STATE
glUseProgram(2)
BindProgramPipeline(5)
# no effect but is the pipeline bound or not?
# My understand is not.

case 2/
RESET STATE
BindProgramPipeline(5)
glUseProgram(2)        
# higher priority than the pipeline. Do we
# unbind the pipeline? 
glUseProgram(0)        
# What state is expected NULL or pipeline 5? my understanding is NULL

Case 3/
RESET STATE
BindProgramPipeline(5)
glUseProgram(0)      
# Don't use a real program.  What state is
# expected NULL or pipeline 5? My understanding is NULL


Cheers,
Gregory