'Re: Re: Implementing a shader API'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Re: Implementing a shader API
From:       Eric Bresie <ebresie () gmail ! com>
Date:       2021-03-27 11:22:20
Message-ID: e0b504c4-0e73-4c41-b4bd-b05527a27203 () Erics-iPhone-12-Pro-Max
[Download RAW message or body]

Don't suppose integrating Java OpenGL if not already done would help?

https://jogamp.org/jogl/www/

They are a little dated but there are the OpenGL related JSRs like

JSR 239: JavaTM Binding for the OpenGL Ž ES API
https://www.jcp.org/en/jsr/detail?id=239
I think this was targeted at Java ME mobile platforms

JSR 231: JavaTM Binding for the OpenGL Ž API
https://www.jcp.org/en/jsr/detail?id=231

Or is some updated JSR really needed here?

Eric Bresie
Ebresie@gmail.com (mailto:Ebresie@gmail.com)

> On March 26, 2021 at 10:34:58 AM CDT, Nir Lisker <nlisker@gmail.com \
> (mailto:nlisker@gmail.com)> wrote: Let's keep the discussion in the \
> openjfx-discuss@openjdk.java.net (mailto:openjfx-discuss@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 \
> (http://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@gmail.com \
> (mailto:jackyguo579@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@videotron.ca \
> > (mailto:sproket@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@gmail.com \
> > > > (mailto:nlisker@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@openjdk.java.net \
> > > > > (mailto:adoption-discuss@openjdk.java.net). 
> > > > > On Mon, Mar 15, 2021 at 1:50 AM Michael Ennen <mike.ennen@gmail.com \
> > > > > (mailto:mike.ennen@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@gmail.com \
> > > > > > (mailto:jackyguo579@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
> > > > > > 
> > > 
> > 


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic