<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-GB link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I’ve been thinking about something similar for a while,
and am toying with the idea of building the rendering pipeline as a typed
expression. It’s all very hand-wavey thoughts at the moment, but I reckon
it’s possible to define a function that describes the pipeline you want
to establish and then ‘compile’ that expression into an executable
object.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>It’s equivalent to defining the graph of the pipeline and
compiling that into an executable sequence.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>They key thing is it separates the definition of what you want
to do (the expression) from the stateful execution. A major bonus is all resource
allocation/deallocations can be extracted late on in the process, which offers
the potential for clever resource usage strategies. Increased efficiency is
actually why I’m interested in pursuing it. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Not a small amount of work though. Any thoughts?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Ta,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Sam<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> hopengl-bounces@haskell.org
[mailto:hopengl-bounces@haskell.org] <b>On Behalf Of </b>Conal Elliott<br>
<b>Sent:</b> 21 July 2009 17:15<br>
<b>To:</b> hopengl@haskell.org; minh thu<br>
<b>Subject:</b> Re: [HOpenGL] Pure, garbage-collected graphics resources<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal>Thanks for these comments<br>
<o:p></o:p></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-right:0cm'>
<p class=MsoNormal>Anyway, I've not a clear picture of what you have in mind
(especially,<br>
at which point in time a, say, VBO should be considered to be part of<br>
things to be rendered). Often, a data structure (say Blah) is created<br>
in a pure way then given to some kind of run :: Blah -> IO () function<br>
for "interpretation". Why not mirror the OpenGL API in a purely<br>
data-centric way then give the data to the run function ?<o:p></o:p></p>
</blockquote>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
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').<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
- Conal<br>
<br>
[1] <a
href="http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-Weak.html#v%3AaddFinalizer">http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-Weak.html#v%3AaddFinalizer</a><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal>On Tue, Jul 21, 2009 at 4:30 AM, minh thu <<a
href="mailto:noteed@gmail.com" target="_blank">noteed@gmail.com</a>> wrote:<o:p></o:p></p>
<p class=MsoNormal>2009/7/21 Conal Elliott <<a href="mailto:conal@conal.net"
target="_blank">conal@conal.net</a>>:<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'>> I'd like to use some
OpenGL resources (VBOs, textures, shaders, and shader<br>
> programs) in a functional way, with immutability, garbage collection, and<br>
> IO-free creation interfaces. Has anyone played with doing such a
thing? I<br>
> guess the GC part would involve foreign pointers with foreign finalizers<br>
> (which now run promptly in GHC iiuc). I don't know of any reliable
way to<br>
> add finalizers to Ptr values, because of the unboxing problem [1].<br>
><br>
> One tricky issue is that graphics context initialization must take place<br>
> before any of these "pure" resources get evaluated. If the
APIs allowed<br>
> access to to multiple graphics contexts, things would get stickier.<br>
><br>
> Comments?<o:p></o:p></p>
</div>
<p class=MsoNormal>Hi,<br>
<br>
I wanted to point you to a paper (Stretching the storage manager: weak<br>
pointers and stable names in Haskell) but see you're one of the<br>
authors.<br>
<br>
As you say, there is the notion of context. I guess you can create the<br>
context with something explicitely in IO, like<br>
<br>
createContext :: IO Context<br>
<br>
then implementing the "pure" resources as data structure referencing<br>
the context.<br>
<br>
Anyway, I've not a clear picture of what you have in mind (especially,<br>
at which point in time a, say, VBO should be considered to be part of<br>
things to be rendered). Often, a data structure (say Blah) is created<br>
in a pure way then given to some kind of run :: Blah -> IO () function<br>
for "interpretation". Why not mirror the OpenGL API in a purely<br>
data-centric way then give the data to the run function ?<br>
<br>
Although the OpenGL C API is imperative, it maps fairly well to a<br>
data-centric approach.<o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>