On Fri, 05 Apr 2013 14:44:54 -0700 Ian Romanick <[email protected]> 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 _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
