[Mesa-dev] [PATCH] docs: Document spec quoting practices

Paul Berry stereotype441 at gmail.com
Fri Jan 4 16:30:59 PST 2013


On 4 January 2013 16:09, Ian Romanick <idr at freedesktop.org> wrote:

> On 12/19/2012 09:56 PM, Paul Berry wrote:
>
>> On 19 December 2012 15:46, Ian Romanick <idr at freedesktop.org
>> <mailto:idr at freedesktop.org>> wrote:
>>
>>     From: Ian Romanick <ian.d.romanick at intel.com
>>     <mailto:ian.d.romanick at intel.**com <ian.d.romanick at intel.com>>>
>>
>>     Signed-off-by: Ian Romanick <ian.d.romanick at intel.com
>>     <mailto:ian.d.romanick at intel.**com <ian.d.romanick at intel.com>>>
>>     Cc: Paul Berry <stereotype441 at gmail.com
>>     <mailto:stereotype441 at gmail.**com <stereotype441 at gmail.com>>>
>>     Cc: Brian Paul <brianp at vmware.com <mailto:brianp at vmware.com>>
>>
>>     ---
>>       docs/devinfo.html | 42 ++++++++++++++++++++++++++++++**++++++++++++
>>       1 file changed, 42 insertions(+)
>>
>>     diff --git a/docs/devinfo.html b/docs/devinfo.html
>>     index 8f4aeef..eb4c897 100644
>>     --- a/docs/devinfo.html
>>     +++ b/docs/devinfo.html
>>     @@ -155,6 +155,48 @@ of <tt>bool</tt>, <tt>true</tt>, and
>>       src/mesa/state_tracker/st_**glsl_to_tgsi.cpp can serve as examples.
>>       </p>
>>
>>     +<p>
>>     +It is often useful to quote sections from relevant specifications
>> near
>>     +code that implements part of the spec.  In order to make it easier to
>>     +find such quotations in the code (via grep and friends) and to find
>> the
>>     +quoted text in the specifications, please use one of the following
>>     +formats.
>>     +</p>
>>     +
>>     +<p>
>>     +Text quoted from the core OpenGL or OpenGL ES specifications:
>>     +</p>
>>     +
>>     +<pre>
>>     +   /* Page AA (page BB of the PDF) in section C.D.E of the OpenGL F.G
>>     +    * specification says:
>>     +    *
>>     +    *     "Some quoted text from the specificiation"
>>     +    */
>>     +</pre>
>>
>>
>> The OpenGL specs since version 3.2 come in four flavours:
>> - glspecN.core.YYYYMMDD.pdf
>> - glspecN.core.YYYYMMDD.**withchanges.pdf
>> - glspecN.compatibility.**YYYYMMDD.pdf
>> - glspecN.compatibility.**YYYYMMDD.withchanges.pdf
>>
>> Since these four documents don't in general have matching page numbers,
>> I think we should make a recommendation as to which one to quote from.
>> My preference: glspecN.compatibility.**YYYYMMDD.withchanges.pdf, since it
>> contains information about the deltas both from core to compatibility
>> and from one version to the next, so it's the most likely to tip us off
>> to subtle API or version dependencies that we need to be careful about.
>>
>
> Except that we don't implement compatibility profiles. :)


True, we don't, but we do implement legacy features in 3.0 and earlier
contexts.  I've found the compatibility doc to be a more useful reference,
since it mentions the legacy features.


>  I agree that in cases where a profile may be involved, the reference
> should call it out.  You're thinking it should look like:
>
>
>     /* Page AA (page BB of the PDF) in section C.D.E of
>      * glspecN.compatibility.**YYYYMMDD.withchanges.pdf says:
>      *
>
>      *     "Some quoted text from the specificiation"
>      */
>
> That's very specific, but it's also kind of ugly to look at.  Hmm...
>
>
>      +
>>     +<p>
>>     +Text quoted from the GLSL or GLSL ES ES specifications:
>>     +</p>
>>     +
>>     +<pre>
>>     +   /* Page AA (page BB of the PDF) in section C.D.E of the GLSL F.G
>>     +    * specification says:
>>     +    *
>>     +    *     "Some quoted text from the specificiation"
>>     +    */
>>     +</pre>
>>     +
>>     +<p>
>>     +Text quoted from an extension specifications:
>>     +</p>
>>     +
>>     +<pre>
>>     +   /* Section C.D.E of the GL_EXT_foo_bar specification says:
>>     +    *
>>     +    *     "Some quoted text from the specificiation"
>>     +    */
>>     +</pre>
>>
>>
>> My impression is that most extension specs aren't divided into numbered
>> sections like this--instead the sections tend to be labeled things like
>> "Overview", "Issues", or "Additions to Chapter N...".  Since extension
>>
>
> This may be a case of under-specifying what I meant.  In this context, by
> "Section C.D.E" I meant the section of the core spec that the extension
> text modifies.  I may have to think about the right way to say this one a
> bit more...
>
> Right now there is a comment in invalidate_framebuffer_storage (fboject.c)
> that says:
>
>    /* The GL_ARB_invalidate_subdata spec says:
>     *
>     *     "If an attachment is specified that does not exist in the
>     *     framebuffer bound to <target>, it is ignored."
>     *
>     * It also says:
>     *
>     *     "If <attachments> contains COLOR_ATTACHMENTm and m is greater
> than
>     *     or equal to the value of MAX_COLOR_ATTACHMENTS, then the error
>     *     INVALID_OPERATION is generated."
>     *
>     * No mention is made of GL_AUXi being out of range.  Therefore, we
> allow
>     * any enum that can be allowed by the API (OpenGL ES 3.0 has a
> different
>     * set of retrictions).
>     */
>
> I'm proposing that this should instead say:
>
>    /* Section 4.5 of the GL_ARB_invalidate_subdata spec says:
>     *
>     *     "If an attachment is specified that does not exist in the
>     *     framebuffer bound to <target>, it is ignored."
>     *
>     * It also says:
>     *
>     *     "If <attachments> contains COLOR_ATTACHMENTm and m is greater
> than
>     *     or equal to the value of MAX_COLOR_ATTACHMENTS, then the error
>     *     INVALID_OPERATION is generated."
>     *
>     * No mention is made of GL_AUXi being out of range.  Therefore, we
> allow
>     * any enum that can be allowed by the API (OpenGL ES 3.0 has a
> different
>     * set of retrictions).
>     */
>
> Though, after looking at this case and a few other cases, I'm not sure
> there's much value in mentioning the section.  Many of the extension specs
> that I checked only modify a single section in a substantive manner.
>
>
>  specifications are text files, perhaps it would be better to quote by
>> line number?
>>
>
> Quoting by line number seems like it would be annoying.  The extension
> specs are (usually) small enough that searching in the document for the
> text should be good enough to fine-tune the location.
>
>
>        <h2>Marking a commit as a candidate for a stable branch</h2>
>>
>>     --
>>     1.7.11.7
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130104/06d8eab2/attachment-0001.html>


More information about the mesa-dev mailing list