<div dir="ltr">On 19 September 2013 00:54, Rogovin, Kevin <span dir="ltr"><<a href="mailto:kevin.rogovin@intel.com" target="_blank">kevin.rogovin@intel.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="FI" link="blue" vlink="purple">
<div>
<p class=""><span lang="EN-US">Hello all,<u></u><u></u></span></p>
<p class=""><span lang="EN-US"><u></u> <u></u></span></p>
<p class=""><span lang="EN-US"> I thank all those that have answered my questions, I still have a few more. Here goes.<u></u><u></u></span></p>
<p class=""><span lang="EN-US"><u></u> <u></u></span></p>
<p class=""><span lang="EN-US">I saw that geometry shaders were landed recently in some form. My questions are:<u></u><u></u></span></p>
<p><u></u><span lang="EN-US" style="font-family:Symbol"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span lang="EN-US">What is the execution style of the geometry shader on i965? (i.e. the fragment shader is invoked 8 fragments at a time and the vertex shader is invoked 2 vertices at a time).</span></p>
</div></div></blockquote><div><br></div><div>The geometry shader support that is currently in Mesa for i965 targets gen7. Gen7 hardware supports executing the geometry shader either 2 primitives at a time ("dual object" dispatch) or 1 primitive at a time ("single" dispatch). Currently the Mesa implementation only supports dual object dispatch, since that was easier to implement (it's more similar to vertex shaders). In the long run I hope to also support single dispatch, since that holds the promise of decreased register pressure for complex geometry shaders.</div>
<div><br></div><div>Gen6 geometry shader hardware only supports single dispatch (it also has a number of other nontrivial differences from gen7), so if we want to support geometry shaders on gen6 in the long run, implementing gen7 single dispatch mode will be a good stepping stone towards that.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="FI" link="blue" vlink="purple"><div>
<p><span lang="EN-US">
<u></u><u></u></span></p>
<p><u></u><span lang="EN-US" style="font-family:Symbol"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span lang="EN-US">what is the “geometry shader style” supported? i.e. are input/output blocks supported between stages, can inputs and outputs be declared as just “in type foo” and “out type foo”? Additionally are the layout()
bits specifying the geometry shader input and output supported? Looking at the mesa-dev traffic, I am guessing it is the “older style” where layout is not in place and input and output blocks are not there yet, but I cannot tell.</span></p>
</div></div></blockquote><div>We only support the style of geometry shaders described in GL 3.2 and GLSL 1.50 (the "newer" style). This was a change of plans I made in July. Previously we were planning to implement the style of geometry shaders described in ARB_geometry_shdader4 first, and then later move on the GL 3.2/GLSL 1.50 style. For a discussion of the motivation for changing plans, see <a href="http://lists.freedesktop.org/archives/mesa-dev/2013-July/042102.html">http://lists.freedesktop.org/archives/mesa-dev/2013-July/042102.html</a>.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="FI" link="blue" vlink="purple"><div>
<p><span lang="EN-US"><u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p class=""><span lang="EN-US">I know I was advised to <b>not</b> yet look at the GL dispatch function pointer thing, but I could not help myself; I saw that the functions are specified by .xml files which in turn generates some source code. Is there
any movement to use the .xml registry from Khronons (at </span><a href="https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/" target="_blank"><span lang="EN-US">https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/</span></a><span lang="EN-US">
)? I admit that this won’t add any features really, but was thinking it might take some manual labor out of the function dispatch thing … though it looks like the .xml from Mesa also has an ID field as well(I think to where the function is located in the dispatch
table)… </span></p></div></div></blockquote><div>Eric Anholt and I were talking about that the other day. I am mildly in favor of it, but I don't know if anyone knowledgeable enough about the dispatch mechanism has the time available to tackle the task.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="FI" link="blue" vlink="purple"><div>
<p class=""><span lang="EN-US"><u></u><u></u></span></p>
<p class=""><span lang="EN-US"><u></u> <u></u></span></p>
<p class=""><span lang="EN-US"><u></u> <u></u></span></p>
<p class=""><span lang="EN-US">Last question set and I do not know a good way to go about this. Right now the documentation of Mesa looks like to me to be in the code in comments; this is great when working on one area/zone, but really hard to get
a global picture of Mesa. Given that I am trying to do just that, I think it would be beneficial to produce some text for others to read. And now the icky questions and begging:<u></u><u></u></span></p>
<p><u></u><span lang="EN-US" style="font-family:Symbol"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span lang="EN-US">Given that I am new, my understanding is going to be incorrect at times and so I will need feedback from those that know for corrections. Additionally a feedback of open questions from people who are new (like
me) or who are working in one area only would be useful to make sure the document is useful to more people than just me. However, I feel uneasy posting blobs of text that might be wrong to the mailing list out of fear of later google searches finding it… thoughts?</span></p>
</div></div></blockquote><div>Disclaimer before I start: I suspect I am one of the more gung-ho advocates of documentation in the Mesa community, so my answers here don't necessarily reflect the majority opinion. </div>
<div><br></div><div>Having said that, I think it would be great to have better overview style documentation in Mesa and I would be glad to give feedback. I wouldn't worry so much about posting blobs of text that might be wrong to the mailing list, as long as it happens in the context of a discussion (like has been happening so far with your questions) or a patch review. You seem to be pretty scrupulous about saying "this is what I've gathered from looking at the code, please correct me if I'm wrong" which I think is more than enough to alert web searchers to the fact that they should take what you say with a grain of salt. (Besides, it's the internet--everyone knows it's full of lies :)) Anyway, if your goal is to add documentation to the project, you're going to have to send out patches for public review, because that's how we make progress in Mesa, and your patches will be big blobs of text, so it's kind of inevitable.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="FI" link="blue" vlink="purple">
<div><p><span lang="EN-US"><u></u><u></u></span></p>
<p><u></u><span lang="EN-US" style="font-family:Symbol"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span lang="EN-US">I would like to land this document into the Mesa repo eventually. An important question is what from shall the document take? I am leaning on the idea of doxygen pages and the doxygen files are in src/ so that
when headers/sources get modified in a non-localized way the doxygen files have a hope to be modified too. My worry is that this adds more work to any implementation work or worse: the .doxy files rot anyways and now located in src/ .</span></p>
</div></div></blockquote><div>I'm not aware of any public web servers that serve up the doxygen documentation right now. If you can find one (or set up one, or convince the <a href="http://freedesktop.org">freedesktop.org</a> maintainers to set up one), I would be in favor of putting overview style documentation in doxygen format. Otherwise I think it would be better to add overview style documentation to the existing docs/ directory in html form, because that's what people see if they go to <a href="http://www.mesa3d.org/">http://www.mesa3d.org/</a>.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="FI" link="blue" vlink="purple"><div>
<p><span lang="EN-US"><u></u><u></u></span></p>
<p><u></u><span lang="EN-US" style="font-family:Symbol"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span lang="EN-US">Going further, assuming that this is wanted and it takes the form of .doxygen files, I would like to be adding doxygen group tags to header files so that navigation to modules and module categorization is also
in the sources. Moreover, I want to generate -2- doxygen messes: one for developers to navigate code (i.e. include sources into the doxgen generated html and another which is header only). Tthe goal being that a developer can click through the code quickly
to find where/how Mesa does something.</span></p></div></div></blockquote><div>If we can find or set up a public server serving up the latest doxygen documentation (and that's a big "if"), then I'd be in favor of adding group tags so that module categorization is in the sources. But I don't understand the benefit of having two separate doxygen outputs (one for headers and one for all code). The fact is, the only consumers of the doxygen output are going to be mesa developers and people who are interested in understanding the source code. That argues for one piece of doxygen output that contains all the code. Besides, we currently have zero public doxygen builds of Mesa; I'd far prefer to take the incremental step of changing this to one, and seeing how it goes for a while, rather than jumping to two and risking confusing people.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="FI" link="blue" vlink="purple"><div>
<p><span lang="EN-US"><u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p class=""><span lang="EN-US"><u></u> <u></u></span></p>
<p class=""><span lang="EN-US">and now a confession, I admit that I am mostly only interested in how it all maps down to i965; so…. I am not too sure how the uptake to other drivers or for that matter all of gallium will take place…</span></p>
</div></div></blockquote><div>There's a lot of code in core Mesa that is shared by all drivers. Even if your documentation efforts only wind up affecting i965 code and shared code, they will still benefit everyone. I think the best way to address this is to take the "patches welcome" attitude--if you set up a public doxygen server, and get the documentation into good enough shape that it is useful, either the gallium folks will want to contribute (in which case they can, by updating comments in the gallium code), or they won't (in which case they still will benefit from the doxygen documentation in core Mesa). Either way it's a win.</div>
</div></div></div>