Conversation

Notices

1. Embed this notice
   dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:11:08 JST dave

   I seem to have gotten a very basic qualified type thing working. still need to noodle with it more, though.

   • Embed this notice
     dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:10:14 JST dave

     in reply to

     I took a look at the type inference code in guile-prescheme and I'm impressed with how elegant it is. However, it's an imperative implementation. My algorithm is functional and I'd like to keep it that way. Once I have something that produces correct output for all of my existing shaders I will try to refactor the code into something nicer.

     clacke likes this.
   • Embed this notice
     dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:10:23 JST dave

     in reply to

     I now have basic struct types working. The qualified type logic was extended to support them and overloaded function generation was extended to deal with structs as arguments. I also added function signatures for a number of built-in GLSL functions. I can once again compile the simple vertex shader I use for 2d sprites:

     (top-level
     ((in vec2 position)
     (in vec2 texcoords)
     (out vec2 frag-tex)
     (uniform mat4 mvp))
     (outputs
     (vertex:position (* mvp
     (vec4 (-> position x)
     (-> position y)
     0.0 1.0)))
     (frag-tex texcoords)))

     GLSL output:

     in vec2 V0;
     in vec2 V1;
     out vec2 V2;
     uniform mat4 V3;
     void main() {
     float V4 = V0.x;
     float V5 = V0.y;
     float V6 = 0.0;
     float V7 = 1.0;
     vec4 V8 = vec4(V4, V5, V6, V7);
     vec4 V9 = V3 * V8;
     gl_Position = V9;
     V2 = V1;
     }

   • Embed this notice
     dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:10:29 JST dave

     in reply to

     Okay now I can emit GLSL for functions with multiple signatures!

     Contrived input program:

     (let* ((f (lambda (x y) (+ x y)))
     (z (f 1.0 2.0)))
     (f 3 4))

     'z' is a useless binding that just demonstrates that 'f' can be called with floats and ints. good thing I don't do dead code elimination yet.

     GLSL output:

     void V2(in int V0, in int V1, out int V4) {
     int V5 = V0 + V1;
     V4 = V5;
     }
     void V2(in float V0, in float V1, out float V6) {
     float V7 = V0 + V1;
     V6 = V7;
     }
     void main() {
     float V8 = 1.0;
     float V9 = 2.0;
     float V10;
     V2(V8, V9, V10);
     float V3 = V10;
     int V11 = 3;
     int V12 = 4;
     int V13;
     V2(V11, V12, V13);
     int V14 = V13;
     }

   • Embed this notice
     dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:10:36 JST dave

     in reply to

     Here's a simple example program:

     (top-level ((in int x))
     (let ((f (lambda (x) (+ x 1))))
     (f 2)))

     The only type declaration is on the shader input attribute 'x'. Here's the typed program that the compiler generates:

     (t ((primitive int))
     (top-level
     ((in int V0)
     (function
     V2
     (t ((for-all
     ((tvar T3) (tvar T7))
     (-> ((tvar T3)) ((tvar T7)))
     (and (= (tvar T3) (primitive int))
     (substitute (tvar T7) (tvar T3)))))
     (lambda (V1)
     (t ((tvar T7))
     (primcall
     +
     (t ((tvar T3)) V1)
     (t ((primitive int)) 1)))))))
     (t ((primitive int))
     (call (t ((-> ((primitive int)) ((primitive int)))) V2)
     (t ((primitive int)) 2)))))

     The interesting bit is the 'for-all' expression that generalizes the function 'f' to accept any arguments as long as they satisfy the predicate (the 'and' expression). In this case the only valid type for 'x' is an integer.

     The compiler is currently unable to emit GLSL code for the function because it doesn't yet know how to translate a 'for-all' into a series of functions for each valid type combination. That's the next step.

   • Embed this notice
     dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:10:43 JST dave

     in reply to

     Okay so this strategy seems to be working! Hopefully will have some cool code to share soon.

   • Embed this notice
     dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:10:48 JST dave

     in reply to

     What might be useful is allowing for a signature like 'a, b -> c' and associate substitutions with predicate conditions. If 'a' is a vector and 'b' is a matrix then substitute 'b' for 'c'. If 'a' is a matrix and 'b' is a vector, substitute 'a' for 'c'.

   • Embed this notice
     dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:10:55 JST dave

     in reply to

     One limitation of this approach seems to be (meaning I haven't found a paper/article stating otherwise yet) that it cannot express all of the possibilities of function overloading. For example, in GLSL it is valid to multiply a matrix by a vector. It is also valid to multiply a vector by a matrix. Both forms return a matrix, but the signatures are different. The first is 'a, b -> a' and the second is 'b, a -> a'. This would require two differently named functions in a qualified type system.

   • Embed this notice
     dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:11:02 JST dave

     in reply to

     Qualified types introduce a type predicate that needs to be checked after inferring each expression. For example, let's say the signature of '+' is 'a, a -> a' where 'a' is any type. Addition only makes sense for certain types of data, so we can then specify which types are valid with a predicate. For example: where 'a' is a float or an int. Adding two booleans is valid as far as the function signature is concerned, but it will then fail the predicate check.

   • Embed this notice
     dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:12:37 JST dave

     in reply to

     Seagull is feeling pleasantly Schemey! There are two big missing features in the language: Loop syntax (GLSL *severely* restricts looping and recursion is *not* allowed so a loop form is essential, unfortunately) and user defined structs. I already have define-shader-type syntax that I've been using with my existing GLSL shader code so I just need to a way to import those into Seagull code and have the compiler generate the GLSL struct declaration.

     clacke likes this.
   • Embed this notice
     dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:12:38 JST dave

     in reply to

     here's a more complicated shader that I ported to seagull. I use this for stretchable dialog boxes. https://gist.github.com/davexunit/5d9c4f707c349e3a5aada5dae1ce674d

   • Embed this notice
     dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:12:38 JST dave

     in reply to

     My most complicated shader port yet: the stroke and fill shaders for my vector graphics renderer. https://gist.github.com/davexunit/83e1ed3d71ea11f48e30fc8cc0d568ec

     clacke repeated this.
   • Embed this notice
     dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:12:39 JST dave

     in reply to

     ahhh I got my single sprite and batch sprite shaders ported over and *they work*!!!

   • Embed this notice
     dave (dthompson@toot.cat)'s status on Sunday, 19-Feb-2023 00:12:40 JST dave

     in reply to

     The next big step was hacking this compiler into my existing shader code so I could actually use the shaders and test that they really work. This required a linking pass that does a bunch of renaming on the separately compiled vertex and shader stages to ensure that vertex output names match up with fragment input names (GLSL needs the names to be the same, ugh!) and that uniform variables between both stages use unique names because they share a global namespace.