Shader model (desktop or mobile) wasn't really accounted for
in the UI. This means that we will get shaders that look like
duplicates (same variant). In this work, we pass the current
shader model from engine into the frontend and filter out
variants of a different shader model.
Moreover, for matinfo, we use a specific dbg shader model (matinfo)
to indicate it is in that mode. We add UI in matinfo to show the
shadermodel.
So UI updates as well.
Fix 3 bugs wrt matdbg:
1. The numbering scheme for materials with same name was buggy
2. The shared depth variants of the default material should also
show up as active material variants.
3. When two instantiation of FMaterial point to the exact same
bits, we still need to treat them as two materials. (Otherwise
we wouldn't be able to modify one of them in matdbg).
- Ensure that waiting on lock times out so that we don't lock
up a thread when the client is gone.
- Add an experimental folder to matdbg/web/ for the new
UI work.
- Use a hanging-GET approach to reduce dependency on websockets.
- Also add mutex to protect access to MaterialRecords, which is
written to/read from from multiple threads.
The websocket code for parsing the EDIT command is pretty verbose.
Proposing that we move to a HTTP POST request instead.
Also moved the API handler code out of DebugServer.h for clarity.
In most places this is simply replaced by `std::string_view`.
We also change a few internal/private headers so they accept
`std::string_view` instead of `utils::CString`.
There were two places where we were doing unaligned reads: one when
computing the hash for the material identifier, and one when parsing
the chunk in ShaderReplacer.
We also had a potential overflow since civetweb does not add a trailing
null to incoming WebSockets messages.
The JSON response to /api/active became malformed after #4465 because
raw hex strings need to be enclosed by quotes.
This commit changes the variant format in the /api/materials response
to be consistent with one used for /api/active. By using integers
instead of strings, we're avoiding the need to parse integers at run
time.
The JSON error did not appear in the Chrome console because it was being
silenced as a hack to appease "matinfo --web-server". I fix this by
removing the hack and simply emitting a valid response when there's
no live backend.
Also fixed the display of materials, which were always being marked
as active even when they had no active variants.
Previously, if you accidentally had two matdbg tabs open in Chrome, the
web app would hang. This fixes two bugs that prevented multiple
simultaneous clients:
1) The websocket handler broadcasted edit events to only the most
recent connection.
2) The number of server threads was only 2, but the actual web app
requires at least 2 threads for each instance, due to the
externally linked CSS file.
If the websocket message exceeds a certain size, we might receive it
in chunks and civetweb does not auto-consolidate for us.
Fixed this by adding a length prefix to the edit command.
Since we are still on Vulkan 1.0, we cannot use SPIR-V 1.3.
If we try to do so, this error is generated:
Invalid SPIR-V binary version 1.3 for target environment SPIR-V 1.0
In non-optimized builds, we were already generating spirv 1.0, but
when we enabled the shader optimizer, we generated spirv 1.3.
This bug has actually been around forever, but we did not notice because
we were only invoking the optimizer in release builds, which does not
enable validation.
We cannot upgrade Vulkan 1.1 because the latest LunarG SDK for macOS
does not support it.
This performs surgical modification of the IFF chunks rather than
invoking filamat from within matdbg. Low-level direct manipulation
(bypassing optimization passes etc) allows us to diagnose issues with
the shading pipeline.
This CL also adds keystroke bindings to the Monaco editor. You can
press Cmd+S to rebuild the current materials, or use Ctrl+Arrow to
navigate between shader variants and materials.
In a subsequent CL I will add a README that describes how this works in
detail, it will include a list of limitations and a feature wishlist.
matdbg is now linked into the Filament Engine in debug config (allowing
live inspection of GLSL / SPIRV) and into the matinfo tool (to support
the --web-server option).
In both cases, the library spins up a small web server that listens to
http://localhost:8080. You can run any Filament app and attach to it.
The web client caches all material information. This allows the user to
close an atttached Filament app, and the web app will continue to
function properly (useful for crash diagnosis). Moreover the user can
launch a second Filament app and the web client will add its materials
to the existing list (useful when comparing two Filament apps).
For now this only supports inspection, not editing. Some of the material
info such as required attributes is not yet displayed but this will be
easy to flesh out in a subsequent PR.
