Implementing a shader API

Fri Mar 26 15:34:58 UTC 2021

Let's keep the discussion in the openjfx-discuss at openjdk.java.net list for
now. I'm sending this mail on the dev list just for continuity.

I'm also very clueless as to how JavaFX links D3D shaders at runtime. Can
> someone give me a quick rundown on that?
>

The D3D shader pointers are in D3DPhongShader.h. There is 1 vertex shader
and several pixel shaders that account for different illumination modes for
performance reasons, and these are swapped at runtime in D3DMeshView.cc
whenever a render is requested.
In this class, the vertex shader is set
with IDirect3DDevice9::SetVertexShader, taking
in D3DPhongShader::getVertexShader. The pixel shader is set
with D3DPhongShader::setPixelShader, taking in the illumination mode
parameters and retrieving the appropriate shader. It is then set with
IDirect3DDevice9::SetPixelShader.

Regarding the shader API, if an error occurs during shader compilation,
> should it simply default to the basic Phong shaders or throw an Exception
> (likely in a new package with other shader stuff)?
>

If you are talking about a new API, then this is too detailed to figure out
at this point. We need to step back and figure out how to have things
working with each other before figuring out what to do on invalid input.

On Fri, Mar 26, 2021 at 5:58 PM Jacky Guo <jackyguo579 at gmail.com> wrote:

> Regarding the shader API, if an error occurs during shader compilation,
> should it simply default to the basic Phong shaders or throw an Exception
> (likely in a new package with other shader stuff)?
>
> I'm also very clueless as to how JavaFX links D3D shaders at runtime. Can
> someone give me a quick rundown on that?
>
> On Wed, Mar 17, 2021 at 9:06 PM Dan Howard <sproket at videotron.ca> wrote:
>
>> This is cool. You should like up with Almas Baimagambetov
>>
>>
>> https://github.com/AlmasB
>>
>>
>> On 3/15/2021 10:12 PM, Jacky Guo wrote:
>> > Regarding uniform parameters (i.e. variables set from Java and called on
>> > the shader):
>> > Since OpenGL's data passing uses locations, you could simply store a
>> map of
>> > uniform parameters (or whatever their JSL equivalent is) to their
>> > locations, and call the required methods and perform the necessary
>> > type-safety checks.
>> > For D3D, you would still use the parameter map, but only for type
>> safety.
>> >
>> > This is assuming I understand how the APIs work and I am not overlooking
>> > something crucial.
>> >
>> > On Mon, Mar 15, 2021 at 4:51 AM Nir Lisker <nlisker at gmail.com> wrote:
>> >
>> >> I've thought about this too for a bit. My question would be how to tell
>> >> the CPU what data to pass to the shader. Take OpenGL for example:
>> writing
>> >> an API to pass a shader and compiling it in runtime is not hard, but
>> you
>> >> need the CPU side to feed the shader its parameters. You would need an
>> API
>> >> for arbitrary data that the shader has been preconfigured to handle.
>> That's
>> >> quite an undertaking.
>> >> And what level of flexibility is this going to give? The shader might
>> >> require data that the public Java API does not expose, so you are
>> limited
>> >> in that regard too. When I wrote the enhancements for the shaders, I
>> also
>> >> had to change the Java side, which you won't be able to do.
>> >> On the D3D side, the shaders are precompiled, so it's a slightly
>> different
>> >> story.
>> >>
>> >>    - Can high school students sign the OCA? (I saw the job title field
>> >>> on the form and wasn't so sure I was legally allowed to sign it)
>> >>
>> >> Maybe ask on adoption-discuss at openjdk.java.net.
>> >>
>> >> On Mon, Mar 15, 2021 at 1:50 AM Michael Ennen <mike.ennen at gmail.com>
>> >> wrote:
>> >>
>> >>> I messed around with adding features to JavaFX's "JSLC" (Java Shader
>> >>> Language Compiler) which currently is only used
>> >>> at compile-time for JavaFX to convert "JSL" shaders to various
>> platform
>> >>> dependent shader languages (GLSL, HLSL, etc.).
>> >>>
>> >>> In my opinion the ideal way to implement a public shader API would be
>> to
>> >>> extend JSLC to be able to be used either
>> >>> at user application compile time, or more ideally, at application
>> run-time
>> >>> to dynamically generate platform dependent shaders
>> >>> depending on what platform JavaFX is running on. Then a JavaFX
>> application
>> >>> developer can write platform independent
>> >>> shaders in JSL. This would be quite a large undertaking and have a
>> high
>> >>> burden of maintenance to keep it current with
>> >>> fast moving shader languages.
>> >>>
>> >>> I was able to convert JSLC grammar to antlr4 (from the previous antlr3
>> >>> version) in this merged commit (pre-dates the move
>> >>> to Github):
>> >>>
>> >>>
>> >>>
>> https://github.com/openjdk/jfx/commit/52adea7c3635656421db766641416ff28213928f#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7
>> >>>
>> >>> I then took advantage of a new feature in antlr4 which allows for
>> >>> extracting embedded actions from the grammar definition file to a
>> visitor
>> >>> class:
>> >>>
>> >>>
>> >>>
>> https://github.com/openjdk/jfx/commit/8889330cc30a47361d47519be2ec662fb5ebe856#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7
>> >>>
>> >>> I then, in a test repository did some work in fleshing out what it
>> would
>> >>> take to implement more features for JSLC which you can find (as messy
>> >>> commits) here:
>> >>>
>> >>> https://github.com/brcolow/jslc
>> >>>
>> >>> That's just my two cents on how a public shader API should best be
>> added
>> >>> to
>> >>> JavaFX, by building on previous work that exists in the source code
>> >>> repository but is only
>> >>> used in a very limited and small way - but there is much potential
>> there
>> >>> and I believe the original author of JSL's intent was to have it be a
>> >>> public API feature to allow
>> >>> JavaFX developers to write platform independent shaders in JSL.
>> >>>
>> >>>
>> >>> On Sun, Mar 14, 2021 at 3:32 PM superminerJG <jackyguo579 at gmail.com>
>> >>> wrote:
>> >>>
>> >>>> Hi everyone.
>> >>>>
>> >>>> This problem might have been discussed numerous times, and has been
>> held
>> >>>> off for quite a while.
>> >>>>
>> >>>> Although we are starting to see lighting improvements added to
>> JavaFX, I
>> >>>> feel that it's necessary for JavaFX to have some kind of custom
>> shader
>> >>>> pipeline. However, nobody has gotten around to doing it, so I thought
>> >>> that
>> >>>> I could lend a hand. Before I get into things, I would like to know
>> how
>> >>> and
>> >>>> what I can contribute. The questions are at the bottom of the email.
>> >>>>
>> >>>> Thanks!
>> >>>> - jgcodes
>> >>>>
>> >>>> Questions:
>> >>>>
>> >>>>     - Can high school students sign the OCA? (I saw the job title
>> field
>> >>> on
>> >>>>     the form and wasn't so sure I was legally allowed to sign it)
>> >>>>     - When I  implement the shader API, should it use some kind of
>> GLSL
>> >>>>     mapping, or should I try to extend JSL to work in 3D?
>> >>>>     - Should I have sent this email to another mailing list?
>> >>>>
>> >>>
>> >>> --
>> >>> Michael Ennen
>> >>>
>>
>