<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 17.12.2010 17:54, Marek Olšįk wrote:
    <blockquote
      cite="mid:AANLkTinw2rcKeChVCmm0y6dHb33QezUW3sgcw+q1jFUo@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">On Fri, Dec 17, 2010 at 4:32 PM, Brian
        Paul <span dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:brianp@vmware.com" target="_blank">brianp@vmware.com</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          Christoph,<br>
          <br>
          I don't see a patch for the st/mesa program translation code
          to check<br>
          that we don't exceed the limit.  Were you going to take care
          of that too?<br>
          <br>
        </blockquote>
      </div>
    </blockquote>
    I didn't plan to for now, at least nothing beyond making the state
    tracker return an error if possible, and removing/modifying a
    certain comment mentioned below.<br>
    <br>
    <blockquote
      cite="mid:AANLkTinw2rcKeChVCmm0y6dHb33QezUW3sgcw+q1jFUo@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          I guess we're assuming that the max number of generic inputs
          == max<br>
          number of generic outputs.  I think that's OK until a counter
          case<br>
          appears.<br>
        </blockquote>
        <div><br>
          The way I understand it is that the max number of generic
          outputs is equal to the max number of generic inputs in the
          next shader stage (the same logic applies to some other shader
          caps too). I guess we need to use get_param to determine which
          shader stages are supported by the driver to know which one is
          next. The name </div>
      </div>
    </blockquote>
    The problem is that (apart from the linked GL program case) you
    cannot know which stage is next until validation time.<br>
    You have the same problem with the existing
    PIPE_SHADER_CAP_MAX_INPUTS/OUTPUTS - nv50's vertex shaders can
    output more variables to geometry shaders than they can to vertex
    shaders.<br>
    <br>
    Maybe MAX_GENERIC_INDEX should be a non-shader specific cap - for
    nvc0 the value is the same everywhere, and for hardware that only
    has VP and FP as well.<br>
    <br>
    <blockquote
      cite="mid:AANLkTinw2rcKeChVCmm0y6dHb33QezUW3sgcw+q1jFUo@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div><b>PIPE_SHADER_CAP_MAX_GENERIC_INPUT_INDEX</b> would be
          less ambiguous (still not perfect though).<br>
          <br>
        </div>
      </div>
    </blockquote>
    I thought about using something even more verbose, like
    PIPE_SHADER_CAP_MAX_GENERIC_INPUT_SEMANTIC_INDEX.<br>
    <br>
    <blockquote
      cite="mid:AANLkTinw2rcKeChVCmm0y6dHb33QezUW3sgcw+q1jFUo@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>However I don't believe in usefulness of this new cap, at
          least not without some serious state tracker work. I don't
          consider failing to translate a shader if some CAP is too low
          particularly useful.<br>
          <br>
        </div>
      </div>
    </blockquote>
    The use of the cap is to prevent state tracker writers from thinking
    they're free to use GENERIC[0,96,8911] or whatever random numbers
    they like and rely on pipe drivers to ensure at all costs that
    linkage will be correct.<br>
    <br>
    In mesa/st I see the comment<br>
    /* Actually, let's try and zero-base this just for<br>
     * readability of the generated TGSI.<br>
     */<br>
    So I guess someone thought it would be ok to start at some
    unspecified high index. Such random behaviour makes it really hard
    to get ARB_separate_shader_objects features (which galliums assumed
    pipe drivers would be able to do anyway from the start) sanely.<br>
    <br>
    ---<br>
    <br>
    So, maybe we can do without this cap. Maybe it would be better to
    just mandate that the GENERIC index be less than
    PIPE_SHADER_CAP_MAX_INPUTS/OUTPUTS after all.<br>
    <br>
    Christoph<br>
    <br>
    <blockquote
      cite="mid:AANLkTinw2rcKeChVCmm0y6dHb33QezUW3sgcw+q1jFUo@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>(posting to mesa-dev as well)<br>
          <br>
          Marek<br>
          <br>
        </div>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <font color="#888888"><br>
            -Brian<br>
          </font>
          <div>
            <div><br>
              <br>
              On 12/17/2010 05:28 AM, Keith Whitwell wrote:<br>
              &gt; Christoph,<br>
              &gt;<br>
              &gt; This looks good.  Thanks for bringing this back to
              life.<br>
              &gt;<br>
              &gt; Keith<br>
              &gt;<br>
              &gt; On Thu, 2010-12-16 at 07:47 -0800, Christoph Bumiller
              wrote:<br>
              &gt;&gt; On 12/14/2010 12:36 PM, Keith Whitwell wrote:<br>
              &gt;&gt;&gt; On Mon, 2010-12-13 at 12:01 -0800, Christoph
              Bumiller wrote:<br>
              &gt;&gt;&gt;&gt; I want to warm this up again adding nvc0
              and<br>
              &gt;&gt;&gt;&gt; GL_ARB_separate_shader_objects to the
              picture.<br>
              &gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt; The latter extends
              GL_EXT_separate_shader_objects to support user<br>
              &gt;&gt;&gt;&gt; defined varyings and guarantees well
              defined behaviour only if<br>
              &gt;&gt;&gt;&gt; - varyings are declared inside the
              gl_PerVertex/gl_PerFragment block the<br>
              &gt;&gt;&gt;&gt; blocks match exactly in name, type,
              qualification, and (most<br>
              &gt;&gt;&gt;&gt; significantly) declaration order.<br>
              &gt;&gt;&gt;&gt; - varyings are assigned matching location
              qualifiers:<br>
              &gt;&gt;&gt;&gt; like: layout(location = 3) in vec4 normal<br>
              &gt;&gt;&gt;&gt; "The number of input locations available
              to a shader is limited."<br>
              &gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt; So, I propose to (loosely) identify
              GENERIC semantic indices with these<br>
              &gt;&gt;&gt;&gt; location qualifiers and let the pipe
              driver set a limit on the allowed<br>
              &gt;&gt;&gt;&gt; maximum (e.g PIPE_SHADER_CAP_MAX_INPUTS,
              and not demand to at least<br>
              &gt;&gt;&gt;&gt; support 219 of them - nvc0 offsers 0x200
              bytes for generic inputs/outputs).<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;&gt; This sounds fine actually.  We kicked this
              around before&amp;  I was<br>
              &gt;&gt;&gt; basically ok with the last iteration of the
              proposal, but this seems ok<br>
              &gt;&gt;&gt; too.<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;&gt; As far as I can tell from a gallium
              perspective you're really just<br>
              &gt;&gt;&gt; proposing a new pipe cap _MAX_INPUTS
              (actually _MAX_GENERIC_INDEX would<br>
              &gt;&gt;&gt; be clearer), which the state tracker
              thereafter has to respect?<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;&gt; That would be fine with me.<br>
              &gt;&gt; First attempt at a patch introducing such a cap
              attached.<br>
              &gt;&gt;<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt; My motivation is mostly that the hardware
              routing table for shader<br>
              &gt;&gt;&gt;&gt; varyings that was present on nv50 has
              been removed with nvc0 (Fermi).<br>
              &gt;&gt;&gt;&gt; And I'm glad, because filling 4 routing
              tables (since we have 5 shader<br>
              &gt;&gt;&gt;&gt; types now) is somewhat annoying. And so
              applying relocations to shaders<br>
              &gt;&gt;&gt;&gt; - it can be done, it's probably not too
              time consuming, but it's just<br>
              &gt;&gt;&gt;&gt; plain *unnecessary* (and thus stupid) for
              OpenGL.<br>
              &gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt; Now about d3d9 ...<br>
              &gt;&gt;&gt;&gt; 1. don't care, I don't see a d3d9 state
              tracker<br>
              &gt;&gt;&gt;&gt; 2. <a moz-do-not-send="true"
href="http://msdn.microsoft.com/en-us/library/bb509647%28v=VS.85%29.aspx"
                target="_blank">http://msdn.microsoft.com/en-us/library/bb509647%28v=VS.85%29.aspx</a><br>
              &gt;&gt;&gt;&gt; says "n is an optional integer between 0
              and the number of resources<br>
              &gt;&gt;&gt;&gt; supported" - what "supported" means here
              isn't clear to me, but, I<br>
              &gt;&gt;&gt;&gt; didn't find any example where someone
              used something OpenGL doesn't have<br>
              &gt;&gt;&gt;&gt; (like COLOR2).<br>
              &gt;&gt;&gt;&gt; 3.<br>
              &gt;&gt;&gt;&gt; <a moz-do-not-send="true"
href="http://msdn.microsoft.com/en-us/library/bb944006%28v=vs.85%29.aspx#Varying_Shader_Inputs_and_Semantics"
                target="_blank">http://msdn.microsoft.com/en-us/library/bb944006%28v=vs.85%29.aspx#Varying_Shader_Inputs_and_Semantics</a><br>
              &gt;&gt;&gt;&gt; says "Input semantics are similar to the
              values in the D3DDECLUSAGE."<br>
              &gt;&gt;&gt;&gt; and<br>
              &gt;&gt;&gt;&gt; DECLUSAGE sounds like you're limited to
              sane values.<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;&gt; I think you're on the right track with (1)...
               It's fairly pointless<br>
              &gt;&gt;&gt; trying to discuss code here which isn't
              public&amp;  I don't think people<br>
              &gt;&gt;&gt; need to be worrying about what may or may not
              be important for code they<br>
              &gt;&gt;&gt; can't see.<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;&gt; I know this idea previously got tied up with
              speculation about what a<br>
              &gt;&gt;&gt; DX9 state tracker might or might not require,
              but in retrospect I wish<br>
              &gt;&gt;&gt; I'd been able to steer conversation away from
              that.<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;&gt; The work on closed components may drive a lot
              of the feature development<br>
              &gt;&gt;&gt; and new interfaces, but there's usually
              enough flexibility that this<br>
              &gt;&gt;&gt; sort of cleanup isn't a big deal.<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;&gt; Keith<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt; Not sure if anyone wants to think about
              this issue at this time (since<br>
              &gt;&gt;&gt;&gt; implementation of
              ARB_separate_shader_objects is probably far in the GL4<br>
              &gt;&gt;&gt;&gt; future), but I'd be happy about any
              comments.<br>
              &gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt; Regards,<br>
              &gt;&gt;&gt;&gt; Christoph<br>
              &gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt; On 04/13/2010 12:55 PM, Luca Barbieri
              wrote:<br>
              &gt;&gt;&gt;&gt;&gt; This patch series is intended to
              resolve the issue of semantic-based shader linkage in
              Gallium.<br>
              &gt;&gt;&gt;&gt;&gt; It can also be found in the
              RFC-gallium-semantics branch.<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; It does not change the current
              Gallium design, but rather formalizes some limitations to
              it, and provides infrastructure to implement this model
              more easily in drivers, along with a full nv30/nv40
              implementation.<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; These limitations are added to allow
              an efficient implementation for both hardware lacking
              special support and hardware having support but also
              special constraints.<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; Note that this does NOT resolve all
              issues, and there are quite a bit left to future
              refinement.<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; In particular, the following issues
              are still open:<br>
              &gt;&gt;&gt;&gt;&gt; 1. COLOR clamping (and floating point
              framebuffers)<br>
              &gt;&gt;&gt;&gt;&gt; 2. A linkage table CSO allowing to
              specify non-identity linkage<br>
              &gt;&gt;&gt;&gt;&gt; 3. BCOLOR/FACE-related issues<br>
              &gt;&gt;&gt;&gt;&gt; 4. Adding a cap to inform the state
              tracker that more than 219 generic indices are provided<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; This topic was already very
              extensively discussed.<br>
              &gt;&gt;&gt;&gt;&gt; See <a moz-do-not-send="true"
href="http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg10865.html"
                target="_blank">http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg10865.html</a>
              for some early inconclusive discussion around an early
              implementation that modified the GLSL linker (which is NOT
              being proposed here)<br>
              &gt;&gt;&gt;&gt;&gt; See <a moz-do-not-send="true"
href="http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12016.html"
                target="_blank">http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12016.html</a>
              for some more discussion that seemed to mostly reach a
              consensus over the approach proposed here.<br>
              &gt;&gt;&gt;&gt;&gt; See in particular <a
                moz-do-not-send="true"
href="http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12041.html"
                target="_blank">http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12041.html</a>
              .<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; That said, I'm going to try to repeat
              all information here, partially by copy&amp;pasting from
              earlier messages.<br>
              &gt;&gt;&gt;&gt;&gt; This message should probably be
              adapted into gallium/docs if/when this is accepted.<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; Here is the short summary; the long
              rationale follows after it.<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; The proposal here is to add the
              following limitations to Gallium, for the intermediate
              semantics:<br>
              &gt;&gt;&gt;&gt;&gt; 1. TGSI_SEMANTIC_NORMAL is removed,
              using a commit by Michal Krol that was never merged<br>
              &gt;&gt;&gt;&gt;&gt; 2. Every semantic except GENERIC,
              COLOR and BCOLOR can only be used with semantic index 0<br>
              &gt;&gt;&gt;&gt;&gt; 3. COLOR and BCOLOR can only be used
              with semantic index 0-1 (note that this doesn't apply to
              fragment outputs)<br>
              &gt;&gt;&gt;&gt;&gt; 4. GENERIC can be used with semantic
              indices 0-218 on any driver, if BCOLOR is not used<br>
              &gt;&gt;&gt;&gt;&gt; 5. GENERIC can be used with semantic
              indices 0-216 on any driver, if BCOLOR IS used<br>
              &gt;&gt;&gt;&gt;&gt; 6. GENERIC can be used with semantic
              indices 0-255 on almost all drivers (those that don't need
              the 0-218 limitation)<br>
              &gt;&gt;&gt;&gt;&gt; 7. Some drivers may also choose to
              support GENERIC with arbitrary indices, but that should
              generally not happen<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; The reason of this, in short, is that
              this maps directly to DirectX 9 SM3, which is the most
              problematic interface of all.<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; The peculiar problem we have here is
              that we have two competing constraints that force us into
              choosing the exact SM3 value:<br>
              &gt;&gt;&gt;&gt;&gt; 1. The VMware SVGA driver must deal
              with an SM3 host interface and would ideally want to
              directly feed the Gallium semantics to the host<br>
              &gt;&gt;&gt;&gt;&gt; 2. An hypotetical DirectX 9 state
              tracker needs to support SM3 and would ideally want to
              directly feed the SM3 semantics to Gallium<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; Note that this is not a reference to
              the VMware DirectX 9 state tracker, since its authors
              haven't provided details about its handling of shader
              semantics.<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; SM3 ends up supporting 219 generic
              indices: 16 indices in 14 classes, minus POSITION0,
              PSIZE0, COLOR0, COLOR1 and FOG0 which are the only ones
              that wouldn't be mapped to GENERIC.<br>
              &gt;&gt;&gt;&gt;&gt; However, Gallium drivers that don't
              benefit from having specific contraints (like svga and
              r600) are supposed to support 256 indices, and my
              nv30/nv40 work does that.<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; The expected implementation, if no
              hardware support exists, is to build a list of relocations
              to apply to either the fragment or the vertex shader, and
              patch one of them at validation time to match the other.<br>
              &gt;&gt;&gt;&gt;&gt; Data structures are provided in
              gallium/auxiliary to ease this, and try to minimize the
              number of times where this needs to be performed.<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; Let's now proceed to the discussion
              and detailed rationale, mostly constructed by
              copy&amp;pasting older messages.<br>
              &gt;&gt;&gt;&gt;&gt; ...<br>
              &gt;<br>
              &gt;<br>
              &gt;<br>
              &gt;
------------------------------------------------------------------------------<br>
              &gt; Lotusphere 2011<br>
              &gt; Register now for Lotusphere 2011 and learn how<br>
              &gt; to connect the dots, take your collaborative
              environment<br>
              &gt; to the next level, and enter the era of Social
              Business.<br>
              &gt; <a moz-do-not-send="true"
                href="http://p.sf.net/sfu/lotusphere-d2d"
                target="_blank">http://p.sf.net/sfu/lotusphere-d2d</a><br>
              &gt; _______________________________________________<br>
              &gt; Mesa3d-dev mailing list<br>
              &gt; <a moz-do-not-send="true"
                href="mailto:Mesa3d-dev@lists.sourceforge.net"
                target="_blank">Mesa3d-dev@lists.sourceforge.net</a><br>
              &gt; <a moz-do-not-send="true"
                href="https://lists.sourceforge.net/lists/listinfo/mesa3d-dev"
                target="_blank">https://lists.sourceforge.net/lists/listinfo/mesa3d-dev</a><br>
              &gt; .<br>
              &gt;<br>
              <br>
              <br>
------------------------------------------------------------------------------<br>
              Lotusphere 2011<br>
              Register now for Lotusphere 2011 and learn how<br>
              to connect the dots, take your collaborative environment<br>
              to the next level, and enter the era of Social Business.<br>
              <a moz-do-not-send="true"
                href="http://p.sf.net/sfu/lotusphere-d2d"
                target="_blank">http://p.sf.net/sfu/lotusphere-d2d</a><br>
              _______________________________________________<br>
              Mesa3d-dev mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:Mesa3d-dev@lists.sourceforge.net"
                target="_blank">Mesa3d-dev@lists.sourceforge.net</a><br>
              <a moz-do-not-send="true"
                href="https://lists.sourceforge.net/lists/listinfo/mesa3d-dev"
                target="_blank">https://lists.sourceforge.net/lists/listinfo/mesa3d-dev</a><br>
            </div>
          </div>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
  </body>
</html>