[HOpenGL] Pure, garbage-collected graphics resources

[Jeff Heard]

Conal, if you figure this out, could you let me know how you did it?
I'm currently pre-allocating all my textures and VBOs, caching them in
an LRU cache, and cycling through them in Hieroglyph.  I'd love to see
them allocated and destroyed lazily and functionally by the garbage
collector and runtime...

-- Jeff

On Tue, Jul 21, 2009 at 12:15 PM, Conal Elliott<conal at conal.net> wrote:
> Thanks for these comments
>
>>
>> Anyway, I've not a clear picture of what you have in mind (especially,
>> at which point in time a, say, VBO should be considered to be part of
>> things to be rendered). Often, a data structure (say Blah) is created
>> in a pure way then given to some kind of run :: Blah -> IO () function
>> for "interpretation". Why not mirror the OpenGL API in a purely
>> data-centric way then give the data to the run function ?
>
> This "data-centric" style (I like that term) is exactly what I like to do in
> all of my libraries, and it's what I'm doing again now.  OpenGL types are
> hidden in the library implementation, and the exposed semantics is
> unaffected by the imperativeness of OpenGL (just as the semantics of Integer
> is unaffected by the imperativeness of 'print').
>
> And then I find myself in an implementation puzzle.  My 'run' function (for
> the purely functional type) involves creating VBOs and textures, which
> greatly accelerate rendering.  I want to *reuse* these resources without
> mutation (i.e. reuse the content, not the memory), which is easy if they're
> wrapped up as functional values that go into my higher-level functional
> values, but tricky if they get created only during 'run'.  Another example
> is shader programs, which I synthesize and then never mutate.
>
> Since I'm using this graphics data in a purely functional way, I want both
> creation and destruction to be handled in a functional way, i.e., lazy
> evaluation and garbage collection, with no visible IO.  I think we can
> finally get there, now that we have dependable prompt execution of C-based
> finalizers.
>
> However, I do not think robust finalization can be added on top of the Ptr
> type, which is used in HOpenGL, because GHC optimizations often drop
> constructors (like Ptr) keeping only the contents, which allows finalizers
> to get called much too soon.  Some examples of this general problem are
> mentioned in the addFinalizer documentation [1].  I think a solution would
> be to replace Ptr with ForeignPtr in HOpenGL.
>
>    - Conal
>
> [1]
> http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-Weak.html#v%3AaddFinalizer
>
>
> On Tue, Jul 21, 2009 at 4:30 AM, minh thu <noteed at gmail.com> wrote:
>>
>> 2009/7/21 Conal Elliott <conal at conal.net>:
>> > I'd like to use some OpenGL resources (VBOs, textures, shaders, and
>> > shader
>> > programs) in a functional way, with immutability, garbage collection,
>> > and
>> > IO-free creation interfaces.  Has anyone played with doing such a thing?
>> >  I
>> > guess the GC part would involve foreign pointers with foreign finalizers
>> > (which now run promptly in GHC iiuc).  I don't know of any reliable way
>> > to
>> > add finalizers to Ptr values, because of the unboxing problem [1].
>> >
>> > One tricky issue is that graphics context initialization must take place
>> > before any of these "pure" resources get evaluated.  If the APIs allowed
>> > access to to multiple graphics contexts, things would get stickier.
>> >
>> > Comments?
>>
>> Hi,
>>
>> I wanted to point you to a paper (Stretching the storage manager: weak
>> pointers and stable names in Haskell) but see you're one of the
>> authors.
>>
>> As you say, there is the notion of context. I guess you can create the
>> context with something explicitely in IO, like
>>
>> createContext :: IO Context
>>
>> then implementing the "pure" resources as data structure referencing
>> the context.
>>
>> Anyway, I've not a clear picture of what you have in mind (especially,
>> at which point in time a, say, VBO should be considered to be part of
>> things to be rendered). Often, a data structure (say Blah) is created
>> in a pure way then given to some kind of run :: Blah -> IO () function
>> for "interpretation". Why not mirror the OpenGL API in a purely
>> data-centric way then give the data to the run function ?
>>
>> Although the OpenGL C API is imperative, it maps fairly well to a
>> data-centric approach.
>
>
> _______________________________________________
> HOpenGL mailing list
> HOpenGL at haskell.org
> http://www.haskell.org/mailman/listinfo/hopengl
>
>