Re: Upstreaming a Vulkan driver with a closed shader backend

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 on
> 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 backend
> 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