W3C home > Mailing lists > Public > public-gpu@w3.org > August 2019

Re: Extension support: maybe not a binary yes/no

From: Ken Russell <kbr@google.com>
Date: Thu, 15 Aug 2019 15:35:50 -0700
Message-ID: <CAMYvS2fWCKNZhJ3=vOcKxN2JXYTNcdAzbTgdR8Q0rnOADNxJWg@mail.gmail.com>
To: "Jasper St. Pierre" <jstpierre@mecheye.net>
Cc: "Myles C. Maxfield" <mmaxfield@apple.com>, Kevin Rogovin <kevinrogovin@invisionapp.com>, public-gpu <public-gpu@w3.org>
For historical context, the WebGL working group's approach has been to
specify as much undefined behavior as possible, and to write
conformance tests to cover all behavioral differences seen across browsers,
OSs and GPUs. Partnerships with GPU vendors helped get hundreds of driver
bugs identified and fixed. (Jasper, if you've encountered bugs in the core
WebGL API or extensions, please file them
<https://github.com/KhronosGroup/WebGL>.)

To keep WebGPU a tractable development target, its functionality and
extensions should be well specified and tested. There doesn't seem a good
reason for advertising an extension as "suspicious" or "non-conformant" -
either the browser should work around any driver bugs (and the bugs should
be reported to the associated GPU vendor), or it should blacklist the
extension on the particular GPU.

-Ken


On Wed, Aug 14, 2019 at 8:32 AM Jasper St. Pierre <jstpierre@mecheye.net>
wrote:

> There's plenty of half-working drivers out there -- the functionality is
> there, but not working exactly as expected. In this case, the extension
> still provides helpful functionality, but driver-specific workarounds are
> required. I've encountered plenty of driver-specific issues just through
> WebGL alone, and this is after ANGLE patches quite a few things up. That
> said, I don't see much benefit in a "suspicious" answer. Browsers can't be
> expected to keep its list of "yes" vs. "suspicious" up to date, so
> application code will probably also necessitate the same driver version
> checks to enable the workarounds for both a "yes" and a "suspicious".
>
> On Wed, Aug 14, 2019 at 8:26 AM Myles C. Maxfield <mmaxfield@apple.com>
> wrote:
>
>>
>>
>> On Aug 14, 2019, at 5:53 AM, Kevin Rogovin <kevinrogovin@invisionapp.com>
>> wrote:
>>
>> 
>> Hi,
>>
>>  On the discussion on Github on dual source blending,
>> https://github.com/gpuweb/gpuweb/issues/391, it was brought up that some
>> hardware declared support but it was buggy on some hardware. This led me to
>> a more general thinking on extensions. There are other cases where a driver
>> advertises an extension but it does not work correctly and the only way to
>> know is to either run the test oneself or examine the GPU vendor and driver
>> string (indeed SKIA has some of this). The thought is that a browser could
>> provide information if it considers an extension, though advertised by the
>> driver, it may not work always. So the extension query mechanism would have
>> three different possible results: "yes", "no" or "yes, but the browser is
>> suspicious of the driver's support".
>>
>>
>> An extension that doesn’t work is hardly an extension at all.
>>
>> Under which circumstances would a browser advertise an extension as
>> “suspicious” but not “no?”
>>
>> And, what would you expect an app to do when it encounters a “suspicious”
>> extension?
>>
>> Given that there are so major browsers now (and even fewer web-engines),
>> if a browser says the 3rd option, it can prod IHV's to fix the issue, since
>> small ISV's have much smaller impact (and will need to implement
>> work-arounds as well).
>>
>> Comments?
>>
>>  -Kevin
>>
>>
>
> --
>   Jasper
>
Received on Thursday, 15 August 2019 22:36:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:26 UTC