Migration to glium

[Yamakaky]

There is a stack overflow in a previous commit, I'm tracking it.

[Yamakaky]

a1a0c73 is the first commit to stack overflow in debug mode.

[Yamakaky]

It should be ok, the screen is similar to before the migration.

[Yamakaky]

I need to refactor the commits ^^

[simias]

Very impressive! I'll review all that as soon as possible.

I've just pushed an implementation of the PSX GPU drawing area using the OpenGL scissor box so that will conflict with your changes, sorry. Hopefully it shouldn't be too difficult to integrate that change...

I haven't looked at the code yet but I've noticed that with your changes all the polygons appear brighter:

Compare with the current raw OpenGL version:

In my "hack" branch I've made some dirty changes to boot up the japanese version of Crash Bandicoot, backporting it on your branch (along with the XY_FIFO fix) seem to work well, although it's still too bright:

My version (with the scissor box that prevents the polygons from leaking everywhere...):

[Yamakaky]

Looks like it's missing gamma correction ^^

[Yamakaky]

Done. Should I refactor the commits or is it ok ?

[Yamakaky]

One problem still: glium::Frame is stored in Renderer, so when the window is closed it's still alive. That's the error message you see. Since you can draw multiple times before the vblank, I can't find a way to easily fix it, except create it higher in the stack trace (but it breaks encapsulation). I'm thinking of it. One way would be to render all the frame in one call.

[simias]

As long as each commit builds individually it's fine (otherwise it's annoying when bisecting a regression). I'll review all that ASAP.

[simias]

Mmh, so I just built your PR and I still have increased brightness compared to master, do you know what causes that?

[Yamakaky]

No...

[simias]

Strange, do you have the same behaviour on your end or is it something on my side?

[Yamakaky]

I just checked, I see the correct colors.

[simias]

By correct colors you mean that you see the same colors with master and your branch? Could you make a screenshot so that I could compare with mine, just to see which one is right and which one is wrong.

[Yamakaky]

With the two versions, I get this image

[Yamakaky]

Should be OK for merge.

[simias]

Okay, I haven't figured out why the colors are brighter on my end but at this point it's not too important.

Do you think we could avoid the "The Frame object must be explicitly destroyed by calling .finish()" error on quit by adding a Drop implementation to the renderer?

[Yamakaky]

Not sure, as we have to drop it before the window is closed. On it.

[tomaka]

The colors are brighter because glium automatically enables gamma correction by default.

If your shader returns RGB colors, then the colors that you see with glium are correct. If your shader already does gamma correction (or if the playstation does not do gamma correction), then you can disable this at program creation.

[Yamakaky]

Then why don't we have the same results?

[tomaka]

If the OpenGL driver doesn't support automatic gamma correction (if you don't have GL_ARB_framebuffer_sRGB or OpenGL 3.0), then it's automatically ignored.

Normally it's not a problem since almost everyone supports it (just like everyone supports shaders and framebuffer objects for example), but I think there's some sort of bug where Mesa doesn't report it correctly.

[Yamakaky]

For the record, I'm on archlinux, xorg, macbook pro 8.1, intel integrated HD3000.

[Yamakaky]

Fixed by #17

[simias]

Well, that's a tricky issue actually, normally if we want to have accurate colors we should emulate the NTSC/PAL color profiles. It shouldn't be too hard to integrate a shader to do that, eventually. It's definitely not sRGB, that's for sure.

[Yamakaky]

Did you try #17 ?

[simias]

I see that in the new renderer::draw code there's no longer an explicit wait for the draw to complete, I assume that it means that glium's draw call blocks by default?

If that's the case is it possible to have a non-blocking draw for instance if we double buffer the vertex buffer to queue new vertex while the previous frame is rendering? That was an optimization I had in mind for the raw OpenGL renderer.

[tomaka]

draw doesn't block. The only thing that could block is Frame::finish if you have vsync enabled. But that was already the case with the previous code.

[Yamakaky]

Synchronisation of the permanent buffer is automatic.

[simias]

So I don't quite understand, how do you guarantee that the content of the vertex buffer is not overwritten while still being processed by the GPU?

[tomaka]

Ah I didn't see you were using PMBs.

Glium creates and manages sync fences automatically. If you use PMBs you should use triple buffering to avoid blocking.

[simias]

so that means three different vertex buffers right? I assume the locking is done at the vb level.

[tomaka]

Having a single vertex buffer that is three times the normal size also works, and is faster because you will only need one VAO.

Here is an example (with an old version of glium):

• The buffer has three times the normal size: https://github.com/tomaka/glium-azdo/blob/master/dynamic-streaming/src/main.rs#L34
• At each draw, we decide which third of the buffer we want to use: https://github.com/tomaka/glium-azdo/blob/master/dynamic-streaming/src/main.rs#L53-L56
• We write to the corresponding slice: https://github.com/tomaka/glium-azdo/blob/master/dynamic-streaming/src/main.rs#L60-L61
• And use the same slice when drawing as well: https://github.com/tomaka/glium-azdo/blob/master/dynamic-streaming/src/main.rs#L76

Glium will only use one VAO and will automatically use glDrawElementsBaseVertex.

[simias]

So glium only locks a slice of the vertex buffer? That's pretty neat.

[tomaka]

Yes

[simias]

Cool, thank you for the details.