<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I see the point.</p>
    <p>I was thinking about using a small, simplified, reliable fixed
      set of basic GPU functions which are always supported, and call
      them from time to time to speed up some mass operations such as
      texture scaling (instead of MMXing big textures on CPU, call
      existing OpenGL driver and free the CPU for different operations
      while GPU scales them). But it DOES involve lots of data exchange,
      at least unless embedded GPU core can process them in the common
      memory space).</p>
    <p> So I see the point, the data exchange can "eat" all this profit.</p>
    <p><br>
    </p>
    <p></p>
    <div class="moz-cite-prefix">On 22.11.2022 14:06, Jose Fonseca
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:BY3PR05MB8161B0D63001E816A1D5E580B60D9@BY3PR05MB8161.namprd05.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
      <div style="font-family: Calibri, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255,
        255, 255);" class="elementToProof">
        Trying to combine two OpenGL implementations it's technically
        difficult.  Furthermore one might thing combining two
        implementations gives the best of both, but easily gives the
        worst of both worlds, because there's overhead moving data
        between them.</div>
      <div style="font-family: Calibri, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255,
        255, 255);" class="elementToProof">
        <br>
      </div>
      <div style="font-family: Calibri, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255,
        255, 255);" class="elementToProof">
        Image the worst case scenario: draw on driver A, copy data to
        driver B, draw on driver B, copy data to driver A.  One might
        devise a heuristic to avoid switching so often, but the end
        result would end being the bulk of the rendering beind done on
        the most capable drvier (llvmpipe in this case), so not much
        better than always using llvmpipe.</div>
      <div style="font-family: Calibri, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255,
        255, 255);" class="elementToProof">
        <br>
      </div>
      <div style="font-family: Calibri, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255,
        255, 255);" class="elementToProof">
        <br>
      </div>
      <div style="font-family: Calibri, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255,
        255, 255);" class="elementToProof">
        <span style="color: rgb(0, 0, 0); font-family: Calibri,
          Helvetica, sans-serif; font-size: 12pt;">This is why
          technologies like NVIDIA SLI which divide the work across
          multiple identical GPUs tend to split the work in a granular
          fashion, like whole frames (GPU 1 draws frame 2*N, GPU 2 draws
          frame 2*N + 1).</span><br>
      </div>
      <div style="font-family:Calibri,Helvetica,sans-serif;
        font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
        <br>
      </div>
      <div style="font-family:Calibri,Helvetica,sans-serif;
        font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
        <span style="font-size:12pt;margin:0px;background-color:rgb(255,
          255, 255)" class="ContentPasted0">Furthermore, mixing
          different implementations easily leads to artifacts, like
          depth fighting, overlapped geometry or gaps between, because
          3D APIs specification have somewhat  lax rules about
          rasterization, and float conversion.</span><br
          class="ContentPasted0">
      </div>
      <div style="font-family:Calibri,Helvetica,sans-serif;
        font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
        <span style="font-size:12pt;margin:0px;background-color:rgb(255,
          255, 255)" class="ContentPasted0"><br>
        </span></div>
      <div style="font-family:Calibri,Helvetica,sans-serif;
        font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
        <span style="font-size:12pt;margin:0px;background-color:rgb(255,
          255, 255)" class="ContentPasted0">Honestly, it's more
          effective to buy a more modern device.</span></div>
      <div style="font-family:Calibri,Helvetica,sans-serif;
        font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
        <br>
      </div>
      <div style="font-family:Calibri,Helvetica,sans-serif;
        font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
        Jose</div>
      <div style="font-family:Calibri,Helvetica,sans-serif;
        font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
        <span style="font-size:12pt;margin:0px;background-color:rgb(255,
          255, 255)"></span><br>
      </div>
      <div style="font-family:Calibri,Helvetica,sans-serif;
        font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
        <br>
      </div>
      <hr tabindex="-1" style="display:inline-block; width:98%">
      <div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
          face="Calibri, sans-serif" color="#000000"><b>From:</b>
          mesa-dev <a class="moz-txt-link-rfc2396E" href="mailto:mesa-dev-bounces@lists.freedesktop.org"><mesa-dev-bounces@lists.freedesktop.org></a> on
          behalf of <a class="moz-txt-link-abbreviated" href="mailto:test@profit-grand.ru">test@profit-grand.ru</a> <a class="moz-txt-link-rfc2396E" href="mailto:test@profit-grand.ru"><test@profit-grand.ru></a><br>
          <b>Sent:</b> Tuesday, November 15, 2022 12:48<br>
          <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a>
          <a class="moz-txt-link-rfc2396E" href="mailto:mesa-dev@lists.freedesktop.org"><mesa-dev@lists.freedesktop.org></a><br>
          <b>Subject:</b> LLVM-pipe: most powerful instructions set ;)</font>
        <div> </div>
      </div>
      <div class="BodyFragment"><font size="2"><span
            style="font-size:11pt">
            <div class="PlainText">!! External Email<br>
              <br>
              First, thanks for saving my day. Software renderer works
              way faster than<br>
              no renderer at all :)<br>
              <br>
              But there are an "instruction set" which is way faster
              than the MMX or<br>
              SSE sets: it's an existing OpenGL 2.0 driver which is not
              sufficient in<br>
              most cases, because at least 3.0 is required nowadays.<br>
              <br>
              Of course, it's not literally an instruction set, but a
              source of<br>
              additional computing power for basic operations (assuming
              advanced<br>
              operations are not supported by the GPU, making LLVM-pipe
              necessary for<br>
              such systems).<br>
              <br>
              So, the actual question is:<br>
              <br>
              Can LLVM-pipe somehow support (today or in future
              versions) a "bridge<br>
              mode", relying on a different OpenGL driver for basic
              operations<br>
              (supported by some ancient GPU) and closing a gap between
              that driver<br>
              and the required OpenGL version it's usual way, by the
              state-of-art<br>
              software renderer?<br>
              <br>
              It's also somewhat related to my OGLOED driver idea (see
              my Github), the<br>
              difference is "bridge mode" is local, OGLOED is not. But
              there are some<br>
              diagrams which can help understanding my question :)<br>
              <br>
              <br>
              !! External Email: This email originated from outside of
              the organization. Do not click links or open attachments
              unless you recognize the sender.<br>
            </div>
          </span></font></div>
    </blockquote>
  </body>
</html>