WIP: Ripping gloo in two via GLIR

[almarklein]

This PR refactors gloo to break it in two pieces, one is the high level gloo interface, which generates GLIR commands. The other is the GLIR interpreter.

In the progress I will also fix some outstanding issues with gloo, as described in #464, like getting rid of local strorage and allow specifying uniforms/attributes before the source code is set.

Closes #464, #510, #450, #338, #407, #351

Overview of changes that this PR makes

All gloo objects:

• No more activate, deactivate methods. No more handle and target properties. Only an id property.
• Gloo objects are context aware. They are associated with the context that is current at the moment of instantiation. If no context is active, they are associated to a "pending context" which will become in use by the first app.Cancas that requests a canvas. This means all our examples still work.

Program:

• The API of Program changes WRT attributes and uniforms. There are no more active_uniforms. Just a function to get info on all variables in shading code.
• There are no variable objects, variable.py is gone. These objects served mainly for deferred setting of values. The GLIR command queue takes over this function.
• There are no more VertexShader and FragmentShader classes, shaders.py is gone. It turns out that shaders do not really have a function other then temporarily existsting to compile the code. Vispy programs should now have more GPU memory available. Just call program.set_shaders() to set source code.
• There are now also warnings when attributes/uniforms are set that are not active. Due to this I found some unnecessary lines of code in some examples.

Buffer:

• No more local storage. This means that setting discontinuous data does not work anymore. Much simpler code though.
• As a consequence data cannot be set on views.
• No more automatic conversion. Passing float64 is not allowed. Or should we convert in this case?

Texture:

• There is no more local copy.
• Passing float64 is not allowed.
• You can use set_size with completely different size and format.
• You can now use set_data using any type and shape.
• Texture does not support views anymore.
• Texture with no data (only shape) can be initialized with Texture((100,100))

Framebuffer

• ColorBuffer, DepthBuffer and StencilBuffer are no more. Just use RenderBuffer. You do not have to specify the format, as the FrameBuffer will do this when attaching (if format is None).
• Deactivating a FrameBuffer will make the previous framebuffer active. This is the job of the GLIR implementation, because in gloo you may not always have access to this information.

Outstanding questions for GLIR spec

• Should GLIR pass enums by string or int? There seem to be more people in favor of strings.

Work to do after this

• There is a call to glGetViewport in text.py. This needs to be removed; we need to get viewport from the event instead.
• GPU objects must be deleted when Gloo objects get cleaned up. I won't be surprised if that will cause problems, so let's do this after Vispy with the current changes seems stable.
• Uniform arrays Uniform arrays not supported in gloo #345

[almarklein]

Current status: broke the buffer class in two. It works with the examples that I tried. Is ready for a first quick review to see whether this corresponds with what others had in mind.

[larsoner]

Should any / all of these be raise NotImplementedError for safety? Maybe they should all be, and if a class wants a no-op, then they can explicitly override.

[almarklein]

No, these should simply be removed (and the calls to them as well), GLIR now takes care of this stuff.

[larsoner]

This looks reasonable to me. I wonder if this will help prevent the rare-ish segfaults we're still getting on Travis. As long as the app tells the GLContext to destroy / invalidate itself, and you check that before executing any gl commands, it should help that issue.

[almarklein]

Whoah, tests pass. Please don't merge though, there is some ugly stuff in there to make it work. Next class to split in two: gloo.Program. I'll get my axe.

[rossant]

remove?

[rossant]

LGTM apart from a few minor comments (notably dead commented code that should probably be removed).

[almarklein]

Addressed comments. There are two pending questions for @Eric89GXL see comments in code.

[almarklein]

These comments are now also addressed. Cyrille was right, I was under the impression that it was glPosition, but that's wrong. Restricting to gl seems to strict, as it would also restrict e.g. "glitch_factor".

[rossant]

OK, ready for merging then! \o/

[almarklein]

Maybe @lcampagn wants to have a look?

[campagnola]

Overall I am impressed that tests are passing and the API is almost exactly the same!

However, broken examples:
basics/scene/viewbox
basics/scene/surface_plot, isosurface
basics/visuals/cube, mesh, polygon, ellipse

Most of these appear to be due to some problem with MeshVisual.

[almarklein]

Fixed examples. One was a quantum-bug; it disappeared when I ran with use_gl('desktop debug'), which is probably how it slipped through.

[larsoner]

Looks like Travis is happy, other than the size test. Is this ready for merge from your end @almarklein? If so, I'm +1 for merge but I'll let @rossant accept responsibility for pushing the button :)

[almarklein]

I am ready :D

[almarklein]

(and really happy to have this about finished, it took quite some effort)

[larsoner]

Yeah, it's quite an impressive bit of work. If it really helps @rossant build clean/fast WebGL visualizations it will be incredibly valuable.

[rossant]

Fantastic!! Much congrats to Almar. We've (slightly) reduced the code base, fixed quite a few bugs, and we have a more solid architecture IMO. And yes, the WebGL backend is coming soon hopefully, I was waiting for this PR to finish it...

[almarklein]

Just a quick note: you need to put closes X, closes Y, closes Z in order for the issues to get closed. closes X, Y, Z does not work.

[rossant]

Oh I thought it was the other way around sorry..

Le jeudi 16 octobre 2014, Almar Klein notifications@github.com a écrit :

Just a quick note: you need to put closes X, closes Y, closes Z in order
for the issues to get closed. closes X, Y, Z does not work.

—
Reply to this email directly or view it on GitHub
#571 (comment).

[almarklein]

No problem :)