Re: [Mesa-dev] Status of GL_ARB_separate_shader_objects? I would like to help.
On 03/23/2013 02:05 PM, gregory hainaut wrote: On Fri, 22 Mar 2013 15:44:07 -0700 Matt Turner matts...@gmail.com wrote: On Fri, Mar 22, 2013 at 1:00 PM, gregory hainaut gregory.hain...@gmail.com wrote: * 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. This is a weird part of the spec. After glGen* (but before glBind*) the associated glIs* function usually returns false. It's something that no one but conformance tests seem to care about. See commit fd93d55141f11069fb76a9b377ad1af88d0ecdd3 (in Mesa) for how to fix this kind of thing. I said usually above because there is some inconsistency. The ARB_sampler_objects spec says that the act of calling glIsSampler() actually creates the object. It looks like for ARB_separate_shader_objects that glGen* followed by glIs* should return false (like VAOs). Ok. Thanks for the example. I updated my code and create a piglit test. By the way, fglrx doesn't follow this behavior, dunno for nvidia. On the mix UseProgram/BindProgramPipeline subjet. I try to search the spec for additional info and found this example: ## Issue 4: When a non-zero program is passed to UseProgram, any subsequent uniform updates will affect that program, ignoring the active program in any bound pipeline object. For example: glUseProgram(0); glBindProgramPipeline(1); glActiveProgram(1, 2); glUniform1f(0, 3.0); // affects program 2 glUseProgram(3); glUniform1f(0, 3.0); // affects program 3 glUseProgram(0); glUniform1f(0, 3.0); // affects program 2 ### So after glUseProgram(0), the state of the pipeline is restored (or they forgot to update this part of the spec when they clarify the priority rule), at least the ActiveProgram. Anyway, I write an extensive piglit test and check the behavior on fglrx. Here the outcome, glUseProgram(0) destroy current program state, the pipeline need to be rebound again for any shader based rendering. However ActiveProgram is restored as the previous example! Any opinion is welcome, run the test on nvidia? Mimic AMD behavior? There are a few places in GL that behave this way. There are two separate pieces of state that may be used. In this case, either the UseProgram state or the BindProgramPipeline state. If UseProgram sets a non-zero program, that state is used. Otherwise the BindProgramPipeline state is used. In Mesa we generally handle this by having both sets of state tracked in the context and a third _State field that's the one actually in use. Right now in the context we have struct gl_shader_state Shader; /** GLSL shader object state */ I think we'd expand this to struct gl_shader_state Shader; /** GLSL shader object state */ struct gl_shader_state SSOShader; struct gl_shader_state *_Shader; /** Points to ::Shader or ::SSOShader */ Or similar. In this case, I think AMD's behavior is incorrect. Cheers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of GL_ARB_separate_shader_objects? I would like to help.
On Fri, 22 Mar 2013 15:44:07 -0700 Matt Turner matts...@gmail.com wrote: On Fri, Mar 22, 2013 at 1:00 PM, gregory hainaut gregory.hain...@gmail.com wrote: * 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. This is a weird part of the spec. After glGen* (but before glBind*) the associated glIs* function usually returns false. It's something that no one but conformance tests seem to care about. See commit fd93d55141f11069fb76a9b377ad1af88d0ecdd3 (in Mesa) for how to fix this kind of thing. I said usually above because there is some inconsistency. The ARB_sampler_objects spec says that the act of calling glIsSampler() actually creates the object. It looks like for ARB_separate_shader_objects that glGen* followed by glIs* should return false (like VAOs). Ok. Thanks for the example. I updated my code and create a piglit test. By the way, fglrx doesn't follow this behavior, dunno for nvidia. On the mix UseProgram/BindProgramPipeline subjet. I try to search the spec for additional info and found this example: ## Issue 4: When a non-zero program is passed to UseProgram, any subsequent uniform updates will affect that program, ignoring the active program in any bound pipeline object. For example: glUseProgram(0); glBindProgramPipeline(1); glActiveProgram(1, 2); glUniform1f(0, 3.0); // affects program 2 glUseProgram(3); glUniform1f(0, 3.0); // affects program 3 glUseProgram(0); glUniform1f(0, 3.0); // affects program 2 ### So after glUseProgram(0), the state of the pipeline is restored (or they forgot to update this part of the spec when they clarify the priority rule), at least the ActiveProgram. Anyway, I write an extensive piglit test and check the behavior on fglrx. Here the outcome, glUseProgram(0) destroy current program state, the pipeline need to be rebound again for any shader based rendering. However ActiveProgram is restored as the previous example! Any opinion is welcome, run the test on nvidia? Mimic AMD behavior? Cheers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Status of GL_ARB_separate_shader_objects? I would like to help.
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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of GL_ARB_separate_shader_objects? I would like to help.
On Fri, Mar 22, 2013 at 1:00 PM, gregory hainaut gregory.hain...@gmail.com wrote: * 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. This is a weird part of the spec. After glGen* (but before glBind*) the associated glIs* function usually returns false. It's something that no one but conformance tests seem to care about. See commit fd93d55141f11069fb76a9b377ad1af88d0ecdd3 (in Mesa) for how to fix this kind of thing. I said usually above because there is some inconsistency. The ARB_sampler_objects spec says that the act of calling glIsSampler() actually creates the object. It looks like for ARB_separate_shader_objects that glGen* followed by glIs* should return false (like VAOs). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
