The Out of Scope section seems too restrictive

[Kangz]

The scope of work is restricted to the development of a programming interface between the Web Platform and modern 3D graphics and computation capabilities present on native system platforms.

Wouldn't this prevent the CG from working on the test-suite or the ANGLE-like library?

It will not define an implementation of a graphics and computation system.

Applied to a specification, this sentence makes it sound like we will not be able to specify how things like rasterization and the memory model work, and will force us to link to other specification that do. The only other public specifications I know that specify basic graphic operations are the OpenGL and the Vulkan specification.

Instead, we could make it explicit that the output of this working group should not be used to guide the implementation of hardware features. (but allows a software implementation like Swiftshader)

The interface is not intended for use in native system platforms or in GPU libraries.

It is unclear what this applies to, for example the ANGLE-like library is a "GPU library" but should be possible to use during application development. Likewise I hope the CG will be able to do extension request to native APIs to make backends more efficient. In particular I'm thinking about a Vulkan extension that would make descriptor pools less restrictive on having to define the maximum number of each descriptor type at pool creation. Extension requests are not the "interface" but contributions nonetheless.

Again what we don't want is a GPU driver implementing the API on top of the hardware directly so we should restrict the restriction ;-)

[othermaciej]

The list of deliverables should probably include software helpful to the task of implementing and deploying a standard, including:

• A test suite.
• An ANGLE-like library to ease implementations on top of multiple back-ends.

Would the W3C Software License be adequate for these or should it be something else?

Perhaps some of these should be optional deliverables.

Apple would object to an ANGLE-like library being a spec deliverable rather than just a software deliverable. Some of the specific language is due to our desire to not get into putting a new native graphics API through the standards process. We want to focus on standardizing the web-level API.

[othermaciej]

(Given the discussion perhaps this should merge with issue #7 )

[Kangz]

I'd like to discuss this more but need to read up on the W3C structure and delivrables first.

[Kangz]

Apple would object to an ANGLE-like library being a spec deliverable rather than just a software deliverable. Some of the specific language is due to our desire to not get into putting a new native graphics API through the standards process. We want to focus on standardizing the web-level API.

Thanks for your answer. I agree that the specification should be for the Web-level API and was not suggesting that the interface of the ANGLE-like library be specified, but that it's usage outside of browsers be in scope of the specification produced by the CG.

If we are able to make a safe, efficient, and portable API for the Web, it will be a great success, not only for the Web but for graphics in general. Even if its interface is not specified, the ANGLE-like library will be quickly picked up by some native developers as a way to save the engineering time needed to support all 3 explicit graphics APIs. We don't want such users of the ANGLE-like library to have to think about IP concerns. Personally I'm already excited at the prospect of using the final API to make a new renderer for Unvanquished, one of my side projects, and port it to the Web.

That's why it would be good to be more precise and restricted in the "Out of scope" section about what we don't want the specification to be applied to. I suggested making the text single out hardware features and GPU drivers as out of scope, would that address Apple's objections?

[grorg]

It is unclear what this applies to, for example the ANGLE-like library is a "GPU library" but should be possible to use during application development.

As @othermaciej said, some of the wording here can be confusing because Apple wanted it to be clear that the goal is to produce an API for use at the Web platform level. That does not exclude it being taken and translated/ported to another level of API by someone else, under the terms of the W3C copyright and patent policies. Like you, I won't be surprised if this happens. I don't believe the wording rules out an ANGLE-like library, but I'll try to come up with something better than "GPU library".

Again what we don't want is a GPU driver implementing the API on top of the hardware directly so we should restrict the restriction ;-)

Agreed.

That's why it would be good to be more precise and restricted in the "Out of scope" section about what we don't want the specification to be applied to. I suggested making the text single out hardware features and GPU drivers as out of scope, would that address Apple's objections?

I think so. I'll make a proposal and check back here with you and @othermaciej.

As for adding an optional software deliverable - I think this is worth it. If the goal is to provide a library, similar to ANGLE, that is aimed at cross-platform implementations on top of native APIs, and not standardizing the API for that library, then it would be clearly helpful for both the specification and browsers.

I expect that such a project would soon get to a size where the development/management might be better off as a separate project, especially if vendors start relying on it for products, but we can deal with that at the time.

[Kangz]

Thanks for considering my suggestion!

I expect that such a project would soon get to a size where the development/management might be better off as a separate project, especially if vendors start relying on it for products, but we can deal with that at the time.

Agreed.

[Kangz]

I think the commit meant to say "Fixes #7" instead, reopening.

[Kangz]

Opened #10 with a potential fix for this.

[grorg]

#10 is merged. Thanks @Kangz