It’s been a few days I haven’t posted about luminance. I’m on holidays, thus I can’t be as involved in the development of the graphics framework as I’m used to on a daily basis. Although I’ve been producing less in the past few days, I’ve been actively thinking about something very important: uniform.
What people usually do
Uniforms are a way to pass data to shaders. I won’t talk about uniform blocks nor uniform buffers – I’ll make a dedicated post for that purpose. The common OpenGL uniform flow is the following:
- you ask OpenGL to retrieve the location of a GLSL uniform through the function
glGetUniformLocation, or you can use an explicit location if you want to handle the semantics on your own ;
- you use that location, the identifier of your shader program and send the actual values with the proper
You typically don’t retrieve the location each time you need to send values to the GPU – you only retrieve them once, while initializing.
The first thing to make uniforms more elegant and safer is to provide a typeclass to provide a shared interface. Instead of using several functions for each type of uniform –
Float and so on – we can just provide a function that will call the right OpenGL function for the type:
That’s the first step, and I think everyone should do that. However, that way of doing has several drawbacks:
- it still relies on side-effects; that is, we can call
sendUniformpretty much everywhere ;
- imagine we have a shader program that requires several uniforms to be passed each time we draw something; what happens if we forget to call a
sendUniform? If we haven’t sent the uniform yet, we might have an undefined behavior. If we already have, we will override all future draws with that value, which is very wrong… ;
- with that way of representing uniforms, we have a very imperative interface; we can have a more composable and pure approach than that, hence enabling us to gain in power and flexibility.
What luminance used to do
In my luminance package, I used to represent uniforms as values.
We can then alter the
Uniform typeclass to make it simpler:
We also have a pure interface now. I used to provide another type,
Uniformed, to be able to send uniforms without exposing
IO, and an operator to accumulate uniforms settings,
The new uniform interface
The problem with that is that we still have the completion problem and the side-effects, because we just wrap them without adding anything special –
Uniformed is isomorphic to
IO. We have no way to create a type and ensure that all uniforms have been sent down to the GPU…
Contravariance to save us!
If you’re an advanced Haskell programmer, you might have noticed something very interesting about our
U type. It’s contravariant in its argument. What’s cool about that is that we could then create new uniform types – new
U – by contramapping over those types! That means we can enrich the scope of the hardcoded
Uniform instances, because the single way we have to get a
U is to use
Uniform.toU. With contravariance, we can – in theory – extend those types to all types.
Sounds handy eh? First thing first, contravariant functor. A contravariant functor is a functor that flips the direction of the morphism:
contramap is the contravariant version of
(>$) is the contravariant version of
(<$). If you’re not used to contravariance or if it’s the first time you see such a type signature, it might seem confusing or even magic. Well, that’s the mathematic magic in the place! But you’ll see just below that there’s no magic no trick in the implementation.
U is contravariant in its argument, we can define a
As you can see, nothing tricky here. We just apply the
(a -> b) function on the input of the resulting
U a so that we can pass it to
u, and we just
runU the whole thing.
A few friends of mine – not Haskeller though – told me things like “That’s just theory bullshit, no one needs to know what a contravariant thingy stuff is!”. Well, here’s an example:
Even though we have an instance of
(Float,Float,Float,Float), there will never be an instance of
Color, so we can’t have a
U Color… Or can we?
The type of
U Color! That works because contravariance enabled us to adapt the
Color structure so that we end up on
(Float,Float,Float,Float). The contravariance property is then a very great ally in such situations!
We can even dig in deeper! Something cool would be to do the same thing, but for several fields. Imagine a mouse:
We’d like to find a cool way to have
U Mouse, so that we can send the mouse cursor to shaders. We’d like to contramap over
mouseY. A bit like with
We could have the same thing for contravariance… And guess what. That exists, and that’s called divisible contravariant functors! A
Divisible contravariant functor is the exact contravariant version of
divide is the contravariant version of
conquer is the contravariant version of
pure. You know that
pure’s type is
a -> f a, which is isomorphic to
(() -> a) -> f a. Take the contravariant version of
(() -> a) -> f a, you end up with
(a -> ()) -> f a.
(a -> ()) is isomorphic to
(), so we can simplify the whole thing to
f a. Here you have
conquer. Thank you to Edward Kmett for helping me understand that!
Let’s see how we can implement
And now let’s use it to get a
And here we have
uMouse :: U Mouse! As you can see, if you have several uniforms – for each fields of the type, you can
divide your type and map all fields to the uniforms by applying several times
The current implementation is almost the one shown here. There’s also a
Decidable instance, but I won’t talk about that for now.
The cool thing about that is that I can lose the
Uniformed monadic type and rely only on
U. Thanks to the
Divisible typeclass, we have completion, and we can’t override future uniforms then!
I hope you’ve learnt something cool and useful through this. Keep in mind that category abstractions are powerful and are useful in some contexts.
Keep hacking around, keep being curious. A Haskeller never stops learning! And that’s what so cool about Haskell! Keep the vibe, and see you another luminance post soon!