Re: Thoughts on shading language

On Mon, Jul 15, 2019 at 8:58 AM Simon Heath <icefox@dreamquest.io> wrote:

> Dear GPU on the Web Community Group,
>
> Hey Simon,


> I'm nobody.  I make indie video games and open source game libraries
> for fun. But this is a public mailing list, so, please allow me to
> bring your attention to this segment of the recent State Of Godot
> presentation at GDC:
>
> https://www.youtube.com/watch?v=C0szslgA8VY&t=2195
>
> It's nice to see developers interested in using WebGPU. They also say that
they want to retarget their Vulkan backend to run on WebGPU which I assume
will be using some Vulkan-Portability on WebGPU library.

Quote: "Apple is fighting with everyone about the shader language used,
> they are acting like little kids, so when they stop quarrelling we will
> probably have WebGPU."
>
> Regardless of the accuracy of this statement, it is a perception I have
> heard before from people who are following the WebGPU development
> process, from the people who are interested enough in writing software
> using this and to be playing with existing implementations even though
> they're not finished.  "Some companies want one kind of language,
> others want a different kind of language, and they're really just
> fighting over vendor lock-in rather than technical advantages."  And
> from my digging into the WebGPU group meeting minutes and Github issues
> a little, it's easy to see how one could form that impression.
>
> This perception is bad.  It makes the web ecosystem look bad.  It makes
> the companies currently slap-fighting each other for market share look
> bad.  And no matter who "wins" it will probably result in a mediocre,
> nasty, compromise solution that makes us all lose.  That's how these
> things generally end, after all.
>
> Saying that discussions around shading language have been difficult is an
understatement, and they sometimes turned into outright flame wars. This
email is great kindling to start a new one so I won't address
vendor-specific complaints.

I don't think the debate around shading language in the group is to achieve
vendor lock-in, after all the result will be a Web spec that will have
conformant implementations in all browsers (and a large test suite to
back-up that conformance claim). Arguments around shading languages are
about technical, philosophical or governance issues, not about "market
share" or "lock-in".


> It will be more complicated for browsers to implement.
>
> So, each vendor's browser team will focus on their preferred portion of
> the standard that they managed to force down everyone's throat, leaving
> other portions unimplemented or poorly implemented.
>
> So, it will have more platform-specific bugs, performance problems and
> feature differences.
>
> A browser won't be able to rightly claim to have WebGPU support if it
doesn't pass the conformance test suite (CTS), this will ensure no feature
goes poorly implemented (performance will be more difficult to harden
though). Like WebGL we'll encourage bug reports and submitting regression
tests to the CTS so the whole ecosystem gets better.

Unfortunately we're talking GPU API here and the drivers we build upon have
varying quality. Implementations will work around known issues but I'm sure
developers using WebGPU will find new driver bugs :/


> So, web developers will have to do more work to try to paper over the
> flaws to make a program that just heckin' works reliably.
>
> We've seen this happen over and over again with different technologies,
> and from the outside it looks exactly like we're seeing it again now.
>
> This is nonsense.  All I want is to make web games that work. So,
> instead of continuing to argue over petty corporate interests in the
> guise of technical merits, allow me to propose a drastic, nay, radical
> change of approach in shader language design:
>
>  1) Ask game and engine developers what sort of tool they want,
>  2) Make that.
>
> Thank you for your insights but I think a problem here is that at step 1)
we might not be able to uniform answer. Also at step 2) you have to
remember that a standard has both users and implementers and you need to
come to a compromise that works for everyone (yes design by committee is
hard and frustrating).


> Sincerely,
> Simon Heath
>
> Cheers,

Corentin