On Mon, 5 Aug 2024 16:02:00 GMT, Lukasz Kostyra <lkost...@openjdk.org> wrote:
> In modern graphics APIs having the knowledge of Shader's name can be > necessary - whether it is because of a different Shader storage/loading > behavior, or to fetch some additional metadata generated upon Shader > precompilation. A good example is shown on development branch for Metal > backend, where [a temporary workaround was > added](https://github.com/openjdk/jfx-sandbox/blob/metal/modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java#L270) > to provide Metal with loaded Shader's name. Metal API uses shaders stored in > a Metal-specific shader library, which makes our "usual ways" of loading > shader code and providing it via an InputStream not possible. > > This change resolves above problem by adding a `pixelShaderName` argument to > `ShaderFactory` interface. Additionally, Glue template for Prism Shaders was > updated to also provide both Shader's name and Shader code to the backend. > Thanks to this change, Prism backends can determine the best course of action > - old backends can ignore newly added `pixelShaderName` parameter and proceed > "as usual", while new backends like Metal can adjust shader loading for their > needs. > > Both D3D and ES2 Prism backends were updated to properly handle these changes. > > NOTE: Because Glue template was changed for Prism stock shaders, it might be > necessary to run a full clean-rebuild sequence to regenerate JSL Shaders and > properly test this change. > > I tested this change on Windows, macOS and Linux, both full test run and by > randomly picking Ensemble8 examples. @arapte Please take a look at this and confirm if those changes will be good for Metal ------------- PR Comment: https://git.openjdk.org/jfx/pull/1530#issuecomment-2269416642
