Re: Upstreaming a Vulkan driver with a closed shader backend

On Thu, Jul 30, 2026 at 9:29=E2=80=AFAM 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 hav=
e
> 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 runt=
ime.
>

Mind going into details why it can't? I kinda get if a company doesn't
want to do this out of ecosystem consideration, but none of the GPU
ISAs are considered a secret these days. And I'm sure somebody with
enough spare time could just take your open source tree and write a
backend driver in a week or so, especially if a blob already exists
that translates from nir to machine-code that could get some
automation thrown at it.

So the end result of your plan would be that you publish a mostly open
source driver, that you won't be able to develop upstream and then
somebody from the community or some random person will write a backend
compiler for it and upstreams the entire thing. You lose any potential
influence over the upstream driver you might have gotten, if you'd
upstream right away. I'm sure company policy would forbid you to
contribute to such a driver that has a reverse engineered backend
compiler, and so it's now out of your hands and a driver will be
developed upstream against your hardware alongside your own mesa fork.
At some point some customers of you _might_ prefer using the upstream
driver in products, because it's fully open source and then you'll
have to dedicate some developers to upstream. Company policy might
still prevent you from open sourcing your backend, because it's still
better in some cases, so you can't have that. Meanwhile the upstream
one is good enough for most other purposes. Enough time passes and the
differences are purely theoretical.

5 or 10 years or so later some big hardware manufacturer decides to
sell a gaming console (or something that needs some mobile GPU) with
the upstream driver and it's taking off quite well.. you abandon your
own fork, because as it turns out, having an upstream driver is less
effort and enough products already ship using the upstream one anyway
and it's better to work together on the same thing.

So from this pov you might as well just open source the
NIR-to-machine-code backend and have an upstream driver under your
maintenance. We'll get an upstream driver one way or the other.

Greetings

Karol

> I've read docs/license.rst and docs/submittingpatches.rst. Neither forbid=
s
> this as far as I can tell, but I don't take the silence as permission, an=
d 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 whet=
her
> to aim it at upstream Mesa.
>
> Thanks,
> jingxu zhang