<div dir="ltr"><div>Hello all,</div><div><br></div><div>I just cleanup a bit and commited code at : <a href="https://gitlab.freedesktop.org/vivekvpandya/mesa/-/commit/d1f29adf926eb44453db1255834575a6f7169d5f">https://gitlab.freedesktop.org/vivekvpandya/mesa/-/commit/d1f29adf926eb44453db1255834575a6f7169d5f</a></div><div><br></div><div>However it is not working as per my expectation (or my expectations are wrong)</div><div><br></div><div>I want to see that driver fail at <a href="https://gitlab.freedesktop.org/vivekvpandya/mesa/-/commit/d1f29adf926eb44453db1255834575a6f7169d5f#54a82819ff146aa01755bf951d797d55a0332a32_0_43">https://gitlab.freedesktop.org/vivekvpandya/mesa/-/commit/d1f29adf926eb44453db1255834575a6f7169d5f#54a82819ff146aa01755bf951d797d55a0332a32_0_43</a></div><div>however in debugger control never reach there.</div><div><br></div><div>I see that in 

<a href="https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e" target="_blank">https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e</a> <br></div><div>
<code>CreateShaderModule</code>() is defined <br></div><div>I am defining 
<code>libresoc_CreateGraphicsPipelines</code>() and I want control to reach here.</div><div><br></div><div>I need to debug more to know what part of code is responsible to call this function. <br></div><div>Just to note I have not done much change in entrypoint generation / extension generation python script so my doubt is that there something I am missing.</div><div><br></div><div>Also when I commented to <a href="https://gitlab.freedesktop.org/vivekvpandya/mesa">https://gitlab.freedesktop.org/vivekvpandya/mesa</a> it seems to be triggered CI/CD, for now I don't want that. Any way to disable CI/CD triggers?<br></div><div><br></div><div>Thanks,</div><div>Vivek<br>


</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 23, 2020 at 6:26 AM apinheiro <<a href="mailto:apinheiro@igalia.com">apinheiro@igalia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <p><br>
    </p>
    <div>On 22/8/20 23:59, Luke Kenneth Casson
      Leighton wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>On Sat, Aug 22, 2020 at 10:34 PM apinheiro <a href="mailto:apinheiro@igalia.com" target="_blank"><apinheiro@igalia.com></a> wrote:

</pre>
      <blockquote type="cite">
        <pre>As Jason mentioned, to get a Vulkan driver started, you would need more
than just one method. If you want a reference:

<a href="https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e" target="_blank">https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e</a>

This commit added the basic skeleton for v3dv (broadcom mesa vulkan
driver).
</pre>
      </blockquote>
      <pre>fantastic this is extremely helpful and much appreciated, thank you.

some background: vivek has kindly agreed to start the NLNet-funded
LibreSOC MESA Vulkan driver.  given that the LibreSOC CPU is a hybrid
CPU/VPU/GPU with an augmented POWER9 ISA (rather than "a totally
separate custom GPU with a foreign ISA completely incompatible with
POWER9"), the first step is actually a general-purpose non-accelerated
*software* Vulkan Driver, very similar to SwiftShader in concept
except:

* utilising NIR in order to take advantage of the 3D shader passes and
the information it can hold
* retaining vector, predication and texturisation intrinsics right up
to the very last second when handing over to LLVM-IR
* relying on "general" LLVM-IR to perform translation for *native*
(host) execution - not a "totally separate custom GPU..."
* initially entirely targetting *host* (native) scalar instructions
[or, if general-purpose LLVM-IR happens to use NEON, SSE etc. that's
great but not our concern]

in other words it should be possible for the LibreSOC Vulkan driver to
run on native non-accelerated CPUs - x86, POWER9, ARM, MIPS and so on.

the second step will be to add custom 3D instructions *to POWER9*, at
which point whilst we hope to retain the ability to still run on
unaccelerated hardware, it is a secondary priority, albeit a very
important one.

as there may be questions "why not start from a different point, why
not use SwiftShader or gallium" and so on, that evaluation took place
here:
<a href="https://bugs.libre-soc.org/show_bug.cgi?id=251" target="_blank">https://bugs.libre-soc.org/show_bug.cgi?id=251</a>

constructive feedback on this approach greatly appreciated:
<a href="https://bugs.libre-soc.org/show_bug.cgi?id=251#c36" target="_blank">https://bugs.libre-soc.org/show_bug.cgi?id=251#c36</a></pre>
    </blockquote>
    <p><br>
    </p>
    <p>Quoting from there:</p>
    <p>>  it should just return some error code as VkResult.</p>
    <p>Not sure why it should return an error code. Even if initially is
      a no-op pipeline, if the method is able to create the object I
      think it is ok to return success, and let errors to be for real
      errors (out of memory, etc). But I guess that's ok if you prefer
      that until it starts to do something real.</p>
    <p>> Test this setup with by forcing
      application to use this driver. Need to figure out way how to
      force it. May be through VK_ICD_FILENAMES.</p>
    <p>Yes you can do that with the
      VK_ICD_FILENAMES envvar.</p>
    <p><br>
    </p>
    <p>> Step3: Once we have above broken
      driver ready we can start enabling code required to process
      "COMPUTE" shaders.</p>
    <p>Any specific reason to start with compute
      shaders? (mostly curiosity).</p></div></blockquote><div>I think compute shaders are the simplest things to get running with much less setup compared to other shader types. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <p>In any case, those steps look good
      enough, although I lack any context of the final target. The only
      thing that I miss is something like "writing the most basic vulkan
      program we can, and get it working with the driver". FWIW, when we
      did that for v3dv, we didn't even rendered anything, we just used
      clear/stores and confirmed that the output was correct. This
      allowed us starting with a basic driver that didn't even need a
      working backend compiler.<br>
    </p>
    <p>BR<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite">
      <pre>with thanks and gratitude,

l.
_______________________________________________
mesa-dev mailing list
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>

</pre>
    </blockquote>
  </div>

</blockquote></div></div>