Re: Thoughts on shading language

Hi Corentin,

Thanks for the response!  I didn't expect something so quickly, and I
hope you will pardon me the bit of a delay to try to give this more
thought.

> 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.

Well, from my experience there's two types of game devs interested in
WebGPU, with some overlap: those who say "Woohoo, I get to ditch my
OpenGL backend for Vulkan, now if only I could do that with my WebGL
backend", and those who say "I really wish I could bother with Vulkan,
but it's far more low-level than what I really need, it would be nice
to have a simplified version with fewer sharp edges". WebGPU is
exciting 'cause it seems to be a way to nicely fill both needs.  Though
again, I hang out at the small end of the spectrum; big fish may have
different concerns.

> 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.

Yeah, sorry.  I really, really don't want to kindle a flame war, and I
deeply sympathize with people who have to deal with the same boring
complaints over and over.  So I'm trying to abstract and examine what
the problem looks like instead of get all frothy about specific vendors
or details.  The question is basically "human-readable vs. machine-
readable shading language", and beyond that I'm not concerned about the
implementation details.  The advantages to each have already been
debated, and are already just in their names -- one is easier for
humans, one is easier for machines.  The rest of the matter has already
been implemented, argued about, experimented upon, broken, fixed, and
so on many times in the last few decades, so it seems like the obvious
answer is "you want both, because they're good at different things and
you can turn one into the other".  But nobody seems to be going that
direction, publically at least, and it's confusing.

> 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 :/

If I'm not running into driver bugs that means that whatever I'm
working on isn't ambitious enough.  ;)

>>  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).

As a scientist, "we might not be able to find a uniform answer" is
unsatisfying to me.  And I'm honestly interested in finding out, maybe
something in the style of other community surveys such as  the Rust or
JS yearly community surveys.  Such a thing is way beyond my means
though, so oh well

I will not argue the difficulty of step 2!  Thank you all again for
everyone's hard work.

Regards,
Simon

Received on Thursday, 18 July 2019 02:26:56 UTC