Homebrew Selena - Shader Compiler

[machinamentum]

Hello,

I've been kicking around this project in my head since around the time of release of Ninjhax 1. This is more or less a pre-release and very much a WIP. Selena is a shader compiler that aims to translate GLSL-esque code into shader assembly. Currently, it can generate very rudimentary code for Nihstro, however, the main goal is to link against the project as a library and produce a shader binary directly that can be immediately fed into ctrulib, your preferred OpenGL implementation, or other graphics libraries.

It doesn't yet perform type checking, error handling, swizzling or any other fancy features. They're important and are on my todo list.

Pre-builts will not be provided until the project is much more matured.
Building:

git clone https://github.com/machinamentum/Selena.git
cd Selena
mkdir build
cd build
cmake ..
make
make install

This will produce an offline compiler to be used within a toolchain and a run-time library to optionally link against.

Usage:

selenacc my_GLSL_shader.vsh -o my_shader.shbin

Options:

-o <output>       | Select output file
-h,--help         | Show this help message
--verbose         | Print parse and syntax tree structures
-S                | Output nihstro assembler

Inline assembly:

Spoiler

The compiler supports robust inline assembly. Syntax:

asm("<opcode> <dst>, <src1>[,<src2>,<src3>]", <variable list>)

Example:

asm("rsq @0, @1", Value);

rsq is the reciprocal square root instruction. @0 is a special directive to the compiler that gets the first temporary register that is unused. @1, @2, @3, @<number> references the list of variables following the command string in sequential order, beginning with 1, and retrieves the register or alias assigned to that variable.

Source: https://github.com/machinamentum/Selena
Examples: https://github.com/machinamentum/selena-examples

 

[Deleted User]

Wow, nice job. Having full GLSL shader support (or similar) would be great.

 

[machinamentum]

Project update:
I've been heavily improving this project. The parser has been drastically improved and has decent syntax error checking. The code generator has been improved and now supports mat4 * vec4 multiplication. A shbin generator has been implemented so the project no longer relies on external assemblers to build shaders (nihcode can still be generated by supplying the "-S" flag on the command line). I've put together some examples of using the compiler for compile-time and run-time shader building at https://github.com/machinamentum/selena-examples. See OP for building and installing the project.

 

[TheCruel]

I have only a couple shaders I've been using, and haven't had much need to use shaders beyond that. But I'll be doing some more intense 3D work soon and I'll remember to check this out then.

I would just suggest simple documentation of supported syntax.

 

[machinamentum]

I have only a couple shaders I've been using, and haven't had much need to use shaders yet. But I'll be doing some more intense 3D work soon and I'll remember to check this out then.

I would just suggest simple documentation of supported syntax.

The parser implements the GLSL ES spec. This will be the target going forward (though currently, it only really supports a handful of the legacy GL built-ins).

 

[yuyuyup]

Please team up with VR legend/gbatemp member CarlKenner aka 2EyeGuy and make 3DS games VR headset compatible

 

[machinamentum]

With the latest commits, the compiler no longer uses built-in uniforms or vertex attributes (gl_Vertex, gl_Color); these are all user-defined now (vertex attributes are assigned register slots in the order they're declared).

The next step is figuring out how to handle varyings. Since the fragment pipeline isn't programmable, it makes sense to have built-ins for these, but the compiler is very flexible and a syntax could be added where the user could specify the hardware outputs based on an index or a string i.e.

varying vec4 OutColor (layout = "result.color");

Both of these approaches are unlike standard GLSL/ES, but they provide a straight forward way to utilize whats available on the 3DS. If the built-in approach is taken what should be the naming convention? GLSL/ES still defines gl_Position as a built-in, so something like gl_NormalQuat would make the naming consistent, but prefixing with (for example) ctr_ instead of gl_ would make it easier to distinguish whats part of the standard language and what is 3DS specific.

 

[TheCruel]

Indeed, prefixing (or suffixing) with CTR would be preferable for anything non-standard. Or could be like Nintendo who used "DMP" in their GL extensions and such, but not like it matters.

I have no advice on varyings though, I have very limited GLSL knowledge.