Selena - Shader Compiler

Discussion in '3DS - Homebrew Development and Emulators' started by machinamentum, Oct 31, 2015.

  1. machinamentum
    OP

    machinamentum GBAtemp Regular

    Member
    163
    450
    Jul 5, 2015
    United States
    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:
    Code:
    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:
    Code:
    selenacc my_GLSL_shader.vsh -o my_shader.shbin
    
    Options:
    Code:
    -o <output>       | Select output file
    -h,--help         | Show this help message
    --verbose         | Print parse and syntax tree structures
    -S                | Output nihstro assembler
    
    Inline assembly:
    Warning: Spoilers inside!
    Source: https://github.com/machinamentum/Selena
    Examples: https://github.com/machinamentum/selena-examples
     
    Last edited by machinamentum, May 27, 2016
  2. Steveice10

    Steveice10 GBAtemp Maniac

    Member
    1,102
    1,655
    Jul 19, 2009
    United States
    Wow, nice job. Having full GLSL shader support (or similar) would be great.
     
  3. machinamentum
    OP

    machinamentum GBAtemp Regular

    Member
    163
    450
    Jul 5, 2015
    United States
    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.
     
  4. TheCruel

    TheCruel Developer

    Banned
    1,351
    2,883
    Dec 6, 2013
    United States
    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.
     
    Last edited by TheCruel, May 27, 2016
    marc00077 and daxtsu like this.
  5. machinamentum
    OP

    machinamentum GBAtemp Regular

    Member
    163
    450
    Jul 5, 2015
    United States
    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).
     
  6. yuyuyup

    yuyuyup GBAtemp Psycho!

    Member
    3,336
    773
    Apr 30, 2006
    United States
    USA MTN timezone
    Please team up with VR legend/gbatemp member CarlKenner aka 2EyeGuy and make 3DS games VR headset compatible
     
  7. machinamentum
    OP

    machinamentum GBAtemp Regular

    Member
    163
    450
    Jul 5, 2015
    United States
    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.
    Code:
    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.
     
    AtlasFontaine and TheCruel like this.
  8. TheCruel

    TheCruel Developer

    Banned
    1,351
    2,883
    Dec 6, 2013
    United States
    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.