Issue with glMapBufferRange() in Ogre 2.1 on macOS

[qfwfq]

Hi!

First of all, thanks to those of you who are working on this excellent engine. I recently ported to 2.1 from 1.9, and it has been a really good experience so far.

I have come across one issue recently though, when porting our game from Windows to macOS, and I am a bit stuck on where to go with it. So I am hoping maybe someone has had the same experience or might have some ideas on what could be wrong. I am using the current tip of v2-1 but previously also saw the same issue with an earlier checkout from February last year (though this also had other issues, since it was missing 70519c3): https://bitbucket.org/sinbad/ogre/commi ... 2c?at=v2-1

So the crash I see happens in the GL3+ render system, when using the VAO manager to create an immutable vertex buffer.

GL3PlusBufferInterface::_firstUpload() calls BufferInterface::upload(), which gets a pointer to the existing staging buffer, calls map() and then tries to write to the memory. It crashes when it tries to memcpy() into the mapped memory, since GL3PlusStagingBuffer::map() returns null in this particular case.

I tracked it down to the glMapBufferRange() inside of GL3PlusStagingBuffer::mapImpl(). Adding some debug output, I see that the first time map() is called on the staging buffer, it works fine. This is in some internals, when creating the render texture or window or something like that.

The second time, triggered by my call to createVertexBuffer(), it will map a range in the same VBO as before, at an offset, but this time it will error out with GL_INVALID_VALUE. The range is perfectly sane and should not be the problem. To make sure, I tried hardcoding the range in the code to [0, 16383] in the code. The first time it is called it still returns correctly, and the second time, a little later, it returns 0x0 and set the error to GL_INVALID_VALUE.

I verified that it calls glUnmapBuffer() on the VBO after the successful upload is done.

As a possible work around, I did try using a dynamic buffer type for the vertex buffer I create, and bypass the code path that uses the staging buffer, but when I do this, it just crashes later in HlmsPbsDatablock::uploadToConstBuffer() which also uses the staging buffer.

My really hacky workaround for now, just to get something up and running, is to change the code to consistently create a new staging buffer in VaoManager::getStagingBuffer(), which fixes the crash and I am now able to run the game. I have some other issues which I don't know if are related (sampling the diffuse texture only yields all black colors for some reason), but meshes are loaded and displayed (as black silhouettes) and the game is running.

Everything is running without a hitch on Windows, and I have no idea where to go with the glMapBufferRange() issue, since all the arguments that are passed to it seem completely sane. Has any mac users here seen anything like this?

This is a MacBook Pro with macOS 10.13.1, AMD Radeon R9 M370X (2 GB), by the way.

Thanks!

[dark_sylinc]

Is there a way to quickly repro this problem (e.g. by modifying Tutorial02 or PbsMaterials)?

Sounds like a driver bug, but without more info I cannot help on a workaround or a fix.

This is a MacBook Pro with macOS 10.13.1, AMD Radeon R9 M370X (2 GB), by the way.

Just in case, I assume you're using the GL3+ RS in macOS to target older Macs? Otherwise the recommended RS for Macs is Metal.

Cheers

[qfwfq]

Thanks! I haven't found any easy way to reproduce it yet, but I will post here as soon as I have something. I did try unmapping and remapping the same range immediately in the first call (the one which works), and this also works fine, so something must be happening to the staging buffer vbo during initialization of the game. I can test on an NVIDIA-based Macbook as well to check if it is actually a driver issue, as you say.

The reason for using GL3+ is mainly for interoperability with Qt Quick, which I am using for the 2D UI elements, but also to avoid having to write all our shaders twice. Especially since we are not planning any release on macOS at the moment. I am mainly porting it so that our graphics guy can run the game natively on his Macbook. So for now we can live with the hack to recreate the staging buffer every time an upload is needed.

Anyway, thanks for the quick response and I will keep digging and let you know if I find something.

[dark_sylinc]

Mmm... that Qt Quick interoperability could be the reason, particularly; if the Qt starts using GL calls while there's buffer of ours bound (I don't think we unbind everything after use)

[qfwfq]

Good point. I am actually resetting the context state before and after calling renderOneFrame() in Ogre: http://doc.qt.io/qt-5/qquickwindow.html ... penGLState

But it sounds like a good idea to investigate that some more.