[Mesa-dev] [PATCH 00/12] RFC: add support of ARB_separate_shader_object extensions

[gregory hainaut]

On Fri, 05 Apr 2013 14:44:54 -0700
Ian Romanick <idr at freedesktop.org> wrote:

> On 04/05/2013 02:25 PM, gregory wrote:
> > Hello,
> >
> > Please find an implementation of the ARB_separate_shader_objects extensions. I concentrate mostly on the state part of
> > the extensions aka the pipeline object. I think GLSL already compiled program separately anyway.
> >
> > I test my implementation on the test that I send yesterday ago on piglit. All tests are ok but I miss a test for new uniform function.
> > Besides there are still some parts unimplemented:
> > 1/ GLX Protocol: not sure it will be useful, as understand GLX is kinda drepecated
> 
> We don't have any other GLX support for GLSL, so I wouldn't worry about it.
> 
> > 2/ Display list: need to be done or maybe enable the extensions on CORE profile
> 
> I haven't had any requests for the functionality with compatibility 
> profiles.  As far as I can tell, all of the ISVs that want this feature 
> are already shifting to core profiles.
> 
> Maybe Aras can give us one humble ISVs opinion. :)

We can also enable the extension on compatibility profile but without the display list part. Not ideal but better than nothings.
FYI, only glUseProgramStages can be compiled within a display list. All others entry points are executed immediately.

> 
> > Stuff that bug me:
> > 1/ I don't get how to use ralloc_strdup. So I set the ralloc's context to NULL, not sure it is fully correct
> 
> The ralloc memory context is (usually) some other thing allocated by 
> ralloc.  When the context is freed, all of the things allocated using 
> that context will also be freed.  So,
> 
>      a = ralloc_size(NULL, 32);
>      b = ralloc_size(a, 32);
>      ...
>      ralloc_free(a);
> 
> Will free both a and b.
> 
> You can also use ralloc_steal to reparent an allocation.  So,
> 
>      a = ralloc_size(NULL, 32);
>      b = ralloc_size(a, 32);
>      c = ralloc_size(NULL, 32);
> 
>      ralloc_steal(c, b);
> 
>      ralloc_free(a);
> 
> will only cause a to be freed.  b is now in the context of c.
> 
> We use this in the GLSL compiler to, basically, implement a 
> mark-and-sweep garbage collector.  As various parts of the compiler 
> allocate new objects and orphan others, we'll do a ralloc_steal pass to 
> reparent all of the objects that are still connected.  A ralloc_free of 
> the old context will destroy all the objects that are no longer connected.

Thanks very much for the input. I definitely had a memory leak which is now fixed on my tree :)

> 
> > 2/ I implement the feature as a pure mesa state. I don't know if they're any rule to create driver functions. Maybe it
> >     would be better to add CreatePipelineObject/DeletePipelineObject/BindPipeline/UseProgramStages. Opinion is welcome
> >
> > Note: I didn't yet rebase my work on latest mesa. Not sure if it is critical for a preliminary review.
> > Note2: I create the xml manually, don't know if there is any automatic flow.
> >
> > Thanks