Initial groundwork in creating WebGPU backend components, namely
the instance, adapter, device, and queue.
If configured to do so, the backend will print out details about
these components.
The samples/hellotriangle.cpp was slightly modified to include a
webgpu option which allows for exercising the above, but does not
yet draw anything to the screen/window.
NOTE: This has only been sanity tested with hello triangle
on Mac OS and the Android emulator at this time, NOT IOS,
Windows, or Linux yet.
This change does three main things. First, it adds an option to the Engine
Builder to pick the feature level at which to instantiate Filament. The only
real practical purpose of allowing this is to be able to instantiate at feature
level 0. Secondly, it allows feature level 0 to properly work on non-ES2
devices. Thirdly, it changes both Android and desktop hellotriangle samples to
explicitly opt-in to feature level 0.
Unfortunately, feature levels are used in two different, somewhat contradictory
ways presently in Filament, which can make reasoning about this change a bit
confusing. From a client perspective, feature levels refer to buckets of
capabilities which are guaranteed to be supported. Internally, there is a
separate "feature level" stored internally at the Driver subclass level which
generally corresponds to the maximum supported feature level, but is also
referenced when activating workarounds for limited devices. For example, Uniform
Buffer Objects are not supported in ES2, however, Filament supports emulating
them such that the client does not need to care at all; a supported feature is a
supported feature. But internally, Filament uses this "Driver" feature level to
determine whether or not a given workaround is needed. There were several cases
where the "active feature level" was being examined in order to activate these
workarounds rather than the "driver feature level", which was incorrect.
Why should non-ES2-only devices want to activate feature level 0? Allowing this
behavior 1. makes feature level 0 more consistent with the behavior of other
feature levels and 2. allows clients a layer of validation that their software
will work on all devices supported by Filament if they explicitly opt into it.
Consistency: Filament guarantees that any given device which supports a given
feature level will also support running on every feature level below, except for
feature level 0. This change removes that exception.
Validation: It's not perfect, and there will likely be bugs and unexpected
differences in behavior between ES2 and non-ES2 devices that crop up in the
future between two devices running on the same feature level. However, it's at
least a basic high level layer of validation that enables more rapid testing
workflows directly via desktop versions of Filament rather than having to fiddle
with something like ANGLE to get perfect GLES 2.0 compliance. Additionally, it
expands options for automated testing (with the same caveats).
This change has been tested on both the desktop and Android versions of
hellotriangle.
* API BREAKAGE: this change aims to fix multi-view support
What has changed:
- View doesn't have a notion of clear color anymore
- View doesn't have a notion of discard flags anymore
- The clear color and color-buffer discard/clear flags are moved to Renderer
- Skybox can now be set to a constant color
- View have a blend-mode
What does is all mean:
"Clearing" (i.e.) setting its background is now handled by Skybox, by
setting a constant color to the Skybox. This should take care of
drawing views side by side.
When a view needs to be drawn on top of another, it's BlendMode needs to
be set to TRANSLUCENT and of course and, generally, it wither won't have
a skybox, or will have one that sets some translucent pixels.
As an optimization, a View with BlendMode::OPAQUE will have its
background cleared with the color specified in Renderer.
If the SwapChain already has some content, it's now possible to set
the Renderer to not discard the content, together with TRANSLUCENT views,
it's possible to draw on top of that content.
It is NOT possible to share depth/stencil buffers between views.
Fixes: #2369, #2372, #2364
* Address reviewers comments.
Note: WebGL is still broken with this PR
