Glium post-mortem

1

Here is a small "post-mortem" post about glium. It is here to express my feelings about what went
wrong with glium. This post is also here because I need some advice from you about what the future
of glium should be.

Usually a post-mortem is supposed to contain the positive aspects of a project. In other words,
what went right. But I'm generally a perfectionnist person and am very critical of my work, so
I don't really know what to put in that category.
Most people report that glium is a huge improvement over raw OpenGL, which I think is true. So
that's a good point. But I don't see any aspect where the development of glium particularly shined
compared to another library.

Let's jump to the negative aspects, which are the most interesting part.

What went wrong

Drivers are still crippled with bugs

I knew that OpenGL drivers were crippled with bugs when I started glium, but I didn't know at which
degree. Glium was supposed to be a safe layer above the drivers and fix all the safety bugs that
are encoutered. That's why glium contains lots of codes like this
or this.

In reality the situation is too catastrophic, and it's almost impossible to keep that initial goal
of fixing driver errors. I have the feeling that some driver writers barely read the specifications,
and the fact that online documentation (like docs.gl) is filled with mistakes doesn't help.

An anecdote is that the first time I ran unit tests with vulkano I was amazed by the mere fact that
it worked. Glium's tests happen to randomly fail because of driver bugs.

The more recent the OpenGL feature the more likely it has bugs in it, even with major vendors.
Some very recent extensions are barely usable with some drivers.

I should have accepted that situation and sticked with well-established OpenGL features that are
known to work well everywhere, instead of exposing the entirety of OpenGL.

Overlapping with Vulkan

The most recent OpenGL features (like persistent-mapped buffers or bindless textures) are
overlapping with what Vulkan proposes. The current situation in 3D rendering is that if you want
low-level control over what's happening then you should use Vulkan, and if you want to have a
high-level API or support older hardware or work on the web then you should use OpenGL.

Before Vulkan was released, it made sense to expose some low-level functionnalities in OpenGL
itself, because high-performance games need low-level control.
But now it's no longer useful. These capabilities only work on recent hardware anyway, and are too
dangerous to ever be exposed by a browser with WebGL.

Had I know that (I'm still a bit bitter about the fact that the development of Vulkan was entirely secret before its release), I wouldn't have bothered with anything more recent than OpenGL 4.0/4.1 in glium.
Vulkan supports hardware released in 2012 or more, so it's not like it's a niche technology.
Even if desktop OpenGL fades away over time, there's still a large market for OpenGL on the web and
on mobile devices. Only very recent mobile phones and tablets can support Vulkan.

Lots of unfinished areas

Overall, glium has a ton of unfinished elements. Textures and buffers (the basic blocks of OpenGL)
still haven't got a complete API.

The reason is simple: when I started glium (and still today), there was no real reference for how
to design an API. I built an API, then changed my mind and changed it, then changed my mind again.
Each change was justified, but I wouldn't have lost that much time if I knew from the start how to
design things in Rust.

Flooded with questions

One aspect that I didn't anticipate is that I'm now "flooded" with questions about glium.
By e-mail, on IRC (some of them in private), and with issues. And it's tiring. Sometimes I
purposely don't answer questions because I don't have the motivation to do so, but I always feel
bad when I do that.

I can put these questions in three categories:

  • "How do you do <thing in OpenGL>?", to which my answer is almost always that glium's API doesn't
    allow that yet, but they can use <hacky solution> instead for now.
  • "I have this problem with glium", to which my answer usually is: I know that this problem exists, but
    fixing it requires a lot of work.
  • "How do you do <thing in 3D rendering>?". Since glium is such high-level and has a tutorial
    oriented towards people who don't know 3D rendering, I also get many questions about 3D rendering
    in general. I generally answer these questions as well, because I consider it rude to answer
    that they should ask someone else.

This could be improved by writing a FAQ and a real-world example of how to use glium. However
these take time and aren't easy to write. In vulkano, I solved the problem by not really
communicating about the library. I started writing a vulkano tutorial, but didn't say a word about
it. I also clearly say everywhere that vulkano isn't ready yet. This is maybe a more cynical
solution, but so far it avoided me having to answer (annoying (sorry)) questions.

Failed to attract code contributors

The initial reason why I talked about glium on reddit and on the forum was to hopefully
attract contributors.
I was hoping that people could help me, especially people experienced in OpenGL.

But after a few months, I still didn't get any contribution to anything else but the documentation.
I realized that it's because the core of the library is far too complicated. With all the API
reworks things began to be more and more messy, and I totally understand that people don't want
to dive in this kind of code.

Since then the situation improved a bit, and I have had several features implemented only thanks
to people other than me. But unfortunately I think that I'm still the only person to understand
how that library is supposed to go forward, at least before this post. Glium is too much of a black box,
and that's obviously bad.

Conclusion

I think that a partial rewrite would be necessary, in other words start from scratch but
copy-paste code from the old library when possible. I don't really have the time however, so in
the meanwhile glium is in that delicate situation where it's bad enough that I want to throw it
away, but not bad enough that people don't use it.

Thanks for reading.
Let me know what you think about all this, and what you think should be the future of glium.

83 Likes
2

I think a safe wrapper for OpenGL makes a lot of sense. I did the same thing in D/C++ in the past, though not to the same extend as glium. It was just much nicer to catch a lot of bugs at compile time than to manually debug them.

I can't say anything about driver bugs as I only have one dev machine. The nvidia driver always worked as expected for my uses( as far as I know). The intel driver was basically unusable.

I haven't really used glium at all and I currently spend all my time learning Vulkan and I don't think I will ever go back to OpenGL at all. If I want to support older gpu's I would probably go with gfx-rs.

It would be nice to know why gfx-rs didn't choose glium for their OpenGL backend. I would assume they didn't want to have an extra dependency.

A bit offtopic but I wanted to say that you inspire me. You write a lot of top notch, highly documented and unit tested code. I am a "perfectionist" too and I have so many days where I barley get anything done because of it, but your projects help me to get past that.

I think there are a lot of other people who appreciate the time and effort you put into your libraries.

I just wanted to say thank you. I hope that doesn't sound too weird.

26 Likes
3

Hi tomaka,

First, let me thank you for all the work you are doing on the glium and vulkan crates. I was watching both for future usage of some graphics related work, but I'm still in the early stages of learning the Rust language. I guess a lot of people go through similar learning processes so for me it's not a surprise that you didn't find a lot of contributers (yet).

If I would be you I would focus my work on vulkan first. By the time this crate will be stable and usable you probably have a much better idea on how to build on top of that. My gut feeling is that the drivers got so chaotic to compensate for programing errors, that the decision to switch to something more stable but solid was necessary. Unfortunately this puts a lot of burden on the shoulders of programers. I do remember times where IRIS Inventor was ment to make it less time-consuming to do 3D programming. Vulkan is almost the opposite (who remembers IRIS Performer?).

Anyway, keep up the good work. I really think Rust is a good language to help making those things much more stable and reliable. It will take some time though ...

4 Likes
4

This is a problem that comes up with pretty much any successful open source project. You get a lot of people interested in using it, and since you're the expert on it, they will ask you.

My main recommendation on this topic would be to aggressively move these questions to public forums, and let other people respond to them. For one, this will reduce the direct load on you a bit. For another, people who are able to help answer questions may be able to build up their expertise and become contributors in the future.

I don't know if a Glium-specific forum, or just directing people here, StackOverflow, /r/rust or /r/rust_gamedev would be most appropriate; but I would say that picking one such place and directing all private queries there (and private IRC queries to an appropriate public IRC channel), could help with reducing the direct burden on you and getting more people in the community involved.

23 Likes
5

I've been working on Free software projects since 1990, and I think this is pretty much on the mark. "These are the problems one hopes for!"

It feels good to help someone, but if you could spend that same time fixing a major bug that affects a thousand people, then, as unpleasant as it is, you need to redirect the single person. You can have a FAQ; you can have a mailing list; you can have an IRC channel. Yes, sometimes helping someone encourages that person to be a contributor, but the calculus is pretty brutal; you have to choose who to help based on your assessment of how likely they are to become a contributor.

The quality issues that are outside of your control are... outside of your control. You've certainly made the situation better than it was! And each difficulty you can compensate for is a step forward. But I don't see why you feel that OpenGL driver bugs reflect poorly on Glium as a project, unless you want to judge Glium in a vacuum, rather than in the context of your users' alternatives.

I love Glium, and I hope it gets better and better!

10 Likes
6

First of all, thanks @tomaka for doing the post-portem!

I'm a bit shocked about the "post" part though, I thought glium is alive and well, used by so many devs to the moment. You've been always providing excellent support, documentation and participating on IRC helping out people. Frankly, I don't recall hearing a single major complaint about glium...

Drivers are still crippled with bugs

Don't color yourself surprised. It's been like this forever. Major gamedevs were doing DirectX titles, which helped to shape this API pretty solid, while GL was always behind both in terms of architecture and polish/bugs.

Had I know that (I'm still a bit bitter about the fact that the development of Vulkan was entirely secret before its release), I wouldn't have bothered with anything more recent than OpenGL 4.0/4.1 in glium

This was rather clear long before Vulkan spec was out. There were already talks/presentations online with the general architecture, there was Mantle and DX12. And you've been staying on top of all Vulkan news...

Lots of unfinished areas

That's an interesting point. On one hand, it would really help if you got a solid core team to discuss the architecture with. We were lucky enough to have such a luxury at start, and it propelled the API evolution of gfx-rs. I'm still wondering about how would the history unfold if you joined us instead of building your own thing (with black jack and ...).

On the other hand, you may have dug a hole for yourself with all the extensive tests and documentation. It greatly improves the welcoming of new contributors/users but has a nasty downside of slowing you down with major changes. We tried to be more lean on the docs and were doing bigger changes easier, while attracting less users.

Flooded with questions

I hear you! Community support takes valuable time. There is often the case where you are inspired to take a stub at some complex thing and hack around one night, but instead spending all of it helping out someone with a problem/bug. Fortunately, at some point the community becomes more autonomous (taking a chance to thank @fkaa and @Bastacyclop in particular). I actually assumed glium was long autonomous as well, I definitely recall hearing some of the contributors helping out each other.

Failed to attract code contributors

So what do you think is the reason for this? I think you were doing great. Could that be the code of glium being a bit too complex? Or maybe, it's the opposite: the library is so good and polished that barely anyone had a need to dive into that, and instead people are just happily using it (@jimb).

gfx-rs had GL backend long before we saw glium. Heck, @tomaka was even contributing to gfx-rs at some point! Github history shows that glium went public about October 2014th, while gfx-rs started on May 2014th.

8 Likes
7

What I didn't realize is that Vulkan would be available on hardware from 2012 and that drivers would all be ready and mature on day 1. In other words, Vulkan is totally usable right now and we don't have to write OpenGL code while waiting for Vulkan.

When I wrote glium, DX12 wasn't available yet either.

My opinion on gfx didn't change. Its goal are incompatible with what I think is the right approach.

1 Like
8

My opinion on gfx didn't change. Its goal are incompatible with what I think is the right approach.

Could you elaborate a little bit on that?

11 Likes
9

Huge thanks tomaka for your work here. You may not realize that your libraries are referenced as forerunners and positive examples in the community. As others have commented above, many of us are new to Rust and/or GPU programming, hence more likely to contribute to docs and minor bits until we gain confidence. Even in more mature tools, building a community of real contributors takes time. It is lonely to innovate, but don't let perfectionism detract from enjoying your success. And put first things first- routinely point private discussion toward a web forum you will also follow, and we can chat and support each other there.

The hardest thing to realize is how precious your time is. I would encourage you to focus efforts on just one library. If you heart is with Vulkan, see if there are others who want to take a more active role helping lead on OpenGL. Rust itself faced such as turning point in the past. No doubt there is a big audience for both OpenGL and Vulkan, but better to focus your efforts and have fun then burn out trying to do it all.

1 Like
10

I want to thank you for your hard work! I think that what you tried to accomplish is perhaps too big of an issue, but is/was a noble effort. I personally liked glium because it seemed simple and made sense. Have you considered a different avenue, such as simplifying opengl to a set standard; I think many of us do not have a desire for bleeding edge when it comes hard to understand or code (for me, as in-- vulkan). With that said, I think that soon as you blackbox something, doing something 'different' probably results in a hacky solution, like you mention. Still, for me at least, an easy to use library that just makes sense is what I desire. Thanks again for your help, you have always been helpful and knowledgeable.

11

Thank you for all the energy and work you have put into glium and glutin. The interface is quickly understandable from the examples. A few, pleasantly short lines get a project started and one doesn't get bogged down in OpenGL boilerplate yet again.

Right now I am making a small example project, and the first thing I thought of was glium.

2 Likes
15

Maybe the "how that library is supposed to go forward"-thing is the problem. Your limits seem to be set too wide (you're drowning trying to fulfill your inner goals). I think if the limits were tight and distinct it would be easier to discard questions not within those limits. Your conscience would take fewer hits if you can point to the current goal you're trying achieve. A forum is definitely a good suggestion. As a user one would want you to continue doing a great job but within reason otherwise this "post" situation will occur. Contributions may be easier to obtain if you define certain well defined areas or function when asking for them (you may have done so, it's nothing I have an opinion on). Please give some thought to this. Don't give up!
Regards, Per Funke

16

@Per Please don't bump old topics here. This one in particular is almost 4 years old.

2 Likes