Code Monkey home page Code Monkey logo

spirvcrossj's Introduction

spirvcrossj -- JVM bindings for SPIRV-cross and glslang

馃毀馃毀 spirvcrossj is retired now, please use lwjgl's shaderc and SPIRVcross bindings 馃毀馃毀

Maven Central 脗路 Join the chat at https://gitter.im/scenerygraphics/SciView 脗路 Linux/macOS Build Status 脗路 Windows Build status

SPIRV-cross is a nifty library from the Khronos Group to enable GLSL shader reflection and conversion of SPIR-V binaries to different GLSL version.

glslang is the Khronos Group GLSL reference compiler and validator, providing the other direction.

spirvcrossj provides a wrapper for Java and other JVM languages for both of SPIRV-cross and glslang.

Usage

Maven

In the profiles section of your pom.xml, add the following profiles:

<profile>
    <id>spirvcrossj-natives-linux</id>
    <activation>
        <os>
            <family>unix</family>
        </os>
    </activation>
    <properties>
        <spirvcrossj.natives>natives-linux</spirvcrossj.natives>
    </properties>
</profile>
<profile>
    <id>spirvcrossj-natives-macos</id>
    <activation>
        <os>
            <family>mac</family>
        </os>
    </activation>
    <properties>
        <spirvcrossj.natives>natives-macos</spirvcrossj.natives>
    </properties>
</profile>
<profile>
    <id>spirvcrossj-natives-windows</id>
    <activation>
        <os>
            <family>windows</family>
        </os>
    </activation>
    <properties>
        <spirvcrossj.natives>natives-windows</spirvcrossj.natives>
    </properties>
</profile>

In case you are using lwjgl3, you can also use the lwjgl-natives-linux, etc. profiles that are already defined. Replace any usages of spirvcrossj.natives with lwjgl.natives, then.

Finally, add the following dependencies:

<dependency>
    <groupId>graphics.scenery</groupId>
    <artifactId>spirvcrossj</artifactId>
    <version>0.8.0-1.1.106.0</version>
</dependency>

<dependency>
    <groupId>graphics.scenery</groupId>
    <artifactId>spirvcrossj</artifactId>
    <version>${spirvcrossj.version}</version>
    <classifier>${spirvcrossj.natives}</classifier>
    <scope>runtime</scope>
</dependency>

Gradle

First of all, you need to have mavenCentral:

repositories {
    ..
    mavenCentral()
    ..
}

Then, under dependencies section, exploiting the lwjgl native switch:

    dependencies {
        ..
        ext.spirvCrossVersion = "0.8.0-1.1.106"
        compile "graphics.scenery:spirvcrossj:$spirvCrossVersion"
    
        switch (OperatingSystem.current()) {
            case OperatingSystem.WINDOWS:
                ext.lwjglNatives = "natives-windows"
                break
            case OperatingSystem.LINUX:
                ext.lwjglNatives = "natives-linux"
                break
            case OperatingSystem.MAC_OS:
                ext.lwjglNatives = "natives-macos"
                break
        }
        runtime "graphics.scenery:spirvcrossj:$spirvCrossVersion:$lwjglNatives"
        ..
    }

Don't forget to add at the top of your build.gradle:

import org.gradle.internal.os.OperatingSystem

You can take a look to a build.gradle here

Building

To build the wrapper, you need the following prerequisites:

  • CMake, version 2.8 or higher.
  • SWIG, version 3.0 or higher.
  • a working build environment, meaning Visual Studio on Windows, autotools and gcc/clang on OSX/Linux.
  • Maven for building the JAR

By default, a debug build is done. To do a release build, add --config Release in the cmake --build step.

OSX/Linux

On OSX and Linux, you can simply run build.sh or follow these steps:

# get SPIRV-cross source code, only needed after initial clone
git submodule init
git submodule update

# do CMAKE build
mkdir build
cd build
cmake ..
cmake --build .

# build Maven artifact
cd ../java-wrapper
mvn install

Windows

Please note that 32bit builds are not supported.

# get SPIRV-cross source code, only needed after initial clone
git submodule init
git submodule update

# do CMAKE build
mkdir build
cd build
cmake -G "Visual Studio 14 2015 Win64" ..
cmake --build .

# build Maven artifact
cd ../java-wrapper
mvn install

Running the tests

You can run the JUnit tests e.g. in Eclipse or IntelliJ after executing the steps above. The loader will pick up either the newly generated JNI libraries, or load the ones from the JAR. Alternatively, the tests can be executed via Maven, as mvn test.

In all cases, two tests are performed:

  • for SPIRV-cross: converting from SPIRV to GLSL 3.10, taking a provided SPIRV binary, removing decorations and converting it back to GLSL 3.10 (TestVulkanToGLSL.java).
  • for glslang: taking in GLSL text files, and compiling them to SPIRV with Vulkan semantics (TestGLSLToVulkan.java).

The input files for these tests are taken from the tests in the repositories of glslang and SPIRV-cross and are expected to compile.

Usage

See the tests for how to use the library. For both SPIRV-cross and glslang, the syntax is very similar to the original C++ version.

spirvcrossj's People

Contributors

ctrueden avatar dependabot[bot] avatar elect86 avatar hinerm avatar mdoube avatar skalarproduktraum avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

spirvcrossj's Issues

classloader hack is more general than imagej-launcher

if(System.getProperty("java.class.path").toLowerCase().contains("imagej-launcher")) {

I ran into this issue when dynamically loading sciview + deps.

The hilarious workaround to take advantage of this workaround is:

(java.lang.System/setProperty "java.class.path" (str "imagej-launcher"
                                                     (java.lang.System/getProperty "path.separator")
                                                     (java.lang.System/getProperty "java.class.path")))

Perhaps it would be possible to check an extra system property like "spirvcrossjUseContextClassloader," because the above workaround is a little bit out there.

Some tags are missing

The following release versions exist but do not have corresponding tags in the repository:

  • 0.7.0-1.1.106.0
  • 0.6.0-1.1.106.0
  • 0.3.0
  • 0.2.4
  • 0.2.3

Warnings from JPMS JVM

Hello,
Just a little post to report a warning that for the moment does not affect the smooth running of the program but may change in the future.

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by graphics.scenery.spirvcrossj.Loader (file:/Users/  ...  jar) to field java.lang.ClassLoader.sys_paths
WARNING: Please consider reporting this to the maintainers of graphics.scenery.spirvcrossj.Loader
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

The operating system is Mac Osx.
The JVM is from OpenJDK 11.
The SPIR-V java library is spirvcrossj version 0.6.0-1.1.106.0 loaded from Gradle.

I also noticed that when the library is included in a distribution jar file, its loading fails.
For some reason that I did not deepen, the temporary local directory intended to accommodate the copy of the lib file to be loaded remains empty.
I work around the problem by implementing code that forces the loading of the library.

spirvcrossj does not fall back to ContextClassLoader if using fat JAR

Hey @skalarproduktraum ,

you may remember, we included Scenery at some point into ClearControl. I just tried updating the dependency to version 0.2.0-beta1.

I'm now getting this error message:

java.lang.NoClassDefFoundError: graphics/scenery/utils/SceneryJPanel
	at sc.iview.DefaultSciViewService.makeSciView(DefaultSciViewService.java:110)
	at sc.iview.DefaultSciViewService.getOrCreateActiveSciView(DefaultSciViewService.java:165)
	at clearcontrol.microscope.lightsheet.postprocessing.visualisation.instructions.SciViewInstruction.initialize(SciViewInstruction.java:57)
	at clearcontrol.microscope.lightsheet.timelapse.LightSheetTimelapse.acquire(LightSheetTimelapse.java:208)
	at clearcontrol.microscope.timelapse.TimelapseBase.loop(TimelapseBase.java:355)
	at clearcontrol.core.device.task.LoopTaskDevice.run(LoopTaskDevice.java:32)
	at clearcontrol.microscope.timelapse.TimelapseBase.run(TimelapseBase.java:301)
	at clearcontrol.core.device.task.TaskDevice.lambda$startTask$0(TaskDevice.java:107)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException: graphics.scenery.utils.SceneryJPanel
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

When calling:

SciViewService sciViewService = context.service( SciViewService.class );
SciView sciView = sciViewService.getOrCreateActiveSciView();

From: https://github.com/mpicbg-csbd/clearcontrol-lightsheet-csbd/blob/master/src/main/java/clearcontrol/microscope/lightsheet/postprocessing/visualisation/instructions/SciViewInstruction.java#L56

Is there some example code available showing how to generate a SciView instance from Java and load a volume into it?

Thanks a lot! No hurry btw.

Cheers,
Robert

Using spirvcrossj inside an ImageJ installation fails to extract native libs

The error I am seeing on macOS 10.13.2 when I open the T1 Head sample and then run SciView > Launch follows.

[SciJava-6acbf2ef-Thread-1] INFO SciView - Started application as PID 29960
Failed to extract native libraries: Users/curtis/code/scenery/SciView/Fiji.app/jars/macosx/spirvcrossj-0.3.0-natives-macos-natives-macos.jar (No such file or directory)
java.io.FileNotFoundException: Users/curtis/code/scenery/SciView/Fiji.app/jars/macosx/spirvcrossj-0.3.0-natives-macos-natives-macos.jar (No such file or directory)
	at java.util.zip.ZipFile.open(Native Method)
	at java.util.zip.ZipFile.<init>(ZipFile.java:225)
	at java.util.zip.ZipFile.<init>(ZipFile.java:155)
	at java.util.jar.JarFile.<init>(JarFile.java:166)
	at java.util.jar.JarFile.<init>(JarFile.java:103)
	at graphics.scenery.spirvcrossj.Loader.loadNatives(Loader.java:129)
	at graphics.scenery.backends.opengl.OpenGLRenderer.<init>(OpenGLRenderer.kt:260)
	at graphics.scenery.backends.opengl.OpenGLRenderer.<init>(OpenGLRenderer.kt:60)
	at graphics.scenery.backends.Renderer$Companion.createRenderer(Renderer.kt:108)
	at graphics.scenery.backends.Renderer$Companion.createRenderer$default(Renderer.kt:102)
	at graphics.scenery.backends.Renderer.createRenderer(Renderer.kt)
	at sc.iview.SciView.init(SciView.java:128)
	at graphics.scenery.SceneryBase.main(SceneryBase.kt:115)
	at sc.iview.LaunchViewer.run(LaunchViewer.java:21)
	at org.scijava.command.CommandModule.run(CommandModule.java:199)
	at org.scijava.module.ModuleRunner.run(ModuleRunner.java:168)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:127)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:66)
	at org.scijava.thread.DefaultThreadService$3.call(DefaultThreadService.java:238)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Unable to load native library: no spirvcrossj in java.library.path
Did you include spirvcrossj-natives-mac in your dependencies?
[ERROR] Module threw error
java.lang.UnsatisfiedLinkError: graphics.scenery.spirvcrossj.libspirvcrossjJNI.initializeProcess()Z
	at graphics.scenery.spirvcrossj.libspirvcrossjJNI.initializeProcess(Native Method)
	at graphics.scenery.spirvcrossj.libspirvcrossj.initializeProcess(libspirvcrossj.java:201)
	at graphics.scenery.backends.opengl.OpenGLRenderer.<init>(OpenGLRenderer.kt:261)
	at graphics.scenery.backends.opengl.OpenGLRenderer.<init>(OpenGLRenderer.kt:60)
	at graphics.scenery.backends.Renderer$Companion.createRenderer(Renderer.kt:108)
	at graphics.scenery.backends.Renderer$Companion.createRenderer$default(Renderer.kt:102)
	at graphics.scenery.backends.Renderer.createRenderer(Renderer.kt)
	at sc.iview.SciView.init(SciView.java:128)
	at graphics.scenery.SceneryBase.main(SceneryBase.kt:115)
	at sc.iview.LaunchViewer.run(LaunchViewer.java:21)
	at org.scijava.command.CommandModule.run(CommandModule.java:199)
	at org.scijava.module.ModuleRunner.run(ModuleRunner.java:168)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:127)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:66)
	at org.scijava.thread.DefaultThreadService$3.call(DefaultThreadService.java:238)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Note the missing leading slash in Users/curtis/... (but maybe this is fine; I don't know), as well as the doubled natives-macos-natives-macos classifier in the filename.

To reproduce:

  • Pull the latest SciView
  • Run sh populate_fiji.sh to build yourself a shiny fresh Fiji.app
  • Launch the Fiji within
  • File > Open Samples > T1 Head
  • SciView > Launch
  • Behold

I thought this might be due to placing the natives JARs in the jars/macosx subfolder (where they are supposed to live in an ImageJ installation these days, to ensure they only ship to people with Macs). But I tried moving all those JARs into the base jars folder and the problem still happens. So I suppose the hacky logic that @skalarproduktraum linked here is the probable culprit.

Accessing SPIRType member properties

Hello

I am working on a brand new renderer for my project, and I need to do some preprocessing on my GLSL shader code before handing it over to either Vulkan or OpenGL 4.0.

My problem with those bindings is that there doesn't appear to be any mapped functionality from the original SPIRType struct, the best I can get is a SWIGTYPE_p_SPIRType object from Compiler.getType, but as far as I can understand it's just an object wrapping a pointer, with no field access

Because I need to inspect the shader stages uniforms to build my descriptor set layouts, I am kind of stuck on this, and I'm not that familiar with SWIG or C++ in general really, so I'd really appreciate any pointers or help for a fix.

Running under Java +10 loadNatives always fails due to new reflection restrictions to internal classes

Hi,
I've updated to Java 11 (from 9) and I have noticed that the loadNatives always fails. After some investigation I concluded that now Reflection.filterFields (that is called when getting any Field) omits all Fields from ClassLoader class. This makes sys_paths effectively inaccessible what causes your code to always fail at native library loading.
For right now I have temporarily fixed this by coping the native file from the temporary direction and placing it in to my run directory where I use this to directly point to the file and load it.

To fix this I suggest replacing the old sys_paths hack with the more official System.load method as I pointed out above.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    馃枛 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 馃搳馃搱馃帀

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google 鉂わ笍 Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.