[Mesa-dev] More questions from a newbie

[Paul Berry]

On 19 September 2013 00:54, Rogovin, Kevin <kevin.rogovin at intel.com> wrote:

>  Hello all,****
>
> ** **
>
>   I thank all those that have answered my questions, I still have a few
> more. Here goes.****
>
> ** **
>
> I saw that geometry shaders were landed recently in some form. My
> questions are:****
>
> **·         **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).
>

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.

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.


> ****
>
> **·         **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.
>
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
http://lists.freedesktop.org/archives/mesa-dev/2013-July/042102.html.


> ****
>
> ** **
>
> ** **
>
> I know I was advised to *not* 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
> https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ )? 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)…
>
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.


> ****
>
> ** **
>
> ** **
>
> 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:****
>
> **·         **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?
>
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.

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.


> ****
>
> **·         **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/ .
>
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 freedesktop.org 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
http://www.mesa3d.org/.


> ****
>
> **·         **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.
>
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.


> ****
>
> ** **
>
> ** **
>
> 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…
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130919/f83ba245/attachment.html>