Re: Upstreaming a Vulkan driver with a closed shader backend

--000000000000ae1e4e0657d55c29
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree with Dave here.  As much as I would love to see Mesa support Huawei
GPUs, depending on an external compiler blob simply isn't a viable solution=
.

~Faith

On Thu, Jul 30, 2026 at 4:54=E2=80=AFAM Dave Airlie <[email protected]> wro=
te:

> Hi,
>
> It's very unlikely we would accept this upstream, just open the ISA,
> your customers will be much happier in the long run.
>
> The main reasons I'd be against this:
>
> It's too asymmetrical - you get more from it than upstream does, and
> it creates an artificial ABI in the middle of the tree. We have enough
> problems with LLVM ABIs and that's open source, to introduce a closed
> source one would be horribly limiting.
> Everyone else who has code upstream has figured it out, as a community
> why would we want to let someone in who can't reach the same barrier
> to entry.
>
> With claude it would take someone who cared a week of tokens to figure
> out your ISA, I'm not sure what secret you'd be hiding.
>
> Dave.
>
>
> On Thu, 30 Jul 2026 at 17:38, jingxu zhang <[email protected]> wrote:
> >
> > Hi,
> >
> > I work at Huawei on the Vulkan driver for an in-house GPU. It's built o=
n
> > Mesa's Vulkan runtime, and we'd like to open source the project, so I
> have
> > some questions about what upstreaming into Mesa would involve.
> >
> > We have one constraint: the GPU ISA can't be published. The Vulkan
> driver and
> > the NIR-level lowering can both be open. The NIR-to-machine-code backen=
d
> > can't, so it would have to ship as a binary that the driver loads at
> runtime.
> >
> > I've read docs/license.rst and docs/submittingpatches.rst. Neither
> forbids
> > this as far as I can tell, but I don't take the silence as permission,
> and I'd
> > like to understand your requirements in more detail.
> >
> > I couldn't find an earlier case of a vendor raising this, accepted or
> > rejected. If it has come up before, a pointer would help.
> >
> > We'll carry on with the open source work either way. The question is
> whether
> > to aim it at upstream Mesa.
> >
> > Thanks,
> > jingxu zhang
>

--000000000000ae1e4e0657d55c29
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I agree with Dave here.=C2=A0 As much as I would love=
 to see Mesa support=C2=A0Huawei GPUs, depending on an external compiler bl=
ob simply isn&#39;t a viable solution.</div><div><br></div><div>~Faith</div=
></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr=
" class=3D"gmail_attr">On Thu, Jul 30, 2026 at 4:54=E2=80=AFAM Dave Airlie =
&lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
It&#39;s very unlikely we would accept this upstream, just open the ISA,<br=
>
your customers will be much happier in the long run.<br>
<br>
The main reasons I&#39;d be against this:<br>
<br>
It&#39;s too asymmetrical - you get more from it than upstream does, and<br=
>
it creates an artificial ABI in the middle of the tree. We have enough<br>
problems with LLVM ABIs and that&#39;s open source, to introduce a closed<b=
r>
source one would be horribly limiting.<br>
Everyone else who has code upstream has figured it out, as a community<br>
why would we want to let someone in who can&#39;t reach the same barrier<br=
>
to entry.<br>
<br>
With claude it would take someone who cared a week of tokens to figure<br>
out your ISA, I&#39;m not sure what secret you&#39;d be hiding.<br>
<br>
Dave.<br>
<br>
<br>
On Thu, 30 Jul 2026 at 17:38, jingxu zhang &lt;<a href=3D"mailto:jxuzhangg@=
gmail.com" target=3D"_blank">[email protected]</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; I work at Huawei on the Vulkan driver for an in-house GPU. It&#39;s bu=
ilt on<br>
&gt; Mesa&#39;s Vulkan runtime, and we&#39;d like to open source the projec=
t, so I have<br>
&gt; some questions about what upstreaming into Mesa would involve.<br>
&gt;<br>
&gt; We have one constraint: the GPU ISA can&#39;t be published. The Vulkan=
 driver and<br>
&gt; the NIR-level lowering can both be open. The NIR-to-machine-code backe=
nd<br>
&gt; can&#39;t, so it would have to ship as a binary that the driver loads =
at runtime.<br>
&gt;<br>
&gt; I&#39;ve read docs/license.rst and docs/submittingpatches.rst. Neither=
 forbids<br>
&gt; this as far as I can tell, but I don&#39;t take the silence as permiss=
ion, and I&#39;d<br>
&gt; like to understand your requirements in more detail.<br>
&gt;<br>
&gt; I couldn&#39;t find an earlier case of a vendor raising this, accepted=
 or<br>
&gt; rejected. If it has come up before, a pointer would help.<br>
&gt;<br>
&gt; We&#39;ll carry on with the open source work either way. The question =
is whether<br>
&gt; to aim it at upstream Mesa.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; jingxu zhang<br>
</blockquote></div>

--000000000000ae1e4e0657d55c29--